Oracle® Fusion Middleware

Oracle SOA SuiteでのSOAアプリケーションの開発

12c (12.2.1)

E67372-02(原本部品番号:E57089-04)

2016年2月

サービス・バインディング・コンポーネントと参照バインディング・コンポーネント、Oracle BPELプロセス、ヒューマン・タスク、ビジネス・ルール、Oracle MediatorおよびSpringサービス・コンポーネントで構成される、Oracleサービス指向アーキテクチャ(SOA)コンポジット・アプリケーションを設計、保護およびデプロイする方法について説明する、開発者向けのドキュメントです。トランスフォーメーションとビジネス・イベントを設計して、ヒューマン・タスクに対して実行時にOracle BPM Worklistで操作する方法の詳細が記載されています。

Oracle Fusion Middleware Oracle SOA SuiteでのSOAアプリケーションの開発, 12c (12.2.1)

E67372-02

Copyright © 2005, 2016, Oracle and/or its affiliates All rights reserved.

原本著者:  Oracle Corporation

原本協力者: Oracle SOA Suite開発、製品管理および品質保証チーム

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

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

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

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

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

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

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

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

目次

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

はじめに

- 対象読者

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- 12c (12.2.1)の新機能と変更された機能

第I部 Oracle SOA Suiteの開始

1 Oracle SOA Suiteを使用したアプリケーション作成の概要

- 1.1 Oracle SOA Suiteの概要

- 1.1.1 サービス指向アーキテクチャ

- 1.1.2 サービス

- 1.1.3 Oracle SOA Suite

- 1.1.4 SOAを有効にするためにOracle SOA Suiteで使用する標準

- 1.1.5 SOAコンポジット・アプリケーション内のサービス・コンポーネント・アーキテクチャ

- 1.1.5.1 サービス・コンポーネント

- 1.1.5.2 バインディング・コンポーネント

- 1.1.5.3 ワイヤ

- 1.1.6 SOAコンポジット・アプリケーションの実行時の動作

- 1.1.6.1 サービス・インフラストラクチャ

- 1.1.6.2 サービス・エンジン

- 1.1.6.3 デプロイ済サービス・アーカイブ

- 1.1.7 SOAコンポジット・アプリケーション設計のアプローチ

- 1.2 Oracle SOA Suiteの開始

- 1.3 アクセシビリティ・オプションの設定

- 1.3.1 Oracle JDeveloperでのアクセシビリティ・オプションの設定

- 1.3.2 Oracle SOAコンポーザおよびOracle BPM Worklistでのアクセシビリティ・オプションの設定

- 1.3.2.1 ログイン前にアクセシビリティ機能を設定する方法

- 1.3.2.2 ログイン後にアクセシビリティ機能を設定する方法

2 SOAコンポジット・アプリケーションの開発のスタート・ガイド

- 2.1 SOAアプリケーションの作成

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

- 2.1.2 SOAアプリケーションおよびプロジェクト作成時の処理内容

- 2.2 サービス・コンポーネントの追加

- 2.2.1 サービス・コンポーネントの追加方法

- 2.2.2 サービス・コンポーネントの追加と削除に関する必知事項

- 2.2.3 サービス・コンポーネントの編集方法

- 2.3 サービス・バインディング・コンポーネントの追加

- 2.3.1 サービス・バインディング・コンポーネントの追加方法

- 2.3.2 Webサービスのインタフェース(WSDL)の定義方法

- 2.3.2.1 スキーマを使用した新規WSDLの定義

- 2.3.2.2 既存のWSDLの選択

- 2.3.2.3 コンポーネントからのサービス・インタフェースのWSDLの自動定義

- 2.3.3 スキーマの表示方法

- 2.3.4 サービス・バインディング・コンポーネントの編集方法

- 2.3.5 サービスの追加と削除に関する必知事項

- 2.3.6 同じコンポジットの異なるWSDLファイルでの同じネームスペースの使用に関する必知事項

- 2.3.7 SOAインフラストラクチャで内部と外部の両方のOracle HTTP Serverを使用する場合における「リソース」ウィンドウのWSDL参照に関する必知事項

- 2.4 参照バインディング・コンポーネントの追加

- 2.4.1 参照バインディング・コンポーネントの追加方法

- 2.4.2 参照の追加と削除に関する必知事項

- 2.4.3 WSDL参照に関する必知事項

- 2.4.4 WSDLファイルでのメッセージ・タイプの混在に関する必知事項

- 2.4.5 コンポジットのデフォルト・リビジョンの起動に関する必知事項

- 2.5 ワイヤの追加

- 2.5.1 サービスとサービス・コンポーネントの接続方法

- 2.5.2 サービス・コンポーネントと参照の接続方法

- 2.5.3 ワイヤの追加と削除に関する必知事項

- 2.6 SOAコンポジット・アプリケーションへの説明の追加

- 2.6.1 説明をSOAコンポジット・アプリケーションに追加する方法

- 2.7 コンポーネントとアーティファクトの名前変更、削除および移動

- 2.7.1 SOAコンポジット・エディタでのコンポーネントの名前変更および削除方法

- 2.7.2 「アプリケーション」ウィンドウでのアーティファクトの名前変更、移動および削除方法

- 2.8 プロパティ・インスペクタにおけるコンポーネント詳細の表示

- 2.9 セキュリティ・ポリシーの追加

- 2.10 SOAコンポジット・アプリケーションのデプロイ

- 2.10.1 デプロイ済SOAコンポジット・アプリケーションの起動方法

- 2.11 SOAコンポジット・アプリケーションの管理とテスト

- 2.11.1 Oracle JDeveloperでのデプロイ済SOAコンポジット・アプリケーションの管理方法

- 2.11.2 デプロイ済SOAコンポジット・アプリケーションのテストおよびデバッグ方法

3 デザインタイムMDSリポジトリとの共有データの管理

- 3.1 SOAデザインタイムMDSリポジトリ管理の概要

- 3.1.1 デフォルトSOAデザインタイムMDSリポジトリ接続の概要

- 3.2 デフォルトSOA-MDSの場所の変更

- 3.2.1 デフォルトSOA-MDSの場所を変更する方法

- 3.3 SOAデザインタイムMDSリポジトリとのデータの共有

- 3.3.1 SOAデザインタイムMDSリポジトリとデータを共有する方法

- 3.4 /appsフォルダの下におけるサブフォルダの作成と削除

- 3.4.1 /appsフォルダの下でサブフォルダの作成と削除を行う方法

- 3.5 JARファイルへの/appsフォルダの選択内容のエクスポート

- 3.5.1 /appsフォルダの選択内容をJARファイルにエクスポートする方法

- 3.6 /appsフォルダへのJARファイルの内容のインポート

- 3.6.1 JARファイルの内容を/appsフォルダにインポートする方法

- 3.7 別のMDSリポジトリへの/appsフォルダの選択内容の転送

- 3.7.1 /appsフォルダの選択内容を別のMDSリポジトリに転送する方法

- 3.8 JARファイルへの既存のリリース11g MDSリポジトリのエクスポート

- 3.8.1 既存のリリース11g MDSリポジトリをJARファイルにエクスポートする方法

- 3.9 SOAデザインタイムMDSリポジトリ内のファイルの参照

第II部 BPELプロセス・サービス・コンポーネントの使用

4 Oracle BPEL Process Managerのスタート・ガイド

- 4.1 BPELプロセス・サービス・コンポーネントの概要

- 4.1.1 BPELプロセス・サービス・コンポーネントの追加方法

- 4.1.2 BPELプロセス・サービス・コンポーネントを検証する方法

- 4.2 アクティビティの概要

- 4.2.1 BPELアクティビティをプロパティ・インスペクタで編集する方法

- 4.2.2 アクティビティのコピーと貼付けをBPELプロジェクトで行う方法

- 4.2.3 アクションの説明をBPELプロセス・アクティビティに追加する方法

- 4.3 パートナ・リンクの概要

- 4.4 パートナ・リンクの作成

- 4.4.1 パートナ・リンクの作成方法

- 4.4.1.1 アウトバウンド・アダプタのパートナ・リンク

- 4.4.1.2 インバウンド・アダプタのパートナ・リンク

- 4.4.1.3 抽象的なWSDLからサービスをコールするパートナ・リンク

- 4.4.1.4 抽象的なWSDLからサービスを実装するパートナ・リンク

- 4.4.1.5 パートナ・リンクとヒューマン・タスクまたはビジネス・ルール

- 4.4.1.6 既存のヒューマン・タスク、ビジネス・ルールまたはOracle Mediatorからのパートナ・リンク

- 4.5 アダプタの概要

- 4.6 BPELプロセス・モニターの概要

5 BPELプロセスの相互作用パターンの概要

- 5.1 一方向メッセージの概要

- 5.1.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

- 5.1.2 サービスとしてのBPELプロセス・サービス・コンポーネント

- 5.2 同期相互作用の概要

- 5.2.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

- 5.2.2 サービスとしてのBPELプロセス・サービス・コンポーネント

- 5.2.3 非同期プロセスを起動する同期BPELプロセス

- 5.3 非同期相互作用の概要

- 5.3.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

- 5.3.2 サービスとしてのBPELプロセス・サービス・コンポーネント

- 5.4 タイムアウト付き非同期相互作用の概要

- 5.4.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

- 5.4.2 サービスとしてのBPELプロセス・サービス・コンポーネント

- 5.5 通知タイマー付き非同期相互作用の概要

- 5.5.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

- 5.5.2 サービスとしてのBPELプロセス・サービス・コンポーネント

- 5.6 1リクエストと複数レスポンスの概要

- 5.6.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

- 5.6.2 サービスとしてのBPELプロセス・サービス・コンポーネント

- 5.7 1リクエストと二者択一レスポンスの概要

- 5.7.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

- 5.7.2 サービスとしてのBPELプロセス・サービス・コンポーネント

- 5.8 1リクエストと必須/オプション・レスポンスの概要

- 5.8.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

- 5.8.2 サービスとしてのBPELプロセス・サービス・コンポーネント

- 5.9 部分処理の概要

- 5.9.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

- 5.9.2 サービスとしてのBPELプロセス・サービス・コンポーネント

- 5.10 複数アプリケーション間の相互作用の概要

6 BPELプロセスでのXMLデータの操作

- 6.1 BPELプロセスでのXMLデータの操作の概要

- 6.1.1 BPELプロセスのXMLデータ

- 6.1.2 assignアクティビティでのデータ操作およびXPath標準

- 6.2 データ・プロバイダ・サービスへのXMLデータ操作の委任

- 6.2.1 エンティティ変数の作成方法

- 6.2.1.1 インバウンド方向のSDOの動作の理解

- 6.2.1.2 アウトバウンド方向のSDO動作の理解

- 6.2.1.3 エンティティ変数の作成とパートナ・リンクの選択

- 6.2.1.4 バインディング・キーの作成

- 6.3 ネイティブ・データとXMLとの間における変換

- 6.3.1 ネイティブ・データからXMLデータへの変換方法

- 6.3.2 XMLデータからネイティブ・データへの変換方法

- 6.3.3 インバウンド・ネイティブ・データから添付ファイルとして格納されるXMLへの変換方法

- 6.4 スタンドアロンSDOベースの変数の使用

- 6.4.1 SDOベースの変数の宣言方法

- 6.4.2 XMLからSDOへの変換方法

- 6.5 式定数またはリテラルXMLでの変数の初期化

- 6.5.1 リテラルXML要素の割当て方法

- 6.6 変数間のコピー

- 6.6.1 変数間でのコピー方法

- 6.6.2 BPEL 2.0のインラインfrom-specを使用した変数を初期化する方法

- 6.7 「構造」ウィンドウでの変数の移動およびコピー

- 6.7.1 「構造」ウィンドウで変数を移動する手順:

- 6.7.2 「構造」ウィンドウで変数をコピーする手順:

- 6.8 要素変数およびメッセージ・タイプ変数内のフィールドへのアクセス

- 6.8.1 要素ベース変数およびメッセージ・タイプベース変数内のフィールドへのアクセス方法

- 6.9 数値の割当て

- 6.9.1 数値の割当て方法

- 6.10 XPath標準による数学的計算の使用

- 6.10.1 XPath標準による数学的計算の使用方法

- 6.11 文字列リテラルの割当て

- 6.11.1 文字列リテラルの割当て方法

- 6.12 文字列の連結

- 6.12.1 文字列の連結方法

- 6.13 ブール値の割当て

- 6.13.1 ブール値の割当て方法

- 6.14 日付または時刻の割当て

- 6.14.1 日付または時刻の割当て方法

- 6.15 属性の操作

- 6.15.1 属性の操作方法

- 6.16 bpelx拡張要素を使用したXMLデータの操作

- 6.16.1 bpelx:appendの使用方法

- 6.16.1.1 BPEL 1.1のbpelx:append

- 6.16.1.2 BPEL 2.0のbpelx:append

- 6.16.2 bpelx:insertBeforeの使用方法

- 6.16.2.1 BPEL 1.1のbpelx:insertBefore

- 6.16.2.2 BPEL 2.0のbpelx:insertBefore

- 6.16.3 bpelx:insertAfterの使用方法

- 6.16.3.1 BPEL 1.1のbpelx:insertAfter

- 6.16.3.2 BPEL 2.0のbpelx:insertAfter

- 6.16.4 bpelx:removeの使用方法

- 6.16.4.1 BPEL 1.1のbpelx:remove

- 6.16.4.2 BPEL 2.0のbpelx:remove

- 6.16.5 bpelx:renameおよびXSDタイプ・キャストの使用方法

- 6.16.5.1 BPEL 1.1のbpelx:rename

- 6.16.5.2 BPEL 2.0のbpelx:rename

- 6.16.6 bpelx:copyListの使用方法

- 6.16.6.1 BPEL 1.1のbpelx:copyList

- 6.16.6.2 BPEL 2.0のbpelx:copyList

- 6.16.7 assign拡張要素の属性の使用方法

- 6.16.7.1 ignoreMissingFromData属性

- 6.16.7.2 insertMissingToData属性

- 6.16.7.3 keepSrcElementName属性

- 6.17 XMLデータの検証

- 6.17.1 BPEL 2.0のXMLデータの検証方法

- 6.17.1.1 assignアクティビティでのXMLの検証

- 6.17.1.2 スタンドアロン、拡張validateアクティビティでのXMLの検証

- 6.17.2 BPEL 1.1のXMLデータの検証方法

- 6.17.2.1 assignアクティビティでのXMLの検証

- 6.17.2.2 スタンドアロン、拡張validateアクティビティでのXMLの検証

- 6.18 BPEL 2.0のメッセージ交換アクティビティでの要素変数の使用

- 6.19 BPEL 2.0でのWSDLメッセージ・パートのマップ

- 6.19.1 WSDLメッセージ・パートのマップ方法

- 6.20 BPEL 2.0でのプロセス定義のインポート

- 6.21 配列に類似したXMLデータ・シーケンスの操作

- 6.21.1 配列を使用するXMLデータ・シーケンスへの静的な索引付け方法

- 6.21.2 SOAPでエンコードされた配列の使用方法

- 6.21.2.1 BPEL 2.0のSOAPでエンコードされた配列

- 6.21.2.2 スキーマ内でwsdl:arrayType属性を使用したSOAP配列の宣言

- 6.21.3 シーケンス・サイズの決定方法

- 6.21.4 式の末尾へのXPathの適用による動的な索引付け方法

- 6.21.4.1 getVariableDataの結果の末尾へのXPathの適用

- 6.21.4.2 bpelx:append拡張要素によるシーケンスへの新しい項目の追加

- 6.21.4.3 データ・シーケンスのマージ

- 6.21.4.4 空要素の配列と等価の機能の生成

- 6.21.5 配列識別子の使用に関する必知事項

- 6.22 文字列からXML要素への変換

- 6.22.1 文字列からXML要素への変換方法

- 6.23 ドキュメント形式とRPC形式のWSDLの違いの理解

- 6.23.1 RPC形式ファイルの使用方法

- 6.24 BPELでのSOAPヘッダーの操作

- 6.24.1 BPELでのSOAPヘッダーの受信方法

- 6.24.2 BPELでのSOAPヘッダーの送信方法

- 6.25 BPEL 2.0での拡張ネームスペースの宣言

- 6.25.1 拡張ネームスペースの宣言方法

- 6.25.2 拡張機能作成時の処理内容

7 BPELプロセスからの同期Webサービスの起動

- 7.1 同期Webサービスの起動に関する概要

- 7.2 同期Webサービスの起動

- 7.2.1 同期Webサービスの起動方法

- 7.2.1.1 BPELプロセスの動作方法

- 7.2.2 同期Webサービス起動時の処理内容

- 7.2.2.1 BPELコード内のパートナ・リンク

- 7.2.2.2 BPELコード内のパートナ・リンク・タイプとポート・タイプ

- 7.2.2.3 リクエストを実行するためのinvokeアクティビティ

- 7.2.2.4 BPELコードでの同期起動

- 7.3 永続同期プロセスのトランザクションのタイムアウト値の指定

- 7.3.1 トランザクションのタイムアウト値の指定方法

- 7.3.2 SyncMaxWaitTimeとタイムアウトのない永続同期リクエストに関する必知事項

- 7.4 同期BPELプロセスを使用した一方向メディエータのコール

8 BPELプロセスからの非同期Webサービスの起動

- 8.1 非同期Webサービスの起動に関する概要

- 8.2 非同期Webサービスの起動

- 8.2.1 非同期Webサービスの起動方法

- 8.2.1.1 非同期サービスに対するパートナ・リンクの追加

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

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

- 8.2.1.4 その他のアクティビティの実行

- 8.2.2 非同期Webサービス起動時の処理内容

- 8.2.2.1 WSDLファイルのportTypeセクション

- 8.2.2.2 WSDLファイルのpartnerLinkTypeセクション

- 8.2.2.3 BPELファイルのパートナ・リンク・セクション

- 8.2.2.4 コンポジット・アプリケーション・ファイル

- 8.2.2.5 invokeアクティビティとreceiveアクティビティ

- 8.2.2.6 新しいインスタンスを開始するためのcreateInstance属性

- 8.2.2.7 長期間にわたる非同期プロセスを保持するためのデハイドレーション・ポイント

- 8.2.2.8 複数のランタイム・エンドポイント・ロケーション

- 8.2.3 タイムアウト後にメッセージをコンシュームする中間プロセスのreceiveアクティビティに関する必知事項

- 8.2.4 複数のクライアント・コンポーネントによる1つのコンポジットの起動に関する必知事項

- 8.2.5 BPEL 2.0 IMAサポートの制限に関する必知事項

- 8.2.6 対話ID指定時の処理内容

- 8.2.6.1 BPEL 1.1のbpelx:conversationId

- 8.2.6.2 BPEL 2.0のbpelx:conversationId

- 8.3 複数のreceiveまたはpickアクティビティで同じパートナ・リンクが使用されている場合における適切なエンドポイントへのコールバック・メッセージのルーティング

- 8.3.1 複数のreceiveまたはpickアクティビティで同じパートナ・リンクが使用されている場合における適切なエンドポイントへのコールバック・メッセージのルーティング

- 8.4 パートナ・リンク操作レベルでの冪等性の管理

- 8.4.1 パートナ・リンク操作レベルでの冪等性の管理方法

- 8.5 実行時に使用するための動的パートナ・リンクの設計時の作成

- 8.5.1 実行時に使用するための動的パートナ・リンクの設計時の作成方法

- 8.6 動的パートナ・リンクを起動する際のセキュリティ証明書のオーバーライド

- 8.7 動的パートナ・リンクのWSDLファイルのオーバーライド

- 8.8 非同期サービスでのWS-Addressingの使用

- 8.8.1 非同期サービスでのWS-Addressingの使用方法

- 8.8.1.1 プログラム間で交換されるメッセージを表示するためのTCPトンネリングの使用方法

- 8.8.1.1.1 同期サービス用のTCPリスナーの設定

- 8.8.1.1.2 非同期サービス用のTCPリスナーの設定

9 相関セットおよびメッセージ集約の使用

- 9.1 非同期サービスでの相関セットの概要

- 9.1.1 相関セットの使用のシナリオ

- 9.1.2 相関セットの内容および概念の理解

- 9.1.3 相関セットの作成の概要

- 9.2 Oracle JDeveloperにおける相関セットの作成

- 9.2.1 相関ウィザードで相関セットを作成する方法

- 9.2.2 「相関」タブで相関セットを手動で作成する方法

- 9.2.2.1 ステップ1: プロジェクトの作成

- 9.2.2.2 ステップ2: パートナ・リンクとファイル・アダプタ・サービスの構成

- 9.2.2.2.1 最初のパートナ・リンクとファイル・アダプタ・サービスの作成

- 9.2.2.2.2 2番目のパートナ・リンクとファイル・アダプタ・サービスの作成

- 9.2.2.3 ステップ3: 3つのreceiveアクティビティの作成

- 9.2.2.3.1 最初のreceiveアクティビティの作成

- 9.2.2.3.2 2番目のreceiveアクティビティの作成

- 9.2.2.4 ステップ4: 相関セットの作成

- 9.2.2.4.1 最初の相関セットの作成

- 9.2.2.4.2 2番目の相関セットの作成

- 9.2.2.5 ステップ5: 相関セットとreceiveアクティビティの関連付け

- 9.2.2.5.1 receiveアクティビティへの最初の相関セットの関連付け

- 9.2.2.5.2 receiveアクティビティへの2番目の相関セットの関連付け

- 9.2.2.5.3 receiveアクティビティへの3番目の相関セットの関連付け

- 9.2.2.6 ステップ6: プロパティ・エイリアスの作成

- 9.2.2.6.1 NameCorrのプロパティ・エイリアスの作成

- 9.2.2.6.2 IDCorrのプロパティ・エイリアスの作成

- 9.2.2.7 ステップ7: WSDLファイルのコンテンツの確認

- 9.2.3 変換IDおよび異なるコンポジット・リビジョンに関する必知事項

- 9.2.4 複数のパートを持つfromParts要素を使用したIMAの相関の設定に関する必知事項

- 9.3 同じインスタンスへのメッセージのルーティング

- 9.3.1 BPELプロセス・インスタンス作成の構成方法

- 9.3.2 receiveアクティビティのエントリと中間プロセスのreceiveアクティビティで同じ操作を使用する方法

- 9.3.3 相関セット使用時の新規インスタンスまたは既存インスタンスへのメッセージのルーティング方法

10 BPELプロセスでのパラレル・フローの使用

- 10.1 BPELプロセスでのパラレル・フローの概要

- 10.1.1 シングル・スレッドでのフローのブランチのパラレル実行に関する必知事項

- 10.2 パラレル・フローの作成

- 10.2.1 パラレル・フローの作成方法

- 10.2.2 パラレル・フロー作成時の処理内容

- 10.2.3 flowアクティビティ内のアクティビティ実行の同期化

- 10.2.4 flowアクティビティ内のアクティビティ間に同期を作成する方法

- 10.2.5 flowアクティビティ内のアクティビティ間に同期を作成するときの処理内容

- 10.2.6 ターゲット・アクティビティの結合条件に関する必知事項

- 10.3 パラレル・ブランチ数のカスタマイズ

- 10.3.1 BPEL 2.0のforEachアクティビティによるアクティビティの複数のセットの処理

- 10.3.1.1 forEachアクティビティの作成方法

- 10.3.1.2 forEachアクティビティ作成時の処理内容

- 10.3.2 BPEL 1.1のflowNアクティビティによるflowアクティビティ数のカスタマイズ

- 10.3.2.1 flowNアクティビティの作成方法

- 10.3.2.2 flowNアクティビティ作成時の処理内容

11 BPELプロセスでの条件分岐の使用

- 11.1 条件分岐の概要

- 11.2 ifまたはswitchアクティビティによる条件分岐の定義

- 11.2.1 BPEL 2.0のifアクティビティの作成による条件分岐の定義

- 11.2.1.1 ifアクティビティの作成方法

- 11.2.1.2 ifアクティビティ作成時の処理内容

- 11.2.2 BPEL 1.1のswitchアクティビティの作成による条件分岐の定義

- 11.2.2.1 switchアクティビティの作成方法

- 11.2.2.2 switchアクティビティ作成時の処理内容

- 11.3 whileアクティビティによる条件分岐の定義

- 11.3.1 whileアクティビティの作成方法

- 11.3.2 whileアクティビティ作成時の処理内容

- 11.4 repeatUntilアクティビティによる条件分岐の定義

- 11.4.1 repeatUntilアクティビティの作成方法

- 11.4.2 repeatUntilアクティビティ作成時の処理内容

- 11.5 アクティビティの実行をバイパスするためのXPath式の指定

- 11.5.1 アクティビティの実行をバイパスするためのXPath式の指定方法

- 11.5.2 アクティビティの実行をバイパスするためのXPath式指定時の処理内容

12 BPELプロセスでのフォルト処理の使用

- 12.1 フォルト・ハンドラの概要

- 12.2 BPEL標準フォルトの概要

- 12.2.1 BPEL 1.1の標準フォルト

- 12.2.2 BPEL 2.0の標準フォルト

- 12.2.2.1 BPEL 2.0でのフォルト処理の優先順位

- 12.3 BPELフォルトのビジネスおよび実行時のフォルト・カテゴリの概要

- 12.3.1 ビジネス・フォルト

- 12.3.2 実行時フォルト

- 12.3.2.1 bindingFault

- 12.3.2.2 remoteFault

- 12.3.2.3 replayFault

- 12.3.3 同期BPELプロセスでのフォルト処理の追加および伝播方法

- 12.3.3.1 スキーマおよびWSDLファイルの編集

- 12.3.3.2 フォルト・ハンドラの追加

- 12.3.3.3 フォルト・レスポンス変数の作成

- 12.3.3.4 Catch Activityブランチへのassignアクティビティの追加

- 12.3.3.5 Catch Activityブランチへのreplyアクティビティの追加

- 12.4 フォルト管理フレームワークを使用したフォルトの処理

- 12.4.1 フォルト・ポリシー・バインディングによる解決方法の理解

- 12.4.2 自動フォルト・リカバリのフォルト・ポリシーをフォルト・ポリシー・ウィザードで設計する方法

- 12.4.2.1 手順1: プロパティ・セットの定義

- 12.4.2.2 手順2: アラートの定義

- 12.4.2.3 手順3: アクションの定義

- 12.4.2.4 手順4: フォルト名およびポリシーの定義

- 12.4.2.5 手順5: フォルト・ポリシーに対するフォルト・ポリシー・バインディングの定義

- 12.4.3 自動フォルト・リカバリのフォルト・ポリシー・ファイルを手動で設計する方法

- 12.4.3.1 自動フォルト・リカバリに対するフォルト・ポリシー・ファイルの手動作成

- 12.4.3.2 フォルト・ポリシー・バインディングへのフォルト・ポリシーの関連付け

- 12.4.3.3 その他のフォルト・ポリシーおよびフォルト・ポリシー・バインディング・ファイルのサンプル

- 12.4.3.4 複数の拒否ハンドラがあるフォルト・ポリシーの設計

- 12.4.4 フォルト・ポリシーの実行方法

- 12.4.5 Javaアクション・フォルト・ポリシーの使用方法

- 12.4.6 Oracle BPM Suiteに対してフォルト・ポリシーを設計する方法

- 12.4.7 フォルト・ポリシーを同期BPELプロセスで設計する方法に関する必知事項

- 12.4.8 インスタンス再試行回数を超過した場合のフォルト管理動作に関する必知事項

- 12.4.9 フォルト・ポリシー再試行中のバインディング・レベル再試行に関する必知事項

- 12.5 BPEL実行時フォルトの捕捉

- 12.5.1 BPEL実行時フォルトの捕捉方法

- 12.6 getFaultAsString XPath拡張関数によるフォルト詳細の取得

- 12.6.1 getFaultAsString XPath拡張関数によるフォルト詳細の取得方法

- 12.7 throwアクティビティによる内部フォルトのスロー

- 12.7.1 throwアクティビティの作成方法

- 12.7.2 throwアクティビティ作成時の処理内容

- 12.8 rethrowアクティビティによるフォルトの再スロー

- 12.8.1 rethrowアクティビティの作成方法

- 12.8.2 フォルト再スロー時の処理内容

- 12.9 外部フォルトを返す

- 12.9.1 同期相互作用でフォルトを返す方法

- 12.9.2 非同期相互作用でフォルトを返す方法

- 12.10 scopeアクティビティによるアクティビティ・グループの管理

- 12.10.1 scopeアクティビティの作成方法

- 12.10.2 scopeアクティビティへの説明ノートおよびイメージの追加

- 12.10.3 scopeアクティビティ作成後の処理内容

- 12.10.4 スコープに関する必知事項

- 12.10.5 スコープ内のフォルト・ハンドラの使用方法

- 12.10.6 idempotentプロパティとフォルト処理に関する必知事項

- 12.10.7 スコープでのcatchアクティビティの作成方法

- 12.10.8 スコープでのcatchアクティビティ作成時の処理内容

- 12.10.9 emptyアクティビティによる操作なしの命令のビジネス・プロセスへの挿入方法

- 12.10.10 emptyアクティビティ作成時の処理内容

- 12.11 replayアクティビティによるscopeアクティビティ内でのアクティビティの再実行

- 12.11.1 replayアクティビティの作成方法

- 12.11.2 replayアクティビティ作成時の処理内容

- 12.12 一連の操作を元に戻した後の補正の使用

- 12.12.1 compensateアクティビティの使用

- 12.12.2 compensateアクティビティの作成方法

- 12.12.3 compensateアクティビティ作成時の処理内容

- 12.12.4 BPEL 2.0のcompensateScopeアクティビティの使用

- 12.12.5 compensateScopeアクティビティの作成方法

- 12.12.6 compensateScopeアクティビティ作成時の処理内容

- 12.13 terminateアクティビティまたはexitアクティビティによるビジネス・プロセス・インスタンスの停止

- 12.13.1 BPEL 2.0のexitアクティビティによるビジネス・プロセス・インスタンスの即時終了

- 12.13.1.1 exitアクティビティの作成方法

- 12.13.1.2 exitアクティビティ作成時の処理内容

- 12.13.2 BPEL 1.1のterminateアクティビティによるビジネス・プロセス・インスタンスの停止

- 12.13.2.1 terminateアクティビティの作成方法

- 12.13.2.2 terminateアクティビティ作成時の処理内容

- 12.14 アサーション条件によるフォルトのスロー

- 12.14.1 アサーション条件の作成方法

- 12.14.1.1 invokeアクティビティ、receiveアクティビティ、replyアクティビティおよびOnMessageブランチでアサート条件を作成する手順は、次のとおりです。

- 12.14.1.2 スタンドアロンassertアクティビティのアサート条件を作成する手順は、次のとおりです。

- 12.14.2 アサーションを無効にする方法

- 12.14.3 アサーション条件作成時の処理内容

- 12.14.4 アサーション条件に関する必知事項

- 12.14.4.1 bpelx:postAssertおよびbpelx:preAssert拡張要素

- 12.14.4.2 faultName属性とmessage属性の使用

- 12.14.4.3 複数のアサーション

- 12.14.4.4 組込みおよびカスタムのXPath関数と$variable参照の使用

- 12.14.4.5 インスタンス監査証跡に対するイベントのアサーション条件評価ロギング

- 12.14.4.6 XMLスキーマ・ブール値タイプに評価されない式によるフォルトのスロー

- 12.14.4.7 スタンドアロンassertアクティビティのアサーション条件

- 12.14.5 アサート後およびアサート前条件のスキーマおよび構文に関する必知事項

- 12.15 再試行可能とのSOAPフォルトの分類

13 BPELプロセスでのトランザクションおよびフォルト伝播のセマンティクス

- 13.1 トランザクション・セマンティクスの概要

- 13.1.1 Oracle BPEL Process Managerのトランザクション・セマンティクス

- 13.1.1.1 bpel.config.transactionがrequiresNewに設定されているBPELCalleeプロセスがBPELCallerプロセスによってコールされる

- 13.1.1.2 bpel.config.transactionがrequiredに設定されているBPELCalleeプロセスがBPELCallerプロセスによってコールされる

- 13.2 一方向起動の実行の概要

- 13.3 トランザクションなしのビジネス・プロセスの実行

- 13.3.1 トランザクションなしでBPELプロセスを使用するタイミング

- 13.3.2 トランザクションなしの実行に関するガイドライン

- 13.3.3 トランザクションなしの同期BPELプロセスの作成方法

- 13.3.4 トランザクションなしの非同期BPELプロセスの作成方法

- 13.4 システム・パフォーマンスの向上のためのメモリー内SOAの使用

- 13.4.1 インメモリー・フロー・インスタンスに対する永続性の設定

- 13.4.2 メモリー内SOAを有効にする手順

- 13.4.2.1 メモリー内SOAフラグの有効化

- 13.4.2.2 メモリー内で実行するビジネス・プロセスの設計

- 13.4.2.2.1 非トランザクションとしての既存のビジネス・プロセスの設定

- 13.4.2.2.2 既存のBPELプロセスの完了永続ポリシーの設定

14 BPELプロセスへのJavaおよびJava EEコードの組込み

- 14.1 BPELプロセスのJavaおよびJava EEコードの概要

- 14.2 BPELプロセスへのJavaおよびJava EEコードの組込み

- 14.2.1 JavaコードをSOAPサービスとしてラップする方法

- 14.2.2 SOAPサービスとしてのJavaコードのラップに関する必知事項

- 14.2.3 bpelx:execタグを使用してBPELプロセスにJavaコード・スニペットを埋め込む方法

- 14.2.4 BPEL 2.0プロセスにJavaコード・スニペットを埋め込む方法

- 14.2.5 XML Facadeを使用してDOM操作を単純化する方法

- 14.2.6 bpelx:exec組込みメソッドを使用する方法

- 14.2.7 サービス・インタフェースにラップされたJavaコードを使用する方法

- 14.3 カスタム・クラスおよびJARファイルの追加

- 14.3.1 カスタム・クラスおよびJARファイルの追加方法

- 14.3.1.1 JARをBpelcClasspathに追加する手順

- 14.3.1.2 カスタム・クラスを追加する手順

- 14.3.1.3 カスタムJARを追加する手順

- 14.4 Oracle JDeveloperのBPELプロセスでのJava埋込みの使用

- 14.4.1 Oracle JDeveloperのBPELプロセスでのJava埋込みの使用方法

- 14.4.2 Java Embeddingアクティビティでのthread.sleep()の使用に関する必知事項

- 14.5 bpelx:execによるサービス・データ・オブジェクトの埋込み

- 14.6 Oracle BPEL Process Managerとのクラスのカスタム実装の共有

- 14.6.1 BPEL接続マネージャ・クラスが優先されるように構成する方法

15 BPELプロセスでのイベントおよびタイムアウトの使用

- 15.1 イベントおよびタイムアウトの概念に関する概要

- 15.2 pickアクティビティのプロセスの待機または継続の選択

- 15.2.1 pickアクティビティの作成方法

- 15.2.2 pickアクティビティ作成時の処理内容

- 15.2.3 BPEL 2.0の同時onMessageブランチに関する必知事項

- 15.3 receiveアクティビティのリクエスト/リプライ操作および入力専用操作に対するタイムアウトの設定

- 15.3.1 receiveアクティビティのタイムアウトの設定方法

- 15.3.2 receiveアクティビティのタイムアウト設定時の処理内容

- 15.3.3 リクエスト・リプライ操作および入力専用操作に対するタイムアウトの設定に関する必知事項

- 15.3.3.1 アクティビティの起動時からの相対的なタイムアウト設定

- 15.3.3.2 絶対的な日時でのタイムアウト設定

- 15.3.3.3 XPath式を使用して動的に計算されるタイムアウト設定

- 15.3.3.4 アクティビティ・タイムアウト時にスローされるbpelx:timeoutフォルト

- 15.3.3.5 アクティビティ・タイムアウト時にBPELインスタンス監査証跡に追加されるイベント

- 15.3.3.6 サーバー再起動時にリカバリ可能なタイムアウト・アクティビティ(有効期限アラーム表のリフレッシュ)

- 15.4 waitアクティビティによる有効期限の設定

- 15.4.1 最小待機時間の指定方法

- 15.4.2 waitアクティビティの作成方法

- 15.4.3 waitアクティビティ作成時の処理内容

- 15.5 BPEL 2.0のOnEventブランチを使用してメッセージ着信を待機するためのイベントの指定

- 15.5.1 scopeアクティビティでのonEventブランチの作成方法

- 15.5.2 OnEventブランチ作成時の処理内容

- 15.6 永続同期プロセスに対するタイムアウトの設定

- 15.7 BPELプロセスにおけるOracle Enterprise Schedulerジョブの起動

- 15.7.1 OracleデータベースとSOA-MDSの接続を作成する方法

- 15.7.2 スケジュール・ジョブ・アクティビティを作成する方法

- 15.7.3 セキュリティ・ポリシーをサービス・バインディング・コンポーネントと参照バインディング・コンポーネントにアタッチする方法

16 マスター・プロセスと詳細プロセスの調整

- 16.1 マスター・プロセスと詳細プロセスの調整に関する概要

- 16.1.1 マスター・プロセスに対するBPELファイル定義

- 16.1.1.1 マスター・プロセスと複数の詳細プロセスの相関

- 16.1.2 詳細プロセスに対するBPELファイル定義

- 16.2 Oracle JDeveloperでのマスター・プロセスと詳細プロセスの調整の定義

- 16.2.1 マスター・プロセスの作成方法

- 16.2.2 詳細プロセスの作成方法

- 16.2.3 invokeアクティビティの作成方法

17 通知サービスの使用

- 17.1 通知サービスの概要

- 17.2 通知チャネル設定の概要

- 17.3 BPELプロセスの設計での通知チャネルの選択

- 17.3.1 電子メール通知チャネルの構成方法

- 17.3.1.1 電子メール添付ファイルの設定

- 17.3.1.2 電子メール・メッセージ本文のHTMLとしての書式設定

- 17.3.1.3 CDATA関数を必要とするメッセージ・コンテンツに対する動的HTMLの使用

- 17.3.2 IM通知チャネルの構成方法

- 17.3.3 SMS通知チャネルの構成方法

- 17.3.4 ボイス通知チャネルの構成方法

- 17.3.5 電子メール・アドレスと電話番号を動的に選択する方法

- 17.3.6 ユーザー・ディレクトリの参照による通知受信者の選択方法

- 17.4 エンド・ユーザーによる通知チャネル選択の許可

- 17.4.1 エンド・ユーザーによる通知チャネルの選択を許可する方法

- 17.4.1.1 通知のヘッダーの作成および送信方法

18Oracle BPEL Process Managerセンサーと分析の使用

- 18.1 Oracle BPEL Process Managerセンサーの概要

- 18.1.1 コンポジット・センサー

- 18.2 Oracle JDeveloperでのセンサーとセンサー・アクションの構成

- 18.2.1 センサーとセンサー・アクションへのアクセス方法

- 18.2.2 アクティビティ、変数、フォルトの各センサーの構成方法

- 18.2.2.1 アクティビティ・センサーを構成する手順:

- 18.2.2.2 変数センサーを構成する手順:

- 18.2.2.3 フォルト・センサーを構成する手順:

- 18.2.3 センサー・アクションの構成方法

- 18.2.4 リモート・トピックおよびキューへのパブリッシュ方法

- 18.2.5 カスタム・データ・パブリッシャの作成方法

- 18.2.6 composite.xmlファイルへのセンサーとセンサー・アクションの登録方法

- 18.3 Oracle Enterprise Manager Fusion Middleware Controlコンソールでのセンサーの定義とセンサー・アクション定義の表示

- 18.4 BPELプロセス分析の構成

- 18.4.1 ビジネス・インジケータの概要

- 18.4.2 標準サンプリング・ポイントの概要

- 18.4.3 ユーザー定義のサンプリング・ポイントの概要

- 18.4.4 分析ビューにアクセスする方法

- 18.4.4.1 ビジネス・インジケータを定義する方法

- 18.4.4.1.1 カウンタの定義

- 18.4.4.1.2 ディメンションの定義

- 18.4.4.1.3 メジャーの定義

- 18.4.4.2 測定を定義する方法

- 18.4.4.2.1 カウンタ・マークを定義する方法

- 18.4.4.2.2 間隔の開始を定義する方法

- 18.4.4.2.3 間隔の停止を定義する方法

- 18.4.4.2.4 単一マークを定義する方法

- 18.4.4.3 コンポジット・レベル分析サンプリング・ポイントを構成する方法

- 18.4.4.4 プロセス・レベル分析サンプリング・ポイントを構成する方法

- 18.4.5 ビジネス・インジケータをビジネス・インジケータ概要エディタで編集する方法

- 18.4.6 BPEL分析のデプロイ

- 18.4.7 実行時におけるBPEL分析の表示

第III部 Oracle Mediatorサービス・コンポーネントの使用

19 Oracle Mediatorのスタート・ガイド

- 19.1 Oracle Mediatorの概要

- 19.2 メディエータの機能

- 19.2.1 コンテンツ・ベースおよびヘッダー・ベースのルーティング

- 19.2.2 同期および非同期の相互作用

- 19.2.3 メッセージの順次およびパラレルのルーティング

- 19.2.4 メッセージの再順序付け

- 19.2.5 データ・トランスフォーメーション

- 19.2.6 ペイロード検証

- 19.2.7 Javaコールアウト

- 19.2.8 イベント処理

- 19.2.9 動的ルーティング

- 19.2.10 エラー処理

- 19.2.11 コール元へのメッセージの返信(エコー)

- 19.2.12 複数パート・メッセージ

- 19.3 メディエータの作成

- 19.3.1 メディエータの作成方法

- 19.3.1.1 メディエータを使用するコンポジット・アプリケーションを作成する手順:

- 19.3.1.2 既存のコンポジット・アプリケーション内にメディエータを作成する手順:

- 19.3.1.3 メディエータを使用する新規プロジェクトを作成する手順は、次のとおりです。

- 19.3.1.4 既存のプロジェクト内にメディエータを作成する手順は、次のとおりです。

- 19.4 メディエータ・エディタ環境の概要

- 19.5 メディエータのインタフェース定義の構成

- 19.5.1 メディエータのインタフェース定義の構成方法

- 19.5.2 メディエータ作成時の処理内容

- 19.5.2.1 インタフェース定義を使用しない

- 19.5.2.2 WSDLベースのインタフェースを使用

- 19.5.2.3 一方向インタフェース定義を使用

- 19.5.2.4 同期インタフェース定義を使用

- 19.5.2.5 非同期インタフェース定義を使用

- 19.5.2.6 イベント・サブスクリプションを使用

- 19.6 メディエータのインタフェースの定義

- 19.6.1 メディエータのインタフェースの定義方法

- 19.6.1.1 イベントをサブスクライブする手順:

- 19.6.1.2 ワイヤを使用してメディエータのサービスを定義する手順:

- 19.6.1.3 メディエータ・エディタでメディエータのサービスを定義する手順:

- 19.7 WSDLファイルの生成

- 19.7.1 WSDLファイルの生成方法

- 19.7.1.1 XSDファイルから一方向インタフェース用のWSDLファイルを生成する手順は、次のとおりです。

- 19.7.1.2 XSDファイルから同期インタフェース用のWSDLファイルを生成する手順は、次のとおりです。

- 19.7.1.3 XSDファイルから非同期インタフェース用のWSDLファイルを生成する手順は、次のとおりです。

- 19.8 検証および優先度のプロパティの指定

- 19.9 メディエータ・サービス・コンポーネントの変更

- 19.9.1 メディエータの操作の変更方法

- 19.9.2 メディエータのイベント・サブスクリプションの変更方法

20 Oracle Mediatorルーティング・ルールの作成

- 20.1 ルーティング・ルールの概要

- 20.1.1 静的ルーティング・ルール

- 20.1.1.1 静的ルールのタイプ

- 20.1.1.2 静的ルーティング・ルール・コンポーネント

- 20.1.2 動的ルーティング・ルール

- 20.1.3 順次実行およびパラレル実行

- 20.1.3.1 順次ルーティング・ルールの基本原則

- 20.1.3.2 パラレルのルーティング・ルールの基本原則

- 20.1.3.3 パラレル・ルーティングにおけるスレッド割当ての精細制御

- 20.2 再順序付けルール

- 20.3 ルーティング・ルールの定義

- 20.3.1 「ルーティング・ルール」セクションへのアクセス方法

- 20.3.1.1 SOAコンポジット・エディタから:

- 20.3.1.2 「アプリケーション」ウィンドウからアクセスする方法

- 20.3.2 静的ルーティング・ルールの作成方法

- 20.3.2.1 メディエータ・サービスまたはイベントの指定方法

- 20.3.2.1.1 サービスを起動する手順:

- 20.3.2.1.2 イベントをトリガーする手順:

- 20.3.2.1.3 サービスをエコーする手順:

- 20.3.2.2 サービスのエコーに関する必知事項

- 20.3.2.3 順次実行またはパラレル実行の指定方法

- 20.3.2.4 レスポンス・メッセージの構成方法

- 20.3.2.5 早すぎるコールバックの処理方法

- 20.3.2.6 複数コールバックの処理方法

- 20.3.2.7 フォルトの処理方法

- 20.3.2.7.1 追加のフォルト・ルーティングを定義する手順:

- 20.3.2.7.2 フォルト・ルーティング・セクションを削除する手順:

- 20.3.2.8 メッセージをフィルタリングする式の指定方法

- 20.3.2.8.1 メッセージをフィルタリングする式を指定する手順:

- 20.3.2.8.2 メッセージ・ペイロードのフィルタ式を指定する手順:

- 20.3.2.9 ネイティブXSDフォーマットとXMLフォーマットとの間における変換方法

- 20.3.2.10 インバウンド変換を使用する方法

- 20.3.2.11 アウトバウンド変換を使用する方法

- 20.3.2.12 XSLTトランスフォーメーションの作成方法

- 20.3.2.12.1 トランスフォーメーションを作成する手順:

- 20.3.2.12.2 ユーザー定義拡張関数を追加する手順:

- 20.3.2.13 XQueryトランスフォーメーションを作成する方法

- 20.3.2.13.1 XQueryトランスフォーメーションを作成するには:

- 20.3.2.13.2 XQueryトランスフォーメーションを編集するには:

- 20.3.2.14 値の割当て方法

- 20.3.2.14.1 ソース・ノードをターゲット・ノードにコピーするには:

- 20.3.2.14.2 複合式を割り当てるには:

- 20.3.2.14.3 定数値とXMLフラグメントを割り当てるには:

- 20.3.2.15 assignアクティビティに関する必知事項

- 20.3.2.16 フィルタおよび割当てのためのヘッダー・アクセス方法

- 20.3.2.16.1 フィルタおよび割当てのためのヘッダー・アクセスに使用する式の手動作成

- 20.3.2.16.2 フィルタおよび割当てのためのプロパティ・アクセスに使用する式の手動作成

- 20.3.2.17 セマンティク検証の使用方法

- 20.3.2.18 添付ファイルの処理方法

- 20.3.2.19 Javaコールアウトの使用方法

- 20.3.2.19.1 Javaコールアウト・クラスを使用できるようにする手順:

- 20.3.2.19.2 コールアウトのJavaクラスを入力する手順:

- 20.3.2.19.3 ペイロードのルート要素を設定する手順(フィルタ式を使用している場合):

- 20.3.2.19.4 ドメイン値マップと相互参照関数を有効にする手順:

- 20.3.2.19.5 メディエータのJavaコールアウトAPI

- 20.3.2.19.6 Javaコールアウト・クラスのサンプル

- 20.3.3 動的ルーティング・ルールの作成方法

- 20.3.3.1 DVMを使用して静的ルーティング・ルールを動的にオーバーライドする方法

- 20.3.3.1.1 DVMを使用して静的ルーティングをオーバーライドするには:

- 20.3.3.1.2 新規ドメインをDVMに追加するには:

- 20.3.3.1.3 新規行をDVMに追加するには:

- 20.3.3.1.4 ドメインをDVMから削除するには:

- 20.3.3.1.5 行をDVMから削除するには:

- 20.3.3.2 デシジョン・コンポーネントを使用して静的ルーティング・ルールを動的にオーバーライドする方法

- 20.3.3.2.1 デシジョン・コンポーネントを使用して静的ルーティングをオーバーライドするには:

- 20.3.3.2.2 デシジョン・コンポーネントを編集する手順は、次のとおりです。

- 20.3.3.3 既存の動的ルーティング・ルールの削除方法

- 20.3.4 動的ルーティング・ルールの使用に関する必知事項

- 20.3.5 デフォルト・ルーティング・ルールの定義方法

- 20.3.5.1 デフォルト・ルールのシナリオ

- 20.3.5.2 デフォルト・ルールのターゲット

- 20.3.5.3 デフォルト・ルール: 検証、トランスフォーメーションおよび割当て機能

- 20.3.5.4 デフォルト・ルール: Javaコールアウト

- 20.3.5.5 デフォルト・ルール: メディエータ.mplanファイル

- 20.4 メディエータ・ルーティングのユースケース

21 Oracle Mediatorにおける複数パート・メッセージの使用

- 21.1 メディエータのマルチパート・メッセージ・サポートの概要

- 21.2 マルチパートのリクエスト・メッセージの使用

- 21.2.1 マルチパートのリクエスト・メッセージに対するフィルタ式の指定方法

- 21.2.2 マルチパートのリクエスト・メッセージに対する検証の追加方法

- 21.2.3 マルチパートのリクエスト・メッセージに対するトランスフォーメーションの作成方法

- 21.2.4 マルチパートのリクエスト・メッセージに対する値の割当て方法

- 21.2.5 マルチパートのリプライ、フォルトおよびコールバック用ソース・メッセージの使用方法

- 21.2.6 マルチパートのターゲット・メッセージの使用方法

22 Oracle Mediatorエラー処理の使用

- 22.1 メディエータのエラー処理の概要

- 22.1.1 フォルト・ポリシー

- 22.1.1.1 条件

- 22.1.1.2 アクション

- 22.1.1.2.1 再試行アクション

- 22.1.1.2.2 再スロー・アクション

- 22.1.1.2.3 管理者操作アクション

- 22.1.1.2.4 中断アクション

- 22.1.1.2.5 Javaコード・アクション

- 22.1.2 フォルト・バインディング

- 22.1.3 メディエータのエラー・グループ

- 22.2 メディエータによるエラー処理の使用

- 22.2.1 メディエータ・サービス・コンポーネントに対するエラー処理の使用方法

- 22.2.2 実行時の処理内容

- 22.3 Oracle Enterprise Manager Fusion Middleware Controlコンソールを使用したフォルト・リカバリ

- 22.4 XMLスキーマ定義ファイルのエラー処理

- 22.4.1 fault-policies.xmlのスキーマ定義ファイル

- 22.4.2 fault-bindings.xmlのスキーマ定義ファイル

23 Oracle Mediatorにおける再順序付け

- 23.1 再シーケンサの概要

- 23.1.1 グループおよび順序ID

- 23.1.2 グループIDと順序IDの識別

- 23.2 再順序付けの順序

- 23.2.1 標準再シーケンサ

- 23.2.1.1 標準再シーケンサの概要

- 23.2.1.2 標準の再順序付けに必要な情報

- 23.2.1.3 標準再シーケンサの例

- 23.2.2 FIFO再シーケンサ

- 23.2.2.1 FIFO再シーケンサの概要

- 23.2.2.2 FIFO再順序付けに必要な情報

- 23.2.2.3 FIFO再シーケンサの例

- 23.2.3 ベスト・エフォート再シーケンサ

- 23.2.3.1 ベスト・エフォート再シーケンサの概要

- 23.2.3.2 ベスト・エフォート再シーケンサ・メッセージ選択戦略

- 23.2.3.2.1 最大行数選択

- 23.2.3.2.2 時間ウィンドウ

- 23.2.3.3 ベスト・エフォート再シーケンサ・メッセージ配信

- 23.2.3.4 ベスト・エフォート再順序付けに必要な情報

- 23.2.3.5 最大行数に基づいたベスト・エフォート再順序付けの例

- 23.2.3.6 時間ウィンドウに基づいたベスト・エフォート再順序付けの例

- 23.3 再シーケンサの構成

- 23.3.1 再順序付けレベルの指定方法

- 23.3.2 再順序付け戦略の構成方法

- 23.3.2.1 標準再シーケンサを構成する手順は、次のとおりです。

- 23.3.2.2 FIFO再シーケンサを構成する手順は、次のとおりです。

- 23.3.2.3 ベスト・エフォート再シーケンサを構成する手順は、次のとおりです。

24 Oracle Mediatorのメッセージ交換パターンの理解

- 24.1 一方向メッセージ交換パターン

- 24.1.1 one.way.returns.faultプロパティ

- 24.1.1.1 one.way.returns.faultプロパティを追加する手順は、次のとおりです。

- 24.2 リクエスト・リプライ・メッセージ交換パターン

- 24.3 リクエスト・リプライ・フォルト・メッセージ交換パターン

- 24.4 リクエスト・コールバック・メッセージ交換パターン

- 24.5 リクエスト・リプライ・コールバック・メッセージ交換パターン

- 24.6 リクエスト・リプライ・フォルト・コールバック・メッセージ交換パターン

第IV部 ビジネス・ルール・サービス・コンポーネントの使用

25 Oracle Business Rulesのスタート・ガイド

- 25.1 ビジネス・ルール・サービス・コンポーネントの概要

- 25.1.1 BPELプロセス、ビジネス・ルールおよびヒューマン・タスクの統合

- 25.2 ルール・デザイナ・エディタ環境の概要

- 25.2.1 「アプリケーション」ウィンドウ

- 25.2.2 ルール・デザイナ・ウィンドウ

- 25.2.3 「構造」ウィンドウ

- 25.2.4 「ビジネス・ルール検証 - ログ」ウィンドウ

- 25.3 ビジネス・ルールの作成および編集の概要

- 25.3.1 ビジネス・ルール・コンポーネントの作成方法

- 25.3.2 ルール・デザイナでのビジネス・ルールの使用

- 25.4 BPELプロセスへのビジネス・ルールの追加

- 25.4.1 ビジネス・ルールの入力の追加方法

- 25.4.2 ビジネス・ルールの出力の追加方法

- 25.4.3 オプションを設定してデシジョン・サービスとビジネス・ルール・ディクショナリを作成する方法

- 25.4.4 BPELプロセスへのビジネス・ルール追加時の処理内容

- 25.4.5 ビジネス・ルール・ディクショナリ作成時の処理内容

- 25.4.6 BPELプロセスでのビジネス・ルールの起動に関する必知事項

- 25.4.7 デシジョン・コンポーネントのステートフル操作に関する必知事項

- 25.5 SOAコンポジット・アプリケーションへのビジネス・ルールの追加

- 25.5.1 SOAコンポジット・アプリケーションへのビジネス・ルールの追加方法

- 25.5.1.1 ビジネス・ルールに入力を追加する方法

- 25.5.1.2 ビジネス・ルールに出力を追加する方法

- 25.5.1.3 オプションを設定してデシジョン・サービスとビジネス・ルール・ディクショナリを作成する方法

- 25.5.2 ビジネス・ルール・コンポーネントでのデシジョン関数の選択および変更方法

- 25.6 コンポジット・アプリケーションでのビジネス・ルールの実行

- 25.6.1 スタンドアロン・デシジョン・サービス・コンポーネントのテストに関する必知事項

- 25.7 ビジネス・ルールとOracle ADF Business Componentsファクト・タイプの使用

26 宣言コンポーネントおよびタスク・フローの使用

- 26.1 宣言コンポーネントおよびタスク・フローの概要

- 26.2 Oracle Business Rulesエディタの宣言コンポーネントの概要

- 26.2.1 Oracle Business Rulesエディタ・コンポーネントの使用

- 26.2.2 ルール・エディタ・コンポーネントを使用したサンプル・アプリケーションの作成および実行方法

- 26.2.2.1 RuleSetModelオブジェクトの作成方法

- 26.2.2.2 .jspxファイルの作成方法

- 26.2.2.3 Oracle Rules共有ライブラリを参照する方法

- 26.2.2.4 サンプル・アプリケーションの実行方法

- 26.2.3 スタンドアロンWLSへのルール・エディタ・アプリケーションのデプロイ方法

- 26.2.4 ルール・エディタ・コンポーネントのカスタム権限に関する必知事項

- 26.2.5 ルール・エディタ・コンポーネントのサポートされているタグに関する必知事項

- 26.3 Oracle Business Rulesディクショナリ・エディタの宣言コンポーネントの概要

- 26.3.1 Oracle Business Rulesディクショナリ・コンポーネントの使用

- 26.3.2 ルール・ディクショナリ・エディタ・コンポーネントを使用したサンプル・アプリケーションの作成および実行方法

- 26.3.2.1 RuleDictionaryModelオブジェクトの作成方法

- 26.3.2.2 ルール・ディクショナリ・エディタ・コンポーネントの.jspxファイルの作成方法

- 26.3.2.3 oracle.rulesおよびoracle.soa.rules_dict_dc.webapp共有ライブラリを参照する方法

- 26.3.2.4 ルール・ディクショナリ・エディタ・サンプル・アプリケーションの実行方法

- 26.3.3 スタンドアロンOracle WebLogic Serverへのルール・ディクショナリ・アプリケーションのデプロイ方法

- 26.3.4 ルール・ディクショナリ・エディタ・コンポーネントのサポートされている属性に関する必知事項

- 26.4 Oracle Business Rulesディクショナリ・エディタのタスク・フローの概要

- 26.4.1 Oracle Business Rulesディクショナリ・タスク・フローの使用

- 26.4.2 ルール・ディクショナリ・エディタのタスク・フローを使用したサンプル・アプリケーションの作成および実行方法

- 26.4.2.1 ルール・ディクショナリ・エディタのタスク・フローを追加する方法

- 26.4.2.2 pagedef.xmlファイルの編集方法

- 26.4.2.3 oracle.rulesおよびoracle.soa.rules_dict_dc.webapp共有ライブラリを参照する方法

- 26.4.2.4 タスク・フロー・サンプル・アプリケーションを実行する方法

- 26.4.3 スタンドアロンOracle WebLogic Serverへのルール・ディクショナリ・エディタのタスク・フロー・アプリケーションのデプロイ方法

- 26.5 ADFベースのWebアプリケーションのローカライズ

- 26.6 翻訳の使用

- 26.6.1 再利用可能なルールUI ADFタスク・フロー・コンポーネントのコンシューマに対する翻訳の有効化

- 26.6.1.1 IRelatedMetadataDetailsの実装を渡すサンプル・コード

- 26.6.2 ルールWeb UIアプリケーションのコンシューマに対する翻訳の有効化

- 26.6.2.1 resourceManagerのインスタンスを作成するためのサンプル・コード

第V部 ヒューマン・ワークフロー・サービス・コンポーネントの使用

27 ヒューマン・ワークフローのスタート・ガイド

- 27.1 ヒューマン・ワークフローの概要

- 27.2 ヒューマン・ワークフローの概要

- 27.2.1 設計時および実行時の概念の概要

- 27.2.1.1 タスクの割当ておよびルーティング

- 27.2.1.1.1 参加者

- 27.2.1.1.2 参加者タイプ

- 27.2.1.1.3 参加者の割当て

- 27.2.1.1.4 非定型ルーティング

- 27.2.1.1.5 ルーティング・フローの結果ベースの完了

- 27.2.1.2 静的、動的およびルールベースのタスク割当て

- 27.2.1.2.1 静的タスク割当て

- 27.2.1.2.2 動的タスク割当て

- 27.2.1.2.3 ビジネス・ルールを使用したタスク割当て

- 27.2.1.3 タスクのステークホルダ

- 27.2.1.4 タスク期限

- 27.2.1.5 通知

- 27.2.1.6 タスク・フォーム

- 27.2.1.7 拡張概念

- 27.2.1.8 レポートおよび監査証跡

- 27.2.2 ヒューマン・ワークフローの設計ステージの概要

- 27.3 ヒューマン・ワークフローのユースケースの概要

- 27.3.1 ユーザーまたはロールへのタスクの割当て

- 27.3.2 様々な参加者タイプの使用

- 27.3.3 エスカレーション、有効期限および委任

- 27.3.4 自動割当ておよび委任

- 27.3.5 タスク・コンテンツに基づいたユーザーの動的割当て

- 27.4 ヒューマン・ワークフロー・アーキテクチャの概要

- 27.4.1 ヒューマン・ワークフロー・サービス

- 27.4.2 ヒューマン・タスクの使用

- 27.4.3 サービス・エンジン

- 27.5 Oracle SOA SuiteとOracle BPM Suiteの間のヒューマン・ワークフローとビジネス・ルールの相違

28 ヒューマン・タスクの作成

- 28.1 ヒューマン・タスクの概要

- 28.1.1 ヒューマン・タスク定義の作成の概要

- 28.1.2 ヒューマン・タスク定義とBPELプロセスの関連付けの概要

- 28.1.3 タスク・フォームの生成の概要

- 28.2 ヒューマン・タスクの作成

- 28.2.1 SOAコンポジット・エディタを使用してヒューマン・タスクを作成する方法

- 28.2.2 Oracle BPELデザイナを使用してヒューマン・タスクを作成する方法

- 28.2.3 ヒューマン・タスク作成時の処理内容

- 28.3 ヒューマン・タスクの構成

- 28.4 ヒューマン・タスク・エディタの終了と変更の保存

- 28.5 ヒューマン・タスクとBPELプロセスの関連付け

- 28.5.1 ヒューマン・タスクをBPELプロセスに関連付ける方法

- 28.5.2 ヒューマン・タスクとBPELプロセス間のワイヤの削除に関する必知事項

- 28.5.3 ヒューマン・タスク・アクティビティのタイトル、イニシエータ、優先度およびパラメータ変数の定義方法

- 28.5.3.1 タスクのタイトルの指定

- 28.5.3.2 タスク・イニシエータとタスク優先度の指定

- 28.5.3.3 タスク・パラメータの指定

- 28.5.4 ヒューマン・タスク・アクティビティの拡張機能の定義方法

- 28.5.4.1 スコープ名とグローバル・タスク変数名の指定

- 28.5.4.2 タスク所有者の指定

- 28.5.4.3 識別キーの指定

- 28.5.4.4 アイデンティティ・コンテキストの指定

- 28.5.4.5 アプリケーション・コンテキストの指定

- 28.5.4.6 他のヒューマン・タスクのタスク履歴の追加

- 28.5.5 生成されたヒューマン・タスク・アクティビティの表示方法

- 28.5.5.1 BPELコールバックの起動

- 28.5.6 生成されたヒューマン・タスク・アクティビティの変更に関する必知事項

- 28.5.7 ヒューマン・タスクで生成されたパートナ・リンクの削除に関する必知事項

- 28.5.8 結果ベース・モデリングの定義方法

- 28.5.8.1 ペイロード更新の指定

- 28.5.8.2 その他のタスクの結果に対応するcase文の使用

- 28.5.9 添付ファイルのエンコーディングに関する必知事項

29 ヒューマン・タスクの構成

- 29.1 ヒューマン・タスク・エディタのセクションへのアクセス

- 29.2 タイトル、説明、結果、優先度、カテゴリ、所有者およびアプリケーション・コンテキストの指定

- 29.2.1 タスクのタイトルの指定方法

- 29.2.2 タスクの説明の指定方法

- 29.2.3 タスクの結果の指定方法

- 29.2.4 タスク優先度の指定方法

- 29.2.5 タスク・カテゴリの指定方法

- 29.2.6 タスク所有者の指定方法

- 29.2.6.1 ユーザー・ディレクトリまたはアプリケーション・ロールのリストを介したタスク所有者の静的な指定

- 29.2.6.2 XPath式によるタスク所有者の動的な指定

- 29.2.7 アプリケーション・コンテキストの指定方法

- 29.3 タスク・ペイロードのデータ構造の指定

- 29.3.1 タスク・ペイロード・データ構造の指定方法

- 29.4 タスク参加者の割当て

- 29.4.1 ステージ名を指定してパラレルおよび順次ブロックを追加する方法

- 29.4.2 タスク参加者の割当て方法

- 29.4.3 単一参加者タイプの構成方法

- 29.4.3.1 単一タスク参加者リストの作成

- 29.4.3.1.1 値ベースの名前と式で構成される参加者リストの作成

- 29.4.3.1.2 値ベースの管理チェーンで構成される参加者リストの作成

- 29.4.3.1.3 ルールセットで構成される参加者リストの作成

- 29.4.3.2 タスクの操作に対する時間制限の指定

- 29.4.3.3 タスクへの他の参加者の招待

- 29.4.3.4 タスク参加者のバイパス

- 29.4.4 パラレル参加者タイプの構成方法

- 29.4.4.1 投票結果の指定

- 29.4.4.2 パラレル・タスク参加者リストの作成

- 29.4.4.3 タスクの操作に対する時間制限の指定

- 29.4.4.4 タスクへの他の参加者の招待

- 29.4.4.5 タスク参加者のバイパス

- 29.4.5 シリアル参加者タイプの構成方法

- 29.4.5.1 シリアル・タスク参加者リストの作成

- 29.4.5.2 タスクの操作に対する時間制限の指定

- 29.4.5.3 タスクへの他の参加者の招待

- 29.4.5.4 タスク参加者のバイパス

- 29.4.6 FYI参加者タイプの構成方法

- 29.4.6.1 FYIタスク参加者リストの作成

- 29.5 ルーティング・ポリシーの選択

- 29.5.1 指定した順序でタスクを全参加者にルーティングする方法

- 29.5.1.1 全参加者による他の参加者の招待または新しい参加者の編集の許可

- 29.5.1.2 起案者による参加者の追加の許可

- 29.5.1.3 他の参加者へのタスクのルーティングの停止

- 29.5.1.4 パラレル・サブタスクでの早期完了の有効化

- 29.5.1.5 早期完了するサブタスクの親サブタスクの完了

- 29.5.2 ビジネス・ルールを使用した詳細タスク・ルーティングの指定方法

- 29.5.2.1 ビジネス・ルールを使用した詳細タスク・ルーティングの概要

- 29.5.2.2 ファクト

- 29.5.2.3 アクション・タイプ

- 29.5.2.4 サンプル・ルールセット

- 29.5.2.5 リンク・ディクショナリのサポート

- 29.5.2.6 拡張ルーティング・ルールの作成

- 29.5.3 外部ルーティングの使用方法

- 29.5.4 エラー割当て先とレビューアの構成方法

- 29.5.4.1 サーバー設定の変更方法

- 29.6 多言語設定とスタイルシートの指定

- 29.6.1 添付ファイルとしてのWordMLスタイルシートとその他のスタイルシートの指定方法

- 29.6.2 多言語設定の指定方法

- 29.7 ワークリストでの「タスクの詳細」に表示するものの指定

- 29.8 タスクのエスカレート、期限更新または終了

- 29.8.1 エスカレーションおよび有効期限ポリシーの概要

- 29.8.2 期限切れがないポリシーの指定方法

- 29.8.3 期限切れがあるポリシーの指定方法

- 29.8.4 有効期限ポリシー期間の延長方法

- 29.8.5 タスク・ポリシーのエスカレート方法

- 29.8.6 エスカレーション・ルールの指定方法

- 29.8.7 期日の指定方法

- 29.9 参加者通知プリファレンスの指定

- 29.9.1 受信者へのタスク・ステータス変更の通知方法

- 29.9.2 通知メッセージの編集方法

- 29.9.3 リマインダの設定方法

- 29.9.4 文字セットのエンコーディングの変更方法

- 29.9.5 詳細を除く通知をセキュア化する方法

- 29.9.6 通知でのOracle BPM Worklist URLの表示方法

- 29.9.7 電子メール・メッセージをアクション可能にする方法

- 29.9.8 電子メール通知によるタスクの添付ファイルの送信方法

- 29.9.9 グループおよびアプリケーション・ロールへの電子メール通知の送信方法

- 29.9.10 通知ヘッダーのカスタマイズ方法

- 29.10 タスク・コンテンツへのアクセス・ポリシーとタスク・アクションの指定

- 29.10.1 アクセス・ルールの概要

- 29.10.2 タスク・コンテンツの操作に対するユーザー権限の指定

- 29.10.3 タスクの操作に対するアクションの指定

- 29.10.4 ワークフロー・デジタル署名ポリシーの指定方法

- 29.10.4.1 認証局の指定

- 29.11 タスク割当てに対する制限の指定

- 29.11.1 タスク割当てに対する制限の指定方法

- 29.12 Javaコールバックまたはビジネス・イベント・コールバックの指定

- 29.12.1 Javaコールバックの指定

- 29.12.2 ビジネス・イベント・コールバックの指定

- 29.12.3 BPELコールバックのタスクとルーティング・カスタマイズの指定方法

- 29.12.4 BPELコールバックを無効にする方法

30 ヒューマン・タスク用のタスク・フォームの設計

- 30.1 タスク・フォームの概要

- 30.1.1 タスク・フォームに関する必知事項: タイムゾーン変換

- 30.2 タスク・フローとタスク・サービスの関連付け

- 30.3 ヒューマン・タスクに基づいたADFタスク・フローの作成

- 30.3.1 ヒューマン・タスク・エディタからADFタスク・フローを作成する方法

- 30.3.2 ヒューマン・タスクに基づいたADFタスク・フローの作成方法

- 30.3.3 ヒューマン・タスクに基づいたADFタスク・フロー作成時の処理内容

- 30.3.4 異なるメタ属性が指定された同じ要素を含む複数のADFタスク・フローに関する必知事項

- 30.4 タスク・フォームの作成

- 30.4.1 自動生成タスク・フォームの作成方法

- 30.4.2 カスタム・ページ・テンプレートにライブラリJARファイルを登録する方法

- 30.4.3 カスタム・タスク・フォーム・ウィザードを使用したタスク・フォームの作成方法

- 30.4.4 「ペイロードを持つ完了済タスク」ドロップ・ハンドラを使用したタスク・フォームの作成方法

- 30.4.4.1 ペイロードを持つ完了済タスク

- 30.4.4.2 ペイロードのない完了済タスク

- 30.4.4.3 電子メールのタスク詳細

- 30.4.4.4 タスク・ヘッダー

- 30.4.4.5 タスク・アクション

- 30.4.4.6 タスク履歴

- 30.4.4.7 タスクのコメントと添付ファイル

- 30.4.5 個別のドロップ・ハンドラを使用したタスク・フォーム・リージョンの作成方法

- 30.4.6 タスク・フォームへのペイロードの追加方法

- 30.4.7 タスク・フォーム作成時の処理内容

- 30.5 タスクXSD変更時のデータ・コントロールのリフレッシュ

- 30.6 タスク・フロー・アプリケーションの保護

- 30.7 電子メール通知の作成

- 30.7.1 電子メール通知の作成方法

- 30.7.1.1 ルーターを使用したタスク・フローの作成

- 30.7.1.2 電子メール通知ページの作成

- 30.7.2 電子メール通知ページ作成時の処理内容

- 30.8 タスク・フローを使用したコンポジット・アプリケーションのデプロイ

- 30.8.1 タスク・フローを使用したコンポジット・アプリケーションのデプロイ方法

- 30.8.2 タスク・フォームの再デプロイ方法

- 30.8.3 タスク・フローを別のアプリケーションとしてデプロイする方法

- 30.8.4 非SOAのOracle WebLogic Serverにタスク・フォームをデプロイする方法

- 30.8.4.1 タスク・フォームをデプロイする前に: ポートの変更

- 30.8.4.2 セッション・トラッキングCookieの一意のCookieコンテキスト・パスの構成

- 30.8.4.3 非SOAのOracle WebLogic Serverへのoracle.soa.workflow.jarのデプロイ

- 30.8.4.4 非SOAのOracle WebLogic Serverでの外部JNDIプロバイダの定義

- 30.8.4.5 非SOAのOracle WebLogic Serverでの外部JNDIプロバイダ・リンクの定義

- 30.8.4.6 bpm-services.jarに対する権限付与を含める方法

- 30.8.4.7 アプリケーションのデプロイ

- 30.8.5 タスク・フォームのデプロイ時の処理内容

- 30.8.6 タスク・フローのアンデプロイに関する必知事項

- 30.9 ワークリストでのタスク・フォームの表示

- 30.10 電子メール通知でのタスクの表示

- 30.10.1 タスク通知におけるワークリスト・アプリケーションのテキストの変更

- 30.10.2 タスク通知におけるワークリスト・アプリケーションのURLの変更

- 30.11 複数のヒューマン・タスクを含むタスク・フロー・アプリケーションの再利用

- 30.11.1 複数のヒューマン・タスクを含むタスク・フロー・アプリケーションの再利用方法

- 30.11.2 様々なアクションを含むタスク・フロー・アプリケーションの再利用方法

31 ヒューマン・ワークフローのチュートリアル

- 31.1 ヒューマン・ワークフローのチュートリアルの概要

- 31.2 前提条件

- 31.3 BPELプロセスを使用したアプリケーションおよびプロジェクトの作成

- 31.4 ヒューマン・タスク・サービス・コンポーネントの作成

- 31.5 ヒューマン・タスクの設計

- 31.6 ヒューマン・タスクとBPELプロセス・サービス・コンポーネントの関連付け

- 31.7 タスク・フォームのプロジェクトの作成

- 31.8 タスク・フォームのデプロイ

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

- 31.10 SOAコンポジット・アプリケーションのデプロイ

- 31.11 プロセス・インスタンスの開始

- 31.12 Oracle BPM Worklistでのタスクの操作

- 31.13 その他のチュートリアル

32 Oracle BPM Worklistの使用

- 32.1 Oracle BPM Worklistの概要

- 32.2 Oracle BPM Worklistへのログイン

- 32.2.1 ワークリストへのログイン方法

- 32.2.1.1 ワークリストにログインするためにweblogicユーザーを有効にする方法

- 32.2.2 ワークリストへのログイン時の処理内容

- 32.2.3 ユーザーがOracle BPM Worklistにログイン中にユーザーの権限を変更した場合の処理内容

- 32.3 タスク・リスト・ページのカスタマイズ

- 32.3.1 タスクのフィルタ方法

- 32.3.1.1 割当て先または状態に基づいてタスクをフィルタ処理する手順

- 32.3.1.2 キーワード検索に基づいてタスクをフィルタ処理する手順

- 32.3.1.3 拡張検索に基づいてタスクをフィルタ処理する手順

- 32.3.2 ワークリスト・ビューを作成、削除およびカスタマイズする方法

- 32.3.2.1 ワークリスト・ビューをカスタマイズする手順

- 32.3.3 タスク・ステータス・グラフのカスタマイズ方法

- 32.3.4 To Doタスクの作成方法

- 32.3.5 ワークリスト・アプリケーションでのサブタスクの作成方法

- 32.3.5.1 サブタスクの作成に関する項必知事項

- 32.4 Microsoft Excelへのタスクのエクスポート

- 32.4.1 Excelへのタスクのエクスポート方法

- 32.5 タスク操作: 「タスクの詳細」ページ

- 32.5.1 システム・アクション

- 32.5.2 タスク履歴

- 32.5.3 タスクの操作方法

- 32.5.3.1 情報をリクエストする手順

- 32.5.3.2 タスクをルーティングする手順

- 32.5.3.3 コメントまたは添付ファイルを追加する手順

- 32.5.4 デジタル署名が必要なタスクの操作方法

- 32.6 タスクの承認

- 32.7 休暇期間の設定

- 32.8 ルールの設定

- 32.8.1 ユーザー・ルールの作成方法

- 32.8.2 グループ・ルールの作成方法

- 32.8.3 複数の割当て先があるタスクの割当てルール

- 32.8.4 再割当てされた休暇ルールでの循環ロジックの回避方法

- 32.9 ワークリスト管理機能の使用

- 32.9.1 管理者が他のユーザーまたはグループのルールを管理する方法

- 32.9.2 ログイン・ページ・レルムのラベルの指定方法

- 32.9.3 リソース・バンドルの指定方法

- 32.9.4 言語のロケール情報の指定方法

- 32.9.5 ユーザー名の形式の指定方法

- 32.9.6 ブランド・ロゴの指定方法

- 32.9.7 ブランド・タイトルの指定方法

- 32.9.8 スキンの選択方法

- 32.9.8.1 スキンを選択する手順

- 32.9.8.2 カスタマイズされたスキンを含むJARファイルを作成する手順

- 32.9.9 カスタマイズされたアプリケーションおよびリンクを有効にする方法

- 32.9.10 タスク・アクションのイメージの指定方法

- 32.10 通知設定の指定

- 32.10.1 メッセージング・フィルタ・ルール

- 32.10.1.1 データ型

- 32.10.1.2 属性

- 32.10.2 ルール・アクション

- 32.10.3 メッセージング・チャネルの管理

- 32.10.3.1 メッセージング・チャネルの表示

- 32.10.3.2 メッセージング・チャネルの作成、編集および削除

- 32.10.4 メッセージング・フィルタの管理

- 32.10.4.1 メッセージング・フィルタの表示

- 32.10.4.2 メッセージング・フィルタの作成

- 32.10.4.3 メッセージング・フィルタの編集

- 32.10.4.4 メッセージング・フィルタの削除

- 32.11 マップ済属性(フレックス・フィールド)の使用

- 32.11.1 属性のマップ方法

- 32.11.1.1 ラベルを作成する手順

- 32.11.1.2 すべてのマッピングを参照する手順

- 32.11.1.3 マッピングをタスク・タイプ別に編集する手順

- 32.11.2 カスタムのマップ済属性

- 32.12 ワークリスト・レポートの作成

- 32.12.1 レポートの作成方法

- 32.12.2 レポート作成時の処理内容

- 32.12.2.1 不参加タスク・レポート

- 32.12.2.2 タスクの優先度レポート

- 32.12.2.3 タスクのサイクル・タイム・レポート

- 32.12.2.4 タスクの生産性レポート

- 32.13 Oracle BPM Worklistへのローカル言語およびタイムゾーンによるアクセス

- 32.13.1 Oracle BPM Worklist内の文字列

- 32.13.2 アイデンティティ・ストアがLDAPベースである場合の優先言語、ユーザーの表示名およびタイムゾーン設定の変更方法

- 32.13.3 タスク表示に使用する言語の変更方法

- 32.13.4 JAZN XMLファイルからの言語設定の変更方法

- 32.13.5 ワークリストでの表示言語の設定に関する必知事項

- 32.13.6 ワークリストで使用するタイムゾーンの変更方法

- 32.14 再利用可能なワークリスト・リージョンの作成

- 32.14.1 埋込みの再利用可能なワークリスト・リージョンを使用したアプリケーションの作成方法

- 32.14.2 デプロイメント・プロファイルの設定方法

- 32.14.3 フェデレーテッド・モードのタスク・フローのデプロイメント準備

- 32.14.4 タスク・リスト・タスク・フローに関する必知事項

- 32.14.5 証明書タスク・フローに関する必知事項

- 32.14.6 レポート・タスク・フローに関する必知事項

- 32.14.7 アプリケーション・プリファレンス・タスク・フローに関する必知事項

- 32.14.8 マップ済属性タスク・フローに関する必知事項

- 32.14.9 ルール・タスク・フローに関する必知事項

- 32.14.10 承認グループ・タスク・フローに関する必知事項

- 32.14.11 タスク構成タスク・フローに関する必知事項

- 32.15 ワークリスト・アプリケーションでカスタマイズされたアプリケーションを有効化するJavaコード

33 カスタム・ワークリスト・クライアントの作成

- 33.1 ワークフロー・サービスのクライアント作成に関する概要

- 33.2 クライアント作成に使用するパッケージとクラス

- 33.3 ワークフロー・サービス・クライアント

- 33.3.1 IWorkflowServiceClientインタフェース

- 33.4 SOAPを使用するクライアント用のクラスパス

- 33.5 リモートEJBを使用するクライアント用のクラスパス

- 33.6 タスクの開始

- 33.6.1 タスクの作成

- 33.6.2 タスクのペイロード要素の作成

- 33.6.3 プログラムによるタスクの開始

- 33.7 ワークフロー標準ビュー定義の変更

- 33.8 HelpDeskUIサンプルを使用したワークリスト・アプリケーションの記述

34 ヒューマン・ワークフロー・サービスの概要

- 34.1 ヒューマン・ワークフロー・サービスの概要

- 34.1.1 ヒューマン・ワークフロー・サービスに対するSOAP、Enterprise JavaBeansおよびJavaサポート

- 34.1.1.1 外部JNDI名のサポート

- 34.1.2 サービスに対するセキュリティ・モデル

- 34.1.2.1 SOAP Webサービス使用時のワークフロー・サービスへのアイデンティティ伝播の制限

- 34.1.2.2 ユーザーにかわるヒューマン・ワークフロー・コンテキストの作成

- 34.1.2.3 JAASアプリケーションによって以前に認証されたユーザーのワークフロー・コンテキストの取得

- 34.1.3 タスク・サービス

- 34.1.4 タスク問合せサービス

- 34.1.5 アイデンティティ・サービス

- 34.1.5.1 アイデンティティ・サービス・プロバイダ

- 34.1.5.1.1 カスタム・ユーザー・リポジトリ・プラグイン

- 34.1.6 タスク・メタデータ・サービス

- 34.1.7 ユーザー・メタデータ・サービス

- 34.1.8 タスク・レポート・サービス

- 34.1.9 ランタイム構成サービス

- 34.1.9.1 属性ラベルの国際化

- 34.1.10 エビデンス・ストア・サービスとデジタル署名

- 34.1.10.1 前提条件

- 34.1.10.2 インタフェースとメソッド

- 34.1.11 タスク・インスタンス属性

- 34.2 ヒューマン・ワークフローからの通知

- 34.2.1 通知のコンテンツ

- 34.2.2 エラー・メッセージのサポート

- 34.2.3 信頼性のサポート

- 34.2.4 Oracle Human Workflow通知サービスの管理

- 34.2.5 通知チャネル・プリファレンスの構成方法

- 34.2.6 異なる言語による通知メッセージの構成方法

- 34.2.7 アクション可能なメッセージの送信方法

- 34.2.7.1 ヒューマン・タスクのアクション可能な電子メールの送信方法

- 34.2.8 インバウンドおよびアウトバウンド添付ファイルの送信方法

- 34.2.9 インバウンド・コメントの送信方法

- 34.2.10 セキュアな通知の送信方法

- 34.2.11 通知に使用されるチャネルの設定方法

- 34.2.12 リマインダの送信方法

- 34.2.13 未処理メッセージに対する自動返信の設定方法

- 34.2.14 カスタム通知ヘッダーの作成方法

- 34.3 割当てサービスの構成

- 34.3.1 動的割当てパターンおよびタスク・エスカレーション・パターン

- 34.3.1.1 動的割当てパターンの実装方法

- 34.3.1.2 動的割当てパターンの構成方法

- 34.3.1.3 動的割当てパターンの表示名の構成方法

- 34.3.1.4 タスク・エスカレーション・パターンの実装方法

- 34.3.2 割当てサービスによるタスク参加者の動的割当て

- 34.3.2.1 割当てサービスの実装方法

- 34.3.2.2 割当てサービスの実装例

- 34.3.2.3 カスタム割当てサービスのデプロイ方法

- 34.3.3 カスタム・エスカレーション関数

- 34.4 コールバックとリソース・バンドルに対するクラスのロード

- 34.5 ワークフロー・サービスのリソース・バンドル

- 34.5.1 タスク・リソース・バンドル

- 34.5.2 グローバル・リソース・バンドル - WorkflowLabels.properties

- 34.5.3 ワークリスト・クライアントのリソース・バンドル

- 34.5.4 タスク詳細のADFタスク・フロー・リソース・バンドル

- 34.5.5 リソース・バンドルでのステージ名と参加者名の指定

- 34.5.6 グループ名とアプリケーション・ロール名での大/小文字の区別

- 34.6 ヒューマン・ワークフロー・クライアントとOracle WebLogic Serverサービスとの統合の概要

- 34.6.1 ヒューマン・ワークフロー・サービス・クライアント

- 34.6.1.1 タスク問合せサービス・クライアントのコード

- 34.6.1.2 構成オプション

- 34.6.1.2.1 JAXBオブジェクト

- 34.6.1.2.2 ワークフロー・クライアント構成ファイル - wf_client_config.xml

- 34.6.1.2.3 プロパティ・マップでのワークフロー・クライアント構成

- 34.6.1.3 クライアントのロギング

- 34.6.1.4 構成移行ユーティリティ

- 34.6.2 アイデンティティ伝播

- 34.6.2.1 Enterprise JavaBeansアイデンティティ伝播

- 34.6.2.1.1 クライアント構成

- 34.6.2.1.2 アイデンティティ伝播のためのクライアント・アプリケーションの要件

- 34.6.2.2 SOAPクライアント用のSAMLトークン・アイデンティティ伝播

- 34.6.2.2.1 クライアント構成

- 34.6.2.3 公開鍵の別名

- 34.6.3 クライアントJARファイル

- 34.7 ヒューマン・タスクのタスクの状態

- 34.8 Oracle Workflowのデータベース・ビュー

- 34.8.1 「不参加タスク・レポート」ビュー

- 34.8.2 「タスクのサイクル・タイム・レポート」ビュー

- 34.8.3 「タスクの生産性レポート」ビュー

- 34.8.4 「タスクの優先度レポート」ビュー

第VI部 バインディング・コンポーネントの使用

35 バインディング・コンポーネントの開始

- 35.1 バインディング・コンポーネントの概要

- 35.1.1 SOAP Webサービス

- 35.1.1.1 WS-AtomicTransactionサポート

- 35.1.1.1.1 WS-ATでのBPELプロセスの参加確認

- 35.1.1.1.2 最適化が有効な場合にWS-ATトランザクションがサポートされない

- 35.1.2 HTTPバインディング・サービス

- 35.1.2.1 サポートされている相互作用

- 35.1.2.2 HTTPバインディング・サービスの構成方法

- 35.1.2.3 HTTPバインディングに対して基本認証を有効にする方法

- 35.1.3 JCAアダプタ

- 35.1.3.1 データベース・アダプタ

- 35.1.3.2 ファイル・アダプタ

- 35.1.3.3 FTPアダプタ

- 35.1.3.4 AQアダプタ

- 35.1.3.5 JMSアダプタ

- 35.1.3.6 MQアダプタ

- 35.1.3.7 ソケット・アダプタ

- 35.1.3.8 サードパーティ・アダプタ

- 35.1.3.9Oracle User Messaging Serviceアダプタ

- 35.1.3.10 LDAPアダプタ

- 35.1.3.11 コヒーレンス・アダプタ

- 35.1.4 Oracle E-Business Suiteアダプタ

- 35.1.5 Oracle BAM 11gアダプタ

- 35.1.6 Oracle B2B

- 35.1.7 Oracle Healthcare Adapter

- 35.1.8 Oracle MFT

- 35.1.9 ADF-BCサービス

- 35.1.10 EJBアダプタ

- 35.1.11 直接バインディング・アダプタ

- 35.1.12 RESTバインディング

- 35.1.13 クラウド・アダプタ

- 35.2 バインディング・コンポーネントとSOAコンポジット・アプリケーションの統合の概要

- 35.2.1 バインディング・コンポーネントとSOAコンポジット・アプリケーションの統合方法

- 35.2.2 ADFバインディングを使用してJSP/Javaクラスからコンポジット・アプリケーションを起動する方法

- 35.3 外部参照のバインディングURLで使用するためのトークンの作成

- 35.3.1 外部参照のバインディングURLで使用するためのトークンの作成方法

36 REST操作とSOAコンポジット・アプリケーションとの統合

- 36.1 RESTサポートの概要

- 36.2 サービスおよび参照バインディング・コンポーネントにおけるRESTサポートの作成

- 36.2.1 SOAコンポジット・アプリケーションのRESTバインディング・コンポーネントを構成する方法

- 36.2.1.1 「RESTメソッド定義」ダイアログ

- 36.2.1.2 「REST操作バインディング」ダイアログ

- 36.2.2 例: 既存のRESTサービス・コンポーネントの有効化

- 36.2.3 例: WADLサービスからREST参照へのリソースおよび操作の追加

- 36.2.4 ショートカットからRESTアダプタを構成する方法

- 36.2.4.1 アプリケーション・サーバーにデプロイされたWebサービスに基づいてRESTサービスを生成する手順:

- 36.2.4.2 アプリケーション・サーバーにデプロイされたRESTサービスに基づいてREST参照を生成する手順:

- 36.2.4.3 SOAコンポーネントのWSDLサービスに基づいてRESTサービスを生成する手順:

- 36.2.5 スキーマを手動で生成する方法

- 36.2.6 サンプルからのスキーマの生成方法

- 36.2.7 グローバル・トークン変数の使用方法

- 36.2.8 RESTヘッダーのプロパティの設定方法

- 36.2.8.1 インバウンドおよびアウトバウンド・ヘッダー

- 36.2.8.2 カスタム・ヘッダー・サポート

- 36.2.9 RESTフォルト・バインディングに関する必知事項

- 36.2.10 JSON InterchangeフォーマットからRESTスキーマへの変換に関する必知事項

- 36.2.11 同一ノード内でRESTサービスをコールするREST参照に関する必知事項

- 36.3 BPELコンポーネントでのJavaScriptおよびJSONの使用

- 36.4 HTTPアナライザによるRESTアダプタのテスト

- 36.5 Oracle Enterprise Manager Fusion Middleware ControlでのREST参照のバインディング・コンポーネントのテストおよび構成

37 Enterprise JavaBeansとコンポジット・アプリケーションの統合

- 37.1 Enterprise JavaBeansバインディングとSOAコンポジット・アプリケーションの統合の概要

- 37.1.1 Javaインタフェースを使用した統合

- 37.1.2 SDOベースのEJBを使用した統合

- 37.2 SDOベースのEnterprise JavaBeansアプリケーションの設計

- 37.2.1 SDOコンパイラを使用したSDOオブジェクトの作成方法

- 37.2.2 セッションBeanを作成してSDOオブジェクトをインポートする方法

- 37.2.3 プロファイルおよびEARファイルの作成方法

- 37.2.4 Enterprise JavaBeans Beanを使用したSDOタイプの定義方法

- 37.2.5 Webサービス注釈の使用方法

- 37.2.6 Enterprise JavaBeans EARファイルのデプロイ方法

- 37.3 Oracle JDeveloperでのEnterprise JavaBeansサービスの作成

- 37.3.1 Javaインタフェース・ベースのEnterprise JavaBeansとSOAコンポジット・アプリケーションの統合方法

- 37.3.2 SDOベースのEnterprise JavaBeansとSOAコンポジット・アプリケーションの統合方法

- 37.4 Oracle SOA Suiteを起動するEnterprise JavaBeansクライアントの設計

- 37.4.1 Oracle SOA Suiteを起動するJavaインタフェース・ベースのクライアントの作成方法

- 37.4.2 SDO-Enterprise JavaBeansサービスの起動方法

- 37.5 Enterprise JavaBeansロールの指定

- 37.6 資格証明ストア・フレームワークでのEnterprise JavaBeansバインディングのサポートの構成

- 37.6.1 資格証明ストア・フレームワークでのEnterprise JavaBeansバインディングのサポートの構成方法

- 37.6.1.1 資格証明ストア・フレームワークでEnterprise JavaBeansバインディングのサポートを構成する手順は、次のとおりです。

- 37.6.1.2 oracle.jps.credstore.mapおよびoracle.jps.credstore.keyプロパティを指定する手順:

- 37.6.1.3 CSFマップ・ストアにSOAインフラストラクチャの実行時アクセスを付与する手順:

38 コンポジット・サービスの起動に直接バインディングを使用

- 38.1 直接バインディングの概要

- 38.1.1 直接サービス・バインディング・コンポーネント

- 38.1.2 直接参照バインディング・コンポーネント

- 38.2 直接バインディング起動APIの概要

- 38.2.1 同期直接バインディング起動

- 38.2.2 非同期直接バインディング起動

- 38.2.3 直接バインディングJavaクライアント・コードをコンパイルおよび実行するために必要なJARファイル

- 38.2.4 SOA直接アドレス構文

- 38.2.5 SOAトランザクション伝播

- 38.3 起動APIを使用したOracle JDeveloperでのSOAコンポジット・アプリケーションの起動

- 38.3.1 インバウンド直接バインディング・サービスの作成方法

- 38.3.2 アウトバウンド直接バインディング参照の作成方法

- 38.3.3 直接バインディングを起動するJ2SEクライアントのアイデンティティの設定方法

- 38.3.4 同一のサーバー名/ドメイン名を持つホスト上でのSOAコンポジットの呼出しに関する必知事項

- 38.4 直接バインディング起動APIの使用例

第VII部 サービス・コンポーネント間の共有機能

39 Oracle SOA Suiteテンプレートおよび再利用可能なサブプロセス

- 39.1 Oracle SOA Suiteテンプレートの概要

- 39.2 スタンドアロンおよびインラインBPELサブプロセスの起動の概要

- 39.2.1 スタンドアロン・サブプロセスの概要

- 39.2.2 インライン・サブプロセスの概要

- 39.3 Oracle SOA Suiteテンプレートと再利用可能なサブプロセスの違い

- 39.4 Oracle SOA Suiteテンプレートの作成

- 39.4.1 SOAプロジェクト・テンプレートの作成および使用

- 39.4.1.1 SOAプロジェクト・テンプレートの作成方法

- 39.4.1.2 別のSOAコンポジットでコンポジット・テンプレートを使用する方法

- 39.4.2 サービス・コンポーネント・テンプレートの作成および使用

- 39.4.2.1 サービス・コンポーネント・テンプレートの作成方法

- 39.4.2.2 別のSOAコンポジットでサービス・コンポーネント・テンプレートを使用する方法

- 39.4.3 BPELスコープ・アクティビティ・テンプレートの作成および使用

- 39.4.3.1 BPELスコープ・アクティビティ・テンプレートの作成方法

- 39.4.3.2 BPELスコープ・アクティビティ・テンプレートを別のBPELプロセスで使用する方法

- 39.4.4 テンプレートの管理

- 39.5 BPELプロセスでのスタンドアロンおよびインラインBPELサブプロセスの作成

- 39.5.1 スタンドアロンBPELサブプロセスの作成方法

- 39.5.2 インライン・サブプロセスの作成方法

- 39.5.3 パートナ・リンクをパラメータとして取得するスタンドアロン・サブプロセスの作成方法

- 39.5.4 サブプロセスの名前変更に関する必知事項

40 XSLTマップ・エディタを使用したトランスフォーメーションの作成

- 40.1 XSLTマップ・エディタの概要

- 40.1.1 マップ・ビューの使用

- 40.1.2 XSLTビューの使用

- 40.1.3 「コンポーネント」ウィンドウの使用

- 40.1.4 「プロパティ」ウィンドウの使用

- 40.2 XSLTマップの作成

- 40.2.1 XSLTマップの作成方法

- 40.2.2 Oracle BPEL Process ManagerでXSLマップ・ファイルを作成する方法

- 40.2.3 Oracle BPEL Process Managerでインポートされたソースとターゲット・スキーマ・ファイルからXSLマップ・ファイルを作成する方法

- 40.2.4 Oracle MediatorでXSLマップ・ファイルを作成する方法

- 40.2.5 XSLマップ・ファイルの作成に関する必知事項

- 40.2.6 XSLマップ・ファイルを作成せずにOracle Mediatorを介してペイロードを渡した場合の実行時の処理内容

- 40.2.7 空のネームスペース・タグがある出力メッセージを受信した場合の処理内容

- 40.3 マップ・ビューでのXSLTマップの編集

- 40.3.1 ノードのリンクによる値のコピーの実行方法

- 40.3.2 出力ドキュメントでの空ノードの作成方法

- 40.3.3 ターゲット・ノードのリテラル・テキスト値の設定方法

- 40.3.4 XSLT文の追加方法

- 40.3.4.1 XSLT文を追加する手順:

- 40.3.4.2 xsl:textまたはxsl:variable文を追加する手順:

- 40.3.4.3 XSLT文をターゲット・ノードにドラッグ・アンド・ドロップする手順:

- 40.3.4.4 xsl:ifを使用した条件付き処理の追加方法

- 40.3.4.4.1 コンテキスト・メニューを使用してxsl:if文を追加する手順は、次のとおりです。

- 40.3.4.4.2 ドラッグ・アンド・ドロップを使用してxsl:if文を追加する手順は、次のとおりです。

- 40.3.4.5 xsl:chooseを使用した条件付き処理の追加方法

- 40.3.4.5.1 コンテキスト・メニューを使用してxsl:choose文を追加する手順は、次のとおりです。

- 40.3.4.5.2 ドラッグ・アンド・ドロップを使用してxsl:choose文を追加する手順は、次のとおりです。

- 40.3.4.6 xsl:for-eachを使用したループの追加方法

- 40.3.4.6.1 コンテキスト・メニューを使用してxsl:for-each文を追加する手順は、次のとおりです。

- 40.3.4.6.2 ドラッグ・アンド・ドロップを使用してxsl:for-each文を追加する手順は、次のとおりです。

- 40.3.4.7 xsl:for-each文へのxsl:sortの追加方法

- 40.3.4.7.1 コンテキスト・メニューを使用してxsl:sort文を追加する手順は、次のとおりです。

- 40.3.4.7.2 ドラッグ・アンド・ドロップを使用してxsl:sort文を追加する手順は、次のとおりです。

- 40.3.4.8 XSLT命令の複製方法

- 40.3.4.8.1 例: XPath式を変更することによるマッピングの変更

- 40.3.4.8.2 例: 削除および再作成によるマッピングの変更

- 40.3.5 要素の複製方法

- 40.3.6 要素または属性の削除方法

- 40.3.7 要素または属性からマッピングを削除する方法

- 40.4 XSLTビューでのXSLTマップの編集

- 40.4.1 マップ前にターゲットの要素または属性を追加する方法

- 40.4.1.1 ターゲット・スキーマからの要素および属性の追加方法

- 40.4.1.1.1 ターゲット・スキーマがある場合に要素および属性を追加する手順は次のとおりです。

- 40.4.1.1.2 ターゲット・スキーマ・ツリーから要素および属性をドラッグ・アンド・ドロップする手順は次のとおりです。

- 40.4.1.2 ターゲット・スキーマがない場合のリテラル要素および属性の追加方法

- 40.4.1.2.1 ターゲット・スキーマがない場合にリテラル要素を追加する手順は次のとおりです。

- 40.4.1.2.2 ターゲット・スキーマがない場合にリテラル属性を追加する手順は次のとおりです。

- 40.4.1.3 出力ドキュメントでの空ノードの作成方法

- 40.4.2 ノードのリンクによる値のコピーの実行方法

- 40.4.3 xsl:valueof文の挿入方法

- 40.4.4 XSLTノードのリテラル・テキスト値の設定方法

- 40.4.5 xsl:text命令を使用したリテラル・テキスト値の設定方法

- 40.4.6 XSLT文の追加方法

- 40.4.6.1 コンテキスト・メニューを使用してXSLT要素を追加する手順は次のとおりです。

- 40.4.6.2 「コンポーネント」ウィンドウからXSLT要素を追加する手順は、次のとおりです。

- 40.4.7 XSLT式属性の値の設定方法

- 40.4.8 要素の複製方法

- 40.4.9 要素または属性の削除方法

- 40.4.10 要素の移動方法

- 40.4.11 要素または属性からマッピングを削除する方法

- 40.5 XPath式の使用

- 40.5.1 既存のソースとターゲットのマッピングの変更方法

- 40.5.1.1 「XPathの編集」ダイアログを使用してXPath式を編集する手順は、次のとおりです。

- 40.5.1.2 「プロパティ」ウィンドウを使用してXPath式を編集する手順は、次のとおりです。

- 40.5.1.3 XPath関数の既存のXPath式への追加方法

- 40.5.2 キャンバス・ペインでの既存の関数XPath式の変更方法

- 40.5.2.1 ドラッグ・アンド・ドロップを使用して関数パラメータを設定する手順は、次のとおりです。

- 40.5.2.2 関数パラメータを削除する手順は、次のとおりです。

- 40.5.2.3 完全XPath式としての関数の編集方法

- 40.5.2.3.1 「XPathパスの編集」ダイアログを使用して関数をテキストのXPath式として編集する手順は、次のとおりです。

- 40.5.2.3.2 「プロパティ」ウィンドウを使用して関数をテキストのXPath式として編集する手順は、次のとおりです。

- 40.5.2.4 関数の個々のパラメータの編集方法

- 40.5.2.4.1 「関数の編集」ダイアログを使用して関数のパラメータを編集する手順は、次のとおりです。

- 40.5.2.4.2 「プロパティ」ウィンドウを使用して関数のパラメータを編集する手順は、次のとおりです。

- 40.5.3 キャンバス・ペインでの新しい関数の作成方法

- 40.5.3.1 キャンバスのコンテキスト・メニューを使用してXPath関数を作成する手順は、次のとおりです。

- 40.5.3.2 「コンポーネント」ウィンドウを使用してXPath関数を作成する手順は、次のとおりです。

- 40.5.3.3 ターゲット・ツリーのコンテキスト・メニューを使用してXPath関数を作成する手順は、次のとおりです。

- 40.5.3.4 ターゲット・ツリーにドラッグすることでXPath関数を作成する手順は、次のとおりです。

- 40.5.4 関数をまとめて連鎖させる方法

- 40.5.5 XPath式の削除方法

- 40.5.6 ユーザー定義関数のインポート方法

- 40.6 自動マップを使用した複合ノードのマッピング

- 40.6.1 自動マップのプリファレンスの設定方法

- 40.6.2 自動マップの実行方法

- 40.7 マップの完了ステータスの確認

- 40.8 マップのテスト

- 40.8.1 トランスフォーメーション・マッピングのロジックをテストする方法

- 40.8.1.1 DVM参照関数を使用するXSLTマップをテストする方法

- 40.8.1.2 XREF関数を使用するXSLTマップをテストする方法

- 40.8.1.2.1 returnValueの使用:

- 40.8.1.2.2 追加行の追加:

- 40.8.2 レポートの生成方法

- 40.8.3 サンプルXML生成のカスタマイズ方法

- 40.9 外部XSLTマップのインポート

- 40.10 変数およびパラメータの使用

- 40.10.1 グローバル変数の追加方法

- 40.10.2 マップ・ビューでのローカル変数の追加方法

- 40.10.3 XSLTビューでのローカル変数の追加方法

- 40.10.4 グローバル・パラメータの追加方法

- 40.11 要素およびタイプの置換

- 40.12 名前付きテンプレートの使用

- 40.12.1 名前付きテンプレートの作成方法

- 40.12.2 名前付きテンプレートの編集方法

- 40.12.3 既存の名前付きテンプレートへのパラメータの追加方法

- 40.12.4 名前付きテンプレートの起動方法

- 40.13 テンプレート・ルールの使用

- 40.13.1 テンプレート・ルールの作成方法

- 40.13.1.1 例: テンプレート・ルールの作成

- 40.13.1.1.1 テンプレートの起動

- 40.13.2 テンプレート・ルールを作成するための既存のマップのリファクタ方法

- 40.14 実行ビューの使用

- 40.14.1 実行ビューを使用したランタイム・エラーの防止または対処方法

- 40.14.1.1 ノードの検索

- 40.14.1.2 表示オプションの設定

- 40.15 XSLTマップのデバッグ

- 40.15.1 XSLTマップ・エディタでのブレークポイントの設定

- 40.15.2 XSLTマップでのデバッガの実行

- 40.15.3 ブレークポイントの表示

- 40.15.4 XSLTブレークポイントの条件の設定

- 40.16 メモリーの問題のトラブルシューティング

- 40.17 XSLマップ・プリファレンスの設定

- 40.17.1 XSLTマップのプリファレンスの設定方法

- 40.17.2 XSLエディタのプリファレンスの設定方法

- 40.17.3 カスタマイズ・ファイルをインポートしてXSLTマップ・エディタの表示プリファレンスを指定する方法

41 XQueryマッパーを使用したトランスフォーメーションの作成

- 41.1 XQueryマッパーの概要

- 41.1.1 ソースおよびターゲット・ツリーについて

- 41.1.2 XQueryマッパー・ツールバーの使用

- 41.1.3 「プロパティ」ウィンドウの使用

- 41.1.4 「コンポーネント」ウィンドウの使用

- 41.1.5 ソース・エディタ

- 41.2 XQueryマップ・ファイルの作成

- 41.2.1 XQueryメイン/ライブラリ・モジュールの作成方法

- 41.3 XQueryマッパーの使用

- 41.3.1 「値マッピング」を使用してリーフ要素値をターゲット・リーフ要素にコピーする方法

- 41.3.2 「マッピングの上書き」を使用して要素サブツリーをターゲット・ツリーにコピーする方法

- 41.3.3 「マッピングの追加」を使用して要素サブツリーをターゲット・ツリーにコピーする方法

- 41.3.4 1回のドラッグ・アンド・ドロップ操作で複数の値マッピングを実行する方法

- 41.4 XQuery関数の使用

- 41.4.1 XQueryマッパーでのXQuery関数の追加方法

- 41.4.1.1 XQuery関数を追加する手順は、次のとおりです。

- 41.4.1.2 関数のパラメータを編集する手順は次のとおりです。

- 41.5 ライブラリ・モジュールの使用

- 41.5.1 ライブラリ・モジュールのインポート方法

- 41.6 ゾーンおよびFLWORコンストラクトの使用

- 41.6.1 FLWORコンストラクトの編集方法

- 41.7 XQueryパフォーマンス向上のためのタイプ注釈の使用

- 41.8 XQueryマップのテスト

- 41.8.1 XQueryマップのテスト方法

42 ビジネス・イベントおよびイベント配信ネットワークの使用

- 42.1 ビジネス・イベントの概要

- 42.1.1 Oracle SOA SuiteとのEDN統合

- 42.1.2 ビジネス・イベントAPIでのリモート・クライアントのサポート

- 42.1.2.1 BusinessEvent.setProperty APIを呼び出す際のイベント配信ネットワーク・プロパティの手動設定に関するガイドライン

- 42.1.2.1.1 手動で設定できないプロパティ

- 42.1.2.1.2 手動で設定可能なプロパティ

- 42.1.3 ローカル・イベント接続およびリモート・イベント接続

- 42.2 Oracle JDeveloperでのビジネス・イベントの作成

- 42.2.1 ビジネス・イベントの作成方法

- 42.3 Oracle Mediatorサービス・コンポーネントからのビジネス・イベントのサブスクライブまたは公開

- 42.3.1 ビジネス・イベントをサブスクライブする方法

- 42.3.2 ビジネス・イベントを公開する方法

- 42.3.3 ビジネス・イベントの作成およびサブスクライブ時の処理内容

- 42.3.4 ビジネス・イベント公開時の処理内容

- 42.3.5 ビジネス・イベントのサブスクライブに関する必知事項

- 42.3.6 SAFを使用するドメイン間でのイベント公開に関する必知事項

- 42.3.6.1 ローカル・サブスクライバの回避策

- 42.3.7 管理サーバー・アプリケーションでSOAサーバーにイベントを公開できるように外部JNDIプロバイダを構成する方法

- 42.3.8 Oracle WebLogic Server JMSが同じローカルJVMでJMSアダプタとして動作しているときのコネクション・ファクトリの構成方法

- 42.4 BPELプロセス・サービス・コンポーネントからのビジネス・イベントのサブスクライブまたは公開

- 42.4.1 ビジネス・イベントをサブスクライブする方法

- 42.4.2 ビジネス・イベントを公開する方法

- 42.4.3 ビジネス・イベントのサブスクライブおよび公開時の処理内容

- 42.5 Oracle ADF Business Componentビジネス・イベントをOracle Mediatorに統合する方法

43 相互参照の使用

- 43.1 相互参照の概要

- 43.2 相互参照表の概要

- 43.3 相互参照に対するOracle Data Integratorのサポート

- 43.4 相互参照表の作成および変更

- 43.4.1 相互参照メタデータの作成方法

- 43.4.2 相互参照作成時の処理内容

- 43.4.3 カスタム・データベース表の作成方法

- 43.4.4 相互参照表へのエンド・システムの追加方法

- 43.5 相互参照表の移入

- 43.5.1 xref:populateXRefRow関数

- 43.5.2 xref:populateLookupXRefRow関数

- 43.5.3 xref:populateXRefRow1M関数

- 43.5.4 相互参照表の列の移入方法

- 43.6 相互参照表の参照

- 43.6.1 xref:lookupXRef関数

- 43.6.2 xref:lookupXRef1M関数

- 43.6.3 xref:lookupPopulatedColumns関数

- 43.6.4 相互参照表の値の参照方法

- 43.7 相互参照表の値の削除

- 43.7.1 相互参照表の値の削除方法

- 43.8 相互参照ユースケースの作成および実行

- 43.8.1 ユース-ケースの作成方法

- 43.8.1.1 タスク1: Oracle Databaseおよびデータベース・アダプタの構成方法

- 43.8.1.2 タスク2: Oracle JDeveloperのアプリケーションおよびプロジェクトの作成方法

- 43.8.1.3 タスク3: 相互参照の作成方法

- 43.8.1.4 タスク4: データベース・アダプタ・サービスの作成方法

- 43.8.1.5 タスク5: EBSおよびSBL外部参照の作成方法

- 43.8.1.6 タスク6: Loggerファイル・アダプタ外部参照の作成方法

- 43.8.1.7 タスク7: Oracle Mediatorサービス・コンポーネントの作成方法

- 43.8.1.8 タスク8: Oracle Mediatorサービス・コンポーネントのルーティング・ルールの指定方法

- 43.8.1.8.1 挿入操作のルーティング・ルールを作成する手順:

- 43.8.1.8.2 更新操作のルーティング・ルールを作成する手順:

- 43.8.1.8.3 ID更新操作のルーティング・ルールを作成する手順:

- 43.8.1.8.4 削除操作のルーティング・ルールを作成する手順:

- 43.8.1.9 タスク9: 「Common」Oracle Mediatorのルーティング・ルールの指定方法

- 43.8.1.9.1 挿入操作のルーティング・ルールを作成する手順:

- 43.8.1.9.2 削除操作のルーティング・ルールを作成する手順:

- 43.8.1.9.3 更新操作のルーティング・ルールを作成する手順:

- 43.8.1.9.4 ID更新操作のルーティング・ルールを作成する手順:

- 43.8.1.10 タスク10: アプリケーション・サーバー接続の構成方法

- 43.8.1.11 タスク11: コンポジット・アプリケーションのデプロイ方法

- 43.8.2 XrefCustAppアプリケーションの実行方法と監視方法

- 43.9 1M関数の相互参照の作成および実行

- 43.9.1 ユース-ケースの作成方法

- 43.9.1.1 タスク1: Oracle Databaseおよびデータベース・アダプタの構成方法

- 43.9.1.2 タスク2: Oracle JDeveloperのアプリケーションおよびプロジェクトの作成方法

- 43.9.1.3 タスク3: 相互参照の作成方法

- 43.9.1.4 タスク4: データベース・アダプタ・サービスの作成方法

- 43.9.1.5 タスク5: EBS外部参照の作成方法

- 43.9.1.6 タスク6: Loggerファイル・アダプタ外部参照の作成方法

- 43.9.1.7 タスク7: Oracle Mediatorサービス・コンポーネントの作成方法

- 43.9.1.8 タスク8: Oracle Mediatorコンポーネントのルーティング・ルールの指定方法

- 43.9.1.8.1 挿入操作のルーティング・ルールを作成する手順:

- 43.9.1.8.2 更新操作のルーティング・ルールを作成する手順:

- 43.9.1.9 タスク9: 「Common」Oracle Mediatorのルーティング・ルールの指定方法

- 43.9.1.9.1 挿入操作のルーティング・ルールを作成する手順:

- 43.9.1.9.2 更新操作のルーティング・ルールを作成する手順:

- 43.9.1.10 タスク10: アプリケーション・サーバー接続の構成方法

- 43.9.1.11 タスク11: コンポジット・アプリケーションのデプロイ方法

44 ドメイン値マップの使用

- 44.1 ドメイン値マップの概要

- 44.1.1 ドメイン値マップ機能

- 44.1.1.1 修飾子ドメイン

- 44.1.1.2 修飾子の階層

- 44.1.1.3 1対多マッピング

- 44.2 ドメイン値マップの作成

- 44.2.1 ドメイン値マップの作成方法

- 44.2.2 ドメイン値マップ作成時の処理内容

- 44.3 ドメイン値マップの編集

- 44.3.1 ドメイン値マップへのドメインの追加方法

- 44.3.2 ドメインの編集方法

- 44.3.3 ドメイン値マップへのドメイン値の追加方法

- 44.3.4 ドメイン値の編集方法

- 44.4 ドメイン値マップ関数の使用

- 44.4.1 ドメイン値マップ関数の理解

- 44.4.1.1 dvm:lookupValue

- 44.4.1.2 dvm:lookupValue1M

- 44.4.2 トランスフォーメーションでのドメイン値マップ関数の使用方法

- 44.4.3 XPath式でのドメイン値マップ関数の使用方法

- 44.4.4 実行時の処理内容

- 44.5 階層ルックアップ用のドメイン値マップ・ユースケースの作成

- 44.5.1 HierarchicalValueユースケースの作成方法

- 44.5.1.1 タスク1: Oracle JDeveloperのアプリケーションおよびプロジェクトの作成方法

- 44.5.1.2 タスク2: ドメイン値マップの作成方法

- 44.5.1.3 タスク3: ファイル・アダプタ・サービスの作成方法

- 44.5.1.4 タスク4: ProcessOrdersメディエータ・コンポーネントの作成方法

- 44.5.1.5 タスク5: ファイル・アダプタ参照の作成方法

- 44.5.1.6 タスク6: ルーティング・ルールの指定方法

- 44.5.1.7 タスク7: アプリケーション・サーバー接続の構成方法

- 44.5.1.8 タスク8: コンポジット・アプリケーションのデプロイ方法

- 44.5.2 HierarchicalValueアプリケーションの実行方法と監視方法

- 44.6 複数の値のドメイン値マップ・ユースケースの作成

- 44.6.1 Multivalueユースケースの作成方法

- 44.6.1.1 タスク1: Oracle JDeveloperのアプリケーションおよびプロジェクトの作成方法

- 44.6.1.2 タスク2: ドメイン値マップの作成方法

- 44.6.1.3 タスク3: ファイル・アダプタ・サービスの作成方法

- 44.6.1.4 タスク4: LookupMultiplevaluesMediatorメディエータの作成方法

- 44.6.1.5 タスク5: ファイル・アダプタ参照の作成方法

- 44.6.1.6 タスク6: ルーティング・ルールの指定方法

- 44.6.1.7 タスク7: アプリケーション・サーバー接続の構成方法

- 44.6.1.8 タスク8: コンポジット・アプリケーションのデプロイ方法

- 44.6.2 Multivalueアプリケーションの実行方法と監視方法

- 44.7 初回使用を高速化するためのDVMキャッシュの事前ロード

- 44.7.1 サーバー起動時のDVMキャッシュの事前ロード方法

45 ドメイン値マップでのOracle SOAコンポーザの使用

- 45.1 Oracle SOAコンポーザの概要

- 45.1.1 Oracle SOAコンポーザへのログイン方法

- 45.2 実行時のドメイン値マップの表示

- 45.2.1 実行時のドメイン値マップの表示方法

- 45.3 実行時のドメイン値マップの編集

- 45.3.1 実行時のドメイン値マップの編集方法

- 45.3.1.1 編集モードへの変更

- 45.3.1.2 行の追加

- 45.3.1.3 行の編集

- 45.3.1.4 行の削除

- 45.4 実行時の変更内容のパブリッシュ

- 45.4.1 実行時に変更内容をパブリッシュする方法

- 45.4.2 実行時に変更内容を破棄する方法

- 45.5 競合の検出

第VIII部 アプリケーションの完成

46 ポリシーおよびメッセージ暗号化を使用したセキュリティの有効化

- 46.1 ポリシーの概要

- 46.2 バインディング・コンポーネントおよびサービス・コンポーネントへのポリシーの添付

- 46.2.1 ポリシーをバインディング・コンポーネントおよびサービス・コンポーネントに添付する方法

- 46.2.1.1 ポリシーをサービス・コンポーネントに添付する手順は、次のとおりです。

- 46.2.2 ポリシー構成プロパティ値のオーバーライド方法

- 46.2.2.1 クライアント構成プロパティ値のオーバーライド

- 46.2.2.2 サーバー構成プロパティ値のオーバーライド

- 46.3 メッセージの特定フィールドの暗号化と復号化

- 46.3.1 メッセージの特定フィールドを暗号化および復号化する方法

47 SOAコンポジット・アプリケーションのデプロイ

- 47.1 デプロイメントの概要

- 47.2 デプロイメントの前提条件

- 47.2.1 Oracle SOA Suiteスキーマの作成

- 47.2.2 SOAドメインの作成

- 47.2.3 SOAクラスタの構成

- 47.3 パッケージ化による影響の理解

- 47.4 コンポジットの構造

- 47.5 ターゲット環境の準備

- 47.5.1 データ・ソースおよびキューの作成方法

- 47.5.1.1 JMSリソースの作成およびJMSアダプタの再デプロイメント用のスクリプト

- 47.5.1.2 データベース・リソースの作成およびデータベース・アダプタの再デプロイメント用のスクリプト

- 47.5.2 コネクション・ファクトリおよび接続プールの作成方法

- 47.5.3 セキュリティを有効化する方法

- 47.5.4 設計時のビジネス・フロー・インスタンス名またはコンポジット・インスタンス名の設定方法

- 47.5.4.1 Oracle Mediatorでのビジネス・フロー・インスタンス名の設定

- 47.5.4.2 BPELプロセスでのビジネス・フロー・インスタンス名の設定

- 47.5.4.3 BPELプロセスでのコンポジット・インスタンス名の設定

- 47.5.5 取引パートナ・アグリーメントおよびタスク・フローのデプロイ方法

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

- 47.5.7 SOA-MDS接続の作成方法

- 47.5.7.1 SOA-MDS接続によるcomposite.xmlファイルのオープンに関する必知事項

- 47.6 デプロイメント前にターゲット環境に応じてアプリケーションをカスタマイズする方法

- 47.6.1 ターゲット環境に応じてSOAコンポジット・アプリケーションをカスタマイズするための構成プランの使用方法

- 47.6.1.1 構成プランの概要

- 47.6.1.2 構成プラン・ファイルの概要

- 47.6.1.3 構成プランのユースケースの概要

- 47.6.1.3.1 環境に依存しないプロセスを作成するときに構成プランを使用する方法

- 47.6.1.4 Oracle JDeveloperでの構成プランの作成方法

- 47.6.1.5 WLSTユーティリティを使用した構成プランの作成方法

- 47.6.1.6 スクリプトを使用した構成プランの添付方法

- 47.6.1.7 グローバル・トークン変数の作成方法

- 47.7 Oracle JDeveloperでのSOAコンポジット・アプリケーションのデプロイ

- 47.7.1 Oracle JDeveloperでの単一のSOAコンポジットのデプロイ方法

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

- 47.7.1.2 (オプション)プロジェクト・デプロイメント・プロファイルの作成

- 47.7.1.3 プロファイルのデプロイ

- 47.7.1.4 タスク・フローのあるヒューマン・タスク・コンポジットのパーティションへのデプロイに関する必知事項

- 47.7.2 Oracle JDeveloperでの複数のSOAコンポジット・アプリケーションのデプロイ方法

- 47.7.3 Oracle JDeveloperでの複数のSOAコンポジット・アプリケーション間の共有データのデプロイ方法および使用方法

- 47.7.3.1 JARプロファイルの作成および共有するアーティファクトの組込み

- 47.7.3.2 JARプロファイルを組み込むSOAバンドルの作成

- 47.7.3.3 Oracle JDeveloperでのSOAバンドルのデプロイ

- 47.7.3.3.1 antでSOAバンドルをデプロイする手順は、次のとおりです。

- 47.7.3.4 共有データの使用

- 47.7.3.4.1 SOA-MDS接続の作成

- 47.7.3.4.2 BPELプロセスの作成

- 47.7.4 Oracle JDeveloperでの既存のSOAアーカイブのデプロイ方法

- 47.8 WLSTユーティリティを使用したSOAコンポジット・アプリケーションのデプロイおよび管理

- 47.9 antスクリプトを使用したSOAコンポジット・アプリケーションのデプロイおよび管理

- 47.9.1 SOAコンポジット・アプリケーションのテストを自動化するためのantの使用方法

- 47.9.2 SOAコンポジット・アプリケーションをコンパイルするためのantの使用方法

- 47.9.3 コンポジットSARファイルにSOAコンポジット・アプリケーションをパッケージ化するためのantの使用方法

- 47.9.4 SOAコンポジット・アプリケーションをデプロイするためのantの使用方法

- 47.9.5 SOAコンポジット・アプリケーションをアンデプロイアーカイブするためのantの使用方法

- 47.9.6 SARファイルにコンポジットをエクスポートするためのantの使用方法

- 47.9.7 JARファイルにコンポジットのデプロイメント後の変更をエクスポートするためのantの使用方法

- 47.9.8 コンポジットのデプロイメント後の変更をインポートするためのantの使用方法

- 47.9.9 JARファイルへ指定したパターンの共有データをエクスポートするためのantの使用方法

- 47.9.10 トップレベルの共有データ・フォルダを削除するためのantの使用方法

- 47.9.11 SOAコンポジット・アプリケーションを起動するためのantの使用方法

- 47.9.12 SOAコンポジット・アプリケーションを停止するためのantの使用方法

- 47.9.13 SOAコンポジット・アプリケーションをアーカイブするためのantの使用方法

- 47.9.14 SOAコンポジット・アプリケーションをリタイアするためのantの使用方法

- 47.9.15 SOAコンポジット・アプリケーションにデフォルト・バージョンを割り当てるためのantの使用方法

- 47.9.16 デプロイ済SOAコンポジット・アプリケーションを一覧表示するためのantの使用方法

- 47.9.17 SOAインフラストラクチャで使用可能なすべてのパーティションを一覧表示するためのantの使用方法

- 47.9.18 パーティション内のすべてのコンポジットを一覧表示するためのantの使用方法

- 47.9.19 SOAインフラストラクチャでパーティションを作成するためのantの使用方法

- 47.9.20 SOAインフラストラクチャでパーティションを削除するためのantの使用方法

- 47.9.21 パーティション内のすべてのコンポジットを起動するためのantの使用方法

- 47.9.22 パーティション内のすべてのコンポジットを停止するためのantの使用方法

- 47.9.23 パーティション内のすべてのコンポジットをアーカイブするためのantの使用方法

- 47.9.24 パーティション内のすべてのコンポジットをリタイアするためのantの使用方法

- 47.9.25 SOAコンポジット・アプリケーションを管理するためのantの使用方法

- 47.10 SOAコンポジット・アプリケーションのOracle Enterprise Manager Fusion Middleware Controlからのデプロイ

- 47.11 クラスタへのSOAコンポジット・アプリケーションのデプロイ

- 47.12 実行中のサーバーがない状態でのSOAコンポジット・アプリケーションのデプロイ

- 47.12.1 オフライン・デプロイメント構成ファイル

- 47.12.1.1 オフライン・デプロイメント構成リスト・ファイル

- 47.12.1.2 オフライン・デプロイメント構成ファイル

- 47.12.1.3 構成ファイルの相対パス

- 47.12.1.4 デプロイメントの順序

- 47.12.2 実行中のサーバーがない状態でSOAコンポジット・アプリケーションと共有データをデプロイする方法

- 47.12.3 クラスタ環境でのオフライン・コンポジット・デプロイメントに関する必知事項

- 47.12.4 MDSリポジトリにない共有データを参照するSOAコンポジット・アプリケーションのデプロイに関する必知事項

- 47.13 デプロイメント後の構成

- 47.13.1 セキュリティ

- 47.13.2 接続の更新

- 47.13.3 データ・ソースおよびキューの更新

- 47.13.4 ポリシーの添付

- 47.14 テストおよびトラブルシューティング

- 47.14.1 デプロイメントの検証

- 47.14.2 デプロイ済コンポジットのインスタンスの開始

- 47.14.3 デプロイ済コンポジットのテストの自動化

- 47.14.4 デプロイメント・エラー受取り後のプロジェクトの再コンパイル

- 47.14.5 Javaのコンパイル・エラーを解決するためのJavaコード・サイズの削減

- 47.14.6 デプロイメントに関する共通のエラーのトラブルシューティング

- 47.14.6.1 Oracle JDeveloperでのデプロイメントに関する共通の問題

- 47.14.6.2 構成プランに関する共通の問題

- 47.14.6.3 管理対象Oracle WebLogic Serverへのデプロイ

- 47.14.6.4 双方向のSSL対応Oracle WebLogic Serverへのデプロイ

- 47.14.6.5 接続できないプロキシ・サーバーを使用したデプロイ

- 47.14.6.6 ADFタスク・フォームのEARファイルのデプロイメント・エラーを解決するためのロックの解放

- 47.14.6.7 メモリー増加によるコンパイル・エラーのリカバリ

- 47.14.6.8 相関セットを使用したreceiveアクティビティのプロパティ・エイリアス定義が存在しないときのOracle JDeveloperコンパイル・エラー

- 47.14.6.9 ADFバインディング・サービス名は、デプロイされたすべてのSOAコンポジット・アプリケーション間で一意であることが必要

- 47.15 SOAコンポジットの実行中のインスタンスへのパッチ適用

- 47.15.1 JDeveloperでの「SOAパッチ開発者」モードの使用

- 47.15.1.1 パッチXMLファイルの生成

- 47.15.1.2 スパース・デプロイメント・プロファイルの作成

- 47.15.2 WLSTを使用したパッチの検証およびデプロイ

- 47.15.3 パッチ・ファイルの削除

48 Oracle SOA Suite開発Mavenプラグインの使用

- 48.1 Oracle SOA Suite Mavenプラグインの概要

- 48.1.1 POMファイルおよびArchetype

- 48.1.2 Mavenプラグインのゴール

- 48.1.2.1 compile

- 48.1.2.2 package

- 48.1.2.3 deploy

- 48.1.2.4 test

- 48.1.2.5 undeploy

- 48.1.3 Mavenオンライン・ヘルプの使用

- 48.2 Oracle SOA Suite Mavenプラグインのインストール

- 48.2.1 Oracle SOA Suite Mavenプラグインの構成方法

- 48.3 Oracle SOA Suite Maven Archetypeの使用

49 SOAコンポジット・アプリケーションのデバッグおよび監査

- 49.1 SOAデバッガの概要

- 49.2 SOAコンポジット・アプリケーションのデバッグ

- 49.2.1 SOAデバッガを開始する方法

- 49.2.2 ブレークポイントを設定してデバッグを開始する方法

- 49.2.3 デバッグ・セッションのステップ実行方法

- 49.2.4 デバッグ・セッションを終了または切断する方法

- 49.2.5 ブレークポイントを削除する方法

- 49.2.6 アダプタ・プロパティを表示する方法

- 49.2.7 スレッドを表示する方法

- 49.3 HTTPアナライザを使用したSOAコンポジット・アプリケーションのテスト

- 49.4 BPELアクティビティ・レベルでのSOAコンポジット・アプリケーションの監査

- 49.4.1 BPELアクティビティ・レベルでSOAコンポジット・アプリケーションを監査する方法

50 SOAコンポジット・アプリケーションのテストの自動化

- 50.1 コンポジット・テスト・フレームワークの概要

- 50.1.1 テスト・ケースの概要

- 50.1.2 テスト・スイートの概要

- 50.1.3 エミュレーションの概要

- 50.1.4 アサーションの概要

- 50.2 テスト・スイートのコンポーネントの概要

- 50.2.1 プロセスの開始

- 50.2.2 エミュレーション

- 50.2.3 アサーション

- 50.2.4 メッセージ・ファイル

- 50.3 「コンポジット・テストの作成」ウィザードを使用したテスト・スイートとテスト・ケースの作成

- 50.4 SOAコンポジット・エディタのテスト・モードによるテスト・ケースのコンテンツの編集

- 50.4.1 インバウンド・メッセージの開始方法

- 50.4.2 アウトバウンド・メッセージのエミュレート方法

- 50.4.3 コールバック・メッセージのエミュレート方法

- 50.4.4 フォルト・メッセージのエミュレート方法

- 50.4.5 アサーションの作成方法

- 50.4.5.1 パート・セクション、非リーフ要素またはXML文書全体に対するアサーションの作成

- 50.4.5.2 リーフ要素に対するアサーションの作成

- 50.4.6 アサーションに関する必知事項

- 50.5 BPELプロセス・サービス・コンポーネントのテスト

- 50.5.1 BPELプロセスのアクティビティのアサーションの概要

- 50.5.2 Waitアクティビティの早送りアクションの概要

- 50.5.3 Assertアクティビティの実行の概要

- 50.5.4 BPELプロセス・サービス・コンポーネントのテストの作成方法

- 50.5.5 アサーションの作成方法

- 50.5.6 waitアクティビティのバイパス方法

- 50.5.7 アクティビティの実行回数の指定方法

- 50.6 テスト・スイートのデプロイおよび実行

- 50.6.1 Oracle JDeveloperからテスト・スイートをデプロイして実行する方法

- 50.6.2 Oracle Enterprise Manager Fusion Middleware Controlからテスト・スイートをデプロイして実行する方法

- 50.6.3 WLSTコマンドを使用してテスト・スイートをデプロイして実行する方法

- 50.6.4 antスクリプトを使用してテスト・スイートをデプロイして実行する方法

第IX部 高度なトピック

51 大規模ドキュメントおよび多数のインスタンスの管理

- 51.1 大規模ドキュメントを処理する場合のベスト・プラクティス

- 51.1.1 大規模ドキュメントを処理する場合のユースケース

- 51.1.1.1 XMLペイロードへのバイナリ・オブジェクトのBase64エンコード・テキストとしての受け渡し

- 51.1.1.1.1 SOAPインライン

- 51.1.1.1.2 SOAP MTOM

- 51.1.1.1.3 ファイル/FTPアダプタによって渡される不透明(Opaque)コンテンツ

- 51.1.1.1.4 Oracle B2Bによって渡される不透明(Opaque)コンテンツ

- 51.1.1.2 アタッチメントのエンドツーエンドのストリーミング

- 51.1.1.2.1 アタッチメント付きのSOAP

- 51.1.1.2.2 ストリーミング・アタッチメントの使用

- 51.1.1.2.3 MIMEアタッチメントを使用するコンポジットの作成

- 51.1.1.2.4 パフォーマンス・オーバーヘッドとパス・スルー・アタッチメント

- 51.1.1.2.5 アタッチメントをストリーミングするためのプロパティ

- 51.1.1.2.6 SOA Webサービスのバインディング・レイヤーからのストリーミング・アタッチメント

- 51.1.1.2.7 SOAPアタッチメントのコンテンツの読取りおよびエンコード

- 51.1.1.2.8 アタッチメント・ストリームの送信

- 51.1.1.2.9 Oracle Mediatorでのアタッチメントのパス・スルー設定のオーバーライド

- 51.1.1.2.10 同期フローを使用したアタッチメントの共有

- 51.1.1.2.11 ファイル/FTPアダプタのアタッチメント・オプション

- 51.1.1.2.12 Oracle B2Bアタッチメント

- 51.1.1.3 SOAコンポジット・アプリケーションとのMTOM最適化メッセージの送受信

- 51.1.1.3.1 SwAおよびMTOM最適化アタッチメントをデータベースに格納するためのシナリオ

- 51.1.1.4 繰返しコンストラクトを使用した大規模XMLの処理

- 51.1.1.4.1 ファイル/FTPアダプタによるデバッチ

- 51.1.1.4.2 ファイル/FTPアダプタによるチャンク

- 51.1.1.5 複雑な構造の大規模XML文書の処理

- 51.1.1.5.1 ファイル/FTPアダプタによるストリーム

- 51.1.1.5.2 Oracle B2Bストリーム

- 51.1.2 大規模ドキュメントの同時処理に関する制限

- 51.1.2.1 大規模ペイロードを処理するための不透明(Opaque)スキーマ

- 51.1.3 SOAコンポジット・アプリケーション用JVMメモリーのサイズ設定の推奨事項

- 51.1.4 チューニングに関する一般的な推奨事項

- 51.1.4.1 一般的な推奨事項

- 51.1.4.1.1 HTTP POSTタイムアウトを増やす

- 51.1.4.1.2 タイムアウト値を増やす

- 51.1.4.2 大規模なペイロードの処理に対するOracle Enterprise Managerからの監査レベルの設定

- 51.1.4.3 Oracle BPEL Process ManagerおよびOracle Mediatorでのassignアクティビティの使用

- 51.1.4.4 大規模ペイロード(Oracle BPEL Process Manager)でのXSLTトランスフォーメーションの使用

- 51.1.4.5 大規模ペイロード(Oracle Mediator)でのXSLTトランスフォーメーションの使用

- 51.1.4.6 繰返し構造に対するXSLTトランスフォーメーションの使用

- 51.1.4.7 Oracle B2Bでの大規模ドキュメントの処理

- 51.1.4.7.1 MDSインスタンス・キャッシュ・サイズ

- 51.1.4.7.2 プロトコル・メッセージ・サイズ

- 51.1.4.7.3 スレッド数

- 51.1.4.7.4 スタック・スレッド最大時間パラメータ

- 51.1.4.7.5 表領域

- 51.1.4.8 インバウンドWebサービスのメッセージ・サイズに対するサイズ制限の設定

- 51.1.4.9 XPath関数を使用したファイル・システムへの大規模なXSLT/XQuery出力の書込み

- 51.2 大規模メタデータを処理する場合のベスト・プラクティス

- 51.2.1 BPELプロセスでの多数のアクティビティの処理に対する境界

- 51.2.2 BPELプロセスでの多数のアクティビティの使用(flowNを使用しない場合)

- 51.2.3 BPELプロセスでの多数のアクティビティの使用(flowNを使用する場合)

- 51.2.4 複数シーケンスを含むフローの使用

- 51.2.5 単一シーケンスを含むフローの使用

- 51.2.6 シーケンスを含まないフローの使用

- 51.2.7 コンポジットの多数のOracle Mediator

- 51.2.8 Oracle B2Bへの大規模データ・セットのインポート

- 51.3 多数のインスタンスを処理する場合のベスト・プラクティス

- 51.3.1 パージ・スクリプトまたはOracle Enterprise Manager Fusion Middleware Controlを使用したインスタンスと拒否されたメッセージの削除

52 SOAコンポジット・アプリケーションのカスタマイズ

- 52.1 SOAコンポジット・アプリケーションのカスタマイズの概要

- 52.2 カスタマイズ可能なコンポジットの作成

- 52.2.1 カスタマイズ・クラスの作成方法

- 52.2.2 カスタマイズ可能なコンポジットの作成方法

- 52.2.3 XSDまたはWSDLファイルの追加方法

- 52.2.4 BPELプロセスでのカスタマイズ・アクティビティの検索方法

- 52.2.5 Oracle JDeveloperでの検証エラーの解決に関する必知事項

- 52.2.6 シーケンスの競合の解決に関する必知事項

- 52.2.6.1 競合を解決する手順:

- 52.2.7 カスタマイズされたアプリケーションのコンパイルおよびデプロイに関する必知事項

- 52.3 バーティカル・アプリケーションのカスタマイズ

- 52.3.1 バーティカル・アプリケーションのカスタマイズ方法

- 52.4 顧客バージョンのカスタマイズ

- 52.4.1 顧客バージョンのカスタマイズ方法

- 52.5 コンポジットのアップグレード

- 52.5.1 コア・アプリケーション・チーム・コンポジットのアップグレード方法

- 52.5.2 バーティカル・アプリケーション・チーム・コンポジットのアップグレード方法

- 52.5.3 カスタマ・コンポジットのアップグレード方法

53 コンポジット・センサーの定義

- 53.1 コンポジット・センサーの概要

- 53.1.1 コンポジット・センサー使用上の制限

- 53.2 コンポジット・センサーの追加

- 53.2.1 コンポジット・センサーの追加方法

- 53.2.1.1 変数の追加方法

- 53.2.1.2 式の追加方法

- 53.2.1.3 プロパティの追加方法

- 53.2.2 重複するコンポジット・センサー名に関する必知事項

- 53.3 実行時のコンポジット・センサー・データの監視

- 53.4 Oracle SOAコンポーザからのコンポジット・センサーの実行時の作成および管理

- 53.4.1 Oracle SOAコンポーザでのコンポジット・センサーの変更の表示に関する必知事項

54 動的ビジネス・プロセスの作成

- 54.1 2レイヤーのビジネス・プロセス管理の概要

- 54.2 phaseアクティビティの作成

- 54.2.1 phaseアクティビティの作成方法

- 54.2.2 phaseアクティビティ作成時の処理内容

- 54.2.3 phaseアクティビティを作成した場合の実行時の処理内容

- 54.2.4 phaseアクティビティの作成に関する必知事項

- 54.3 動的ルーティング・デシジョン表の作成

- 54.3.1 動的ルーティング・デシジョン表の作成方法

- 54.3.2 動的ルーティング・デシジョン表作成時の処理内容

55 Spring Frameworkを使用したSOAコンポジット・アプリケーションへの統合

- 55.1 Springサービス・コンポーネントの概要

- 55.2 同じSOAコンポジット・アプリケーション内でのJavaベース・コンポーネントとWSDLベース・コンポーネントの統合

- 55.2.1 JavaベースおよびWSDLベースの統合例

- 55.2.2 Spring Frameworkでのコールバックの使用

- 55.3 Oracle JDeveloperでのSpringサービス・コンポーネントの作成

- 55.3.1 Oracle JDeveloperでのSpringサービス・コンポーネントの作成方法

- 55.3.2 JavaからWSDLへの変換時のJavaクラス・エラーに関する必知事項

- 55.4 グローバルSpringコンテキストを介したカスタムSpring Beanの定義

- 55.4.1 グローバルSpringコンテキストを介したカスタムSpring Beanの定義方法

- 55.5 事前定義済のSpring Beanの使用

- 55.5.1 headerHelperBeanのIHeaderHelperBean.javaインタフェース

- 55.5.2 instancerHelperBeanのIInstanceHelperBean.javaインタフェース

- 55.5.3 loggerBeanのILoggerBean.javaインタフェース

- 55.5.4 Springコンテキスト・ファイル内の事前定義済Spring Beanの参照方法

- 55.6 JAXBおよびOXMのサポート

- 55.6.1 拡張されたマッピング・ファイル

- 55.7 Springサービス・コンポーネントによるGroovyおよびAspectjクラスの構成

- 55.8 Springエラーのトラブルシューティング

- 55.8.1 起動するSpring Beanインタフェースが見つからない

- 55.8.2 SOAコンポジット・エディタでSpringサービス・コンポーネントを追加できない

第X部 付録

A BPELプロセスのアクティビティとサービス

- A.1 アクティビティおよびコンポーネントの概要

- A.2 BPEL 1.1および2.0アクティビティの概要

- A.2.1 多くのアクティビティに共通のタブ

- A.2.1.1 「注釈」タブ

- A.2.1.2 「アサーション」タブ

- A.2.1.3 「相関」タブ

- A.2.1.4 「ドキュメント」タブ

- A.2.1.5 「ヘッダー」タブ

- A.2.1.6 「プロパティ」タブ

- A.2.1.7 「スキップ条件」タブ

- A.2.1.8 「ソース」タブと「ターゲット」タブ

- A.2.1.9 「タイムアウト」タブ

- A.2.2 アダプタ構成時以外のネイティブ・フォーマット・ビルダー・ウィザードの使用

- A.2.2.1 「アプリケーション」ウィンドウからネイティブ・フォーマット・スキーマを作成する手順:

- A.2.2.2 「アプリケーション」ウィンドウで既存のネイティブ・フォーマット・スキーマを編集する手順:

- A.2.3 Assignアクティビティ

- A.2.4 Assertアクティビティ

- A.2.5 Bind Entityアクティビティ

- A.2.6 Callアクティビティ

- A.2.7 Compensateアクティビティ

- A.2.8 CompensateScopeアクティビティ

- A.2.9 Create Entityアクティビティ

- A.2.10 Dehydrateアクティビティ

- A.2.11 Dynamic Partner Linkアクティビティ

- A.2.12 Emailアクティビティ

- A.2.13 Emptyアクティビティ

- A.2.14 Exitアクティビティ

- A.2.15 Flowアクティビティ

- A.2.16 FlowNアクティビティ

- A.2.17 forEachアクティビティ

- A.2.18 Ifアクティビティ

- A.2.19 IMアクティビティ

- A.2.20 Invokeアクティビティ

- A.2.21 Java Embeddingアクティビティ

- A.2.22 Partner Linkアクティビティ

- A.2.23 Phaseアクティビティ

- A.2.24 Pickアクティビティ

- A.2.24.1 assignアクティビティの前に相関構文を配置する手順:

- A.2.25 Receiveアクティビティ

- A.2.26 Receive Signalアクティビティ

- A.2.27 Remove Entityアクティビティ

- A.2.28 RepeatUntilアクティビティ

- A.2.29 Replayアクティビティ

- A.2.30 Replyアクティビティ

- A.2.31 Rethrowアクティビティ

- A.2.32 ジョブのスケジュール

- A.2.33 Scopeアクティビティ

- A.2.34 Sequenceアクティビティ

- A.2.35 Signalアクティビティ

- A.2.36 SMSアクティビティ

- A.2.37 Switchアクティビティ

- A.2.38 Terminateアクティビティ

- A.2.39 Throwアクティビティ

- A.2.40 Translateアクティビティ

- A.2.41 User Notificationアクティビティ

- A.2.42 Validateアクティビティ

- A.2.43 Voiceアクティビティ

- A.2.44 Waitアクティビティ

- A.2.45 Whileアクティビティ

- A.2.46 XQuery Transformアクティビティ

- A.2.47 XSLT Transformアクティビティ

- A.3 BPELサービスの概要

B XPath拡張関数

- B.1 拡張関数

- B.1.1 batchProcessActive

- B.1.2 batchProcessCompleted

- B.1.3 copyList

- B.1.4 create-nodeset-from-delimited-string

- B.1.5 createDelimitedString

- B.1.6 createEssParameter

- B.1.7 doStreamingTranslate

- B.1.8 doTranslateFromNative

- B.1.9 doTranslateToNative

- B.1.10 format

- B.1.11 genEmptyElem

- B.1.12 generate-guid

- B.1.13 get-content-from-file-function

- B.1.14 getApplicationName

- B.1.15 getAttachmentContent

- B.1.16 getAttachmentProperty

- B.1.17 getChildElement

- B.1.18 getComponentInstanceID

- B.1.19 getComponentName

- B.1.20 getCompositeInstanceID

- B.1.21 getCompositeName

- B.1.22 getCompositeURL

- B.1.23 getECID

- B.1.24 getFaultAsString

- B.1.25 getFaultAsXML

- B.1.26 getFaultName

- B.1.27 getMilestoneName

- B.1.28 getOwnerDocument

- B.1.29 getParentComponentInstanceID

- B.1.30 getRevision

- B.1.31 getTaskReminderDuration

- B.1.32 instanceOf

- B.1.33 lookup-xml

- B.1.34 parseEscapedXML

- B.1.35 parseXML

- B.1.36 processScalableDocumentToNative

- B.1.37 processXSLTAttachmentFromNativeToNative

- B.1.38 processXSLTAttachmentFromNativeToStream

- B.1.39 processXSLTAttachmentToNativeStream

- B.1.40 processXSLTAttachmentToStream

- B.1.41 processXSLTForScalableDocument

- B.1.42 setCompositeInstanceTitle

- B.2 BPEL拡張関数

- B.2.1 BPEL 1.1とBPEL 2.0におけるBPEL拡張関数

- B.2.1.1 getLinkStatus

- B.2.1.2 getVariableData

- B.2.1.2.1 結果ノードセットのサイズが実行時に選択されるノードセットのサイズと異なる場合にスローされるselectionFailureフォルト

- B.2.1.3 getVariableProperty (BPEL 1.1)

- B.2.1.4 getVariableProperty (BPEL 2.0)

- B.2.1.5 doXslTransform (BPEL 2.0)

- B.3 BPEL XPath拡張関数

- B.3.1 addQuotes

- B.3.2 authenticate

- B.3.3 countNodes

- B.3.4 doXSLTransform

- B.3.5 doXSLTransformForDoc

- B.3.6 doc

- B.3.7 formatDate

- B.3.8 generateGUID

- B.3.9 getConfigProperty

- B.3.10 getContentAsString

- B.3.11 getConversationId

- B.3.12 getCreator

- B.3.13 getCurrentDate

- B.3.14 getCurrentDateTime

- B.3.15 getCurrentTime

- B.3.16 getElement

- B.3.17 getInstanceId

- B.3.18 getNodeValue

- B.3.19 getNodes

- B.3.20 getPreference

- B.3.21 getProcessId

- B.3.22 getProcessOwnerId

- B.3.23 getProcessURL

- B.3.24 getProcessVersion

- B.3.25 integer

- B.3.26 listUsers

- B.3.27 lookupUser

- B.3.28 parseEscapedXML

- B.3.29 processXQuery

- B.3.30 processXQuery10

- B.3.31 processXQuery2004

- B.3.32 processXSLT

- B.3.33 readBinaryFromFile

- B.3.34 readBinaryFromFileWithMimeHeaders

- B.3.35 readFile

- B.3.36 search

- B.3.37 toCDATA

- B.3.38 tryToCastToBoolean

- B.3.39 writeBinaryToFile

- B.3.40 getGroupIdsFromGroupAlias

- B.3.41 getUserIdsFromGroupAlias

- B.4 変換関数

- B.4.1 boolean

- B.4.2 number

- B.4.3 string

- B.5 DVM関数

- B.5.1 lookupValue

- B.5.2 lookupValue1M

- B.6 データベース関数

- B.6.1 lookup-table

- B.6.2 query-database

- B.6.3 sequence-next-val

- B.7 日付関数

- B.7.1 add-dayTimeDuration-to-dateTime

- B.7.2 current-date

- B.7.3 current-dateTime

- B.7.3.1 秒単位で日時の値を表示する手順:

- B.7.4 current-time

- B.7.5 day-from-dateTime

- B.7.6 format-dateTime

- B.7.7 hours-from-dateTime

- B.7.8 minutes-from-dateTime

- B.7.9 month-from-dateTime

- B.7.10 seconds-from-dateTime

- B.7.11 subtract-dayTimeDuration-from-dateTime

- B.7.12 timezone-from-dateTime

- B.7.13 year-from-dateTime

- B.8 アイデンティティ・サービス関数

- B.8.1 getDefaultRealmName

- B.8.2 getGroupProperty

- B.8.3 getManager

- B.8.4 getManagerFromManagementChain

- B.8.5 getReportees

- B.8.6 getSupportedRealmNames

- B.8.7 getUserProperty

- B.8.8 getUserRoles

- B.8.9 getUsersInAppRole

- B.8.10 getUsersInGroup

- B.8.11 isUserInAppRole

- B.8.12 isUserInRole

- B.8.13 lookupGroup

- B.8.14 lookupUser

- B.9 論理関数

- B.9.1 and

- B.9.2 equals

- B.9.3 false

- B.9.4 greater

- B.9.5 greater equals

- B.9.6 less

- B.9.7 less equals

- B.9.8 not

- B.9.9 not equals

- B.9.10 or

- B.9.11 true

- B.10 数学関数

- B.10.1 abs

- B.10.2 add

- B.10.3 ceiling

- B.10.4 count

- B.10.5 divide

- B.10.6 floor

- B.10.7 max-value-among-nodeset

- B.10.8 min-value-among-nodeset

- B.10.9 mod

- B.10.10 multiply

- B.10.11 round

- B.10.12 square-root

- B.10.13 subtract

- B.10.14 sum

- B.10.15 unary

- B.11 ノード・セット関数

- B.11.1 last

- B.11.2 local-name

- B.11.3 name

- B.11.4 namespace-uri

- B.11.5 position

- B.11.6 union

- B.12 文字列関数

- B.12.1 compare

- B.12.2 compare-ignore-case

- B.12.3 concat

- B.12.4 contains

- B.12.5 create-delimited-string

- B.12.6 ends-with

- B.12.7 format-string

- B.12.8 get-content-as-string

- B.12.9 get-localized-string

- B.12.10 index-within-string

- B.12.11 last-index-within-string

- B.12.12 left-trim

- B.12.13 lower-case

- B.12.14 matches

- B.12.15 normalize-space

- B.12.16 right-trim

- B.12.17 starts-with

- B.12.18 string-length

- B.12.19 substring

- B.12.20 substring-after

- B.12.21 substring-before

- B.12.22 translate

- B.12.23 upper-case

- B.13 ワークフロー・サービス関数

- B.13.1 clearTaskAssignees

- B.13.2 createWordMLDocument

- B.13.3 dynamicTaskAssign

- B.13.4 getNotificationProperty

- B.13.5 getNumberOfTaskApprovals

- B.13.6 getPreviousTaskApprover

- B.13.7 getTaskAttachmentByIndex

- B.13.8 getTaskAttachmentByName

- B.13.9 getTaskAttachmentContents

- B.13.10 getTaskAttachmentsCount

- B.13.11 getTaskResourceBundleString

- B.14 XREF関数

- B.14.1 lookupPopulatedColumns

- B.14.2 lookupXRef

- B.14.3 lookupXRef1M

- B.14.4 markForDelete

- B.14.5 populateLookupXRefRow

- B.14.6 populateXRefRow

- B.14.7 populateXRefRow1M

- B.15 Oracle JDeveloperの式ビルダーでのXPath式の構築

- B.15.1 式ビルダーの使用方法

- B.15.2 XPathビルディング・アシスタントの概要

- B.15.3 XPathビルディング・アシスタントの使用方法

- B.15.4 XSLTマッパーでのXPathビルディング・アシスタントの使用

- B.15.5 関数パラメータのツールのヒント

- B.15.6 構文検証およびセマンティック検証

- B.15.7 フリー・フォーム・テキストおよびXPath式を使用した式の作成

- B.15.8 Windows上でXPath関数でディレクトリ・パスにダブル・スラッシュを使用するとエラーが発生する可能性がある

- B.16 ユーザー定義XPath拡張関数の作成

- B.16.1 ユーザー定義XPath拡張関数の実装方法

- B.16.1.1 XSLTマッパーに対する関数の実装方法

- B.16.1.2 他のすべてのコンポーネントに対する関数の実装方法

- B.16.2 ユーザー定義XPath拡張関数の構成方法

- B.16.3 ユーザー定義関数のランタイムへのデプロイ方法

C デプロイメント・ディスクリプタのプロパティ

- C.1 デプロイメント・ディスクリプタのプロパティの概要

- C.1.1 プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法

- C.1.2 BPELプロセス内でのプリファレンス値の取得方法

D センサー・パブリック・ビューとセンサー・アクションXSDの理解

- D.1 センサー・パブリック・ビューとセンサー・アクションXSDファイルの概要

- D.2 センサー・パブリック・ビュー

- D.2.1 スキーマ

- D.2.1.1 BPEL_PROCESS_INSTANCES

- D.2.1.2 BPEL_ACTIVITY_SENSOR_VALUES

- D.2.1.3 BPEL_FAULT_SENSOR_VALUES

- D.2.1.4 BPEL_VARIABLE_SENSOR_VALUES

- D.3 センサー・アクションXSDファイル

E メッセージ・ヘッダーを介した正規化メッセージ・プロパティの伝播

- E.1 正規化されたメッセージの概要

- E.1.1 Oracle Web Services Addressingのプロパティ

- E.1.2 メッセージ・ヘッダー内で正規化メッセージ・プロパティを設定する方法

- E.2 bpelx拡張による正規化されたメッセージのプロパティの操作

- E.2.1 BPEL 2.0のbpelx拡張構文

- E.2.2 BPEL 1.1のbpelx拡張構文

F ルール・ディクショナリ・エディタのタスク・フローによって実装されるインタフェース

- F.1 MetadataDetailsインタフェース

- F.1.1 getDocumentメソッド

- F.1.2 getRelatedDocumentメソッド

- F.1.3 setDocumentメソッド

- F.2 NLSPreferencesインタフェース

G Oracle SOA Suite構成プロパティのロード・マップ

- G.1 Oracle BPEL Process Managerデプロイメント・ディスクリプタのプロパティ

- G.2 正規化されたメッセージ・ヘッダー・プロパティ

- G.2.1 Oracle JCAアダプタのメッセージ・ヘッダー・プロパティ

- G.2.2 Oracle BPEL Process ManagerおよびOracle Web Services Addressingのメッセージ・ヘッダー・プロパティ

- G.2.3 Oracle B2Bのメッセージ・ヘッダー・プロパティ

- G.3 SOAコンポジット・アプリケーションのプロパティ

- G.4 フォルト・ポリシーとアダプタ拒否メッセージのプロパティ

- G.5 Oracle B2Bのシステム・プロパティ

- G.6 Oracle Healthcareのプロパティ

- G.7 Oracle Business Activity Monitoringのプロパティ

- G.8 Oracle Enterprise Manager Fusion Middleware Controlのプロパティ・ページ

- G.8.1 SOAインフラストラクチャのプロパティ

- G.8.2 Oracle BPEL Process Managerのプロパティ

- G.8.3 ヒューマン・ワークフロー通知とタスク・サービスのプロパティ

- G.8.4 Oracle Mediatorのプロパティ

- G.8.5 相互参照プロパティ

- G.8.6 Oracle B2Bのプロパティ

- G.8.7 サービス・バインディング・コンポーネントと参照バインディング・コンポーネントのプロパティ

- G.8.8 グローバル・トークン変数と自動データベース・パージのプロパティ

- G.9 システムMBeanブラウザの拡張プロパティ

- G.9.1 SOAインフラストラクチャの拡張プロパティ

- G.9.2 Oracle BPEL Process Managerの拡張プロパティ

- G.9.3 Oracle Mediatorの拡張プロパティ

- G.9.4 ヒューマン・ワークフロー通知とタスク・サービスの拡張プロパティ

- G.9.5 Oracle B2Bの拡張プロパティ

H XSLTエディタでの大規模なスキーマの操作

- H.1 スパース・マッピング

- H.1.1 XSLTビューのクイック・スタート

- H.2 非スパース・マッピング

- H.3 テキストの見にくさの低減

- H.4 ツリーの検索

- H.5 大規模な入力ドキュメントのコピーと変更

- H.6 要素置換およびタイプ置換を使用したテスト・ファイルの生成

はじめに

このマニュアルでは、Oracle SOA Suiteの使用方法を説明します。

「はじめに」の内容は次のとおりです。

- 対象読者

- 関連ドキュメント

- 表記規則

対象読者

このマニュアルは、Oracle SOA Suiteを使用してアプリケーションを開発するすべてのユーザーを対象としています。

関連ドキュメント

詳細は、次のOracleドキュメントを参照してください。

- Oracle B2Bユーザーズ・ガイド

- Oracle SOA Suite Healthcare Integrationユーザーズ・ガイド

- Oracle BAMを使用したビジネス・アクティビティのモニタリング

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

- Oracle Business Process Managementを使用したビジネス・ルールの設計

- Oracle Business Process Management Rulesランゲージ・リファレンス

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

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

- Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド

- 高可用性ガイド

- WebLogic Server WLSTコマンド・リファレンス

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

ここでは、Oracle SOA Suiteの新機能と変更された機能、およびこのガイドに記載されているその他の重要な変更について説明し、追加情報の参照先も記載しています。このドキュメントは、以前『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』と呼ばれていたドキュメントの新版です。

既知の問題のリスト(リリース・ノート)は、http://www.oracle.com/technetwork/middleware/docs/soa-aiafp-knownissuesindex-364630.htmlを参照してください。

12c (12.2.1)の新機能と変更された機能

Oracle SOA Suite 12c (12.2.1)では、次の新開発機能および変更された開発機能を含めるためこのガイドが更新されています。

注意:

このガイドで示される画面は実装状態と多少異なる場合があります。相違点は軽微なものです。

- 実行中のコンポジット・インスタンスへのパッチ適用のサポート。「SOAコンポジットの実行中のインスタンスへのパッチ適用」を参照してください

- メモリー内SOAのサポート。「システム・パフォーマンスの向上のためのメモリー内SOAの使用」を参照してください

- XSLTマップのデバッグのサポートおよび条件付きデバッグのサポート。「XSLTマップのデバッグ」を参照してください

- エンドツーエンドのJSONおよびJavaScriptのサポート。「REST操作とSOAコンポジット・アプリケーションとの統合」を参照してください

第I部 Oracle SOA Suiteスタート・ガイド

この部では、Oracle SOA Suiteの概要と、SOAコンポジット・アプリケーションの開発について説明します。

この部は、次の章で構成されています。

- Oracle SOA Suiteを使用したアプリケーション作成の概要

- SOAコンポジット・アプリケーションの開発のスタート・ガイド

- デザインタイムMDSリポジトリとの共有データの管理

1 Oracle SOA Suiteを使用したアプリケーション作成の概要

この章では、サービス指向アーキテクチャ(SOA)とOracle SOA Suite、SOAを有効にするためにOracle SOA Suiteで使用する標準、SOAコンポジット・アプリケーションのアーキテクチャと実行時の動作、SOAコンポジット・アプリケーション設計へのアプローチおよびOracle SOA Suiteの詳細の参照先について説明します。

この章の内容は次のとおりです。

- Oracle SOA Suiteの概要

- Oracle SOA Suiteスタート・ガイド

- アクセシビリティ・オプションの設定

1.1 Oracle SOA Suiteの概要

この章では、サービス指向アーキテクチャおよび標準の概要、Oracle SOA Suiteの機能、サービス・コンポーネントのアーキテクチャ、実行時の動作および設計時のアプローチについて説明します。

1.1.1 サービス指向アーキテクチャ

市場の変化、競争の激化、顧客ニーズの推移によって、ITにはこれまで以上の柔軟性とスピードが求められています。現在、すべての企業はグローバルなビジネス環境における変化を予測し、競合他社にすばやく対応し、成長のために自社の資産を最大限に活用する必要性に迫られています。このような課題に対し、先進企業では、アプリケーションやIT環境の複雑さを克服し、これらの要求に応える手段としてサービス指向アーキテクチャ(SOA)を採用しています。

SOAは、ビジネス上の問題に対するソリューションを提供するために、エンタープライズ・アプリケーション統合の構築をサポートするエンタープライズ・アーキテクチャを提供します。SOAは、統合と再利用が容易で、柔軟かつ順応性のあるITインフラストラクチャを作成するモジュール型ビジネスのWebサービスとして、エンタープライズ・アプリケーションの開発を促進します。

1.1.2 サービス

SOAでは、ビジネス機能を個別の単位、つまりサービスに分割します。SOAアプリケーションでは、サービスを再利用してビジネス・プロセスを自動化します。

サービスは標準インタフェースとメッセージ構造によって定義されます。最も広く使用されているメカニズムはWebサービス用の標準です。この標準には、サービス・インタフェース定義用のWeb Services Description Language (WSDL)ファイル、およびメッセージ構造定義用のXMLスキーマ・ドキュメント(XSD)が含まれます。これらのXML標準は、標準プロトコルを使用して容易に変換されます。Webサービス用の標準は標準ドキュメント構造を使用しているため、サービス実装で使用するオペレーティング・システムやコンピュータ言語に関係なく、既存のシステム間の相互運用が可能になります。

SOAアプローチを設計するときは、サービス・ポートフォリオ・プランを作成して、ビジネス・プロセスでサービスとして使用する共通機能を識別します。プランを作成して管理することにより、可能な場合は常に、既存のサービスやアプリケーションを再利用したり別の目的用に再定義できます。また、このプランにより、アプリケーションに必要な機能を作成する時間を削減できます。

1.1.3 Oracle SOA Suite

Oracle SOA Suiteには、コンポジット・アプリケーションを設計、デプロイおよび管理するためのサービス・インフラストラクチャ・コンポーネントの完全なセットが用意されています。Oracle SOA Suiteにより、サービスの作成と管理を行って、複合アプリケーションとビジネス・プロセスに編成できます。コンポジットを使用すれば、複数のテクノロジ・コンポーネントを組み合せて1つのSOAコンポジット・アプリケーションを簡単に作成できます。Oracle SOA Suiteは異種ITインフラストラクチャに組み込まれ、企業によるSOAの段階的な採用を可能にします。

Oracle SOA Suiteの各コンポーネントは、単一のデプロイメント、管理、ツール・モデル、エンドツーエンドのセキュリティ、統一メタデータ管理などの共通機能を利用しています。Oracle SOA Suiteの優れている点は、次のような統合された機能セットが備わっていることです。

- メッセージング

- サービスの検出

- 編成

- Webサービスの管理とセキュリティ

- ビジネス・ルール

- 人との対話

- イベント・フレームワーク

- ビジネス・アクティビティ・モニタリング

1.1.4 SOAを有効にするためにOracle SOA Suiteで使用する標準

Oracle SOA Suiteでは、標準および相互運用性を特に重要視しています。次の標準が使用されています。

- サービス・コンポーネント・アーキテクチャ(SCA)アセンブリ・モデル
サービス詳細と相互運用性を提供し、コンポジット・アプリケーションを形成します。SCAにより、ビジネス・ロジックを、すべてのSCA準拠アプリケーションに容易に統合できる再利用可能なサービス・コンポーネントとして表現できます。その結果、アプリケーションはSOAコンポジット・アプリケーションになります。SCA標準の仕様は、オープン複合サービス・アーキテクチャ(CSA)会員セクションを介して、Organization for the Advancement of Structured Information Standards (OASIS)によって管理されています。

http://www.oasis-opencsa.org

- サービス・データ・オブジェクト(SDO)
標準データ・メソッドを指定することで、物理的にどのようにアクセスされているかに関係なくビジネス・データを修正できます。SOAコンポジット・アプリケーションでSDOを使用する場合、特定のバックエンド・データ・ソースへのアクセス方法についての知識は不要です。つまり、静的または動的なプログラミング・スタイルを使用して、接続および切断されたアクセスを取得できます。

- Business Process Execution Language(BPEL)
ビジネス・プロセス・オーケストレーションと実行に関する業界標準を企業に提供します。BPELを使用すると、独立した一連のサービスをエンドツーエンドのプロセス・フローに統合するビジネス・プロセスを設計できます。この統合により、プロセスのコストと複雑さが低減されます。BPELバージョン1.1および2.0がサポートされています。

- XSLトランスフォーメーション(XSLT)
XML文書を処理し、文書データを、あるXMLスキーマから他のスキーマに変換します。

- XQueryトランスフォーメーション(XQuery)
構造化と非構造化のデータにおける問合せと変換のコレクションで、一般的にXMLの形式です。

- Java Connector Architecture(JCA)
エンタープライズ情報システム(EIS)での多数のアプリケーション・サーバー間にある接続性の問題に対して、Javaテクノロジ・ソリューションを提供します。

- Java Message Service
Java 2 Platform Enterprise Edition (Java EE)に基づいたアプリケーション・コンポーネントによって、異種システム間で分散されているビジネス・ロジックにアクセスできるメッセージング標準を提供します。

- Web Service Definition Language (WSDL)ファイル
SOAコンポジット・アプリケーションへのエントリ・ポイントを提供します。WSDLファイルは標準規約言語を提供するもので、サービスの機能を理解する場合に必須です。

- Simple Object Access Protocol
メッセージ配信に対するデフォルトのネットワーク・プロトコルを提供します。

- Representational State Transfer (REST)
ネットワーク・アプリケーションを設計するためのアーキテクチャが用意されています。RESTfulアプリケーションでは、HTTPリクエストを使用してデータのポスト(作成および更新)、データの取得(問合せの作成など)およびデータの削除を行います。RESTは、Webサービスを使用するかわりの方法となります。

- JavaScript Object Notation(JSON)
オブジェクトと呼ばれる連想配列と単純なデータ構造を表現するための言語が用意されています。JSONは、人間が判読可能なデータの交換を行うために設計された標準です。JSONはJavaScriptスクリプト言語から派生しています。

- Webアプリケーション記述言語(WADL)
HTTPベースWebアプリケーション(一般的にREST Webサービス)の可読なXML説明が用意されています。WADLにより、Webの既存HTTPアーキテクチャに基づいて、Webサービスの再利用が単純になります。

1.1.5 SOAコンポジット・アプリケーション内のサービス・コンポーネント・アーキテクチャ

Oracle SOA Suiteでは、SCA標準を使用して複数のサービス・コンポーネントを1つのSOAコンポジット・アプリケーションに組み立てます。SCAは、次のプログラミング・モデルを提供します。

- Java、C++などのプログラミング言語やXSLTなどの宣言的な言語を含む各種のテクノロジを使用して記述されたサービス・コンポーネントを作成します。SCAでは、特定のプログラミング言語やテクノロジ(Webサービスを含む)を使用する必要はありません。

- 複数のサービス・コンポーネントを1つのSOAコンポジット・アプリケーションに組み立てます。SCA環境では、サービス・コンポーネントはアプリケーションのビルディング・ブロックです。

SCAでは、サービス・コンポーネントの分散グループをアプリケーションにまとめるためのモデルを提供することにより、サービスの詳細、サービスとサービス・コンポーネントの相互作用方法を記述できます。コンポジットはサービス・コンポーネントをグループ化するのに使用され、ワイヤはサービス・コンポーネントを接続するのに使用されます。SCAの目的は、セキュリティおよびトランザクションを含むコンポジットにインフラストラクチャを宣言的に適用することにより、ミドルウェアの問題をプログラミング・コードから除去することです。

SCAには、主に次の利点があります。

- 疎結合
サービス・コンポーネントは、他のサービス・コンポーネントがどのように構築されているかを考慮することなく、他のサービス・コンポーネントと統合できます。

- 柔軟性
サービス・コンポーネントは、他のサービス・コンポーネントと簡単に交換できます。

- サービス起動
サービスは、同期的または非同期的に起動できます。

- 生産性
サービス・コンポーネントを簡単に統合し、SOAコンポジット・アプリケーションを作成します。

- 簡単なメンテナンスとデバッグ
サービス・コンポーネントは、問題が発生しても簡単に保守やデバッグを実行できます。

SOAコンポジットは複数のサービス、サービス・コンポーネントおよび参照の集合で、単一のアプリケーション内で設計されデプロイされます。サービス、サービス・コンポーネントおよび参照間でのワイヤリングにより、メッセージ通信が可能になります。コンポジットの詳細は、composite.xmlファイルに格納されています。

図1-1 はコンポジットの例を示しています。このコンポジットには、インバウンド・サービス・バインディング・コンポーネント、BPELプロセス・サービス・コンポーネント(Account)、ビジネス・ルール・サービス・コンポーネント(AccountRule)および2つのアウトバウンド参照バインディング・コンポーネントが含まれています。

図1-1 単純なSOAコンポジット・アーキテクチャ

1.1.5.1 サービス・コンポーネント

サービス・コンポーネントは、SOAコンポジット・アプリケーションの構築に使用するビルディング・ブロックです。

次のサービス・コンポーネントを使用できます。各サービス・コンポーネントに対して同じ名前の対応するサービス・エンジンがあります。すべてのサービス・エンジンは、単一のコンポジットでの相互作用が可能です。

- BPELプロセスにより、プロセス・オーケストレーションおよび同期または非同期プロセスの保存ができます。一連のビジネス・アクティビティとサービスをエンドツーエンドのプロセス・フローに統合するビジネス・プロセスを設計します。

- ビジネス・ルールにより、ルールに基づいたビジネス上の意思決定を設計できます。

- ヒューマン・タスクにより、ユーザーまたはグループが、エンドツーエンドのビジネス・プロセス・フローの一環として実行するタスクを記述するワークフローのモデリングが提供されます。

- メディエータは、異なるコンポーネント間でイベント(メッセージ)をルーティングするために使用します。

- Springにより、JavaインタフェースをSOAコンポジット・アプリケーションに統合できます。

サービス・コンポーネントの詳細は、「サービス・コンポーネントの追加」を参照してください。

1.1.5.2 バインディング・コンポーネント

バインディング・コンポーネントは、SOAコンポジットと外部との接続を確立します。バインディング・コンポーネントには、次の2種類があります。

- サービス
サービスは、外部の世界に対して、SOAコンポジット・アプリケーションへのエントリ・ポイントを提供します。サービスのWSDLファイルによって、そのサービスの機能が外部のアプリケーションに通知されます。これらの機能は、SOAコンポジット・アプリケーション・コンポーネントとの接続に使用されます。サービスのバインディング接続性には、サービス(SOAP/HTTPやJCAアダプタなど)と通信できるプロトコルが記述されています。

- 参照
参照は、SOAコンポジット・アプリケーションから外部にある外部サービスに送信するメッセージを有効にします。

表1-1 では、Oracle SOA Suiteで提供されるバインディング・コンポーネントをリストして説明します。

表1-1 Oracle SOA Suiteで提供されるバインディング・コンポーネント

バインディング・コンポーネント

説明

Webサービス(SOAP over HTTP)

SOAP over HTTPを使用した標準ベース・サービスへの接続に使用します。

JCAアダプタ

テクノロジ(データベース、ファイル・システム、FTPサーバー、メッセージング、JMS、IBM WebSphere MQ、Oracle User Messaging Service、LDAPサーバー、Oracle Coherenceキャッシュなど)およびアプリケーション(Oracle E-Business Suite、PeopleSoftなど)への、サービスと参照の統合に使用します。

これには、AQアダプタ、データベース・アダプタ、ファイル・アダプタ、FTPアダプタ、JMSアダプタ、MQアダプタ、ソケット・アダプタ、Oracle User Messaging Serviceアダプタ、LDAPアダプタ、Oracle Coherenceアダプタおよびサード・パーティ・アダプタが含まれます。

Oracle B2B

Oracle Metadata Servicesリポジトリ(MDSリポジトリ)でのB2Bメタデータの参照とドキュメント定義の選択に使用します。

Oracle Healthcare

ヘルスケア・システムとの間でメッセージを送受信するために使用します。

ADF-BCサービス

SOAプラットフォームがあるSDOを使用したOracle Application Development Framework (ADF)アプリケーションへの接続に使用します。

Oracle E-Business Suite

OracleアプリケーションへのOracle E-Business Suiteアダプタの統合に使用します。

BAM 11gアダプタ

Java EEアプリケーションをOracle BAMgサーバーに統合してデータを送るために使用し、また、SOAコンポジット・アプリケーションにおいて参照バインディング・コンポーネントとしても使用します。

注意: このアダプタはOracle BAM 11gサーバーにのみ接続できます。

EJBサービス

Enterprise JavaBeansへのSDOパラメータまたはJavaインタフェースの統合に使用します。

直接バインディング・サービス

インバウンド方向では、SOAコンポジット・アプリケーションの起動、およびRemote Method Invocation (RMI)を介したメッセージの交換に使用します。アウトバウンド方向では、Oracle Service Bus (OSB)フローまたは別のSOAコンポジット・アプリケーションの起動に使用します。

HTTPバインディング

HTTPバインディングへのSOAコンポジット・アプリケーションの統合に使用します。

RESTサービス

SOAコンポジット・アプリケーションのRESTサービスとREST対応SOAコンポジット・アプリケーションの統合に使用します。

Oracle Managed File Transfer (MFT)

多くのエンドポイント・タイプ(リモートや組込みのFTPサーバーやsFTPサーバー、ディレクトリ、SOAP Webサービス、Oracle SOA Suite、Oracle Service Bus、Oracle B2B、Oracle Healthcare、Oracle Data Integratorエンドポイントなど)におけるファイル転送に使用します。

クラウド・アダプタ

クラウド・アダプタにより、クラウド・サーバーとメッセージの送受信ができます。

バインディング・コンポーネントの詳細は、「サービス・バインディング・コンポーネントの追加」および「参照バインディング・コンポーネントの追加」を参照してください。

1.1.5.3 ワイヤ

ワイヤを使用すると、メッセージ通信のために、次のコンポーネントを単一のSOAコンポジット・アプリケーションでグラフィカルに接続できます。

- サービス・コンポーネントに対するサービス

- 他のサービス・コンポーネントに対するサービス・コンポーネント

- 参照に対するサービス・コンポーネント

ワイヤの詳細は、「ワイヤの追加」を参照してください。

1.1.6 SOAコンポジット・アプリケーションの実行時の動作

図1-2 は、SCAテクノロジを使用したSOAコンポジット・アプリケーションの操作性を示しています。この例では、外部アプリケーション(..NET支払計算)がSOAコンポジット・アプリケーションとの接続を開始しています。

サービス、参照、サービス・コンポーネントおよびワイヤがアプリケーション内で実行するタスクの詳細は、「SOAコンポジット・アプリケーション内のサービス・コンポーネント・アーキテクチャ」を参照してください。

図1-2 SOAコンポジット・アプリケーションの実行時の動作

.NET支払計算は外部アプリケーションで、SOAPメッセージをSOAアプリケーションに送信して接続を開始します。サービス・インフラストラクチャは、バインディング・コンポーネントからSOAPメッセージを受信し、対象のコンポーネント・ターゲットを判断します。BPELプロセス・サービス・エンジンは、BPEL融資プロセス・アプリケーションが処理するメッセージをサービス・インフラストラクチャから受信し、処理が完了すると、そのサービス・インフラストラクチャに転送します。

表1-2 は、図1-2 に示すSOAコンポジット・アプリケーションの操作性を説明しています。

表1-2 SCAテクノロジを使用したSOAコンポジット・アプリケーションの概要

部分

説明

図%s 2での使用例

関連項目

バインディング・コンポーネント

SOAコンポジットと外部との接続を確立します。このロールには2つのタイプがあります。

- サービス・バインディング・コンポーネントは、SOAコンポジット・アプリケーションへのエントリ・ポイントを提供します。

- 参照バインディング・コンポーネントは、SOAコンポジット・アプリケーションから外部サービスへのメッセージの送信を可能にします。

SOAPバインディング・コンポーネント・サービスは、次のことを行います。

- WSDLファイルでその機能を通知します。

- .NETアプリケーションからSOAPメッセージを受信します。

- セキュリティ・チェックのために、ポリシー・インフラストラクチャを通じてメッセージを送信します。

- メッセージを正規化されたメッセージ(XMLフォーマットでのサービスのWSDL規約の内部表現)に変換します。

- メッセージをサービス・インフラストラクチャに転送します。

図1-2 の参照バインディング・コンポーネントの例は、融資プロセス・アプリケーションです。

サービス・コンポーネント

サービス・インフラストラクチャ

内部メッセージ・トランスポートを提供します。

サービス・インフラストラクチャ:

- SOAPサービス・バインディング・コンポーネントからメッセージを受信します。

- 処理するメッセージを、最初にBPELプロセス・サービス・エンジンに転送し、次にヒューマン・タスク・サービス・エンジンに転送します。

サービス・インフラストラクチャ

サービス・エンジン(サービス・コンポーネントをホストするコンテナ)

サービス・コンポーネントのビジネス・ロジックまたは処理ルールをホストします。各サービス・コンポーネントには固有のサービス・エンジンがあります。

BPELプロセス・サービス・エンジン:

- BPEL融資プロセス・アプリケーションが処理するメッセージをサービス・インフラストラクチャから受信します。

- 処理が完了するとメッセージをサービス・インフラストラクチャに転送します。

サービス・エンジン

Universal Description, Discovery, and Integration (UDDI)およびMDS

MDSリポジトリには、使用可能なサービスの説明が保存されます。UDDIでは、これらのサービスが通知され、実行時における検出と動的バインディングを可能にします。

このコンポジット・アプリケーションで使用されるSOAPサービスは、MDSリポジトリに保存され、またUDDIに対して公開できます。

olink:SOAGSデザインタイムMDSリポジトリとの共有データの管理

SOAアーカイブ・コンポジット

(デプロイメント・ユニット)

コンポジット・アプリケーションを記述するデプロイメント・ユニット。

コンポジット・アプリケーションのSOAアーカイブ(SAR)はサービス・インフラストラクチャにデプロイされます。

デプロイ済サービス・アーカイブ

1.1.6.1 サービス・インフラストラクチャ

サービス・インフラストラクチャは、次の内部メッセージ・ルーティング・インフラストラクチャ機能を提供して、コンポーネントを接続し、データ・フローを有効にします。

- SOAPサービスやアダプタを介して、サービス・プロバイダや外部パートナからメッセージを受信します。

- メッセージを適切なサービス・エンジンに送信します。

- サービス・エンジンから受信したメッセージを、ワイヤリングに基づいて、コンポジットの追加サービス・エンジンまたは参照バインディング・コンポーネントに送信します。

1.1.6.2 サービス・エンジン

サービス・エンジンは、サービス・コンポーネントのビジネス・ロジックや処理ルールをホストするコンテナです。サービス・エンジンはサービス・インフラストラクチャから受信したメッセージ情報を処理します。

各サービス・コンポーネントに対して同じ名前の対応するサービス・エンジンがあります。すべてのサービス・エンジンは、単一のコンポジットでの相互作用が可能です。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

1.1.6.3 デプロイ済サービス・アーカイブ

SARは、SOAアーカイブ・デプロイメント・ユニットです。SARファイルは、接頭辞sca_が必要な特別なJARファイルです (例: sca_OrderBookingComposite_rev1.0.jar)。SARファイルは、サービス・インフラストラクチャにデプロイされます。SARは、BPELプロセス、ビジネス・ルール、ヒューマン・タスクおよびOracle Mediatorルーティング・サービスなどのサービス・コンポーネントを単一のアプリケーションにパッケージ化します。SARファイルは、以前のリリースのBPELスーツケース・アーカイブと類似していますが、上位のコンポジット・レベルで対応し、アプリケーションに含まれる追加サービス・コンポーネント(ヒューマン・タスク、ビジネス・ルールおよびOracle Mediatorルーティング・サービスなど)があります。

詳細は、「SOAコンポジット・アプリケーションのデプロイ」を参照してください。

1.1.7 SOAコンポジット・アプリケーション設計のアプローチ

SOAコンポジット・アプリケーションを作成する際は、次のいずれかのアプローチを選択できます。

- トップダウン: ビジネス・プロセスを分析し、プロセスをサポートするアクティビティを識別します。コンポジットを作成するときに、を使用してすべてのSOAコンポーネントを定義します。すべてのサービスを最初に作成し、次に、作成したサービスを参照するBPELプロセスを作成します。

- ボトムアップ: 既存のアプリケーションとアセットを分析し、サービスとして使用可能かどうかを識別します。BPELプロセスを作成するときに、必要に応じてサービスを作成します。この方法は、ITが変更に応じる必要がある場合に有効です。

1.2 Oracle SOA Suiteスタート・ガイド

この開発者ガイドは、表1-3 で説明する各項で構成されています。この表の各項を使用して、SOAコンポジット・アプリケーションの開発を開始できます。

表1-3 Oracle SOA Suiteの開始

開始する作業

参照先

コンポジット、サービスおよび参照バインディング・コンポーネントの基本的な手順と、Oracle JDeveloperでのサービス・コンポーネントの作成

SOAコンポジット・アプリケーションの開発のスタート・ガイド

SOAデザインタイムOracle Metadata Servicesリポジトリ(MDSリポジトリ)との共有データの使用

デザインタイムMDSリポジトリとの共有データの管理

コンポジットでのBPELプロセス・サービス・コンポーネントの設計

BPELプロセス・サービス・コンポーネントの使用

コンポジットでのOracle Mediatorサービス・コンポーネントの設計

Oracle Mediatorサービス・コンポーネントの使用

コンポジットでのビジネス・ルール・サービス・コンポーネントの設計

ビジネス・ルール・サービス・コンポーネントの使用

コンポジットでのヒューマン・ワークフロー・サービス・コンポーネントの設計

ヒューマン・ワークフロー・サービス・コンポーネントの使用

コンポジットでのサービス・バインディング・コンポーネントおよび参照バインディング・コンポーネントの設計

バインディング・コンポーネントの使用

テンプレート、XSLT変換およびXQuery変換、ビジネス・イベント、相互参照、ドメイン値マップなどのコンポーネント間で共有可能な機能

サービス・コンポーネント間の共有機能

セキュリティ・ポリシー・アタッチメント、デプロイメント、デバッグ、コンポジットのテストの自動化などのコンポジット・タスクの完成

アプリケーションの完成

大量のドキュメントや大量のインスタンス、コンポジットのカスタマイズ、コンポジット・センサー、Spring Frameworkの管理などの高度なトピック

高度なトピック

この開発者ガイドに加え、次のような追加のリソースが用意されています。

- Oracle SOA Suiteサンプルでは、Oracle SOA Suiteとそのコンポーネントについて、様々なユースケースのサンプルへのアクセスを提供しています。

- 『Oracle SOA Suiteの理解』では、企業が直面するビジネスにおける課題や、Oracle SOA Suiteによる設計時から実行時に至るまでのこれらの課題への対処方法について説明しています。

1.3 アクセシビリティ・オプションの設定

Oracle SOA Suiteでは、アプリケーションの開発にOracle JDeveloperとOracle SOAコンポーザの両方を使用します。この項では、両方の環境でのアクセシビリティ・オプションについて説明します。

1.3.1 Oracle JDeveloperでのアクセシビリティ・オプションの設定

Oracle JDeveloperでは、スクリーン・リーダー、拡大表示、キーボード・ナビゲーションのための標準的なショートカット・キーのサポートなどのアクセシビリティ・オプションが提供されています。フォントのサイズや色、オブジェクトの色や形など、さらに読みやすくするためにOracle JDeveloperをカスタマイズすることもできます。Oracle JDeveloperのアクセシビリティの構成の詳細は、Oracle JDeveloperによるアプリケーションの開発のOracle JDeveloperのアクセシビリティ情報に関する項を参照してください。

1.3.2 Oracle SOAコンポーザおよびOracle BPM Worklistでのアクセシビリティ・オプションの設定

アクセシビリティ設定は、アプリケーションのすべてのコンポーネントを読むのに役立ちます。Oracle SOAコンポーザまたはOracle BPM Worklistの現在のインスタンスまたはすべてのインスタンスに対してアクセシビリティ・オプションを設定できます。

1.3.2.1 ログイン前にアクセシビリティ機能を設定する方法

Oracle SOAコンポーザまたはOracle BPM Worklistには、ログイン・ページに「アクセシビリティ」メニューがあるので、ログインの前にアクセシビリティを構成できます。これらの設定は、現在のセッションのみ、またはすべてのセッションに対して保持できます。

ログイン前にアクセシビリティ・オプションを設定するには、次の手順を実行します。

1. Oracle SOAコンポーザまたはOracle BPM Worklistを起動します。

2. ログイン・ページで、右上隅の「アクセシビリティ」をクリックします。

図1-3 に示すように、「アクセシビリティ設定の編集」ページが表示されます。

図1-3 「アクセシビリティ設定の編集」ページ

3. 次のオプションを選択します。

- スクリーン・リーダーの使用。

- 高コントラスト色の使用

- 大きいフォントの使用。

4. このセッションに対してのみ新しい設定を保存するには、「このセッションで使用」をクリックします。すべてのセッションに対して設定を保存するには、「プリファレンスとして保存して使用」をクリックします。

1.3.2.2 ログイン後にアクセシビリティ・オプションを設定する方法

Oracle SOAコンポーザまたはOracle BPM Worklistにログインした後は、任意のページからアクセシビリティ・オプションを構成できます。これにより、ユーザー・プリファレンスが変更されます。これらは再度変更されるまで、すべてのセッションで保持されます。

ログイン後にアクセシビリティ・オプションを設定する手順は次のとおりです。

1. Oracle SOAコンポーザまたはOracle BPM Worklistを起動してログインします。

2. 任意のページから、右上隅の「プリファレンス」を選択します。

「プリファレンス」ダイアログが表示されます。

3. 「プリファレンス」列で、「アクセシビリティ」をクリックします。

図1-4 に示すように、「アクセシビリティ・プリファレンス」が表示されます。

図1-4 「プリファレンス」ダイアログ

4. スクリーン・リーダーを使用する場合は、「モード設定」フィールドで、「スクリーン・リーダー・モードの有効化」を選択します。スクリーン・リーダーを使用しない場合、「スクリーン・リーダー・モードの無効化」を選択します。

5. 「コントラスト設定」フィールドで、コンソール上のオブジェクト間のコントラストを強めるには、「高コントラストの使用」を選択し、そのようにしない場合は「通常のコントラストの使用」を選択します。

6. 「フォント設定」フィールドで、フォント・サイズを大きくする場合は「大きいフォントの使用」を選択し、それ以外の場合は「通常フォントの使用」を選択します。

7. 「OK」をクリックします。

2 SOAコンポジット・アプリケーションの開発のスタート・ガイド

この章では、Oracle JDeveloperを使用してSOAコンポジット・アプリケーションを作成する方法について説明します。ここでは、コンポジット、サービス・バインディング・コンポーネント、参照バインディング・コンポーネント、サービス・コンポーネントの作成と、セキュリティ、デプロイメントおよびテストの基本的な手順を、SOAコンポジット・アプリケーションの設計時に考慮が必要な重要な問題とともに説明します。

この章の内容は次のとおりです。

- SOAアプリケーションの作成

- サービス・コンポーネントの追加

- 「サービス・バインディング・コンポーネントの追加」

- 参照バインディング・コンポーネントの追加

- ワイヤの追加

- SOAコンポジット・アプリケーションへの説明の追加

- コンポーネントとアーティファクトの名前変更、削除および移動

- プロパティ・インスペクタにおけるコンポーネント詳細の表示

- セキュリティ・ポリシーの追加

- SOAコンポジット・アプリケーションのデプロイ

- SOAコンポジット・アプリケーションの管理とテスト

2.1 SOAアプリケーションの作成

新しいアプリケーションの構築での最初の手順は、そのアプリケーションへの名前の割当てとソース・ファイルを保存するディレクトリの指定です。Oracle SOA Suiteのクイック・スタートをインストールすると、Oracle SOA Suite拡張機能がOracle JDeveloperに自動的にインストールされます。この点が、Oracle SOA Suite拡張機能を手動でOracle JDeveloperにインポートした以前のリリースとは異なります。Oracle SOA Suiteのクイック・スタートのインストールの詳細は、『SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』を参照してください。

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

最初にSOAプロジェクト用のアプリケーションを作成します。

SOAアプリケーションおよびプロジェクトを作成する手順は、次のとおりです。

1. Oracle JDeveloper Studio Editionを起動します。

2. Oracle JDeveloperを初めて実行する場合は、Java JDKの場所およびOracle JDeveloperを実行するユーザー・ロールを指定します。JDKのバージョンは、1.7.0_15以上である必要があります。

3. 表2-1 の説明に従って、SOAコンポジット・アプリケーションを作成します。

表2-1 SOAコンポジット・アプリケーションの作成

Oracle JDeveloperの状態

結果

アプリケーションがない

たとえばOracle JDeveloperを初めて開いている場合。

左上にある「アプリケーション」ウィンドウで、「新規アプリケーション」をクリックします。

既存のアプリケーションがある。

「ファイル」メイン・メニューから次の手順を実行します。

a. 「新規」→「アプリケーション」を選択します。
別のアプリケーション・コンポジットの作成を選択できる「新規ギャラリ」が開きます。

b. 「カテゴリ」ツリーで、「全般」→「アプリケーション」を選択します。

c. 「項目」ペインで「SOAアプリケーション」を選択し、「OK」をクリックします。

「アプリケーション」メイン・メニューから次の手順を実行します。

a. 「新規」を選択します。
別のアプリケーション・コンポジットの作成を選択できる「新規ギャラリ」が開きます。

b. 「カテゴリ」ツリーで、「全般」→「アプリケーション」を選択します。

c. 「項目」ペインで「SOAアプリケーション」を選択し、「OK」をクリックします。

「アプリケーション」ウィンドウの「アプリケーション」メニューから次の手順を実行します。

a. 左上にある「アプリケーション」ウィンドウで、「アプリケーション」ドロップダウン・リストから「新規アプリケーション」を選択します。

SOAアプリケーションの作成ウィザードが表示されます。

4. 「アプリケーションの名前付け」ページで、必要に応じて、アプリケーションの名前と場所を変更できます。このアプリケーションが最初のアプリケーションである場合は、「アプリケーション・テンプレート」から「SOAアプリケーション」を選択します。パッケージ接頭辞のデフォルトをそのまま使用して、「次」をクリックします。

注意:

次のアプリケーション命名規則に注意してください。

- 空白を使用したアプリケーション名は作成できません。

- 空白があるディレクトリ・パスにアプリケーションおよびプロジェクトを作成することはできません(例: c:\Program Files)。

- UNIXオペレーティング・システムでは、LANGおよびLC_All環境変数をUTF-8キャラクタ・セットを使用するロケールに設定して、Unicodeサポートを有効にすることをお薦めします。この設定により、オペレーティング・システムではあらゆる文字をUnicodeで処理できるようになります。SOAテクノロジはUnicodeに基づいています。オペレーティング・システムがUTF-8以外のエンコーディングを使用するように構成されている場合は、SOAコンポーネントが想定とは異なって機能する可能性があります。たとえば、ファイル名がASCIIでない場合は、ファイルにアクセスできず、エラーが発生する可能性があります。オペレーティング・システムの制約によって発生する問題はサポート対象外となります。
設計時環境でOracle JDeveloperを使用している場合は、「ツール」→「プリファレンス」→「環境」→「エンコーディング」→「UTF-8」の順に選択して、Unicodeのサポートを有効にします。この設定は、実行時の環境にも適用可能です。

5. 「プロジェクトの名前付け」ページで、必要に応じて、SOAプロジェクトの名前と場所を変更できます。デフォルトでは、Oracle JDeveloperによって、モデル・プロジェクトに、SOAプロジェクト・テクノロジ、SOAコンポジット・アプリケーションを記述するcomposite.xmlファイル、および必須ライブラリが追加されます。

6. 「次へ」をクリックします。

注意:

コンポジット名およびコンポーネント名は、500文字以下にする必要があります。

同じインフラストラクチャにデプロイされるプロジェクトは、SOAコンポジット・アプリケーション全体で一意の名前である必要があります。コンポジットの一意性はプロジェクト名で判断されます。たとえば、表2-2 に記載されている操作は実行しないでください。デプロイ時に、2番目にデプロイされたプロジェクト(コンポジット)で最初にデプロイされたプロジェクト(コンポジット)が上書きされます。

表2-2 SOAプロジェクトの名前付けに関する制限

作成するアプリケーションの名前

作成するSOAプロジェクト名

Application1

Project1

Application2

Project1

SOAアプリケーションの作成ウィザードのプロジェクトSOA設定ページが表示されます。

7. SOA設定の構成ページで、この例用に「空のコンポジット」をクリックし、「終了」をクリックします。表2-3 で、このページのオプションをすべて説明します。

表2-3 「SOA設定の構成」ページ

要素

説明

空のコンポジット

空のSOAコンポジット・アプリケーションを作成します。このタイプはデフォルトで選択されています。

BPELプロセスを使用するコンポジット

「BPELプロセスの作成」ダイアログが自動的に開き、ここで最初のBPELプロセスを作成します。BPELプロセスでは、一連のビジネス・アクティビティおよびサービスをエンドツーエンドのプロセス・フローに統合するビジネス・プロセスを設計できます。

メディエータを使用するコンポジット

「メディエータの作成」ダイアログが自動的に開き、ここで最初のOracle Mediatorサービス・コンポーネントを作成します。Oracle Mediatorを使用すると、異なるコンポーネント間でイベント(メッセージ)をルーティングできます。

ヒューマン・タスクを使用するコンポジット

「ヒューマン・タスクの作成」ダイアログが自動的に開き、ここで最初のヒューマン・タスク・サービス・コンポーネントを作成します。ヒューマン・タスク・コンポーネントでは、エンドツーエンドのビジネス・フローの一部として実行されるユーザーまたはグループのタスクを記述するワークフローをモデル化できます。これらのタスクは、プロセスの実行時にOracle BPM Worklistを介してアクセスされます。

サブプロセスを使用するコンポジット

サブプロセスを使用してSOAコンポジット・アプリケーションが自動的に作成されます。サブプロセスは、別個のプロセスが特定のプロセッサ内で再利用できるBPELコードのフラグメントです。

ビジネス・ルールを使用するコンポジット

「ビジネス・ルールの作成」ダイアログが自動的に開き、ここで最初のビジネス・ルール・サービス・コンポーネントを作成します。ビジネス・ルールにより、ルールに基づくビジネス上の意思決定を設計できます。

Springを使用するコンポジット

「Springの作成」ダイアログが自動的に開き、ここでspringコンテキスト・サービス・コンポーネントを作成します。Springコンテキスト・サービス・コンポーネントは、WSDLファイルではなくJavaインタフェースを使用するコンポーネントをSOAコンポジット・アプリケーションに統合できます。Javaインタフェースを使用するコンポーネントを、同じSOAコンポジット・アプリケーション内のWSDLファイルを使用するコンポーネントと統合することもできます。

8. 「ファイル」メイン・メニューから「すべて保存」を選択します。

2.1.2 SOAアプリケーションおよびプロジェクト作成時の処理内容

SOAアプリケーションを作成すると、Oracle JDeveloperではアプリケーションに関連するすべてのソース・ファイルを含むプロジェクトが作成されます。したがって、Oracle JDeveloperを使用してアプリケーションに必要な追加プロジェクトを作成できます。

図2-1 に、OrderBookingCompositeと呼ばれるプロジェクトのSOAコンポジット・エディタを示します。

図2-1 SOAコンポジット・アプリケーションの新規ワークスペース

表2-4 で、SOAコンポジット・エディタについて説明します。

図2-4 SOAコンポジット・エディタ

要素

説明

「アプリケーション」ウィンドウ(左上)

SOAプロジェクトに含まれている特定のサービス・コンポーネントの主要なディレクトリおよびファイルが表示されます。環境に合せて必要に応じて構造を変更できます。唯一の制限として、すべてのファイルがSOAディレクトリにある必要があります。

- Service_component_directory
追加した各サービス・コンポーネントのアーティファクトのディレクトリが表示されます。

BPELディレクトリがBPELプロセス用に作成されます。

MediatorsディレクトリがOracle Mediator用に作成されます。

HumanTasksディレクトリがヒューマン・タスク用に作成されます。

oracle/rulesディレクトリがビジネス・ルール用に作成されます。

- イベント
ビジネス・イベント・ファイル(.edn)が表示されます。

- スキーマ
BPELプロセス・スキーマ・ファイル(.xsd)が表示されます。

- テスト・スイート
テスト・スイート・ファイルが表示されます。

- トランスフォーメーション
トランスフォーメーションXSLTマッパー・ファイル(.xsl)およびXQueryマッパー・ファイル(.xqy)が表示されます。

- WSDL
すべてのWSDLファイル(.wsdl)が表示されます。

- composite_name
composite_nameファイルが、SOAプロジェクトの作成時に自動的に作成されます。このファイルでは、サービス、サービス・コンポーネント、参照およびワイヤのコンポジット・アセンブリ全体が記述されます。

「構造」ウィンドウ(左下)

「構造」ウィンドウでは、アクティブ・ウィンドウで現在選択されているドキュメント内のデータの構造ビューを提供します。

デザイナ(中央)

サービス・コンポーネント、サービスおよび参照を「コンポーネント」ウィンドウからデザイナ内のコンポジットにドラッグします。サービス・コンポーネントをデザイナにドラッグ・アンド・ドロップすると、対応するプロパティ・エディタが起動して、そのサービス・コンポーネントに関連する構成タスクを実行できます。たとえば、Oracle Mediatorサービス・コンポーネントをデザイナにドラッグ・アンド・ドロップすると、Mediator Editorが表示され、ここでOracle Mediatorサービス・コンポーネントを構成します。

後続のすべての編集セッションについて、これらのサービス・コンポーネントをダブルクリックして、それぞれのエディタを再度開きます。

プロジェクト名(デザイナの上)

SOAコンポジット・アプリケーションのプロジェクト名を表示します。

左側のスイムレーン(「公開されたサービス」)

左側のスイムレーンは、Webサービス、RESTアダプタ、JCAアダプタなど、SOAコンポジット・アプリケーションへのエントリ・ポイントを提供するサービス用です。

右側のスイムレーン(「外部参照」)

右側のスイムレーンは、WebサービスやJCAアダプタなど、外部にある外部サービスにメッセージを送信する参照用です。

「コンポーネント」ウィンドウ(右上 - 「コンポーネント」タブ)

「コンポーネント」ウィンドウでは、SOAコンポジットで使用できる様々なリソースが提供されます。次のサービス・コンポーネントおよびアダプタが含まれます。

- コンポーネント
デザイナにドラッグ・アンド・ドロップできるBPELプロセス、ビジネス・ルール、ヒューマン・タスク、Oracle MediatorおよびSpringコンポーネントが表示されます。

- テクノロジ
左側または右側のスイムレーンにドラッグできるJCAアダプタ(AQ、ファイル、FTP、データベース、JMS、MQ、Oracle User Messaging Service、ソケット、LDAPサーバー、Coherenceキャッシュ)、サード・パーティ・アダプタ、クラウド・アダプタ、Oracle BAM 11gバインディング・コンポーネント、Oracle Healthcareバインディング・コンポーネント、Oracle B2Bバインディング・コンポーネント、EJBバインディング・コンポーネント、ADF-BCバインディング・コンポーネント、アプリケーション・アダプタ(Oracle E-Business Suite、JDE WorldおよびSAP)、直接バインディング・コンポーネント、HTTPバインディング・コンポーネント、Oracle Managed File Transfer (MFT)アダプタ、Representational State Transfer (REST)アダプタおよびWebサービス・バインディング・コンポーネントが表示されます。

「リソース」ウィンドウ(右上 - 「リソース」タブ)

「リソース」ウィンドウには、1つのダイアログが用意されており、ここからローカルなリソースとリモートのリソースの両方を参照できます。たとえば、次のリソースにアクセスできます。

- MDSリポジトリからのスキーマやWSDLなどの共有データ。

- HTTP接続、ファイルURLまたはアプリケーション・サーバー接続を介してアクセスできるリモート・リソースを使用するWSILブラウザ機能。

- Universal Description, Discover, and Integration (UDDI)レジストリに登録されるリモート・リソース。

SOAコンポジット・アプリケーション用のこれらのリソースは、「WSDLチューザ」ダイアログから選択します。このダイアログには、様々な方法でアクセスできます。たとえば、サービス・バインディング・コンポーネントまたはOracle Mediatorサービス・コンポーネントで使用するWSDLファイルを選択した場合、またはBPELプロセスで使用するスキーマ・ファイルを選択した場合に、「SOAリソース・ブラウザ」ダイアログが表示されます。このダイアログの上部の「リソース」をクリックし、使用可能なリソースにアクセスします。

「ログ」ウィンドウ(中央下)

「ログ」ウィンドウには、アプリケーションのコンパイル、検証およびデプロイメントに関するメッセージが表示されます。

プロパティ・インスペクタ(右下)

「プロパティ・インスペクタ」には、選択されているサービス・コンポーネント、サービスまたは参照のプロパティが表示されます。

また、BPELアクティビティ・プロパティを編集して、BPELプロセス・サービス・コンポーネントのデプロイメント・ディスクリプタのプロパティも定義できます。

詳細は、「BPELアクティビティをプロパティ・インスペクタで編集する方法」および「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。

アプリケーション・ビュー

アプリケーション・ビューには、SOAコンポジット・アプリケーションのアーティファクトが表示されます。

composite_nameファイル(composite.xmlファイルとも呼ばれます)は、デザイナではタブとして、「アプリケーション」ウィンドウではファイルとして表示されます。このファイルは、新しいSOAプロジェクトの作成時に自動的に作成されます。このファイルには、サービス、サービス・コンポーネントおよび参照のコンポジット構成全体が記述されています。1つのSOAプロジェクトに対して1つのcomposite.xmlファイルがあります。

composite.xmlファイルを使用するには、ほとんどの場合、図2-1 に示すようにデザイナ、「構造」ウィンドウおよび「プロパティ・インスペクタ」を使用します。デザイナを使用すると、WYSIWYG環境に多くのファイルを表示できます。さらに、概要エディタにファイルを表示して宣言的に変更したり、ファイルのソース・コードを表示することもできます。「構造」ウィンドウには、現在選択されているファイルの構造が示されます。このウィンドウでオブジェクトを選択し、選択したオブジェクトのプロパティを「プロパティ・インスペクタ」で編集できます。

2.2 サービス・コンポーネントの追加

アプリケーションを作成した後は、通常、そのアプリケーションのビジネス・ロジックまたは処理ルールを実装するサービス・コンポーネントを追加します。SOAコンポジット・エディタの「コンポーネント」ウィンドウを使用して、サービス・コンポーネントをコンポジットにドラッグ・アンド・ドロップできます。

2.2.1 サービス・コンポーネントの追加方法

サービス・コンポーネントを追加する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウの上部で、「コンポーネント」をクリックします。

2. 「SOA」セクションから、コンポーネントをデザイナにドラッグします。

図2-2 に、デザイナに追加されるBPELプロセスを示します。

図2-2 SOAコンポジット・アプリケーションへのBPELプロセスの追加

選択したサービス・コンポーネントに固有のダイアログが表示されます。表2-5 は、使用可能なエディタを示しています。

表2-5 サービス・コンポーネント・エディタの起動

ドラッグするサービス・コンポーネント

起動する対象

BPELプロセス

「BPELプロセスの作成」ダイアログが開きます。このダイアログで、一連のビジネス・アクティビティおよびサービスをエンドツーエンドのプロセス・フローに統合するBPELプロセスを作成します。

ビジネス・ルール

「ビジネス・ルールの作成」ダイアログが開きます。このダイアログで、ルールに基づいてビジネス・デシジョンを作成します。

ヒューマン・タスク

「ヒューマン・タスクの作成」ダイアログが開きます。このダイアログで、ユーザーまたはグループがエンドツーエンドのプロセス・フローの一環として実行するタスクを記述するワークフローを作成します。

メディエータ

「メディエータの作成」ダイアログが開きます。このダイアログで、メッセージやイベントのルーティング、フィルタおよびトランスフォーメーションを実行するサービスを定義します。

Springコンポーネント

「Springの作成」ダイアログが起動し、JavaインタフェースをSOAコンポジット・アプリケーションに統合するためのSpringコンテキスト・ファイルを作成できます。

3. サービス・コンポーネントの設定を構成して、「OK」をクリックします。サービス・コンポーネントのダイアログに関するヘルプは、「ヘルプ」をクリックするか、[F1]を押します。

図2-3 は、OrderProcessor BPELプロセスを作成するためにデータが入力された「BPELプロセス」ダイアログを示しています。このプロセスは非同期として選択されています。「SOAPサービスとして公開」チェック・ボックスを選択することで、Oracle JDeveloperによって、インバウンドSOAP Webサービスに接続されたこのサービス・コンポーネントが自動的に作成されます。

図2-3 「BPELプロセスの作成」ダイアログ

4. 「OK」をクリックします。

図2-4 は、デザイナのOrderProcessor BPELプロセス・サービス・コンポーネントを示しています。左側のスイムレーンにあるorderprocessor_client_epというSOAPサービス・バインディング・コンポーネントは、外部に対してSOAコンポジット・アプリケーションへのエントリ・ポイントを提供します。「BPELプロセスの作成」ダイアログで「SOAPサービスとして公開」オプションを選択しなかった場合、orderprocessor_client_epサービスは表示されません。サービスは、「サービス・バインディング・コンポーネントの追加方法」の手順に従って、後で追加できます。

図2-4 コンポジット内のBPELプロセス

サービス・コンポーネントの内容は、現時点でも後からでも詳細に定義できます。このトップダウンの例では、この時点で内容が定義されます。

5. 「ファイル」メイン・メニューから、「すべて保存」を選択します。

2.2.2 サービス・コンポーネントの追加と削除に関する必知事項

サービス・コンポーネントの追加については次の詳細に注意してください。

- サービス・コンポーネントは、SOAコンポジット・エディタまたは他のコンポーネントのデザイナから作成します。たとえば、ヒューマン・タスク・コンポーネントは、SOAコンポジット・エディタまたはOracle BPELデザイナから作成できます。

- 「リソース」ウィンドウを使用して、で定義されていたり、デプロイされているサービス・コンポーネントを参照します。

サービス・コンポーネントの削除については次の詳細に注意してください。

- サービス・コンポーネントを削除するには、該当するサービス・コンポーネントを右クリックして、コンテキスト・メニューから「削除」を選択します。

- サービス・コンポーネントが削除されると、それを示す参照はすべて無効になり、すべてのワイヤは削除されます。サービス・コンポーネントも「アプリケーション」ウィンドウから削除されます。

- 別のサービス・コンポーネント内から作成されたサービス・コンポーネントを削除できます。たとえば、Oracle JDeveloperのBPELプロセス・サービス・コンポーネント内で作成されたヒューマン・タスクは、から削除できます。さらに、タスクへのパートナ・リンクも削除できます。パートナ・リンクを削除すると、参照インタフェースが削除され、タスクへのワイヤが削除されます。

2.2.3 サービス・コンポーネントの編集方法

サービス・コンポーネントを編集して、サービス・コンポーネントに関する特定の詳細を定義します。

サービス・コンポーネントを編集する手順は、次のとおりです。

1. 表2-6 に示すように、デザイナで該当するサービス・コンポーネントをダブルクリックして適切なエディタまたはデザイナを表示します。

表2-6 SOAサービス・コンポーネントのウィザードとダイアログの起動

ダブルクリックするサービス・コンポーネント

表示対象

BPELプロセス

詳細設計のためのOracle BPELデザイナ

ビジネス・ルール

詳細設計のためのビジネス・ルール・デザイナ

ヒューマン・タスク

詳細設計のためのヒューマン・タスク・エディタ

メディエータ

詳細設計のためのOracle Mediatorエディタ

Springコンポーネント

詳細設計のためのSpringエディタ

2. 選択したサービス・コンポーネントの設定を変更します。サービス・コンポーネント・エディタまたはデザイナに関するヘルプは、「ヘルプ」をクリックするか、[F1]を押してください。これらのエディタについては、この後の章で説明します。

3. 「ファイル」メイン・メニューから、「すべて保存」を選択します。

4. 「アプリケーション」ウィンドウでcomposite_nameをダブルクリックするか、デザイナ上でcomposite_nameをクリックします。

この操作により、に戻ります。

2.3 サービス・バインディング・コンポーネントの追加

SOAコンポジット・アプリケーションへのエントリ・ポイントとして機能するサービス・バインディング・コンポーネントを外部から追加します。

2.3.1 サービス・バインディング・コンポーネントの追加方法

注意:

この項では、サービス・バインディング・コンポーネントを手動で作成する方法を説明します。また、サービス・コンポーネントを作成するときに、「SOAPサービスとして公開」を選択すると、サービス・バインディング・コンポーネントを自動的に作成できます。これを選択すると、BPELプロセス、ヒューマン・タスク・サービスまたはOracle Mediatorサービス・コンポーネントに自動的に接続されるインバウンドWebサービス・バインディング・コンポーネントが作成されます。

SOAコンポジット・エディタの「コンポーネント」ウィンドウを使用して、バインディング・コンポーネントをコンポジットにドラッグ・アンド・ドロップできます。

サービス・バインディング・コンポーネントを追加する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOAP」Webサービスを左側の「公開されたサービス」スイムレーンにドラッグして、サービス・インタフェースを定義します。

図2-5 に、デザイナに追加されるSOAP Webサービスを示します。

図2-5 コンポジットへのSOAP Webサービスの追加

選択したサービスに固有のダイアログが表示されます。表2-7 は、使用可能なエディタを示しています。

表2-7 サービス・エディタ

ドラッグするサービス

起動する対象

SOAP

「Webサービスの作成」ダイアログが起動し、Web呼出しサービスを作成できます。

アダプタ

アダプタ構成ウィザードが起動し、データベース表、データベース・キュー、ファイル・システム、FTPサーバー、Java Message Services (JMS)、IBM WebSphere MQ、Oracle User Messaging Service、Oracle BAM 11gサーバー、LDAPサーバー、Coherenceキャッシュ、ソケット、クラウド・アダプタまたはOracle E-Business Suiteアプリケーション、JDE WorldアプリケーションやSAPアプリケーションとサービスを統合できます。

ADF-BC

「ADF-BCサービスの作成」ダイアログが起動し、サービス・データ・オブジェクト(SDO)呼出しサービスを作成できます。

B2B

「B2B構成」ウィザードによって、ドキュメント定義の選択手順が示されます。

Healthcare

「Healthcare構成」ウィザードによって、ヘルスケア・システムとの統合手順が示されます。

EJB

「EJBサービスの作成」が起動し、SDOパラメータまたはJavaインタフェースをEnterprise JavaBeansで使用するためのEnterprise JavaBeansサービスを作成できます。

HTTP

HTTPバインディングの作成ウィザードが起動し、HTTPバインディングを作成できます。このウィザードを使用すると、HTTPのPOSTおよびGET操作からSOAコンポジット・アプリケーションを起動できます。

直接

「直接バインディング・サービスの作成」ダイアログが起動し、インバウンド方向で、SOAコンポジット・アプリケーションを起動し、Remote Method Invocation (RMI)を介してメッセージを交換できます。

REST

REST操作をサービス・バインディング・コンポーネントや参照バインディング・コンポーネントとして統合するための「RESTバインディングの作成」ダイアログ

MFT

MFT構成ウィザードによって、MFTのソースやターゲットを作成できます。

2. サービスの設定値を構成します。サービス・エディタに関するヘルプは、「ヘルプ」をクリックするか、[F1]を押してください。Webサービスを追加する場合は、使用するWSDLファイルを選択する必要があります。詳細は、「Webサービスのインタフェース(WSDL)の定義方法」を参照してください。

3. 「終了」をクリックします。

図2-6 は、OrderProcessor BPELプロセス用のorderprocessor_client_epサービスを作成するためにデータが入力された「Webサービス」ダイアログを示しています。

図2-6 「Webサービスの作成」ダイアログ

4. 「OK」をクリックします。

サービス・バインディング・コンポーネントが左側のスイムレーンに表示されます。図2-7 に、composite_nameファイルに追加されたorderprocessor_client_ep serviceバインディング・コンポーネントを示します(この例では、OrderBookingCompositeという名前です)。

図2-7 コンポジット内のWebサービス

5. 「ファイル」メイン・メニューから「すべて保存」を選択します。

2.3.2 Webサービスのインタフェース(WSDL)の定義方法

「サービス・バインディング・コンポーネントの追加方法」で説明しているように、Webサービスは、SOAコンポジット・アプリケーションに追加できるバインディング・コンポーネントの一種です。Webサービスのインタフェース(WSDL)ファイルを定義する必要があります。

Webサービスのインタフェース(WSDL)を定義する手順は、次のとおりです。

1. 「テクノロジ」セクションから、「SOAP」Webサービスを左側の「公開されたサービス」スイムレーンにドラッグします。

図2-6 に示す「Webサービスの作成」ダイアログが表示されます。

2. 表2-8 に記載されている詳細を入力します。

表2-8 「Webサービスの作成」ダイアログのフィールドと値

フィールド

値

名前

サービスの名前を入力します。

タイプ

Webサービスに対してタイプ(メッセージの方向)を選択します。Webサービスを左側のスイムレーンにドラッグしているため、「サービス」タイプが正しい選択であり、デフォルトでこのタイプが表示されます。

- サービス(デフォルト)
SOAコンポジット・アプリケーションへのエントリ・ポイントを提供するWebサービスを作成します。

- 参照
外部にある外部サービスへのアクセスを提供するWebサービスを作成します。

この例では、SOAコンポジット・アプリケーションへのエントリ・ポイントの作成方法を説明しているため、「サービス」が選択されています。

3. サービスに対するWSDLファイルを選択します。選択には3種類の方法があります。

- スキーマを使用した新規WSDLの定義

- 既存のWSDLの選択

- コンポーネントからのサービス・インタフェースのWSDLの自動定義

4. 「入力」表の上の「追加」アイコンをクリックすると、新規WSDLメッセージ・パートを追加するための「メッセージ・パートの追加」ダイアログが表示されます。WSDLファイルに複数のメッセージが含まれる場合、それぞれに1つのメッセージ・パートを追加できます。メッセージ・パートに対して、XMLスキーマの単純型、プロジェクトのスキーマ・ファイルおよびプロジェクトのWSDLファイルを選択できます。

詳細は、「ヘルプ」をクリックします。

5. 「OK」をクリックして「Webサービスの作成」ダイアログに戻ります。

6. 表2-9 で説明する追加フィールドに注意してください。

表2-9 「Webサービスの作成」ダイアログのフィールドと値

フィールド

値

ポート・タイプ

ポート・タイプが表示されます。

コールバック・ポート・タイプ

無効。WSDLファイルが同期サービス用であるためです。このフィールドは非同期サービスの場合に有効になります。

7. 「OK」をクリックします。

8. 「ファイル」メイン・メニューから、「すべて保存」を選択します。

注意:

- ソース・ビューでWSDLファイルのWSDLの場所を手動で更新しないでください。この操作はサポートされていません。サポートされているのは、設計ビューでの更新のみです。

- WSDLネームスペースは一意にする必要があります。単にWSDLをコピーして名前変更しないでください。ネームスペースも必ず変更してください。

2.3.2.1 スキーマを使用した新規WSDLの定義

既存のスキーマを使用して新しいWSDLを定義するか、新しいスキーマを定義します。

1. 「WSDL URL」フィールドの右側で、「既存のWSDLを検索します。」(1番目)アイコンをクリックします。

2. 上部で、「ファイルシステム」をクリックします。

3. 既存のWSDLファイルをローカル・ファイル・システムで選択します(この例では、OrderProcessor.wsdlが選択されています)。図2-8に詳細を示します。

図2-8 WSDLファイルの選択

2.3.2.2 既存のWSDLの選択

コンポーネントのインタフェースを定義したときに作成されたWSDLを選択します。WSDLは、プロジェクト/アプリケーションのブラウザから選択できます。

1. 「WSDL URL」フィールドの右側で、「既存のWSDLを検索します。」(1番目)アイコンをクリックします。

2. 上部で、SOA-MDSをクリックします。選択すると、他のアプリケーションの既存のWSDLファイルを使用できるようになります。

2.3.2.3 コンポーネントからのサービス・インタフェースのWSDLの自動定義

コンポーネントからサービス・インタフェースのWSDLを自動的に定義します。

1. 「WSDL URL」フィールドの右側で、「スキーマからWSDLを生成」(2番目)アイコンをクリックすると、スキーマからWSDLファイルが自動生成されます。

図2-9 は「WSDLの作成」ダイアログを示しています。WSDLファイル名、ディレクトリの場所、ネームスペース、ポート・タイプ、操作名、およびインタフェース・タイプのデフォルト値が表示されます。指定したディレクトリが現在のプロジェクトのサブディレクトリでない場合、警告メッセージが表示されます。指定したディレクトリが存在しない場合、自動作成されます。

デフォルト値は変更できます。

図2-9 WSDLファイルの自動生成

2.3.3 スキーマの表示方法

インタフェースのWSDLファイルで使用するすべてのスキーマを表示でき、必要な場合は、「インタフェースの更新」ダイアログで、選択されたメッセージ・パートに対する新しいメッセージ・スキーマを選択できます。

スキーマを表示する手順は、次のとおりです。

1. 特定のバインディング・コンポーネントまたはサービス・コンポーネント上に表示される小さい矢印ハンドルをダブルクリックします。図2-10に詳細を示します。

図2-10 インバウンド・インタフェース・ハンドルの選択

図2-11 に示す「インタフェースの更新」ダイアログには、WSDLファイルで現在使用されているすべてのスキーマが表示されます。

図2-11 「インタフェースの更新」ダイアログ

2. 新しいメッセージ・スキーマを選択する方法については、「ヘルプ」をクリックするか、[F1]を押してください。

2.3.4 サービス・バインディング・コンポーネントの編集方法

最初にサービスを作成し、後でその内容を編集することもできます。コンポーネントのアイコンをダブルクリックすると、適切なエディタまたはウィザードが表示されます。表2-10 に概要を示します。

表2-10 サービスのウィザードとダイアログの起動

ダブルクリックするサービス

用途

SOAP

「サービスの更新」ダイアログが表示されます。

アダプタ

アダプタ構成ウィザードに再入力します。

ADF-BC

「サービスの更新」ダイアログが表示されます。

B2B

B2B構成ウィザードに再入力します。

Healthcare

Healthcare構成ウィザードに再入力します。

EJBサービス

「サービスの更新」ダイアログが表示されます。

HTTP

HTTPバインディング・ウィザードに再入力します。

直接

「サービスの更新」ダイアログに再入力します。

REST

「RESTバインディング」ダイアログに再入力します。

MFT

MFT構成ウィザードに再入力します。

2.3.5 サービスの追加と削除に関する必知事項

サービスの追加については次の詳細に注意してください。

- サービス・コンポーネントに新しいサービスが追加されると、そのサービス・コンポーネントには、メタデータを適切に変更できるように通知されます。たとえば、新しいサービスがBPELサービス・コンポーネントに追加されると、そのBPELサービス・コンポーネントには、receiveまたはon-messageアクティビティに接続可能なパートナ・リンクを作成するように通知されます。

サービスの削除については次の詳細に注意してください。

- サービス・コンポーネントにより提供されているサービスが削除されると、そのサービス・コンポーネントに対するすべての参照が無効となり、ワイヤが削除されます。

2.3.6 同じコンポジットの異なるWSDLファイルでの同じネームスペースの使用に関する必知事項

同じSOAコンポジット・アプリケーションの異なる2つのWSDLファイルにおいて、完全修飾された同じネームスペースを使用することはあいまいであり、サポートされていません。これにより、コンパイル時に、重複した定義のエラーによってアプリケーションが失敗します。すべてのWSDLファイルに対して一意のネームスペースを使用するようにしてください。

2.3.7 SOAインフラストラクチャで内部と外部の両方のOracle HTTP Serverを使用する場合における「リソース」ウィンドウのWSDL参照に関する必知事項

Oracle Enterprise Manager Fusion Middleware Controlの「SOAインフラストラクチャの共通プロパティ」ページにある「サーバーURL」フィールドで、内部および外部の両方のOracle HTTP Serverを使用するようにSOAインフラストラクチャを構成している場合、「リソース」ウィンドウを使用してWSDL URLを参照できません。ただし、Webサービス・バインディング・コンポーネントの「サービスの更新」ダイアログの「WSDL URL」フィールドに、適切なWSDL URLを貼り付けることはできます。図2-12に詳細を示します。

図2-12 「WSDL URL」フィールド

2.4 参照バインディング・コンポーネントの追加

参照バインディング・コンポーネントを追加します。このコンポーネントは、外部にある外部サービスにメッセージを送信するためのSOAコンポジット・アプリケーションを有効にします。

2.4.1 参照バインディング・コンポーネントの追加方法

SOAコンポジット・エディタの「コンポーネント」ウィンドウを使用して、参照バインディング・コンポーネントをコンポジットにドラッグ・アンド・ドロップできます。

参照バインディング・コンポーネントを追加する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「テクノロジ」リストから、サービスを右側の「外部参照」スイムレーンにドラッグします。

図2-13 に、デザイナに追加されるWebサービスを示します。

図2-13 コンポジットへのSOAP Webサービスの追加

選択されている参照固有のダイアログまたはウィザードが表示されます。表2-11 は、使用可能なエディタを示しています。

表2-11 参照エディタ

ドラッグするサービス

起動する対象

SOAP

「Webサービスの作成」ダイアログが起動し、Web呼出しサービスを作成できます。

アダプタ

アダプタ構成ウィザードが起動し、データベース表、データベース・キュー、ファイル・システム、FTPサーバー、Java Message Services (JMS)、IBM WebSphere MQ、Oracle User Messaging Service、Oracle BAM 11gサーバー、LDAPサーバー、Coherenceキャッシュ、ソケット、クラウド・アダプタまたはOracle E-Business Suiteアプリケーション、JDE WorldアプリケーションやSAPアプリケーションとサービスを統合できます。

ADF-BC

「ADF-BCサービスの作成」ダイアログが起動し、サービス・データ・オブジェクト(SDO)呼出しサービスを作成できます。

B2B

B2Bウィザードが起動し、ドキュメント定義を選択できます。

Healthcare

「Healthcare構成」ウィザードによって、ヘルスケア・システムとの統合手順が示されます。

EJB

「EJBサービスの作成」ダイアログが起動し、SDOパラメータをEnterprise JavaBeansで使用するためのEnterprise JavaBeansサービスを作成できます。

HTTP

HTTPバインディングの作成ウィザードが起動し、HTTPバインディングを作成できます。このウィザードを使用すると、HTTPのPOSTおよびGET操作からSOAコンポジット・アプリケーションを起動したり、HTTPのPOSTおよびGET操作からHTTPエンドポイントを起動できます。

直接

「直接バインディング・サービスの作成」ダイアログが起動し、Oracle Service Busフローまたは別のSOAコンポジット・アプリケーションを起動できます。

REST

REST操作をサービス・バインディング・コンポーネントや参照バインディング・コンポーネントとして統合するための「RESTバインディングの作成」ダイアログ

MFT

MFT構成ウィザードによって、MFTのソースやターゲットを作成できます。

3. 参照バインディング・コンポーネントの設定値を構成します。参照エディタに関するヘルプは、「ヘルプ」をクリックするか、[F1]を押してください。

4. 「終了」をクリックします。

図2-14 は、参照を作成するためにデータが入力された「Webサービスの作成」ダイアログを示しています。

図2-14 「Webサービスの作成」ダイアログ

5. 「OK」をクリックします。

図2-15 に、SOAコンポジット・アプリケーションの右側のスイムレーンに追加されたStoreFrontService参照バインディング・コンポーネントを示します。

図2-15 コンポジット内のSOAP Webサービス

6. 「ファイル」メイン・メニューから、「すべて保存」を選択します。

2.4.2 参照の追加と削除に関する必知事項

参照の追加については次の詳細に注意してください。

- に新しい参照を追加する唯一の方法は、必要なターゲット・サービス・コンポーネントにサービス・コンポーネントを接続することです。新しい参照が追加されると、サービス・コンポーネントに通知されて適切に変更できます。たとえば、参照がBPELサービス・コンポーネントに追加されると、BPELサービス・コンポーネントにパートナ・リンクを追加するように通知されます。このパートナ・リンクはinvokeアクティビティで使用可能です。

参照の削除については次の詳細に注意してください。

- サービス・コンポーネントに対する参照が削除されると、関連付けられているワイヤも削除され、メタデータを更新できるようにサービス・コンポーネントに通知されます。たとえば、参照がBPELサービス・コンポーネントから削除されると、そのBPELメタデータにあるパートナ・リンクを削除するようにサービス・コンポーネントに通知されます。

- ワイヤに接続されている参照を削除すると、その参照とワイヤも消去されます。

2.4.3 WSDL参照に関する必知事項

WSDLファイルは、WSDLを含む新規コンポーネント(サービス・バインディング・コンポーネント、Oracle MediatorやBPELプロセスなどのサービス・コンポーネント、または参照バインディング・コンポーネント)を作成するたびにSOAコンポジット・アプリケーションに追加されます。コンポーネントを削除すると、そのコンポーネントで使用されていたWSDLインポートは、別のコンポーネントで使用されていない場合にのみ削除されます。WSDLインポートは、そのWSDLインポートを使用していた最後のコンポーネントが削除されると常に削除されます。

サービス・バインディング・コンポーネントまたは参照バインディング・コンポーネントが新しいWSDLを使用するように更新されると、インタフェースが削除されて新しいインタフェースが追加されたかのように処理されます。したがって、古いWSDLインポートは、別のコンポーネントで使用されていない場合のみ削除されます。

サービス・バインディング・コンポーネントまたは参照バインディング・コンポーネントが新しい場所から同じWSDL (porttype qname)を使用するように更新されると、WSDLインポートおよび他のすべてのWSDL参照(例: 外部参照WSDLをインポートするBPELプロセスWSDL)は新しい場所を参照するように自動的に更新されます。

composite_name (composite.xml)ファイルのインポートのソース・ビューで単にWSDLの場所を変更するだけでは不十分です。メタデータ内にはユーザー・インタフェースで必要なWSDL参照があります(コンポジット・サービスおよび参照のui:wsdlLocation属性を参照)。また、実行時に必要なWSDL参照もあります(例: BPELプロセスWSDLなど別のWSDLをインポートするWSDL)。このファイル内のWSDL URLが参照されている次の場所を変更してください。

- ユーザー・インタフェースの場所 - Oracle JDeveloperでのみ使用されます。

- インポート: デプロイ時に使用されます。

- 参照定義内のWSDLの場所: 実行時に使用されます。

WSDLの場所は常に、WSDLの場所が指定されたSOAコンポジット・エディタのダイアログ(例: Webサービス、BPELパートナ・リンクなど)で変更してください。URLのホスト・アドレスを変更すると、SOAコンポジット・エディタはすべてのWSDL参照を自動的に更新します。

2.4.4 WSDLファイルでのメッセージ・タイプの混在に関する必知事項

BPELプロセスで、WSDLファイルに複数のWSDLメッセージが宣言され、その他のメッセージにはパートがなんらかの要素となるよう定義されているのに対し、1つ以上のメッセージにそのパートがなんらかのタイプとなるよう定義されている場合、実行時の動作が予測不可能となる可能性があります。これは、これらのWSDLにタイプの混在したメッセージが含まれると見なされるためです。たとえば、assignアクティビティ内に複数のコピー・アクションがあるとします。これらのコピー・アクションでは、次の複数のパートを持つ出力変数の移入が試行されます。

- パート1はxsd:stringタイプとして宣言されています。

- パート2はxsd:intタイプとして宣言されています。

- パート3はカスタム設計の複雑なタイプの要素として宣言されています。

この動作はサポートされていません。

2.4.5 コンポジットのデフォルト・リビジョンの起動に関する必知事項

リビジョン番号を含まないWSDL URLは、デフォルトのコンポジット・アプリケーションによって処理されます。このため、コール元のコンポジットを変更せずに、コール先サービスのデフォルト・リビジョンを常にコールできます。

デフォルトWSDLを選択し、Oracle JDeveloperの「WSDLチューザ」ダイアログで使用します。

コンポジットのデフォルト・バージョンを起動する手順は、次のとおりです。

1. 「Webサービスの作成」ダイアログで、「WSDL URL」フィールドの右側にあるアイコンをクリックして「WSDLチューザ」ダイアログを起動します。

2. 上部で、「アプリケーション・サーバー」または「WSIL」を選択します。

3. ノードを展開し、デプロイされたコンポジットとリビジョンのすべてをリストします。デフォルトのバージョンには、タイトルにDefaultという語が表示されます(たとえば、FaultFlow [Default 1.0])。

図2-16 「WSDLチューザ」ダイアログ

4. 適切なデフォルトのエンドポイントを選択し、「OK」をクリックします。

2.5 ワイヤの追加

サービス、サービス・コンポーネントおよび参照を接続します。この例では、Webサービスとサービス・コンポーネントを接続します。次の点に注意してください。

- Webサービスはインバウンド・サービスであるため、参照ハンドルは右側に表示されます。アウトバウンド参照であるWebサービスは、右側に参照ハンドルがありません。

- 定義済のインタフェースは未定義のインタフェースにどちらの方向から(参照からサービスへ、またはサービスから参照へ)でもドラッグできます。未定義のインタフェースは定義済のインタフェースを継承します。このルールにはいくつかの例外があります。

- コンポーネントには、新しいインタフェースを却下する権限があります。たとえば、Oracle Mediatorには1つのインバウンド・サービスしか保持できません。このため、コンポーネントは2番目のサービスが作成されないように却下します。

- ビジネス・ルールは参照をサポートしないため、アウトバウンド・サービス(外部参照)をビジネス・ルールにドラッグすることはできません。ワイヤをドラッグすると、ユーザー・インタフェースでは、有効なターゲットであるインタフェースがハイライト表示されます。

- インタフェースを一意に識別する際には、ポート・タイプとネームスペースが使用されます。

- 異なるインタフェースを持つサービスとコンポジットは接続できません。たとえば、同期WSDLファイルで構成されているWebサービスは非同期BPELプロセスに接続できません。図2-17に詳細を示します。

図2-17 異なるインタフェースを持つサービスとコンポジットの接続に関する制限

サービスと参照は一致する必要があります。つまり、インタフェースとコールバックは同じになる必要があります。インタフェースが異なる2つのサービスがある場合は、2つのサービス間にOracle Mediatorを配置し、インタフェース間のトランスフォーメーションを実行できます。

2.5.1 サービスとサービス・コンポーネントの接続方法

SOAコンポジット・エディタで、サービス・バインディング・コンポーネントをサービス・コンポーネントに接続できます。

サービスとサービス・コンポーネントを接続する手順は、次のとおりです。

1. 図2-18 に示すように、サービス参照ハンドルからワイヤをサービス・コンポーネント・インタフェースにドラッグします。

図2-18 ワイヤ接続

2. サービス・コンポーネントがBPELプロセスの場合は、BPELプロセスをダブルクリックしてOracle BPELデザイナを開きます。図2-19 に示すように、サービスは、左側のスイムレーンにパートナ・リンクとして表示されることに注意してください。

図2-19 BPELプロセスにおけるパートナ・リンクとしてのサービスの表示

3. 「ファイル」メイン・メニューから「すべて保存」を選択します。

2.5.2 サービス・コンポーネントと参照の接続方法

SOAコンポジット・エディタで、サービス・コンポーネントを参照バインディング・コンポーネントに接続できます。

サービス・コンポーネントと参照を接続する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウでcomposite_nameをダブルクリックするか、デザイナ上でcomposite_nameをクリックします。

2. 図2-20 に示すように、サービス・コンポーネントからワイヤを参照にドラッグします。

図2-20 サービス・コンポーネントと参照のワイヤリング

3. サービス・コンポーネントがBPELプロセスの場合は、BPELプロセスをダブルクリックしてOracle BPELデザイナを開きます。図2-21 に示すように、参照は、右側のスイムレーンにパートナ・リンクとして表示されることに注意してください。

図2-21 BPELプロセスにおけるパートナ・リンクとしての参照の表示

4. 「ファイル」メイン・メニューから「すべて保存」を選択します。

5. 「アプリケーション」ウィンドウで、composite_nameファイルを選択します。

6. 「ソース」タブをクリックして、作成した内容を確認します。

orderprocessor_client_epサービス・バインディング・コンポーネントは、コンポジットへのエントリ・ポイントを提供します。

<service name="orderprocessor_client_ep"
ui:wsdlLocation="oramds:/apps/FusionOrderDemoShared
/services/orderbooking/OrderBookingProcessor.wsdl">
<interface.wsdl interface= "http://www.globalcompany.example.com/ns
/OrderBookingService#wsdl.interface(OrderProcessor)"
<binding.adf serviceName="OrderProcessorService" registryName=""/>
<callback>
<binding.ws port="http://www.globalcompany.example.com/ns
/OrderBookingService#wsdl.endpoint(orderprocessor_clientep/OrderProcessorCallback_
pt)"/>
</callback>
</service>

OrderProcessor BPELプロセス・サービス・コンポーネントが表示されます。

<component name="OrderProcessor">
<implementation.bpel src="OrderProcessor.bpel"/>
</component>

StoreFrontServiceという名前の参照バインディング・コンポーネントが表示されます。この参照は、外部にある外部サービスへのアクセスを提供します。

<reference name="StoreFrontService"
ui:wsdlLocation="oramds:/apps/FusionOrderDemoShared
/services/oracle/fodemo/storefront/store/service/common/serviceinterface/StoreFron
tService.wsdl">
<interface.wsdl
interface="www.globalcompany.example.com#wsdl.interface(StoreFrontService)"/>
<binding.ws
port="www.globalcompany.example.com#wsdl.endpoint(StoreFrontService/StoreFrontServ
iceSoapHttpPort)"
location="oramds:/apps/FusionOrderDemoShared/services/oracle/fodemo/storefront/sto
re/service/common/serviceinterface/StoreFrontService.wsdl"/>
</reference>

サービス・コンポーネント間の通信(またはワイヤリング)は、次のようになっています。

- ソースのorderprocessor_client_epサービス・バインディング・コンポーネントは、ターゲットのOrderProcessor BPELプロセス・サービス・コンポーネントに接続されています。ワイヤリングにより、この特定のBPELプロセスとWebサービス・メッセージ通信ができます。

- ソースのOrderProcessor BPELプロセスは、ターゲットのStoreFrontService参照バインディング・コンポーネントに接続されています。これは、外部にある外部サービスへの参照です。

<wire>
<source.uri>orderprocessor_client_ep</source.uri>
<target.uri>OrderProcessor/orderprocessor_client_ep</target.uri>
</wire>

<wire>
<source.uri>OrderProcessor/StoreFrontService</source.uri>
<target.uri>StoreFrontService</target.uri>
</wire>

2.5.3 ワイヤの追加と削除に関する必知事項

ワイヤの追加については次の詳細に注意してください。

- サービス・コンポーネントの参照がターゲット・サービス・コンポーネントのサービスと一致する場合、サービス・コンポーネントは別のサービス・コンポーネントに接続できます。一致するという意味は、同じインタフェースとコールバック・インタフェースであることに注意してください。

- 2つのOracle Mediatorサービス・コンポーネント間に次のワイヤリングを追加すると、無限ループが発生します。

- ビジネス・イベントを作成した場合

- Oracle Mediatorサービス・コンポーネントを作成し、イベントをサブスクライブした場合。

- 2番目のOracle Mediatorサービス・コンポーネントを作成し、同じイベントを公開した場合。

- 最初のOracle Mediatorを2番目のOracle Mediatorコンポーネント・サービスに接続した場合。

2つのOracle Mediator間のワイヤを削除すると、すべてのメッセージについて、2番目のOracle Mediatorはイベントを公開でき、最初のOracle Mediatorはそのイベントをサブスクライブできます。

ワイヤの削除については次の詳細に注意してください。

- ワイヤが削除されると、コンポーネントのアウトバウンド参照は自動的に削除され、クリーン・アップ(パートナ・リンクの削除、ルーティング・ルールの消去など)が可能であることがコンポーネントに通知されます。ただし、コンポーネントのサービス・インタフェースは削除されません。Oracle SOA Suiteのすべてのサービスは、WSDLインタフェースで定義されます。コンポーネントのインタフェースが定義されると、でサービス・インタフェースが自動的に削除されることはありません。
サービスのWSDLインタフェースを変更する必要がある場合は、次のような回避策があります。

- ほとんどの場合、変更が必要なのはインバウンド・サービス定義ではなくスキーマです。で、WSDLを使用するインタフェース・アイコンをクリックします。たとえば、Webサービス・インタフェース・アイコンやOracle Mediatorサービス・アイコンをクリックできます。この結果、「インタフェースの更新」ダイアログが起動し、このダイアログでWSDLメッセージのスキーマを変更できます。

- Oracle Mediatorサービス・コンポーネントを使用している場合は、Oracle Mediatorエディタの「WSDLからの操作のリフレッシュ」アイコンを使用して、(新しい操作を追加した後に) Oracle Mediator WSDLをリフレッシュまたは置換できます。ただし、現在の操作を削除しようとすると警告が表示されます。このアイコンを使用してWSDLを新規インバウンド・サービスWSDLに変更すると、インタフェースが変更されるため、通常は接続が切断されます。その後に、Oracle Mediatorを新規サービスに接続できます。

- 多くの場合、新規サービスでは完全に新しいOracle Mediatorが必要です。古いOracle Mediatorを削除し、新しいOracle Mediatorを作成して新規サービスに接続します。

- BPELプロセス・サービス・コンポーネントを使用している場合は、「パートナ・リンクの編集」ダイアログで新規のWSDLを選択します。

「インタフェースの更新」ダイアログの詳細は、「スキーマの表示方法」を参照してください。

2.6 SOAコンポジット・アプリケーションへの説明の追加

コンポジットの上にある「TODOタスク」アイコンにカーソルを合せると表示されるSOAコンポジット・アプリケーションの説明を追加できます。SOAコンポジット・アプリケーションのサービス、参照およびサービス・コンポーネントのアクションを説明で説明できます。

2.6.1 説明をSOAコンポジット・アプリケーションに追加する方法

説明をSOAコンポジット・アプリケーションに追加するには:

1. SOAコンポジット・エディタの上で、「TODOタスク」アイコンをクリックします。図2-22に詳細を示します。

図2-22 「TODOタスク」アイコン

2. 表行でダブルクリックし、説明を追加します。

3. 完了すると、表行の外側をクリックしてから、「閉じる」をクリックします。

4. SOAコンポジット・アプリケーションの上にある「TODOタスク」アイコンにカーソルを合せると、説明が表示されます。図2-23に詳細を示します。

図2-23 SOAコンポジット・アプリケーションの説明

2.7 コンポーネントとアーティファクトの名前変更、削除および移動

Oracle JDeveloperの次のセクションでは、一部のコンポーネントおよびアーティファクトの名前変更、削除および移動ができます(リファクタとも呼ばれます)。

- SOAコンポジット・エディタ
コンポーネントの名前の変更および削除が可能です。これらのアクションは、Oracle SOA Suiteメタデータに影響します(必ずしも特定のアーティファクトには当てはまりません)。

- 「アプリケーション」ウィンドウ
WSDL、スキーマなどのアーティファクトの名前の変更、削除および移動が可能です。これらのアクションは、Oracle JDeveloperアーティファクトに影響します。

注意:

Oracle BPELデザイナ、ヒューマン・タスク・エディタおよびその他のエディタを開いた状態でリファクタ・タスクを実行しないでください。行う場合は、リファクタ後にエディタを閉じてから再度開いてください。たとえば、BPELプロセスが開いた状態で、「アプリケーション」ウィンドウでBPELプロセスのWSDLファイルの名前を変更するとします。これによって、基礎となるBPELファイルは変更されますが、完全に終了するまでOracle BPELデザイナでこの変更は反映されず、同期化されない状態になります。Oracle BPELデザイナを閉じてから再度開いてください。変更が同期されます。

2.7.1 SOAコンポジット・エディタでのコンポーネントの名前変更および削除方法

表2-12 では、SOAコンポジット・エディタで実行可能なリファクタ・タスクを既知の制限とともに説明します。この機能を使用する前に、これらの制限をよく確認してください。

表2-12 コンポーネントのリファクタ

アクション

SOAコンポジット・エディタでの手順

サービス・コンポーネントまたはバインディング・コンポーネントの名前の変更

1. コンポーネントを右クリックし、「名前の変更」を選択します。名前を変更すると、コンポジットでコンポーネントへの参照のすべてが更新されます。

以下の制限に注意してください。

- ヒューマン・ワークフロー、サブプロセスまたはビジネス・ルールのコンポーネントの名前は変更できません。

サービス・コンポーネント、バインディング・コンポーネントまたはBPELサブプロセスの削除

1. コンポーネントまたはサブプロセスを右クリックして、「削除」を選択します。

別のフォルダへのサービス・コンポーネントまたはバインディング・コンポーネントの移動

このタスクはSOAコンポジット・エディタからは実行できません。

2.7.2 「アプリケーション」ウィンドウでのアーティファクトの名前変更、移動および削除方法

表2-13 では、「アプリケーション」ウィンドウで実行可能なリファクタ・タスクを既知の制限とともに説明します。この機能を使用する前に、これらの制限をよく確認してください。

表2-13 コンポーネント・アーティファクトのリファクタ

アクション

「アプリケーション」ウィンドウでの手順

サービス・コンポーネントまたはバインディング・コンポーネントのアーティファクトの名前の変更

1. コンポーネント・ファイルを右クリックし、「リファクタ」→「名前の変更」を選択します。

以下の制限に注意してください。

- SOAコンポジット・エディタでコンポーネントの名前を変更しても、コンポーネント実装ファイル(.bpel、.mplanなど)の名前は変更されません。これによって問題は発生しません。実装ファイルを同じ名前に変更する場合は、「アプリケーション」ウィンドウを使用してください。

- ヒューマン・ワークフロー、サブプロセスまたはビジネス・ルールのコンポーネントの名前は変更できません。

- ビジネス・ルールおよびヒューマン・タスクのアーティファクトの名前変更または移動はサポートされていません。たとえば、ヒューマン・タスクのスキーマ・ファイル(HumanTaskPayload.xsdなど)の名前は変更できますが、.taskファイル内のこのXSDへの参照は更新されません。

- ポート・タイプ、操作および要素の名前は、WSDLエディタおよびXSDエディタでは変更できません。

- ディレクトリまたはアーティファクトの名前は、空白を使用して変更しないでください。名前に空白があると、参照が無効になります。

- SOAプロジェクトおよびコンポジットの名前は変更できます。

サービス・コンポーネント、バインディング・コンポーネントまたはBPELサブプロセスのアーティファクトの削除

1. コンポーネント・ファイルを右クリックし、「リファクタ」→「削除」を選択します。

以下の制限に注意してください。

- 「アプリケーション」ウィンドウでアーティファクトを削除すると、「使用方法の表示」オプションが含まれたメッセージが表示されます。「使用方法の表示」が選択されていると、ファイル内部からアーティファクトへの参照や使用方法が表示されます。「削除」オプションが実行されると、サブプロセス・ファイルのみが削除され、参照は削除されません。必ず最初に「使用方法の表示」を選択してから、削除するファイルへの参照を手動で削除してください。

別のフォルダへのサービス・コンポーネントまたはバインディング・コンポーネントの移動

1. コンポーネント・ファイルを右クリックし、「リファクタ」→「移動」を選択します。

以下の制限に注意してください。

- データベース・アダプタのアーティファクトを移動すると、データベース・アダプタには多数のアーティファクトがあり、それらが暗黙的に名前で参照されていて同じディレクトリに存在する必要があるため、問題が発生する可能性があります。

- コンポーネントの実装ファイル(.mplan、.bpel、.sbpel、.task、.rules、.springなど)は、「アプリケーション」ウィンドウでは移動できません。ただし、これらのファイルの名前は変更できます。

- ディレクトリまたはアーティファクトの名前は、空白を使用して移動しないでください。名前に空白があると、参照が無効になります。

- XSLTファイルを移動する場合、現在の拡張およびスクロールされた状態やXSLTマップ・エディタで最後に選択された項目などの機能が失われます。これは、NonDeployedFilesディレクトリがXSLTファイルと同じフォルダに作成されるためです。このフォルダは、テスト・ファイル、ディクショナリ・ファイル、レポート・ファイル、DVM/XREFテスト・サポート・ファイルなどのデフォルトの場所です。 このディクショナリは、このフォルダには複数のXSLTファイルで使用されるファイルが含まれており、このXSLTファイルとフォルダ内のファイル名には直接的な関係がないため、XSLTファイルが移動された場合も移動されません。

2.8 プロパティ・インスペクタにおけるコンポーネント詳細の表示

プロパティ・インスペクタには、SOAコンポジット・エディタの選択サービス・コンポーネントやバインディング・コンポーネントに関する詳細が表示されます。

プロパティをプロパティ・インスペクタで表示するには:

1. サービス、サービス・コンポーネントまたは参照を選択します。この例では、BPELプロセス・サービス・コンポーネントが選択されます。

プロパティ・インスペクタがリフレッシュされ、一般的なコンポーネント詳細、デプロイメント・ディスクリプタのプロパティを追加するためのセクション、およびアタッチされたセキュリティ・ポリシーが表示されます。図2-24に詳細を示します。

図2-24 プロパティ・インスペクタ

BPELアクティビティをOracle BPELデザイナで編集するには、プロパティ・インスペクタを使用することもできます。詳細は、「BPELアクティビティをプロパティ・インスペクタで編集する方法」および「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。

2.9 セキュリティ・ポリシーの追加

SOAコンポジット・アプリケーションを作成する際に、サービス・バインディング・コンポーネント、サービス・コンポーネントおよび参照バインディング・コンポーネントにポリシーを添付してWebサービスを保護できます。ポリシーの実装方法の詳細は、「ポリシーおよびメッセージ暗号化を使用したセキュリティの有効化」を参照してください。

2.10 SOAコンポジット・アプリケーションのデプロイ

SOAコンポジット・アプリケーションのデプロイには、Oracle WebLogic Serverへの接続の作成、およびOracle WebLogic Server管理対象サーバーへのSOAコンポジット・アプリケーションのアーカイブのデプロイも含まれます。SOAコンポジット・アプリケーションのデプロイ方法の詳細は、「SOAコンポジット・アプリケーションのデプロイ」を参照してください。

2.10.1 デプロイ済SOAコンポジット・アプリケーションの起動方法

SOAコンポジット・アプリケーションから、デプロイ済のSOAコンポジット・アプリケーションを起動できます。

デプロイ済SOAコンポジット・アプリケーションを起動する手順は、次のとおりです。

1. 次のいずれかの方法を使用して、Webサービスまたはパートナ・リンクを作成します。

a. SOAコンポジット・エディタで、「コンポーネント」ウィンドウから「外部参照」スイムレーンに「SOAP」アイコンをドラッグします。

b. Oracle BPELデザイナで、「コンポーネント」ウィンドウの「BPELコンストラクト」セクションから右側のスイムレーンに「パートナ・リンク」をドラッグします。

2. 作成したサービスのタイプに基づいて「SOAリソース・ブラウザ」ダイアログにアクセスします。

a. 「Webサービスの作成」ダイアログから、「既存のWSDLを検索します。」アイコンをクリックします。「WSDLチューザ」ダイアログの「アプリケーション・サーバー」セクションが表示されます。

b. 「パートナ・リンクの編集」ダイアログから、「SOAリソース・ブラウザ」アイコンをクリックします。「WSDLチューザ」ダイアログの「アプリケーション・サーバー」セクションが表示されます。

3. 「アプリケーション・サーバー」が選択されていない場合、選択します。

4. ツリーを開いて、SOAコンポジット・アプリケーションがデプロイされたサーバーへのアプリケーション・サーバー接続を表示します。

5. アプリケーション・サーバー接続を展開します。

6. SOAフォルダおよびパーティションを開きます。図2-25に詳細を示します。

図2-25 SOAコンポジット・アプリケーションの参照

7. コンポジット・サービスを選択します。

8. 「OK」をクリックします。

アプリケーション・サーバー接続の作成方法の詳細は、「アプリケーション・サーバー接続の作成」を参照してください。

2.11 SOAコンポジット・アプリケーションの管理とテスト

SOAコンポジット・アプリケーションを作成してデプロイした後は、Oracle JDeveloperとOracle Enterprise Manager Fusion Middleware Controlを組み合せて使用して、そのSOAコンポジット・アプリケーションを管理およびテストします。

2.11.1 Oracle JDeveloperでのデプロイ済SOAコンポジット・アプリケーションの管理方法

Oracle JDeveloperの「アプリケーション・サーバー・ナビゲータ」から、デプロイ済のSOAコンポジット・アプリケーションを管理できます。管理タスクには、SOAコンポジット・アプリケーション・リビジョンのアンデプロイ、アクティブ化、リタイア、有効化および無効化があります。

注意:

ここで説明する手順は、SOAインフラストラクチャがデプロイされたOracle WebLogic管理サーバーへのアプリケーション・サーバー接続が作成済であることを前提にしています。Oracle WebLogic管理サーバーへの接続を作成すると、管理対象およびクラスタ化されたOracle WebLogic Serverを同じドメインで参照できます。「ファイル」メイン・メニューから、「新規」→「アプリケーション」→「接続」→「アプリケーション・サーバー接続」を選択して、接続を作成します。

1. 「ウィンドウ」メイン・メニューから、「アプリケーション・サーバー」を選択します。

2. 接続名を展開します(この例では「MyConnection」)。

図2-26 に示すように、「SOA」フォルダが表示されます。「SOA」フォルダには、デプロイ済のSOAコンポジット・アプリケーションのリビジョンとサービスがすべて表示されます。これにより、すべてのOracle WebLogic管理サーバー、管理対象のOracle WebLogic Serverおよびクラスタ化されたOracle WebLogic Serverにデプロイされたすべてのアプリケーションを同じドメインで参照できます。図2-26に詳細を示します。

図2-26 アプリケーション・サーバー・ナビゲータ

3. 「SOA」フォルダを展開します。

4. コンポジット・アプリケーションがデプロイされたパーティションを展開します。

図2-27 に示すように、デプロイ済のSOAコンポジット・アプリケーションとサービスが表示されます。

図2-27 デプロイ済のSOAコンポジット・アプリケーション

5. デプロイされているSOAコンポジット・アプリケーションを右クリックします。

6. 実行するオプションを選択します。選択肢として表示されるオプションは、アプリケーションの現在の状態に基づきます。表2-14に詳細を示します。

表2-14 SOAコンポジット・アプリケーションのオプション

オプション

説明

停止

実行中のSOAコンポジット・アプリケーションのリビジョンを停止します。コンポジットが停止されると、そのコンポジットへのすべてのリクエスト(開始またはコールバック)は拒否されます。

注意: 使用するバインディング・コンポーネントによって動作が異なります。たとえば、Webサービス・リクエストの場合は、却下されてコール元に戻されます。JCAアダプタ・バインディング・コンポーネントでは、このような場合、異なる動作になることがあります(リクエストが拒否表に配置されるなど)。

このオプションは、コンポジット・アプリケーションが起動されているときに表示されます。

開始

停止したコンポジット・アプリケーションのリビジョンを再起動します。これにより、新規リクエストを処理できるようになります(却下されません)。メッセージのリカバリは発生しません。

このオプションは、コンポジット・アプリケーションが停止されているときに表示されます。

リタイア

選択したコンポジットのリビジョンをリタイア状態にします。プロセスのライフ・サイクルがリタイア状態の場合、新しいインスタンスは作成できません。既存インスタンスは正常に完了できます。

コンポジット・アプリケーションへの開始リクエストは拒否されてクライアントに返されます。拒否の際の異なるバインディング・コンポーネントの動作については、停止オプションの場合と同様です。

開始されたコンポジット・アプリケーション・インスタンスへのコールバックは正常に実行されます。

このオプションは、コンポジット・アプリケーションがアクティブなときに表示されます。

アクティブ化

リタイア状態のコンポジット・アプリケーションのリビジョンをアクティブ化します。このオプションでの次の動作に注意してください。

- デプロイされると、すべてのコンポジット・アプリケーションは自動的にアクティブになります。

- 新しくデプロイされたコンポジット・アプリケーションの他のリビジョンはアクティブのままで、自動的にリタイアされることはありません。必要であれば、これらは明示的にリタイアする必要があります。

このオプションは、アプリケーションがリタイアされているときに表示されます。

アンデプロイ

選択したコンポジット・アプリケーションのリビジョンをアンデプロイします。このアクションの結果は次のようになります。

- コンポジット・アプリケーションのこのリビジョンは、構成およびモニターできなくなります。

- コンポジット・アプリケーションのこのリビジョンのインスタンスは処理できなくなります。

- すでに完了したプロセスは表示できません。

- 現在実行中のインスタンスの状態が中止になり、このコンポジットに送信された新しいメッセージは処理されません。

- コンポジット・アプリケーションのデフォルトのリビジョン(たとえば2.0)をアンデプロイすると、そのコンポジット・アプリケーションの次に利用可能なリビジョン(たとえば1.0)がデフォルトになります。

デフォルトのリビジョンの設定

選択したコンポジット・アプリケーション・リビジョンをデフォルトとして設定します。

7. デプロイメント・プロファイルが含まれるビルトインのSOAコンポジット・アプリケーション・アーカイブをデプロイする場合、SOAフォルダを右クリックし、「SOAアーカイブのデプロイ」を選択します。このアーカイブは単一アプリケーションのJARファイルまたは複数のアプリケーションが含まれるSOAバンドルZIPファイルで構成されます。

次を選択するように求めるプロンプトが表示されます。

- SOAコンポジット・アプリケーションのアーカイブをデプロイするターゲットSOAサーバー。

- デプロイするアーカイブ。

- アプリケーションに添付する構成プラン。通常、プロジェクトをある環境から別の環境に(たとえば、テスト環境から本番環境に)移動する場合は、JDBC接続文字列や様々なサーバーのホスト名など、環境固有の値をいくつか変更する必要があります。これらの値は、構成プランと呼ばれる単一のテキスト(XML)ファイルを使用して変更できます。構成プランは、Oracle JDeveloperまたはコマンドラインから作成します。構成プランは、プロセスのデプロイメント時に、プロジェクトを別のターゲット環境に適合させるために置換する必要のある値に関するSOAプロジェクトを検索する際に使用されます。これはオプションです。

- 同じリビジョンIDを持つ既存のコンポジットを上書きするかどうか。これにより、アプリケーションのリビジョンを再デプロイできます。

図2-28に詳細を示します。

図2-28 「SOAアーカイブのデプロイ」ダイアログ

詳細は、次のドキュメントを参照してください。

- デプロイメント・プロファイルおよび構成プランの作成方法、および既存のSOAアーカイブのデプロイ方法の詳細は、「SOAコンポジット・アプリケーションのデプロイ」を参照してください

- Oracle Enterprise Manager Fusion Middleware Controlからデプロイ済SOAコンポジット・アプリケーションを管理する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

2.11.2 デプロイ済SOAコンポジット・アプリケーションのテストおよびデバッグ方法

SOAコンポジット・アプリケーションをデプロイすると、Oracle Enterprise Manager Fusion Middleware Controlの「Webサービスのテスト」ページからそのテスト・インスタンスを開始して、XMLペイロード・データを検証することができます。テスト・インスタンスの開始の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

テスト・インスタンスの作成に加え、次のテスト・タスクおよびデバッグ・タスクもOracle JDeveloperで実行できます。

- 本番環境へのデプロイメントの前に、SOAコンポジット・アプリケーションとそのWebサービス・パートナ間の相互作用をシミュレートします。これにより、本番環境へのデプロイメント準備が完了するまでに、プロセスとWebサービス・パートナの相互作用が期待どおりであるかを確認できます。ユニット・テストの作成方法の詳細は、「SOAコンポジット・アプリケーションのテストの自動化」を参照してください。

- Oracle JDeveloperでは、SOAデバッガを使用して、SOAコンポジット・アプリケーションをテストおよびデバッグします。SOAデバッガは、Oracle JDeveloper内でトラブルシューティング環境を提供することによって、SOAコンポジット・アプリケーションの開発サイクルを短縮します。これにより、SOAコンポジット・アプリケーションをOracle JDeveloperでビルドし、それをSOAインフラストラクチャにデプロイし、Oracle Enterprise Manager Fusion Middleware Controlを起動して監査証跡とフロー・トレースのテストまたは表示を行ってから、Oracle JDeveloperに戻って作業を繰り返すという時間のかかるプロセスが必要なくなります。詳細は、「SOAコンポジット・アプリケーションのデバッグおよび監査」を参照してください。

3 デザインタイムMDSリポジトリとの共有データの管理

この章では、フォルダの作成と削除を行う方法、/appsフォルダの内容をJARファイルに対してエクスポートとインポートを行う方法、/appsフォルダの内容を別のSOAデザインタイムOracle Metadata Services Repository (MDSリポジトリ)に転送する方法、リリース11g MDSリポジトリをJARファイルにエクスポートする方法、およびSOA-MDS転送ウィザードを使用してデータをSOAデザインタイムMDSリポジトリと共有する方法を含む、共有データをSOAデザインタイムMDSリポジトリで管理する方法について説明します。

この章の内容は次のとおりです。

- SOAデザインタイムMDSリポジトリ管理の概要

- デフォルトSOA-MDSの場所の変更

- SOAデザインタイムMDSリポジトリとのデータの共有

- /appsフォルダの下におけるサブフォルダの作成と削除

- JARファイルへの/appsフォルダの選択内容のエクスポート

- /appsフォルダへのJARファイルの内容のインポート

- 別のMDSリポジトリへの/appsフォルダの選択内容の転送

- JARファイルへの既存のリリース11gのエクスポート

- SOAデザインタイムMDSリポジトリ内のファイルの参照

3.1 SOAデザインタイムMDSリポジトリ管理の概要

SOAコンポジット・アプリケーションを作成すると、ファイルベースのSOAデザインタイムMDSリポジトリが自動的に作成されます。MDSリポジトリ名は変更できませんが、既存のファイルベースのリポジトリを指すように変更できます。通常は、バージョン制御システム(MDS)の場所を指します。共有操作はデザインタイム・リポジトリに対して行われます。これらの操作をデータベース・ベースMDSリポジトリに対して実行できません。

Oracle JDeveloperで、SOAデザインタイムMDSリポジトリに対して次の操作を実行できます。

- Oracle SOA Suiteによって認識される次のフォルダをSOAデザインタイムMDSリポジトリで参照します。

- /apps: Oracle Service Busアーティファクトを含めて、共有データが格納されます。

- /appsフォルダや/appsのサブフォルダの下に直接フォルダを作成します。

- /appsフォルダの下にあるファイルとサブフォルダを削除します。/appsフォルダ自体は、削除できません。

- /appsフォルダの選択内容をJARファイルにエクスポートします。/appsフォルダ自体は、JARファイルに含まれていません。

- JARファイルの内容を/appsフォルダの下にインポートします。JARファイルに/appsがルート・フォルダとして含まれていると、デザインタイムMDSリポジトリの/appsフォルダの下に作成されます。これによって、/apps/appsのトップレベル・ディレクトリ構造が用意されます。

- あるMDSリポジトリから別のMDSリポジトリに/appsフォルダの内容を転送します。

- 既存のMDSリポジトリ(たとえば、リリース11gデータベース・ベースのMDSリポジトリ)をJARファイルにエクスポートします。このJARファイルはリリース12cデザインタイムMDSリポジトリにインポートできます。

3.1.1 デフォルトSOAデザインタイムMDSリポジトリ接続の概要

SOAコンポジット・アプリケーションを作成すると、SOA_DesignTimeRepositoryという名前のファイルベースのSOAデザインタイムMDSリポジトリ接続が自動的に含まれます。デフォルトのディレクトリの場所は$JDEV_USER_DIR/soamdsです。

この接続は次の機能を提供します。

- 設計時に使用するファイル・ベースMDSリポジトリ。データベース・ベース型デザインタイムMDSリポジトリは、サポートされません。

- すべてのMDSリポジトリは参照可能です。

- デフォルトのリポジトリ場所は、別のフォルダやバージョン制御の場所を指すように変更できます。

- すべてのSOA-MDS操作では、このSOAデザインタイムMDSリポジトリを使用します。

- ウィザードにより、このMDSリポジトリで、WSDLやスキーマ・ファイルなどのデザインタイム・アーティファクトをSOAプロジェクトから共有できます。

注意:

- 共有データをSOAデザインタイムMDSリポジトリに追加して、リポジトリをバージョン制御システムでバックアップする場合、このデータをバージョン制御システムに追加する操作はOracle SOA Suiteでは提供されません。この共有データをバージョン制御システムに追加する必要があります。

- adf-config.xmlファイルにSOA-MDSリポジトリ(/appsネームスペース)が事前構成されているリリース11g SOAコンポジット・アプリケーションがある場合、すべての共有および消費操作は、adf-config.xmlに定義されている既存のリポジトリに対して実行されます。

3.2 デフォルトSOA-MDSの場所の変更

SOAコンポジット・アプリケーションが作成されると、名前がSOA_DesignTimeRepositoryであるデフォルトSOA-MDS接続が自動的に含まれます。SOAデザインタイムMDSリポジトリの/appsフォルダが自動的に作成されます。

注意:

Oracle JDeveloperプロジェクトのファイルがSOA_DesignTimeRepositoryを使用して共有されている場合は、元のファイルがSOAプロジェクトからデフォルトのSOA-MDSリポジトリに移動されます。

3.2.1 デフォルトSOA-MDSの場所を変更する方法

デフォルトのSOA-MDSの場所を変更する手順は、次のとおりです。

1. SOAコンポジット・アプリケーションを作成します。

2. 「ウィンドウ」メイン・メニューから、「リソース」を選択します。

3. 「コンポーネント」ウィンドウで、「リソース」をクリックします。

4. SOA-MDSを展開します。図3-1 に示すようなアーティファクトが表示されます。

- SOAコンポジット・アプリケーションで自動的に作成される際に名前がSOA_DesignTimeRepositoryであるSOA-MDS接続。

- MDSリポジトリの/appsフォルダ。このフォルダは最初は空です。

図3-1 Oracle JDeveloperの「リソース」ウィンドウ

5. SOA_DesignTimeRepository接続を右クリックして「プロパティ」を選択し、バージョン制御の場所を指すようにします。

MDS-SOA接続の編集ダイアログが表示されます。

6. 「MDSルート・フォルダ」フィールドで「参照」をクリックします。

7. /appsフォルダのバージョン制御の場所を選択して、「選択」をクリックします。SOA-MDSブラウザには、/appsフォルダおよび/soaフォルダのみが表示されます。そのため、/appsが選択したバージョン制御の場所にない場合は、ブラウザによってレンダリングされません。

図3-2 に示すように、指定された場所がMDS-SOA接続の編集ダイアログに表示されます。

図3-2 「SOA-MDS接続の編集」ダイアログ

8. 「OK」をクリックして、SOA_DesignTimeRepository接続を展開します。

図3-3 に示すように、手順7で指定された場所で/appsフォルダが移入されます。

図3-3 移入された/appsフォルダ

3.3 SOAデザインタイムMDSリポジトリとのデータの共有

SOA-MDS転送ウィザードによって、SOAデザインタイムMDSリポジトリとWSDL、XSD、WADLおよびXQueryのファイルを共有できます。これらのファイルは他のSOAコンポジット・アプリケーションと共有できます。

ウィザードでは最初に、現在のアプリケーションのadf-config.xmlファイルで定義された既存のデザインタイムMDSリポジトリとファイルの共有を試行します。MDSリポジトリがadf-config.xmlファイルで定義されていないと、SOA_DesignTimeRepositoryを使用してアーティファクトが共有されます。

注意:

- XSD、WSDL、WADLおよびXQueryのファイルのみを共有できます。さらに、これらのファイル・タイプのみがデザインタイムMDSリポジトリからランタイムMDSリポジトリに転送できます。

- ネイティブのフォーマット・ビルダー・ウィザードを使用して作成した「アプリケーション」ウィンドウでXSDファイルを右クリックした場合、「SOAデザインタイムMDSリポジトリを使用して共有」オプションは使用できません。

3.3.1 SOAデザインタイムMDSリポジトリとデータを共有する方法

SOAデザインタイムMDSリポジトリとデータを共有する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで共有するファイル(この例ではXSDファイル)を右クリックして、「SOAデザインタイムMDSリポジトリを使用して共有」を選択します。図3-4に詳細を示します。

図3-4 SOAデザインタイムMDSリポジトリとのデータ共有

SOA-MDS転送ウィザードの「ようこそ」ページが表示され、選択したファイルがSOAデザインタイムMDSリポジトリに転送されることが示されます。

2. 「次へ」をクリックします。

「ターゲットの選択」ダイアログが表示されます。

3. デザインタイムMDSリポジトリを参照し、選択したアーティファクトを共有するためのターゲット・フォルダを選択して、「次へ」をクリックします。また、ファイルを共有するためのサブフォルダを作成したり、既存のフォルダを検索できます。図3-5に詳細を示します。

図3-5 「SOA-MDS転送ウィザード」の「ターゲットの選択」ページ

「依存性」ダイアログが表示されます。

4. 図3-6 に示すように、デザインタイムMDSリポジトリにあるターゲットoramds URLの場所に転送するファイルを確認します。

さらに別の依存ファイルも表示できます。たとえば、WSDLファイルを選択したと仮定します。WSDLファイルにはスキーマ・ファイル(潜在的に複数のファイル)に依存性が存在する場合があるので、これらのXSDファイルも表示されます。

図3-6 「SOA-MDS転送ウィザード」の「依存性」ページ

緑色のチェック・マークは、ファイルのパスが正しく解決可能であることを示します。

注意:

- URLがアクセスできないと、エラー・アイコンが表示されます。たとえば、数個の親レベル(たとえば、../../../)を横断するスキーマに依存性があるWSDLファイルを転送すると仮定します。そのような参照がWSDLに存在する場合、適切なターゲット・フォルダを選択しないと、URLの指す場所が/appsフォルダを超えている場合があり、SOAインフラストラクチャでアクセスできません。エラー・アイコンは、ターゲットURLをアクセスできずに転送を続行できないことを示します、取り消すか、「戻る」をクリックして、異なるターゲット・フォルダを選択する必要があります。つまり、すべてのURLの接続先は、/appsフォルダで始まる必要があります。

- ファイル転送は、ターゲットSOAデザインタイムMDSリポジトリの/appsフォルダに関係します。依存ファイルは一般的に同じパラレル・レベルにあります。たとえば、転送用に選択したWSDLファイルがWSDLsフォルダにあり、依存するXSDファイルがSchemasフォルダにあります。「アプリケーション」ウィンドウで、SOAコンポジット・アプリケーションのSOAフォルダの下で両方のフォルダが同じパラレル・レベルにあります。ただし、依存ファイルが異なるレベル(共有するファイルよりも高いレベル)にある場合、ファイルの相対階層を判別する必要があります。たとえば、../../../.xsdの場所にあるXSDファイルをfoo.wsdlが参照する場合、ターゲットのデザインタイムMDSリポジトリにおいてappsの下で3つのサブフォルダを手動で作成し、foo.wsdlを下位のフォルダ・レベルに共有する必要があります。これによって、XSDをappsレベルで共有できます。

5. ファイルをオーバーライドする場合は、「ドキュメントがターゲットMDSリポジトリに存在する場合は上書きします」を選択して、「次へ」をクリックします。このチェック・ボックスを選択しない場合で、目的の場所にファイルがすでに存在するときは、ファイルは転送されず、エラー・メッセージが表示されます。特定のファイルを選択的に転送できません。

「参照」ダイアログが表示されます。

6. 図3-7 に示すように、適切なoramds URLで転送した後に、変更するファイルを表示して、「終了」をクリックします。移動中のファイルに依存するファイルがこのリストに含まれます。移動されるファイルのoramds URLを反映するために、すべての依存ファイルが変更されます。

図3-7 「SOA-MDS転送ウィザード」の「参照」ページ

7. 転送が正常に完了したことを示すメッセージのプロンプトが表示されたら、「OK」をクリックします。

完了すると、次の更新が行われます。

- 選択したアーティファクトは、「リソース」ウィンドウのSOA-MDS接続の下に表示されます。

- 「アプリケーション」ウィンドウのadf-config.xmlファイルが、/appsネームスペースで変更されます。

<namespace path="/apps" metadata-store-usage="mstore-usage_2"/>

SOAデザインタイムMDSリポジトリ・ホームを内部的に指す変数が設定されます。

value="${soamds.apps.home}

- アーティファクトの参照(たとえば、WSDLファイル)が更新され、oramds URLの場所を指すようになります。

3.4 /appsフォルダの下におけるサブフォルダの作成と削除

SOAデザインタイムMDSリポジトリの/appsフォルダの下でサブフォルダを作成および削除できます。/appsフォルダは削除できません。

3.4.1 /appsフォルダの下でサブフォルダの作成と削除を行う方法

/appsフォルダの下でサブフォルダの作成と削除を行うには:

1. /appsフォルダまたは/appsのサブフォルダを右クリックして「フォルダの作成」を選択し、バージョン制御の場所を指すようにします。

「フォルダの作成」ダイアログが表示されます。

2. フォルダの名前を入力(この例では、Fooを入力)し、「OK」をクリックします。

図3-8 に示すように、/appsフォルダの下にフォルダが作成されます。

図3-8 /appsフォルダの下にある新規サブフォルダ

3. 削除するフォルダ(この例では、Foo)を右クリックし、「削除」をクリックします。

図3-9 に示すように、フォルダが削除されます。

図3-9 /appsフォルダの下で削除されたサブフォルダ

3.5 JARファイルへの/appsフォルダの選択内容のエクスポート

SOAデザインタイムMDSリポジトリの/appsフォルダで選択内容をJARファイルにエクスポートできます。/appsフォルダ自体は、JARにエクスポートされません。

3.5.1 /appsフォルダの選択内容をJARファイルにエクスポートする方法

/appsフォルダの選択内容をJARファイルにエクスポートするには:

1. 図3-10 に示すように、エクスポートする内容が含まれるSOA-MDS接続(たとえば、デフォルトのSOA_DesignTimeRepository接続や別の接続)を右クリックして、「Jarにエクスポート」を選択します。

図3-10 「Jarにエクスポート」コマンド

「Jarにエクスポート」ダイアログが表示されます。

2. 表3-1の説明に従って、環境に適した値を指定し、「OK」 をクリックします。

表3-1 「Jarにエクスポート」ダイアログ

フィールド

説明

エクスポートするドキュメントの選択

ファイルかフォルダの名前を入力して、「検索」をクリックするか、手動で/appsフォルダを展開して識別し、JARファイルにエクスポートするフォルダとファイルを選択します。

選択ドキュメントのプレビュー

エクスポートする内容のプレビューを選択します。

JAR名

「参照」をクリックして、選択したフォルダおよびファイルをエクスポートするJARファイルを選択します。

「Jarにエクスポート」ダイアログは図3-11 のようになります。

図3-11 「Jarにエクスポート」ダイアログ

3. エクスポートが成功したことを示すメッセージのプロンプトが表示されたら、「OK」をクリックします。

3.6 /appsフォルダへのJARファイルの内容のインポート

SOAデザインタイムやデータベース・ベースのMDSリポジトリの/appsフォルダにJARファイルの内容をインポートできます。/appsがルート・フォルダとして含まれているJARファイルをインポートすると、デザインタイムMDSリポジトリの/appsフォルダの下に作成されます。これによって、/apps/appsのトップレベル・ディレクトリ構造が用意されます。

3.6.1 JARファイルの内容を/appsフォルダにインポートする方法

JARファイルの内容を/appsフォルダにインポートするには:

1. JARファイルのインポート先となるSOA-MDS接続(たとえば、デフォルトのSOA_DesignTimeRepository接続や別の接続)を右クリックして、「Jarからインポート」を選択します。

2. 「参照」をクリックし、インポートするJARを選択します。

図3-12 に示すように、「Jarからインポート」ダイアログが表示されます。

図3-12 「Jarからインポート」ダイアログ

緑色のチェック・マークは、コンテンツがターゲット・リポジトリに存在しないことを示します。コンテンツがターゲット・リポジトリに存在すると、警告アイコンが表示されます。「インポート」をクリックしてコンテンツを上書きするか、「取消」をクリックしてインポート操作全体を取り消すことを選択できます。特定のファイルを選択的にインポートできません。

3. 「インポート」をクリックします。警告アイコンのあるアーティファクトは上書きされます。

図3-13 に示すように、インポートされるJARファイルの内容が/appsフォルダの下に表示されます。

図3-13 「リソース」ウィンドウでのインポートされたJARファイルの内容

3.7 別のMDSリポジトリへの/appsフォルダの選択内容の転送

あるMDSリポジトリの/appsフォルダの選択内容を別のMDSリポジトリの/appsフォルダに転送できます。転送先となるMDSリポジトリのタイプに制限はありません。たとえば、ファイルベース・リポジトリの選択内容をデータベース・ベースMDSリポジトリに移動できますし、その逆もできます。

注意:

Oracle BPELデザイナ、ヒューマン・タスク・エディタまたはその他のエディタを開いた状態で、/appsフォルダの内容を別のMDSリポジトリに転送しないでください。これを行う場合は、転送完了後にエディタを閉じてから再度開いてください。開いた状態のエディタでは、転送による変更が反映されず、完全に閉じないかぎり同期化されない状態になります。

3.7.1 /appsフォルダの選択内容を別のMDSリポジトリに転送する方法

/appsフォルダの選択内容を別のMDSリポジトリに転送する手順は、次のとおりです。

1. 転送する内容が含まれるSOA-MDS接続(たとえば、デフォルトのSOA_DesignTimeRepository接続や別の接続)を右クリックして、「転送」を選択します。図3-14に詳細を示します。

図3-14 「転送」メニュー・オプション

「SOA-MDSに転送」ダイアログが表示されます。

2. 表3-2の説明に従って、環境に適した値を指定し、「OK」 をクリックします。

表3-2 「SOA-MDSに転送」ダイアログ

フィールド

説明

転送するドキュメントの選択

転送する内容を選択します。

選択ドキュメントのプレビュー

転送する内容のプレビューを選択します。

ターゲット接続

内容の転送先となるMDSリポジトリのSOA-MDS接続を選択します。

「SOA-MDSに転送」ダイアログは図3-15 のようになります。

図3-15 「SOA-MDSに転送」ダイアログ

3. 転送が成功したことを示すメッセージのプロンプトが表示されたら、「OK」をクリックします。

手順2の「ターゲット接続」フィールドで選択したSOA-MDSターゲット接続の/appsフォルダの下に内容が表示されます。図3-16に詳細を示します。

図3-16 選択されたSOA-MDS接続の/appsフォルダの下で表示されている内容

3.8 JARファイルへの既存のリリース11g MDSリポジトリのエクスポート

リリース12cデザインタイムMDSリポジトリにインポートできるJARファイルにリリース11g MDSリポジトリをエクスポートできます。adf-config.xmlファイルが/appsで更新され、情報が格納されます。/appsが定義されたadf-config.xmlファイルがある(つまり、既存の共有リポジトリがある)場合は、リリース12cのリポジトリもエクスポートできます。

3.8.1 既存のリリース11g MDSリポジトリをJARファイルにエクスポートする方法

既存のリリース11g MDSリポジトリをJARファイルにエクスポートする手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、エクスポートするプロジェクトのadf-config.xmlを右クリックして、「SOA-MDSコンテンツのエクスポート」を選択します。図3-17に詳細を示します。

図3-17 「アプリケーション」ウィンドウからの11g MDSリポジトリのエクスポート

「Jarにエクスポート」ダイアログが表示されます。

2. JARファイルにエクスポートするリリース11g MDSリポジトリを選択します。

3. JARファイルをリリース12cデザインタイムMDSリポジトリにインポートするには、「/appsフォルダへのJARファイルの内容のインポート」を参照してください。

3.9 SOAデザインタイムMDSリポジトリ内のファイルの参照

SOAデザインタイムMDSリポジトリで、ファイルを参照および選択できます。たとえば、「Webサービスの作成」ダイアログからアクセスする「WSDLチューザ」ダイアログには、図3-18 に示すとおり、SOAデザインタイムMDSリポジトリの選択項目が含まれます。

図3-18 「WSDLチューザ」ダイアログのSOA-MDSの選択

「タイプ・チューザ」ダイアログには「最近使用したファイル」フォルダが含まれ、このフォルダの情報はOracle JDeveloperセッションの間保持されます。たとえば、新しいBPELプロセスを作成し、SOAデザインタイムMDSリポジトリのスキーマから入力変数を定義する場合は、一度このスキーマに移動します。同じスキーマから出力変数を定義する場合は、そのスキーマは「最近使用したファイル」フォルダに引き続き表示されています。図3-19 に、「最近使用したファイル」フォルダを示します。

図3-19 タイプ・チューザ

第II部 BPELプロセス・サービス・コンポーネントの使用

この部では、BPELプロセス・サービス・コンポーネントについて説明します。

この部は、次の章で構成されています。

- Oracle BPEL Process Managerのスタート・ガイド

- BPELプロセスの相互作用パターンの概要

- BPELプロセスでのXMLデータの操作

- BPELプロセスからの同期Webサービスの起動

- BPELプロセスからの非同期Webサービスの起動

- 相関セットおよびメッセージ集約の使用

- BPELプロセスでのパラレル・フローの使用

- BPELプロセスでの条件分岐の使用

- BPELプロセスでのフォルト処理の使用

- BPELプロセスでのトランザクションおよびフォルト伝播のセマンティクス

- BPELプロセスへのJavaおよびJava EEコードの組込み

- BPELプロセスでのイベントおよびタイムアウトの使用

- マスター・プロセスと詳細プロセスの調整

- 通知サービスの使用

- Oracle BPEL Process Managerセンサーと分析の使用

4 Oracle BPEL Process Managerのスタート・ガイド

この章では、Oracle BPEL Process Managerの基本操作について説明します。アクティビティ、パートナリンク、アダプタ、モニターなどの主要なBPEL設計機能とともに、BPELプロセスの作成と検証について説明します。

この章の内容は次のとおりです。

- BPELプロセス・サービス・コンポーネントの概要

- アクティビティの概要

- パートナ・リンクの概要

- パートナ・リンクの作成

- アダプタの概要

- BPELプロセス・モニターの概要

4.1 BPELプロセス・サービス・コンポーネントの概要

この項では、設計環境でのBPELプロセス・サービス・コンポーネントの概要を説明します。

4.1.1 BPELプロセス・サービス・コンポーネントの追加方法

で、BPELプロセス・サービス・コンポーネントをSOAコンポジット・アプリケーションに追加します。

BPELプロセス・サービス・コンポーネントを追加する手順は、次のとおりです。

1. 表4-1 の説明に従って、Oracle JDeveloperを起動します。

表4-1 Oracle JDeveloperの起動

起動対象

Windowsの場合

UNIXの場合

Oracle JDeveloper

a. JDev_Oracle_Home\jdeveloper\JDev\bin\jdev.exeをクリックするか、ショートカットを作成します。

a. $ORACLE_HOME/jdeveloper/jdev/bin/に移動します。

b. 次のコマンドを実行します。

./jdev

2. 次のいずれかの方法を使用して、BPELプロセス・サービス・コンポーネントを追加します。
既存のSOAコンポジット・アプリケーションのサービス・コンポーネントとして追加する方法:

「コンポーネント」ウィンドウの「コンポーネント」セクションから、「BPELプロセス」サービス・コンポーネントをにドラッグします。これにより、図4-1 に示す「BPELプロセスの作成」ダイアログが表示されます。

新規アプリケーションに追加する方法:

a. 「アプリケーション」ウィンドウから、「ファイル」→「新規」→「アプリケーション」の順に選択します。

b. 「カテゴリ」リストの「一般」で、「アプリケーション」を選択します。

c. 「項目」リストで「SOAアプリケーション」を選択し、「OK」をクリックします。
これにより、SOAアプリケーションの作成ウィザードが起動します。

d. 「アプリケーション名」ダイアログで、「アプリケーション名」フィールドにアプリケーション名を入力します。

e. 「ディレクトリ」フィールドで、デフォルトの場所を受け入れるか、SOAコンポジット・アプリケーションを作成する新しいディレクトリ・パスを入力します。

f. 「次へ」をクリックします。

g. 「プロジェクト名」ダイアログで、「プロジェクト名」フィールドに名前を入力します。

h. 「ディレクトリ」フィールドで、デフォルトの場所を受け入れるか、プロジェクトを作成する新しいディレクトリ・パスを入力します。

i. 「次へ」をクリックします。

j. 「開始」セクションでは、「標準コンポジット」が選択されていることを確認してください。他の選択である「SOAテンプレート」により、SOAプロジェクトの再利用可能な部分を作成して、新規プロジェクトを進めることができます。詳細は、「Oracle SOA Suiteテンプレートおよび再使用可能なサブプロセス」を参照してください。

k. 「プロジェクトのSOA設定」ダイアログで、BPELプロセスを使用するコンポジットを選択します。

l. 「終了」をクリックします。
これにより、図4-1 に示す「BPELプロセスの作成」ダイアログが表示されます。

図4-1 「BPELプロセスの作成」ダイアログ

3. 表4-2 に示すように、必要な詳細を指定します。

注意:

同じ.bpelファイルでBPEL 1.1とBPEL 2.0の構文を使用することはできません。ただし、同じSOAコンポジット・アプリケーションにBPEL 1.1プロジェクトとBPEL 2.0プロジェクトを含めることができます。

表4-2 「BPELプロセスの作成」ダイアログ

フィールド

説明

BPEL仕様

作成するBPELプロセスのタイプを選択します。

- BPEL 2.0仕様
BPEL 2.0仕様をサポートするBPELプロジェクトを作成します。これはデフォルト選択です。

- BPEL 1.1仕様
BPEL 1.1仕様をサポートするBPELプロジェクトを作成します。

名前

BPELプロセスの名前を入力するか、またはデフォルト名をそのまま使用します。入力した名前が、「アプリケーション」ウィンドウのBPELプロセスおよびWeb Services Description Language (WSDL)ファイルのファイル名になります。

BPELプロセスの作成時は、必ず完全に一意の名前を使用してください。次のものを作成しないでください。

- 先頭が数値のプロセス名(1SayHelloなど)。

- ハイフンを含むプロセス名(Say-Helloなど)。

- 同じ名前で、大/小文字が異なる2つのプロセス名(SayHelloとsayhelloなど)。
ビジネス・インテリジェンス(BI)のデータ・オブジェクト名は、Oracle BAMサーバーではすべて大文字の形式で生成されるため、これが特に重要です。たとえば、BPELProcess1という名前のBPELプロセスを作成する場合、デプロイ後のOracle BAM BIデータ・オブジェクトとしてはBI_DEFAULT_PROJECT1_BPELPROCESS1というBI名が生成されます。BPELProcess1およびBPELPRocess1の2つのBPELプロセスを作成すると、同じBIデータ・オブジェクト名が生成されます。

- 500文字を超えるプロセス名。

- ASCIIでないプロセス名。BPELプロセス名はSOAプロジェクトのディレクトリおよびファイルの名前に使用されますが、これが問題を引き起こす可能性があります。

ネームスペース

ネームスペースのデフォルトのパスを使用するか、カスタム・パスを入力します。

ディレクトリ

BPELプロセス・サービス・コンポーネントのアーティファクトを配置するディレクトリを指定するか、project_root_directory/SOA/BPELのデフォルト・ディレクトリをそのまま使用します。

ディレクトリ・パスを変更できますが、ディレクトリがSOAフォルダ(つまりproject_root_directory/SOA)の下にあることを確認してください。ディレクトリをSOAの外部に指定すると、エラー・メッセージが表示され、BPELプロセスは作成されません。

テンプレート

設計するBPELプロセス・サービス・コンポーネントのタイプに基づくテンプレートを選択します。テンプレートによって、「アプリケーション」ウィンドウにデフォルト・ファイルの基本セット(process_name.wsdlおよびprocess_name.bpel)が提供され、これらのファイルを使用してBPELプロセス・サービス・コンポーネントの設計を開始できます。

- 非同期BPELプロセス: BPELプロセス・コンポーネント・フローを開始するreceiveアクティビティ(デフォルト)、およびクライアントを非同期にコールバックするinvokeアクティビティを使用して、非同期プロセスを作成します。このタイプはデフォルトで選択されています。詳細は、「BPELプロセスからの非同期Webサービスの起動」を参照してください。

- 同期BPELプロセス: BPELプロセス・サービス・コンポーネント・フローを開始するreceiveアクティビティ(デフォルト)、および結果を返すreplyアクティビティを使用して、同期プロセスを作成します。詳細は、「BPELプロセスからの同期Webサービスの起動」を参照してください。

- 一方向BPELプロセス: 一方向コール・インタフェース定義でプロセスを作成します。

- サービスを後で定義: アクティビティを含まない空のBPELプロセス・サービス・コンポーネントを作成する場合に選択します。

- WSDLに基づく: 既存のWSDLファイルによって定義されたインタフェースを使用してBPELプロセスを作成します。使用するWSDL Uniform Resource Locator (URL)、ポート・タイプおよびコールバック・ポート・タイプを指定する必要があります。

- イベントのサブスクライブ: ビジネス・イベントをサブスクライブできるBPELプロセスを作成します。このオプションを選択すると、ダイアログがリフレッシュされてイベント表が表示されます。「追加」アイコンをクリックすると、サブスクライブするイベントを選択できます。選択した内容は、イベント表に表示されます。その後、一貫性レベルと、このイベントをパブリッシュするかどうかを選択できます。「フィルタ」アイコンをクリックして、選択したイベントのフィルタ式を作成することもできます。この選択によって、「式ビルダー」ダイアログが表示されます。詳細は、「ビジネス・イベントおよびイベント配信ネットワークの使用」を参照してください。

サービス名

デフォルト値をそのまま使用するか、またはこのプロセスで公開されているサービス名を入力します。invoke、receive、OnMessageまたはreplyアクティビティを開くと、デフォルトで、サービス名が「パートナ・リンク」フィールドに表示されます。この名前はパートナ・リンクと同じ名前です。

SOAPサービスとして公開

インバウンドSimple Object Access Protocol (SOAP) Webサービス・バインディング・コンポーネントに自動的に接続(連結)されるBPELプロセス・サービス・コンポーネントを作成する場合は、このチェック・ボックスを選択します。このチェック・ボックスを選択しないと、BPELプロセス・サービス・コンポーネントは、SOAコンポジット・エディタでスタンドアロン・コンポーネントとして作成されます。このBPELプロセス・サービス・コンポーネントは後からサービスに明示的に関連付けることができます。このチェック・ボックスはデフォルトで選択されています。

配信

注意: このフィールドは、「テンプレート」リストで次のいずれかのテンプレートを選択した場合に表示されます。

- 非同期BPELプロセス

- 一方向BPELプロセス

- イベントのサブスクライブ

配信レイヤーでのプロセスの永続ポリシーを設定します。このリストを使用すると、oneWayDeliveryPolicyデプロイメント・ディスクリプタのプロパティの値を指定できます。有効な値は、次のとおりです。

- async.persist: メッセージはデータベースに保存されます。この設定の場合、信頼性は確保されますが、データベースのパフォーマンスに多少の影響が出ます。システムの全体的なパフォーマンスに影響が出ることもあります。これはデフォルト値です。

- async.cache: 受信した配信メッセージはインメモリー・キャッシュにのみ保存されます。信頼性よりパフォーマンスを優先する場合は、この設定を検討してください。async.cacheに設定すると、一方向メッセージの到着頻度が配信の頻度よりかなり高い場合や、サーバー障害が発生した場合には、メッセージが失われる可能性があります。また、システムが過負荷の状態になり(メッセージがスケジュール済キューにたまり)、メモリー不足エラーが発生することもあります。各自のユースケース・シナリオを検討し、この設定が適切かどうかを判断してください。
高可用性環境でoneWayDeliveryPolicyをasync.cacheに設定すると、サーバー・クラッシュ発生時に実行途中の起動メッセージおよびコールバック・メッセージが失われたり、重複したりすることがあります。async.cacheに対しては、サーバーのフェイルオーバーはサポートされていません。詳細は、『高可用性ガイド』を参照してください。

- sync: 同じスレッドで直接起動が発生します。呼出しキューのメッセージのスケジューリングはバイパスされ、BPELインスタンスが同期的に呼び出されます。この設定は、データベースのパフォーマンスに影響を与えることがあります。

このプロパティのトランザクションおよびフォルト伝播のセマンティクスの詳細は、「BPELプロセスでのトランザクションおよびフォルト伝播のセマンティクス」を参照してください。

プロパティ・インスペクタでこのプロパティの値を変更する方法については、「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。

トランザクション

注意: このフィールドは、「テンプレート」リストで「同期BPELプロセス」を選択した場合に表示されます。

コールを開始するBPELインスタンスのトランザクション動作を設定します。このリストを使用すると、transactionデプロイメント・ディスクリプタのプロパティの値を指定できます。有効な値は、次のとおりです。

- required: リクエスト/レスポンス(開始)環境では、この設定によって、トランザクションがある場合はコール元トランザクションが結合され、トランザクションがない場合は新規トランザクションが作成されます。「配信」リスト値(oneWayDeliveryPolicyプロパティ)がsyncに設定されている一方向開始環境では、起動メッセージは、同じトランザクションの同一スレッドを使用して処理されます。これはデフォルト値です。

- requiresNew: 新規トランザクションが実行のために作成され、既存のトランザクションがある場合はそのトランザクションが一時停止されます。この動作は、リクエスト/レスポンス(開始)環境、および「配信」リスト値(oneWayDeliveryPolicyプロパティ)がsyncに設定されている一方向開始環境の両方に適用されます。

- notSupported: ビジネス・トランザクションのアクティビティをトランザクションなしで実行できます。

注意: このプロパティは、中間プロセスのreceiveアクティビティには適用されません。この場合は、別のトランザクションの別のスレッドを使用してメッセージが処理されます。これは、相関が必要であり、常に非同期で処理されるためです。

このプロパティのトランザクションおよびフォルト伝播のセマンティクスの詳細は、「BPELプロセスでのトランザクションおよびフォルト伝播のセマンティクス」を参照してください。

プロパティ・インスペクタでこのプロパティの値を変更する方法については、「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。

入力

デフォルトの入力XSDスキーマをそのまま使用するか、「検索」アイコンをクリックして別のXSDを選択します。「検索」アイコンをクリックすると、「タイプ・チューザ」ダイアログが表示されます。インポートしたスキーマを参照して、入力要素(注文書など)を選択します。「タイプ・チューザ」ダイアログで、既存のスキーマまたはWSDLをインポートすることもできます。

「タイプ・チューザ」ダイアログには、使用するコンテキストに基づいて情報が表示されます。たとえば、変数に対して単純、メッセージまたは要素のタイプを選択した場合、ダイアログには、XMLスキーマ単純型、WSDLファイル・メッセージ・タイプまたはXMLスキーマ要素がそれぞれ表示されます。メッセージ・パートのタイプを選択すると、プロジェクトのスキーマ・ファイル、XMLスキーマ単純型およびプロジェクトのWSDLファイルがダイアログに表示されます。

出力

デフォルトの出力XSDスキーマをそのまま使用するか、「検索」アイコンをクリックして別のXSDを選択します。「検索」アイコンをクリックすると、「タイプ・チューザ」ダイアログが表示されます。インポートしたスキーマを参照して、出力要素(注文書など)を選択します。

4. 「OK」をクリックします。
図4-2 に示すセクションがOracle BPELデザイナに表示されます。

図4-2 Oracle BPELデザイナのセクション

このビューの各セクションを使用して、特定の設計およびデプロイメント・タスクを実行できます。表4-3 に、図4-2 にリストされている各セクションを示します。

表4-3 Oracle JDeveloperのセクション

要素

説明

「アプリケーション」ウィンドウ(左上)

SOAプロジェクトのディレクトリとファイルが表示されます。「SOA」フォルダの下にある主要なディレクトリとファイルには、次が含まれています。

- BPEL
BPELプロセス・サービス・コンポーネント・ファイル(.bpel)が表示されます。

- イベント
ビジネス・イベント・ファイル(.edn)が表示されます。

- スキーマ
BPELプロセス・スキーマ・ファイルが表示されます。

- テスト・スイート
テスト・スイート・ファイルが表示されます。詳細は、「SOAコンポジット・アプリケーションのテストの自動化」を参照してください。

- トランスフォーメーション
トランスフォーメーションXSLTマッパー・ファイル(.xsl)およびXQueryマッパー・ファイル(.xqy)が表示されます。

- WSDL
BPELプロセスWSDLファイルが表示されます。

- composite_name
SOAコンポジット・アプリケーション全体(composite.xmlファイルと呼ぶ場合があります)を説明します。このファイルの詳細は、「SOAアプリケーションおよびプロジェクト作成時の処理内容」を参照してください。

Oracle BPELデザイナ(「設計」タブ)

設計するBPELプロセス・サービス・コンポーネントがグラフィカルに表示されます。このビューは、次のいずれかの処理を実行すると表示されます。

- 「アプリケーション」ウィンドウで.bpelファイル名をダブルクリックした場合

- .bpelファイルを選択して、デザイナの下部にある「設計」タブをクリックした場合

- SOAコンポジット・エディタでBPELプロセス・コンポーネントをダブルクリックした場合

アクティビティのドラッグ、パートナ・リンクの作成などによるBPELプロセス・サービス・コンポーネントの設計に応じて、「設計」ウィンドウは変化します。

「コンポーネント」ウィンドウ(右上)

BPELプロセス・サービス・コンポーネントに追加可能なアクティビティが表示されます。アクティビティはビルディング・ブロックです。「コンポーネント」ウィンドウの 「BPELコンストラクト」、「サブプロセス」 (最初は空です)および「Oracle Extensions」のセクションでは、BPELプロセス・サービス・コンポーネントのデザイナにドラッグするサブプロセスとアクティビティのセットが表示されます。「コンポーネント」ウィンドウには、デザイナの状態に関連があるページのみが表示されます。「BPELコンストラクト」、「サブプロセス」および「Oracle Extensions」は、ほぼ常に表示されます。ただし、transformアクティビティでトランスフォーメーションを設計している場合、「コンポーネント」ウィンドウには、「文字列関数」、「数学関数」、「ノードセット関数」など、そのアクティビティに関連する選択項目のみが表示されます。

「構造」ウィンドウ(左下)

デザイナで現在選択しているBPELプロセス・サービス・コンポーネントのデータが構造的に表示されます。このウィンドウから、次のような様々なタスクを実行できます。

- スキーマのインポート。

- メッセージ・タイプの定義。

- 変数、エイリアス、相関セット、パートナ・リンクなどの要素の管理(作成、編集および削除)

- デザイナに表示するBPELプロセス・フロー・シーケンスのアクティビティの編集。

「ログ」ウィンドウ(中央下)

検証およびコンパイルのステータスに関するメッセージが表示されます。BPELプロセス・サービス・コンポーネントで検証が正しく行われるように、次のことを確認する必要があります。

- BPELプロセス・サービス・コンポーネントに入力変数が指定されていること。

- パートナ・リンクが選択されていること。

- パートナ・ロールが選択されていること。

- 操作が空でないこと。

- 入力変数タイプとパートナ・リンク操作タイプが一致していること。

デプロイメントに失敗した場合は、エラーのタイプと場所を示すメッセージが表示されます。

「ソース」タブ

BPELプロセス・サービス・コンポーネント・ファイル内部の構文が表示されます。アクティビティやパートナ・リンクをドラッグしたり、別のタスクを実行すると、これらのソース・ファイルの構文が即時に更新され、変更内容が反映されます。

「履歴」タブ

ファイルのリビジョン履歴や、ファイルの読取り専用バージョンと編集可能バージョンが並べて表示されます。

プロパティ・インスペクタ

アクティビティに関する詳細が表示されます。「設計」ウィンドウでアクティビティをクリックすると、編集用に開きます。詳細は、「BPELアクティビティをプロパティ・インスペクタで編集する方法」を参照してください。

注意:

これらのセクションの詳細を参照する場合、該当するセクション内にカーソルを置いて[F1]を押し、オンライン・ヘルプを表示することもできます。

5. Oracle BPELデザイナの上部にある「プロパティ構造」リストで「情報」を選択して、BPELプロジェクトのバージョン(1.1または2.0)を表示します。図4-3に詳細を示します。

図4-3 BPELプロジェクトのバージョン

「情報」ダイアログが表示されます。

4.1.2 BPELプロセス・サービス・コンポーネントを検証する方法

構文的およびセマンティク的に(パートナ・リンクや変数はinvokeアクティビティで定義されていないなど)BPELプロセスを検証できます。検証が失敗すると、情報が「ログ」ウィンドウに表示されます。

BPELプロセス・サービス・コンポーネントを検証するには:

1. Oracle BPELデザイナで、BPELプロセスの上にある緑のチェック・マーク・アイコンをクリックします。図4-4に詳細を示します。

図4-4 Oracle BPELデザイナの「検証」アイコン

2. 図4-5 に示すように、検証結果が「ログ」ウィンドウに表示されます。

図4-5 「ログ」ウィンドウにおけるBPELプロセス検証結果

図4-6 に示すように、検証エラーが発生すると、メッセージが「ログ」ウィンドウに表示されます。

図4-6 「ログ」ウィンドウの検証結果

4.2 アクティビティの概要

アクティビティは、BPELプロセス・サービス・コンポーネントのビルディング・ブロックです。Oracle BPELデザイナには、BPELプロセス・サービス・コンポーネントにドラッグする一連のアクティビティが用意されています。アクティビティの属性(プロパティ値)を定義するには、そのアクティビティをダブルクリックします。アクティビティを使用すると、BPELプロセス・サービス・コンポーネント内で特定のタスクを実行できます。次に、いくつかの主要なアクティビティの例を示します。

- assignアクティビティを使用すると、ある変数の内容を別の変数にコピーするなどのデータの操作を実行できます。図4-7 に、assignアクティビティを示します。

図4-7 assignアクティビティ

- invokeアクティビティを使用すると、(パートナ・リンクによって識別された)サービスを起動し、このサービスに対して実行する操作を指定できます。図4-8 に、invokeアクティビティを示します。

図4-8 invokeアクティビティ

- receiveアクティビティは、サービスからの非同期コールバック・レスポンス・メッセージを待機します。図4-9 に、receiveアクティビティを示します。receiveアクティビティは、パートナ・リンクを使用してプロセスが非同期に開始される場合にも使用されます。

図4-9 receiveアクティビティ

図4-10 に、プロパティ・ウィンドウ(ここではinvokeアクティビティ)の例を示します。

図4-10 invokeアクティビティの例

このinvokeアクティビティを使用すると、サービス(パートナ・リンクで識別)に対して起動する操作を指定できます。操作は、サービスによって指定されたポートでの一方向またはリクエスト/レスポンスです。invokeアクティビティで変数を自動的に作成することも可能です。invokeアクティビティは、同期サービスを起動するか、非同期Webサービスを開始します。

invokeアクティビティは、プロセス内でデータを送受信するためのポートをオープンします。このポートを使用して、必要なデータの送信およびレスポンスの受信を行います。同期コールバックの場合、関数の送受信に必要なポートは1つのみです。

アクティビティの詳細は、「BPELプロセスのアクティビティとサービス」を参照してください。

同じプロジェクト内または複数のプロジェクト間でアクティビティのコピーおよび貼付けを行う方法の詳細は、「アクティビティのコピーと貼付けをBPELプロジェクトで行う方法」を参照してください。

アクティビティをプロパティ・インスペクタで編集する方法の詳細は、「BPELアクティビティをプロパティ・インスペクタで編集する方法」を参照してください。

4.2.1 BPELアクティビティをプロパティ・インスペクタで編集する方法

Oracle JDeveloperのOracle BPELデザイナのプロパティ・インスペクタでBPEL1.1と2.0のプロセスのアクティビティのプロパティ・フィールドを編集できます。このアクションは、アクティビティをダブルクリックするかアクティビティを右クリックして「編集」を選択し、変更を行い、「適用」か「OK」をクリックするアクションと同じです。

BPELアクティビティをプロパティ・インスペクタで編集するには:

1. Oracle BPELデザイナで、アクティビティをシングルクリックします。この例では、図4-11 でXSLT transformアクティビティが選択されています。

2. このアクティビティのプロパティ・フィールドが、Oracle BPELデザイナの下のプロパティ・インスペクタで編集用に表示されます。

図4-11 プロパティ・インスペクタで編集用に表示されるアクティビティ

3. 変更を行って「適用」キーを押すか、別のアクティビティをクリックすることでこのアクティビティから移動します。

4. 編集したアクティビティに戻り、変更が適用されたことに注意します。

また、catchアクティビティや変数など、scopeアクティビティ内でアクションを編集できます。

5. scopeアクティビティを展開します。

6. プロパティ・インスペクタで、「変数」をクリックします。

プロパティ・インスペクタがリフレッシュされ、「追加」、「編集」および「削除」のアイコンを含めて、変数のプロパティ・フィールドが表示されます。図4-12に詳細を示します。

図4-12 scopeアクティビティの「変数」セクションがプロパティ・インスペクタで編集用に表示される

4.2.2 アクティビティのコピーと貼付けをBPELプロジェクトで行う方法

同じBPELプロジェクト内またはBPELプロジェクト間で、アクティビティをコピーして貼り付けることができます。これにより、類似したアクティビティ全体を複数回作成する必要がなくなります。アクティビティを1回設計して複数の場所で使用し、必要に応じて編集できます。

注意:

個別のOnAlarmアクティビティを1つのscopeアクティビティからコピーして、別のscopeアクティビティに貼り付けることができます。個別のOnAlarmアクティビティを1つのpickアクティビティからコピーして、別のpickアクティビティに貼り付けることもできます。

以下の制限に注意してください。

- BPEL 1.1プロジェクトからBPEL 2.0プロジェクトに、またはBPEL 2.0プロジェクトからBPEL 1.1プロジェクトにアクティビティをコピーすることはできません。

- BPEL 2.0プロジェクトでは、個別のOnAlarmアクティビティをpickアクティビティからscopeアクティビティにコピーしたり、その逆を行うことはできません。ただし、このタイプのコピーおよび貼付けは、BPEL 1.1プロジェクトではサポートされています。

- scopeアクティビティをコピーして貼り付ける場合、最初のscopeアクティビティで参照される変数はコピーされません。

アクティビティをコピーして貼り付ける手順は、次のとおりです。

1. コピーするアクティビティを右クリックします。

2. 「コピー」を選択します。

3. アクティビティを貼り付けるプロジェクトに移動します。

4. 次のタスクのいずれかを実行します。

a. このアクティビティを貼り付ける場所に最も近いアクティビティを右クリックします。

b. 選択したアクティビティの前後どちらに貼り付けるかを選択します。

または

a. 図4-13 に示すように、BPELプロセスをハイライト表示します。

図4-13 選択されたBPELプロセス

b. 右クリックして「貼付け」→「中に貼付け」の順に選択します。
アクティビティがBPELプロセスの上部に貼り付けられます。

4.2.3 アクションの説明をBPELプロセス・アクティビティに追加する方法

アクションの説明をBPELプロセス・アクティビティに追加できます。これによって、そのアクティビティに「TODOタスク」アイコンが作成されます。このアイコンの上にカーソルを合せると、アクションの説明が表示されます。BPELプロセス・サービス・コンポーネントのアクティビティが実行するアクションを説明で説明できます。

アクションの説明をBPELプロセス・アクティビティに追加する方法:

1. アクティビティを右クリックし、「TODOタスクの追加」を選択します。

「TODOタスクの追加」ダイアログが表示されます。

2. アクティビティで実行されるアクションの説明を追加してから、「OK」をクリックします。

3. BPELアクティビティの右側にある「TODOタスク」アイコンにカーソルを合せると、説明が表示されます。図4-14に詳細を示します。

図4-14 BPELアクティビティの説明

4.3 パートナ・リンクの概要

パートナ・リンクを使用すると、BPELプロセス・サービス・コンポーネントと対話する外部サービスを定義できます。パートナ・リンクは、(推奨される方法)またはOracle BPELデザイナのBPELプロセス・サービス・コンポーネント内にサービスまたは参照(JCAアダプタ経由など)として定義できます。図4-15 に、パートナ・リンク・アイコン(この例ではPartnerSupplierMediatorという名前)を示します。

図4-15 「パートナ・リンク」アイコン

パートナ・リンク・タイプは、対話において各サービスが果たす役割を定義すること、および対話の中でメッセージを受信するために各サービスが提供するポート・タイプを指定することで、2つのサービス間での対話関係の特性を決定します。

図4-16 に、サービスに対するパートナ・リンクの属性の例を示します。

図4-16 「パートナ・リンク」ダイアログ

表4-4 に、このダイアログの各フィールドを示します。

表4-4 「パートナ・リンクの作成」ダイアログのフィールド

フィールド

説明

名前

パートナ・リンクに対して指定する一意のわかりやすい名前です。

プロセス

BPELプロセス・サービス・コンポーネント名が表示されます。

WSDL URL

パートナ・リンクに対して選択するWSDLファイルまたはJavaインタフェースの名前と場所。使用するWSDLファイルまたはJavaインタフェースを選択するためにウィンドウにアクセスするには、「SOAサービス・エクスプローラ」アイコン(「WSDL URL」フィールドの左上から2番目のアイコン)をクリックします。

「参照」フォルダの下にjavaEJBの名前とともに表示される選択用のJavaインタフェース。このパートナ・リンクと接続するコンポーネントがWSDLファイルを使用し、Javaインタフェースを選択して「OK」をクリックすると、このコンポーネントにはWSDLインタフェースが必要であることを示すメッセージが表示されます。「はい」をクリックすると、Javaインタフェースに基づいて互換性のあるWSDLファイルが作成されます。

Javaインタフェースを使用するコンポーネントをSOAコンポジット・アプリケーションに統合する方法の詳細は、「Spring Frameworkを使用したSOAコンポジット・アプリケーションへの統合」を参照してください。

パートナ・リンク・タイプ

WSDLファイルで定義したパートナ・リンクです。

パートナ・ロール

パートナ・リンクによって実行されるロールです。

マイ・ロール

BPELプロセス・サービス・コンポーネントが実行するロールです。これが、同期プロセスの場合は、BPELプロセス・サービス・コンポーネントにロールはありません。

注意:

「パートナ・リンクの作成」ダイアログの「パートナ・リンク・タイプ」、「パートナ・ロール」および「マイ・ロール」フィールドは、BPEL標準で定義される必須フィールドです。

ベスト・プラクティス

Oracle MediatorとBPELプロセス・サービス・コンポーネントは、常にSOAコンポジット・エディタ(Oracle BPELデザイナではなく)で作成して接続することをお薦めします。

Oracle MediatorまたはBPELプロセスのパートナ・リンクをOracle BPELデザイナでBPELプロセスに追加し、invokeアクティビティを介していずれかのパートナ・リンクをBPELプロセスに接続しても、その接続は、SOAコンポジット・エディタには自動的には反映されません。SOAコンポジット・エディタで、Oracle MediatorまたはBPELプロセス・サービス・コンポーネントをBPELプロセスに再度明示的に接続する必要があります。

Oracle BPELデザイナのヒューマン・タスクまたはビジネス・ルールのパートナ・リンクには問題はありません。SOAコンポジット・エディタでは、両方とも自動的に接続されます。

パートナ・リンクをプロパティ・インスペクタで編集する方法の詳細は、「BPELアクティビティをプロパティ・インスペクタで編集する方法」を参照してください。

4.4 パートナ・リンクの作成

Oracle BPELデザイナのBPELプロセス内にパートナ・リンクを作成する方法は、でのパートナ・リンクの表示方法に影響します。この項では、この影響について説明します。WSDLファイルは、ローカル・オペレーティング・システムに配置される場合や、リモートでホストされる場合(この場合はWSDLのURLが必要)があります。

同様に、SOAコンポジット・エディタでサービス・バインディング・コンポーネントまたは参照バインディング・コンポーネントを作成し、BPELプロセス・サービス・コンポーネントに接続すると、パートナ・リンクがOracle BPELデザイナに表示されます。

4.4.1 パートナ・リンクの作成方法

パートナ・リンクを作成する手順は、次のとおりです。

1. SOAコンポジット・エディタで、BPELプロセス・サービス・コンポーネントをダブルクリックします。

Oracle BPELデザイナが表示されます。

2. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

3. 図4-17 に示すように、パートナ・リンクを適切な「パートナ・リンク」スイムレーンにドラッグします。

図4-17 Oracle BPELデザイナでのパートナ・リンクの作成

「パートナ・リンクの作成」ダイアログが表示されます。

4. 表4-4 の説明に従って、このダイアログの各フィールドを完了します。

次の各項では、パートナ・リンクの作成がSOAコンポジット・エディタに与える影響について説明します。

4.4.1.1 アウトバウンド・アダプタのパートナ・リンク

表4-5 に、への影響を示します。

表4-5 パートナ・リンクの作成がに与える影響

Oracle BPELデザイナでBPELプロセスに作成されるもの

表示されるもの

アウトバウンド・アダプタのパートナ・リンク

- BPELプロセス・サービス・コンポーネントの参照ハンドル

- コンポジット内でアウトバウンド・アダプタを表す参照

- BPELプロセス・サービス・コンポーネントとアダプタ参照を接続するワイヤ

図4-18 に、この作成方法を使用するとにどのように表示されるかを示します。

図4-18 への影響

4.4.1.2 インバウンド・アダプタのパートナ・リンク

表4-6 に、への影響を示します。

表4-6 パートナ・リンクの作成がに与える影響

Oracle BPELデザイナでBPELプロセスに作成されるもの

表示されるもの

インバウンド・アダプタのパートナ・リンク

- BPELプロセス・サービス・コンポーネントのサービス

- コンポジット内でインバウンド・アダプタを表すサービス

- インバウンド・アダプタ・サービスをBPELプロセス・サービス・コンポーネントに接続するワイヤ

図4-19 に、この作成方法を使用するとにどのように表示されるかを示します。

図4-19 への影響

4.4.1.3 抽象的なWSDLからサービスをコールするパートナ・リンク

表4-7 に、への影響を示します。

表4-7 パートナ・リンクの作成がに与える影響

Oracle BPELデザイナでBPELプロセスに作成されるもの

表示されるもの

抽象的なWSDLからサービスをコールするパートナ・リンク

BPELプロセス・サービス・コンポーネントに定義されたインタフェースおよびコールバック・インタフェースを持つ参照ハンドル

4.4.1.4 抽象的なWSDLからサービスを実装するパートナ・リンク

表4-8 に、への影響を示します。

表4-8 パートナ・リンクの作成がに与える影響

Oracle BPELデザイナでBPELプロセスに作成されるもの

表示されるもの

抽象的なWSDLからサービスを実装するパートナ・リンク

BPELプロセス・サービス・コンポーネントのインタフェースおよびコールバック・インタフェースを持つサービスが作成されます。

注意: 指定されたインタフェースおよびコールバック・インタフェースがある外部SOAP参照がに存在する場合は、新しい外部SOAP参照を作成してそれに接続することも、既存の外部SOAP参照に接続することもできます。

図4-20 に、この作成方法を使用するとにどのように表示されるかを示します。

図4-20 への影響

4.4.1.5 パートナ・リンクとヒューマン・タスクまたはビジネス・ルール

表4-9 に、への影響を示します。

表4-9 パートナ・リンクの作成がに与える影響

Oracle BPELデザイナでBPELプロセスに作成されるもの

表示されるもの

ヒューマン・タスクまたはビジネス・ルール

- コンポジット内のヒューマン・タスクまたはビジネス・ルール

- BPELプロセス・サービス・コンポーネントの参照

- BPELプロセス・サービス・コンポーネントと新しいヒューマン・タスクまたはビジネス・ルールを接続するワイヤ

図4-21 に、この作成方法を使用するとにどのように表示されるかを示します。

図4-21 への影響

4.4.1.6 既存のヒューマン・タスク、ビジネス・ルールまたはOracle Mediatorからのパートナ・リンク

表4-10 に、への影響を示します。

表4-10 パートナ・リンクの作成がに与える影響

Oracle BPELデザイナでBPELプロセスに作成されるもの

表示されるもの

既存のヒューマン・タスク、ビジネス・ルールまたはメディエータ・サービス・コンポーネントをBPELプロセスにドラッグすることによるパートナ・リンク

- BPELプロセス・サービス・コンポーネントの参照

- BPELプロセス・サービス・コンポーネントと既存のヒューマン・タスク、ビジネス・ルールまたはメディエータを接続するワイヤ

図4-22 に、この作成方法を使用するとにどのように表示されるかを示します。

図4-22 への影響

4.5 アダプタの概要

図4-16 に示す「パートナ・リンク」ダイアログを使用すると、およびOracle JDeveloperが提供するもう1つの主要な機能を利用できます。アダプタ構成ウィザードにアクセスするには、図4-23 に示す「サービス・ウィザード」アイコンをクリックします。

図4-23 アダプタの定義

アダプタにより、BPELプロセス・サービス・コンポーネント(したがって、SOAコンポジット・アプリケーション全体)を、ファイル・システム、FTPサーバー、データベース表、データベース・キュー、ソケット、Java Message Service (JMS)、Oracle User Messaging Serviceなどへのアクセスと統合できます。HTTPバインディング、直接バインディング、EJBなどのサービスと統合することもできます。このウィザードを使用すると、図4-24 に示すサービスとアダプタのタイプを、BPELプロセス・サービス・コンポーネントで使用するように構成できます。

図4-24 サービス・タイプとアダプタ・タイプ

サービス・タイプとアダプタ・タイプの詳細は、「バインディング・コンポーネントのスタート・ガイド」を参照してください。

アダプタ・タイプ(この例では、「ファイル」が図4-24 で選択されました)を選択すると、図4-25 に示すダイアログにより名前の入力を求められます。ウィザードが完了すると、この名前のWSDLファイルが、「WSDL」フォルダの下にある「アプリケーション」ウィンドウに表示されます。サービス名はプロジェクト内で一意である必要があります。このファイルには、このウィザードで指定したアダプタ構成設定が含まれます。その他の構成ファイル(ヘッダー・ファイル、アダプタ固有のファイルなど)も作成され、「アプリケーション」ウィンドウに表示されます。

図4-25 アダプタのサービス名

このダイアログの後に表示されるアダプタ構成ウィザードのダイアログは、選択したアダプタ・タイプに基づきます。

また、内のサービスまたは参照として、アダプタをSOAコンポジット・アプリケーションに追加できます。

テクノロジ・アダプタの詳細は、『テクノロジ・アダプタの理解』を参照してください。

4.6 BPELプロセス・モニターの概要

Oracle BPELデザイナ上部の監視ビューに変更を選択することで、Oracle BPELデザイナでBPELプロセス・モニターを構成できます。図4-26に詳細を示します。BPELプロセス・モニターでは、データを分析してグラフィカル表示するために、Oracle BAMアダプタを介してデータをOracle BAMに送信できます。

図4-26 BPELプロセス・モニター

ビジネス・インジケータ、間隔およびカウンタの詳細は、Oracle SOA Suite 11gのドキュメントを参照してください。

http://docs.oracle.com/cd/E28280_01/dev.1111/e10224/bam_adapter.htm#BABIJBCC

5 BPELプロセスの相互作用パターンの概要

この章では、BPELプロセス・サービス・コンポーネントと外部サービスとの間における共通の相互作用パターン(一方向メッセージ、同期および非同期の相互作用、1リクエストと複数/単一レスポンス、1リクエストと必須/オプション・レスポンス、部分処理、複数アプリケーション間の相互作用など)について説明します。また、それぞれを使用する場合のベスト・プラクティスについても説明します。

この章の内容は次のとおりです。

- 一方向メッセージの概要

- 同期相互作用の概要

- 非同期相互作用の概要

- タイムアウト付き非同期相互作用の概要

- 通知タイマー付き非同期相互作用の概要

- 1リクエストと複数レスポンスの概要

- 1リクエストと二者択一レスポンスの概要

- 1リクエストと必須/オプション・レスポンスの概要

- 部分処理の概要

- 複数アプリケーション間の相互作用の概要

5.1 一方向メッセージの概要

一方向メッセージ(Fire and Forget)では、クライアントはメッセージをサービスに送信し(図5-1 のd1)、サービスはそれに対して返信する必要がありません。メッセージを送信するクライアントは、レスポンスを待機せずに即時に実行を続行します。次の例に、この環境におけるBPELプロセスWSDLファイルのportTypeとoperationのパートを示します。

. . .
<wsdl:portType name="BPELProcess1">
<wsdl:operation name="process">
<wsdl:input  message="client:BPELProcess1RequestMessage" />
</wsdl:operation>
</wsdl:portType>
. . .

図5-1 に概要を示します。

図5-1 一方向メッセージ

5.1.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

クライアントとしてのBPELプロセス・サービス・コンポーネントには、有効なパートナ・リンク、およびターゲットのサービスとメッセージを持つinvokeアクティビティが必要です。すべてのパートナ・アクティビティと同様に、Web Services Description Language (WSDL)ファイルは相互作用を定義します。

5.1.2 サービスとしてのBPELプロセス・サービス・コンポーネント

クライアントからメッセージを受け取るために、BPELプロセス・サービス・コンポーネントにはreceiveアクティビティが必要です。

5.2 同期相互作用の概要

同期相互作用では、クライアントはリクエストをサービスに送信し(図5-2 のd1)、リプライを即時に受信します(図5-2 のd2)。BPELプロセス・サービス・コンポーネントはこの相互作用のいずれかの終端であり、そのロール(クライアントまたはサービス)に従ってコーディングする必要があります。たとえば、オンライン新聞の購読をリクエストしたユーザーは、リクエストの受取り確認電子メールを即時に受信します。次の例に、この環境におけるBPELプロセスWSDLファイルのportTypeとoperationのパートを示します。

. . .
<wsdl:portType name="BPELProcess1">
<wsdl:operation name="process">
<wsdl:input  message="client:BPELProcess1RequestMessage" />
<wsdl:output message="client:BPELProcess1ResponseMessage"/>
</wsdl:operation>
</wsdl:portType>

図5-2 に概要を示します。

図5-2 同期相互作用

5.2.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

BPELプロセス・サービス・コンポーネントが同期トランザクションのクライアント側にある場合は、invokeアクティビティが必要です。クライアント側のポートは、リクエストを送信し、リプライを受信します。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。

5.2.2 サービスとしてのBPELプロセス・サービス・コンポーネント

BPELプロセス・サービス・コンポーネントが同期トランザクションのサービス側にある場合は、着信リクエストを受け取るreceiveアクティビティ、およびリクエストされた情報またはWSDLで定義されたエラー・メッセージ(フォルト、図5-2 のf1)のいずれかを返すreplyアクティビティが必要です。

同期相互作用の詳細は、「BPELプロセスからの同期Webサービスの起動」を参照してください。

5.2.3 非同期プロセスを起動する同期BPELプロセス

同期BPELプロセスによって非同期プロセスが起動される場合、そのコールバック・レスポンス・メッセージはBPELプロセスによって認識されず、そのプロセスはレスポンスの待機をタイムアウトします。このタイプの相互作用パターンはサポートされていません。

5.3 非同期相互作用の概要

非同期相互作用では、クライアントはリクエストをサービスに送信し、サービスが応答するまで待機します。次の例に、この環境におけるBPELプロセスWSDLファイルのportTypeとoperationのパートを示します。

. . .
<wsdl:portType name="BPELProcess1">
<wsdl:operation name="process">
<wsdl:input message="client:BPELProcess1RequestMessage"/>
</wsdl:operation>
</wsdl:portType>

. . .
<wsdl:portType name="BPELProcess1Callback">
<wsdl:operation name="processResponse">
<wsdl:input message="client:BPELProcess1ResponseMessage"/>
</wsdl:operation>
</wsdl:portType>

図5-3 に概要を示します。

図5-3 非同期相互作用

5.3.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

BPELプロセス・サービス・コンポーネントが非同期トランザクションのクライアント側にある場合は、リクエストを送信するinvokeアクティビティおよびリプライを受信するreceiveアクティビティが必要です。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。

5.3.2 サービスとしてのBPELプロセス・サービス・コンポーネント

同期トランザクションと同様に、BPELプロセス・サービス・コンポーネントが非同期トランザクションのサービス側にある場合は、着信リクエストを受け取るreceiveアクティビティ、およびリクエストされた情報またはフォルトのいずれかを返すinvokeアクティビティが必要です。同期BPELプロセスからの応答との違いに注意してください。同期BPELプロセスはクライアントへの応答にreplyアクティビティを使用します。非同期サービスはinvokeアクティビティを使用します。

非同期相互作用の詳細は、「BPELプロセスからの非同期Webサービスの起動」を参照してください。

5.4 タイムアウト付き非同期相互作用の概要

タイムアウト付き非同期相互作用(BPELでpickアクティビティを使用して実行)では、クライアントはリクエストをサービスに送信し、リプライを受信するまであるいは一定の時間が経過するまでの、いずれか早い時点まで待機します。たとえば、クライアントが融資提案をリクエストします。クライアントが指定時間内に融資提案リプライを受信しなかった場合は、リクエストが取り消されます。図5-4 に概要を示します。

図5-4 タイムアウト付き非同期相互作用

5.4.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

BPELプロセス・サービス・コンポーネントがタイムアウト付きの非同期トランザクションのクライアント側にある場合は、リクエストを送信するinvokeアクティビティおよび2つのブランチ(onMessageブランチおよびonAlarmブランチ)を持つpickアクティビティが必要です。時間制限の後にリプライが到着した場合、メッセージは配信不能キューに送られます。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。

タイムアウト付き非同期相互作用の詳細は、「pickアクティビティのプロセスの待機または継続の選択」を参照してください。

5.4.2 サービスとしてのBPELプロセス・サービス・コンポーネント

サービスとしてのBPELプロセス・サービス・コンポーネントの動作は、非同期相互作用でのサービスとしてのBPELプロセス・サービス・コンポーネントの動作に相当します。

5.5 通知タイマー付き非同期相互作用の概要

通知タイマー付き非同期相互作用では、クライアントはリクエストをサービスに送信し、リプライを待機しますが、タイマーが時間切れになると通知が送信されます。タイマーが時間切れになっても、クライアントはサービスからのリプライを待機し続けます。図5-5 に概要を示します。

図5-5 通知タイマー付き非同期相互作用

5.5.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

BPELプロセス・サービス・コンポーネントがこのトランザクションのクライアント側にある場合は、リクエストを送信するinvokeアクティビティおよびリプライを受信するreceiveアクティビティを含むscopeアクティビティが必要です。scopeアクティビティのonAlarmハンドラには時間制限、および時間切れになったときの指示が含まれます。たとえば、30分待機した後、予想を超える時間がプロセスにかかっているという警告を送信します。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。

5.5.2 サービスとしてのBPELプロセス・サービス・コンポーネント

サービスとしてのBPELプロセス・サービス・コンポーネントの動作は、非同期相互作用でのサービスとしてのBPELプロセス・サービス・コンポーネントの動作に相当します。

5.6 1リクエストと複数レスポンスの概要

このタイプの相互作用では、クライアントは1つのリクエストをサービスに送信し、複数のレスポンスを受信します。たとえば、商品をオンラインで注文するリクエストに対し、最初のレスポンスは納期予定、2番目のレスポンスは支払い確認、3番目のレスポンスは商品が発送されたことの通知である場合があります。この例では、レスポンスの数とタイプが予想されていることに注意してください。図5-6 に概要を示します。

図5-6 1リクエストと複数レスポンス

5.6.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

BPELプロセス・サービス・コンポーネントがこのトランザクションのクライアント側にある場合は、リクエストを送信するinvokeアクティビティ、および3つのreceiveアクティビティ(各リプライに対して1つ)を持つsequenceアクティビティが必要です。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。

5.6.2 サービスとしてのBPELプロセス・サービス・コンポーネント

BPELサービスには、クライアントからのメッセージを受け取るreceiveアクティビティと、3つのinvokeアクティビティ(各リプライに対して1つ)を持つsequence属性が必要です。

5.7 1リクエストと二者択一レスポンスの概要

1リクエストと二者択一レスポンスを使用する相互作用では、クライアントは1つのリクエストをサービスに送信し、2つのうちのいずれかのレスポンスを受信します。たとえば、商品をオンラインで注文するリクエストに対し、最初のレスポンスは在庫ありメッセージまたは在庫切れメッセージのいずれかである場合があります。図5-7 に概要を示します。

図5-7 1リクエストと二者択一レスポンス

5.7.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

BPELプロセス・サービス・コンポーネントがこのトランザクションのクライアント側にある場合は、BPELプロセス・サービス・コンポーネント内に次のアクティビティが必要です。

- リクエストを送信するinvokeアクティビティ。

- 2つのブランチを持つpickアクティビティ。1つ目のonMessageブランチは、在庫ありメッセージを受信した場合の、在庫ありレスポンスおよび指示用。

- 2つ目のonMessageブランチは、在庫切れメッセージを受信した場合の、在庫切れレスポンスおよび指示用。

すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。

1つのリクエストと二者択一レスポンスを使用する相互作用の詳細は、「pickアクティビティのプロセスの待機または継続の選択」を参照してください。

5.7.2 サービスとしてのBPELプロセス・サービス・コンポーネント

BPELサービスには、クライアントからメッセージを受け入れるためのreceiveアクティビティ、およびswitchアクティビティ(BPEL 1.1)またはifアクティビティ(BPEL 2.0)が必要で、ifアクティビティには2つのブランチがあり、1つは品目が入手可能な場合に在庫ありメッセージを送信するinvokeアクティビティを持つもの、もう1つは品目が入手不可の場合に在庫切れメッセージを送信するinvokeアクティビティを持つものです。

5.8 1リクエストと必須/オプション・レスポンスの概要

このタイプの相互作用では、クライアントは1つのリクエストをサービスに送信し、1つまたは2つのレスポンスを受信します。ここでのリクエストは、商品をオンラインで注文することです。商品が遅れている場合は、遅延を顧客に通知するメッセージがサービスにより送信されます。どのような場合も、商品の発送時には必ず通知が送信されます。図5-8 に概要を示します。

図5-8 1リクエストと必須/オプション・レスポンス

5.8.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

BPELプロセス・サービス・コンポーネントがこのトランザクションのクライアント側にある場合は、リクエストを送信するinvokeアクティビティおよび必須リプライを受信するreceiveアクティビティを含む、scopeアクティビティが必要です。scopeアクティビティのonMessageハンドラは、オプションのメッセージおよびそれを受信した場合の指示(商品が遅れていることをユーザーに通知するなど)を受け取るように設定されています。クライアントBPELプロセス・サービス・コンポーネントは必須リプライの受信を待機します。最初に必須リプライを受信すると、BPELプロセス・サービス・コンポーネントはオプションのリプライを待機せずに続行します。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。

5.8.2 サービスとしてのBPELプロセス・サービス・コンポーネント

BPELサービスには、receiveアクティビティと必須発送メッセージを送信するinvokeアクティビティを含むscopeアクティビティ、および時間切れになった場合のオプションの遅延メッセージを送信する(品目が24時間以内に出荷されない場合の遅延メッセージの送信など)scopeのonAlarmハンドラが必要です。

5.9 部分処理の概要

部分処理では、クライアントはリクエストをサービスに送信し、すぐにレスポンスを受信しますが、処理はサービス側で続行されます。たとえば、クライアントはパッケージ・ツアーを購入するリクエストを送信します。サービスは購入を確認するリプライをただちに送信して、ホテル、フライト、レンタカーなどの予約を続行します。このパターンでは、長期間の処理が続く複数の単発コールバックも含まれることがあります。図5-9 に概要を示します。

図5-9 部分処理

5.9.1 クライアントとしてのBPELプロセス・サービス・コンポーネント

BPELクライアントが単純なこのケースでは、各リクエストに対するinvokeアクティビティと、非同期トランザクションの各リプライに対するreceiveアクティビティまたは各同期トランザクションに対するinvokeアクティビティが必要です。これらのトランザクションが完了すると、残りの作業はサービスによって処理されます。すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。

5.9.2 サービスとしてのBPELプロセス・サービス・コンポーネント

BPELサービスには、クライアントからの各リクエストに対するreceiveアクティビティと、各レスポンスに対するinvokeアクティビティが必要です。レスポンスが終了すると、サービスとしてのBPELプロセス・サービス・コンポーネントは、必要なタスクを実行するために相互作用で収集された情報を使用して、クライアントからの追加入力なしにその処理を続行できます。

5.10 複数アプリケーション間の相互作用の概要

購入者、販売者、発送者など、トランザクションに3つ以上のアプリケーションが必要な場合があります。この場合、購入者は販売者にリクエストを送信し、販売者はそのリクエストを発送者に送信し、発送者は購入者に通知を送信します。この「A-B-C-A」トランザクション・パターンは、同時に多数のトランザクションを処理できます。このため、どのメッセージがどこに送信されるのかを追跡するためのメカニズムが必要です。図5-10 に概要を示します。

すべてのパートナ・アクティビティと同様に、WSDLファイルは相互作用を定義します。

図5-10 複数アプリケーション間の相互作用

このような調整は、WS-Addressingと相関セットを使用して管理できます。これらの詳細は、「BPELプロセスからの非同期Webサービスの起動」を参照してください。

6 BPELプロセスでのXMLデータの操作

この章では、BPELプロセス・サービス・コンポーネントでのXMLデータの操作方法について説明します。この章では様々な例を提供します。変数、シーケンスおよび配列の使用方法とXPath式の使用方法、数学的計算などのタスクの実行方法に関するトピックが含まれています。サポートされる仕様についても説明しています。

この章の内容は次のとおりです。

- BPELプロセスでのXMLデータの操作の概要

- データ・プロバイダ・サービスへのXMLデータ操作の委任

- ネイティブ・データとXMLとの間における変換

- スタンドアロンSDOベースの変数の使用

- 式定数またはリテラルXMLでの変数の初期化

- 変数間のコピー

- 「構造」ウィンドウでの変数の移動およびコピー

- 要素変数およびメッセージ・タイプ変数内のフィールドへのアクセス

- 数値の割当て

- XPath標準による数学的計算の使用

- 文字列リテラルの割当て

- 文字列の連結

- ブール値の割当て

- 日付または時刻の割当て

- 属性の操作

- bpelx拡張要素を使用したXMLデータの操作

- XMLデータの検証

- BPEL 2.0のメッセージ交換アクティビティでの要素変数の使用

- BPEL 2.0でのWSDLメッセージ・パートのマップ

- BPEL 2.0でのプロセス定義のインポート

- 配列に類似したXMLデータ・シーケンスの操作

- 文字列からのXML要素への変換

- ドキュメント形式とRPC形式のWSDLの違いの理解

- BPELでのSOAPヘッダーの操作

- BPEL 2.0での拡張ネームスペースの宣言

注意:

この章の大部分の例では、関連するメッセージ・タイプを定義するWSDLファイルは、Remote Procedure Call (RPC)形式ではなくドキュメント・リテラル形式であると想定しています。RPC形式のWSDL定義の場合、XPath問合せ文字列の構成方法に違いがあります。RPCのWSDLファイルで定義されたタイプを使用する場合は、「ドキュメント形式とRPC形式のWSDLの違いの理解」を参照してください。

6.1 BPELプロセスでのXMLデータの操作の概要

この項では、BPELプロセスでのXMLデータの使用について概要を説明します。

6.1.1 BPELプロセスのXMLデータ

BPELプロセス・サービス・コンポーネントでは、ほとんどのデータはXMLフォーマットです。データには、BPELプロセス・サービス・コンポーネントとの間で受け渡されるメッセージ、外部サービスとの間で交換されるメッセージ、プロセスで使用されるローカル変数などがあります。通常は次のいずれかのXMLスキーマを使用して、これらのメッセージおよび変数のタイプを定義します。

- フローのWeb Services Description Language (WSDL)ファイル

- 起動されるサービスのWSDLファイル

- そのWSDLファイルで参照されるXSDファイル

したがって、BPELのほとんどの変数はXMLデータであり、BPELプロセス・サービス・コンポーネントはそのコードの大部分を使用して、これらのXML変数を操作します。通常は、様々なサービスに必要な表現間でのデータ・トランスフォーメーション、データのローカル操作(複数のサービス呼出しからの結果の結合など)などが行われます。

BPELでは、サービス・データ・オブジェクト(SDO)変数もサポートしています。この変数は、XML形式ではなく、メモリー構造形式です。

6.1.2 assignアクティビティでのデータ操作およびXPath標準

BPELのデータ操作は、XPath標準に基づくassignアクティビティが開始点になります。このタイプの操作では多くの場合、XPath問合せ、式および関数が使用されます。

通常は、より複雑なデータ・トランスフォーメーションまたは操作を行うためのXQuery、XSLTまたはJavaを使用する高度な方法も使用できます。

この項では、BPELでXMLデータを操作する方法の概要を説明します。様々な組合せで使用される主要なビルディング・ブロックの概要を示し、例をあげて説明します。後続の各項では、これらのビルディング・ブロックを適用して特定のタスクを実行する方法について説明します。

XML変数間でデータをコピーする場合、または式の値を計算して変数に格納するには、assignアクティビティを使用します。アクティビティ内のcopy要素は、互換性のあるタイプの割当てのソースとターゲット(コピー先とコピー元の内容)を指定します。

次の例に、に記載されているBPELバージョン1.1の正式な構文を示します。

<assign standard-attributes>
standard-elements
<copy>
from-spec
to-spec
</copy>
</assign>

次の例に、に記載されているBPELバージョン2.0の正式な構文を示します。keepSrcElementName属性は、コピー操作中に(to-specの選択に従って)宛先の要素名が、(from-specの選択に従って)ソースの要素名で置換されるかどうかを指定します。keepSrcElementNameをno (デフォルト値)に設定すると、元の宛先要素の名前(つまり、ネームスペース名とローカル名のプロパティ)が、作成される要素の名前として使用されます。keepSrcElementNameをyesに設定すると、ソース要素名が、作成される宛先要素の名前として使用されます。

<assign validate="yes|no"? standard-attributes>
standard-elements
(
<copy keepSrcElementName="yes|no"? ignoreMissingFromData="yes|no"?>
from-spec
to-spec
</copy>
. . .
. . .
</assign>

この構文は、両方の仕様で詳細に説明されています。通常、from-specおよびto-specは、次の例に示すように、変数または変数パートを指定します。

<assign>
<copy>
<from variable="c1" part="address"/>
<to variable="c3"/>
</copy>
</assign>

Oracle JDeveloperを使用する場合は、「From」セクションと「To」セクションを備えた「コピー・ルール」ダイアログでassignアクティビティの詳細を指定します。これにより、前述のBPELソース・コードの構文が反映されます。

XPath標準は、assignアクティビティで主要な役割を果たします。概要として、簡単な例をここに示します。その他のコンテキストでの例および説明は、後続の各項に示します。

- XPath問合せ
XPath問合せは、ソースまたはターゲットの変数パート内のフィールドを選択します。from句またはto句には、値がXPath問合せ文字列であるquery属性を含めることができます。次にコードの例を示します。

<from variable="input" part="payload"
query="/p:CreditFlowRequest/p:ssn"/>

query属性の値には、ノードを1つのみ選択するロケーション・パスを指定する必要があります。query属性およびXPath標準の構文の詳細は、それぞれ(第14.3項)または(第8.4項)およびを参照してください。

- XPath式
XPath式(from句のexpression属性で指定)を使用して、変数に格納する値を指定します。次に例を示します。

<from expression="100"/>

式には一般的な式(つまり、任意のXPath値のタイプに評価されるXPath式)を指定できます。同様に、式属性の値がコピー操作内のfrom句で使用される場合、式属性の値は必ず1つのノードまたは1つのオブジェクトのみを返す必要があります。XPath式の詳細は、の第9.1.4項を参照してください。

XPath式内では、次の種類の関数をコールできます。

- コアXPath関数
XPathでは、文字列操作関数(concatなど)や数値関数(sumなど)を含む多数の組込み関数がサポートされています。

<from expression="concat('string one', 'string two')"/>

XPath標準に組み込まれた関数の完全なリストは、の第4項を参照してください。

- BPEL XPath拡張関数
BPELはいくつかの拡張関数をコアXPath関数に追加し、これによりXPath式がプロセスからの情報にアクセスできます。

- BPEL 1.1の場合、拡張関数は標準BPELネームスペースhttp://schemas.xmlsoap.org/ws/2003/03/business-process/で定義され、接頭辞bpws:によって指定されます。

<from expression= "bpws:getVariableData('input', 'payload', '/p:value') + 1"/>

詳細は、の第9.1項および第14.1項を参照してください。getVariableDataの詳細は、「getVariableData」を参照してください。

- BPEL 2.0の場合も、拡張関数は標準BPELネームスペースhttp://schemas.xmlsoap.org/ws/2003/03/business-process/で定義されます。ただし、接頭辞はbpel:になります。

<from>bpel:getVariableProperty('input', 'propertyName')</from>

詳細は、の第8.3項を参照してください。getVariablePropertyの詳細は、「getVariableProperty (BPEL 2.0)」を参照してください。

- Oracle BPEL XPath拡張関数
Oracleには、新しい関数を追加するためにBPELおよびXPath標準に組み込まれた機能を使用する、その他のXPath関数が用意されています。

これらの関数は、ネームスペースhttp://schemas.oracle.com/xpath/extensionで定義され、接頭辞ora:によって指定されます。

- カスタム関数
Oracle BPEL Process Managerの関数は、bpel-xpath-functions-config.xmlファイルに定義され、orabpel.jarファイルに格納されます。詳細は、「ユーザー定義XPath拡張関数の作成」を参照してください。

高度なデータ操作をBPELのassignアクティビティやコアXPath関数で実行するのは困難な場合があります。ただし、複雑なデータ操作やデータ・トランスフォーメーションは、XSLT、Java、またはassignアクティビティのbpelx操作(「bpelx拡張要素を使用したXMLデータの操作」を参照)を使用したり、Webサービスとして実行することができます。XSLTの場合、には、これらのトランスフォーメーションを実行するXPath関数が組み込まれています。

XPathおよびXQueryトランスフォーメーション・コード例の詳細は、「XSLTマップ・エディタを使用したトランスフォーメーションの作成」および「XQueryマッパーを使用したトランスフォーメーションの作成」を参照してください。

assignアクティビティの詳細は、「Assignアクティビティ」を参照してください。

注意:

assignアクティビティ経由で大きいスキーマが渡されると、「Assignの編集」ダイアログのターゲットまたはソース・ペイロード・ノードを右クリックして「すべての子ノードを開く」を選択した場合に、Oracle JDeveloperが停止したり、メモリー不足になる可能性があります。回避策として、ペイロード要素は手動で開いてください。

6.2 データ・プロバイダ・サービスへのXMLデータ操作の委任

エンティティ変数を使用して、基礎となるデータ・プロバイダ・サービスがBPELデータ操作を実行するように指定できます。データ・プロバイダ・サービスはデータ・ストア内でデータ操作をバックグラウンドで実行しますが、Oracle SOA Suiteが提供する他のデータ・ストア関連の機能(たとえば、データベース・アダプタ)を使用しません。これにより、Oracle SOA Suiteの実行時パフォーマンスが向上し、コンパイルおよび実行時に、基礎となるデータ・プロバイダ・サービスのネイティブ機能が組み込まれます。

エンティティ変数は、SDOベースのデータを使用してOracle Application Development Framework (ADF) Business Componentデータ・プロバイダ・サービスと一緒に使用できます。

11gより前のリリースでは、BPELビジネス・プロセス内で交換された変数およびメッセージは、XML構造に組み込まれる分離されたペイロード(Webサービスから返されるデータのスナップショット)でした。ある場合では、ユーザーにはこの構成要素タイプが必要でした。別の場合では、この構成要素は難題でした。

エンティティ変数は、次のような11gより前のリリースの問題に対応しています。

- 拡張データ変換
基礎となるデータがXML形式でない場合は、データ変換(デリミタ付きテキストからXMLへの変換など)が必要でした。基礎となるデータのサイズが大きい場合、処理はパフォーマンスに影響を与える場合がありました。

- 失効したスナップショット・データ
(WSDLメッセージを含めて)BPEL内の変数は分離されたペイロードでした。これが必要な場合もありました。別の場合では、Oracle BPEL Process Managerの外部にある他のアプリケーションによって変数が最新データに変更されて表示されることが必要でした。つまり、分離されたデータ・モデルでは、すべてのニーズを満たさない失効したデータ・セットが提供されていました。また、スナップショットによってデータが重複するため、データ・サイズが大きい場合はパフォーマンスに影響を与えていました。

- ネイティブ・データ動作の損失
一部のデータ変換の実装には、XMLスキーマの範囲外のデータ構造の適用またはビジネス・データ・ロジックが必要でした。たとえば、開始日は終了日より前である必要があります。変数が分離されたペイロードの場合は、関連するWebサービスの起動中にのみ検証が実行されました。特定の操作後(ただしWebサービスの起動前)に、特別なビジネス・データ・ロジックを必要に応じて実行することが推奨される場合がありました。

リリース11gからリリース12cまででこれらの課題に対応するには、変数宣言時にエンティティ変数を作成します。エンティティ変数は、バックグラウンドで様々なデータ・プロバイダ・サービス・テクノロジにアクセスし、プラグインするためのデータ・ハンドルとして機能します。コンパイルおよび実行時に、Oracle BPEL Process Managerは基礎となるデータ・プロバイダ・サービスにデータ操作を委任します。

表6-1 では、以前のリリース(例としてデータベース・アダプタを使用)と、エンティティ変数を使用するリリース11gと12cで、データ変換がどのように実行されるかを説明します。

表6-1 以前および現在のリリースでのデータ操作機能

10.1.xリリース

エンティティ変数を使用する場合の11gと12cのリリース

データを明示的にロードして保存するようなデータ操作は、Oracle BPEL Process Managerのデータベース・アダプタにより実行されていました。すべてのデータ(たとえば、注文書)はデータベースのデハイドレーション・ストアに保存されていました。

データをロードして保存するようなデータ操作は、データ・プロバイダ・サービス(Oracle ADF Business Componentアプリケーション)により自動的に実行され、サービスを起動するコードを記述する必要はありません。

Oracle BPEL Process Managerは、注文書データを指し示すキー(たとえば、注文書ID (POID))を格納します。Oracle BPEL Process Managerは、データへのアクセスがリクエストされたときにこのキーをフェッチします(bind entityアクティビティが実行します)。キーを使用してデータをバインドするように明示的にリクエストする必要があります。データ・プロバイダ・サービスは、すべてのデータ変更をデハイドレーション・ストア・データベースとは異なるデータベースに格納します。これによりデータは重複しません。

変数内のデータはドキュメント・オブジェクト・モデル(DOM)形式でした。

変数内のデータはSDO形式であり、DOMより簡単に変換処理できます。特に、データ・プロバイダ・サービスがSDO形式に対応している場合は簡単です。

注意:

現在は、BPELプロセス・サービス・コンポーネントのみがSDO形式の変数を使用できます。コンポジット・アプリケーションに、SDOベースのJavaバインディング・コンポーネント参照と接続されたOracle Mediatorサービス・コンポーネントがある場合、変数のデータ形式のデフォルトはDOMとなります。さらに、表6-1 で説明したリリース10.1.xの機能は、リリース11gと12cでもサポートされています。

6.2.1 エンティティ変数の作成方法

この項では、Oracle JDeveloperでエンティティ変数とバインディング・キーを作成する方法について説明します。

Oracle BPEL Process Managerのリリース10.1.xでは、すべての変数データはDOM形式でした。リリース11g以降、リリース12cでも、SDO形式の変数データもサポートされています。BPELプロセス・サービス・コンポーネントのDOMおよびSDO変数は、暗黙的に必要な形式に変換されます。たとえば、DOMベースの変数を使用するOracle BPELサービス・コンポーネントは、これらの変数を必要に応じてassignアクティビティでSDOベースの変数に自動的に変換し、逆の場合も同様に変換します。いずれのタイプの形式もXSDスキーマ・ファイルで定義されています。ユーザーが介入する必要はありません。

エンティティ変数は、SDO形式のデータもサポートしています。ただし、DOM変数やSDO変数とは異なり、SDOベースのデータを持つエンティティ変数を使用すると、データ(たとえば、注文書)に一意のキー値をバインドできます。そのキーのみが、デハイドレーション・ストアに格納されます。変換が必要なデータは、Oracle ADF Business Componentアプリケーションのサービスと一緒に格納されます。キーはサービス内に格納されるデータを指し示します。データが必要な場合はデータ・プロバイダ・サービスからフェッチされ、メモリーに配置されます。プロセスは、bind entityアクティビティとデハイドレーション・ストアの2つの場所で発生します。たとえば、Oracle BPEL Process Managerがリハイドレートする場合は、エンティティ変数のキーのみが格納され、ウェイクアップ時には、暗黙的なバインドが行われて現在のデータが取得されます。

6.2.1.1 インバウンド方向のSDOの動作の理解

SDOバインディング・コンポーネント・サービスは、図6-1 に示すように、コンポジット・アプリケーションへのエントリ・ポイントを外部に提供します。

図6-1 インバウンド方向

およびOracle BPELデザイナを使用して次のタスクを実行します。

- SDOバインディング・コンポーネント・サービスとBPELプロセス・サービス・コンポーネントをコンポジット・アプリケーションに定義します。

- SDOサービスとBPELプロセス・サービス・コンポーネントを接続(ワイヤ)します。

- BPELプロセス・サービス・コンポーネントの詳細を定義します。

の使用方法の詳細は、「SOAコンポジット・アプリケーションの開発のスタート・ガイド」を参照してください。

6.2.1.2 アウトバウンド方向のSDO動作の理解

図6-2 に示すように、SDOバインディング・コンポーネント参照を使用すると、コンポジット・アプリケーションからOracle ADF Business Componentアプリケーションの外部のパートナにメッセージを送信できます。

図6-2 アウトバウンド方向

Oracle ADF Business Componentアプリケーションが外部へのパートナ・リンクの場合、には、アウトバウンド通信を作成するためにコンポジット・アプリケーションにドラッグするSDOバインディング・コンポーネント参照はありません。かわりに、コンポジット・アプリケーションとOracle ADF Business Componentアプリケーションの間に次の通信が発生します。

- Oracle ADF Business Componentアプリケーションはデプロイされ、自動的にサービス・インフラストラクチャのSDOサービスとして登録されます

- Oracle JDeveloperを使用してADF-BCサービスとしてこのアプリケーションを参照および検索し、パートナ・リンク接続を作成します。

- Oracle ADF Business Componentアプリケーション・サービスが検出された場合、composite.xmlファイルは、参照の詳細(binding.adfプロパティ)で自動的に更新されます。

6.2.1.3 エンティティ変数の作成とパートナ・リンクの選択

ここでは、Oracle ADF Business Componentアプリケーションのために、エンティティ変数を作成し、パートナ・リンクを選択します。次の例は、Oracle ADF Business Componentデータ・プロバイダ・サービスの注文データを指し示すために、bind entityアクティビティを使用して、OrderProcessor BPELプロセス・サービス・コンポーネントが注文IDを受け取る方法を示しています。

注意:

エンティティ変数は、BPEL仕様のバージョン1.1または2.0を使用するBPELプロジェクトでサポートされています。

エンティティ変数を作成し、パートナ・リンクを選択する手順は、次のとおりです。

1. Oracle JDeveloperで、BPELプロセス・サービス・コンポーネントの「構造」ウィンドウに移動します。

2. 「変数」フォルダを右クリックし、「すべての子ノードを開く」を選択します。

3. 2番目の「変数」フォルダで、右クリックして「変数の作成」を選択します。

「変数の作成」ダイアログが表示されます。

4. 「名前」フィールドに、名前を入力します。

5. 「エンティティ変数」チェック・ボックスをクリックし、「パートナ・リンク」フィールドの右側の「検索」アイコンを選択します。

「パートナ・リンク・チューザ」ダイアログに、使用可能なサービス(ADF-BCというSDOサービスを含む)のリストが表示されます。

6. Oracle ADF Business Componentアプリケーションのためのサービスを参照し、選択します。

7. 「OK」をクリックし、「パートナ・リンク・チューザ」ダイアログと「変数の作成」ダイアログを閉じます。

ダイアログは図6-3 のようになります。

図6-3 「変数の作成」ダイアログ

6.2.1.4 バインディング・キーの作成

ここでは、Oracle ADF Business Componentデータ・プロバイダ・サービスの注文データを指し示すキーを作成します。

バインディング・キーを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「Oracle Extensions」を展開します。

2. 「SDO」セクションまで下にスクロールします。

3. bind entityアクティビティを、BPELプロセス・サービス・コンポーネントにドラッグします。図6-4に詳細を示します。

図6-4 「コンポーネント」ウィンドウのbind entityアクティビティ

「Bind Entity」ダイアログが表示されます。

4. 「名前」フィールドに、名前を入力します。

5. 「エンティティ変数」フィールドの右側の「検索」アイコンをクリックします。

「変数チューザ」ダイアログが表示されます。

6. 「エンティティ変数の作成とパートナ・リンクの選択」で作成したエンティティ変数を選択し、「OK」をクリックします。

7. 「一意キー」セクションで、「追加」アイコンをクリックします。

「キーの指定」ダイアログが表示されます。このダイアログを使用して、Oracle ADF Business Componentデータ・プロバイダ・サービスから注文IDを取得するためのキーを作成します。

8. 表6-2 に記載されている詳細を入力し、バインディング・キーを定義します。

表6-2 「キーの指定」ダイアログのフィールドと値

フィールド

値

キー・ローカル・パート

キーのローカル・パートを入力します。

キー・ネームスペースURI

キーに対するネームスペースURIを入力します。

キー値

キー値式を入力します。この式はキーのタイプと一致する必要があります。次に、POIDキーに対する式値キーの例を示します。

- $inputMsg.payload/tns:poid

- bpws:getVariableData('inputmsg','payload','tns:poid')

エンティティ変数に対するPOIDキーは、通常、別のメッセージから取得されます。POIDキーのタイプが整数で、式の結果がABCの文字列である場合、文字列から整数への変換は失敗し、bind entityアクティビティも実行時に失敗となります。

図6-5 に、完成した「キーの指定」ダイアログを示します。

図6-5 「キーの指定」ダイアログ

9. 「OK」をクリックして「キーの指定」ダイアログを閉じます。

図6-6 に示すように、「一意キー」の表に名前/値ペアが表示されます。これで、設計は完了します。

図6-6 「エンティティのバインド」ダイアログ

10. 「OK」をクリックして「エンティティのバインド」ダイアログを閉じます。

実行時にbind entityアクティビティが実行されると、エンティティ変数を使用する準備が整います。

SDOを使用する方法の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。このガイドには、アプリケーション・モジュールをWebサービスとして公開する方法や、表示データ・オブジェクトの行をSDOとして公開する方法が記載されています。アプリケーション・モジュールは、ビジネス・ロジックを関連する一連のビジネス機能としてカプセル化するADFフレームワーク・コンポーネントです。

6.3 ネイティブ・データとXMLとの間における変換

BPELプロセス変換アクティビティにより、ネイティブXSDフォーマットとXMLフォーマットとの間でメッセージを変換できます。次の変換タイプがサポートされています。

- インバウンド変換:

- ネイティブ・フォーマットからXMLへ

- 不透明からXMLへ

- ネイティブからディレクトリの添付ファイルへ

- アウトバウンド変換:

- XMLからネイティブ・フォーマットへ

- XMLからディレクトリの添付ファイルへ

- BPEL 1.1と.2.0の両方のプロジェクトでサポートされています。

インバウンド・メッセージ変換では自動的に、doTranslateFromNative関数を使用します。アウトバウンド・メッセージ変換では自動的に、doTranslateToNative関数を使用します。assignアクティビティを作成して「式ビルダー」ダイアログを起動し、これらの関数を構成する必要はありません。translateアクティビティは、assignアクティビティを自動的に生成します。

6.3.1 ネイティブ・データからXMLデータへの変換方法

この項では、インバウンド・メッセージをネイティブXSDフォーマット(この例では、文字列データ)で受信しXMLフォーマットに変換するために、変換アクティビティをBPELプロセスで構成方法について説明します。ネイティブ・フォーマット・ビルダー・ウィザードを使用して、新しいスキーマ・ファイルを作成します。

ネイティブ・データをXMLデータに変換する手順は、次のとおりです。

1. BPELプロセスをSOAコンポジット・エディタで右クリックし、「編集」を選択します。
Oracle BPELデザイナが表示されます。

2. 「コンポーネント」ウィンドウの「Oracle Extensions」セクションを展開し、変換アクティビティをBPELプロセスにドラッグします。図6-7に詳細を示します。

図6-7 BPELプロセスの変換アクティビティ

3. 変換アクティビティを右クリックし、「編集」を選択します。
「変換」ダイアログが編集用に表示されます。

4. NativeからXMLにを選択して、インバウンド・ネイティブ・データ(この例では、単一の文字列)を受信します。

5. 「入力」フィールドの右側にある「参照」アイコンをクリックします。
「変数XPathビルダー」ダイアログが表示されます。

6. XMLフォーマットに変換するインバウンド・ペイロードの一部であるネイティブ文字列を選択して、「OK」をクリックします。図6-8に詳細を示します。

図6-8 変数XPathビルダー

7. 「NXSDスキーマ」フィールドの右側で、使用するスキーマを選択します。

- スキーマが存在する場合、「検索」(1番目)アイコンを選択し、「タイプ・チューザ」ダイアログを起動します。

- スキーマが存在しない場合、2番目のアイコンを選択して、ネイティブ・フォーマット・ビルダー・ウィザードを起動し、スキーマを作成します。

次の例では、ネイティブ・フォーマット・ビルダー・ウィザードを使用して、カンマ区切りデリミタを使用するテキスト・ファイルから新規スキーマを作成する方法について説明しています。

a. 「ファイル名とディレクトリ」ダイアログの「ファイル名」フィールドで、名前を入力し、「次へ」をクリックします。

b. 「タイプの選択」ダイアログで、「デリミタ付き(フィールドが特殊文字で区切られているレコードが含まれています)」を選択し、「次へ」をクリックします。

c. 「ファイルの説明」ダイアログで、「参照」 をクリックし、カンマ区切りデリミタを使用するテキスト・ファイルを選択します。
「サンプル・ファイルの選択」ダイアログが表示されます。

d. 使用するファイルを選択して「OK」をクリックします。
このファイルの内容が、「ファイルの説明」ダイアログの下部に表示されます。図6-9に詳細を示します。

図6-9 サンプル・ファイルの内容

e. 「次へ」をクリックします。

f. 「レコード編成」で、「次へ」をクリックします。

g. 「要素の指定」ダイアログで、レコードを示す要素の名前を入力(この例では、addrを入力)し、「次へ」をクリックします。

h. フィールドをテキスト・ファイルで区切る特殊文字としてカンマのデフォルト値を「デリミタの指定」ダイアログで受け入れ、「次へ」をクリックします。

i. 「フィールド・プロパティ」ダイアログの「名前」列で、「C1」、「C2」、「C3」、「C4」、「C5」および「C6」のかわりに適切な値を入力し、「次へ」をクリックします。図6-10に詳細を示します。

図6-10 特定の値で置換される「名前」列デフォルト値

新しいスキーマが生成されたネイティブ・フォーマット・スキーマ・ダイアログに表示されます。

j. 「テスト」をクリックして、スキーマをテストします。

k. 「結果XML」セクションで、緑色の矢印をクリックします。
ネイティブ・スキーマとその結果のXMLが表示されます。図6-11に詳細を示します。

図6-11 ネイティブ・スキーマのテスト出力

l. 「OK」をクリックして、生成されたネイティブ・フォーマット・スキーマ・ダイアログに戻ります。

m. 「次へ」、「終了」、の順にクリックします。
addr_schema1.xsdファイルが生成され、「変換」ダイアログの「NXSDスキーマ」フィールドに表示されます。

8. 「出力タイプ」リストから、「DOM」を選択します。「DOM」を選択した場合、DOMとSDOMの両方がサポートされます。

9. 「出力」フィールドの右側で、スキーマの変数を選択します。

a. 手順7で指定されたスキーマに準拠している出力変数がある場合、「検索」(1番目)アイコンをクリックし、既存の変数を選択します。

b. 既存の変数がない場合、「追加」(2番目)アイコンをクリックし、「変数の作成」ダイアログを起動します。デフォルト値をそのまま使用するか、変数の名前を変更して出力変数を作成して、「OK」をクリックします。手順7で作成されたスキーマを変数は自動的に指します。

完成すると、「変換」ダイアログは図6-12 のようになります。

10. 図6-12 ネイティブからXMLに変換するために構成された「変換」ダイアログ

同期リクエストの出力は、新しいスキーマを指すように変更する必要があります。

11. 「アプリケーション」ウィンドウで、BPELプロセスのWSDLファイル(この例では、BPELProcess1.wsdlという名前)を選択します。

12. Oracle BPELデザイナの下部で、「ソース」をクリックします。

13. WSDLファイルの<wsdl:message>セクションまでスクロールします。

14. レスポンス要素(この例では、名前はprocessResponse)をBPELProcess1ResponseMessageメッセージ用にクリックし、プロパティ・インスペクタを右下の隅で起動します。図6-13に詳細を示します。

図6-13 WSDLファイルのルート要素選択

15. プロパティ・インスペクタで新規ルート要素を選択します(この例では、ns1:addr)。図6-14に詳細を示します。

図6-14 プロパティ・インスペクタで選択されたルート要素

ns1:addrルート要素がWSDLファイルに追加されています。図6-15に詳細を示します。

図6-15 WSDLファイルで表示される新規ルート要素

16. 変換アクティビティの下にあるBPELプロセスにassignアクティビティをドラッグします。
変換出力変数をBPEL出力変数に割り当てます。

17. assignアクティビティの「コピー・ルール」タブで、変数をマップし、「OK」をクリックします。図6-16に詳細を示します。

図6-16 assignの編集ダイアログ

これで、設計は完了します。

6.3.2 XMLデータからネイティブ・データへの変換方法

この項では、受信したXMLメッセージをネイティブ・データ・フォーマット(カンマ区切り文字列など)に変換する方法について説明します。この例では、「ネイティブ・データからXMLデータへの変換方法」で作成したスキーマ・ファイルをネイティブXSDフォーマットに変換するためのアウトバウンドXMLフォーマットとして使用しています。

XMLフォーマットをネイティブ・データに変換する手順は、次のとおりです。

1. 同期BPELプロセスを作成します。

2. 「BPELプロセスの作成」ダイアログの「入力」フィールドで、デフォルトの入力XSDスキーマを受け入れるか、「検索」アイコンをクリックして、異なるXSDを選択します。この例では、「ネイティブ・データからXMLデータへの変換方法」のネイティブ・フォーマット・ビルダーで作成したスキーマが選択されています。図6-17に詳細を示します。

図6-17 入力スキーマの選択

3. BPELプロセスをSOAコンポジット・エディタで右クリックし、「編集」を選択します。

Oracle BPELデザイナが表示されます。

4. 「コンポーネント」ウィンドウの「Oracle Extensions」セクションを展開し、変換アクティビティをBPELプロセスにドラッグします。

5. 変換アクティビティを右クリックし、「編集」を選択します。

「変換」ダイアログが編集用に表示されます。

6. 「XMLからネイティブ」を選択して、アウトバウンドXMLデータをネイティブXSDフォーマットに変換します。

7. 「入力」フィールドの右側にある「参照」(1番目)アイコンをクリックします。

8. 入力変数を選択します。図6-18に詳細を示します。

図6-18 入力変数の選択

9. 「NXSDスキーマ」フィールドの右側にある「検索」(1番目)アイコンを選択し、「タイプ・チューザ」ダイアログを起動します。

10. スキーマ・ファイルを選択して「OK」をクリックします。この例では、「ネイティブ・データからXMLデータへの変換方法」と同じスキーマ・ファイルが使用されています。図6-19に詳細を示します。

図6-19 スキーマ・ファイルの選択

11. 「出力タイプ」リストから、「文字列」を選択します。

かわりに、「添付ファイル」を指定すると、ダイアログはリフレッシュされ、添付ファイルのディレクトリ場所を指定するための「場所」フィールドが表示されます。「添付ファイル」の選択は、XMLデータが非常に大きいシナリオでは便利です。

12. 「出力」フィールドの右側で、「検索」(1番目)アイコンをクリックするか、「変数の作成」アイコンをクリックして、タイプ文字列の新しい出力変数を自動的に作成します。

13. 出力変数を選択して「OK」をクリックします。図6-20に詳細を示します。

図6-20 出力変数の選択

「変換」ダイアログは図6-21 のようになります。

図6-21 アウトバウンド変換用に構成された「変換」ダイアログ

これで、設計は完了します。

6.3.3 インバウンド・ネイティブ・データから添付ファイルとして格納されるXMLへの変換方法

この項では、ネイティブ・データ・フォーマットのインバウンド・メッセージを添付ファイルに変換する方法について説明します。添付ファイルは、受信データが非常に大きいシナリオで便利です。

インバウンド・ネイティブXSDフォーマットを添付ファイルに変換するには:

1. BPELプロセスを作成します(この例では、一方向BPELプロセスが作成されます)。

2. BPELプロセスをSOAコンポジット・エディタで右クリックし、「編集」を選択します。

Oracle BPELデザイナが表示されます。

3. 「コンポーネント」ウィンドウの「Oracle Extensions」セクションを展開し、変換アクティビティをBPELプロセスにドラッグします。

4. 変換アクティビティを右クリックし、「編集」を選択します。

「変換」ダイアログが編集用に表示されます。

5. 「ネイティブからXML」を選択して、インバウンド・ネイティブ・データを添付ファイルに変換します。

6. 「入力」フィールドの右側にある「参照」(1番目)アイコンをクリックします。

7. 入力変数を選択します(この例では、巨大な文字列)。図6-22に詳細を示します。

図6-22 入力変数の選択

8. 「NXSDスキーマ」フィールドの右側にある「検索」(1番目)アイコンを選択し、「タイプ・チューザ」ダイアログを起動します。

9. スキーマ・ファイルを選択して「OK」をクリックします。この例では、「ネイティブ・データからXMLデータへの変換方法」と同じスキーマ・ファイルが使用されています。図6-23に詳細を示します。

図6-23 スキーマ・ファイルの選択

10. 「出力タイプ」リストから、「添付ファイル」を選択します。

ダイアログがリフレッシュされ、「場所」フィールドが表示されます。

11. 「場所」フィールドに、添付ファイルへのディレクトリ・パスを入力します。このフィールドを空白のままにすると、添付ファイルはデータベースに格納されます。

12. 「出力」フィールドの右側にある「追加」(2番目)アイコンをクリックし、「変数の作成」ダイアログを起動します。

13. 「OK」をクリックして出力変数を作成します。出力変数はタイプ添付ファイルに属します。

「変換」ダイアログは図6-24 のようになります。

図6-24 添付ファイルの「変換」ダイアログ

14. 「OK」をクリックします。

15. 「アプリケーション」ウィンドウで、BPELプロセスのファイルを選択します。

16. 「ソース」をクリックします。

17. 添付ファイル用に指定した場所がhref属性にコピーされることに注意してください。href属性は、手順12で作成されたタイプ添付ファイルの変数の一部です。

. . .
<copy>
<from> '/scratch/sbandyop/tmp/out/dhqa_addr_att.xml'</from>
<to> $Translate1_OutputVar_1/@href</to>
</copy>
. . .

18. 「アプリケーション」ウィンドウで、BPELプロセスのWSDLファイルを選択します。

19. 「ソース」をクリックします。

20. ファイルのWSDL定義セクションに追加されたattachmentコードと、手順12で作成された変数により指し示されるhref属性に注意してください。

. . .
xmlns:attach="http://xmlns.oracle.com/DHQATranslateApp/DHQATranslateToAttach/BPELProcess1/attachment"
. . .
. . .
. . .
<element name="attachmentElement">
<complexType>
<attribute name="href" type="string"/>
</complexType>
</element>
. . .
. . .

これで、設計は完了します。

6.4 スタンドアロンSDOベースの変数の使用

スタンドアロンSDOベースの変数は、通常のBPEL XML-DOMベースの変数と類似しています。主な違いは、基礎となるデータ形式がDOMベースではなくSDOベースであることです。したがって、SDOベースの変数は、Java APIアクセス、簡単に使用できる最新のAPI、変更内容のサマリーなど、様々なSDO機能を使用できます。ただし、SDOを使用する場合は、XML-DOMベースの変数を使用する場合にはない複数の制限も適用されます。最も顕著な制限は、SDOがXPath式の小さいサブセットのみをサポートしていることです。

6.4.1 SDOベースの変数の宣言方法

SDOベースの変数を宣言するための構文は、BPEL変数を宣言する構文と類似しています。次の例に詳細を示します。

<variable name="deptVar_s" element="hrtypes:dept" />
<variable name="deptVar_v" element="hrtypes:dept" bpelx:sdoCapable="false" />

自動検出を無効にする場合は、bpelx:sdoCapable="true|false"スイッチを使用します。たとえば、ここでのサンプルの変数deptVar_vは通常のDOMベースの変数です。次に、XSDの例を示します。

<xsd:element name="dept" type="Dept"/>
<xsd:complexType name="Dept"
sdoJava:instanceClass="sdo.sample.service.types.Dept">
<xsd:annotation>
<xsd:appinfo source="Key"
xmlns="http://xmlns.oracle.com/bc4j/service/metadata/">
<key>
<attribute>Deptno</attribute>
</key>
<fetchMode>minimal</fetchMode>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="Deptno" type="xsd:integer" minOccurs="0"/>
<xsd:element name="Dname" type="xsd:string" minOccurs="0"
nillable="true"/>
<xsd:element name="Loc" type="xsd:string" minOccurs="0" nillable="true"/>
<xsd:element name="Emp" type="Emp" minOccurs="0" maxOccurs="unbounded"
nillable="true"/>
</xsd:sequence>
</xsd:complexType>

6.4.2 XMLからSDOへの変換方法

Oracle BPEL Process Managerでは、DOMとSDOの2つのデータ形式をサポートしています。同じビジネス・プロセス内で、さらに同じ式の中で、DOMベースの変数とSDOベースの変数の使用を切り替えることができます。Oracle BPEL Process Managerのデータ・フレームワークは、DOM形式とSDO形式を自動的に変換します。

Oracle BPEL Process Managerでは、エンティティ変数のXPathリライト機能を使用することで、基本的なSDO仕様ではサポートされない複数のXPath機能(変数の参照、関数コールなど)を使用できます。一方で、SDOベースの変数を使用するXPathには、別の制限があります(and、orおよびnotがサポートされないなど)。

次に、XMLからSDOに変換する例を示します。

<assign>
<copy>
<from>
<ns0:dept xmlns:ns0="http://sdo.sample.service/types/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns0:Deptno>10</ns0:Deptno>
<ns0:Dname>ACCOUNTING</ns0:Dname>
<ns0:Loc>NEW YORK</ns0:Loc>
<ns0:Emp>
<ns0:Empno>7782</ns0:Empno>
<ns0:Ename>CLARK</ns0:Ename>
<ns0:Job>MANAGER</ns0:Job>
<ns0:Mgr>7839</ns0:Mgr>
<ns0:Hiredate>1981-06-09</ns0:Hiredate>
<ns0:Sal>2450</ns0:Sal>
<ns0:Deptno>10</ns0:Deptno>
</ns0:Emp>
<ns0:Emp>
<ns0:Empno>7839</ns0:Empno>
<ns0:Ename>KING</ns0:Ename>
<ns0:Job>PRESIDENT</ns0:Job>
<ns0:Hiredate>1981-11-17</ns0:Hiredate>
<ns0:Sal>5000</ns0:Sal>
<ns0:Deptno>10</ns0:Deptno>
</ns0:Emp>
<ns0:Emp>
<ns0:Empno>7934</ns0:Empno>
<ns0:Ename>MILLER</ns0:Ename>
<ns0:Job>CLERK</ns0:Job>
<ns0:Mgr>7782</ns0:Mgr>
<ns0:Hiredate>1982-01-23</ns0:Hiredate>
<ns0:Sal>1300</ns0:Sal>
<ns0:Deptno>10</ns0:Deptno>
</ns0:Emp>
</ns0:dept>
</from>
<to variable="deptVar_s" />
</copy>
</assign>

次に、SDO変数のXPath式からDOM変数にコピーする例を示します。

<assign>
<!-- copy from an XPath expression of an SDO variable to DOM variable -->
<copy>
<from expression="$deptVar_s/hrtypes:Emp[2]" />
<to variable="empVar_v" />
</copy>
<!-- copy from an XPath expression of an DOM variable to SDO variable -->
<copy>
<from expression="$deptVar_v/hrtypes:Emp[2]" />
<to variable="empVar_s" />
</copy>
<!-- insert a DOM based data into an SDO variable -->
<bpelx:insertAfter>
<bpelx:from variable="empVar_v" />
<bpelx:to variable="deptVar_s" query="hrtypes:Emp" />
</bpelx:insertAfter>
<!-- insert a SDO based data into an SDO variable at particular location,
no XML conversion is needed  -->
<bpelx:insertBefore>
<bpelx:from expression="$deptVar_s/hrtypes:Emp[hrtypes:Sal = 1300]" />
<bpelx:to variable="deptVar_s" query="hrtypes:Emp[6]" />
</bpelx:insertBefore>
</assign>

次に、SDOデータを削除する例を示します。

<assign>
<bpelx:remove>
<bpelx:target variable="deptVar_s" query="hrtypes:Emp[2]" />
</bpelx:remove>
</assign>

注意:

SDOベースの変数に対するbpelx:append操作は、次の理由によりサポートされていません。

- SDOベースの変数に対する<copy>操作には、高性能な更新機能があります(<copy>操作の前に<bpelx:append>操作を実行する必要がないなど)。

- SDOデータ・オブジェクトはメタデータ駆動で、一般的に新しいプロパティを任意に追加することがサポートされていません。

6.5 式定数またはリテラルXMLでの変数の初期化

BPELでは、リテラルXMLを変数に代入する方法が役立つことがよくあります(たとえば、動的データを変数に対するXMLデータ・コンテンツ内の特定のフィールドにコピーする前に、変数を初期化する場合などです)。また、XMLデータ値をプロセスにハード・コーディングするときのテストにも役立ちます。assignアクティビティの「コピー・ルール」タブで「リテラル」アイコンをターゲット・ノードにドラッグすることによって、リテラルXMLを割り当てます。

assignアクティビティでのリテラルXMLの割当ての詳細は、「Assignアクティビティ」を参照してください。

6.5.1 リテラルXML要素の割当て方法

次の例では、リテラルのresult要素をoutput変数のpayloadパートに割り当てます。

<assign>
<!-- copy from literal xml to the variable -->
<copy>
<from>
<result xmlns="http://samples.otn.com">
<name/>
<symbol/>
<price>12.3</price>
<quantity>0</quantity>
<approved/>
<message/>
</result>
</from>
<to variable="output" part="payload"/>
</copy>
</assign>

6.6 変数間のコピー

変数間のコピーでは、1つの変数(またはパート)から互換性のあるタイプの別の変数に直接コピーします。どちらの変数でも特定のフィールドを指定する必要はありません。つまり、XPath問合せを指定する必要はありません。

図6-25 に示すように、「Assignの編集」ダイアログの「コピー・ルール」タブで、変数のコピーを実行します。

図6-25 変数割当てのための「コピー・ルール」タブ

「コピー・ルール」タブの詳細は、「bpelx拡張要素を使用したXMLデータの操作」および「Assignアクティビティ」を参照してください。

6.6.1 変数間でのコピー方法

次の例は、2つの割当ての実行を示しています。最初に同じタイプの2つの変数の間でコピーを実行し、次に変数パートをそのパートと同じタイプの別の変数にコピーします。

<assign>
<copy>
<from variable="c1"/>
<to variable="c2"/>
</copy>
<copy>
<from variable="c1" part = "address"/>
<to variable="c3"/>
</copy>
</assign>

次の例に示すように、BPELファイルは変数を定義します。

<variable name="c1" messageType="x:person"/>
<variable name="c2" messageType="x:person"/>
<variable name="c3" element="y:address"/>

次の例に示すように、WSDLファイルはpersonメッセージ・タイプを定義します。

<message name="person" xmlns:x="http://tempuri.org/bpws/example">
<part name="full-name" type="xsd:string"/>
<part name="address" element="x:address"/>
</message>

このコード例の詳細は、の第9.3.2項を参照してください。BPEL 2.0の場合は、の第8.4.4項の類似した例を参照してください。

詳細は、「Assignアクティビティ」を参照してください。

6.6.2 BPEL 2.0のインラインfrom-specを使用した変数を初期化する方法

インラインfrom-specを使用することで、必要に応じて変数を初期化できます。このタイプの変数を作成するには、BPEL 2.0プロジェクトの「変数の作成」ダイアログで「初期化」タブをクリックします。図6-26に詳細を示します。

図6-26 「変数の作成」ダイアログの「初期化」タブ

インライン変数の初期化は、概念的には、変数宣言に表示される順序でそれぞれが初期化された、一連の仮想assignアクティビティを含む1つの仮想sequenceアクティビティとして設計されます。各仮想assignアクティビティには、from-specが変数の初期化で指定されている1つの仮想コピー操作が含まれます。to-specは、作成される変数を指します。次の例に詳細を示します。

<variables>
<variable name="tmp" element="tns:output">
<from>
<literal>
<output xmlns="http://samples.otn.com/bpel2.0/ch8.1">
<value>1000</value>
</output>
</literal>
</from>
</variable>
</variables>

詳細は、の第8.1項を参照してください。

6.7 「構造」ウィンドウでの変数の移動およびコピー

Oracle JDeveloperの「構造」ウィンドウでは、scopeアクティビティ間で変数を移動およびコピーできます。

6.7.1 「構造」ウィンドウで変数を移動する手順:

1. 「構造」ウィンドウで、scopeアクティビティに移動する変数を選択します。図6-27に詳細を示します。

図6-27 「構造」ウィンドウで移動する変数

2. scopeアクティビティの「変数」フォルダに変数をドラッグします。
scopeアクティビティの「変数」フォルダに変数が表示されます(図6-28 を参照)。

図6-28 「構造」ウィンドウでscopeアクティビティに移動された変数

3. BPELプロセスで、scopeアクティビティの「変数」アイコンをクリックします。
移動した変数が表示されます(図6-29 を参照)。

図6-29 scopeアクティビティの「変数」ダイアログに表示される移動された変数

6.7.2 「構造」ウィンドウで変数をコピーする手順:

1. 「構造」ウィンドウで、scopeアクティビティに移動する変数を選択します。

2. [Ctrl]キーを押したままにします。

3. scopeアクティビティの「変数」フォルダに変数をドラッグします。
両方の「変数」フォルダに変数が表示されます(図6-30 を参照)。

図6-30 「構造」ウィンドウでscopeアクティビティにコピーされた変数

6.8 要素変数およびメッセージ・タイプ変数内のフィールドへのアクセス

ほとんどのWSDLファイルやXSDファイルに定義のタイプが存在する場合は、要素およびメッセージ・タイプに基づいて変数パート内のコピー元またはコピー先フィールドのレベルに移動する必要があります。そこで、XMLスキーマの複合型を順に使用します。このアクションを実行するには、assignアクティビティの「コピー・ルール」タブのfrom句またはto句にXPath問合せを指定します。

「コピー・ルール」タブの詳細は、「bpelx拡張要素を使用したXMLデータの操作」および「Assignアクティビティ」を参照してください。

6.8.1 要素ベース変数およびメッセージ・タイプベース変数内のフィールドへのアクセス方法

次の例では、ssnフィールドはCreditFlowプロセスの入力メッセージから信用格付けサービスの入力メッセージのssnフィールドにコピーされます。

<assign>
<copy>
<from variable="input" part="payload"
query="/tns:CreditFlowRequest/tns:ssn"/>
<to variable="crInput" part="payload" query="/tns:ssn"/>
</copy>
</assign>

次の例に、この割当てに必要なメッセージ・タイプベースの変数をBPELファイルで定義する方法を示します。

<variable name="input" messageType="tns:CreditFlowRequestMessage"/>
<variable name="crInput"
messageType="services:CreditRatingServiceRequestMessage"/>

crInput変数は、信用格付けサービスへの入力メッセージとして使用されます。そのメッセージ・タイプCreditFlowRequestMessageは、次の例に示すように、CreditFlowService.wsdlファイルで定義されます。

<message name="CreditFlowRequestMessage">
<part name="payload" element="tns:CreditFlowRequest"/>
</message>

CreditFlowRequestは、ssnという名前のフィールドで定義されます。メッセージ・タイプCreditRatingServiceRequestMessageは、次の例に示すように、CreditRatingService.wsdlファイルで定義されます。

<message name="CreditRatingServiceRequestMessage">
<part name="payload" element="tns:ssn"/>
</message>

次の例に、最初の割当て例の割当てに含まれるメッセージ・タイプベース変数をBPELファイルで定義する方法のBPEL 2.0の構文を示します。/tns:CreditFlowRequestは不要であることに注意してください。

<copy>
<from>$input.payload/tns:ssn</from>
<to>$crInput.payload</to>
</copy>

BPELプロセスでは、要素ベースの変数も使用できます。次の例に、BPEL 1.1で要素ベースの変数を使用する方法を示します。autoloanフィールドは融資申請プロセスの入力メッセージからWebサービスの入力メッセージのcustomerフィールドにコピーされます。

<assign>
<copy>
<from variable="input" part="payload"
query="/tns:invalidLoanApplication/autoloan:
application/autoloan:customer"/>
<to variable="customer"/>
</copy>
</assign>

次の例に、BPEL 2.0で要素ベースの変数を使用する方法を示します。

<assign>
<copy>
<from>$input.payload/autoloan:application/autoloan:customer</from>
<to>$customer</to>
</copy>
</assign>

次の例に、割当てに必要な要素ベースの変数をBPELファイルで定義する方法を示します。

<variable name="customer" element="tns:customerProfile"/>

6.9 数値の割当て

XPath式では数値を割り当てることができます。

6.9.1 数値の割当て方法

次の例は、XPath式に整数値100を割り当てる方法を示しています。

<assign>
<!-- copy from integer expression to the variable -->
<copy>
<from expression="100"/>
<to variable="output" part="payload" query="/p:result/p:quantity"/>
</copy>
</assign>

6.10 XPath標準による数学的計算の使用

次の項の式のように、単純な計算式を使用して、数値を増分させることができます。

6.10.1 XPath標準による数学的計算の使用方法

次の例では、BPEL XPath関数getVariableDataにより、増分した値が取得されます。getVariableDataへの引数は、from句のvariable、partおよびquery属性と同じです(オプションの最後の2つの引数を含む)。

<assign>
<copy>
<from expression="bpws:getVariableData('input', 'payload',
'/p:value') + 1"/>
<to variable="output" part="payload" query="/p:result"/>
</copy>
</assign>

また、次の例に示すように、BPEL 1.1で$variable構文を使用することもできます。

<assign>
<copy>
<from expression="$input.payload + 1"/>
<to variable="output" part="payload" query="/p:result"/>
</copy>
</assign>

次の例に、BPEL 2.0で$variable構文を使用する方法を示します。

<assign>
<copy>
<from>$input.payload + 1</from>
<to>$output.payload</to>
</copy>
</assign>

6.11 文字列リテラルの割当て

assignアクティビティの「コピー・ルール」タブで、文字列リテラルを変数に割り当てることができます。

assignアクティビティの詳細は、「bpelx拡張要素を使用したXMLデータの操作」および「Assignアクティビティ」を参照してください。

6.11.1 文字列リテラルの割当て方法

次の例のコードは、文字列リテラル'GE'から評価されるBPEL 1.1式を、指定された変数パート内のsymbolフィールドにコピーしています。(二重引用符および一重引用符を使用していることに注意してください)。

<assign>
<!-- copy from string expression to the variable -->
<copy>
<from expression="'GE'"/>
<to variable="output" part="payload" query="/p:result/p:symbol"/>
</copy>
</assign>

次の例に、BPEL 2.0でこの式を実行する方法を示します。

<assign>
<copy>
<from>'GE'</from>
<to>$output.payload/p:symbol</from>
</copy>
</assign>

詳細は、「Assignアクティビティ」を参照してください。

6.12 文字列の連結

1つの文字列変数(または変数パート、フィールド)の値を別の文字列変数にコピーするのではなく、いくつかの文字列を連結するなどの文字列操作を最初に実行できます。

6.12.1 文字列の連結方法

連結は、concatというコアXPath関数を使用して実行します。また、連結に含まれる変数値は、BPEL XPath関数getVariableDataを使用して取得します。次の例では、getVariableDataがinput変数のpayloadパートからnameフィールドの値をフェッチします。次に、文字リテラル'Hello 'が、この値の先頭に連結されます。

<assign>
<!-- copy from XPath expression to the variable -->
<copy>
<from expression="concat('Hello ',
bpws:getVariableData('input', 'payload', '/p:name'))"/>
<to variable="output" part="payload" query="/p:result/p:message"/>
</copy>
</assign>

XPathで使用できるその他の文字列操作関数は、の第4.2項にリストされています。

6.13 ブール値の割当て

XPathブール関数を使用してブール値を割り当てることができます。

6.13.1 ブール値の割当て方法

次の例に、BPEL 1.1でブール値を割り当てる例を示します。from句のXPath式は、XPathブール関数trueのコールであり、指定されたapprovedフィールドがtrueに設定されます。関数falseも使用できます。

<assign>
<!-- copy from boolean expression function to the variable -->
<copy>
<from expression="true()"/>
<to variable="output" part="payload" query="/result/approved"/>
</copy>
</assign>

次の例に、BPEL 2.0でブール値を割り当てる例を示します。

<assign>
<copy>
<from>true()</from>
<to>$output.payload/approved</to>
</copy>
</assign>

XPath仕様では、ブール定数値を返すメソッドとして"true()"および"false()"関数を使用するように推奨しています。

かわりに"boolean(true)"または"boolean(false)"を使用すると、ブール関数内のtrueまたはfalseはtrueまたはfalse定数ではなく相対要素ステップと解釈されます。現行のXPathコンテキスト・ノードでtrueという子ノードの選択が試行されます。ほとんどの場合、trueノードは存在しません。したがって、空の結果ノードセットが返され、それがXPath 1.0のboolean()関数によりfalseの結果に変換されます。この結果は混同される可能性があります。

6.14 日付または時刻の割当て

Oracle BPEL XPath関数のgetCurrentDate、getCurrentTimeまたはgetCurrentDateTimeを使用して、日付または時刻フィールドの現在値を割り当てることができます。さらに、日時の値が標準XSD形式の場合は、Oracle BPEL XPath関数formatDateをコールして、出力用により適切な文字に変換できます。

関連情報は、の第9.1.2項およびの第8.3.2項を参照してください。

XPath関数および式ビルダーの詳細は、「XPath拡張関数」を参照してください。

6.14.1 日付または時刻の割当て方法

次の例に、BPEL 1.1で関数getCurrentDateを使用する例を示します。

<!-- execute the XPath extension function getCurrentDate() -->
<assign>
<copy>
<from expression="xpath20:getCurrentDate()"/>
<to variable="output" part="payload"
query="ns1:invoice/invoiceDate"/>
</copy>
</assign>

次の例に、BPEL 2.0で関数getCurrentDateを使用する例を示します。

<assign>
<copy>
<from>xpath20:getCurrentDate()</from>
<to>$output.payload/invoiceDate</to>
</copy>
</assign>

次の例では、XSD形式で指定された日時の値をformatDate関数が文字列'Jun 10, 2005'に変換し、文字列フィールドformattedDateに割り当てています。

<!-- execute the XPath extension function formatDate() -->
<assign>
<copy>
<from expression="ora:formatDate('2005-06-10T15:56:00',
'MMM dd, yyyy')"/>
<to variable="output" part="payload"
query="ns1:invoice/formattedDate"/>
</copy>
</assign>

次の例に、BPEL 2.0でのformatDate関数の動作を示します。

<assign>
<copy>
<from>ora:formatDate('2005-06-10T15:56:00','MMM dd, yyyy')</from>
<to>$output.payload/formattedDate</to>
</copy>
</assign>

6.15 属性の操作

XML属性として定義されている要素は相互にコピーできます。XPath問合せ構文では、@記号は子要素のかわりに属性を参照します。

6.15.1 属性の操作方法

次の例のコードは、このXMLデータからcustId属性をフェッチしてコピーしています。

<invalidLoanApplication xmlns="http://samples.otn.com">
<application xmlns = "http://samples.otn.com/XPath/autoloan">
<customer custId = "111" >
<name>
Mike Olive
</name>
...
</customer>
...
</application>
</invalidLoanApplication>

次の例のBPEL 1.1のコードは、customerフィールドのcustId属性を選択し、変数custIdに割り当てています。

<assign>
<!-- get the custId attribute and assign to variable custId -->
<copy>
<from variable="input" part="payload"
query="/tns:invalidLoanApplication/autoloan:application
/autoloan:customer/@custId"/>
<to variable="custId"/>
</copy>
</assign>

次の例に、customerフィールドのcustId属性を選択し、変数custIdに割り当てるためのBPEL 2.0の対応する構文を示します。

<assign>
<copy>
<from>$input.payload/autoloan:application/autoloan:customer/@custId</from>
<to>$custId</to>
</copy>
</assign>

この例のネームスペース接頭辞は必須ではありません。次の例に示すように、WSDLファイルは、custIdが属性として定義される型を持つように顧客を定義します。

<complexType name="CustomerProfileType">
<sequence>
<element name="name" type="string"/>
...
</sequence>
<attribute name="custId" type="string"/>
</complexType>

6.16 bpelx拡張要素を使用したXMLデータの操作

assignアクティビティではXMLデータに対して様々な操作を実行できます。この項で説明されているbpelx拡張要素タイプにはこの機能が用意されています。Oracle BPELデザイナでは、「割当て」ダイアログの「コピー・ルール」タブの下部にbpelx拡張要素タイプを追加できます。コピー・ルールを作成した後、作成したルールを選択し、BPEL 1.1のドロップダウン・リストまたはBPEL 2.0のコンテキスト・メニューからbpelx拡張要素タイプを選択します。これにより、コピー・ルールが選択した拡張要素タイプに変更されます。

BPEL 1.1では、図6-31 に示すように、ドロップダウン・リストから拡張要素タイプを選択します。

図6-31 BPEL 1.1のbpelx拡張要素に変換されたコピー・ルール

BPEL 2.0では、図6-32 に示すように、コピー・ルールを右クリックし、ルール・タイプの変更を選択して拡張要素タイプを選択することで、拡張要素タイプを選択します。

図6-32 BPEL 2.0のbpelx拡張要素に変換されたコピー・ルール

詳細は、このダイアログのオンライン・ヘルプおよび「Assignアクティビティ」を参照してください。

6.16.1 bpelx:appendの使用方法

assignアクティビティでbpelx:append拡張要素を使用すると、BPELプロセス・サービス・コンポーネントは1つの変数、式またはXMLフラグメントのコンテンツを別の変数のコンテンツに追加できます。この拡張機能を使用するには、「コピー・ルール」タブの下部で次の手順の1つを実行します。

- BPEL 1.1の場合は、図6-31 のように、コピー・ルールを選択してドロップダウン・リストから「追加」を選択します。

- BPEL 2.0の場合、図6-32 のように、コピー・ルールを右クリックしてルール・タイプの変更を選択し、「追加」を選択します。

注意:

bpelx:append拡張要素では、SDO変数の使用はサポートされていません。エラーが発生します。

6.16.1.1 BPEL 1.1のbpelx:append

次に、BPELバージョン1.1をサポートするBPELプロジェクトのbpelx:appendの例を示します。

<bpel:assign>
<bpelx:append>
<bpelx:from ... />
<bpelx:to ... />
</bpelx:append>
</bpel:assign>

bpelx:append内のfrom-spec問合せでは、0(ゼロ)個以上のノードが取得されます。ノード・リストは、to-spec問合せで指定したターゲット・ノードに子ノードとして追加されます。

to-spec問合せでは、単一L-Value要素ノードを1つ取得する必要があります。それ以外の場合は、bpel:selectionFailureフォルトが生成されます。to-spec問合せではパートナ・リンクを参照できません。

次の例では、1つの部品表(BOM)の複数のb:partを連結BOMのb:partに追加することで、複数のBOMを1つのBOMに連結しています。

<bpel:assign>
<bpelx:append>
<bpelx:from variable="billOfMaterialVar"
query="/b:bom/b:parts/b:part" />
<bpelx:to variable="consolidatedBillOfMaterialVar"
query="/b:bom/b:parts" />
</bpelx:append>
</bpel:assign>

6.16.1.2 BPEL 2.0のbpelx:append

次に、BPELバージョン2.0をサポートするBPELプロジェクトのbpelx:append構文の例を示します。BPEL 2.0では、この機能は「BPEL 1.1のbpelx:append」で説明されている機能と同じですが、構文が多少異なります。

<bpel:assign>
<bpelx:append>
<bpelx:from>$billOfMaterialVar/b:parts/b:part</bpelx:from>
<bpelx:to>$consolidatedBillOfMaterialVar/b:parts</bpelx:from>
</bpelx:append>
</bpel:assign>

6.16.2 bpelx:insertBeforeの使用方法

注意:

bpelx:insertBefore拡張要素ではSDO変数を使用できますが、ターゲットは、コピーされたデータの移動先の変数属性にする必要があります。

assignアクティビティでbpelx:insertBefore拡張要素を使用すると、BPELプロセス・サービス・コンポーネントは1つの変数、式またはXMLフラグメントのコンテンツを別の変数のコンテンツの前に挿入できます。この拡張機能を使用するには、「コピー・ルール」タブの下部で次の手順の1つを実行します。

- BPEL 1.1の場合は、図6-31 のように、コピー・ルールを選択してドロップダウン・リストから「前に挿入」を選択します。

- BPEL 2.0の場合、図6-32 のように、コピー・ルールを右クリックして「ルール・タイプの変更」を選択し、「前に挿入」を選択します。

6.16.2.1 BPEL 1.1のbpelx:insertBefore

次に、BPELバージョン1.1をサポートするBPELプロジェクトのbpelx:insertBeforeの例を示します。

<bpel:assign>
<bpelx:insertBefore>
<bpelx:from ... />
<bpelx:to ... />
</bpelx:insertBefore>
</bpel:assign>

bpelx:insertBefore内のfrom-spec問合せでは、0(ゼロ)個以上のノードが取得されます。ノード・リストは、to-spec問合せで指定したターゲット・ノードに子ノードとして追加されます。

insertBefore操作のto-spec問合せは、1つ以上の単一L-Valueノードを指し示します。複数のノードが返された場合は、最初のノードが参照ノードとして使用されます。参照ノードは要素ノードである必要があります。参照ノードの親も要素ノードである必要があります。それ以外の場合は、bpel:selectionFailureフォルトが生成されます。from-spec問合せの選択により生成されたノード・リストは、参照ノードの前に挿入されます。to-spec問合せではパートナ・リンクを参照できません。

次の例に、<insertBefore>の実行前の構文を示します。addrVarの値は次のとおりです。

<a:usAddress>
<a:state>CA</a:state>
<a:zipcode>94065</a:zipcode>
</a:usAddress>

次の例に、実行後の構文を示します。

<bpel:assign>
<bpelx:insertBefore>
<bpelx:from>
<a:city>Redwood Shore></a:city>
</bpelx:from>
<bpelx:to "addrVar" query="/a:usAddress/a:state" />
</bpelx:insertBefore>
</bpel:assign>

次の例に、addrVarの値を示します。

<a:usAddress>
<a:city>Redwood Shore</a:city>
<a:state>CA</a:state>
<a:zipcode>94065</a:zipcode>
</a:usAddress>

6.16.2.2 BPEL 2.0のbpelx:insertBefore

次に、BPELバージョン2.0をサポートするBPELプロジェクトのbpelx:insertBefore構文の例を示します。BPEL 2.0では、この機能は「BPEL 1.1のbpelx:insertBefore」で説明されている機能と同じですが、構文が多少異なります。extensionAssignOperation要素はbpelx:insertBefore拡張要素をラップします。

<assign>
<extensionAssignOperation>
<bpelx:insertBefore>
<bpelx:from>
<bpelx:literal>
<a:city>Redwood Shore></a:city>
</bpelx:literal>
</bpelx:from>
<bpelx:to>$addrVar/a:state</bpelx:to>
</bpelx:insertBefore>
</extensionAssignOperation>
</assign>

6.16.3 bpelx:insertAfterの使用方法

注意:

bpelx:insertAfter拡張要素ではSDO変数を使用できすが、ターゲットは、コピーされたデータの移動先の変数属性にする必要があります。

assignアクティビティでbpelx:insertAfter拡張要素を使用すると、BPELプロセス・サービス・コンポーネントは1つの変数、式またはXMLフラグメントのコンテンツを別の変数のコンテンツの後に挿入できます。この拡張機能を使用するには、「コピー・ルール」タブの下部で次の手順の1つを実行します。

- BPEL 1.1の場合は、図6-31 のように、コピー・ルールを選択してドロップダウン・リストから「後に挿入」を選択します。

- BPEL 2.0の場合、図6-32 のように、コピー・ルールを右クリックしてルール・タイプの変更を選択し、「後に挿入」を選択します。

6.16.3.1 BPEL 1.1のbpelx:insertAfter

次に、BPELバージョン1.1をサポートするBPELプロジェクトのbpelx:insertAfterの例を示します。

<bpel:assign>
<bpelx:insertAfter>
<bpelx:from ... />
<bpelx:to ... />
</bpelx:insertAfter>
</bpel:assign>

この操作は「bpelx:insertBeforeの使用方法」で説明した機能に類似していますが、次の違いがあります。

- to-spec問合せで複数のL-Valueノードが返される場合は、最後のノードが参照ノードとして使用されます。

- 参照ノードの前にノードが挿入されるかわりに、参照ノードの後にソース・ノードが挿入されます。

この操作は、conditional-switch+(appendまたはinsertBefore)のマクロとみなすこともできます。

次の例に、<insertAfter>の実行前の構文を示します。addrVarの値は次のとおりです。

<a:usAddress>
<a:addressLine>500 Oracle Parkway</a:addressLine>
<a:state>CA</a:state>
<a:zipcode>94065</a:zipcode>
</a:usAddress>

次の例に、実行後の構文を示します。

<bpel:assign>
<bpelx:insertAfter>
<bpelx:from>
<a:addressLine>Mailstop 1op6</a:addressLine>
</bpelx:from>
<bpelx:to "addrVar" query="/a:usAddress/a:addressLine[1]" />
</bpelx:insertAfter>
</bpel:assign>

次の例に、addrVarの値を示します。

<a:usAddress>
<a:addressLine>500 Oracle Parkway</a:addressLine>
<a:addressLine>Mailstop 1op6</a:addressLine>
<a:state>CA</a:state>
<a:zipcode>94065</a:zipcode>
</a:usAddress>

bpelx:insertAfter内のfrom-spec問合せでは、0(ゼロ)個以上のノードが取得されます。ノード・リストは、to-spec問合せで指定したターゲット・ノードに子ノードとして追加されます。

6.16.3.2 BPEL 2.0のbpelx:insertAfter

次に、BPELバージョン2.0をサポートするBPELプロジェクトのbpelx:insertAfter構文の例を示します。BPEL 2.0では、この機能は「BPEL 1.1のbpelx:InsertAfter」で説明されている機能と同じですが、構文が多少異なります。extensionAssignOperation要素はbpelx:insertAfter拡張要素をラップします。

<assign>
<extensionAssignOperation>
<bpelx:insertAfter>
<bpelx:from>
<bpelx:literal>
<a:addressLine>Mailstop 1op6</a:addressLine>
</bpelx:literal>
</bpelx:from>
<bpelx:to>$addrVar/a:addressLine[1]</bpelx:to>
</bpelx:insertAfter>
</extensionAssignOperation>
</assign>

6.16.4 bpelx:removeの使用方法

assignアクティビティでbpelx:remove拡張要素を使用すると、BPELプロセス・サービス・コンポーネントは変数を削除できます。Oracle BPELデザイナでbpelx:remove拡張要素を追加するには、「コピー・ルール」タブの右上隅にある「削除」アイコンを、削除するターゲット変数にドラッグしてカーソルを離します。このアイコンを、センター・キャンバスにドラッグしてダイアログを呼び出し、ルールを指定し、ダイアログを保存して閉じ、アイコンをターゲット・ノードにドラッグすることもできます。図6-33に詳細を示します。

図6-33 assignアクティビティの「コピー・ルール」タブの「削除」アイコン

カーソルを離すと、bpelx:remove拡張要素がターゲット変数に適用されます。図6-34に詳細を示します。

図6-34 ターゲット変数に適用されたbpelx:remove拡張要素

6.16.4.1 BPEL 1.1のbpelx:remove

次に、BPELバージョン1.1をサポートするBPELプロジェクトのbpelx:removeの例を示します。

<bpel:assign>
<bpelx:remove>
<bpelx:target variable="ncname" part="ncname"? query="xpath_str" />
</bpelx:remove>
</bpel:assign>

XPath式で指定したノード削除がサポートされます。XPath式では複数のノードを指定できますが、いずれもL-Valueである必要があります。この親からは、テキスト・ノード、属性ノードおよび要素ノードを削除できます。

XPath式では、1つ以上のノードを返すことができます。XPath式で0(ゼロ)個のノードが返される場合は、bpel:selectionFailureフォルトが生成されます。

bpelx:targetの構文は、copy操作のto-specに類似しており、そのサブセットです。

次の例にaddrVarを示します。値は次のとおりです。

<a:usAddress>
<a:addressLine>500 Oracle Parkway</a:addressLine>
<a:addressLine>Mailstop 1op6</a:addressLine>
<a:state>CA</a:state>
<a:zipcode>94065</a:zipcode>
</a:usAddress>

BPELプロセス・サービス・コンポーネント・ファイルで次に示す構文を実行すると、2番目のアドレス行であるMailstopが削除されます。

<bpel:assign>
<bpelx:remove>
<target variable="addrVar"
query="/a:usAddress/a:addressLine[2]" />
</bpelx:remove>
</bpel:assign>

BPELプロセス・サービス・コンポーネント・ファイルで次に示す構文を実行すると、両方のアドレス行が削除されます。

<bpel:assign>
<bpelx:remove>
<target variable="addrVar"
query="/a:usAddress/a:addressLine" />
</bpelx:remove>
</bpel:assign>

6.16.4.2 BPEL 2.0のbpelx:remove

次に、BPELバージョン2.0をサポートするBPELプロジェクトのbpelx:remove構文の例を示します。BPEL 2.0では、この機能は「BPEL 1.1のbpelx:remove」で説明されている機能と同じですが、構文が多少異なります。extensionAssignOperation要素はbpelx:remove拡張要素をラップします。

<assign>
<extensionAssignOperation>
<bpelx:remove>
<bpelx:target>$ncname.ncname/xpath_str</bpelx:target>
</bpelx:remove>
</extensionAssignOperation>
</assign>

6.16.5 bpelx:renameおよびXSDタイプ・キャストの使用方法

assignアクティビティでbpelx:rename拡張要素を使用すると、BPELプロセス・サービス・コンポーネントはXSDタイプ・キャストを使用して要素の名前を変更できます。Oracle BPELデザイナでbpelx:rename拡張要素を追加するには、「コピー・ルール」タブの右上隅にある「名前の変更」アイコンを、名前を変更するターゲット変数にドラッグしてカーソルを離します。図6-33 に示すように、「名前の変更」アイコンは「削除」アイコンの右側に表示されます。カーソルを離すと、ターゲット変数の名前を変更するための「名前の変更」ダイアログが表示されます。このアイコンを、センター・キャンバスにドラッグしてこのダイアログを呼び出し、名前を指定し、ダイアログを保存して閉じ、アイコンをターゲット・ノードにドラッグすることもできます。

6.16.5.1 BPEL 1.1のbpelx:rename

次に、BPELバージョン1.1をサポートするBPELプロジェクトのbpelx:renameの例を示します。

<bpel:assign>
<bpelx:rename elementTo="QName1"? typeCastTo="QName2"?>
<bpelx:target variable="ncname" part="ncname"? query="xpath_str" />
</bpelx:rename>
</bpel:assign>

bpelx:targetの構文は、copy操作のto-specに類似しており、そのサブセットです。ターゲットは要素ノードのリストを返す必要があります。それ以外の場合は、bpel:selectionFailureフォルトが生成されます。from-specで指定した要素ノード名が、elementTo属性で指定したQNameに変更されます。その要素ノードにxsi:type属性が追加され、それらの要素がtypeCastTo属性で指定したQNameタイプにキャストされます。

次の例に示す従業員リストがあるとします。

<e:empList>
<e:emp>
<e:firstName>John</e:firstName><e:lastName>Dole</e:lastName>
<e:emp>
<e:emp xsi:type="e:ManagerType">
<e:firstName>Jane</e:firstName><e:lastName>Dole</e:lastName>
<e:approvalLimit>3000</e:approvalLimit>
<e:managing />
<e:emp>
<e:emp>
<e:firstName>Peter</e:firstName><e:lastName>Smith</e:lastName>
<e:emp>
<e:emp>
<e:firstName>Mary</e:firstName><e:lastName>Smith</e:lastName>
<e:emp>
</e:empList>

昇格の変更が、次の例の従業員リストのPeter Smithに適用されます。

<bpel:assign>
<bpelx:rename typeCastTo="e:ManagerType">
<bpelx:target variable="empListVar"
query="/e:empList/e:emp[./e:firstName='Peter' and
./e:lastName='Smith'" />
</bpelx:rename>
</bpel:assign>

前述のキャスト(名前変更)の実行後は、Peter Smithにxsi:type情報が追加され、データは次の例に示すようになります。

<e:empList>
<e:emp>
<e:firstName>John</e:firstName><e:lastName>Dole</e:lastName>
<e:emp>
<e:emp xsi:type="e:ManagerType">
<e:firstName>Jane</e:firstName><e:lastName>Dole</e:lastName>
<e:approvalLimit>3000</e:approvalLimit>
<e:managing />
<e:emp>
<e:emp xsi:type="e:ManagerType">
<e:firstName>Peter</e:firstName><e:lastName>Smith</e:lastName>
<e:emp>
<e:emp>
<e:firstName>Mary</e:firstName><e:lastName>Smith</e:lastName>
<e:emp>
</e:empList>

<approvalLimit>および<managing>がないため、Peter Smithの従業員データは無効になっています。したがって、その情報を追加するために<append>が使用されます。次に例を示します。

<bpel:assign>
<bpelx:rename typeCastTo="e:ManagerType">
<bpelx:target variable="empListVar"
query="/e:empList/e:emp[./e:firstName='Peter' and
./e:lastName='Smith'" />
</bpelx:rename>
<bpelx:append>
<bpelx:from>
<e:approvalLimit>2500</e:approvalLimit>
<e:managing />
</bpelx:from>
<bpelx:to variable="empListVar"
query="/e:empList/e:emp[./e:firstName='Peter' and
./e:lastName='Smith'" />
</bpelx:append>
</bpel:assign>

renameおよびappendの両方を実行すると、対応するデータは次の例のようになります。

<e:emp xsi:type="e:ManagerType">
<e:firstName>Peter</e:firstName><e:lastName>Smith</e:lastName>
<e:approvalLimit>2500</e:approvalLimit>
<e:managing />
<e:emp>

6.16.5.2 BPEL 2.0のbpelx:rename

次に、BPELバージョン2.0をサポートするBPELプロジェクトのbpelx:rename構文の例を示します。BPEL 2.0では、この機能は「BPEL 1.1のbpelx:rename」で説明されている機能と同じですが、構文が多少異なります。extensionAssignOperation要素はbpelx:rename操作をラップします。

<bpel:assign>
<extensionAssignOperation>
<bpelx:rename elementTo="QName1"? typeCastTo="QName2"?>
<bpelx:target>$ncname[.ncname][/xpath_str]</bpelx:target>
</bpelx:rename>
</extensionAssignOperation>
</bpel:assign>

6.16.6 bpelx:copyListの使用方法

assignアクティビティでbpelx:copyList拡張要素を使用すると、BPELプロセス・サービス・コンポーネントは1つの変数、式またはXMLフラグメントのコンテンツに対して別の変数へのcopyList操作を実行できます。この拡張機能を使用するには、「コピー・ルール」タブの下部で次の手順の1つを実行します。

- BPEL 1.1の場合は、図6-31 のように、コピー・ルールを選択してドロップダウン・リストから「リストのコピー」を選択します。

- BPEL 2.0の場合、図6-32 のように、コピー・ルールを右クリックしてルール・タイプの変更を選択し、「リストのコピー」を選択します。

6.16.6.1 BPEL 1.1のbpelx:copyList

次に、BPELバージョン1.1をサポートするBPELプロジェクトのbpelx:copyListの例を示します。

<bpel:assign>
<bpelx:copyList>
<bpelx:from ... />
<bpelx:to ... />
</bpelx:copyList>
</bpel:assign>

from-spec問合せでは、すべての属性ノードまたはすべての要素ノードのリストを取得できます。to-spec問合せでは、L-Valueノード(すべての属性ノードまたはすべての要素ノード)のリストを取得できます。

to-spec問合せで返される要素ノードは、すべて同じ親要素を持つ必要があります。to-spec問合せで要素ノードのリストが返される場合は、すべての要素ノードが連続している必要があります。

from-spec問合せで属性ノードが返される場合、to-spec問合せでは属性ノードが返される必要があります。同様に、from-spec問合せで要素ノードが返される場合、to-spec問合せでは要素ノードが返される必要があります。それ以外の場合は、bpws:mismatchedAssignmentFailureフォルトがスローされます。

from-spec問合せでは0(ゼロ)個のノードを返すことができますが、to-spec問合せではノードを1個以上返す必要があります。from-spec問合せで0(ゼロ)個のノードが返される場合、copyList操作の効果はremove操作と同様になります。

copyList操作には、次の機能があります。

- to-spec問合せが指すノードがすべて削除されます。

- to-spec問合せで要素ノードのリストが返され、そのノードが削除された後に子ノードが残っている場合、from-spec問合せで返されたノードは、to-spec問合せで指定した最後の要素と同レベルの次の要素の前に挿入されます。残りの子ノードがない場合は、append操作が実行されます。

- to-spec問合せで属性ノードのリストが返される場合は、その属性が親要素から削除されます。次に、from-spec問合せで返された属性が親要素に追加されます。

たとえば、次に示すようなスキーマが定義されているとします。

<schema attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="http://xmlns.oracle.com/Event_jws/Event/EventTest"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="process">
<complexType>
<sequence>
<element name="payload" type="string"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="processResponse">
<complexType>
<sequence>
<element name="payload" type="string"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
</schema>

from変数には、次の例に示すコンテンツが含まれています。

<ns1:process xmlns:ns1="http://xmlns.oracle.com/Event_jws/Event/EventTest">
<ns1: payload >a</ns1: payload >
<ns1: payload >b</ns1: payload >
</ns1:process>

to変数には、次の例に示すコンテンツが含まれています。

<ns1:processResponse xmlns:ns1="http://xmlns.oracle.com/Event_
jws/Event/EventTest">
<ns1: payload >c</ns1: payload >
</ns1:process>

bpelx:copyList操作は、次の例のようになります。

<assign>
<bpelx:copyList>
<bpelx:from variable="inputVariable" part="payload"
query="/client:process/client:payload"/>
<bpelx:to variable="outputVariable" part="payload"
query="/client:processResponse/client:payload"/>
</bpelx:copyList>
</assign>

これによって、次の例のようにto変数が定義されます。

<ns1:processResponse xmlns:ns1="http://xmlns.oracle.com/Event_
jws/Event/EventTest">
<ns1: payload >a</ns1: payload >
<ns1: payload >b</ns1: payload >
</ns1:process>

6.16.6.2 BPEL 2.0のbpelx:copyList

次に、BPELバージョン2.0をサポートするBPELプロジェクトのbpelx:copyList構文の例を示します。BPEL 2.0では、この機能は「BPEL 1.1のbpelx:copyList」で説明されている機能と同じですが、構文が多少異なります。extensionAssignOperation要素はbpelx:copyList拡張要素をラップします。

<assign>
<extensionAssignOperation>
<bpelx:copyList>
<bpelx:from>$inputVariable.payload/client:payload</bpelx:from>
<bpelx:to>$outputVariable.payload/client:payload</bpelx:to>
</bpelx:copyList>
</extensionAssignOperation>
</assign>

6.16.7 assign拡張要素の属性の使用方法

次の属性をassignアクティビティのコピー・ルールに割り当てることができます。

- ignoreMissingFromData

- insertMissingToData

- keepSrcElementName

assignアクティビティの「コピー・ルール」タブの下部で、選択したコピー・ルールを右クリックして、適切な属性を選択するためのメニューを表示します。図6-35に詳細を示します。

図6-35 assign拡張要素の属性

6.16.7.1 ignoreMissingFromData属性

ignoreMissingFromData属性は、bpel:selectionFailure標準フォルトを抑止します。表6-3 に、BPELバージョン1.1とバージョン2.0の構文の違いを示します。

表6-3 ignoreMissingFromData属性の構文

BPEL 1.1

BPEL 2.0

<copy bpelx:ignoreMissingFromData="yes|no"/>

<copy ignoreMissingFromData="yes|no"/>

6.16.7.2 insertMissingToData属性

insertMissingToData属性は、項目が選択されなかった場合、to-specで指定された(XPath) L-valueを実行するようにランタイムに指示します。表6-4 に、BPELバージョン1.1とバージョン2.0の構文の違いを示します。

表6-4 insertMissingToData属性の構文

BPEL 1.1

BPEL 2.0

<copy bpelx:insertMissingToData="yes|no"/>

<copy bpelx:insertMissingToData="yes|no"/>

6.16.7.3 keepSrcElementName属性

keepSrcElementName属性を使用すると、(to-specの選択に従って)宛先の要素名をソースの要素名に置換できます。この属性は、BPEL 1.1では実装されていませんでした。表6-5 に、BPELバージョン2.0でサポートされている構文を示します。

表6-5 keepSrcElementName属性の構文

BPEL 1.1

BPEL 2.0

未実装

<copy keepSrcElementName="yes|no"/>

6.17 XMLデータの検証

コードを検証してBPELプロジェクト内の無効なXMLデータを識別できます。

6.17.1 BPEL 2.0のXMLデータの検証方法

この項では、BPEL 2.0のXMLデータの検証について説明します。

6.17.1.1 assignアクティビティでのXMLの検証

Oracle BPELデザイナ内のassignアクティビティで、次の手順を実行します。

1. 「コンポーネント」ウィンドウの「BPELコンストラクト」セクションから、デザイナにassignアクティビティをドラッグします。

2. assignアクティビティをダブルクリックします。

3. 「一般」タブで、アクティビティの名前を入力し、「検証」チェック・ボックスを選択します。

4. 「適用」をクリックし、「OK」をクリックします。

5. 「ソース」タブをクリックして構文を表示します。assignアクティビティを使用してXMLデータを検証するための構文は、BPELバージョン1.1とバージョン2.0では多少異なります。

<assign name="Assign1" validate="yes">
. . .
</assign>

6.17.1.2 スタンドアロン、拡張validateアクティビティでのXMLの検証

Oracle BPELデザイナ内のスタンドアロン(assignアクティビティなしで使用可能な拡張validateアクティビティ)で、次の手順を実行します。

1. 「コンポーネント」ウィンドウの「BPELコンストラクト」セクションから、デザイナにvalidateアクティビティをドラッグします。

2. 「検証」アイコンをダブルクリックします。

3. アクティビティの名前を入力します。

4. 「追加」アイコンをクリックして、検証する変数を選択します。

5. 変数を選択し、「OK」をクリックします。

6. 「適用」をクリックし、「OK」をクリックします。

7. 「ソース」タブをクリックして構文を表示します。validateアクティビティを使用してXMLデータを検証するための構文は、BPELバージョン1.1とバージョン2.0では多少異なります。

<validate name="Validate1" variables="inputVariable"/>

6.17.2 BPEL 1.1のXMLデータの検証方法

この項では、BPEL 1.1のXMLデータの検証について説明します。

6.17.2.1 assignアクティビティでのXMLの検証

Oracle BPELデザイナ内のassignアクティビティで、次の手順を実行します。

1. 「コンポーネント」ウィンドウの「BPELコンストラクト」セクションから、デザイナにassignアクティビティをドラッグします。

2. assignアクティビティをダブルクリックします。

3. 「一般」タブで、アクティビティの名前を入力し、「検証」チェック・ボックスを選択します。

4. 「適用」をクリックし、「OK」をクリックします。

5. 「ソース」タブをクリックして構文を表示します。

<assign name=Assign1" bpelx:validate="yes"
. . .
</assign>

6.17.2.2 スタンドアロン、拡張validateアクティビティでのXMLの検証

Oracle BPELデザイナ内のスタンドアロン(assignアクティビティなしで使用可能な拡張validateアクティビティ)で、次の手順を実行します。

1. 「コンポーネント」ウィンドウの「Oracle Extensions」セクションから、デザイナにvalidateアクティビティをドラッグします。

2. 「検証」アイコンをダブルクリックします。

3. アクティビティの名前を入力します。

4. 「追加」アイコンをクリックして、検証する変数を選択します。

5. 変数を選択し、「OK」をクリックします。

6. 「適用」をクリックし、「OK」をクリックします。

7. 「ソース」タブをクリックして構文を表示します。

<bpelx:validate name=Validate1" variables="inputVariable"/>

6.18 BPEL 2.0のメッセージ交換アクティビティでの要素変数の使用

次のメッセージ交換アクティビティで変数を指定できます。

- 「Invoke」ダイアログの(inputVariable属性の)「入力」フィールドと(outputVariable属性の)「出力」フィールド

- receiveアクティビティの(variable属性の)「入力」フィールド

- replyアクティビティの(variable属性の)「出力」フィールド

これらのフィールドで参照される変数は通常、QNameが操作で使用される入力および出力メッセージ・タイプと一致するメッセージ・タイプ変数である必要があります。

例外は、アクティビティのWSDL操作が、要素を使用して定義された1つのパートを含むメッセージを使用している場合です。この場合、パートの定義に使用される同じ要素タイプの変数はそれぞれ、invokeアクティビティのinputVariable属性とoutputVariable属性、またはreceiveアクティビティまたはreplyアクティビティのvariable属性で参照できます。

この状況で変数を使用するのは、関連するWSDLメッセージ・タイプに基づいて匿名の一時WSDLメッセージ変数を宣言するのと同じである必要があります。

匿名の一時WSDLメッセージ変数と要素変数の間で要素データをコピーするのは、keepSrcElementName属性がyesに設定された1回のコピー操作による単一の仮想assignアクティビティとして機能します。仮想割当ては、実際のassignアクティビティと同じルールに従い、同じフォルトを使用する必要があります。表6-6に詳細を示します。

表6-6 WSDLメッセージ・パートのマップ

対象

説明

inputVariable属性

属性で参照される変数の値により、匿名の一時WSDLメッセージ変数のパートの値が設定されます。

outputVariable属性

一時WSDLメッセージ変数の受信したパートの値により、属性で参照される変数の値が設定されます。

receiveアクティビティ

着信パートの値により、variable属性で参照される変数の値が設定されます。

replyアクティビティ

variable属性で参照される変数の値により、送信される匿名の一時WSDLメッセージ変数のパートの値が設定されます。フォルトを送信するreplyアクティビティの場合も、同じシナリオが適用されます。

keepSrcElementName属性の詳細は、「keepSrcElementName属性」を参照してください。

6.19 BPEL 2.0でのWSDLメッセージ・パートのマップ

invokeアクティビティおよびreplyアクティビティの「引数マッピング」セクションは、BPEL変数のコンテンツから明示的に作成されるマルチパートWSDLメッセージの代替手段を提供します。

「引数マッピング」セクションを使用する場合、該当するWSDL操作の入力メッセージで指定されたタイプに基づいて、匿名の一時WSDL変数が定義されます。

WSDLメッセージ・パートのマッピングの詳細は、次のURLにあるを参照してください。

http://www.oasis-open.org

6.19.1 WSDLメッセージ・パートのマップ方法

「引数マッピング」表には、選択した操作のパートが含まれています。この表の「値」列を編集することで、各メッセージ・パートの値を設定できます。値を取得して、メッセージ・パートを格納する変数を選択します。

BPEL 2.0でのWSDLメッセージ・パートをマップする手順は、次のとおりです。

1. 図6-36 のreceiveアクティビティには、クライアントからの標準のinputVariable変数が含まれていることに注意してください。

図6-36 receiveアクティビティ

2. 図6-37 のreplyアクティビティの下部にある「引数マッピング」ボタンに注意してください。表のエントリをクリックすることで、各メッセージ・パートの値を設定できます。

図6-37 replyアクティビティの下部に定義されている「引数マッピング」セクション

6.20 BPEL 2.0でのプロセス定義のインポート

import要素を使用して、BPELプロセスが依存する定義を指定できます。次の例に示すように、バージョン2.0のBPELプロセスを作成すると、import要素が.bpelファイルに追加されます。

<process name="Loan Flow"
. . .
. . .
<import namespace="http://xmlns.oracle.com/SOAApplication/SOAProject/LoanFlow"
location="LoanFlow.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"/>

次の例に示すように、import要素を使用して、ネームスペースのないスキーマをインポートすることもできます。

<process name="Loan Flow"
. . .
. . .
<import location="xsd/NoNamespaceSchema.xsd"
importType="http://www.w3.org/2001/XMLSchema"/>

次の例に示すように、import要素を使用して、ネームスペースを持つスキーマをインポートすることもできます。

<process name="Loan Flow"
. . .
. . .
<import namespace="http://www.example.org" location="xsd/TestSchema.xsd"
importType="http://www.w3.org/2001/XMLSchema"/>

import要素は、外部XMLスキーマまたはWSDL定義に対する依存性を宣言するために用意されています。任意の数のimport要素をprocess要素の子として表示できます。各import要素には次の属性を含めることができます。

- namespace: インポートされた定義を指定する絶対URIを識別します。これはオプションの属性です。ネームスペースが指定されている場合、インポートされた定義はそのネームスペースに含まれている必要があります。ネームスペースが指定されていない場合、これはネームスペースで修飾されていない外部定義が使用中であることを示します。インポートされた定義にtargetNamespaceの指定を含めないでください。

- location: 重要な定義を含むドキュメントの場所を指定するURIを識別します。これはオプションの属性です。相対URIを指定できます。location属性が指定されていない場合、プロセスでは外部定義が使用されます。ただし、これらの定義の配置先を示す文は指定されません。

- importType: インポートするドキュメントのタイプを識別します。これは、ドキュメントで使用されるエンコーディング言語を指定する絶対URIである必要があります。これは必須属性です。

- XMLスキーマ1.0ドキュメントをインポートする場合は、この属性の値を"http://www.w3.org/2001/XMLSchema"に設定する必要があります。

- WSDL 1.1ドキュメントをインポートする場合は、値を"http://schemas.xmlsoap.org/wsdl/"に設定する必要があります。この属性に他の値を指定することもできます。

詳細は、の第5.4項を参照してください。

6.21 配列に類似したXMLデータ・シーケンスの操作

データ・シーケンスは、XMLで使用される最も基本的なデータ・モデルの1つです。しかし、データ・シーケンスの操作が重要な場合があります。BPELプロセス・サービス・コンポーネントで使用される最も一般的なデータ・シーケンス・パターンの1つが配列です。XMLスキーマに基づき、データ・シーケンス定義はその属性maxOccursから識別できます。この属性が、1より大きい値に設定されているか、unboundedとしてマークされています。詳細は、http://www.w3.org/TRのXML Schema Specificationを参照してください。

この項の例では、BPELのデータ・シーケンスを操作するいくつかの基本的な方法を示します。ただし、ループの実行、エンドポイントの動的参照など、関連するその他の要件が存在します。次の項では、データ・シーケンス操作の特定の要件について説明します。

6.21.1 配列を使用するXMLデータ・シーケンスへの静的な索引付け方法

必要な要素索引が設計時にわかっているとき、XPath機能を使用してデータ・シーケンス要素を選択する方法を次の2つの例で示します。これらのケースでは、最初の要素です。

次の例では、addresses[1]はaddressesデータ・シーケンスの最初の要素を選択します。

<assign>
<!-- get the first address and assign to variable address -->
<copy>
<from variable="input" part="payload"
query="/tns:invalidLoanApplication/autoloan:application
/autoloan:customer/autoloan:addresses[1]"/>
<to variable="address"/>
</copy>
</assign>

この問合せで、addresses[1]はaddresses[position()=1]と等価で、positionはコアXPath関数の1つです(の第2.4項と第4.1項を参照)。次の例の問合せでは、position関数を明示的にコールして、アドレスのデータ・シーケンスの最初の要素を選択します。次に、そのアドレスのstreet要素(アクティビティで変数street1に割り当てられます)を選択します。

<assign>
<!-- get the first address's street and assign to street1 -->
<copy>
<from variable="input" part="payload"
query="/tns:invalidLoanApplication/autoloan:application
/autoloan:customer/autoloan:addresses[position()=1]
/autoloan:street"/>
<to variable="street1"/>
</copy>
</assign>

WSDLファイルで入力変数の定義とそのペイロード・パートを確認する際、addressesフィールドの定義に到達するまでに、いくつかのレベルを下っていきます。そこで、maxOccurs="unbounded"属性が見つかります。2つのXPath索引付けメソッドは機能的には同じであり、どちらを使用してもかまいません。

6.21.2 SOAPでエンコードされた配列の使用方法

Oracle SOA Suiteでは、SOAP RPCでエンコードされた配列をサポートしています。このサポートにより、Oracle BPEL Process Managerは、SOAP 1.1配列を使用するSOAP Webサービス(RPCでエンコードされた)をコールするクライアントとして機能できます。

次の例に、myFavoriteNumbersというSOAP配列ペイロードの例を示します。

<myFavoriteNumbers SOAP-ENC:arrayType="xsd:int2">
<number>3</number>
<number>4</number>
</myFavoriteNumbers>

また、スキーマの要素の属性attributeFormDefaultおよびelementFormDefaultが"unqualified"に設定されていることを確認してください。次の例に詳細を示します。

attributeFormDefault="unqualified" elementFormDefault="unqualified"
targetNamespace="java:services" xmlns:s0="http://schemas.xmlsoap.org/wsdl/"
xmlns:xs="http://www.w3.org/2001/XMLSchema">

次の機能はサポートされていません。

- SOAP配列を使用するBPELによって公開されるサービス

- 部分的に送信される配列

- スパース配列

- 多次元配列

SOAPでエンコードされた配列を使用する手順は、次のとおりです。

次の例に、BPELプロジェクトにbpelx:appendタグの付いたSOAP配列を準備する方法を示します。

1. Oracle JDeveloperでBPELプロセスを作成します。

2. 起動用のぺイロードを準備します。bpelx:appendは、項目をSOAP配列に追加するために使用されることに注意してください。

<bpws:assign>
<bpws:copy>
<bpws:from variable="input" part="payload" query="/tns:value"/>
<bpws:to variable="request" part="strArray"
query="/strArray/JavaLangstring"/>
</bpws:copy>
</bpws:assign>
<bpws:assign>
<bpelx:append>
<bpelx:from variable="request" part="strArray"
query="/strArray/JavaLangstring1"/>
<bpelx:to variable="request" part="strArray" query="/strArray"/>
</bpelx:append>
</bpws:assign>

3. 次のネームスペースをWSDLファイルにインポートします。WSDLスキーマ要素にインポート文が欠落している場合、Oracle JDeveloperではSOAP-ENCタグを認識しません。

<xs:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />

6.21.2.1 BPEL 2.0のSOAPでエンコードされた配列

SOAPでエンコードされた配列は、BPEL仕様のバージョン2.0を使用するBPELプロジェクトでサポートされています。次の例に、BPEL 2.0プロジェクトのSOAPでエンコードされた配列を持つassignアクティビティのサンプルを示します。

<assign name="Assign_1">
<copy>
<from>$inputVariable.payload</from>
<to>$Invoke_1_echoArray_InputVariable.strArray/JavaLangstring[1]</to>
</copy>
<extensionAssignOperation>
<bpelx:append>
<bpelx:from variable="Invoke_1_echoArray_InputVariable"
part="strArray">
<bpelx:query>
JavaLangstring[1]
</bpelx:query>
</bpelx:from>
<bpelx:to variable="Invoke_1_echoArray_InputVariable"
part="strArray">
</bpelx:to>
</bpelx:append>
</extensionAssignOperation>
</assign>

次の例に、BPEL 2.0プロジェクトのSOAPでエンコードされた配列を持つinvokeアクティビティのサンプルを示します。

<invoke name="Invoke1" partnerLink="FileOut"
portType="ns3:Write_ptt" operation="Write"
bpelx:invokeAsDetail="no">
<toParts>
<toPart part="body" fromVariable="ArrayVariable"/>
</toParts>
</invoke>

6.21.2.2 スキーマ内でwsdl:arrayType属性を使用したSOAP配列の宣言

SOAPでエンコードされた配列のWSDLでは、スキーマ内でwsdl:arrayType属性を使用してSOAP配列を宣言できます。次の例に詳細を示します。

<xsd:complexType name="UserObject">
<xsd:sequence>
<xsd:element name="userInformation" nillable="true"
type="n5:ArrayOfKeyValuePair"/>
<xsd:element name="username" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ArrayOfKeyValuePair">
<xsd:complexContent>
<xsd:restriction base="soapenc:Array">
<xsd:attribute ref="soapenc:arrayType"
wsdl:arrayType="n5:KeyValuePair[]"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="KeyValuePair">
<xsd:sequence>
<xsd:element name="key" nillable="true" type="xsd:string"/>
<xsd:element name="value" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>

次の例に、BPEL 1.1でSOAPでエンコードされた配列を作成してアクセスする方法を示します。

<bpws:copy>
<bpws:from>
<ns1:userInformation soapenc:arrayType="com1:KeyValuePair[1]"
xmlns:ns1="http://www.schematargetnamespace.com/wsdl/Impl/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"/>
<ns1:KeyValuePair
xmlns:ns1="http://www.schematargetnamespace.com/wsdl/Impl/">
<key>testkey</key>
<value>testval1</value>
</ns1:KeyValuePair>
</ns1:userInformation>
</bpws:from>
<bpws:to variable="Inputvar" part="userObject"
query="/userObject/userInformation"/>

</bpws:copy>
<!--Update elements with SOAPENC Array-->
<bpws:copy>
<bpws:from variable="KeyValueVar" part="KeyValuePair"
query="/KeyValuePair/ns2:key"/>
<bpws:to variable="Inputvar" part="userObject'
query="//*[local-name()='KeyValuePair'][1]/*[local-name()='key']"/>
</bpws:copy>

<bpws:copy>
<bpws:from variable="KeyValueVar" part="KeyValuePair"
query="/KeyValuePair/client:value"/>
<bpws:to variable="Inputvar" part="userObject"
query="//*[local-name()='KeyValuePair'][1]/*[local-name()='value']"/>

</bpws:copy>
<!-- Append elements within SOAPENC Array -->
<bpelx:append>
<bpelx:from variable="Inputvar" part="userObject"
query="//*[local-name()='KeyValuePair'][1]"/>
<bpelx:to variable="Inputvar" part="userObject"
query="/userObject/userInformation"/>
</bpelx:append>

6.21.3 シーケンス・サイズの決定方法

データ・シーケンスの実行時のサイズ、つまりシーケンス内のノードまたはデータ項目の数を知る必要がある場合は、XPath組込み関数count()とBPEL組込み関数getVariableData()を組み合せて使用することで取得できます。

次の例のコードは、itemシーケンス内の要素数を計算し、それを整数変数lineItemSizeに割り当てています。

<assign>
<copy>
<from expression="count(bpws:getVariableData('outpoint', 'payload',
'/p:invoice/p:lineItems/p:item')"/>
<to variable="lineItemSize"/>
</copy>
</assign>

6.21.4 式の末尾へのXPathの適用による動的な索引付け方法

多くの場合、データ・シーケンスへの索引付けに動的な値が必要になることがあります。つまり、シーケンスのn番目のノード(nの値は実行時に定義)の取得が必要な場合です。この項では、式の末尾にXPathを適用して動的な索引付けを行う方法について説明します。

6.21.4.1 getVariableDataの結果の末尾へのXPathの適用

次の例に示す動的索引付けメソッドでは、XPathをbpws:getVariableData()の最後の引数として使用するのではなく、bwps:getVariableData()の結果の末尾にXPathを適用します。末尾のXPathは、位置述語内の整数型の索引変数(つまり、[...])を参照します。

<variable name="idx" type="xsd:integer"/>
...
<assign>
<copy>
<from expression="bpws:getVariableData('input','payload'
)/p:line-item[bpws:getVariableData('idx')]/p:line-total" />
<to variable="lineTotalVar" />
</copy>
</assign>

実行時に、idx整数変数の値として2が格納されるとします。前述の例のfrom内の式は、次の例の式と同等です。

<from expression="bpws:getVariableData('input','payload'
)/p:line-item[2]/p:line-total" />

XPathがbwps:getVariableData()関数の末尾に使用される場合とこの関数内で使用される場合では、XPathの使用方法に多少の違いがあります。同じ例(payloadが要素p:invoiceのメッセージ・パートである例)を使用すると、XPathをgetVariableData()関数内で使用する場合は、ルート要素名(/p:invoice)をXPathの先頭に指定する必要があります。

次の例に詳細を示します。

bpws:getVariableData('input', 'payload','/p:invoice/p:line-item[2]/p:line-total')

XPathをbwps:getVariableData()関数の末尾に使用する場合、ルート要素名をXPath内に指定する必要はありません。

次に例を示します。

bpws:getVariableData('input', 'payload')/p:line-item[2]/p:line-total

これは、getVariableData()関数で返されるノードがルート要素であるためです。ルート要素名をXPathで再指定すると重複になり、XPathの標準セマンティクスでは不正となります。

6.21.4.2 bpelx:append拡張要素によるシーケンスへの新しい項目の追加

assignアクティビティでbpelx:append拡張要素を使用すると、BPELプロセス・サービス・コンポーネントは既存の親要素に新しい要素を追加できます。次に例を示します。

<assign name="assign-3">
<copy>
<from expression="bpws:getVariableData('idx')+1" />
<to variable="idx"/>
</copy>
<bpelx:append>
<bpelx:from variable="partInfoResultVar" part="payload" />
<bpelx:to variable="output" part="payload" />
</bpelx:append>
...
</assign>

この例のbpelx:appendロジックにより、partInfoResultVar変数のペイロード要素が、output変数のペイロード要素に子として追加されます。つまり、output変数のペイロード要素が親要素として使用されます。

6.21.4.3 データ・シーケンスのマージ

2つのシーケンスを単一のデータ・シーケンスにマージできます。このパターンは、データ・シーケンスが配列内にある場合(つまり、互換性のあるタイプのデータ項目のシーケンスの場合)によく使用されます。次に示すassignの下の2つのappend操作は、データ・シーケンスのマージ方法を示しています。

<assign>
<!-- initialize "mergedLineItems" variable
to an empty element -->
<copy>
<from> <p:lineItems /> </from>
<to variable="mergedLineItems" />
</copy>
<bpelx:append>
<bpelx:from variable="input" part="payload"
query="/p:invoice/p:lineItems/p:lineitem" />
<bpelx:to variable="mergedLineItems" />
</bpelx:append>
<bpelx:append>
<bpelx:from variable="literalLineItems"
query="/p:lineItems/p:lineitem" />
<bpelx:to variable="mergedLineItems" />
</bpelx:append>
</assign>

6.21.4.4 空要素の配列と等価の機能の生成

genEmptyElem関数では、空要素の配列と等価の機能がXML構造に生成されます。この関数は、次の引数をとります。

genEmptyElem('ElemQName',int?, 'TypeQName'?, boolean?)

次の点に注意してください。

- 最初の引数では、空要素のQNameを指定します。

- 2番目の引数はオプションで整数型であり、空要素の数を指定します。指定されていない場合、デフォルトのサイズは1です。

- 3番目の引数はオプションで、生成される空の名前のxsi:typeとなるQNameを指定します。このxsi:typeパターンは、SOAPENC:Arrayに相当します。指定されていないか、空の文字列である場合、xsi:type属性は生成されません。

- 4番目のオプションのブール型引数は、要素がXSD-nillableの場合に、生成される空の要素がXSI - nilかどうかを指定します。デフォルト値はfalseです。指定されていないか、falseである場合、xsi:nilは生成されません。

次の例に、poの下で10個の空の<lineItem>要素を使用して発注書(PO)を初期化するappend文を示します。

<bpelx:assign>
<bpelx:append>
<bpelx:from expression="ora:genEmptyElem('p:lineItem',10)" />
<bpelx:to variable="poVar" query="/p:po" />
</bpelx:append>
</bpelx:assign>

前述の例のgenEmptyElem関数は、次の例のように埋込みXQuery式で置き換えることができます。

ora:genEmptyElem('p:lineItem',10)
== for $i in (1 to 10) return <p:lineItem />

この関数により生成される空要素は、通常は無効なXMLデータです。空要素の作成後に、さらにデータの初期化を実行します。前述と同じ例を使用して、次の操作を実行できます。

- 空のlineItem要素に属性要素と子要素を追加します。

- copy操作を実行して空要素を置き換えます。たとえば、flowNアクティビティの下で、この等価配列内の個別エントリにWebサービスの結果からコピーします。

6.21.5 配列識別子の使用に関する必知事項

ネイティブ・フォーマット・ビルダー配列識別子環境での処理には、ノードの親ノードに関する情報が必要です。reportSAXEvents APIが使用されるため、通常、この情報はアウトバウンド・メッセージ・シナリオには使用できません。ネイティブ・スキーマのnxsd:useArrayIdentifiersをtrueに設定することで、アウトバウンド・メッセージ・シナリオにDOM解析を使用できるようになります。大規模なペイロードによりパフォーマンスの低下につながる可能性があるため、この設定には注意が必要です。次の例に詳細を示します。

<?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/demoSchema/csv"
xmlns:tns="http://xmlns.oracle.com/pcbpel/demoSchema/csv"
elementFormDefault="qualified"
attributeFormDefault="unqualified" nxsd:encoding="US-ASCII"
nxsd:stream="chars" nxsd:version="NXSD" nxsd:useArrayIdentifiers="true">
<xsd:element name="Root-Element">
....
</xsd:element>
</xsd:schema>

6.22 文字列からのXML要素への変換

サービスは文字列を返すように定義されることがありますが、文字列の内容は実際にはXMLデータです。問題は、BPELではXMLデータの操作(XPath問合せや式などを使用)はサポートされていますが、変数またはフィールドが文字列型の場合にこの機能が使用できないことです。Javaでは、DOM関数を使用して文字列を構造化されたXMLオブジェクト・タイプに変換します。同じことが、BPEL XPath関数parseEscapedXMLを使用して実行できます。

parseEscapedXMLの詳細は、「parseEscapedXML」を参照してください。

6.22.1 文字列からXML要素への変換方法

parseEscapedXML関数はXMLデータを受け取り、DOMによって解析し、型指定されたBPEL変数に割当て可能な構造化XMLデータを返します。次に例を示します。

<!-- execute the XPath extension function
parseEscapedXML('&lt;item&gt;') and assign to a variable
-->
<assign>
<copy>
<from expression="oratext:parseEscapedXML(
'&lt;item xmlns=&quot;http://samples.otn.com&quot;
sku=&quot;006&quot;&gt;
&lt;description&gt;sun ultra sparc VI server
&lt;/description&gt;
&lt;price&gt;1000
&lt;/price&gt;
&lt;quantity&gt;2
&lt;/quantity&gt;
&lt;lineTotal&gt;2000
&lt;/lineTotal&gt;
&lt;/item&gt;')"/>
<to variable="escapedLineItem"/>
</copy>
</assign>

6.23 ドキュメント形式とRPC形式のWSDLの違いの理解

この章のこれまでの項で示した例は、次の例のように、メッセージがXMLスキーマのelementで定義されているドキュメント形式のWSDLファイルでした。

<message name="LoanFlowRequestMessage">
<part name="payload" element="s1:loanApplication"/>
</message>

これは、次の例に示すように、メッセージがXMLスキーマのtypeで定義される、RPC形式のWSDLファイルとは異なります。

<message name="LoanFlowRequestMessage">
<part name="payload" type="s1:LoanApplicationType"/>
</message>

6.23.1 RPC形式ファイルの使用方法

これは、この章のこれまでの情報とは異なります。これらの2つのWSDLメッセージ形式では、XPath問合せの作成方法に相違があります。RPC形式のメッセージの場合、最上位要素(およびXPath問合せ文字列の最初のノード)はパート名(前述の例ではpayload)です。ドキュメント形式メッセージでは、最上位ノードは要素名(たとえばloanApplication)です。

次の例(WSDLファイルおよびBPELファイル)に、LoanServicesという名前のアプリケーションがRPC形式の場合のXPath問合せ文字列を示します。

<message name="LoanServiceResultMessage">
<part name="payload" type="s1:LoanOfferType"/>
</message>

<complexType name="LoanOfferType">
<sequence>
<element name="providerName" type="string"/>
<element name="selected" type="boolean"/>
<element name="approved" type="boolean"/>
<element name="APR" type="double"/>
</sequence>
</complexType>

<variable name="output"
messageType="tns:LoanServiceResultMessage"/>
...
<assign>
<copy>
<from expression="9.9"/>
<to variable="output" part="payload" query="/payload/APR"/>
</copy>
</assign>

6.24 BPELでのSOAPヘッダーの操作

BPELの通信アクティビティ(invoke、receive、replyおよびonMessage)は、指定のメッセージ変数を介してメッセージを送受信します。これらのデフォルト・アクティビティでは、各方向で1つの変数の操作が許可されます。たとえば、invokeアクティビティにはinputVariableおよびoutputVariable属性があります。この2つの属性にそれぞれ変数を1つ指定できます。関連する特定の操作で使用するペイロード・メッセージが各方向で1つのみの場合は、これで十分です。

ただし、WSDLは1つの操作での複数のメッセージをサポートしています。SOAPの場合、SOAPヘッダーとしてメイン・ペイロード・メッセージとともに複数のメッセージを送信できます。ただし、BPELのデフォルトの通信アクティビティは、追加のヘッダー・メッセージに対応できません。

Oracle BPEL Process Managerでは、デフォルトのBPEL通信アクティビティをbpelx:headerVariable拡張要素で拡張することで、この問題を解決しています。次の例に、拡張要素の構文を示します。

<invoke bpelx:inputHeaderVariable="inHeader1 inHeader2 ..."
bpelx:outputHeaderVariable="outHeader1 outHeader2 ..."
.../>

<receive bpelx:headerVariable="inHeader1 inHeader2 ..." .../>
<onMessage bpelx:headerVariable="inHeader1 inHeader2 ..." .../>
<reply bpelx:headerVariable="inHeader1 inHeader2 ..." .../>

6.24.1 BPELでのSOAPヘッダーの受信方法

この項では、SOAPヘッダーを受信するBPELファイルとWSDLファイルの作成方法を、例をあげて説明します。

BPELでSOAPヘッダーを受信する手順は、次のとおりです。

1. ヘッダー・メッセージとそれをSOAPリクエストにバインドするSOAPバインディングを宣言するWSDLファイルを作成します。次に例を示します。

<!-- custom header -->
<message name="CustomHeaderMessage">
<part name="header1" element="tns:header1"/>
<part name="header2" element="tns:header2"/>
</message>

<binding name="HeaderServiceBinding" type="tns:HeaderService">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="initiate">
<soap:operation style="document" soapAction="initiate"/>
<input>
<soap:header message="tns:CustomHeaderMessage"
part="header1" use="literal"/>
<soap:header message="tns:CustomHeaderMessage"
part="header2" use="literal"/>
<soap:body use="literal"/>
</input>
</operation>
</binding>

2. 次の例に示すように、ヘッダー・メッセージ変数を宣言し、bpelx:headerVariableを使用してヘッダーを受信するBPELソース・ファイルを作成します。

<variables>  <variable name="input"
messageType="tns:HeaderServiceRequestMessage"/>
<variable name="event"
messageType="tns:HeaderServiceEventMessage"/>
<variable name="output"
messageType="tns:HeaderServiceResultMessage"/>
<variable name="customHeader"
messageType="tns:CustomHeaderMessage"/>
</variables>

<sequence>
<!-- receive input from requester -->
<receive name="receiveInput" partnerLink="client"
portType="tns:HeaderService" operation="initiate"
variable="input"
bpelx:headerVariable="customHeader"
createInstance="yes"/>

6.24.2 BPELでのSOAPヘッダーの送信方法

この項では、SOAPヘッダーの送信方法を例をあげて説明します。

BPELでSOAPヘッダーを送信する手順は、次のとおりです。

1. composite.xmlファイルで参照を定義して、HeaderServiceを参照します。

2. 次の例に示すように、カスタム・ヘッダー変数を定義して操作し、bpelx:inputHeaderVariableを使用して送信します。

<variables>
<variable name="input" messageType="tns:HeaderTestRequestMessage"/>
<variable name="output" messageType="tns:HeaderTestResultMessage"/>
<variable name="request" messageType="services:HeaderServiceRequestMessage"/>
<variable name="response" messageType="services:HeaderServiceResultMessage"/>
<variable name="customHeader"messageType="services:CustomHeaderMessage"/>
</variables>
...
<!-- initiate the remote process -->
<invoke name="invokeAsyncService"
partnerLink="HeaderService"
portType="services:HeaderService"
bpelx:inputHeaderVariable="customHeader"
operation="initiate"
inputVariable="request"/>

6.25 BPEL 2.0での拡張ネームスペースの宣言

BPELバージョン2.0のプロセスを拡張して、カスタム拡張ネームスペース宣言を追加できます。mustUnderstand属性を使用すると、カスタム・ネームスペースがBPELプロセスで認識される必要があるセマンティックを持つかどうかを示すことができます。

mustUnderstandがyesに設定された1つ以上の拡張機能がBPELプロセスでサポートされていない場合、プロセス定義は拒否されます。

拡張機能はextensions要素に定義されます。次の例に詳細を示します。

<process ...>
...
<extensions>?
<extension namespace="myURI" mustUnderstand="yes|no" />+
</extensions>
...
</process>

extension要素のコンテンツは、標準のBPELネームスペースとは異なるネームスペースで修飾された1つの要素である必要があります。

拡張宣言の詳細は、次のURLにあるを参照してください。

http://www.oasis-open.org

6.25.1 拡張ネームスペースの宣言方法

拡張ネームスペースを宣言する手順は、次のとおりです。

1. BPEL 2.0プロセスで、Oracle BPELデザイナの上にある「拡張機能」アイコンをクリックします。

「拡張機能」ダイアログが表示されます。

2. 「拡張機能」フォルダを選択し、「追加」アイコンをクリックします。

「拡張機能」ダイアログが表示されます。

3. 「ネームスペース」フィールドに、宣言する拡張ネームスペースを入力します。このネームスペースは、標準のBPELネームスペースとは異なるものにする必要があります。

4. 拡張機能がBPELプロセスで認識されるようにするには、「認識する必要がある」チェック・ボックスを選択します。

5. 「OK」をクリックします。

6. 「閉じる」をクリックします。

6.25.2 拡張機能作成時の処理内容

設計の完了後、.bpelプロセスは次の例のようになります。

<extensions>
<extension namespace="http://xmlns.mycompany.com/myNamespace"
mustUnderstand="yes"/>
</extensions>

7 BPELプロセスからの同期Webサービスの起動

この章では、BPELプロセスから同期Webサービスを起動する方法について説明します。ここでは、同期起動の実行に必要なコンポーネントの設定方法、およびこれらのコンポーネントのコード方法についても示します。また、タイムアウト値を指定し、同期BPELプロセスを使用して、一方向のOracle Mediatorをコールする方法についても説明します。

この章の内容は次のとおりです。

- 同期Webサービスの起動に関する概要

- 同期Webサービスの起動

- 永続同期プロセスのトランザクションのタイムアウト値の指定

- 同期BPELプロセスを使用した一方向メディエータのコール

7.1 同期Webサービスの起動に関する概要

同期Webサービスは、起動に対してレスポンスを即時に返します。BPELは、パートナ・リンクを介して同期Webサービスに接続し、データを送信し、同一の同期起動でリプライを受信できます。

同期起動には、次のコンポーネントが必要です。

- パートナ・リンク
タスクを実行するためにBPELプロセス・サービス・コンポーネントが接続するWebサービスの場所とロールを定義し、WebサービスとBPELプロセス・サービス・コンポーネントの間で情報を受け渡すための変数を定義します。パートナ・リンクは、BPELプロセス・サービス・コンポーネントがコールする各Webサービスに対して必要です。パートナ・リンクは次のいずれかの方法で作成できます。

- SOAコンポジット・エディタで、「SOAP」サービスを「コンポーネント」ウィンドウの「テクノロジ」セクションから「公開されたサービス」または「外部参照」のスイムレーンにドラッグした場合。詳細は、「サービス・バインディング・コンポーネントの追加」または「参照バインディング・コンポーネントの追加」を参照してください。

- Oracle BPELデザイナで、「パートナ・リンク」アイコンを「コンポーネント」ウィンドウの「BPELコンストラクト」セクションから「パートナ・リンク」スイムレーンにドラッグした場合。この章では、この2番目の方法について説明します。

- invokeアクティビティ
データを送受信するためのポートを、BPELプロセス・サービス・コンポーネント内でオープンします。たとえば、このポートは、クレジット・カード認可サービスを使用して顧客の与信が受諾可能であることを検証する情報の取得に使用します。同期コールバックの場合、関数の送受信に必要なポートは1つのみです。

7.2 同期Webサービスの起動

名前がOrderProcessor.bpelであるファイルを使用する同期起動操作についてこの項で説明します。

7.2.1 同期Webサービスの起動方法

同期Webサービスを起動する手順は、次のとおりです。

1. Oracle BPELデザイナの「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. 必要なパートナ・リンク、invokeアクティビティ、scopeアクティビティおよびassignアクティビティをデザイナにドラッグします。

3. それぞれのダイアログを編集します。

BPELプロセス(名前はOrderProcessorで、シンプルなアクション・セットを定義しています)のscopeアクティビティ(名前はScope_AuthorizeCreditCard)のダイアグラムを図7-1 に示します。

図7-1 OrderProcessor.bpelのダイアグラム

7.2.1.1 BPELプロセスの動作方法

次のアクションが実行されます。

1. 「Assign_CreditCardCheckInput」 assignアクティビティによって、クライアントからのデータがパッケージ化されます。assignアクティビティを使用すると、ある変数の内容を別の変数にコピーできます。ここでは、クレジット・カード・タイプ、クレジット・カード番号および購入金額を取得し、それらを「CreditCardAuthorizationService」サービスの入力変数に代入します。

2. 「InvokeCheckCreditCard」 invokeアクティビティによって「CreditCardAuthorizationService」サービスがコールされます。図7-2 は、「CreditCardAuthorizationService」Webサービスを示しています。このWebサービスはパートナ・リンクとして定義されています。

図7-2 「CreditCardAuthorizationService」パートナ・リンク

図7-3 は、「InvokeCheckCreditCard」invokeアクティビティを示しています。

図7-3 「InvokeCheckCreditCard」invokeアクティビティ

3. ifアクティビティ(BPEL 2.0)またはswitchアクティビティ(BPEL 1.1)は、クレジット・カード検証の結果を確認します。ifアクティビティおよびswitchアクティビティの詳細は、「ifまたはswitchアクティビティによる条件分岐の定義」を参照してください。

注意:

BPEL 2.0のifアクティビティは、BPEL 1.1のswitchアクティビティにかわるものです。

7.2.2 同期Webサービス起動時の処理内容

パートナ・リンクとinvokeアクティビティを作成すると、同期Webサービスの起動に必要なBPELコードが、適切なBPELおよびWeb Services Description Language (WSDL)ファイルに追加されます。

7.2.2.1 BPELコード内のパートナ・リンク

OrderProcessor.bpelコードでは、パートナ・リンクによって、リンク名とタイプ、およびパートナ・サービスとの相互作用におけるBPELプロセス・サービス・コンポーネントのロールが定義されます。

次に、BPELソース・コードでのCreditCardAuthorizationServiceパートナ・リンク定義を示します。

<partnerLink name="CreditCardAuthorizationService"
partnerRole="CreditAuthorizationPort"
partnerLinkType="ns2:CreditCardAuthorizationService"/>

次の例は、Scope_AuthorizeCreditCardスコープでローカルにアクセスできる変数定義を示しています。これらの変数のタイプは、このプロセス自体のWSDLに定義されています。

<variable name="lCreditCardInput"
messageType="ns2:CreditAuthorizationRequestMessage"/>
<variable name="lCreditCardOutput"
messageType="ns2:CreditAuthorizationResponseMessage"/>

WSDLファイルによって、次のようなBPELプロセス・サービス・コンポーネントのインタフェースが定義されます。

- それが受け付けるメッセージと返すメッセージ

- サポートされている操作

- その他のパラメータ

7.2.2.2 BPELコード内のパートナ・リンク・タイプとポート・タイプ

WebサービスのCreditCardAuthorizationService.wsdlファイルには、2つのセクションがあります。これらのセクションを使用して、WebサービスとBPELプロセス・サービス・コンポーネントの連携を可能にします。

- partnerLinkType:
BPELプロセス・サービス・コンポーネントとクレジット・カード認可Webサービス間の変換について、次の特性を定義します。

- それぞれが果たすロール(操作)

- 対話でメッセージを受信するためにそれぞれが提供するportType

- portType:
対話内で参加者によって実装される一連の関連操作です。ポート・タイプは、受渡しする情報や、その情報の形式などを定義します。同期起動には、同期プロセスの起動およびレスポンスでのクライアントのコールバックを実行する1つのポート・タイプのみが必要です。非同期コールバック(リプライが即時に行われないもの)には、次の2つのポート・タイプが必要です。

- 1つは、リクエストを送信するため。

- もう1つは、リプライが着信したときに、それを受信するため。

この例では、portType CreditAuthorizationPortが、クレジット・カード・タイプ、クレジット・カード番号および購入金額を受信し、信用調査結果を返します。

次に、partnerLinkTypeおよびportTypeの例を示します。

<plnk:partnerLinkType name="CreditCardAuthorizationService">
<plnk:role name="CreditAuthorizationPort">
<plnk:portType name="tns:CreditAuthorizationPort"/>
</plnk:role>
</plnk:partnerLinkType>

7.2.2.3 リクエストを実行するためのinvokeアクティビティ

invokeアクティビティには、lCreditCardInputローカル入力変数が含まれています。クレジット・カード認可WebサービスがlCreditCardInputローカル入力変数を使用します。この変数には、顧客のクレジット・カード・タイプ、クレジット・カード番号および購入金額が格納されます。lCreditCardOutput変数は、CreditCardAuthorizationServiceサービスからの信用調査結果を返します。次の例に詳細を示します。

<invoke name="InvokeCheckCreditCard"
inputVariable="lCreditCardInput"
outputVariable="lCreditCardOutput"
partnerLink="CreditCardAuthorizationService"
portType="ns2:CreditAuthorizationPort"
operation="AuthorizeCredit"/>

7.2.2.4 BPELコードでの同期起動

次の例に示すBPELコードは、同期起動を実行します。

<assign name="Assign_CreditCheckInput">
<copy>
<from variable="gOrderInfoVariable"
query="/ns4:orderInfoVOSDO/ns4:OrderTotal"/>
<to variable="lCreditCardInput" part="Authorization"
query="/ns8:AuthInformation/ns8:PurchaseAmount"/>
</copy>
<copy>
<from variable="gOrderInfoVariable"
query="/ns4:orderInfoVOSDO/ns4:CardTypeCode"/>
<to variable="lCreditCardInput" part="Authorization"
query="/ns8:AuthInformation/ns8:CCType"/>
</copy>
<copy>
<from variable="gOrderInfoVariable"
query="/ns4:orderInfoVOSDO/ns4:AccountNumber"/>
<to variable="lCreditCardInput" part="Authorization"
query="/ns8:AuthInformation/ns8:CCNumber"/>
</copy>
</assign>
<invoke name="InvokeCheckCreditCard"
inputVariable="lCreditCardInput"
outputVariable="lCreditCardOutput"
partnerLink="CreditCardAuthorizationService"
portType="ns2:CreditAuthorizationPort"
operation="AuthorizeCredit"/>

7.3 永続同期プロセスのトランザクションのタイムアウト値の指定

Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで、SyncMaxWaitTimeプロパティを使用して、トランザクションのタイムアウト値を指定できます。SyncMaxWaitTimeプロパティは、非同期方式でコールされる永続同期プロセスに適用されます。BPELプロセス・サービス・コンポーネントが指定時間内にリプライを受信しないと、アクティビティはエラーとなります。詳細は、「SyncMaxWaitTimeとタイムアウトのない永続同期リクエストに関する必知事項」を参照してください。

7.3.1 トランザクションのタイムアウト値の指定方法

トランザクションのタイムアウト値を指定する手順は、次のとおりです。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 「SOAインフラストラクチャ」メニューから、「SOA管理」→「BPELプロパティ」の順に選択します。

3. 「BPELサービス・エンジン・プロパティ」ページの下部で、「詳細BPEL構成プロパティ」をクリックします。

4. 「SyncMaxWaitTime」をクリックします。

5. 「値」フィールドに値を秒単位で指定します。

6. 「適用」をクリックします。

7. 「戻る」をクリックします。

7.3.2 SyncMaxWaitTimeとタイムアウトのない永続同期リクエストに関する必知事項

SyncMaxWaitTimeプロパティは、非同期方式でコールされる永続同期プロセスに適用されます。

次の例に示す定義がBPELプロセスに存在していると仮定します。このプロセスは、breakpointアクティビティがないため、永続プロセスではありません。

<receive name="receiveInput" partnerLink="client" variable="input"
createInstance="yes" />
<assign>
...
</assign>
<reply name="replyOutput" partnerLink="client" variable="output" />

Javaクライアントまたは別のBPELプロセスがこのプロセスをコールすると、assignアクティビティが実行され、replyアクティビティによって出力メッセージがHashMapに設定され、クライアント(実際には配信サービス)が取得できるようになります。replyは最後のアクティビティであるため、スレッドがクライアント側に戻り、リプライ・メッセージの取得が試みられます。リプライ・メッセージはすでに挿入されているため、クライアントは待機せずにリプライで戻ります。

次の例に示すように、BPELプロセスにbreakpointアクティビティがあると仮定します。

<receive name="receiveInput" partnerLink="client" variable="input"
createInstance="yes" />
<assign>
...
</assign>
<wait name="Wait1">
<for>'PT10S'</for>
</wait>
<reply name="replyOutput" partnerLink="client" variable="output" />

同期プロセス内部に非同期のアクティビティが存在することは適切ではありませんが、BPELではこの種の設計が禁止されていません。

クライアント(または別のBPELプロセス)がプロセスをコールすると、wait (breakpoint)アクティビティが実行されます。ただし、waitはいくらかの時間が経過した後に非同期スレッドによってバックグラウンドで処理されるため、スレッドの実行はクライアント側に戻ります。クライアント(実際には配信サービス)はリプライ・メッセージの取得を試みますが、プロセス内のリプライ・アクティビティはその時点では実行されていないため、メッセージは存在しません。したがって、クライアント・スレッドはSyncMaxWaitTime値(秒数)に指定されている時間が経過するまで待機します。この時間を超えると、クライアント・スレッドはコール元にタイムアウト例外を返します。待機時間がSyncMaxWaitTime値未満の場合は、非同期のバックグラウンド・スレッドが待機状態から再開し、リプライを実行します。リプライはHashMapに配置され、待機側(クライアント・スレッド)に通知されます。クライアント・スレッドは、リプライ・メッセージを取得して戻ります。

したがって、プロセスの中ほどにブレークポイントがある場合は、同期プロセスの起動にのみSyncMaxWaitTimeが適用されます。ブレークポイントがない場合は、プロセス全体がクライアント・スレッドで実行され、リプライ・メッセージを返します。

7.4 同期BPELプロセスを使用した一方向メディエータのコール

非同期コールバックを使用してバック・エンドで同期リプライをシミュレートしながら、フロント・エンドで同期インタフェースを公開できます。これは、composite.xmlファイルのbpel.config.transactionプロパティがrequiresNewに自動設定されている場合のBPELプロセスのデフォルト動作です。次の例に詳細を示します。

<component name="BPELProcess1">
<implementation.bpel src="BPELProcess1.bpel"/>
<property name="bpel.config.transaction" type="xs:string"
many="false">requiresNew</property>
</component>

requiresNew値をお薦めします。クライアントのトランザクションに参加する場合は、bpel.config.transactionプロパティをrequiredに設定する必要があります。

8 BPELプロセスからの非同期Webサービスの起動

この章では、BPELプロセスからの非同期Webサービスの構成および起動方法について説明します。また、複数のreceiveまたはpickアクティビティで同じパートナ・リンクが使用されている場合に適切なエンドポイントにコールバック・メッセージをルーティングする方法、パートナ・リンク操作レベルで冪等性を管理する方法、実行時に動的パートナ・リンクを作成する方法、動的パートナ・リンク環境でセキュリティ証明書およびWSDLファイルをオーバーライドする方法、およびWS-Addressingを使用する方法について説明します。

この章の内容は次のとおりです。

- 非同期Webサービスの起動に関する概要

- 非同期Webサービスの起動

- 複数のreceiveまたはpickアクティビティで同じパートナ・リンクが使用されている場合における適切なエンドポイントへのコールバック・メッセージのルーティング

- パートナ・リンク操作レベルでの冪等性の管理

- 実行時に使用するための動的パートナ・リンクの設計時の作成

- 動的パートナ・リンクを起動する際のセキュリティ証明書のオーバーライド

- 動的パートナ・リンクのWSDLファイルのオーバーライド

- 非同期サービスでのWS-Addressingの使用

8.1 非同期Webサービスの起動に関する概要

非同期メッセージ形式は、サービス(融資処理など)でクライアント・リクエストの処理に時間がかかる環境で役に立ちます。また、非同期サービスは、同期サービスよりも優れた耐障害性を持ち、かつスケーラブルなアーキテクチャも提供します。

この項では、United Loanという企業での非同期Webサービスの起動について説明します。United Loanは、クライアントの融資申請リクエストを処理して融資提案を返す非同期Webサービスを公開します。このユースケースでは、BPELプロセス・サービス・コンポーネントとこの非同期融資申請承認Webサービスを統合する方法について説明します。

このユースケースでは、非同期サービスからの情報をリクエストし、レスポンスを受け取るための基本的な設計概念について説明します。この例のUnited Loanの非同期サービスは、別のBPELプロセス・サービス・コンポーネントです。しかし、適切に設計されたWebサービスであれば、同じBPELコールで対話できます。ターゲットのWebサービスのWSDLファイルには、必要な情報のリクエストと受信に必要な情報が含まれています。

非同期Webサービスでは、次のアクションが(優先度に従って)実行されます。

1. assignアクティビティにより融資申請が準備されます。

2. invokeアクティビティにより融資申請が開始されます。申請の内容は、リクエスト変数に入力されます。このリクエスト変数が非同期融資処理Webサービスに送信されます。
融資申請の開始時、申請を開始したクライアントとパートナ・リンクに固有の相関IDも、融資処理Webサービスに送信されます。相関IDにより、適切な融資提案レスポンスが、対応する融資申請のリクエスト元に確実に返されます。

3. その後、融資処理Webサービスにより、適切なレスポンスがreceiveアクティビティ(相関IDを使用して追跡)に送信されます。

4. assignアクティビティにより融資申請提案が読み取られます。

この章の後続の各項では、非同期機能の詳細を説明します。

8.2 非同期Webサービスの起動

この項では、非同期機能をBPELプロセス・サービス・コンポーネントに追加するためのタスクの概要を説明します。

8.2.1 非同期Webサービスの起動方法

次の手順を実行し、Webサービスを非同期で起動します。

- パートナ・リンクの追加

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

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

- assignアクティビティの作成

8.2.1.1 非同期サービスに対するパートナ・リンクの追加

ここでは、融資申請承認Webサービスに対するパートナ・リンク(この例ではLoanServiceという名前)をBPELプロセスに作成する方法について説明します。

非同期サービスに対してパートナ・リンクを追加する手順は、次のとおりです。

1. SOAコンポジット・エディタで、BPELプロセスを「コンポーネント」ウィンドウの「コンポーネント」セクションからデザイナにドラッグします。

「BPELプロセスの作成」ダイアログが表示されます。

2. ダイアログの説明に従って、非同期BPELプロセス・サービス・コンポーネントを作成します。

3. 完了後に「OK」をクリックします。

4. SOAコンポジット・エディタのSOAコンポジット・アプリケーションで、BPELプロセス・サービス・コンポーネント(この例では、LoanBrokerというコンポーネント名)をダブルクリックします。

Oracle BPELデザイナが表示されます。

5. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

6. 「パートナ・リンク」アイコンを適切な「パートナ・リンク」スイムレーンにドラッグします。

「パートナ・リンクの作成」ダイアログが表示されます。

7. 次の詳細を入力して、パートナ・リンクを作成し、融資申請承認Webサービスを選択します。

- 名前
パートナ・リンクの名前を入力します(この例ではLoanServiceを入力します)。

- プロセス
BPELプロセス・サービス・コンポーネント名が表示されます(この例ではLoanBrokerが表示されます)。

- WSDL URL
使用するWeb Services Description Language (WSDL)ファイルを入力します。このフィールドの上にある「SOAリソース・ブラウザ」アイコンをクリックして、正しいWSDLを検索します。

- パートナ・リンク・タイプ
BPELプロセス・サービス・コンポーネントのインタフェース先である外部サービスを指します。リストから選択します(この例ではLoanServiceを選択します)。

- パートナ・ロール
外部ソースのロールです(プロバイダなど)。リストから選択します(この例ではLoanServiceProviderを選択します)。

- マイ・ロール
この相互作用におけるBPELプロセス・サービス・コンポーネントのロールです。リストから選択します(この例ではLoanServiceRequesterを選択します)。

8. 「OK」をクリックします。

融資申請承認Webサービス(United Loan)の新しいパートナ・リンクがデザイナのスイムレーンに表示されます。

8.2.1.2 invokeアクティビティの追加

次の手順に従って、invokeアクティビティとrequestという名前のグローバル入力変数を作成します。このアクティビティは、融資申請承認Webサービス(United Loan)を使用して、非同期BPELプロセス・サービス・コンポーネント・アクティビティを開始します。融資申請承認Webサービスは、request入力変数を使用してクライアントからの融資申請を受け取ります。

invokeアクティビティを追加する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. invokeアクティビティをreceiveアクティビティの下にドラッグします。

3. 「構造」ウィンドウに移動します。この例では、「構造」ウィンドウから変数を作成する手順を説明しますが、「Invoke」ダイアログの「入力」フィールドと「出力」フィールドの右側にある「追加」アイコンをクリックして変数を作成することもできます。

4. 「変数」を右クリックし、「すべての子ノードを開く」を選択します。

5. ツリーの2つ目の「変数」フォルダで右クリックし、「変数の作成」を選択します。

「変数の作成」ダイアログが表示されます。

6. 変数名を入力し、表示されたオプションから「メッセージ・タイプ」を選択します。

- タイプ
このオプションでは、XMLスキーマの単純型(文字型やブール型など)を選択できます。

- メッセージ・タイプ
このオプションでは、パートナ・リンクまたは現在のBPELプロセス・サービス・コンポーネントのプロジェクトWSDLファイルに対するWSDLメッセージ・ファイル定義を選択できます(レスポンス・メッセージやリクエスト・メッセージなど)。メッセージ・タイプと関連付けられている変数をinvoke、receiveまたはreplyアクティビティの入力変数または出力変数として指定できます。

メッセージ・タイプを表示するには、「メッセージ・タイプ」オプションを選択し、「参照」アイコンを選択して「タイプ・チューザ」ダイアログを表示します。ここから、選択するために「メッセージ・タイプ」ツリーを展開します。この例では、「LoanServiceRequestMessage」が選択されます。

- 要素
このオプションでは、現在のBPELプロセス・サービス・コンポーネントのプロジェクト・スキーマ・ファイルまたはプロジェクトWSDLファイルのXMLスキーマ要素、またはパートナ・リンクのXMLスキーマ要素を選択できます。

7. 「OK」をクリックします。

8. invokeアクティビティをクリックして、そのプロパティ・フィールドをプロパティ・インスペクタで表示するか、invokeアクティビティをダブルクリックし、「Invoke」ダイアログを表示します。

アクティビティをプロパティ・インスペクタで編集する方法の詳細は、「BPELアクティビティをプロパティ・インスペクタで編集する方法」を参照してください。

9. 「Invoke」ダイアログで、「パートナ・リンク」リストからパートナ・リンク(この例では「LoanService」)を選択し、「操作」リストから「initiate」を選択します。

10. 「入力」フィールドの右で、2番目のアイコンをクリックし、ステップ6で作成した入力変数を選択します。

「変数チューザ」ダイアログが表示され、変数の選択が可能になります。

出力変数はreceive操作で返されるため、指定していません。invokeアクティビティが作成されます。

invokeアクティビティの詳細は、「invokeアクティビティとreceiveアクティビティ」を参照してください。

11. 「OK」をクリックします。

8.2.1.3 receiveアクティビティの追加

次の手順に従って、receiveアクティビティとresponseという名前のグローバル出力変数を作成します。このアクティビティは、融資申請承認Webサービスのコールバック処理を待機します。融資申請承認Webサービスは、この出力変数を使用して、融資提案結果をクライアントに送信します。

receiveアクティビティを追加する手順は、次のとおりです。

1. 「invokeアクティビティの追加」で作成したinvokeアクティビティの直後に、「コンポーネント」ウィンドウから、receiveアクティビティをドラッグします。

2. 「invokeアクティビティの追加」のステップ3からステップ7と同様の手順で、「変数の作成」ダイアログを開き、受信情報を格納する変数を作成します。

注意:

BPEL仕様のバージョン2.0をサポートするBPELプロジェクトでは、「変数の作成」ダイアログに、変数タイプのインラインを(変数、式、リテラル、パートナ・リンク、プロパティなどとして)初期化できる「初期化」タブがあります。BPELプロセスを作成する際のデフォルト・バージョンはBPEL 2.0です。詳細は、「BPEL 2.0のインラインfrom-specを使用した変数を初期化する方法」を参照してください。

3. receiveアクティビティをダブルクリックし、名前をreceive_invokeに変更します。

4. 「パートナ・リンク」リストからパートナ・リンクを選択します(この例では「LoanService」を選択します)。

5. 「操作」リストから「onResult」を選択します。「インスタンスの作成」チェック・ボックスを選択しないでください。

6. 「invokeアクティビティの追加」のステップ3からステップ7で作成した変数を選択します。

7. 「OK」をクリックします。

receiveアクティビティと出力変数が作成されます。BPELファイル(この例ではLoanBroker.bpel)の最初のreceiveアクティビティが最初のBPELプロセス・サービス・コンポーネント・インスタンスを作成したため、2つ目のインスタンスを作成する必要はありません。

8.2.1.4 その他のアクティビティの実行

非同期固有のタスクに加え、次のタスクを実行する必要があります。

- クライアントの融資申込書のinput変数ペイロードを融資申請承認Webサービスのrequest変数ペイロードにコピーする、データ操作用の最初のassignアクティビティを、invokeアクティビティの前に作成します。

- 受け取るクライアントのoutput変数に融資申請承認Webサービスの融資申請結果のresponse変数ペイロードをコピーする、データ操作用の2番目のassignアクティビティを、receiveアクティビティの後ろに作成します。

8.2.2 非同期Webサービス起動時の処理内容

この項では、非同期Webサービス起動時の処理内容について説明します。

8.2.2.1 WSDLファイルのportTypeセクション

WSDLファイル(この例ではLoanService)のportTypeセクションは、非同期サービスに使用するポートを定義します。

非同期サービスにはポート・タイプが2つ定義されます。各ポート・タイプは一方向操作を実行します。この例では、次のようになります。

- 一方のポート・タイプが非同期プロセスに応答します。

- 他方のものが、非同期レスポンスでクライアントにコールバックします。

次の例では、portType LoanServiceCallbackがクライアントの融資申請リクエストを受け取り、portType LoanServiceが融資提案レスポンスを使用してクライアントを非同期でコールバックします。

<!-- portType implemented by the LoanService BPEL process -->
<portType name="LoanService">
<operation name="initiate">
<input message="tns:LoanServiceRequestMessage"/>
</operation>
</portType>
<!-- portType implemented by the requester of LoanService BPEL process
for asynchronous callback purposes
-->
<portType name="LoanServiceCallback">
<operation name="onResult">
<input message="tns:LoanServiceResultMessage"/>
</operation>
</portType>

8.2.2.2 WSDLファイルのpartnerLinkTypeセクション

WSDLファイル(この例ではLoanService)のpartnerLinkTypeセクションは、BPELプロセス・サービス・コンポーネントの次の特性を定義します。

- 果たすロール(操作)

- 対話でメッセージを受信するために提供するportType

非同期サービスのパートナ・リンク・タイプには、Webサービス・プロバイダに対するロールとクライアント・リクエスタに対するロールの2つのロールがあります。

次の例では、LoanServiceProviderロールおよびLoanService portTypeは、クライアント・リクエスト・メッセージに使用され、LoanServiceRequesterロールおよびLoanServiceCallback portTypeは、レスポンス・メッセージをクライアントに非同期で返す(コールバックする)ために使用されます。

<plnk:partnerLinkType name="LoanService">
<plnk:role name="LoanServiceProvider">
<plnk:portType name="client:LoanService"/>
</plnk:role>
<plnk:role name="LoanServiceRequester">
<plnk:portType name="client:LoanServiceCallback"/>
</plnk:role>
</plnk:partnerLinkType>

2つのポート・タイプ(invokeアクティビティのportType="services:LoanService"とreceiveアクティビティのportType="services:LoanServiceCallback")は、この1つの非同期BPELプロセス・サービス・コンポーネントに結合されます。基本的に、ポート・タイプは実行される一連の操作です。このBPELプロセス・サービス・コンポーネントの場合、実行する操作は2つ(invokeアクティビティのinitiateとreceiveアクティビティのonResult)あります。

8.2.2.3 BPELファイルのパートナ・リンク・セクション

サービスをBPELからコールするには、プロセスとWebサービスの連携方法をBPELファイルで定義する必要があります。partnerLinksセクションを表示します。プロセスが相互作用するサービスはパートナ・リンクとして設計されます。各パートナ・リンクは、partnerLinkTypeによって定義されます。

各パートナ・リンクには名前が付けられています。この名前は、そのパートナ・リンクによるすべてのサービス相互作用に使用されます。これは、レスポンスを、同じタイプの同時リクエストに対する異なるパートナ・リンクに相関する場合に重要です。

非同期プロセスは、クライアントへのコールバックに2番目のパートナ・リンクを使用します。この例では、2番目のパートナ・リンクLoanServiceが融資申請承認Webサービスによって使用されます。次に例を示します。

<!-- This process invokes the asynchronous LoanService. -->

<partnerLink name="LoanService"
partnerLinkType="services:LoanService"
myRole="LoanServiceRequester"
partnerRole="LoanServiceProvider"/>
</partnerLinks>

属性myRoleは、クライアントのロールを示します。属性partnerRoleは、この対話におけるパートナのロールを示します。非同期プロセスでは、各partnerLinkTypeにmyRole属性とpartnerRole属性があります。

8.2.2.4 コンポジット・アプリケーション・ファイル

composite.xmlファイルには、次に示すように、融資申請承認Webサービスが表示されます。

<component name="LoanBroker">
<implementation.bpel process="LoanBroker.bpel"/>
</component>

パートナ・リンクの作成手順の詳細は、「非同期サービスに対するパートナ・リンクの追加」を参照してください。

8.2.2.5 invokeアクティビティとreceiveアクティビティ

variablesおよびsequenceセクションを表示します。ここでは特に、invokeアクティビティとreceiveアクティビティの2つの領域に注目します。

- invokeアクティビティは、同期Webサービスを起動(「BPELプロセスからの同期Webサービスの起動」を参照)するか、または非同期サービスを開始します。
invokeアクティビティにはvariableセクションで定義されたrequestグローバル入力変数が含まれます。requestグローバル入力変数は融資申請承認Webサービスで使用されます。この変数には、最初の融資申込書の内容が格納されます。

- 融資申請承認Webサービスからの非同期コールバックを待機するreceiveアクティビティ。receiveアクティビティにはvariablesセクションで定義されたresponseグローバル出力変数が含まれます。この変数には、融資提案レスポンスが格納されます。receiveアクティビティは、サービスからのコールバック・メッセージを非同期に待機します。BPELプロセス・サービス・コンポーネントは、コールバック・メッセージの到着を待機中、デハイドレーション(圧縮して格納)されます。

次に例を示します。

<variables>
<variable name="request"
messageType="services:LoanServiceRequestMessage"/>
<variable name="response"
messageType="services:LoanServiceResultMessage"/>
</variables>
<sequence>
<!-- initialize the input of LoanService -->
<assign>
. . .
. . .
</assign>
<!--  initiate the remote process -->
<invoke name="invoke" partnerLink="LoanService"
portType="services:LoanService"
operation="initiate" inputVariable="request"/>
<!--  receive the result of the remote process -->
<receive name="receive_invoke" partnerLink="LoanService"
portType="services:LoanServiceCallback"
operation="onResult" variable="response"/>

invokeアクティビティによって非同期サービスが開始されると、Web Services Addressing (WS-Addressing)(「非同期サービスでのWS-Addressingの使用」で説明)を使用して、クライアント・リクエストに固有の相関IDが送信されます。複数のプロセスがサービス・コールバックを待機している可能性があるため、サーバーでは、どのBPELプロセス・サービス・コンポーネント・インスタンスが融資申請承認Webサービスからのコールバック・メッセージを待機しているかを把握する必要があります。相関IDによって、サーバーは、レスポンスを適切なリクエスト・インスタンスと関係付けることができます。

8.2.2.6 新しいインスタンスを開始するためのcreateInstance属性

最初のreceiveアクティビティには、createInstance属性があります。この最初のreceiveアクティビティでは、createInstance要素はyesに設定されています。これにより、新しいBPELプロセス・サービス・コンポーネント・インスタンスが起動されます。対話のためには、少なくとも1つのインスタンスが起動している必要があります。このため、2番目のreceiveアクティビティではcreateInstance変数をnoに設定します。

次の例に、createInstance属性のソース・コードを示します。

<!-- receive input from requester -->
<receive name="receiveInput" partnerLink="client"
portType="tns:LoanBroker"
operation="initiate" variable="input"
createInstance="yes"/>

8.2.2.7 長期間にわたる非同期プロセスを保持するためのデハイドレーション・ポイント

非同期コールバックの待機中、長期間にわたる非同期プロセスとその現在の状態の情報をデータベース内に自動的に保存するには、データベースをデハイドレーション・ストアとして使用します。データベースにプロセスを格納することにより、プロセスを維持し、システムの停止やネットワークの問題が発生した場合の状態や信頼性の低下を防ぎます。この機能により、BPELプロセス・サービス・コンポーネントの信頼性とスケーラビリティの両方が向上します。また、クラスタリングおよびフェイルオーバーのサポートにもこの機能を使用できます。

invokeアクティビティとreceiveアクティビティの間にこのポイントを挿入します。dehydrateアクティビティを使用してデハイドレーション・ポイントを明示的に指定することもできます。詳細は、「dehydrateアクティビティ」を参照してください。

8.2.2.8 複数のランタイム・エンドポイント・ロケーション

Oracle SOA Suiteでは、パートナ・リンクの複数のエンドポイント・ロケーションの指定がサポートされています。この機能は、最初のエンドポイントが停止した場合に、フェイルオーバーするのに便利です。パートナ・リンクの代替エンドポイント・ロケーションを提供するには、composite.xmlファイルにlocation属性を追加します。次に例を示します。

<reference name="HeaderService ...>
<binding.ws port="http://services.otn.com/HelloWorldApp#wsdl.endpoint(client/
HelloWorldService_pt)"
location="http://server:port/soa-infra/services/default/
HelloWorldService!1.0/client?WSDL">
<property name="endpointURI">http://jsmith.us.example.com:80/a.jsp
@http://myhost.us.example.com:8888/soa-infra/services/HelloWorldApp/HelloWorld!
1.0*2007-10-22_14-33-04_195/client
</property>
</binding.ws>
</reference>

8.2.3 タイムアウト後にメッセージをコンシュームする中間プロセスのreceiveアクティビティに関する必知事項

タイムアウトによって発生した例外が処理されない場合は、receiveアクティビティで構成されたタイムアウトが期限切れになった後も、BPELプロセスによって中間プロセスのreceiveアクティビティのメッセージがコンシュームされます。このようなシナリオでは、コールバック・メッセージは配信時にコンシュームされます。これは予想された動作です。

たとえば、次のタスクを実行するとします。

- クライアントBPELプロセスおよびサービスBPELプロセスでSOAコンポジット・アプリケーションを作成し、非同期のinvokeアクティビティおよびreceiveアクティビティを使用してメッセージを交換する。

- クライアントBPELプロセスのreceiveアクティビティの「タイムアウト」タブで、30秒のタイムアウトを構成する。

- サービスBPELプロセスに5分間待機するwaitアクティビティを構成する。

タイムアウトが発生した後は、クライアントBPELプロセスが引き続き実行中の状態ではなく、フォルト状態で完了済としてマークされ、サービスBPELプロセスからのコールバック・メッセージが無視されることが予想されます。ただし、クライアントBPELプロセスでタイムアウト・フォルトがスローされた場合、そのプロセスは実行中の状態のままになります。サービスBPELプロセスがwaitアクティビティの完了から5分後に応答すると、レスポンスがクライアントBPELプロセスに返信されてコンシュームされ、実行中のプロセス・インスタンスに対して調整されます。

8.2.4 複数のクライアント・コンポーネントによる1つのコンポジットの起動に関する必知事項

複数のクライアント・コンポーネントがそのリモートのWSDLファイルを使用して1つのSOAコンポジット・アプリケーションを起動した場合は、リモート・コンポジットをコールしている元のクライアントにreceiveアクティビティが存在する場合にのみ、コールバック・レスポンスをこのクライアントで取得できます。元のクライアントにreceiveアクティビティが存在せず、コンポジットをコールする後続のクライアントのいずれにもreceiveアクティビティが存在しない場合、レスポンス・メッセージは失われます。これにより、元のクライアント・プロセスのリカバリ状態となります。

これは予想された動作です。これは、起動されているコンポジットでは、receiveアクティビティがどのクライアントに存在するか、またはクライアントが実際にBPELプロセス・サービス・コンポーネントであるかどうかを認識できないためです。

8.2.5 BPEL 2.0 IMAサポートの制限に関する必知事項

receiveアクティビティは一種のインバウンド・メッセージ・アクティビティ(IMA)です。IMAのその他の例は次のとおりです。

- scopeアクティビティ(BPEL 1.1)またはpickアクティビティのonMessageブランチ

- BPEL 2.0のscopeアクティビティのonEventブランチ

BPEL 2.0仕様では、複数のIMAを相互に使用する、または拡張アクティビティから導出した他のIMAとともに使用することができます。実行時の動作を一定に保つために、BPEL 2.0仕様ではinitiate属性をjoinに設定した相関セットを使用できます。ただし、Oracle BPEL Process ManagerにおけるBPEL 2.0仕様では、この動作がサポートされていません。複数のIMAをサポートする唯一の方法は、それらをpickアクティビティのonMessageブランチとしてコーディングする(つまり、createInstanceをyesに設定する)ことです。また、Oracle BPEL Process Managerでは、複数IMAのその他の形、たとえば2つのブランチを持つflowアクティビティで、それぞれがreceiveアクティビティを持ち、createInstanceの設定がyesで、相関セットのinitiateの設定がjoinであるなどの形もサポートされていません。

解決方法として、次のように、交互に2つのreceiveアクティビティがある2つのBPELプロセスを設計する必要があります。

- Process1: receive1の後にreceive2が続き、receive1でのみ、createInstanceがyesに設定されています。

- Process2: receive2の後にreceive1が続きます。receive2でのみ、createInstanceがyesに設定されています。

同じことが、receiveアクティビティとpickアクティビティ、または2つのpickアクティビティなど、IMAの他の組合せにも適用されます。

8.2.6 対話ID指定時の処理内容

invokeアクティビティ(およびreceiveアクティビティなどの他のアクティビティ、pickまたはscopeアクティビティのonMessageブランチ)の「対話ID」フィールドにオプションの対話ID値を入力することもできます。

対話IDは、非同期対話中にプロセス・インスタンスを識別します。デフォルトでは、BPELプロセス・サービス・エンジンにより、WSAアドレッシングで指定されているように、対話(複数のinvokeアクティビティおよびreceiveアクティビティにまたがる可能性があります)ごとに一意のIDが生成されます。必要に応じて、使用するサービス・エンジンに独自の値を指定できます。対話IDはbpelx:conversationId拡張要素で実装されます。

8.2.6.1 BPEL 1.1のbpelx:conversationId

次に、BPELバージョン1.1をサポートするBPELプロジェクト内のbpelx:conversationId拡張要素の例を示します。bpelx:conversationId拡張要素はXPath式をとります。

<invoke ... bpelx:conversationId="$convId2">
</invoke>

<receive ... bpelx:conversationId="$convId2">
</receive>

<onMessage... bpelx:conversationId="$convId2">
</onMessage>

8.2.6.2 BPEL 2.0のbpelx:conversationId

次に、BPELバージョン2.0をサポートするBPELプロジェクト内のbpelx:conversationId拡張要素の例を示します。bpelx:conversationId拡張要素はBPEL 2.0 XPath式をとります。

<invoke ...>
<bpelx:conversationId>$convId1</bpelx:conversationId>
</invoke>

<receive ...>
<bpelx:conversationId>$convId1</bpelx:conversationId>
</receive>

<onMessage ...>
<bpelx:conversationId>$convId2</bpelx:conversationId>
</onMessage>

8.3 複数のreceiveまたはpickアクティビティで同じパートナ・リンクが使用されている場合における適切なエンドポイントへのコールバック・メッセージのルーティング

複数のreceiveアクティビティまたはpickアクティビティが同じパートナ・リンクに関連付けられている場合に、適切なエンドポイント・アドレスへのコールバック・メッセージのルーティングを解決するには、replyToAddress正規化されたメッセージのプロパティが必要です。

これは、BPELプロセス・サービス・エンジンでは、replyToAddressプロパティが格納されるのは、起動元のreceiveまたはpickアクティビティでパートナ・リンクからのリクエストを受信するときの1回のみであるためです。replyToAddressは、コールバック・メッセージをルーティングし、中間プロセスのreceiveまたはpickアクティビティが使用されている場合にリセットされません。replyToAddressプロパティは、bpelx:inputProperty拡張要素を使用します。

8.3.1 複数のreceiveまたはpickアクティビティで同じパートナ・リンクが使用されている場合における適切なエンドポイントへのコールバック・メッセージのルーティング

中間プロセスのreceiveアクティビティの後に続くinvokeアクティビティ(コールバック用)に対して、このプロパティをクライアントのreplyToAddressに設定してください。つまり、クライアントが、中間プロセスのreceiveアクティビティに対してWS-Addressing replyTo情報を送信する場合でも、assignアクティビティを使用してそれを動的に設定しないかぎり、それがパートナ・リンクに設定されることはありません。

たとえば、BPELプロセスが次に示すとおりであるとします。

Caller                               Callee
-----------------------------------------------------------
<receive>                            <receive> Initiate CS1
<invoke>initiate CS1 -------->       <receive> Use CS1
<wait>
<receive>use CS1    <--------        <invoke>
<invoke>

複数のreceiveおよびpickアクティビティで同じパートナ・リンクが使用されている場合において適切なエンドポイントにコールバック・メッセージをルーティングする手順は、次のとおりです。

1. 中間プロセスのreceiveアクティビティからクライアントのreplyToAddress値を取得します。

<receive name="receiveMsgFromAccessor" partnerLink="midprocess_client"
portType="client:mySingletonBPEL" operation="process"
variable="ReceiveMidProcess" createInstance="no">
<bpelx:fromProperties>
<bpelx:fromProperty name="replyToAddress" variable="var_replyToAddress"/>
</bpelx:fromProperties>
<correlations>
<correlation set="<YourCorrset>" initiate="no"/>
</correlations>
</receive>

2. そのinvokeアクティビティ(コールバック用)で、「プロパティ」タブをクリックします。

3. 「追加」アイコンをクリックして、プロパティおよびその内容(変数またはXPath式)を選択します。

注意:

BPEL 1.1プロセスでは、プロパティは「プロパティ」列に自動的に表示されます。「名前」列でプロパティを選択し、「値」列および「タイプ」列をダブルクリックして適切な値を入力します。

4. 「名前」列で、下にスクロールして「replyToAddress」プロパティを選択します。「wsa.replyToAddress」または「bpel.replyToAddress」を選択しないでください。

5. 「値」列で、変数名を値(この例では、手順1のvar_replyToAddressが入力されています)として指定して、「OK」をクリックします。

図8-1 に示すように、Invokeの編集ダイアログが表示されます。

図8-1 invokeアクティビティの「プロパティ」タブ

6. 「適用」をクリックし、「OK」をクリックします。

7. Oracle BPELデザイナで、「ソース」をクリックします。

BPELプロセス・ファイル内のinvokeアクティビティは次のようになります。

<invoke name="callbackAccessor" partnerLink="midprocess_client"
portType="client:mySingletonBPELCallback"
operation="processResponse"
inputVariable="CallbackAccessorVar"
bpelx:invokeAsDetail="no">
<bpelx:inputProperty name="replyToAddress"
variable="var_replyToAddtess"/>

8.4 パートナ・リンク操作レベルでの冪等性の管理

idempotentアクティビティは、問題なく再試行できるアクティビティです。idempotentアクティビティは、永続プロセスと一時プロセスの両方に適用されます。冪等性は、パートナ・リンクの操作レベルで管理できます。たとえば、いくつかのパートナ・リンクでは複数の操作を公開できます(たとえば、getEmployee、depositPayCheckなど)。いくつかの操作を冪等として定義できます(たとえば、getEmployee)。これによって、これらの操作を複数回コールできるようになります。他の操作は、冪等にする必要がない場合があり(たとえば、depositPayCheck)、この設定は不要です。デハイドレーションは、非冪等操作の後に発生します。

デフォルトでは、すべてのパートナ・リンク操作は冪等です。必要な場合は、操作を非冪等に設定できます。この設定は、idempotentデプロイメント・ディスクリプタのプロパティと同じ機能を、より詳細な操作レベルで提供します。

idempotentデプロイメント・ディスクリプタのプロパティの詳細は、「idempotentプロパティとフォルト処理に関する必知事項」および「デプロイメント・ディスクリプタのプロパティの概要」を参照してください。

8.4.1 パートナ・リンク操作レベルでの冪等性の管理方法

パートナ・リンク操作レベルで冪等性の管理する手順は、次のとおりです。

1. Oracle BPELデザイナで、冪等性の管理対象となる操作が含まれているパートナ・リンクをダブル・クリックします。

2. パートナ・リンクの「冪等性」タブをクリックします。

デフォルトでは、「冪等」列ですべての操作が冪等であると選択されています。

3. 操作を非冪等と定義する場合は、その操作の「冪等」チェック・ボックスを選択解除します。図8-2に詳細を示します。

図8-2 パートナ・リンク・アクティビティの「冪等性」タブ

4. 「適用」をクリックします。

5. 「OK」をクリックします。

冪等性およびidempotentプロパティの詳細は、「デプロイメント・ディスクリプタのプロパティの概要」を参照してください。

8.5 実行時に使用するための動的パートナ・リンクの設計時の作成

SOAコンポジット・アプリケーションを設計する場合、次の課題に直面することがあります。

- サービス・エンドポイント(アドレス)が設計時にわからない場合があります。

- アプリケーションの実行中に、エンドポイント参照の変更が必要な場合があります。

動的パートナ・リンク機能を使用すると、BPELバージョン1.1および2.0の実行時に使用するために、エンドポイント参照をパートナ・リンクに動的に割り当てることができます。動的パートナ・リンクでは、switchアクティビティに類似した条件が提供され、この条件は実行時に評価されます。

8.5.1 実行時に使用するための動的パートナ・リンクの設計時の作成方法

実行時に使用するために動的パートナ・リンクを設計時に作成する手順は、次のとおりです。

1. 同じportTypeを使用する複数のサービスが含まれているWSDLファイルを作成します。

<service name="AmericanLoan">
<port name="LoanServicePort" binding="tns:LoanServiceBinding">
<soap:address location="host:port/soa-infra/services/domain_
name/AmericanLoan/client"/>
</port>
</service>

<service name="AlliedLoan">
<port name="LoanServicePort" binding="tns:LoanServiceBinding">
<soap:address location="host:port/soa-infra/services/domain_
name/AlliedLoan/client"/>
</port>
</service>

<service name="AcmeLoan">
<port name="LoanServicePort" binding="tns:LoanServiceBinding">
<soap:address location="host:port/soa-infra/services/domain_
name/AcmeLoan/client"/>
</port>
</service>

2. 「SOAP」バインディング・コンポーネントをSOAコンポジット・エディタの「外部参照」スイムレーンにドラッグします。

「Webサービスの作成」ダイアログが表示されます。

3. Webサービスを定義して、「OK」をクリックします。

完了すると、WSDLを使用するcomposite.xmlファイルの参照バインディング・コンポーネントのエントリは、次のようになります。

<reference name="loanService">
<interface.wsdl interface="http://services.otn.com#wsdl.interface(LoanService)"
callbackInterface="http://services.otn.com#wsdl.interface(LoanServiceCallback)"
/>
<binding.ws port=
"http://services.otn.com#wsdl.endpoint(AmericanLoan/LoanService_pt)"/>
</reference>

注意:

- binding.ws port設定の追加はオプションです。これは、Oracle BPEL Process Managerから渡されるプロパティによって、実行時にポートがオーバーライドされるためです。

- port設定がなく、この参照に関連付けられている具体WSDLのコンポジット・インポートもない場合は、location属性を使用して具体WSDLの場所を指定する必要があります。

4. BPELプロセスをダブルクリックして、Oracle BPELデザイナを入力します。

5. assignアクティビティをデザイナにドラッグします。

6. 図8-3 に示すように、ターゲット・パートナ・リンクの上にある「XMLフラグメント」アイコンを選択します。BPEL 2.0を使用中の場合は、「リテラル」アイコンをドラッグします。

図8-3 「XMLフラグメント」アイコン

7. このアイコンをターゲット・パートナ・リンクにドラッグします。

BPEL 1.1用の「XMLフラグメント」ダイアログが表示されます。BPEL 2.0を使用中の場合は、「リテラル」ダイアログが表示されます。

8. エンドポイント参照を含むXMLフラグメントをパートナ・リンクに割り当てて、「OK」をクリックします。図8-4に詳細を示します。

図8-4 BPEL 1.1の「XMLフラグメント」ダイアログ

完了すると、BPELファイルにはWSDLで定義されたサービスのいずれかが含まれます。

次にBPEL 1.1の例を示します。

<EndpointReference xmlns="http://schemas.xmlsoap.org/ws/2003/03/addressing">
<Address>http://host:port/soa-infra/services/domain_name
/AlliedLoan/client</Address>
<ServiceName xmlns:ns1="http://services.otn.com"
PortName="LoanServicePort">ns1:AlliedLoan</ServiceName>
</EndpointReference>

次にBPEL 2.0の例を示します。

<assign>
<copy>
<from>
<literal>
<sref:service-ref>
<services:EndpointReference>
<services:Address>http://host:port/soa-infra/services/domain_
name/AlliedLoan/client</services:Address>
<services:ServiceName
xmlns:ns1="http://services.otn.com">ns1:AlliedLoan</services:
ServiceName>
</services:EndpointReference>
</sref:service-ref>
</literal>
</from>
<to partnerLink="LoanService"/>
</copy>
</assign>

8.6 動的パートナ・リンクを起動する際のセキュリティ証明書のオーバーライド

動的パートナ・リンクを使用すると複数のWebサービスと対話できます。この対話には、メッセージを暗号化するために様々なセキュリティ証明書を必要とするメッセージ保護ポリシーの使用が含まれる場合があります。これらの証明書は、Webサービスごとに異なる場合があります。キーストア受信者別名値を指定して、WebサービスのWSDLファイル内のセキュリティ証明書をオーバーライドできます。

パートナ・リンクを起動する際にセキュリティ証明書をオーバーライドする手順は、次のとおりです。

1. 文字列タイプの変数(たとえば、KEYSTORE_RECIPIENT_ALIAS)を定義します。図8-5に詳細を示します。

図8-5 KEYSTORE_RECIPIENT_ALIASの変数定義

2. assignアクティビティの「コピー・ルール」タブで、orakeyを変数KEYSTORE_RECIPIENT_ALIASに割り当てます。図8-6に詳細を示します。

図8-6 KEYSTORE_RECIPIENT_ALIASへのorakeyの割当て

3. Webサービスのパートナ・リンクを起動するinvokeアクティビティで、「プロパティ」タブをクリックします。

4. keystore.recipient.aliasプロパティをクリックします。

注意:

BPEL 2.0プロセスでは、プロパティは「プロパティ」列に自動的に表示されません。「追加」 アイコンをクリックして、プロパティとその内容(変数またはXPath式)を選択する必要があります。

5. 「値」列をダブルクリックし、「参照」(...)アイコンを表示します。

6. 「参照」(...)アイコンをクリックし、「アダプタ・プロパティ値」ダイアログを表示します。

7. 「参照」アイコンをクリックして、「変数XPathビルダー」ダイアログを表示します。

8. 値としてkeystore_recipient_aliasを選択し、「OK」をクリックします。図8-7に詳細を示します。BPELプロセスでWebサービスを起動する際にWSDLファイルに設定されているセキュリティ証明書が、このプロパティによってオーバーライドされます。

注意:

BPEL 2.0では、「プロパティ」表には、「名前」列および「値」列のみが存在します。「タイプ」列はありません。

図8-7 invokeアクティビティの正規化されたメッセージのプロパティkeystore.recipient.alias

9. 「適用」をクリックし、「OK」をクリックします。

完了すると、BPELファイルは次のように定義されます。

. . .
. . .
<variables>
<variable name="WsaAddress" element="ns6:EndpointReference"/>
<variable name="KEYSTORE_RECIPIENT_ALIAS" type="xsd:string"/>
</variables>

<assign name="AssignAddress">
<copy>
<from
expression="'http://localhost:8001/soa-infra/services/default/ServiceWithNewCer
tificate!1.0*soa_c94537fb-97a4-4b0f-900f-fefffc34f7fe/service_ep'"/>
<to variable="WsaAddress"
query="/ns6:EndpointReference/ns6:Address"/>
</copy>
<copy>
<from variable="WsaAddress"/>
<to partnerLink="Service"/>
</copy>
</assign>

<assign name="AssignAlias">
<copy>
<from expression='"orakey"'/>
<to variable="KEYSTORE_RECIPIENT_ALIAS"/>
</copy>
</assign>

<invoke name="Invoke"
inputVariable="Invoke_InputVariable"
partnerLink="Service"
portType="ns1:ServiceBPELProcess"
operation="process"
bpelx:invokeAsDetail="no">

<bpelx:inputProperty name="endpointURI"
variable="inputVariable"
part="payload"
query="/client:process/client:input"/>

<bpelx:inputProperty name="keystore.recipient.alias"
variable="KEYSTORE_RECIPIENT_ALIAS"/>
</invoke>

正規化されたメッセージのプロパティの詳細は、「メッセージ・ヘッダーを介した正規化メッセージ・プロパティの伝播」を参照してください。

8.7 動的パートナ・リンクのWSDLファイルのオーバーライド

場合によっては、次のような理由によって、動的パートナ・リンクによって使用されるデフォルトWSDLファイルをオーバーライドする必要があります。

- メッセージ保護セキュリティ・ポリシーを使用するサービスと統合する必要がある。

- WSDLに、メッセージ暗号化に使用される証明書など重要な情報が含まれている可能性がある。

正規化されたメッセージのプロパティendpointWSDLによって、動的パートナ・リンクのWSDLファイルを指定できます。エンドポイントのみでなく、WSDL全体を動的に指定する必要があります。これにより、WSDLファイルをOracle Web Services Manager (OWSM)に渡すことができ、その後、OWSMは指定されたWSDLから適切なサービス証明書を取得できます。

WSDLファイル内の証明書は、次の場合には無視されます。

- 「動的パートナ・リンクを起動する際のセキュリティ証明書のオーバーライド」に記載されているrecipient.key.aliasプロパティ名が存在している。

- endpointWSDLプロパティが存在していない。

それ以外の場合、証明書はWSDLファイルから取得されます。

動的パートナ・リンクのWSDLファイルをオーバーライドする手順は、次のとおりです。

1. 文字列タイプの変数を定義します(この例では、the_wsdl_varが定義されます)。

2. assignアクティビティの「コピー・ルール」タブで、WSDLを変数the_wsdl_varに割り当てます。

3. パートナ・リンクを起動するinvokeアクティビティで、「プロパティ」タブをクリックします。

4. endpointWSDLプロパティをクリックします。

注意:

BPEL 2.0プロセスでは、プロパティは「プロパティ」列に自動的に表示されません。「追加」 アイコンをクリックして、プロパティとその内容(変数またはXPath式)を選択する必要があります。

5. 「値」列をダブルクリックし、「参照」(...)アイコンを表示します。

6. 「参照」(...)アイコンをクリックし、「アダプタ・プロパティ値」ダイアログを表示します。

7. 「参照」アイコンをクリックして、「変数XPathビルダー」ダイアログを表示します。

8. 変数としてthe_wsdl_varを選択し、「OK」をクリックします。この値によって、動的パートナ・リンクのWSDLが指定されます。

注意:

BPEL 2.0では、「プロパティ」表には、「名前」列および「値」列のみが存在します。「タイプ」列はありません。

図8-8 invokeアクティビティの正規化されたメッセージのプロパティendpointWSDL

完了すると、BPELファイルは次のように定義されます。

<variables>
<variable name="the_wsdl_var" type="xsd:string"/>
</variables>

<assign name="myAssignWsdl">
<copy>
<from
expression='"http://localhost:8001/soa-infra/services/default/ServiceWithNewCer
tificate!1.0/service_ep?WSDL"'/>
<to variable="the_wsdl_var"/>
</copy>
</assign>

<invoke name="Invoke"
inputVariable="Invoke_InputVariable"
partnerLink="Service"
portType="ns1:ServiceBPELProcess"
operation="process"
bpelx:invokeAsDetail="no">

<bpelx:inputProperty name="endpointWSDL"
variable="the_wsdl_var"/>

</invoke>

正規化されたメッセージのプロパティの詳細は、「メッセージ・ヘッダーを介した正規化メッセージ・プロパティの伝播」を参照してください。

8.8 非同期サービスでのWS-Addressingの使用

ある時点でアクティブなインスタンスは多数存在する可能性があるため、サーバーはWebサービス・レスポンスに、対応する適切なBPELプロセス・サービス・コンポーネント・インスタンスを指示する必要があります。WS-Addressingを使用すると、非同期メッセージを識別して、非同期コールバックが確実に適切なクライアントを特定できるようにすることができます。

図8-9 に、WS-Addressingの概要を示します。WS-Addressingは、非同期メッセージの相関にSimple Object Access Protocol (SOAP)ヘッダーを使用します。メッセージは、使用されるトランスポートまたはアプリケーションに依存しません。

図8-9 WS-Addressingヘッダーを使用したコールバック

図8-9 は、レスポンスが正しい宛先に送信されるように、メッセージがWSヘッダーとともに渡される様子を示しています。

この章の例では、相関にWS-Addressingを使用しています。メッセージの表示には、TCPトンネリングを使用できます。これについては、「プログラム間で交換されるメッセージを表示するためのTCPトンネリングの使用方法」で説明します。

WS-Addressingは、通常は通信プロトコルおよびメッセージ・システムで提供される次の情報を定義します。この情報は、トランスポートまたはアプリケーションに依存せずに処理されます。

- エンドポイント・ロケーション(返信先アドレス)
返信先アドレスは、BPELクライアントがコールバック・メッセージをリスニングする場所を指定します。

- 対話ID
TCPトンネリングを使用して、BPELプロセス・サービス・コンポーネント・フローとWebサービスの間で交換されたSOAPメッセージ(相関IDを含むメッセージなど)を表示します。BPELプロセス・サービス・コンポーネント・フローの通信先のサービスに対して送受信される正確なSOAPメッセージを確認できます。

BPELプロセス・サービス・コンポーネント・フローとWebサービスの間にソフトウェア・リスナーを挿入します。BPELプロセス・サービス・コンポーネント・フローはリスナー(TCPトンネル)と通信します。リスナーはメッセージをWebサービスに転送し、表示します。Webサービスからのレスポンスはトンネルに返され、トンネルはレスポンスを表示して、BPELプロセス・サービス・コンポーネントに返します。

8.8.1 非同期サービスでのWS-Addressingの使用方法

WS-Addressingは公開されている仕様であり、でサポートされるデフォルトの相関方法です。WS-Addressingを使用するために、.bpelファイルおよび.wsdlファイルを編集する必要はありません。

8.8.1.1 プログラム間で交換されるメッセージを表示するためのTCPトンネリングの使用方法

プログラムとサービスの間で交換されるメッセージは、TCPトンネリングにより表示できます。これは、BPELプロセス・サービス・コンポーネント・フローとWebサービスの間で交換される正確なSOAPメッセージを表示する場合に、特に役立ちます。

SOAPメッセージを監視するには、フローとサービスの間にソフトウェア・リスナーを挿入します。フローはリスナー(TCPトンネル)と通信し、リスナーはサービスにメッセージを転送し、メッセージを表示します。同様に、サービスからのレスポンスはトンネルに返され、トンネルはレスポンスを表示してフローに返します。

サーバーとWebサービスの間で交換されたすべてのメッセージを表示する場合、該当するすべてのメッセージがサービスとの間で1回のリクエスト/リプライのやり取りで交換されるため、同期サービスに対して必要なTCPトンネルは1つのみです。非同期サービスの場合、2つのトンネル(サービスの起動用に1つ、フローのコールバック・ポート用に1つ)を設定する必要があります。

8.8.1.1.1 同期サービス用のTCPリスナーの設定

プロセスで開始される同期サービス用のTCPリスナーを設定する手順は、次のとおりです。

1. Axis TCPモニター(tcpmon)のダウンロードおよびインストールの方法については、次のURLにアクセスしてください。

http://ws.apache.org/commons/tcpmon/

2. tcpmonの使用方法の詳細は、次のURLを参照してください。

http://ws.apache.org/axis/java/user-guide.html

3. クラスパスにaxis.jarを設定します。

4. tcpmonを開始します。

C:\...\> java org.apache.axis.utils.tcpmon localport remoteHost
port_on_which_remote_server_is_running

5. composite.xmlファイルで、フローのbinding.wsの下にendpointURIプロパティを追加し、サービスのエンドポイントをオーバーライドします。

6. オペレーティング・システムのコマンド・プロンプトからantを使用して、プロセスをコンパイルおよびデプロイします。

同じテクニックで、Axisや.NETなど、別のツール・キットからBPELプロセス・サービス・コンポーネントをWebサービスとして起動するために渡されるSOAPメッセージを参照できます。

8.8.1.1.2 非同期サービス用のTCPリスナーの設定

非同期サービスからのコールバックのSOAPメッセージを表示するTCPリスナーを設定する手順は、次のとおりです。

1. ポートでのリスニングとOracle BPEL Process Managerポートの送信を実行するTCPリスナーを起動します。

a. 「Oracle Enterprise Manager Fusion Middleware Control」を開きます。

b. 「SOAインフラストラクチャ」メニューから、「SOA管理」→「共通プロパティ」の順に選択します。

c. 「コールバック・サーバーURL」に値を指定します。このURLは、サーバーによって非同期コールバック・アドレスの一部としてインボーカに送信されます。

2. 「SOAインフラストラクチャ」メニューから、「管理」→「システムMBeanブラウザ」の順に選択します。

3. 「アプリケーション定義のMBean」→「oracle.soa.config」→「サーバー: soa_server」→「SCAComposite」の順に展開します。
soa_serverは、特定のサーバー・インスタンス名です(例: AdminServer)。

サーバーにデプロイされているすべてのSOAコンポジット・アプリケーションが表示されます。

4. 次の手順に従って、このプロパティをコンポジット・アプリケーションに設定します。このアクションにより、コンポジット・アプリケーションのすべてのバインディングにプロパティ設定が適用されます。

a. コンポジットをクリックします。

b. 「属性」タブが選択されていることを確認します。

c. 「名前」列で、「プロパティ」をクリックします。

d. 「追加」アイコンをクリックします。

e. 新しく追加した「Element_number」(リストの最後に表示されます)を開きます。
numberは、最後のプロパティの番号の次の番号です。たとえば、プロパティ・リストに12個の要素があるときに新しいプロパティを追加すると、Element_13が表示されます。

f. 「名前」フィールドに、oracle.webservices.local.optimizationと入力します。

g. 「値」フィールドに、falseと入力します。

h. 「複数」フィールドに、falseと入力します。

i. 「適用」をクリックし、次に「戻る」をクリックします。

j. 「操作」タブの「名前」列で、「保存」をクリックします。

k. 「起動」をクリックして操作を実行します。

l. 「戻る」をクリックするか、「システムMBeanブラウザ」ペインでノードをクリックします。

注意:

プロパティを追加、削除または更新した後は、「システムMBeanブラウザ」ページの右上隅にある「キャッシュされたツリー・データのリフレッシュ」アイコンをクリックすると、新しいデータを参照できます。

5. 次の手順に従って、このプロパティを特定のバインディングに設定します。

a. コンポジット・アプリケーションを開き、特定のSCAComposite.SCAReference.SCABindingフォルダに移動します。

b. 「WSBinding」をクリックします。

c. ステップ4.bから4.lを実行します。

6. 非同期Webサービスを起動するフローを開始します。これを同期TCPトンネリング構成と組み合せると、サービス開始リクエストを最初のTCPトンネル経由で送信できます。
非同期サービスからのコールバックは、TCPリスナーに表示されます。

Oracle JDeveloperユーザーは、組込みパケット・モニターを使用して、同期サービスと非同期サービスの両方についてSOAPメッセージを表示することもできます。

メッセージの相関での相関セットの使用方法の詳細は、「相関セットおよびメッセージ集約の使用」を参照してください。

9 相関セットおよびメッセージ集約の使用

この章では、相関セットを使用して、非同期コールバックが確実に適切なクライアントを特定できるようにする方法について説明します。また、集約パターンを使用して、同じインスタンスにメッセージをルーティングする方法についても説明します。

この章の内容は次のとおりです。

- 非同期サービスでの相関セットの概要

- Oracle JDeveloperにおける相関セットの作成

- 同じインスタンスへのメッセージのルーティング

9.1 非同期サービスでの相関セットの概要

相関セットは、Webサービスのレスポンスを適切なBPELプロセス・サービス・コンポーネント・インスタンスに戻すための方法を提供します。相関セットを使用すると、非同期メッセージを識別して、非同期コールバックが確実に適切なクライアントを特定できるようにすることができます。相関セットは、連携が単純なinvokeとreceiveアクティビティでない場合に定義します。

相関セットは、メッセージ本体の内容に基づいて非同期メッセージの相関を可能にするBPELメカニズムです。この方法を使用するには、BPELプロセスに相関セットを定義します。この方法は、WS-Addressingをサポートしないサービス用、または対話がA > B > AではなくA > B > C > Aという形式の場合など、一定の高度な対話パターン用に設計されています。

9.1.1 相関セットの使用のシナリオ

相関を使用すると、メッセージ本文の内容に基づいて非同期メッセージを関連付けることができます。すべてのビジネス・シナリオに相関が必要なわけではありません。

- 同期コールでは、会話のコンテキストがスタックまたはTCP接続にわたって保持されるため、相関は必要ありません。

- 通常、BPELプロセスに承諾することでメッセージが関連付けられ、WS-Addressingヘッダーを使用してWebアプリケーションでセッション・クッキーのように動作するトークンを渡します。詳細は、「非同期サービスでのWS-Addressingの使用」を参照してください。

相関は次のシナリオで必要です。次の各ケースでは、BPELプロセスはメッセージの内容の一部を表示するために構成する必要があり、これを使用してメッセージを受信するために適切なプロセス・インスタンスを選択します。

- WS-Addressingをサポートしていない非同期サービスを使用している場合。

- 別のシステムから要求していないメッセージを受信する場合。

- メッセージが複数のサービスを経由し、最初のサービスによって最後のサービスからレスポンスが直接要求された場合。

- ファイルを介して通信している場合。

9.1.2 相関セットの内容および概念の理解

この項では、主要な相関セットの概念に関する概要を説明します。

相関セットを使用する適切なBPELインスタンスは、次のように取得されます。

- BPELプロセスは、カスタム相関を許可するために、相関セットと呼ばれる構成を提供します。

- 相関セットは、メッセージを受信するための適切なプロセスを特定するためにBPELプロセス・サービス・エンジンが使用するプロパティの集合です。

- 相関セット内の各プロパティは、プロパティ・エイリアスを介して1つ以上のメッセージ・タイプの要素にマッピングできます。図9-1 に概要を示します。

図9-1 相関セット

次の主な相関のガイドラインに注意してください。

- メッセージを受信するプロセスのみが相関に関係します。以前のアクティビティと関連付けるために送信サービスに十分な情報がメッセージに含まれているかぎりは、相関が発生していることを送信者が認識する必要はありません。

- 相関プロパティは、それを設定するBPELプロセスが存続している間は一意である必要があります。

- 2つのプロセスが同じ相関トークンを使用していることを確認します。たとえば、プロセスで2つの異なるインスタンスを開始する場合、経費請求プロセスを関連付けるために社会保障番号を使用することは推奨されません。

- プロパティは、値または注文書や発注番号などの実際のビジネス識別子から構成できます。文字列である必要はなく、任意の適当なXMLタイプを使用できます。

主な相関概念の属性は次のとおりです。相関ウィザードで相関セットを設計するときに、Oracle JDeveloperでこれらの属性を設定します。

- initiate属性は次のように設定されます。

- はい: 相関セットは、転送されるメッセージで使用可能なプロパティの値を使用して開始されます。

- いいえ: 相関セットは、メッセージで使用可能なプロパティの値を検証します。

- pattern属性は次のように設定されます。

- イン (BPEL 1.1の場合)またはレスポンス (BPEL 2.0の場合): 相関プロパティは、受信メッセージ上で設定および検証されます。

- アウト (BPEL 1.1の場合)またはリクエスト (BPEL 2.0の場合): 相関プロパティは、送信BPELメッセージ上で設定および検証されます。

- アウト-イン (BPEL 1.1の場合)またはリクエスト/レスポンス (BPEL 2.0の場合): 相関プロパティは、受信と送信メッセージの両方で設定および検証されます。

- プロパティ・エイリアスは、グローバル・プロパティを特定のメッセージ・パートのフィールドにマッピングします。このアクションにより、プロパティ名を、メッセージのパートと場所を表すエイリアスにできます。このエイリアスは、XPath式で使用できます。

9.1.3 相関セットの作成の概要

表9-1 に、相関セットの作成に必要な手順の概要を示します。これらの手順を実行する相関ウィザードのページへの参照および設定する値の例を説明します。

表9-1 相関セットの作成の概要

手順

相関ウィザードのページ

例

交換を関連付けるプロパティ名およびタイプを使用して相関セットを作成します。

この情報は、相関ウィザードの「相関セットの定義」ページで設定します。図9-2を参照してください。

次のプロパティ名およびタイプを使用してphonenumber相関セットを作成します。

- 文字列型のusername

- int型のuserordernumber

- ブール型のIsGift

会話を開始するinvokeアクティビティまたはreceiveアクティビティに相関を追加し、「開始」を「はい」に設定します。

相関ウィザードの「設定の開始」ページで、アクティビティを選択して「開始」属性を設定します。図9-3を参照してください。

「internalReceive」 receiveアクティビティを選択して、「開始」を「はい」に設定します。

プロパティ・エイリアスのマッピングを各メッセージの適切な要素に作成します。会話の両方のメッセージで同じ値を持つ必要があります。要素は、2つのメッセージで異なる名前および異なる構造にできますが、相関を機能させるには、メッセージに同じ値が含まれている必要があります。

この情報は、相関ウィザードの「プロパティ・エイリアス」ページで設定します。図9-7を参照してください。このページでは次の2つのエディタを使用でき、このエディタを使用してプロパティ・エイリアスのマッピングを作成できます。

- エイリアス・エディタ(図9-4)

- エイリアス・ドラッグ・アンド・ドロップ・エディタ(図9-5 )

相関セットのプロパティ値を実行時に移入するためにプロパティ・エイリアスを定義します。

- エイリアスのusernameをnameメッセージ要素にマッピングします。

- エイリアスのuserordernumberをpoNumberメッセージ要素にマッピングします。

- エイリアスのIsGiftをgiftメッセージ要素にマッピングします。

そのプロパティを使用して同じ相関セットを追加のアクティビティに追加します。それらを「開始」に設定しないでください。BPELプロセスをこれを使用して適切なプロセス・インスタンスを選択します。パターンを適切に設定します。

アクティビティ相関エディタの「開始」タブで設定します。図9-10を参照してください。

「internalCallback」 invokeアクティビティを選択します。

- 「開始」を「いいえ」に設定します。

- 「パターン」を「リクエスト」に設定します。

9.2 Oracle JDeveloperにおける相関セットの作成

相関セットを次のアクティビティとブランチで作成できます。

- receiveアクティビティ

- replyアクティビティ

- invokeアクティビティ

- onMessageブランチ

- onEventブランチ

Oracle JDeveloperで相関セットを作成する方法は2種類あります。

- アクティビティの相関ウィザードを使用した自動の方法

- アクティビティの「相関」タブを使用した手動の方法

9.2.1 相関ウィザードで相関セットを作成する方法

相関ウィザードで相関セットを作成する手順は、次のとおりです。

1. 適切なアクティビティ(receiveアクティビティなど)を右クリックし、「相関の設定」を選択します。
相関ウィザードの「相関セットの定義」ページが表示されます。

2. 環境に適したレスポンスを指定してから、「次へ」をクリックします。表9-2に詳細を示します。

表9-2 「相関ウィザード」の「相関セットの定義」ページ

フィールド

説明

相関セットの作成

選択すると新しい相関セットが作成されます。

既存の相関セットの選択

選択アクティビティを含ませるための既存相関セットを選択します。

名前

作成する相関セットの名前を入力します。

スコープ

新しい相関セットを作成するスコープまたはプロセスが表示されます。

プロパティ

a. 「追加」をクリックし、「プロパティ」表の「名前」列で新規プロパティを作成するか、「参照」をクリックし、既存プロパティを選択します。

b. 「タイプ」列をクリックしてから、省略記号をクリックし、「タイプ・チューザ」ダイアログを起動して、プロパティ・タイプを選択します(たとえば、整数やブールなどのタイプ)。

完了すると、相関ウィザードの「相関セットの定義」ページは図9-2 のようになります。

図9-2 「相関ウィザード」の「相関セットの定義」ページ

相関ウィザードの「設定の開始」ページが表示されます。

3. 環境に適したレスポンスを指定してから、「次へ」をクリックします。表9-3に詳細を示します。

表9-3 「相関ウィザード」の「設定の開始」ページ

フィールド

説明

アクティビティ

相関が設定されるアクティビティが表示されます。

開始

このアクティビティが相関セットでイニシエータであるかどうかを選択します。

「はい」に設定されると、相関セットは、送受信されるメッセージで発生するプロパティの値を使用して開始されます。

完了すると、相関ウィザードの「設定の開始」ページは図9-3 のようになります。

図9-3 「相関ウィザード」の「設定の開始」ページ

相関ウィザードの「プロパティ・エイリアス」ページが、プロパティを値にマッピングするために表示されます。ウィザードの「相関セットの定義」ページで以前に定義されたプロパティが、「プロパティ・エイリアス」表に表示されます。

「プロパティ・エイリアス」により、変数の特定メッセージ・パートでプロパティをフィールドにマッピングできます。このアクションにより、プロパティをメッセージのパートと場所のエイリアスにできます。

4. プロパティを表でクリックし、変数のメッセージ・パートをプロパティにマッピングする方法を選択します。表9-4に詳細を示します。

表9-4 変数メッセージ・パートをプロパティにマッピングする方法

使用対象

移動先の手順

エイリアス・エディタ

5

エイリアス・ドラッグ・アンド・ドロップ・エディタ

6

5. 「編集」(1番目)アイコンをクリックして、「エイリアス・エディタ」ダイアログを起動します。

a. 変数を展開します。

b. プロパティを示すメッセージ・パートを選択して、「OK」をクリックします。図9-4に詳細を示します。

図9-4 エイリアス・エディタ

6. 「エイリアス・ドラッグ・アンド・ドロップ・エディタ」(2番目)アイコンをクリックして、「エイリアス・ドラッグ・アンド・ドロップ・エディタ」ダイアログを起動します。

a. 変数を展開します。

b. プロパティを示すメッセージ・パートを選択します。

c. メッセージ・パートを相関ウィザードの「プロパティ・エイリアス」ページのプロパティ行にドラッグ・アンド・ドロップします。図9-5に詳細を示します。

図9-5 エイリアス・ドラッグ・アンド・ドロップ・エディタ

図9-6 に示すとおり、既存のプロパティ・エイリアスが相関ウィザードの「プロパティ・エイリアス」ページの下の部分にリストされます。この例では、既存のプロパティ・エイリアスはありません。

図9-6 相関ウィザードの「プロパティ・エイリアス」ページの下の部分

d. 完了したら、「次へ」をクリックします。

7. 変数の特定メッセージ・パートをプロパティにマッピングするプロパティをさらに選択します。

完了すると、相関ウィザードの「プロパティ・エイリアス」ページは図9-7 のようになります。図9-2 で作成したプロパティが「プロパティ」列に表示されます。エイリアス・エディタ(図9-4 )またはエイリアス・ドラッグ・アンド・ドロップ・エディタ(図9-5 )を使用してプロパティがマッピングされたメッセージ要素が「問合せ」列に表示されます。

図9-7 「相関ウィザード」の「プロパティ・エイリアス」ページ

8. 「次へ」をクリックします。
相関ウィザードの「相関されたアクティビティ」ページが表示されます。図9-8に詳細を示します。

図9-8 「相関ウィザード」の「プロパティ・エイリアス」ページ(アクティビティなし)

9. 「追加」アイコンをクリックし、さらにアクティビティを相関セットに追加します(複数のアクティビティをこの相関セットに関連付けることができます)。
「アクティビティ・ブラウザ」ダイアログが表示されます。

10. 追加するアクティビティを選択して「OK」をクリックします。図9-9に詳細を示します。

図9-9 アクティビティを選択するためのアクティビティ・ブラウザ

相関ウィザードの「相関されたアクティビティ」ページの「相関アクティビティ」フィールドにこのアクティビティが追加されます。

11. 「相関アクティビティ」フィールドで、アクティビティを選択し、「編集」をクリックして、「アクティビティ相関エディタ」ダイアログの「開始」タブを起動します。図9-10に詳細を示します。

図9-10 「アクティビティ相関エディタ」の「開始」タブ

12. 「開始」リストおよび「パターン」リストから適切な値を選択します。この例では、次のように指定します。

- 「開始」リストから「いいえ」を選択します(相関セットがメッセージ内の使用可能なプロパティを検証するため)。

- Patternリストから「リクエスト」を選択します(相関プロパティは、送信BPELメッセージ上で設定および検証されるため)。

BPEL 2.0では、相関がインバウンド・メッセージに適用される場合は「レスポンス」を、相関がアウトバウンド・メッセージに適用される場合は「リクエスト」を、または相関がアウトバウンド・メッセージとインバウンド・メッセージの両方に適用される場合は「リクエスト/レスポンス」を選択できます。

BPEL 1.1では、相関がインバウンド・メッセージ(レスポンス)に適用される場合は「イン」を、相関がアウトバウンド・メッセージ(リクエスト)に適用される場合は「アウト」を、または相関がアウトバウンド・メッセージとインバウンド・メッセージの両方(レスポンスとリクエスト)に適用される場合は「アウト-イン」を選択できます。

13. 「エイリアス」タブをクリックします。

14. 手順4から手順7まで繰り返して、変数のメッセージ・パートをプロパティにマッピングする方法とプロパティを選択します。
完了すると、「エイリアス」ダイアログは図9-11 のようになります。

図9-11 アクティビティ相関エディタの「エイリアス」タブ

15. 「OK」をクリックして、相関ウィザードの「相関されたアクティビティ」ページに戻ります(図9-12 のように表示されます)。

図9-12 「相関ウィザード」の「相関されたアクティビティ」ページ(アクティビティが選択された状態)

16. 「次へ」をクリックし、「アクティビティ」、「相関セット」および「エイリアス」のタブの詳細を確認します。

- アクティビティ: 相関とロールに関連するアクティビティが表示されます(たとえば、receiveアクティビティはイニシエータで、invokeアクティビティは応答者)。

- 相関セット: 相関セットの名前が表示されます。

- エイリアス: 相関セットでアクティビティ用に定義されたプロパティ・エイリアスが表示されます。

図9-13に詳細を示します。

図9-13 「相関ウィザード」の「サマリー」ページ

17. 「終了」をクリックします。
相関セットが作成されます。

18. 「構造」ウィンドウに、相関ウィザードで定義した相関セット、プロパティおよびプロパティ・エイリアスを表示します。

19. Oracle BPELデザイナで、いずれかの参加アクティビティの「相関」タブをクリックし、定義した詳細を表示します(たとえば、receiveアクティビティ)。図9-14に詳細を示します。

図9-14 receiveアクティビティの「相関」タブ

20. 相関セットで使用されるアクティビティを調べる場合、次の手順を実行します。

a. Oracle BPELデザイナの上にある「検索」アイコンをクリックして、「相関検索」を選択します。
「相関セット・チューザ」ダイアログが表示されます。

b. 相関セットを選択して「OK」をクリックします。

c. 「相関検索」で、「OK」をクリックします。
相関セットを使用するアクティビティが「ログ」ウィンドウに表示されます。

21. 別のアクティビティを既存の相関セットに追加する場合、アクティビティを右クリックし、「相関の設定」を選択します。
相関ウィザードの「相関セットの定義」ページが表示されます。

22. 「既存の相関セットの選択」を選択します。

23. 「相関セット」リストで、相関セットを選択し、「OK」をクリックします。

24. 相関ウィザードの各ページに従ってアクティビティを定義します。

9.2.2 「相関」タブで相関セットを手動で作成する方法

この項では、非同期サービスで相関セットを手動で作成するための手順について説明します。この例では、invokeアクティビティが関連付けられていないreceiveアクティビティを3つ含むプロセスに相関セットを使用する方法を示します。

9.2.2.1 ステップ1: プロジェクトの作成

プロジェクトを作成するには:

1. Oracle JDeveloperを起動します。

2. 「ファイル」メイン・メニューから、「新規」→「アプリケーション」を選択します。

3. 「SOAアプリケーション」を選択し、「OK」をクリックします。

SOAアプリケーションの作成ウィザードが表示されます。

4. 「アプリケーション名」フィールドに、名前を入力します(この例ではMyCorrelationSetAppが入力されています)。

5. 残りのすべての設定に対するデフォルト値をそのまま使用し、「次へ」をクリックします。

6. 「プロジェクト名」フィールドに、名前を入力します(この例ではMyCorrelationSetCompositeが入力されています)。

7. 残りのすべての設定に対するデフォルト値をそのまま使用し、「次へ」をクリックします。

8. 「コンポジット・テンプレート」セクションで、BPELプロセスを使用するコンポジットを選択し、「終了」をクリックします。

「BPELプロセスの作成」ダイアログが表示されます。

9. 表9-5 に示されている値を入力します。

表9-5 「BPELプロセスの作成」ダイアログのフィールドと値

フィールド

値

名前

名前を入力します(この例ではMyCorrelationSetが入力されています)。

テンプレート

「非同期BPELプロセス」を選択します。

SOAPサービスとして公開

チェック・ボックスを選択します。プロセスを作成すると、SOAPサービスが「公開されたサービス」スイムレーンに表示されることに注意してください。このサービスは外部からコンポジット・アプリケーションへのエントリ・ポイントを提供します。

10. 残りのすべての設定に対するデフォルト値をそのまま使用し、「OK」をクリックします。

9.2.2.2 ステップ2: パートナ・リンクとファイル・アダプタ・サービスの構成

次に、SOAPサービスを使用する3つのパートナ・リンクを作成します。

この項の内容は次のとおりです。

- 融資申請読取り用のアダプタ・サービスを持つ最初のパートナ・リンクを作成します。

- 申請レスポンス読取り用のアダプタ・サービスを持つ2番目のパートナ・リンクを作成します。

- 顧客レスポンス読取り用のアダプタ・サービスを持つ3番目のパートナ・リンクを作成します。

9.2.2.2.1 初期パートナ・リンクとファイル・アダプタ・サービスの作成

最初のパートナ・リンクとファイル・アダプタ・サービスを作成する手順は、次のとおりです。

1. 「MyCorrelationSet」BPELプロセスをダブルクリックします。

2. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を開きます。

3. 最初の「パートナ・リンク」アクティビティをデザイナの右スイムレーンにドラッグします。

4. 最上部の3つ目のアイコン(「サービス・ウィザード」アイコン)をクリックします。図9-15 に示すように、この操作でアダプタ構成ウィザードが起動します。

図9-15 アダプタ構成ウィザードの起動

5. 「サービスまたはアダプタの設定」ダイアログで「ファイル」を選択し、「OK」をクリックします。

6. ファイル・アダプタの「参照」ダイアログの「名前」フィールドで、名前を入力して(この例では、FirstReceiveが入力されています)「次へ」をクリックします。

7. 「アダプタ・インタフェース」ダイアログで、デフォルト設定をそのまま使用し、「次へ」をクリックします。

8. 「操作」ダイアログで「操作タイプ」として「Read File」を選択し、「次へ」をクリックします。「操作名」フィールドには、Readが自動的に入力されます。

9. 「着信ファイル用のディレクトリ(物理パス)」フィールドの上で「参照」をクリックします。

10. ファイルの読取り元のディレクトリを選択します(この例ではC:\files\receiveprocess\FirstInputDirを選択します)。

11. 「選択」をクリックします。

12. 「次へ」をクリックします。

13. 「ファイルのフィルタ処理」ダイアログで、適切なファイル・フィルタ・パラメータを入力します。

14. 「次へ」をクリックします。

15. 「ファイル・ポーリング」ダイアログで、適切なファイル・ポーリング・パラメータを入力します。

16. 「次へ」をクリックします。

17. 「メッセージ」ダイアログで「URL」フィールドの横にある「参照」をクリックして、「タイプ・チューザ」ダイアログを表示します。

18. 適切なXSDスキーマ・ファイルを選択します。この例では、Book1_4.xsdはスキーマであり、スキーマ要素としてLoanApplが選択されています。

19. 「OK」をクリックします。

「URL」フィールドと「スキーマ要素」フィールドに値が入力されます(この例ではそれぞれBook1_4.xsdとLoanAppl)。

20. 「次へ」をクリックします。

21. 「終了」をクリックします。

「パートナ・リンク」ダイアログが再び表示されます。その他すべてのフィールドには値が自動的に入力されます。ダイアログは表9-6 のようになります。

表9-6 「パートナ・リンク」ダイアログのフィールドと値

フィールド

値

名前

FirstReceive

WSDL URL

directory_path/FirstReceive.wsdl

パートナ・リンク・タイプ

Read_plt

パートナ・ロール

指定しません。

マイ・ロール

Read_role

22. 「OK」をクリックします。

9.2.2.2.2 2番目のパートナ・リンクとファイル・アダプタ・サービスの作成

2番目のパートナ・リンクとファイル・アダプタ・サービスを作成する手順は、次のとおりです。

1. 2番目の「パートナ・リンク」アクティビティを「FirstReceive」パートナ・リンク・アクティビティの下にドラッグします。

2. 最上部の3つ目のアイコン(「サービス・ウィザード」アイコン)をクリックします。

3. 「サービスまたはアダプタの設定」ダイアログで「ファイル」を選択し、「OK」をクリックします。

4. ファイル・アダプタの「参照」ダイアログの「名前」フィールドで、名前を入力して(この例では、SecondFileReadが入力されています)「次へ」をクリックします。この名前は、「最初のパートナ・リンクとファイル・アダプタ・サービスの作成」の手順6で入力した名前とは異なる必要があります。

5. 「アダプタ・インタフェース」ダイアログで、デフォルト設定をそのまま使用し、「次へ」をクリックします。

6. 「操作」ダイアログで「操作タイプ」として「Read File」を選択します。

7. 「操作名」フィールドで、名前を変更します(この例ではRead1が入力されています)。

8. 「次へ」をクリックします。

9. 「物理パス」として「ディレクトリ名は次の方法で指定します」を選択します。

10. 「着信ファイル用のディレクトリ(物理パス)」フィールドの上で「参照」をクリックします。

11. ファイルの読取り元のディレクトリを選択します(この例ではC:\files\receiveprocess\SecondInputDirと入力します)。

12. 「選択」をクリックします。

13. 「次へ」をクリックします。

14. 「ファイルのフィルタ処理」ダイアログで、適切なファイル・フィルタ処理パラメータを入力します。

15. 「次へ」をクリックします。

16. 「ファイル・ポーリング」ダイアログで、適切なファイル・ポーリング・パラメータを入力します。

17. 「次へ」をクリックします。

18. 「メッセージ」ダイアログで「URL」フィールドの横にある「参照」をクリックして、「タイプ・チューザ」ダイアログを表示します。

19. 適切なXSDスキーマ・ファイルを選択します。この例では、Book1_5.xsdはスキーマであり、スキーマ要素としてLoanAppResponseが選択されています。

20. 「OK」をクリックします。

「URL」フィールドと「スキーマ要素」フィールドに値が入力されます(この例ではそれぞれBook1_5.xsdとLoanAppResponse)。

21. 「次へ」をクリックします。

22. 「終了」をクリックします。

「パートナ・リンク」ダイアログが再び表示されます。その他すべてのフィールドには値が自動的に入力されます。ダイアログは表9-7 のようになります。

表9-7 「パートナ・リンク」ダイアログのフィールドと値

フィールド

値

名前

SecondReceive

WSDL URL

directory_path/SecondFileRead.wsdl

パートナ・リンク・タイプ

Read1_plt

パートナ・ロール

指定しません。

マイ・ロール

Read1_role

23. 「OK」をクリックします。

9.2.2.2.2.1 3番目のパートナ・リンクとファイル・アダプタ・サービスの作成

3番目のパートナ・リンクとファイル・アダプタ・サービスを作成する手順は、次のとおりです。

1. 3番目の「パートナ・リンク」アクティビティを「SecondReceive」パートナ・リンク・アクティビティの下にドラッグします。

2. 最上部の3つ目のアイコン(「サービス・ウィザード」アイコン)をクリックします。

3. 「サービスまたはアダプタの設定」ダイアログで「ファイル」を選択し、「OK」をクリックします。

4. ファイル・アダプタの「参照」ダイアログの「名前」フィールドで、名前を入力して(この例では、ThirdFileReadが入力されています)「次へ」をクリックします。この名前は、「最初のパートナ・リンクとファイル・アダプタ・サービスの作成」の手順6および「2番目のパートナ・リンクとファイル・アダプタ・サービスの作成」の手順4で入力した名前とは異なる必要があります。

5. 「アダプタ・インタフェース」ダイアログで、デフォルト設定をそのまま使用し、「次へ」をクリックします。

6. 「操作」ダイアログで「操作タイプ」として「Read File」を選択します。

7. 「操作名」フィールドで、名前を変更します(この例ではRead2が入力されています)。この名前は一意である必要があります。

8. 「次へ」をクリックします。

9. 「物理パス」として「ディレクトリ名は次の方法で指定します」を選択します。

10. 「着信ファイル用のディレクトリ(物理パス)」フィールドの上で「参照」をクリックします。

11. ファイルの読取り元のディレクトリを選択します(この例ではC:\files\receiveprocess\ThirdInputDirと入力します)。

12. 「選択」をクリックします。

13. 「次へ」をクリックします。

14. 「ファイルのフィルタ処理」ダイアログで、適切なファイル・フィルタ処理パラメータを入力します。

15. 「次へ」をクリックします。

16. 「ファイル・ポーリング」ダイアログで、適切なファイル・ポーリング・パラメータを入力します。

17. 「次へ」をクリックします。

18. 「メッセージ」ダイアログで「URL」フィールドの横にある「参照」をクリックして、「タイプ・チューザ」ダイアログを表示します。

19. 適切なXSDスキーマ・ファイルを選択します。この例では、Book1_6.xsdはスキーマであり、スキーマ要素としてCustResponseが選択されています。

20. 「OK」をクリックします。

「URL」フィールドと「スキーマ要素」フィールドに値が入力されます(この例ではそれぞれBook1_6.xsdとCustResponse)。

21. 「次へ」をクリックします。

22. 「終了」をクリックします。

「パートナ・リンク」ダイアログが再び表示されます。その他すべてのフィールドには値が自動的に入力されます。ダイアログは表9-8 のようになります。

表9-8 「パートナ・リンク」ダイアログのフィールドと値

フィールド

値

名前

ThirdReceive

WSDL URL

directory_path/ThirdFileRead.wsdl

パートナ・リンク・タイプ

Read2_plt

パートナ・ロール

指定しません。

マイ・ロール

Read2_role

23. 「OK」をクリックします。

9.2.2.3 ステップ3: 3つのreceiveアクティビティの作成

次に、3つのreceiveアクティビティ(各パートナ・リンクにつき1つずつ)を作成します。receiveアクティビティでは、情報の送信元のパートナ・リンクを指定します。

9.2.2.3.1 最初のreceiveアクティビティの作成

最初のreceiveアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. デザイナの「receiveInput」receiveアクティビティの下に、「Receive」アクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティをクリックして、そのプロパティ・フィールドをプロパティ・インスペクタで表示するか、「Receive」アイコンをダブルクリックし、「Receive」ダイアログを表示します。

アクティビティをプロパティ・インスペクタで編集する方法の詳細は、「BPELアクティビティをプロパティ・インスペクタで編集する方法」を参照してください。

4. 表9-9 に示す詳細を入力して、最初のパートナ・リンク(FirstReceive)を最初のreceiveアクティビティと関連付けます。

表9-9 「Receive」ダイアログのフィールドと値

フィールド

値

名前

receiveFirst

パートナ・リンク

FirstReceive

インスタンスの作成

このチェック・ボックスを選択します。

「操作」(Read)フィールドは自動的に入力されます。

5. 「変数」フィールドの右側にある最初のアイコンをクリックします。これは、変数を自動作成するアイコンです。

6. 「変数の作成」ダイアログで「OK」をクリックします。

receiveFirst_Read_InputVariableという名前の変数が自動的に「変数」フィールドに作成されます。

7. 手順4の説明に従って「インスタンスの作成」チェック・ボックスが選択されていることを確認します。

8. 「OK」をクリックします。

9.2.2.3.2 2番目のreceiveアクティビティの作成

2番目のreceiveアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウから、2番目のreceiveアクティビティを「receiveFirst」receiveアクティビティの下にドラッグします。

2. 「Receive」アイコンをダブルクリックし、「Receive」ダイアログを表示します。

3. 表9-10 に示す詳細を入力して、2番目のパートナ・リンク(SecondReceive)を2番目のreceiveアクティビティと関連付けます。

表9-10 「Receive」ダイアログのフィールドと値

フィールド

値

名前

receiveSecond

パートナ・リンク

SecondFileRead

インスタンスの作成

このチェック・ボックスは選択しないでください。

「操作」(Read1)フィールドは自動的に入力されます。

4. 「変数」フィールドの右側にある最初のアイコンをクリックします。

5. 「変数の作成」ダイアログで「OK」をクリックします。

receiveSecond_Read1_InputVariableという名前の変数が自動的に「変数」フィールドに作成されます。

6. 「OK」をクリックします。

9.2.2.3.2.1 3番目のreceiveアクティビティの作成

3番目のreceiveアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウから、3番目のreceiveアクティビティを「receiveSecond」receiveアクティビティの下にドラッグします。

2. 「Receive」アイコンをダブルクリックし、「Receive」ダイアログを表示します。

3. 表9-11 に示す詳細を入力して、3番目のパートナ・リンク(ThirdReceive)を3番目のreceiveアクティビティと関連付けます。

表9-11 「Receive」ダイアログのフィールドと値

フィールド

値

名前

receiveThird

パートナ・リンク

ThirdFileRead

インスタンスの作成

このチェック・ボックスは選択しないでください。

「操作」(Read2)フィールドは自動的に入力されます。

4. 「変数」フィールドの右側にある最初のアイコンをクリックします。

5. 「変数の作成」ダイアログで「OK」をクリックします。

receiveThird_Read2_InputVariableという名前の変数が自動的に「変数」フィールドに作成されます。

6. 「OK」をクリックします。

各receiveアクティビティが、特定のパートナ・リンクに関連付けられました。

9.2.2.4 ステップ4: 相関セットの作成

次に、相関セットを作成します。相関トークンのセットは、相関グループのすべてのメッセージで共有されるプロパティのセットです。

9.2.2.4.1 最初の相関セットの作成

最初の相関セットを作成する手順は、次のとおりです。

1. Oracle JDeveloperの「構造」ウィンドウで「相関セット」を右クリックし、「すべての子ノードを開く」を選択します。

2. 2番目の「相関セット」フォルダを右クリックして、「相関セットの作成」を選択します。

3. 「相関セットの作成」ダイアログの「名前」フィールドでCorrelationSet1と入力します。

4. 「プロパティ」セクションで、「追加」アイコンをクリックして「プロパティ・チューザ」ダイアログを表示します。

5. 「プロパティ」を選択し、「追加」アイコン(上の最初のアイコン)をクリックして「プロパティの作成」ダイアログを表示します。

6. 「名前」フィールドに、NameCorrと入力します。

7. 「タイプ」フィールドの右側にある「参照」アイコンをクリックします。

8. 「タイプ・チューザ」ダイアログで「string」を選択し、「OK」をクリックします。

9. 各ダイアログで、「OK」をクリックして、「プロパティの作成」ダイアログ、「プロパティ・チューザ」ダイアログおよび「相関セットの作成」ダイアログを閉じます。

9.2.2.4.2 2番目の相関セットの作成

2番目の相関セットを作成する手順は、次のとおりです。

1. Oracle JDeveloperの「構造」ウィンドウの「相関セット」セクションに戻ります。

2. 「相関セット」フォルダを右クリックして、「相関セットの作成」を選択します。

3. 「相関セットの作成」ダイアログの「名前」フィールドでCorrelationSet2と入力します。

4. 「プロパティ」セクションで、「追加」アイコンをクリックして「プロパティ・チューザ」ダイアログを表示します。

5. 「プロパティ」を選択し、「追加」アイコンをクリックして「プロパティの作成」ダイアログを表示します。

6. 「名前」フィールドに、IDCorrと入力します。

7. 「タイプ」フィールドの右側にある「参照」アイコンをクリックします。

8. 「タイプ・チューザ」ダイアログで「double」を選択し、「OK」をクリックします。

9. 各ダイアログで、「OK」をクリックして、「プロパティの作成」ダイアログ、「プロパティ・チューザ」ダイアログおよび「相関セットの作成」ダイアログを閉じます。

9.2.2.5 ステップ5: 相関セットとreceiveアクティビティの関連付け

次に、相関セットをreceiveアクティビティと関連付けます。次の相関セットのタスクを実行します。

- 最初の相関グループで、最初と2番目のreceiveアクティビティをCorrelationSet1相関セットと関連付けます。

- 2番目の相関グループで、2番目と3番目のreceiveアクティビティをCorrelationSet2相関セットと関連付けます。

9.2.2.5.1 最初の相関セットのreceiveアクティビティへの関連付け

最初の相関セットをreceiveアクティビティに関連付ける手順は、次のとおりです。

1. 「receiveFirst」receiveアクティビティをダブルクリックし、「Receive」ダイアログを表示します。

2. 「相関」タブをクリックします。

3. 「追加」アイコンをクリックして、「相関セット」ドロップダウン・リストを表示します。

4. 「CorrelationSet1」を選択します。

5. 「開始」列をクリックしてドロップダウン・リストを表示し、「はい」を選択します。「はい」に設定すると、このセットが、交換するメッセージに含まれるプロパティの値で開始されます。

6. 「OK」をクリックします。

9.2.2.5.2 2番目の相関セットのreceiveアクティビティへの関連付け

2番目の相関セットをreceiveアクティビティに関連付ける手順は、次のとおりです。

1. 「receiveSecond」receiveアクティビティをダブルクリックし、「Receive」ダイアログを表示します。

2. 「相関」タブをクリックします。

3. 「追加」アイコンをクリックして、「相関セット」ドロップダウン・リストを表示します。

4. 「CorrelationSet2」を選択し、次に「OK」をクリックします。

5. 「開始」列をクリックしてドロップダウン・リストを表示し、「はい」を選択します。

6. 「追加」を再度クリックし、「CorrelationSet1」を選択します。

7. 「OK」をクリックします。

8. 「開始」列をクリックしてドロップダウン・リストを表示し、「CorrelationSet1」で「いいえ」を選択します。

9. 「OK」をクリックします。

これにより、最初と2番目のreceiveアクティビティが1つの相関グループにまとめられます。

9.2.2.5.3 3番目の相関セットのreceiveアクティビティへの関連付け

3番目の相関セットをreceiveアクティビティに関連付ける手順は、次のとおりです。

1. 「receiveThird」receiveアクティビティをダブルクリックし、「Receive」ダイアログを表示します。

2. 「相関」タブをクリックします。

3. 「追加」アイコンをクリックします。

4. 「CorrelationSet2」を選択します。

5. CorrelationSet2の「開始」列を「いいえ」に設定します。

6. 「OK」をクリックします。

これにより、2番目と3番目のreceiveアクティビティが2番目の相関グループにまとめられます。

9.2.2.6 ステップ6: プロパティ・エイリアスの作成

プロパティ・エイリアスを使用すると、グローバル・プロパティを特定のメッセージ・パートのフィールドにマップできます。このアクションにより、プロパティ名を、メッセージのパートと場所を表すエイリアスにできます。このエイリアスは、XPath式で使用できます。

9.2.2.6.1 NameCorrのプロパティ・エイリアスの作成

NameCorr相関セットに次の2つのプロパティ・エイリアスを作成します。

- NameCorrをreceiveFirst receiveアクティビティのLoanApplメッセージ・タイプ・パートにマップします。このreceiveアクティビティをFirstReceiveパートナ・リンク(FirstReceive.wsdlファイルで定義)と関連付けます。

- NameCorrをreceiveSecond receiveアクティビティの受信メッセージ・タイプ・パートLoanAppResponseにマップします。このreceiveアクティビティをSecondReceiveパートナ・リンク(SecondFileRead.wsdlファイルで定義)と関連付けます。

NameCorrのプロパティ・エイリアスを作成する手順は、次のとおりです。

1. Oracle JDeveloperの「構造」ウィンドウで、「プロパティ・エイリアス」を右クリックします。

2. 「プロパティ・エイリアスの作成」を選択します。

3. 「プロパティ」リストから「NameCorr」を選択します。

4. 「メッセージ・タイプ」→「パートナ・リンク」→「FirstReceive」→「FirstReceive.wsdl」→「メッセージ・タイプ」→「LoanAppl_msg」→「Part - LoanAppl」の順に展開して選択します。

5. 「問合せ」フィールドで[Ctrl]を押しながら[Space]を押して、次のXPath式を定義します。

/ns2:LoanAppl/ns2:Name

6. 「OK」をクリックします。

7. ステップ1から3を繰り返して、NameCorrの2番目のプロパティ・エイリアスを作成します。

8. 「メッセージ・タイプ」→「プロジェクトのWSDLファイル」→「SecondFileRead.wsdl」→「メッセージ・タイプ」→「LoanAppResponse_msg」→「Part - LoanAppResponse」の順に展開して選択します。

9. 「問合せ」フィールドで[Ctrl]を押しながら[Space]を押して、次のXPath式を定義します。

/ns4:LoanAppResponse/ns4:APR

10. 「OK」をクリックします。

9.2.2.6.2 IDCorrのプロパティ・エイリアスの作成

IDCorr相関セットに次の2つのプロパティ・エイリアスを作成します。

- IDCorrをreceiveSecond receiveアクティビティのLoanAppResponseメッセージ・タイプ・パートにマップします。このreceiveアクティビティをSecondReceiveパートナ・リンク(SecondFileRead.wsdlファイルで定義)と関連付けます。

- IDCorrをreceiveThird receiveアクティビティのCustResponseメッセージ・タイプ・パートにマップします。このreceiveアクティビティをThirdReceiveパートナ・リンク(ThirdFileRead.wsdlファイルで定義)と関連付けます。

IDCorrのプロパティ・エイリアスを作成する手順は、次のとおりです。

1. 「構造」ウィンドウで、「プロパティ・エイリアス」を右クリックします。

2. 「プロパティ・エイリアスの作成」を選択します。

3. 「プロパティ」リストから「IDCorr」を選択します。

4. 「メッセージ・タイプ」→「プロジェクトのWSDLファイル」→「SecondFileRead.wsdl」→「メッセージ・タイプ」→「LoanAppResponse_msg」→「Part - LoanAppResponse」の順に展開して選択します。

5. 「問合せ」フィールドで[Ctrl]を押しながら[Space]を押して、次のXPath式を定義します。

/ns4:LoanAppResponse/ns4:APR

6. 「OK」をクリックします。

7. ステップ1から3を繰り返して、IDCorrの2番目のプロパティ・エイリアスを作成します。

8. 「メッセージ・タイプ」→「プロジェクトのWSDLファイル」→「ThirdFileRead.wsdl」→「メッセージ・タイプ」→「CustResponse_msg」→「Part - CustResponse」の順に展開して選択します。

9. 「問合せ」フィールドで[Ctrl]を押しながら[Space]を押して、次のXPath式を定義します。

/ns6:CustResponse/ns6:APR

これで、設計は完了します。

10. 「OK」をクリックします。

9.2.2.7 ステップ7: WSDLファイルのコンテンツの確認

WSDLファイルのコンテンツを確認する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウをリフレッシュします。

相関セット・プロパティのNameCorrおよびIDCorrは、「アプリケーション」ウィンドウのMyCorrelationSet_Properties.wsdlファイルに定義されています。

<definitions
name="properties"
targetNamespace="http://xmlns.oracle.com/MyCorrelationSet/correlationset"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<bpws:property name="NameCorr" type="xsd:string"/>
<bpws:property name="IDCorr" type="xsd:double"/>
</definitions>

プロパティ・エイリアスは、MyCorrelationSet.wsdlファイルに定義されています。

<bpws:propertyAlias propertyName="ns1:NameCorr"
messageType="ns3:LoanAppl_msg"
part="LoanAppl" query="/ns2:LoanAppl/ns2:Name"/>

<bpws:propertyAlias propertyName="ns1:NameCorr"
messageType="ns5:LoanAppResponse_msg"
part="LoanAppResponse" query="/ns4:LoanAppResponse/ns4:APR"/>

<bpws:propertyAlias propertyName="ns1:IDCorr"
messageType="ns5:LoanAppResponse_msg"
part="LoanAppResponse" query="/ns4:LoanAppResponse/ns4:APR"/>

<bpws:propertyAlias propertyName="ns1:IDCorr"
messageType="ns7:CustResponse_msg"
part="CustResponse" query="/ns6:CustResponse/ns6:APR"/>

この例では、BPELプロセス・サービス・コンポーネントはWebサービス・プロバイダとしては作成されていないので、MyCorrelationSet.wsdlファイルはBPELプロセス・サービス・コンポーネントでは参照されません。このため、旧WSDLに定義されている相関セットを参照するには、MyCorrelationSet.wsdlファイルをFirstReceive.wsdlファイル内にインポートする必要があります。

<import namespace="http://xmlns.oracle.com/MyCorrelationSet"
location="MyCorrelationSet.wsdl"/>

9.2.3 変換IDおよび異なるコンポジット・リビジョンに関する必知事項

SOAコンポジット・アプリケーションの違うリビジョンに同じ変換IDを使用しないでください。BPELプロセスで相関セットを使用する場合は、ユーザーが明示的に対話IDの値を管理します。対話IDの値の生成に関して、Oracle SOA Suiteによって妨害や制約が追加されることはありません。これは、Oracle SOA Suiteで違うリビジョンに対して同じ対話IDが生成されているように見えても、実際はユーザーがこの動作を管理するということを意味します。Oracle SOA Suiteでは、異なるリビジョンの別々のインスタンスに対して同じ対話IDを使用することに対する制限はありません。

相関セットを使用しない場合は、生成される対話IDはユーザーではなく、Oracle SOA Suiteによって決定されるため、生成される対話IDは一意になるので問題はありません。

Oracle SOA Suiteでは、コールバック・ルーティングでリビジョンのチェックは実行されません。コールバック・メッセージのルーティングは、次の情報にのみ基づきます。

- 対話ID: これは、入力値と相関セットに基づいて計算されます。プロセスの2つのリビジョンに同じ相関セットを使用し、インスタンスの作成時に同じ入力値を入力した場合は、両方のリビジョンとも同じ対話IDを使用してサブスクライブされます。この場合、あるリビジョンに対するコールバックが別のリビジョンに配信される場合に混乱が発生します。

- 操作名(両方のリビジョンで同じです)。

- BPELサービス・コンポーネント名(これも、両方のリビジョンで同じです)。

リビジョン番号の概念は、Oracle SOAコンポジット・アプリケーションには適用可能ですが、BPEL仕様には含まれていません。このため、ルーティングを決定するための要素としては使用されません。

また、コールバックのルーティングの一部としてリビジョンを追加すると、別の問題を引き起こす原因となります。コールバックを送信する場合は、エンドポイントURLも指定します。エンドポイントURLにコンポジット・リビジョンが含まれていない場合(非常に可能性は高い)、メッセージのルーティング先はデフォルトのリビジョンであると判断されます。もしOracle SOA Suiteの実行時にコールバック・ルーティングの一部としてリビジョンのチェックを追加すると、デフォルト以外のリビジョンのインスタンスに対してはコールバックを送信できなくなります。

たとえば、次のBPELプロセスがあるとします。

- receive_1という名前のreceiveアクティビティのエントリ(相関セットを使用)

- Webサービスを起動するinvokeアクティビティ

- receive_2という名前のreceiveアクティビティ

次の手順を実行すると仮定します。

1. BPELコンポーネントが含まれているcomposite_Aのリビジョン1.0をデプロイします。

2. 相関セットを使用しているリビジョン1.0のインスタンスを作成し、値に123と入力し、その結果conv_id = "123"が生成されます。
このタイミングで、このプロセスは一方向のinvokeアクティビティを介してWebサービスを起動し、receive_2アクティビティでコールバックの着信を待機します。

3. composite_Aのリビジョン2.0をデプロイし、その結果、2.0がデフォルトのリビジョンになります。
Webサービスは、リビジョン1.0のインスタンスに対してコールバックを送信します。しかし、URLの中でリビジョン番号は指定されていません。通常、ユーザーは、URLにリビジョン番号を使用しないようにコールバックを作成しています。これは、Webサービスは外部のものであるため、継続的にリビジョン・タグを使用するようにWebサービスの設定を変更できないからです。なぜならば、リビジョン・タグはOracle SOA Suite内部の仕様で、外部では認識できない概念であるからです。

リビジョン番号が指定されていないため、SOAサーバーではリビジョン番号が2.0であるとみなされるので、もしコールバックのルーティングにリビジョン番号を考慮した場合は、1.0が宛先であるこのコールバックを正しいリビジョンの1.0に転送できません。かわりに、2.0のデフォルトのリビジョンにルーティングしようとしますが、コールバックを待機している2.0のインスタンスは存在しません。

ユーザーは、リビジョンに基づいてコールバック・メッセージをルーティングすることはできません。コールバック・メッセージのルーティングの基準に使用可能なオプションは、変換ID (相関セットを使用しない場合は、これも使用不可)、操作名およびコンポーネント名のみです。

このような理由から、異なるインスタンスには別々の対話IDを使用して(つまり、変換IDの作成のための入力値には異なる値を使用して)混乱を回避し、ルーティングが対話IDのみに基づいて行われるようにする必要があります。

9.2.4 複数のパートを持つfromParts要素を使用したIMAの相関の設定に関する必知事項

次の使用例を考えてみます。

- タイプが同じ複数のパートを持つWSDLメッセージ・タイプのBPEL 2.0プロセス

- 前述のパートの要素タイプに基づいて定義されているプロパティ・エイリアス

各パートに対して定義されたfromPartsを持つfromParts要素を使用するインバウンド・メッセージ・アクティビティ(IMA) (receiveアクティビティ、scopeまたはpickアクティビティのonMessageブランチ、BPEL 2.0のscopeアクティビティのonEventブランチなど)を持つプロセスの場合、ランタイム環境でプロパティ・エイリアスが適用されるパートを判断できないため、相関を定義できません。

toParts要素およびfromParts要素を使用してWSDLメッセージ・パートをマッピングする方法の詳細は、「BPEL 2.0でのWSDLメッセージ・パートのマップ」を参照してください。

9.3 同じインスタンスへのメッセージのルーティング

Oracle BPEL Process Managerでは、メッセージ集約機能がサポートされています。複数のメッセージが同じプロセス/パートナ・リンク/操作名にルーティングされる場合、最初のメッセージは新規インスタンスを作成するためにルーティングされ、後続のメッセージは中間プロセスのreceiveアクティビティを使用して作成されたインスタンスを続行するためにルーティングできます。

メッセージ集約を使用すると、同じ操作(またはイベント名)をreceiveアクティビティのエントリおよび中間プロセスのreceiveアクティビティで使用できます。

注意:

- この機能では集約のみが実行され、再順序付けは行われません。この機能は、正しくない順序で受信されるメッセージを適切な順序の形式になるよう再順序付けを行いません。したがって、最初のメッセージとは、単に処理された最初のメッセージを意味します。これは、時間順での最初のメッセージとは異なる場合があります。

- メッセージ集約機能を活用するには、相関セットを使用する必要があります。

- あいまいなコール(最初のreceiveアクティビティと中間プロセスのreceiveアクティビティの両方における)としての同期操作がサポートされています。ただし、これはこの機能の推奨される用途ではないため、使用しないようにしてください。

9.3.1 BPELプロセス・インスタンス作成の構成方法

reenableAggregationOnCompleteプロパティを使用して、メッセージをルーティングするために作成して使用するインスタンス数を制御できます。

BPELプロセス・インスタンス作成を構成する手順は、次のとおりです。

1. SOAコンポジット・エディタで、図9-16 に示すように、BPELプロセス・サービス・コンポーネントを選択します。

図9-16 選択されたBPELプロセス・サービス・コンポーネント

2. Oracle JDeveloperの右下の隅にある「プロパティ・インスペクタ」に移動します。「プロパティ・インスペクタ」が表示されない場合は、「表示」メイン・メニューから「プロパティ・インスペクタ」を選択します。

3. 図9-17 に示すように、「プロパティ」セクションで「追加」アイコンをクリックします。

図9-17 プロパティ・インスペクタ

「プロパティの作成」ダイアログが表示されます。

4. 「名前」フィールドで、bpel.config.reenableAggregationOnCompleteデプロイメント・ディスクリプタのプロパティを入力します。このタイプのデプロイメント・ディスクリプタには、接頭辞bpel.configが必要です。

5. 「値」フィールドで、表9-12 の説明に従ってtrueと入力します。

表9-12 reenableAggregationOnCompleteプロパティ設定

値

説明

例

true

メッセージを処理する新規インスタンスが作成されます。ただし、メッセージの受信からインスタンスの完了までの間に、1つのウィンドウが表示されます。これにより、メッセージがDLV_MESSAGE表に残される場合があります。この設定により、競合状態が発生する場合があります。詳細は、表9-13 を参照してください。

initiate操作を使用して、クライアントに対してメッセージ1から4を起動します。これにより、次のアクションが発生します。

- BPELプロセスの2つのインスタンスが作成されて完了されます。

- メッセージ1と2は最初のインスタンスに、メッセージ3と4は2番目のインスタンスにルーティングされます。

false

これはデフォルトの動作です。この設定により、集約機能が無効化されます。作成されるインスタンスは1つのみです。インスタンスによって処理されないメッセージは、DLV_MESSAGE表に残されます。ほとんどの環境で、この設定を使用することをお薦めします。

initiate操作を使用して、クライアントに対してメッセージ1から4を起動します。BPELプロセスの1つのインスタンスが作成されて完了されます。

同じ相関セットを使用する複数のメッセージを1つのBPELインスタンスにルーティングしないようにしてください。

図9-18 は、完成した「プロパティの作成」ダイアログを示しています。

図9-18 「プロパティの作成」ダイアログ

6. 「OK」をクリックします。

composite.xmlファイル内のbpel.config接頭辞が付いたreenableAggregationOnCompleteプロパティは、次のようになります。

<composite name="Aggregation" revision="1.0" label="2011-07-10_13-52-24_174"
mode="active" state="on">
. . .
. . .
<component name="Aggregation" version="1.1">
<implementation.bpel src="Aggregation.bpel"/>
<property name="bpel.config.reenableAggregationOnComplete" type="xs:string"
many="false" override="may">true</property>
</component>
. . .
. . .
</composite>

9.3.2 receiveアクティビティのエントリと中間プロセスのreceiveアクティビティで同じ操作を使用する方法

次の例に示すように、相関セットを作成するとします。Oracle BPEL Process Managerに対するすべてのメッセージは、同じ操作名にルーティングされます。メッセージの相関IDは同じとなります。インタフェースWSDLでは、アクティビティのエントリ(receiveInput)と中間プロセスのreceiveアクティビティ(Continue_Receive)が区別されません。すべてのメッセージはinitiate操作を使用して処理されます。すべてのメッセージをルーティングするシングル・インスタンスが作成されます。

このことは、同じパートナ・リンクについて異なる操作名を定義する必要があった11g リリース1 11.1.1.6より前のリリースとは異なります。プロセスで2つの操作を公開する必要があり、コール元で適切な操作名を選択する必要がありました。

<receive name="receiveInput" partnerLink="client" portType="client:BPELProcess1"
operation="initiate" variable="inputVariable" createInstance="yes">
<correlations>
<correlation initiate="yes" set="CorrelationSet_1"/>
</correlations>
</receive>

<!-- Asynchronous callback to the requester. (Note: the callback location and
correlation id is transparently handled using WS-addressing.) -->
<assign name="Assign_1">
<copy>
<from variable="inputVariable" part="payload"
query="/client:BPELProcess1ProcessRequest/client:input"/>
<to variable="Invoke_1_initiate_InputVariable" part="payload"
query="/ns1:BPELProcess2ProcessRequest/ns1:input"/>
</copy>
</assign>

<receive name="Continue_Receive" partnerLink="client"
portType="client:BPELProcess1" operation="initiate" variable="inputVariable"
createInstance="no">
<correlations>
<correlation initiate="no" set="CorrelationSet_1"/>
</correlations>
</receive>

イベント配信ネットワーク(EDN)のビジネス・イベントの場合、receiveアクティビティのエントリと中間プロセスのreceiveアクティビティの両方で、operation属性をbpelx:eventNameに置換します。

bpelx:eventName="ns3:initiateEvent"/>

次の情報が、DLV_AGGREGATION表に保持されます。

- 対話ID

- ドメイン名

- コンポーネント名とタイプ

- コンポジット名、ラベルおよびリビジョン

- 状態

- 受信日

- CIキー

- 主キー

この情報は、パージ・スクリプトを使用してこの表から、またはOracle Enterprise Manager Fusion Middleware Controlの「自動パージ」ページから削除できます。これらのオプションの両方の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

9.3.3 相関セット使用時の新規インスタンスまたは既存インスタンスへのメッセージのルーティング方法

相関セットを使用したBPELプロセスでは、適切なルーティングが実行されます。メッセージは次のいずれかとなる可能性があります。

- 新しいインスタンスを作成する起動メッセージ

- 既存のインスタンスを続行するコールバック・メッセージ

図9-19 に、同じ操作(process)を使用したreceiveアクティビティのエントリと中間プロセスのreceiveアクティビティを示します。

図9-19 新規インスタンスまたは既存インスタンスへの新規メッセージのルーティング

次の例に、同じ操作(process)を使用したreceiveアクティビティのエントリと中間プロセスのreceiveアクティビティの例を示します。

<receive name="receiveInput" partnerLink="client" portType="client:BPELProcess1"
operation="process" variable="inputVariable" createInstance="yes">
<correlations>
<correlation initiate="yes" set="CorrelationSet_1"/>
</correlations>
</receive>

<!-- some business logic -->

<while name="While_1" condition=*loop for 3 iterations*>
<sequence name="Sequence_1">
<receive name="Continue_Receive" partnerLink="client"
portType="client:BPELProcess1" operation="process" variable="inputVariable"
createInstance="no">
<correlations>
<correlation initiate="no" set="CorrelationSet_1"/>
</correlations>
</receive>

<!-- some business logic -->

</sequence>
</while>

前の例の初期のシナリオでは、次のアクションがBPELプロセスP1で発生します。

- パートナによって、4つのメッセージ(メッセージ1、メッセージ2、メッセージ3およびメッセージ4)が同じパートナ(相関ID 101)に対して提供されます。

- メッセージ1によって、BPELプロセスP1の新しいインスタンスが作成されます。このメッセージは起動メッセージとしてマークされます。

- メッセージ2、3および4は、Continue_Receiveアクティビティを使用して受信されます。これらのメッセージはコールバック・メッセージとしてマークされます。

- whileループが3回反復されることが想定されるため、インスタンスが閉じます。

ここで、追加メッセージがルーティングされ、これにより、競合状態が発生する可能性があると想定します。表9-13に詳細を示します。

表9-13 メッセージ配信シナリオ

シナリオ

説明

起動メッセージとしてマーク

コールバック・メッセージとしてマーク

1

ここで、パートナによって、同じ相関ID (101)に対してメッセージ5が提供されると想定します。メッセージ5はBPELプロセスP1の新しいインスタンスを作成し、whileループ内のContinue_Receiveアクティビティで3つの追加メッセージ(6、7および8)を待機します。

- メッセージ1

- メッセージ5

- メッセージ2

- メッセージ3

- メッセージ4

- メッセージ6

- メッセージ7

- メッセージ8

2

メッセージ4と5が短い時間ウィンドウ内で受信される場合、メッセージ4によってインスタンスBPELプロセスP1が閉じ、メッセージ5がこのインスタンスへのコールバックとしてルーティングされる場合があります。このシナリオによって競合状態が発生する場合があります。次に例を示します。

- メッセージ6が到着すると、新しいインスタンスのreceiveアクティビティのエントリにルーティングされます。

- メッセージ7および8が、Continue_Receiveアクティビティにルーティングされます。

- メッセージ5は、BPELプロセス・サービス・エンジンのリカバリ部分によってのみContinue_Receiveアクティビティにルーティングされます。これは、クローズされたインスタンスに最初にルーティングされ、処理できなかったためです。

- メッセージ1

- メッセージ6

- メッセージ2

- メッセージ3

- メッセージ4

- メッセージ5

- メッセージ7

- メッセージ8

3

これはシナリオ2に類似しています。ただし、この場合、メッセージ7、8および9は受信されません。次に例を示します。

- メッセージ5は、サブスクライバを待機する、未処理のコールバック・メッセージとなります。

- BPELプロセス・サービス・エンジンのリカバリにより、メッセージ5の処理が試行され、使用可能なサブスクライバが存在しないため失敗します。

メッセージ・リカバリにはいくつかのオプションがあります。

- Oracle Enterprise Manager Fusion Middleware Controlの「システムMBeanブラウザ」プロパティmaxRecoverAttemptを使用したコールバック・メッセージのリカバリ制限。この数によって、起動メッセージやコールバック・メッセージをリカバリするための自動リカバリによる試行回数が指定されます。リカバリ試行回数がこの数を超えると、メッセージの状態は「消耗済」に変更されます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の起動メッセージおよびコールバック・メッセージに対する自動リカバリ試行の構成に関する項を参照してください。

- カスタムSQLスクリプトを記述して、criteriaCallbackのstateが0に設定されていることを確認します。このコールバックの相関値は、クローズされた状態(state = 0)でCORRELATION_GROUPに存在します。これは、コールバック・メッセージにクローズされた集約インスタンスのマークが付けられていることを示しています。ビジネス・ロジックに基づいて、これらのインスタンスの取消しやパージを行うことができます。
注意: BPELは、対話ベースのシステムとして設計されています。未承諾メッセージが処理されていないときは、アプリケーションでは、相関集約の一部として常に受信メッセージを考慮し、ビジネス・ニーズに応じて、メッセージをサブスクライブして処理するか、または無視するかを選択します。

- メッセージ1

- メッセージ6

- メッセージ2

- メッセージ3

- メッセージ4

- メッセージ5

10 BPELプロセスでのパラレル・フローの使用

この章では、BPELプロセス・サービス・コンポーネントでのパラレル・フローの使用方法について説明します。パラレル・フローを使用すると、BPELプロセス・サービス・コンポーネントで複数のタスクを同時に実行できます。パラレル・フローは、時間を要する独立した複数のタスクを実行する必要がある場合に特に役立ちます。この章では、パラレル・ブランチの数をカスタマイズする方法についても説明します。

この章の内容は次のとおりです。

- BPELプロセスでのパラレル・フローの概要

- パラレル・フローの作成

- パラレル・ブランチ数のカスタマイズ

10.1 BPELプロセスでのパラレル・フローの概要

BPELプロセスでは、複数の非同期ソースからの情報の収集が必要になる場合があります。各コールバックに要する時間(時間数または日数)は明らかでないため、各サービスを一度に1つずつコールするのでは時間がかかりすぎることがあります。複数のコールを1つのパラレル・フローに分解することにより、BPELプロセス・サービス・コンポーネントは複数のWebサービスを同時に起動し、レスポンスが到着するたびに受信できます。この方法は時間の節約に効果的です。

図10-1 は、名前がRetrieve_QuotesFromSuppliersであるflowアクティビティを示します。「Retrieve_QuotesFromSuppliers」flowアクティビティは、次の2つのサプライヤに注文情報をパラレルで送信します。

- 社内倉庫(InternalWarehouseService)

- 外部パートナ倉庫(PartnerSupplierMediator)

2つの倉庫は、注文に対する入札をflowアクティビティに返します。ここでは、2つの非同期コールバックがパラレルで実行されます。一方のコールバックは、もう一方のコールバックが先に完了するまで待機する必要がありません。各レスポンスは異なるグローバル変数に格納されます。

図10-1 パラレル・フローの起動

10.1.1 シングル・スレッドでのフローのブランチのパラレル実行に関する必知事項

シングル・スレッドではflow、flowNおよびforEachアクティビティ内のブランチはシリアルで実行されます(つまり、N番目のブランチは、N-1の実行が完了した後にのみ実行されます)。実行は完全なパラレルではありません。これは、このモードでは、ブランチは複数の並行スレッドで実行されないためです。そのかわり、1つのスレッドでフローのブランチの実行が開始され、ブロック・アクティビティ(たとえば、同期のinvokeなど)に到達するまで続行されます。このときは、新しいスレッドが作成されて他のブランチの実行が開始され、プロセスは続行されます。このため、フローのブランチはパラレルで実行されている印象を受けます。このモードでは、フローのブランチにブロック・アクティビティが定義されていない場合、ブランチはやはりシリアルで実行されます。

この設計は、いくつかの理由に基づいてこのようになっています。

- 誤ってスレッドを多く生成しすぎてシステムが高負荷状態になることがないように、シングル・スレッド処理がデフォルトの方式になっています。ただし、アダプタ・ポーリング・スレッド、BPELプロセスのサービス・エンジン・スレッド、Oracle WebLogic Serverのワーク・マネージャなど、他の場所ではスレッドをチューニングできます。

- BPELプロセスの仕様では、純粋なマルチスレッド・プログラミングに必要なBPEL変数のスレッド・セーフティが保証されるメカニズムは提供されていません(つまり、Javaなどにおける同期修飾子がサポートされていません)。

- ブランチの1つでのトランザクションのロールバックの実装は定義されていません。

疑似的なパラレル処理を実現するには、デプロイメント・ディスクリプタのプロパティnonBlockingInvokeを使用して、invokeアクティビティをブロックしないように構成できます。このプロパティをtrueに設定すると、各ブランチのinvokeアクティビティをパラレルで実行するための新しいスレッドが作成されます。

nonBlockingInvokeプロパティの詳細は、「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。

10.2 パラレル・フローの作成

BPELプロセス・サービス・コンポーネントにパラレル・フローを作成するには、flowアクティビティを使用します。flowアクティビティを使用すると、1つ以上のアクティビティを同時に実行するように指定できます。flowアクティビティは同期性も備えています。flowアクティビティは、フロー内のすべてのアクティビティが処理を終了したときに完了します。このアクティビティが完了しても、許可条件がfalseの場合はスキップされている可能性があります。

注意:

flowアクティビティ内のブランチは、シングル・スレッドでシリアルで実行されます。詳細は、「シングル・スレッドでのフローのブランチのパラレル実行に関する必知事項」を参照してください。

10.2.1 パラレル・フローの作成方法

パラレル・フローを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」→「構造化アクティビティ」を展開します。

2. flowアクティビティをデザイナにドラッグします。

3. 図10-2 に示すように、+記号をクリックしてflowアクティビティを開きます。

図10-2 flowアクティビティ

flowアクティビティには、最初に2つのブランチがあり、各ブランチには機能要素用のボックスがあります。これらのボックスにデータを移入するには、scopeアクティビティの場合のように、機能を作成するか、複数のアクティビティをボックスにドラッグします。flowアクティビティを強調表示し、「シーケンスの追加」アイコンをクリックすることで、ブランチを追加できます。図10-3に詳細を示します。

図10-3 「シーケンスの追加」アイコン

4. 複数のサービスを同時に起動するには、追加するアクティビティをflowの両側にドラッグして定義します。図10-4に詳細を示します。

図10-4 開いた状態のflowアクティビティ

完了すると、flowアクティビティの設計は図10-5 のようになります。この例は、「Retrieve_QuotesFromSuppliers」 flowアクティビティを示しています。入札を受け取るために、「InternalWarehouseService」および「PartnerSupplierMediator」の2つのブランチが定義されています。

図10-5 設計完了後のflowアクティビティ

10.2.2 パラレル・フロー作成時の処理内容

通常、flowアクティビティには多数のsequenceアクティビティが含まれています。各sequenceはパラレルに実行されます。次の例は、設計完了後のOrderProcessor.bpelファイルのRetrieve_QuotesFromSuppliers flowアクティビティに対してsequenceが2つある構文を示しています。ただし、flowアクティビティには多数のsequenceを指定できます。flowアクティビティには、他のアクティビティを含めることもできます。次の例では、flowの各sequenceにassign、invokeおよびreceiveアクティビティが含まれています。

<flow name="Retrieve_QuotesFromSuppliers">
<sequence name="Sequence_4">
<assign name="Assign_InternalWarehouseRequest">
<copy>
<from>$inputVariable.gOrderInfoVariable/ns3:CardNum</from>
<to>lInternalWarehouseInputVariable/ns4:ccnb</to>
</copy>
</assign>
<invoke name="Invoke_InternalWarehouse"
inputVariable="lInternalWarehouseInputVariable"
partnerLink="InternalWarehouseService"
portType="ns1:InternalWarehouseService"
operation="process"/>
<receive name="Receive_InternalWarehouse"
createInstance="no"
variable="lInternalWarehouseResponseVariable"
partnerLink="InternalWarehouseService"
portType="ns1:InternalWarehouseServiceCallback"
operation="processResponse"/>
<assign name="Assign_InterWHResponse">
<bpelx:append>
<bpelx:from variable="lInternalWarehouseResponseVariable"
part="payload"
query="/ns1:WarehouseResponse"/>
<bpelx:to variable="gWarehouseQuotes"
query="/ns1:WarehouseList"/>
</bpelx:append>
</assign>
</sequence>
<sequence name="Sequence_4">
<assign name="Assign_PartnerRequest">
<copy>
<from variable="gOrderInfoVariable"
query="/ns4:orderInfoVOSDO"/>
<to variable="lPartnerSupplierInputVariable"
part="request" query="/ns4:orderInfoVOSDO"/>
</copy>
</assign>
<invoke name="Invoke_PartnerSupplier"
partnerLink="PartnerSupplierMediator"
portType="ns15:execute_ptt" operation="execute"
inputVariable="lPartnerSupplierInputVariable"/>
<receive name="Receive_PartnerResponse"
createInstance="no"
variable="lPartnerResponseVariable"
partnerLink="PartnerSupplierMediator"
portType="ns15:callback_ptt" operation="callback"/>
<assign name="Assign_PartnerWHResponse">
<bpelx:append>
<bpelx:from variable="lPartnerResponseVariable"
part="callback"
query="/ns1:WarehouseResponse"/>
<bpelx:to variable="gWarehouseQuotes"
query="/ns1:WarehouseList"/>
</bpelx:append>
</assign>
</sequence>
</flow>

10.2.3 flowアクティビティ内のアクティビティ実行の同期化

flowアクティビティ内のアクティビティの実行を同期化すると、他のアクティビティが完了した後にのみ特定のアクティビティを実行できるようになります。たとえば、invokeアクティビティverifyFlightがあり、flowの開始時に他のinvokeアクティビティ(verifyHotel、verifyCarRentalおよびscheduleFlight)と並行して実行されると仮定します。ただし、フライトのスケジュールが必要なのは、フライトが使用可能であることを確認した後のみです。したがって、verifyFlight invokeアクティビティとscheduleFlight invokeアクティビティの間にリンクを追加できます。このリンクにより、リンクのターゲットであるアクティビティ(scheduleFlight)は、リンクのソースであるアクティビティ(verifyFlight)が完了した場合のみ実行されることを示す、依存関係のレベルが指定されます。

次の例に詳細を示します。リンク名verifyFlight-To-scheduleFlightは、ソースverifyFlight invokeアクティビティおよびターゲットscheduleFlight invokeアクティビティに割り当てられます。ソースverifyFlightの実行が完了した後、ターゲットscheduleFlightが実行されます。

<flow ...>
<links>
<link name="verifyFlight-To-scheduleFlight" />
</links>
<documentation>
Verify the availability of a flight, hotel, and rental car in parallel
</documentation>
<invoke name="verifyFlight" ...>
<sources>
<source linkName="verifyFlight-To-scheduleFlight" />
</sources>
</invoke>
<invoke name="verifyHotel" ... />
<invoke name="verifyCarRental" ... />
<invoke name="scheduleFlight" ...>
<targets>
<target linkName="verifyFlight-To-scheduleFlight" />
</targets>
</invoke>
</flow>

前の例は、BPELバージョン2.0におけるリンク構文の例を示しています。BPELバージョン1.1とBPELバージョン2.0では、リンク構文が若干異なります。

- BPELバージョン1.1では、<target>と<source>を使用します。

- BPELバージョン2.0では、<targets>と<sources>を使用します。

表10-1に詳細を示します。

表10-1 BPELバージョン1.1とBPELバージョン2.0のリンク構文

BPELバージョン1.1の例

BPELバージョン2.0の例

<flow>
<links>
<link name="XtoY"/>
<link name="CtoD"/>
</links>
<sequence name="X">
<source linkName="XtoY"/>
<invoke name="A" .../>
<invoke name="B" .../>
</sequence>
<sequence name"Y">
<target linkName="XtoY"/>
<receive name="C" ...>
<source linkName="CtoD"/>
</receive>
<invoke name="E" .../>
</sequence>
<invoke partnerLink="D" ...>
<target linkName="CtoD"/>
</invoke>
</flow>

<flow>
<links>
<link name="AtoB"/>
</links>
<assign name="B">
<targets>
<target linkName="AtoB"/>
</targets>
<copy>
<from>concat($output.payload,
'B')</from>
<to>$output.payload</to>
</copy>
</assign>
<assign name="A">
<sources>
<source linkName="AtoB"/>
</sources>
<copy>
<from>concat($output.payload,
'A')</from>
<to>$output.payload</to>
</copy>
</assign>
</flow>

10.2.4 flowアクティビティ内のアクティビティ間に同期を作成する方法

flowアクティビティ内のアクティビティ間に同期を作成する手順は、次のとおりです。

注意:

「ソース」タブおよび「ターゲット」タブは、BPEL 2.0プロジェクトでのみ使用できます。BPEL 1.1プロジェクトの場合、この機能を使用するには、BPELファイルを直接編集する必要があります。

1. flowアクティビティを作成します。詳細は、「パラレル・フローの作成方法」を参照してください。

2. flowアクティビティの「一般」タブで、「追加」アイコンをクリックします。

3. 図10-6 に示すように、リンクの名前を入力します。

図10-6 リンク名の作成

4. 「適用」をクリックし、「OK」をクリックします。

5. 適切なアクティビティをフロー・アクティビティにドラッグし、ステップ3で定義したのと同じリンク名でソースとして定義します。ソースとターゲットのリンク名の値は、フロー・アクティビティで宣言されているリンク名と同じである必要があります。この例では、Aという名前のassignアクティビティがソースとして定義されています(図10-7 )。

図10-7 ソース・アクティビティ

各ソース・アクティビティは、指定されたリンクをたどるための保護手段として、オプションの「遷移条件」を指定できます。この列の行をクリックして「ブラウザ」アイコンを呼び出し、「式ビルダー」ダイアログにアクセスするか、または条件を作成します。「遷移条件」列を空白のままにすると、trueと評価されると想定されます。

6. assignアクティビティの適切なコピー・ルールを定義します。

7. 「適用」をクリックし、「OK」をクリックします。

8. 追加のアクティビティをflowアクティビティにドラッグし、ステップ3で定義したのと同じリンク名を持つターゲットとして定義します。この例では、Bという名前の別のassignアクティビティが図10-8 でターゲットとして定義されています。

図10-8 ターゲット・アクティビティ

9. assignアクティビティの適切なコピー・ルールを定義します。

10. 「適用」をクリックし、「OK」をクリックします。

11. BPELプロセスの設計を続行します。

完了後、設計は図10-9 のようになります。

図10-9 リンクと同期された3つのflowアクティビティ

10.2.5 flowアクティビティ内のアクティビティ間に同期を作成するときの処理内容

次の例は、アクティビティ実行を同期化するためのリンクを持つ3つのflowアクティビティの設計が完了した後の.bpelファイルを示しています。

- Flow_1は、単純なアクティビティ間のリンクを示します。
Flow_1にはAtoBという名前のリンクが含まれています。リンクのターゲットであるアクティビティ(assignアクティビティB)は、リンクのソースであるアクティビティ(assignアクティビティA)が完了した場合のみ実行されます。

- Flow_2は、単純なアクティビティと複合アクティビティの間のリンクを示します。
Flow_2にはAtoBという名前のリンクも含まれています。リンクのターゲットであるアクティビティ(assignアクティビティB)は、リンクのソースであるアクティビティ(scopeアクティビティscope1)が完了した場合のみ実行されます。

- Flow_3は、複合アクティビティ間のリンクを示します。
Flow_3にはAtoBという名前のリンクも含まれています。リンクのターゲットであるアクティビティ(sequenceアクティビティSequence_1)は、リンクのソースであるアクティビティ(scopeアクティビティscope2)が完了した場合のみ実行されます。

<!-- link between simple activities -->
<flow name=Flow_1>
<links>
<link name="AtoB"/>
</links>
<assign name="A">
<sources>
<source linkName="AtoB"/>
</sources>
<copy>
<from>concat($output.payload, 'A')</from>
<to>$output.payload</to>
</copy>
</assign>
<assign name="B">
<targets>
<target linkName="AtoB"/>
</targets>
<copy>
<from>concat($output.payload, 'B')</from>
<to>$output.payload</to>
</copy>
</assign>
</flow>

<!-- link between simple activity and composite activity -->
<flow name=Flow_2>
<links>
<link name="AtoB"/>
</links>
<scope name="scope1">
<sources>
<source linkName="AtoB"/>
</sources>
<assign name="A">
<copy>
<from>concat($output.payload, 'A')</from>
<to>$output.payload</to>
</copy>
</assign>
</scope>
<assign name="B">
<targets>
<target linkName="AtoB"/>
</targets>
<copy>
<from>concat($output.payload, 'B')</from>
<to>$output.payload</to>
</copy>
</assign>
</flow>

<!-- link between composite activities -->
<flow name=Flow_3>
<links>
<link name="AtoB"/>
</links>
<scope name="scope2">
<sources>
<source linkName="AtoB"/>
</sources>
<assign name="A">
<copy>
<from>concat($output.payload, 'A')</from>
<to>$output.payload</to>
</copy>
</assign>
</scope>
<sequence name="Sequence_1>
<targets>
<target linkName="AtoB"/>
</targets>
<assign name="B">
<copy>
<from>concat($output.payload, 'B')</from>
<to>$output.payload</to>
</copy>
</assign>
</sequence>
</flow>
</sequence>

10.2.6 ターゲット・アクティビティの結合条件に関する必知事項

ターゲット・アクティビティでオプションの結合条件を指定できます。結合条件の値はブール式です。結合条件が指定されていない場合、結合条件は、このアクティビティのすべての着信リンクのリンク・ステータスの分離(つまり、論理OR演算)になります。

Oracle BPELデザイナでは、結合条件を追加するための設計はサポートされていません。結合条件を追加するには、Oracle BPELデザイナの「ソース」ビューの.bpelファイルに条件を手動で追加する必要があります。

次に、結合条件の例を示します。

<flow>
<links>
<link name="linkStatus2"/>
</links>
<empty name="E2">
<sources>
<source linkName="linkStatus2">
<transitionCondition>false()</transitionCondition>
</source>
</sources>
</empty>
<empty name="E2">
<targets>
<joinCondition>bpws:getLinkStatus('linkStatus2')=true()</joinCondition>
<target linkName="linkStatus2"/>
</targets>
</empty>
</flow>

10.3 パラレル・ブランチ数のカスタマイズ

この項では、次のアクティビティを使用してパラレル・ブランチの数をカスタマイズする方法について説明します。

- forEachアクティビティ(BPELバージョン2.0プロジェクト)

- flowNアクティビティ(BPELバージョン1.1プロジェクト)

注意:

flowNおよびforEachアクティビティ内のブランチは、シングル・スレッドでシリアルで実行されます。詳細は、「シングル・スレッドでのフローのブランチのパラレル実行に関する必知事項」を参照してください。

10.3.1 BPEL 2.0のforEachアクティビティによるアクティビティの複数のセットの処理

forEachアクティビティを使用すると、アクティビティの複数のセットを順次、または並行して処理できます。forEachアクティビティは、含まれている(子)scopeアクティビティを正確にN+1回実行し、Nは、最終カウンタ値から、「For Each」ダイアログの「カウンタの値」タブで指定する開始カウンタ値を引いた値に等しくなります。flowアクティビティなど、他の構造化アクティビティは、含まれているアクティビティとして任意のタイプのアクティビティを使用できますが、forEachアクティビティにはscopeアクティビティのみ含めることができます。

forEachアクティビティを開始すると、開始カウンタ値と最終カウンタ値に指定した式が評価されます。この2つの値は、返された後、アクティビティのライフサイクルの間は変化しません。どちらの式も、少なくとも1文字を含む値を返す必要があります。これらの式が有効な値を返さない場合、フォルトがスローされます。開始カウンタ値が最終カウンタ値より大きい場合、含まれているscopeアクティビティは実行されず、forEachアクティビティは完了したとみなされます。

各反復中に、「一般」タブの「カウンタ名」フィールドに指定された変数は、forEachアクティビティに含まれているスコープで暗黙的に宣言されます。スコープの最初の反復中に、カウンタ変数は開始カウンタ値で初期化されます。次の反復で、カウンタ変数は開始カウンタ値+1で初期化されます。その後の反復のたびに、前に初期化されたカウンタ変数値が1ずつ増分され、カウンタ値が最終カウンタ値に設定される最後の反復まで繰り返されます。カウンタ変数は、囲まれたscopeアクティビティに対してローカルです。反復中に値を変更できますが、各反復の後にその値は失われます。したがって、カウンタ変数値は次の反復のカウンタ値には影響しません。

forEachアクティビティは、次のループ反復をサポートしています。

- 順次(デフォルト)
forEachアクティビティは、scopeアクティビティ内で定義されている特定のアクティビティのセットに対して、ループ反復を順番にN回実行します。例として、forEachアクティビティは、注文書メッセージがN個の受注品目で構成される、受信注文書メッセージに対して繰り返されるとします。囲まれたscopeアクティビティはN+1回実行され、各インスタンスは前の反復が完了した後にのみ開始されます。

- パラレル
すべてのループ反復は同時に開始され、並行して処理されます。並列反復は、独立したデータのセットが処理される環境、または異なるパートナとの独立した対話が並行して行われる環境で役に立ちます。並列ループを有効にするには、「一般」タブで「パラレル実行」チェック・ボックスを選択します。これらのシナリオでは、含まれているscopeアクティビティのN+1インスタンスが並行して実行されます。scopeアクティビティの各コピーには、順に実行されるforEachアクティビティに指定したのと同じ方法で宣言された、「一般」タブの「カウンタ名」フィールドで指定したものと同じカウンタ変数が使用されます。各インスタンスのカウンタ変数は、開始カウンタ値で始まり、最終カウンタ値まで増える整数値の1つで並行して一意に初期化される必要があります。

flowアクティビティと異なり、forEachアクティビティのパラレル・ブランチの数は設計時には不明です。指定されたカウンタ変数は、パラレル・ブランチ数を使用して繰り返され、開始カウンタ値および最終カウンタ値で制御されます。

「完了」タブで完了条件を指定することもできます。この条件により、forEachアクティビティは条件を実行し、指定されたすべてのブランチを実行または完了しなくても完了できます。例として、並列リクエストを送信し、十分な数の受信者のサブセットが返信したとします。次の状態を回避するために、オプションで完了条件が指定されます。

- いくつかの子の実行(順次ケース)

- 一部の子の強制的な早期終了(パラレル・ケース)

完了条件を指定しない場合、forEachアクティビティは、含まれているscopeが完了したときに完了します。

(フォルトまたはtrueと評価される完了条件により)早すぎる終了が発生した場合、N+1要件は適用されません。

次の例にforEachアクティビティの構文を示します。

<forEach counterName="MyVariableName" parallel="yes|no"
standard-attributes>
standard-elements
<startCounterValue expressionLanguage="anyURI"?>
unsigned-integer-expression
</startCounterValue>
<finalCounterValue expressionLanguage="anyURI"?>
unsigned-integer-expression
</finalCounterValue>
<completionCondition>?
<branches expressionLanguage="anyURI"?
successfulBranchesOnly="yes|no"?>?
unsigned-integer-expression
</branches>
</completionCondition>
<scope ..>...</scope>
</forEach>

注意:

successfulBranchesOnly属性はこのリリースではサポートされません。

10.3.1.1 forEachアクティビティの作成方法

forEachアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」→「構造化アクティビティ」を展開します。

2. 図10-10 に示すように、forEachアクティビティをデザイナにドラッグします。

forEachアクティビティに含まれているscopeアクティビティを確認します。

図10-10 forEachアクティビティに含まれているscopeアクティビティ

3. forEachアクティビティをダブルクリックします。

4. 図10-11 に示すように、「一般」タブの「カウンタ名」フィールドにカウンタ値の名前を入力します。

「パラレル実行」チェック・ボックスが選択されている場合、すべてのループ反復が同時に開始され、並行して処理されます。次のブランチは、前のブランチが完了していなくても開始されます。選択されていない場合、次のブランチは、前のブランチが完了するまで開始されません。

図10-11 forEachアクティビティの「一般」タブ

5. 「カウンタの値」タブをクリックします。

6. 「式ビルダー」アイコンをクリックして、図10-12 に示すように開始カウンタ値および最終カウンタ値を入力します。

図10-12 forEachアクティビティの「カウンタの値」タブ

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

8. forEachアクティビティが条件を実行し、指定されたすべてのブランチを実行または完了しなくても完了できるようにする完了条件を指定する場合は、「式」フィールドの上の「XPath式ビルダー」アイコンをクリックして、条件を入力します。図10-13に詳細を示します。

図10-13 forEachアクティビティの「完了」タブ

9. 「適用」をクリックし、「OK」をクリックします。

10. forEachアクティビティに含まれているscopeアクティビティを開きます。

11. 囲まれたscopeアクティビティを設計します。

完了後、forEachアクティビティと含まれているscopeアクティビティは、図10-14 のような構造になります。

図10-14 含まれているscopeアクティビティと開いた状態のscopeアクティビティを持つforEachアクティビティ

10.3.1.2 forEachアクティビティ作成時の処理内容

次の例は、順に実行されるforEachアクティビティの設計が完了した後の.bpelファイルを示しています。

<faultHandlers>
<catch faultName="bpel:invalidBranchCondition">
<sequence>
<assign>
<copy>
<from>'invalidBranchCondition happened'</from>
<to>$output.payload</to>
</copy>
</assign>

<reply name="replyOutput" partnerLink="client"
portType="tns:Test" operation="process" variable="output"/>
</sequence>
</catch>
</faultHandlers>
<sequence>
<!-- pick input from requester -->
<receive name="receive" createInstance="yes"
partnerLink="client" portType="tns:Test"
operation="process" variable="input"/>
<assign>
<copy>
<from>3</from>
<to>$request.payload</to>
</copy>
<copy>
<from>''</from>
<to>$output.payload</to>
</copy>
</assign>

<forEach counterName="i" parallel="no">
<startCounterValue>$input.payload/tns:startCounter+1</startCounterValue>
<finalCounterValue>$input.payload/tns:finalCounter+1</finalCounterValue>
<completionCondition>
<branches>$input.payload/tns:branches+1</branches>
</completionCondition>
<scope name="scope1">
<partnerLinks>
<partnerLink name="DummyService" partnerLinkType="tns:DummyService"
myRole="DummyServiceClient" partnerRole="DummyServiceProvider"/>
</partnerLinks>
<sequence>
<assign>
<copy>
<from>concat($output.payload, $i, 'A')</from>
<to>$output.payload</to>
</copy>
</assign>
<invoke name="invokeDummyService" partnerLink="DummyService"
portType="tns:DummyPortType"
operation="initiate" inputVariable="request"/>
<receive name="receiveFromDummyService" partnerLink="DummyService"
portType="tns:DummyCallbackPortType"
operation="onResult" variable="response"/>          <assign>
<copy>
<from>concat($output.payload, $i, 'B')</from>
<to>$output.payload</to>
</copy>
</assign>
</sequence>
</scope>
</forEach>

<!-- respond output to requester -->
<reply name="replyOutput" partnerLink="client"
portType="tns:Test" operation="process" variable="output"/>
</sequence>

次の例は、パラレルforEachアクティビティの設計が完了した後の.bpelファイルを示しています。

<sequence>
<!-- pick input from requester -->
<receive name="receive" createInstance="yes"
partnerLink="client" portType="tns:Test"
operation="process" variable="input"/>
<assign>
<copy>
<from>$input.payload/tns:value1</from>
<to>$request.payload</to>
</copy>
<copy>
<from>''</from>
<to>$output.payload</to>
</copy>
</assign>
<forEach counterName="i" parallel="yes">
<startCounterValue>($input.payload/tns:value1 + 1)</startCounterValue>
<finalCounterValue>($input.payload/tns:value2 + 2)</finalCounterValue>
<scope name="scope1">
<partnerLinks>
<partnerLink name="DummyService" partnerLinkType="tns:DummyService"
myRole="DummyServiceClient" partnerRole="DummyServiceProvider"/>
</partnerLinks>
<sequence>
<assign>
<copy>
<from>concat($output.payload, 'A')</from>
<to>$output.payload</to>
</copy>
</assign>
<invoke name="invokeDummyService" partnerLink="DummyService"
portType="tns:DummyPortType"
operation="initiate" inputVariable="request"/>
<receive name="receiveFromDummyService" partnerLink="DummyService"
portType="tns:DummyCallbackPortType"
operation="onResult" variable="response"/>
<assign>
<copy>
<from>concat($output.payload, 'B')</from>
<to>$output.payload</to>
</copy>
</assign>
</sequence>
</scope>
</forEach>
<!-- respond output to requester -->
<reply name="replyOutput" partnerLink="client"
portType="tns:Test" operation="process" variable="output"/>
</sequence>

10.3.2 BPEL 1.1のflowNアクティビティによるflowアクティビティ数のカスタマイズ

flowアクティビティでは、BPELコードによってパラレル・ブランチの数が決定されます。ただし、必要なブランチの数は、多くの場合、使用可能な情報に応じて異なります。flowNアクティビティは、Nの値に等しい複数のフローを作成します。この値は、使用可能なデータおよびプロセス内のロジックに基づいて実行時に定義されます。索引変数は、Nの値に到達するまで、新しいブランチが作成されるたびに増分されます。

flowNアクティビティは、任意の数のデータ要素に対してアクティビティを実行します。BPELプロセス・サービス・コンポーネントは、要素の数の変化に応じて適切に調整を実行します。

flowNで作成される各ブランチは、同じアクティビティを実行しますが、異なるデータを使用します。各ブランチは、索引変数を使用して入力変数を参照します。索引変数をXPath式で使用すると、そのブランチに固有のデータを取得できます。

たとえば、データの配列があるとします。BPELプロセス・サービス・コンポーネントは、count関数を使用して配列内の要素の数を判断します。次に、Nが要素の数に設定されます。索引変数は、事前に設定された値(デフォルトは0(ゼロ))で始まります。flowNは、複数のブランチを作成して配列の各要素を取得し、その要素に含まれるデータを使用してアクティビティを実行します。これらのブランチは、初期索引値とNの間のすべての値を使用して、並行して生成され、実行されます。flowNアクティビティは、索引変数がNの値に到達すると終了します。たとえば、配列に3つの要素が含まれている場合、Nは3に設定されます。索引変数が1で始まるとすると、flowNアクティビティは索引1、2および3を使用して3つのパラレル・ブランチを作成します。

flowNアクティビティでは、Webサービスから取得したデータなど、他のソースのデータも使用できます。

図10-15 に、3つのホテルを参照するOracle Enterprise Manager Fusion Middleware ControlのflowNアクティビティの実行時フローを示します。この図は、BPELプロセス・サービス・コンポーネントではなく、プロセスを実際に実行する方法を示しているため、ビューそのものではありません。この例では、3つのホテルがありますが、ブランチの数は使用可能なホテルの数に応じて異なります。

図10-15 flowNアクティビティの実行を示すOracle Enterprise Manager Fusion Middleware Controlビュー

10.3.2.1 flowNアクティビティの作成方法

flowNアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「Oracle Extensions」を展開します。

2. flowNアクティビティをデザイナにドラッグします。

3. +記号をクリックしてflowNアクティビティを開きます。

4. flowNアクティビティをクリックして、そのプロパティ・フィールドをプロパティ・インスペクタで表示するか、flowNアクティビティをダブルクリックします。

アクティビティをプロパティ・インスペクタで編集する方法の詳細は、「BPELアクティビティをプロパティ・インスペクタで編集する方法」を参照してください。

図10-16 に、「FlowN」ダイアログを示します。

図10-16 「FlowN」ダイアログ

「FlowN」ダイアログでは次のことができます。

- アクティビティ名の設定

- 値またはNの値(作成するブランチ数)の計算式の入力

- 索引変数(各ブランチでの待機時間)の定義

5. 追加するアクティビティをflowNアクティビティにドラッグして定義します。

図10-17 は、flowNアクティビティと他のアクティビティが表示されている様子を示しています。

図10-17 flowNアクティビティと他のアクティビティ

10.3.2.2 flowNアクティビティ作成時の処理内容

次のコードは、flowNアクティビティを使用して任意の数のホテルの情報を参照する.bpelファイルを示しています。

次の例は順序名を示しています。

<sequence name="main">
<!-- Received input from requester.
Note: This maps to operation defined in NflowHotels.wsdl
The requester sends a set of hotels names wrapped into the "inputVariable"
-->

次のアクションを実行します。receiveアクティビティは、クライアント・パートナ・リンクをコールし、flowNアクティビティがNの数を定義してホテル情報を参照するために必要な情報を取得します。次に例を示します。

<receive name="receiveInput" partnerLink="client"
portType="client:NflowHotels" operation="initiate" variable="inputVariable"
createInstance="yes"/>
<!--
The 'count()' Xpath function is used to get the number of hotelName
noded passed in.
An intermediate variable called "NbParallelFlow" is
used to store the number of N flows being executed
-->
<assign name="getHotelsN">
<copy>
<from
expression="count($InputVariable.payload/client:HotelName);"/>
<to variable="NbParallelFlow"/>
</copy>
</assign>
<!-- Initiating the FlowN activity
The N value is initialized with the value stored in the
"NbParallelFlow" variable
The variable call "Index" is defined as the index variable
NOTE: Both "NbParallelFlow" and "Index" variables have to be declared
-->

次に、flowNアクティビティが開始されます。flowNのアクティビティの名前を定義した後、NをinputVariable(ホテル・エントリの数)の値として定義します。また、このアクティビティは、索引変数としてindexを割り当てます。次に例を示します。

<bpelx:flowN name="FlowN" N="bpws:getVariableData('NbParallelFlow')
indexVariable="Index'>
<sequence name="Sequence_1">
<!-- Fetching each hotelName by indexing the "inputVariable" with the
"Index" variable.
Note the usage of the  "concat()" Xpath function to create the
expression accessing the array element.
-->

次の例に示すコピー・ルールで索引変数を使用し、複数のホテル・エントリを1つのリストに連結します。

<assign name="setHotelId">
<copy>
<from expression=
"bpws:getVariableData('inputVariable','payload',concat('/client:Nflo
wHotelsProcessRequest/client:ListOfHotels/client:HotelName[',
bpws:getVariableData('Index'),']'))"/>
<to variable="InvokeHotelDetailInputVariable" part="payload"
query="/ns2:hotelInfoRequest/ns2:id"/>
</copy>
</assign>

このホテル情報を使用して、invokeアクティビティは、Webサービスから各ホテルの詳細情報を参照します。次に例を示します。

<!-- For each hotel, invoke the web service giving detailed information
on the hotel -->
<invoke name="InvokeHotelDetail" partnerLink="getHotelDetail"
portType="ns2:getHotelDetail" operation="process"
inputVariable="InvokeHotelDetailInputVariable"
outputVariable="InvokeHotelDetailOutputVariable"/>
</sequence>
</bpelx:flowN>

最後に、このBPELプロセスは、各ホテルの詳細情報をクライアント・パートナ・リンクに送信します。次に例を示します。

<invoke name="callbackClient" partnerLink="client"
portType="client:NflowHotelsCallback" operation="onResult"
inputVariable="outputVariable"/>
</sequence>
</sequence>

11 BPELプロセスでの条件分岐の使用

この章では、BPELプロセス・サービス・コンポーネントでの条件分岐の使用方法について説明します。条件分岐により、BPELプロセス・サービス・コンポーネントの実行フローを制御するための判断ができるようになります。この章では、switch、if、while、repeatUntilの各アクティビティを使用して条件分岐を定義する方法、およびアクティビティの実行をバイパスできるXPath式を指定する方法についても説明します。

この章の内容は次のとおりです。

- 条件分岐の概要

- ifまたはswitchアクティビティによる条件分岐の定義

- whileアクティビティによる条件分岐の定義

- repeatUntilアクティビティによる条件分岐の定義

- アクティビティの実行をバイパスするためのXPath式の指定

11.1 条件分岐の概要

BPELは、条件分岐によって選択するロジックを利用します。次のアクティビティを使用すると、条件分岐に基づいて異なるアクションを選択するコードを設計できます。

- ifアクティビティ(BPELバージョン2.0プロジェクト)
2つ以上のブランチのいずれかに決めるために特定のアクティビティに条件動作が必要な場合、ifアクティビティを使用できます。ifアクティビティは、BPEL 1.1プロセスに見られたswitchアクティビティにかわるものです。ifアクティビティの作成方法の詳細は、「BPEL 2.0のifアクティビティの作成による条件分岐の定義」を参照してください。

- switchアクティビティ(BPELバージョン1.1プロジェクト)
2つ以上のブランチを設定できます。各ブランチにはXPath式の形式を使用します。式がtrueの場合、そのブランチが実行されます。式がfalseの場合、BPELプロセス・サービス・コンポーネントは有効なブランチ条件が見つかるか、otherwiseブランチに達するか、ブランチがなくなるまで次のブランチ条件に進みます。複数のブランチ条件がtrueの場合は、最初にtrueと判断されたブランチがBPELにより実行されます。switchアクティビティの作成方法の詳細は、「BPEL 1.1のswitchアクティビティの作成による条件分岐の定義」を参照してください。

- whileアクティビティ
2つのアクション間で選択を実行するwhileループを作成できます。whileアクティビティの説明は、「whileアクティビティによる条件分岐の定義」にあります。

多数のブランチが設定され、各ブランチにはXPath式形式の条件が指定されます。

条件分岐には、タイムアウトを設定できます。つまり、指定の期間内にレスポンスを生成できない場合、BPELフローは待機を中止し、そのアクティビティを再開できます。この機能の詳細は、「BPELプロセスでのイベントおよびタイムアウトの使用」で説明します。

注意:

条件分岐ロジックはビジネス・ルールを使用して定義することもできます。『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

11.2 ifまたはswitchアクティビティによる条件分岐の定義

この項では、次のアクティビティを使用して条件分岐を定義する方法について説明します。

- BPELバージョン2.0プロジェクトのifアクティビティ

- BPELバージョン1.1プロジェクトのswitchアクティビティ

11.2.1 BPEL 2.0のifアクティビティの作成による条件分岐の定義

2つ以上のブランチのいずれかに決めるために特定のアクティビティに条件動作が必要な場合、ifアクティビティを使用できます。ブランチのセットから、実行するアクティビティが1つだけ選択されます。ifアクティビティは、次の順序で実行対象とみなされる1つ以上の条件分岐のリストで構成されます。

- ifブランチ

- オプションのelseifブランチ

- オプションのelseブランチ

条件がtrueに評価される最初のブランチが採用され、そこに含まれているアクティビティが実行されます。条件付きブランチが採用されない場合は、elseブランチが採用されます(存在する場合)。ifアクティビティは、選択されたブランチに含まれるアクティビティが完了した時点で、またはtrueに評価される条件がなまelseブランチが指定されていない場合にはただちに終了します。

ifアクティビティは、BPELバージョン1.1に含まれていたswitchアクティビティにかわる、BPELバージョン2.0の機能です。

次の例にifアクティビティの構文を示します。

<if standard-attributes>
standard-elements
<condition>some conditon expression</condition>
activity
<elseif>*
<condition>some condition expression</condition>
some activity
</elseif>
<else>?
some activity
</else>
</if>

11.2.1.1 ifアクティビティの作成方法

ifアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. ifアクティビティをデザイナにドラッグします。

図11-1 に示すように、if条件とelse条件が表示されます。

図11-1 ifアクティビティ

3. ifブランチをクリックします。

4. 図11-2 に示すように、「条件」フィールドに条件を入力します。「XPath式ビルダー」アイコンをクリックして、「式ビルダー」ダイアログを起動することもできます。

図11-2 ifアクティビティのifブランチ

5. 「OK」をクリックします。

6. 必要に応じて、追加のアクティビティをif条件にドラッグして定義します。これらのアクティビティは、if条件がtrueと評価された場合に実行されます。

7. elseifブランチをクリックします(このブランチを追加した場合)。

8. 図11-3 に示すように、「条件」フィールドに条件を入力します。

図11-3 ifアクティビティのelseifブランチ

9. 「OK」をクリックします。

10. elseif条件を追加する場合は、ifアクティビティを強調表示し、「追加」アイコンを選択してメニューを起動します。

11. 必要に応じて、追加のアクティビティをelseif条件にドラッグして定義します。これらのアクティビティは、ifブランチがtrueと評価されず、このelseifブランチがtrueと評価された場合に実行されます。

12. elseラベルをクリックします。

13. 必要に応じて、条件を入力するか、追加のアクティビティをelse条件にドラッグして定義します。これらのアクティビティは、ifおよびその他のelseifブランチがtrueと評価されず、このelseブランチがtrueと評価された場合に実行されます。

図11-4 に、完了したifアクティビティを示します。各ブランチには、含まれているアクティビティが表示されています。

図11-4 完了したifアクティビティ

11.2.1.2 ifアクティビティ作成時の処理内容

次のコードは、設計完了後の.bpelファイルの例を示しています。ifアクティビティでは、if、elseifおよびelseの各ブランチが定義されています。trueと評価された最初のブランチが実行されます。

<sequence>
<!-- receive input from requester -->
<receive name="receiveInput" partnerLink="client" portType="tns:Test"
operation="process" variable="input" createInstance="yes"/>
<!-- assign default value -->
<assign>
<copy>
<from>'Value is greater than zero'</from>
<to>$output.payload</to>
</copy>
<assign>
<copy>
<from>'Value is greater than zero'</from>
<to>$output.payload</to>
</copy>
</assign>
<!-- switch depends on the input value field -->
<if>
<condition>$input.payload > 0</condition>
<extensionActivity>
<bpelx:exec name="Java_Embedding" version="1.5" language="java">
System.out.println("if condition is true.\n");
</bpelx:exec>
</extensionActivity>
<elseif>
<condition>bpws:getVariableData('input', 'payload') &lt; 0</condition>
<assign>
<copy>
<from>'Value is less than zero'</from>
<to>$output.payload</to>
</copy>
</assign>
</elseif>
<else>
<assign>
<copy>
<from>'Value is equal to zero'</from>
<to>$output.payload</to>
</copy>
</assign>
</else>
</if>

<!-- respond output to requester -->
<reply name="replyOutput" partnerLink="client"
portType="tns:Test" operation="process" variable="output"/>
</sequence>

11.2.2 BPEL 1.1のswitchアクティビティの作成による条件分岐の定義

2社からの融資提案が同時に収集されるBPELプロセス・サービス・コンポーネントのflowアクティビティを設計し、ここではいずれの条件も比較されていないと仮定します。各条件は、それぞれのグローバル変数に格納されています。2つの提案を比較し、その比較に基づいて決定するには、switchアクティビティを使用できます。

図11-5 に、switchアクティビティに定義されたBPEL条件分岐プロセスの概要を示します。

図11-5 条件分岐

11.2.2.1 switchアクティビティの作成方法

switchアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. 図11-6 に示すように、switchアクティビティをデザイナにドラッグします。

switchアクティビティにはデフォルトで2つのswitch caseブランチがあり、各ブランチには機能要素を挿入するためのボックスがあります。ブランチを追加するには、switchアクティビティ全体を選択して右クリックし、メニューから「Switch Caseの追加」を選択します。

図11-6 switchアクティビティ

3. 最初のブランチで、「条件」ボックスをダブルクリックします。

図11-7 に示すように、条件を入力するためのダイアログが表示されます。

図11-7 「条件」ダイアログ

4. 「ラベル」フィールドに、条件分岐の名前を入力します。完了すると、Oracle BPELデザイナにこの名前が表示されます。

5. 「条件」フィールドで、「式ビルダー」アイコンをクリックして「式ビルダー」ダイアログにアクセスします。

6. 式を作成します。

bpws:getVariableDate('loanOffer1','payload','/loanOffer/APR') >
bpws:getVariableData('loanOffer2','payload','/loanOffer/APR')

この例では、融資企業からの完成した2つの融資提案は、グローバル変数loanOffer1およびloanOffer2に格納されます。それぞれの融資提案変数には、融資提案のAPRが格納されます。BPELフローは、APRが最も低い融資を選択する必要があります。次のいずれかのswitchアクティビティを実行します。

- loanOffer1のAPRの方が高い場合、最初のブランチはloanOffer2のペイロードをselectedLoanOfferのペイロードに割り当てることで、loanOffer2を選択します。

- loanOffer1にloanOffer2より小さいAPRがない場合、otherwise caseはloanOffer1ペイロードをselectedLoanOfferペイロードに割り当てます。

7. 「OK」をクリックします。

式が表示されます。ダイアログの「ラベル」フィールドに入力した値は、条件分岐の名前になります。

8. 「OK」をクリックします。

9. 必要に応じて、その他のアクティビティを追加および構成します。図11-8に詳細を示します。

図11-8 switchアクティビティの設計

11.2.2.2 switchアクティビティ作成時の処理内容

flowアクティビティなどのswitchアクティビティには複数のブランチがあります。次の例では、2つのブランチのみが設計完了後の.bpelファイルに表示されています。最初のブランチは、United Loanという企業からの融資提案を選択するブランチであり、XPathブール式を含むcase条件が適合した場合に実行されます。そうでない場合、Star Loanという企業からの融資提案を選択する2番目のブランチが実行されます。デフォルトでは、switchアクティビティには2つのswitch caseが含まれていますが、必要に応じて追加できます。

<switch name="switch-1">
<case condition="bpws:getVariableData('loanOffer1','payload',
'/autoloan:loanOffer/autoloan:APR') >
bpws:getVariableData('loanOffer2','payload','/autoloan:loanOffer/autoloan:APR
')">
" name="Choose_the_Loan_with_the_Lower_APR">
<bpelx:annotation>
<bpelx:general>
<bpelx:property name="userLabel">Choose the Loan with
the Lower APR</bpelx:property>
</bpelx:general>
</bpelx:annotation>
<assign name="selectUnitedLoan">
<copy>
<from variable="loanOffer1" part="payload">
</from>
<to variable="selectedLoanOffer" part="payload"/>
</copy>
</assign>
</case>
<otherwise>
<assign name="selectStarLoan">
<copy>
<from variable="loanOffer2" part="payload">
</from>
<to variable="selectedLoanOffer" part="payload"/>
</copy>
</assign>
</otherwise>
</switch>

11.3 whileアクティビティによる条件分岐の定義

複数のアクション間で選択を行うようにBPELコードを設計する別の方法としては、whileアクティビティを使用したwhileループの作成があります。whileループは、指定の条件が適合するまで、アクティビティを繰り返します。たとえば、重要なWebサービスでリクエストに対してサービス・ビジー・メッセージを返している場合、そのサービスが使用可能になるまで、whileアクティビティを使用してポーリングし続けることができます。このときのwhileアクティビティの条件はサービスから受け取った最新のメッセージがビジーであることで、whileアクティビティ内の操作はサービスを再チェックすることです。Webサービスからサービス・ビジー以外のメッセージが戻ると、whileアクティビティは終了し、理想的にはWebサービスからの有効なレスポンスを使用して、BPELプロセス・サービス・コンポーネントが続行されます。

11.3.1 whileアクティビティの作成方法

whileアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. whileアクティビティをデザイナにドラッグします。

3. +記号をクリックしてwhileアクティビティを開きます。

whileアクティビティには、条件式を作成するアイコンとwhile定義を検証するアイコンがあります。また、アクティビティをドラッグしてwhileループを定義する領域も用意されています。

4. while条件を使用するための追加のアクティビティ(scopeアクティビティなど)をwhileアクティビティの「アクティビティをここにドロップ」領域にドラッグして定義します。

このアクティビティとして、既存のアクティビティや新しいアクティビティを使用できます。

5. 「XPath式ビルダー」アイコンをクリックして、「式ビルダー」ダイアログを開きます。

6. 図11-9 に示すように、繰り返し実行する式を入力します。このアクションは、指定したwhile条件のブール値がtrueでなくなるまで実行されます。この例のアクティビティは、5未満の場合に繰り返しループするように設定されています。

図11-9 式が設定されているwhileアクティビティ

7. 完了後に「OK」をクリックします。

11.3.2 whileアクティビティ作成時の処理内容

次のコードは、設計完了後の.bpelファイルの例を示しています。whileアクティビティ内にscopeアクティビティがあります。scopeアクティビティには、シーケンスおよびフォルト・ハンドラが最上位レベルに含まれています。シーケンスにはinvokeアクティビティ、assignアクティビティ、およびシーケンスにラップされたassignアクティビティとwaitアクティビティを含むcatchAllを定義するフォルト・ハンドラが含まれています。

次のコードにより、外部サービスがコールされます。外部サービスがフォルトをスローすると、フォルト・ハンドラによってフォルトが捕捉され、dbStatus変数値が増分されます。

したがって、whileループの終了条件は次のいずれかとなります。

- 例外がないこと(dbStatus値が値10に設定されており、これにより、while条件はfalseと評価されます)

- フォルトが5回スローされた後であること(dbStatus値が5に設定されており、while条件はfalseを返します)

<while name="While_1" condition="bpws:getVariableData('dbStatus') > 5">
<scope name="Scope_1">
<faultHandlers>
<catchAll>
<sequence name="Sequence_2">
<assign name="assign_DB_retry">
<copy>
<from expression="bpws:getVariableData('dbStatus') + 1"/>
<to variable="dbStatus"/>
</copy>
</assign>
<wait name="Wait_30_sec" for="'PT31S'"/>
</sequence>
</catchAll>
</faultHandlers>
<sequence name="Sequence_1">
<invoke name="Write_DBWrite" partnerLink="WriteDBRecord"
portType="ns2:WriteDBRecord_ptt" operation="insert"
inputVariable="Invoke_DBWrite_merge_InputVariable"/>
<assign name="Assign_dbComplete">
<copy>
<from expression="'10'"/>
<to variable="dbStatus"/>
</copy>
</assign>
</sequence>
</scope>
</while>

注意:

前の例のwhileアクティビティのコード・フラグメントでは、BPEL 1.1コンストラクトbpws:getVariableData('dbStatus')が使用されています。BPEL 2.0の場合、変数は$記号およびドット(.)表記法を使用して、直接参照されます。次に例を示します。

<while name="While1">
<condition>$inputVariable.payload/client:counter > 0
</condition>

11.4 repeatUntilアクティビティによる条件分岐の定義

アクティビティの本文を少なくとも1回実行する必要がある場合は、whileアクティビティではなくrepeatUntilアクティビティを使用します。repeatUntilアクティビティのXPath式の条件は、アクティビティの本文が完了した後に評価されます。条件は、指定したブール条件がtrueになるまで繰返し評価されます(アクティビティの本体も処理されます)。

注意:

このアクティビティは、BPELバージョン2.0プロジェクトでサポートされています。

11.4.1 repeatUntilアクティビティの作成方法

repeatUntilアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. 「繰返し期限」アクティビティをデザイナにドラッグします。

3. 「繰返し期限」アクティビティをクリックして、そのプロパティ・フィールドをプロパティ・インスペクタで表示するか、「繰返し期限」アクティビティをダブルクリックします。

アクティビティをプロパティ・インスペクタで編集する方法の詳細は、「BPELアクティビティをプロパティ・インスペクタで編集する方法」を参照してください。

4. 名前を入力するか、デフォルト値をそのまま使用します。

5. 「条件」フィールドで、「XPath式ビルダー」アイコンをクリックしてXPath式条件を入力します。

「式ビルダー」ダイアログが表示されます。

6. XPathブール式の条件を入力し、「OK」をクリックします。

図11-10 に示すように、入力した条件が「繰返し期限」ダイアログに表示されます。

図11-10 入力が完了した「繰返し期限」ダイアログ

7. 「適用」をクリックし、「OK」をクリックします。

8. 図11-11 に示すように、「繰返し期限」アクティビティを展開します。

図11-11 展開した状態のrepeatUntilアクティビティ

9. 「コンポーネント」ウィンドウからアクティビティをドラッグし、プロパティ値を定義することで、アクティビティの本文を設計します。これらのアクティビティは、XPath式の条件がtrueと評価されるまで評価されます。

11.4.2 repeatUntilアクティビティ作成時の処理内容

次に、設計完了後の.bpelファイルの例を示します。このシナリオでは、注文書の検証を少なくとも1回実行し、その後はステータスが5に更新されるまで、完了ステータスの評価に基づいて検証を繰り返します。

<repeatUntil>
<sequence>
<invoke name="PurchaseOrderValidation" ... />
<receive name="receiveValidation"
partnerLink="PurchaseOrderValidation"
operation="returnPurchaseOrderValidation"
variable="PurchaseOrderStatusResponse" />
</sequence>
<condition>
bpel:getVariableProperty(
"PurchaseOrderStatusResponse","tst:completionStatus") < 5
</condition>
</repeatUntil>

11.5 アクティビティの実行をバイパスするためのXPath式の指定

Oracleの拡張機能を使用すると、BPELバージョン1.1および2.0のアクティビティにXPath式を指定して、trueと評価された場合に、そのアクティビティがスキップされるようにできます。この機能は、アクティビティを条件付きで実行するために使用するswitchアクティビティの代替手段として提供されています。アクティビティのスキップ条件は、次のように指定します。

<activity bpelx:skipCondition="boolean-expr"/>

bpelx:skipCondition属性により、アクティビティ・インスタンスが作成されるとすぐに、XPath式が評価されます。スキップ式でfalseのブール値が返された場合は、アクティビティが実行されます。スキップ式でtrueのブール値が返された場合、アクティビティは即時に完了となり、そのアクティビティの直後のアクティビティに実行が移動します。

11.5.1 アクティビティの実行をバイパスするためのXPath式の指定方法

アクティビティの実行をバイパスするためのXPath式を指定する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. スキップ条件を作成するアクティビティをデザイナにドラッグします。

3. 「スキップ条件」タブをクリックします。

4. trueと評価された場合にアクティビティをスキップさせるXPath式を指定します。図11-12に詳細を示します。

図11-12 スキップ条件XPath式

5. 「適用」をクリックし、「OK」をクリックします。

11.5.2 アクティビティの実行をバイパスするためのXPath式指定時の処理内容

.bpelファイルのコード・セグメントは、特定の操作に対する設計完了後の定義を示しています。

たとえば、次のコードに示されているXPath式は、trueと評価された場合に(たとえば、inputが20)、assignアクティビティをスキップさせます。

<sequence name="main">
. . .
. . .
<assign name="Assign_1"
bpelx:skipCondition="number(bpws:getVariableData('inputVariable','payload','/client:
process/client:input')) > 10">
<copy>
<from expression="'Assign Block is not Skipped'"/>
<to variable="inputVariable" part="payload"
query="/client:process/client:input"/>
</copy>
</assign>
. . .
. . .
</sequence>

bpelx:skipCondition属性は、スキップ条件とは反対の条件が指定された単一のcase要素が含まれるswitch/case構造化アクティビティに相当します。

次の例は、BPEL 1.1におけるbpelx:skipCondition属性を示しています。myvalueが0の場合、式はtrueと評価され、assignアクティビティがスキップされます。myvalueが10の場合、式はfalseと評価され、assignアクティビティのコピー操作が実行されます。

<assign bpelx:skipCondition="bpws:getVariableData('input',
'payload','/tns:inputMsg/tns:myvalue') <= 0">
<copy>
<from expression="'Value is greater than zero'"/>
<to variable="output" part="payload"
query="/tns:resultMsg/tns:valueResult"/>
</copy>
</assign>

次の例は、switchアクティビティを使用した同等の機能を示しています。

<switch>
<case condition="bpws:getVariableData('input',
'payload','/tns:inputMsg/tns:value') > 0">
<assign>
<copy>
<from expression="'Value is greater than zero'"/>
<to variable="output" part="payload"
query="/tns:resultMsg/tns:valueResult"/>
</copy>
</assign>
</case>
</switch>

BPEL 2.0では、bpelx:skipCondition構文がアクティビティの子要素として表示されます。次のコードは、この規則を使用したassignアクティビティの例を示しています。

<assign name="Assign4">
<bpelx:skipCondition>ora:getNodeValue($inputVariable.payload/client:input) > 5
</bpelx:skipCondition><copy>
<from>"dummy result"</from>
<to>$outputVariable.payload/client:result</to>
</copy></assign>

スキップ条件式には、組込みおよびカスタムのXPath関数も使用できます。次のコードは、いくつかの例を示しています。

<assign bpelx:skipCondition="bpws:getVariableData( 'crOutput', 'payload',
'/tns:rating' ) > 0">

<assign bpelx:skipCondition="custom:validateRating()" ... />

<assign xmlns:fn='http://www.w3.org/2005/xpath-functions'
bpelx:skipCondition="fn:false()" ... />

XPath式の評価でエラーがスローされると、そのエラーはBPELフォルトにラップされて、アクティビティからスローされます。

イベントは、trueと評価しているスキップ条件式によってバイパスされるアクティビティのBPELインスタンス監査証跡に追加されます。スキップ条件がfalseと評価された(アクティビティが実行されることを意味する)場合も、スキップ条件式が評価されたという事実が、デバッグのために監査証跡に記録されます。

XPathエンジンがブール値の評価に失敗した場合は、bpws:subLanguageFaultがスローされます。これは、switch/case条件がブール値に評価されない場合にスローされるフォルトと同じです。このフォルトも、デバッグのために監査証跡に記録されます。

12 BPELプロセスでのフォルト処理の使用

この章では、BPELプロセスのフォルト処理について説明します。BPELプロセス・サービス・コンポーネントでは、フォルト処理を使用して、Webサービス外部から返されたエラー・メッセージやその他の例外を処理し、ビジネス・フォルトまたは実行時フォルトに応じてエラー・メッセージを生成できます。この章では、フォルト管理フレームワークを使用して、フォルトを捕捉したり、フォルト・ポリシー・ファイルに定義されているユーザー指定のアクションを実行する方法についても説明します。

この章の内容は次のとおりです。

- フォルト・ハンドラの概要

- BPEL標準フォルトの概要

- BPELフォルトのビジネスおよび実行時のフォルト・カテゴリの概要

- フォルト管理フレームワークによるフォルト処理

- BPEL実行時フォルトの捕捉

- getFaultAsString XPath式関数によるフォルト詳細の取得

- throwアクティビティによる内部フォルトのスロー

- rethrowアクティビティによるフォルトの再スロー

- 外部フォルトを返す

- 「scopeアクティビティによるアクティビティ・グループの管理」

- replayアクティビティによるscopeアクティビティ内でのアクティビティの再実行

- 一連の操作を元に戻した後の補正の使用

- terminateアクティビティまたはexitアクティビティによるビジネス・プロセス・インスタンスの停止

- アサーション条件によるフォルトのスロー

- 再試行可能とのSOAPフォルトの分類

12.1 フォルト・ハンドラの概要

フォルト・ハンドラは、通常予想される以外のデータ(数値のかわりにエラー・メッセージなど)がターゲット・サービスから返されたときに、BPELプロセス・サービス・コンポーネントの対応方法を定義します。フォルト・ハンドラの例として、Webサービスで通常返される信用格付けの数値のかわりに、ネガティブ情報メッセージが返された場合を想定します。

図12-1 は、フォルト・ハンドラが信用格付け変数を-1000に設定する方法の例を示しています。

図12-1 フォルト処理

次の例のコード・セグメントは、この操作のフォルト・ハンドラをBPELファイルに定義します。

<faultHandlers>
<catch faultName="services:NegativeCredit" faultVariable="crError">
<assign name="crin">
<copy>
<from expression="-1000">
</from>
<to variable="input" part="payload"
query="/autoloan:loanApplication/autoloan:creditRating"/>
</copy>
</assign>
</catch>
</faultHandlers>

faultHandlersタグには、フォルト処理コードが入ります。フォルト・ハンドラ内のcatchアクティビティによって、フォルト名と変数、およびcreditRating変数を「-1000」に設定するコピー指示が定義されます。

BPELプロセス・サービス・コンポーネントに対してWebサービスを選択する際、返される可能性があるフォルトを特定し、それぞれに対してフォルト・ハンドラを設定します。

12.2 BPEL標準フォルトの概要

この項では、BPEL 1.1およびBPEL 2.0の標準フォルトを識別します。

12.2.1 BPEL 1.1の標準フォルト

この項では、BPEL 1.1の標準フォルトを識別します。特に指定がないかぎり、はhttp://schemas.xmlsoap.org/ws/2003/03/business-process/のネームスペースで次の標準フォルトを定義します。

- bindingFault (http://schemas.oracle.com/bpel/extensionで定義されているBPEL拡張フォルト)

- conflictingReceive

- conflictingRequest

- correlationViolation

- forcedTermination

- invalidReply

- joinFailure

- mismatchedAssignmentFailure

- remoteFault (http://schemas.oracle.com/bpel/extensionで定義されているBPEL拡張フォルト)

- repeatedCompensation

- selectionFailure

- uninitializedVariable

- assertFailure

- coordinationFault

- entityInternalNestedError

- maxLoopCountExceeded

- owsmPolicyFault

- rollback

- timeout

標準フォルトの定義は、次のとおりです。

- タイプなし。つまり、messageTypesは関連付けられていません。

- Web Services Description Language (WSDL)メッセージには関連付けられていません。

- 次のようにフォルト変数なしで捕捉されます。

<catch faultName="bpws:selectionFailure">

12.2.2 BPEL 2.0の標準フォルト

次のリストは、WS-BPEL仕様内で定義されている標準フォルトを指定します。標準フォルト名はすべて、標準のWS-BPELネームスペースで修飾されます。

- ambiguousReceive

- completionConditionFailure

- conflictingReceive

- conflictingRequest

- correlationViolation

- invalidBranchCondition

- invalidExpressionValue

- invalidVariables

- joinFailure

- mismatchedAssignmentFailure

- missingReply

- missingRequest

- scopeInitializationFailure

- selectionFailure

- subLanguageExecutionFault

- uninitializedPartnerRole

- uninitializedVariable

- unsupportedReference

- xsltInvalidSource

- xsltStylesheetNotFound

12.2.2.1 BPEL 2.0でのフォルト処理の優先順位

BPEL 2.0の場合、関連するデータなしでスローされたフォルトを捕捉するための優先順位は次のとおりです。

- 一致するfaultName値を持つcatchアクティビティがあり、そのfaultName値でfaultVariable属性が指定されていない場合、フォルトは識別されたcatchアクティビティに送信されます。

- catchAllアクティビティがある場合、フォルトはcatchAllフォルト・ハンドラに送信されます。

- それ以外の場合、フォルトはデフォルトのフォルト・ハンドラによって処理されます。

BPEL 2.0の場合、関連するデータとともにスローされたフォルトを捕捉するための優先順位は次のとおりです。

- 一致するfaultName値を持つcatchアクティビティがあり、そのfaultName値でfaultVariable属性が指定されていない場合、フォルトは識別されたcatchアクティビティに送信されます。

- フォルト・データが、次のものを含むWSDLメッセージ・タイプの場合:

- メッセージには、要素で定義された単一パーツが含まれます。

- 一致するfaultName値を持つcatchアクティビティであり、その値にはfaultVariableがあり、これに関連付けられているfaultElement QNameは、単一のWSDLメッセージ・パーツの実行時要素データのQNameと一致します。

その後フォルトは、単一パーツの要素の値に初期化されたfaultVariableを持つ、識別されたcatchアクティビティに送信されます。

- 一致するfaultName値を持つcatchアクティビティがあり、そのfaultName値でfaultVariable属性が指定されていない場合、フォルトは識別されたcatchアクティビティに送信されます。この場合、フォルト値はフォルト・ハンドラ内からは使用できませんが、rethrowアクティビティで使用できます。

- faultName属性がないcatchコンストラクトがあり、そのfaultName属性に、タイプが実行時フォルト・データのタイプと一致するfaultVariableがある場合、フォルトは識別されたcatchアクティビティに送信されます。

- フォルト・データが、メッセージに要素で定義された単一パーツが含まれるWSDLメッセージ・タイプで、faultVariableを持つfaultName属性がないcatchアクティビティが存在し、そのfaultVariableの関連するfaultElementのQNameが単一のWSDLメッセージ・パーツの実行時要素データのQNameと一致する場合、フォルトは、単一パーツの要素の値に初期化されたfaultVariableを持つ、識別されたcatchアクティビティに送信されます。

- catchAllアクティビティがある場合、フォルトはcatchAllフォルト・ハンドラに送信されます。

- それ以外の場合、フォルトはデフォルトのフォルト・ハンドラによって処理されます。

12.3 BPELフォルトのビジネスおよび実行時のフォルト・カテゴリの概要

BPELフォルトには、Qnameというフォルト名(ネームスペースで修飾された名前)と、可能性のあるmessageTypeがあります。BPELフォルトには次の2つのカテゴリがあります。

- ビジネス・フォルト

- 実行時フォルト

12.3.1 ビジネス・フォルト

ビジネス・フォルトはアプリケーション固有のフォルトであり、処理されている情報に問題がある場合(社会保障番号がデータベース内で見つからない場合など)に生成されます。ビジネス・フォルトは、アプリケーションがthrowアクティビティを実行したとき、またはinvokeアクティビティがレスポンスとしてフォルトを受け取った場合に発生します。ビジネス・フォルトのフォルト名はBPELプロセス・サービス・コンポーネントによって指定されます。該当する場合は、messageTypeが、WSDLファイルで定義されます。ビジネス・フォルトは、faultNameおよびfaultVariableを使用してfaultHandlerで捕捉できます。

<catch faultName="ns1:faultName" faultVariable="varName">

12.3.2 実行時フォルト

実行時フォルトは、BPELプロセス・サービス・コンポーネントまたはWebサービスの実行中に問題(変数名が正しくないためにデータを正しくコピーできないなど)が発生した結果です。この種のフォルトはユーザー定義ではなく、システムによりスローされます。それらは、次に示すような様々な理由で生成されます。

- プロセスによって、値の不適切な使用が試行される。

- 論理エラーが発生する(無限ループなど)。

- SOAPコールでSimple Object Access Protocol (SOAP)フォルトが発生する。

- サーバーによって例外がスローされる。

様々な実行時フォルトが自動的に提供されています。これらのフォルトは、http://schemas.oracle.com/bpel/extensionネームスペースにあります。また、messageType RuntimeFaultMessageに関連付けられています。次の例に示すように、messageTypeはWSDLファイルに定義されます。

<?xml version="1.0" encoding="UTF-8" ?>
<definitions name="RuntimeFault"
targetNamespace="http://schemas.oracle.com/bpel/extension"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/">

<message name="RuntimeFaultMessage">
<part name="code" type="xsd:string" />
<part name="summary" type="xsd:string" />
<part name="detail" type="xsd:string" />
</message>
</definitions>

フォルトの捕捉時に(messageType RuntimeFaultMessageの)faultVariableが使用される場合は、faultVariableからフォルト・サマリーおよび詳細とともにフォルト・コードを問合せできます。

12.3.2.1 bindingFault

bindingFaultは、起動準備に失敗した場合にアクティビティ内でスローされます。たとえば、プロセスのWSDLのロードに失敗した場合などです。bindingFaultは再試行不可です。通常、このタイプのフォルトは管理者操作により修正する必要があります。

12.3.2.2 remoteFault

remoteFaultもアクティビティ内でスローされます。スローの原因は、起動の失敗です。たとえば、リモート・サービスからSOAPフォルトが返されます。

12.3.2.3 replayFault

replayFaultは、スコープ内のアクティビティを再実行します。このフォルトは、スコープ内のいずれかの時点でスコープへと移行されます。このフォルトは共通フォルトには移入されませんが、BPELに対してスコープの再実行の指標になります。その後、サーバーによりスコープが最初から再実行されます。

12.3.3 同期BPELプロセスでのフォルト処理の追加および伝播方法

この項では、同期BPELプロセスでのフォルト処理の追加および伝播方法について説明します。設計中に、次のタスクを実行します。

- 既存のスキーマおよびWSDLファイルを変更し、フォルト要素、フォルト・メッセージおよびフォルト操作の詳細を含めます。

- BPELプロセスにフォルト処理を追加します(具体的にはcatchアクティビティ)。

- WSDLファイルに指定したフォルト・メッセージ・タイプでフォルト変数を作成します。

- assignおよびreplyアクティビティを、追加のフォルト処理詳細とともに追加します。

12.3.3.1 スキーマおよびWSDLファイルの編集

スキーマおよびWSDLファイルを編集する手順は、次のとおりです。

1. 「BPELプロセスの作成」ダイアログでデフォルト設定を使用して同期BPELプロセス(この例では、TestProcessという名前)を作成します。

2. 「アプリケーション」ウィンドウの「スキーマ」フォルダで、「TestProcess.xsd」ファイルをダブルクリックします。

3. 「ソース」ビューをクリックし、processFaultという新しい要素を追加します。

<element name="processFault">
<complexType>
<sequence>
<element name="result" type="string"/>
</sequence>
</complexType>
</element>

4. 「アプリケーション」ウィンドウで、「WSDL」フォルダを開きます。

5. 「TestProcess.wsdl」ファイルをダブルクリックします。

6. 「ソース」ビューをクリックし、TestProcessFaultMessageという新しいメッセージ・タイプを追加します。

<wsdl:message name="TestProcessFaultMessage">
<wsdl:part name="payload" element="client:processFault"/>
</wsdl:message>

7. WSDLファイルでoperation要素を編集し、フォルトを追加します。

<wsdl:operation name="process">
<wsdl:input  message="client:TestProcessRequestMessage" />
<wsdl:output message="client:TestProcessResponseMessage"/>
<wsdl:fault name="FaultResponse" message="
client:TestProcessFaultMessage"/>
</wsdl:operation>

8. 「File」メニューから、「Save」を選択します。

12.3.3.2 フォルト・ハンドラの追加

フォルト・ハンドラを追加する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「SOA」→「BPEL」の順に開きます。

2. 「TestProcess.bpel」をダブルクリックします。

3. BPELプロセスで「Catchの追加」アイコンをクリックし、そのBPELプロセスのフォルト・ハンドラとしてcatchアクティビティを追加します。CatchAllアクティビティを使用することもできます。図12-2に詳細を示します。

図12-2 「Catchの追加」アイコン

4. catchアクティビティをダブルクリックし、システム・フォルトを指定します。図12-3に詳細を示します。

図12-3 catchアクティビティ

このシステム・フォルトをトリガーするassertアクティビティはありません。このアクティビティを追加して、入力フィールドをアサートできます。

5. 「ネームスペースURI」フィールドで、「参照」アイコンをクリックします。

「フォルト・チューザ」ダイアログが表示されます。

6. システム・フォルト(この例では、assertFailure)を選択し、「OK」をクリックします。選択可能なシステム・フォルトが他にも多数あります。図12-4に詳細を示します。

図12-4 「フォルト・チューザ」ダイアログ

catchの編集ダイアログに戻ります。

7. 「フォルト変数」フィールドで、「変数の作成」アイコンをクリックします。

「変数の作成」ダイアログが表示されます。

FaultVarの名前およびRuntimeFaultMessageタイプの変数が作成されます。図12-5に詳細を示します。

図12-5 「変数の作成」ダイアログ

8. RuntimeFault.wsdlファイルを「SOA」→「WSDL」フォルダにコピーします。これは、BPELプロセスWSDLファイルと同じ場所です。

9. 「OK」をクリックし、「Catchの編集」ダイアログで「OK」をクリックします。

12.3.3.3 フォルト・レスポンス変数の作成

フォルト・レスポンス変数を作成する手順は、次のとおりです。

1. 「構造」ウィンドウで、「変数」フォルダを右クリックし、「変数の作成」を選択します。

2. 「名前」フィールドで、Faultresponseと入力します。

3. 「メッセージ・タイプ」を選択します。

4. 「メッセージ・タイプ」フィールドの「参照」アイコンをクリックします。

5. 「メッセージ・タイプ」→「プロジェクトのWSDLファイル」→「TestProcess.wsdl」→「メッセージ・タイプ」→「TestProcessFaultMessage」の順に開き、「OK」をクリックします。図12-6に詳細を示します。

図12-6「タイプ・チューザ」ダイアログ

6. 「変数の作成」ダイアログで「OK」をクリックします。

12.3.3.4 Catch Activityブランチへのassignアクティビティの追加

Catch Activityブランチにassignアクティビティを追加する手順は、次のとおりです。

1. assignアクティビティを、catchアクティビティ・ブロックにドラッグします。

2. assignアクティビティをダブルクリックします。

3. FaultVar変数のcode、summaryおよびdetailの各フィールドをFaultResponse変数に連結し、「OK」をクリックします。図12-7に詳細を示します。

図12-7 assignの編集ダイアログ

4. 「一般」タブの「名前」フィールドで、名前(この例では、FaultDataForClient)を入力します。

12.3.3.5 Catch Activityブランチへのreplyアクティビティの追加

Catch Activityブランチにreplyアクティビティを追加する手順は、次のとおりです。

1. catchアクティビティ・ブロック内のAssignアクティビティの下にあるReplyアクティビティをドラッグします。

2. replyアクティビティをダブルクリックします。

3. 「ネームスペースURI」フィールドで、「参照」アイコンをクリックします。

「フォルト・チューザ」ダイアログが表示されます。

4. 「プロジェクトのWSDLファイル」→「TestProcess.wsdl」を開き、FaultResponseという名前のフォルトを選択します。図12-8に詳細を示します。

図12-8 「フォルト・チューザ」ダイアログ

5. 「名前」フィールドに、名前を入力します(この例ではReplyWithFault)。

6. 「パートナ・リンク」フィールドで、「参照」アイコンをクリックします。

「パートナ・リンク・チューザ」ダイアログが表示されます。

7. replyOutput replyアクティビティが接続されている同じパートナ・リンクを選択し、「OK」をクリックします。

8. 「変数」フィールドの「参照」アイコンをクリックします。

「変数チューザ」ダイアログが表示されます。

9. FaultResponse変数を選択し、「OK」をクリックします。

図12-9 「変数の選択」ダイアログ

10. replyの編集ダイアログで、「OK」をクリックします。

BPELプロセスは図12-10 のようになります。両方のreplyアクティビティが、同じパートナ・リンクに接続されます。

図12-10 BPELプロセスの設計

12.4 フォルト管理フレームワークを使用したフォルトの処理

Oracle SOA Suiteには、BPELプロセスのフォルトを処理するために一般的なフォルト管理フレームワークが用意されています。プロセスでinvokeアクティビティの実行時にフォルトが発生すると、そのフォルトはフレームワークによって捕捉され、フォルト・ポリシー・ファイルでそのコンポジットまたはコンポーネントに関連付けられているユーザー指定のアクションが実行されます。フォルト・ポリシーは、invokeアクティビティの結果であるフォルトに適用できます。フォルトは、ターゲット・サービスでのアサート前、アサート後、起動または実際のビジネスでの障害で発生する可能性があります。

管理者操作が規定のアクションである状況でフォルトが発生した場合は、Oracle Enterprise Manager Fusion Middleware Controlからリカバリ・アクションを実行します。フォルト管理フレームワークによって、scopeアクティビティのcatchアクティビティを使用してBPELプロセスを設計するための代替手段が提供されます。

この項では、フォルト管理フレームワークを構成する複数のコンポーネントの概要について説明します。

- フォルト管理フレームワークでは、invokeアクティビティのすべてのフォルト(ビジネスおよび実行時)が捕捉されます。

- フォルト・ポリシー・ファイルには、フォルト条件および対応するフォルト・リカバリ・アクションを定義します。それぞれのフォルト条件で、処理を試みる特定のフォルトまたは一連のフォルトを指定し、それに対応するアクションを指定します。フォルト・ポリシー・ファイルでは一連のアクションがIDで識別されます。

- 一連の条件によってアクションが起動されます(フォルト・ポリシーとも呼ばれます)。

- 電子メールまたはJMSにより、条件に関連付けられているエラーをユーザーに通知します。

- フォルト・ポリシー・バインディング・ファイルは、フォルト・ポリシー・ファイルに定義されているポリシーを次のものに関連付けます。

- SOAコンポジット・アプリケーション

- BPELプロセスとOracle Mediatorのサービス・コンポーネント

- BPELプロセスとOracle Mediatorのサービス・コンポーネントの参照バインディング・コンポーネント

フォルト管理フレームワークでは、SOAコンポジット・アプリケーションのcomposite.xmlファイルと同じディレクトリ、または設定した2つのプロパティで識別されるリモートの場所で、フォルト・ポリシー・バインディングを検索します。リモートの場所はMDSリポジトリ内です。

注意:

フォルト管理フレームワークで構成されるフォルト・ポリシーは、BPELプロセスのscopeアクティビティのcatchアクティビティに定義されるフォルト処理よりも優先されます。フォルト管理フレームワークは、フォルト処理をcatchアクティビティに再スローするように構成できます。

- フォルト・ポリシー・ファイル(fault-policies.xml)およびフォルト・ポリシー・バインディング・ファイル(fault-bindings.xml)は、次のいずれかの場所に格納されます。

- SOAコンポジット・アプリケーションのcomposite.xmlファイルと同じディレクトリ。

- composite.xmlファイルに追加した2つのプロパティで指定された別の場所。このオプションは、1つのフォルト・ポリシーを複数のSOAコンポジット・アプリケーションで使用する必要がある場合に便利です。このオプションは、composite.xmlファイルと同じディレクトリに格納されているフォルト・ポリシー・ファイルよりも優先されます。次の例は、この2つのプロパティの詳細を示しています。この例では、フォルト・ポリシー・ファイルが、Oracle Metadata Services (MDS)リポジトリの共有領域のSOA部分に配置されます。

<property
name="oracle.composite.faultPolicyFile">oramds:/apps/faultpolicyfiles/
fault-policies.xml
</property>
<property
name="oracle.composite.faultBindingFile">oramds:/apps/faultpolicyfiles/
fault-bindings.xml
</property>

Oracle Mediatorのフォルト処理機能の詳細は、「Oracle Mediatorエラー処理の使用」を参照してください。

Oracle Business Process Management (BPM) Suiteによるフォルト・ポリシーの作成の詳細は、Oracle Business Process Management Studioを使用したビジネス・プロセスの開発の「BPMでのフォルト処理の使用」を参照してください。

12.4.1 フォルト・ポリシー・バインディングによる解決方法の理解

フォルト・ポリシー・バインディング・ファイルは、フォルト・ポリシー・ファイルに定義されているポリシーをSOAコンポジット・アプリケーションまたはコンポーネント(サービス・コンポーネントまたは参照バインディング・コンポーネント)に関連付けます。フォルト管理フレームワークでは、次の順序でフォルト・ポリシー・バインディングの識別が試みられます。

- composite.xmlファイルに定義されている参照バインディング・コンポーネント。

- composite.xmlファイルに定義されているBPELプロセスまたはOracle Mediatorのサービス・コンポーネント。

- composite.xmlファイルに定義されているSOAコンポジット・アプリケーション。

解決する過程で条件に適したアクションが見つからない場合、フォルト管理フレームワークでは、その解決は失敗とみなされ、次の解決レベルに移動します。

たとえば、invokeアクティビティがfaultname="abc"で失敗となった場合を考えてみます。fault-bindings.xmlファイルには、次のポリシー・バインディングが指定されているとします。

- policy-id-1へのSOAコンポジット・アプリケーションのバインド

- policy-id-2へのBPELプロセス/Oracle Mediatorサービス・コンポジットまたは参照バインディング・コンポーネントのバインド

また、fault-bindings.xmlファイルには、次のバインディングも指定されているとします。

- policy-id-3へのSOAコンポジット・アプリケーションのバインド

- policy-id-4への参照バインディング・コンポーネントまたはサービス・コンポーネントのバインド

フォルト管理フレームワークは、次のように動作します。

- 最初に、解決バインディング(この場合はpolicy-id-4)と照合します。

- フォルトの解決に失敗した場合は、可能な次の照合(policy-id-2との照合)に進みます。

- フォルトの解決に失敗した場合は、可能な次の照合(policy-id-3との照合)に進みます。

- フォルトの解決に失敗した場合は、可能な次の照合(この場合はpolicy-id-1との照合)に進みます。

- フォルトが解決していない場合、そのフォルトはBPELフォルトcatchアクティビティに送信されます。

12.4.2 自動フォルト・リカバリのフォルト・ポリシーをフォルト・ポリシー・ウィザードで設計する方法

フォルト・ポリシーをフォルト・ポリシー・ウィザードで設計し、フォルト・ポリシーをフォルト・ポリシー・バインディング・ファイルに関連付けることができます。

自動フォルト・リカバリのフォルト・ポリシーをフォルト・ポリシー・ウィザードで設計する手順は、次のとおりです。

1. Oracle JDeveloperのメイン・メニューから、「ファイル」→「新規」→「ギャラリから」を選択します。

2. 「カテゴリ」リストで、「SOA層」→「フォルト」を選択します。

3. 「項目」リストで、「フォルト・ポリシー・ドキュメント」を選択します。

表12-11 に示すようなフォルト・ポリシー・エディタが表示されます。policy1の名前で単一のフォルト・ポリシーが、構成用に最初に表示されます。

図12-11 初期表示のフォルト・ポリシー・エディタ

フォルト・ポリシー・エディタには複数のセクションおよびタブがあります。フォルト・ポリシー・エディタは、次の順序で構成することをお薦めします。

- 「プロパティ」タブ

- 「アラート」タブ

- 「アクション」タブ

- フォルト・ポリシー名およびフォルト・ハンドラ

- フォルト・ポリシー・バインディング・ファイルとの関連付け

12.4.2.1 手順1: プロパティ・セットの定義

最初に、プロパティ・セットを定義して「手順2: アラートの定義」で定義されるJMSアラートと関連付けます。JMS宛先やコネクション・ファクトリなどのプロパティ・セットの構成詳細を複数のJMSアラートと関連付けることができます。たとえば、JMSアラートの場合、宛先、キュー情報およびコネクション・ファクトリは、フォルト・ポリシーに構成された追加のJMSアラートによる参照が可能です。

注意:

このリリースでは、電子メールアラートに対してプロパティ・セットを作成できません。

1. 「プロパティ」タブをクリックします。表12-1 に使用可能なフィールドの詳細を示します。

表12-1 プロパティ・セットの選択

説明

結果

電子メール・アラート

電子メール・アラートでは、このリリースのプロパティ・セットはサポートされていません。

JMSキュー・アラート

a. 「追加」をクリックして、JMSアラートに対するプロパティおよび値を指定します。次のプロパティおよび関連付けられた値は必須です。

- jmsDestination: 構成されたキューまたはトピックのJNDI名で、ここでアラートがキューまたはパブリッシュされます。

- connectionFactory: 使用する構成済コネクション・ファクトリのJNDI名。

図12-12 に、JMS宛先およびコネクション・ファクトリ値で構成されたプロパティ・セットを示します。

図12-12 JMSプロパティ・セットの構成

定義済JMS propertySetセクションを含む、完全に定義されたフォルト・ポリシー・ファイルの例については、「自動フォルト・リカバリのフォルト・ポリシーを手動で設計する方法」の手順4を参照してください。

12.4.2.2 手順2: アラートの定義

1. 「アラート」タブをクリックします。次の2種類の通知アラートがサポートされています。

- 電子メール: 電子メール受信者を構成して、フォルト発生時にアラートを受信できます。また、同じ電子メール受信者をOracle Enterprise Manager Fusion Middleware Controlの「ワークフロー通知プロパティ」ページの「メーラー」タブに構成する必要があります。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のヒューマン・ワークフロー通知プロパティの構成に関する項を参照してください。

- JMS: フォルトをJMSキューにエンキューするか、JMSトピックにパブリッシュできます。JMSヘッダー値も指定できます。JMS通知は、フォルトを処理するためにサードパーティの解決システムと統合できます。サードパーティの解決システムは、ターゲットのキューおよびトピックにデキューおよびサブスクライブします。ヘッダーのプロパティ値に基づいて利用することで、より詳細にメッセージを利用できます。JMSメッセージのペイロード・タイプは、XMLフォーマットのテキスト・メッセージです。さらに、JMSキューとトピックおよびコネクション・ファクトリをOracle WebLogic Server管理コンソールで構成する必要があります。詳細は、『Oracle WebLogic Server JMSリソースの管理』の基本JMSシステム・リソースの構成に関する項を参照してください。

2. 「追加」アイコンをクリックします。表12-2に詳細を示します。

表12-2 アラートの選択

選択

結果

電子メール

フォルト発生時に電子メール・アラートを受信する受信者を指定できます。

a. 「ID」フィールドで、IDを指定するか、デフォルト値をそのまま使用します。

b. 「宛先」および「Cc」フィールドで、電子メール受信者を指定します。
注意: 「プロパティ・セット」リストからプロパティ・セットを選択しないでください。電子メール・アラートでは、このリリースのプロパティ・セットはサポートされていません。

c. 完了後に、「OK」をクリックします。

JMS

フォルト発生時にJMSアラートを受信するキューを指定できます。

JMSアラートの構成には次の2つのプロパティが必要です。

- jmsDestination: 構成されたキューまたはトピックのJNDI名で、ここでアラートがキューおよびパブリッシュされます。

- connectionFactory: 使用する構成済コネクション・ファクトリのJNDI名。

a. 「ID」フィールドで、IDを指定するか、デフォルト値をそのまま使用します。

b. 「プロパティ・セット」リストで、「手順1: プロパティ・セットの定義」で作成した既存のプロパティ・セットを選択するか、「必須プロパティの作成」をクリックして、jmsDestinationおよびconnectionFactoryに定義されている値を使用して新しいプロパティ・セットを作成します。

c. 「ヘッダー」表で、必要に応じてJMSヘッダー値を指定して、詳細なフォルト利用を実現します。標準およびカスタムの外部システムはどちらも、構成されたヘッダー・プロパティに基づいて、サブスクリプションをフィルタできます。

d. 完了後に、「OK」をクリックします。

図12-13 に、「電子メールのプロパティ」ダイアログでの電子メール・アラートの構成を示します。

図12-13 電子メール・アラートの構成

図12-14 に、「JMSのプロパティ」ダイアログでのJMSアラートの構成を示します。この例では、プロパティ・セット(「必須プロパティの作成」をクリックすることで起動される「プロパティ・セット」ダイアログで定義)とヘッダーの両方が定義されています。

図12-14 JMSアラートの構成

定義済「アラート」セクションを含む、完全に定義されたフォルト・ポリシー・ファイルの例については、「自動フォルト・リカバリのフォルト・ポリシーを手動で設計する方法」の手順4を参照してください。

12.4.2.3 手順3: アクションの定義

1. 「アクション」タブをクリックします。デフォルトでは、アクションのすべてのタイプが自動的に選択されています。図12-15に詳細を示します。

図12-15 フォルト・ポリシー・エディタの「アクション」セクション

表12-3 に、使用可能なアクション・タイプを示します。

表12-3 サポートされているアクション・タイプ

アクション

説明

中断

ビジネス・フロー全体を終了します。

管理者操作

現在のアクティビティの処理が停止します。フォルトを処理するためには、Oracle Enterprise Manager Fusion Middleware Controlから管理者操作を行う必要があります。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のビジネス・フロー・インスタンスでのフォルトのリカバリに関する項を参照してください。

Javaアクション:

外部Javaクラスを実行できます。詳細は、「Javaアクション・フォルト・ポリシーの使用方法」を参照してください。

スコープの再実行

再実行フォルトが発生します。

フォルトの再スロー

BPELフォルト・ハンドラ(scopeアクティビティ内のcatchアクティビティ)にフォルトが送信されます。使用可能なハンドラがない場合、そのフォルトは上部に報告されます。

エンキュー

適切なコンテキストとペイロードとともに、JMSメッセージとしてJMSキューに拒否メッセージをエンキューします。構成の詳細は、『テクノロジ・アダプタの理解』のJMSキューに関する項を参照してください。

WSの起動:

Webサービスを呼び出すことで、拒否メッセージを処理します。構成の詳細は、『テクノロジ・アダプタの理解』のWebサービス・ハンドラに関する項を参照してください。

ファイル・アクション

拒否メッセージをファイルに格納することによって、メッセージのエラー・ハンドラを作成します。構成の詳細は、『テクノロジ・アダプタの理解』のファイルに関する項を参照してください。

再試行

アクティビティを再試行するために、次のオプションが用意されています。

- 指定回数の再試行。

- 再試行から次の再試行までの遅延(秒単位)の指定。

- 指数バックオフによる再試行間隔の増加。

- N回の再試行が失敗となった場合の再試行失敗時アクションへのチェーン。

再試行の詳細は、表12-6 を参照してください。

定義済「アクション」セクションでのフォルト・ポリシー・ファイルの例については、「自動フォルト・リカバリのフォルト・ポリシーを手動で設計する方法」の手順4を参照してください。

12.4.2.4 手順4: フォルト名およびポリシーの定義

1. フォルト・ポリシー・エディタの上部セクションで、フォルト・ポリシーのフォルト名、説明およびデフォルト・アクションを定義します。表12-4に詳細を示します。

表12-4 フォルト・ポリシー・エディタ - 上部のセクション

要素

説明

「フォルト・ポリシーの追加」アイコン(左上隅)

また、さらに別のフォルト・ポリシーを構成用に単一ポリシー・ドキュメントに追加できます。

「追加」アイコンを左上隅でクリックし、さらに別のフォルト・ポリシーを追加します。フォルト・ポリシー・エディタの左端にある列にすべてのポリシーが表示されます。定義するポリシーをクリックできます。

フォルト・ポリシーを削除します

選択したフォルト・ポリシーを削除します。

フォルト・ポリシー

フォルト・ポリシーの名前を入力するか、policynumberのデフォルト名をそのまま使用します。

「フォルトの追加」アイコン(右上隅)

クリックしてフォルトを追加します。

フォルトを削除します

クリックしてフォルトを削除します。

フォルト名

捕捉するフォルトの標準タイプを選択します。このリストには、選択可能なシステム・フォルト(バインディング、Oracle Mediatorまたはリモート)またはサービス(ビジネス)・フォルトが表示されます。

説明

説明を入力します(オプション)。説明は実行時に監査証跡に維持されます。

デフォルト・アクション

このセクションでは、次のタスクを実行します。

a. リストから、このフォルト発生時に実行するデフォルト・アクション(たとえば、中断、再スロー、再試行など)を選択します。選択可能なアクションは、「手順3: アクションの定義」で保持または削除したアクションに基づいています。

または

a. 「追加」アイコンをクリックし、if-then条件をフォルト・ポリシーに追加します。この選択では「If」、「Then」および「Default」のフィールドが表示されます。
たとえば、条件を「If」フィールド(デフォルトは「true」)を指定すると、起動するアクション(たとえば、管理者操作)を「Then」フィールドで選択できます。条件が「true」でない場合、発生するデフォルト・アクション(たとえば、「中断」)を「Default」フィールドで選択できます。

b. 「If」フィールドで、条件を入力するか、「式ビルダー」アイコンをクリックしてXPath式条件を構築します。

c. 「Then」フィールドで、「If」フィールドの条件がtrueに評価される場合に起動される条件を指定します。

d. 「デフォルト」フィールドで、「If」フィールドの条件がfalseに評価される場合に起動される条件を指定します。

e. 「追加」アイコンの左にある「アラート」アイコンをクリックし、条件発生時に送信するアラートのタイプを選択します。選択可能なアラート・タイプが、このダイアログの「アラート」タブに表示されます。複数のアラートを条件で指定できます。

完了すると、フォルト・ポリシー・エディタは図12-16 のようになります。

図12-16 フォルト名、説明およびデフォルト・アクションが定義されたフォルト・ポリシー・エディタ

2. SOAコンポジット・エディタの上で、フォルト・ポリシーのファイルを閉じ、変更の保存を促すプロンプトが表示された際、「はい」をクリックします。図12-17に詳細を示します。

図12-17 フォルト・ポリシー変更の保存

これでポリシー構成が完了しました。フォルト・ポリシー・バインディングにフォルト・ポリシーを関連付ける準備ができています。

12.4.2.5 手順5: フォルト・ポリシーに対するフォルト・ポリシー・バインディングの定義

フォルト・ポリシー・ウィザードでフォルト・ポリシーを設計した後に、フォルト・ポリシーをフォルト・ポリシー・バインディング・ファイルに関連付けます。フォルト・ポリシー・バインディング・ファイルは、フォルト・ポリシー・ファイルに定義されたポリシーを、SOAコンポジット・アプリケーションのサービス・コンポーネント、サービス・バインディング・コンポーネントまたは参照バインディング・コンポーネントに関連付けます。

1. SOAコンポジット・エディタを開きます。

2. SOAコンポジット・エディタ上部のアイコンをクリックして、このフォルト・ポリシーのフォルト・ポリシー・バインディングを定義します。図12-18に詳細を示します。

図12-18 フォルト・ポリシーのバインディング・アイコン

「コンポジット・フォルト・ポリシー」ダイアログが表示されます。

3. 異なるフォルト・ポリシー・ファイル(たとえば、ファイル・ディレクトリやMDSリポジトリで作成されたもの)を指定する場合、「フォルト・ポリシー・ファイル」フィールドの右側にある「参照」アイコンをクリックします。

4. SOAコンポジット・アプリケーション、サービス・バインディング・コンポーネントまたは参照バインディング・コンポーネントの「ポリシー」列で、添付するフォルト・ポリシーを選択します。図12-19に詳細を示します。

図12-19 「コンポジット・フォルト・ポリシー」ダイアログ

5. 「アプリケーション」ウィンドウの「SOA」フォルダ、「fault-bindings.xml」ファイルを選択して、その内容を表示します。図12-20に詳細を示します。

図12-20 fault-bindings.xmlファイルの選択

ファイルは図12-21 のようになります。

図12-21 fault-bindings.xmlファイル

12.4.3 自動フォルト・リカバリのフォルト・ポリシーを手動で設計する方法

この項では、フォルト・ポリシーを手動で設計する方法について説明します。「自動フォルト・リカバリのフォルト・ポリシーをフォルト・ポリシー・ウィザードで設計する方法」で説明されているように、フォルト・ポリシーをフォルト・ポリシー・ウィザードで設計することが推奨アプローチです。

12.4.3.1 自動フォルト・リカバリに対するフォルト・ポリシー・ファイルの手動作成

自動フォルト・リカバリに対するフォルト・ポリシー・ファイルを手動で作成する手順は、次のとおりです。

1. フォルト・ポリシー・ファイルを(たとえば、fault-policies.xmlなどの名前で)作成します。このファイルには、特定のタスクを実行するためのconditionセクションとactionセクションを挿入します。

2. このファイルをcomposite.xmlファイルと同じディレクトリまたは別の場所に格納してoracle.composite.faultPolicyFileプロパティを定義します。

<property
name="oracle.composite.faultPolicyFile">oramds:/apps/faultpolicyfiles/
fault-policies.xml
</property>
<property
name="oracle.composite.faultBindingFile">oramds:/apps/faultpolicyfiles/
fault-bindings.xml
</property>

フォルト・ポリシー・ファイルがファイル・システム内に配置されている場合は、次の書式を使用します。

<property
name="oracle.composite.faultPolicyFile">file:/project/apps/fault-policies.xml
</property>

3. フォルト・ポリシー・ファイルのconditionセクションを定義します。

- このconditionセクションについては、次の点に注意してください。

- このセクションには、faultNameに基づいて条件を指定します。

- faultNameには、複数の条件を構成できます。

- 各条件には、1つのtestセクション(XPath式)と1つのactionセクションがあります。

- testセクション(XPath式)は、フォルト時に使用可能なフォルト変数に対して評価されます。

- actionセクションには、同じファイルに定義されているアクションへの参照があります。

- 問い合せることができるのは、フォルト時に使用可能なフォルト変数のみです。

- 条件の評価順序は、ドキュメントに記載されている順序によって決まります。

- 特定のエラー条件が発生した際に配信する条件(電子メール、JMSキューまたはログ・ファイル)と1つ以上のアラートを関連付けることができます。

表12-5 に、フォルト・ポリシー・ファイルのconditionセクションの例を示します。conditionセクションで定義される全アクションは、actionセクションにおけるアクションに関連付けられる必要があります。

表12-5 フォルト・ポリシー・ファイルでのconditionセクションの使用

条件の例

フォルト・ポリシー・ファイルの構文

この条件は、code = "WSDLFailure"のフォルト変数をチェックします。

ora-terminateのactionが指定されています。

<condition>
<test>$fault.code="WSDLReading Error"
</test>
<action ref="ora-terminate"/>
</condition>

test条件は指定されていません。これは、指定したfaultNameのcatchAll条件です。

<condition>
<action ref="ora-rethrow"/>
</condition>

2つのユーザー通知アラートが条件で定義されています。フォルト発生時に作成するユーザー通知アラートのタイプ(たとえば、電子メール・アラート、JMSキュー・アラートまたはログ・ファイル・アラート)を選択します。

<condition>
<alert ref = "ora-jms"/>
<alert ref = "ora-email"/>
<action ref="ora-rethrow"/>
</condition>

faultName名前属性がない場合は、任意のQNameのフォルトのcatchAllアクティビティを示します。

<faultName > . . . </faultName>

4. フォルト・ポリシー・ファイルのactionセクションを定義します。フォルト・ポリシー・ファイルの検証は、デプロイメント時に実施されます。フォルト・ポリシーを変更する場合は、フォルト・ポリシーが含まれているSOAコンポジット・アプリケーションを再デプロイする必要があります。

表12-6 に、フォルト・ポリシー・ファイルのactionセクションの例をいくつか示します。一部のフォルトには、自動リカバリ・アクションを指定できます。再試行と管理者操作を除くすべてのリカバリ・アクションでは、複数のアクションが同時に実行されます。

表12-6 フォルト・ポリシー・ファイルでのactionセクションの使用

リカバリ・アクション

フォルト・ポリシー・ファイルの構文

再試行: アクティビティを再試行するために、次のアクションが用意されています。

- 指定回数の再試行。

- 再試行から次の再試行までの遅延(秒単位)の指定。

- 指数バックオフによる再試行間隔の増加。

- N回の再試行が失敗となった場合の再試行失敗時アクションへのチェーン。

- 再試行が成功した場合の再試行成功時アクションへのチェーン。

注意: 指数バックオフでは、次の再試行が2倍のdelayでスケジュールされいて、このdelayは、現在の再試行間隔を示します。たとえば、現在の再試行間隔が2秒の場合、次の再試行間隔は4秒にスケジュールされ、その次は8秒、16秒と、retryCount値に達するまで増分されます。

<Action id="ora-retry">
<Retry>
<retryCount>3</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
<retryFailureAction ref="ora-java"/>
<retrySuccessAction ref="ora-java"/>
</Retry>
</Action>

次の詳細に注意してください。

- 再試行に成功した場合、フォルト管理フレームワークは、再試行成功時アクションにチェーンされます。

- すべての再試行に失敗した場合、フォルト管理フレームワークは、再試行失敗時アクションにチェーンされます。

管理者操作: 現在のアクティビティの処理が停止します。この場合は、Oracle Enterprise Manager Fusion Middleware Controlに移動して、このインスタンスに対するリカバリ・アクションを手動で実行できます。

<Action id="ora-human-intervention">
<humanIntervention/></Action>

プロセスの終了: プロセスを終了します。

<Action id="ora-terminate"><abort/></Action>

Javaコード: 外部Javaクラスを実行できます。

returnValue: 実装されるJavaクラスは、文字列を戻すメソッドを実装している必要があります。ポリシーは、戻された文字列に基づいて新しいアクションにチェーンできます。

詳細は、「Javaアクション・フォルト・ポリシーの使用方法」を参照してください。

<Action id="ora-java">
<!-- this is user provided custom java
class-->
<javaAction className="mypackage.myClass"
defaultAction="ora-terminate">
<returnValue value="REPLAY"
ref="ora-terminate"/>
<returnValue value="RETRHOW"
ref="ora-rethrow-fault"/>
<returnValue value="ABORT"
ref="ora-terminate"/>
<returnValue value="RETRY" ref="ora-retry"/>
<returnValue value="MANUAL"
ref="ora-human-intervention"/>
</javaAction>
</Action>

フォルトの再スロー: フォルトは、BPELフォルト・ハンドラ(scopeアクティビティ内のcatchアクティビティ)に送信されます。使用可能なハンドラがない場合、そのフォルトは上部に報告されます。

<Action id="ora-rethrow-fault"><rethrowFault/></Action>

スコープの再実行: 再実行フォルトが発生します。

<Action id="ora-replay-scope"><replayScope/></Action>

注意:

あらかじめシードされているリカバリ・アクションのタグ名(ora-retry、ora-human-intervention、ora-terminateなど)は、単なるサンプルです。これらの名前は各自の環境に適した名前に置換できます。

condition、actionおよびalertのセクションが完全に定義されているフォルト・ポリシー・ファイルは、次のようになります。

注意:

- フォルト・ポリシー・ファイルの名前は、単一の固有名に限定されているわけではありません。ただし、これらの名前は、fault-policy.xsdスキーマ・ファイルに準拠している必要があります。

- このフォルト・ポリシー・ファイルは、フォルト名に基づいてフォルトを捕捉する例を示しています。フォルトは、メッセージ・タイプまたはフォルト名(あるいはその両方)に基づいて捕捉することもできます。

<faultName name="myfault" type="fault:faultType">

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<faultPolicy version="2.0.1" id="ModifyAndRecover"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Conditions>
<!-- Handle remoteFault system exceptions -->
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:remoteFault">
<condition>
<!--<test>$fault.code="1"</test>-->
<alert ref = "ora-jms"/>
<alert ref = "ora-email"/>
<action ref="default-human-intervention"/>
</condition>
</faultName>
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:bindingFault">
<condition>
<action ref="default-human-intervention"/>
</condition>
</faultName>          </Conditions>
<Alerts>
<Alert id="ora-email">
<email>
<To>joe.smith@example.com</To>
<CC>joe.smith@example.com</CC>
</email>
</Alert>
<Alert id="ora-jms">
<JMS propertySet="jms-props">
<Headers>
<property name="correlationId">myvalue</property>
<property name="correlationId1">myvalue1</property>
</Headers>
</JMS>
</Alert>
</Alerts>
<Actions>
<!-- Generics -->
<Action id="default-terminate">
<abort/>
</Action>
<Action id="default-replay-scope">
<replayScope/>
</Action>
<Action id="default-rethrow-fault">
<rethrowFault/>
</Action>
<Action id="default-human-intervention">
<humanIntervention/>
</Action>
<Action id="ora-retry-with-human-intervention">
<retry>
<retryCount>1</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
<retryFailureAction ref="default-terminate"/>
</retry>
</Action>
</Actions>
<Properties>
<propertySet name="jms-props">
<property name="jmsDestination">MyQueue</property>
<property
name="connectionFactory">jms/fabric/ehconnectionfactory</property>
</propertySet>
</Properties>
</faultPolicy>
</faultPolicies>

12.4.3.2 フォルト・ポリシー・バインディングへのフォルト・ポリシーの関連付け

注意:

フォルト・ポリシー・バインディング・ファイルは、fault-bindings.xmlという名前にする必要があります。これは、fault-bindings.xsdスキーマ・ファイルに準拠しています。

フォルト・ポリシー・バインディングにフォルト・ポリシーを関連付ける手順は、次のとおりです。

1. フォルト・ポリシー・バインディング・ファイル(fault-bindings.xml)を作成します。このファイルは、フォルト・ポリシー・ファイルに定義されているポリシーを、使用しているフォルト・ポリシー・バインディング(SOAコンポジット・アプリケーションまたはコンポーネント(参照バインディング・コンポーネントまたはBPELプロセス/Oracle Mediatorのサービス・コンポーネント)のいずれか)のレベルに関連付けます。

2. 「自動フォルト・リカバリに対するフォルト・ポリシー・ファイルの手動作成」の手順2に示すように、composite.xmlファイルと同じディレクトリにファイルを置くか、ファイルをリモートの場所に置いてoracle.composite.faultBindingFileプロパティを定義します。

フォルト・ポリシー・バインディング・ファイルは、fault-policies.xmlファイルに定義されているフォルト・ポリシーを関連付けます。

<?xml version="1.0" encoding="UTF-8" ?>
<faultPolicyBindings version="0.0.1"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<composite faultPolicy="FusionMidFaults"/>
<!--<composite faultPolicy="ServiceExceptionFaults"/>-->
<!--<composite faultPolicy="GenericSystemFaults"/>-->
</faultPolicyBindings>

12.4.3.3 その他のフォルト・ポリシーおよびフォルト・ポリシー・バインディング・ファイルのサンプル

この項では、フォルト・ポリシーとフォルト・ポリシー・バインディング・ファイルのその他のサンプルを示します。次の例にfault-policies.xmlファイルの内容を示します。

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
<faultPolicy version="2.0.1"
id="CRM_ServiceFaults"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Conditions>
<!-- Fault if wsdlRuntimeLocation is not reachable -->
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:remoteFault">
<condition>
<test>$fault.code="WSDLReadingError"</test>
<action ref="ora-terminate"/>
</condition>
<condition>
<action ref="ora-java"/>
</condition>
</faultName>
<!-- Fault if location port is not reachable-->
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:bindingFault">
<!--ORA-00001: unique constraint violated on insert-->
<condition>
<test>$fault.code="1"</test>
<action ref="ora-java"/>
</condition>
<!--ORA-01400: cannot insert NULL -->
<condition>
<test xmlns:test="http://test">$fault.code="1400"</test>
<action ref="ora-terminate"/>
</condition>
<!--ORA-03220: required parameter is NULL or missing -->
<condition>
<test>$fault.code="3220"</test>
<action ref="ora-terminate"/>
</condition>
<condition>
<action ref="ora-retry-crm-endpoint"/>
</condition>
</faultName>
<!-- Business faults -->
<!-- Fault comes with a payload of error, make sure the name space is
provided here or at root level -->
<faultName xmlns:credit="http://services.otn.com"
name="credit:NegativeCredit">
<!-- you get this fault when SSN starts with 0-->
<condition>
<test>$fault.payload="Bankruptcy Report"</test>
<alert ref = "ora-email"/>
<action ref="ora-human-intervention"/>
<!--action ref="ora-retry"/-->
</condition>
<!-- you get this fault when SSN starts with 1-->
<condition>
<test>$fault.payload="Bankruptcy Report-abort"</test>
<action ref="ora-terminate"/>
</condition>
<!-- you get this fault when SSN starts with 2-->
<condition>
<test>$fault.payload="Bankruptcy Report-rethrow"</test>
<action ref="ora-rethrow-fault"/>
</condition>
<!-- you get this fault when SSN starts with 3-->
<condition>
<test>$fault.payload="Bankruptcy Report-replay"</test>
<action ref="ora-replay-scope"/>
</condition>
<!-- you get this fault when SSN starts with 4-->
<condition>
<test
xmlns:myError="http://services.otn.com">$fault.payload="Bankruptcy
Report-human"</test>
<action ref="ora-human-intervention"/>
</condition>
<!-- you get this fault when SSN starts with 5-->
<condition>
<test>$fault.payload="Bankruptcy Report-java"</test>
<action ref="ora-java"/>
</condition>
</faultName>
</Conditions>
<Actions>
<Action id="ora-retry">
<retry>
<retryCount>3</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
<retryFailureAction ref="ora-java"/>
<retrySuccessAction ref="ora-java"/>
</retry>
</Action>
<Action id="ora-retry-crm-endpoint">
<retry>
<retryCount>5</retryCount>
<retryFailureAction ref="ora-java"/>
<retryInterval>5</retryInterval>
<retrySuccessAction ref="ora-java"/>
</retry>
</Action>
<Action id="ora-replay-scope">
<replayScope/>
</Action>
<Action id="ora-rethrow-fault">
<rethrowFault/>
</Action>
<Action id="ora-human-intervention">
<humanIntervention/>
</Action>
<Action id="ora-terminate">
<abort/>
</Action>
<Action id="ora-java">
<!-- this is user provided class-->
<javaAction
className="com.oracle.bpel.client.config.faultpolicy.TestJavaAction"
defaultAction="ora-terminate" propertySet="prop-for-billing">
<returnValue value="REPLAY" ref="ora-terminate"/>
<returnValue value="RETRHOW" ref="ora-rethrow-fault"/>
<returnValue value="ABORT" ref="ora-terminate"/>
<returnValue value="RETRY" ref="ora-retry"/>
<returnValue value="MANUAL" ref="ora-human-intervention"/>
</javaAction>
</Action>
</Actions>
<Properties>
<propertySet name="prop-for-billing">
<property name="user_email_recipient">bpeladmin</property>
<property name="email_recipient">joe@abc.com</property>
<property name="email_recipient">mike@xyz.com</property>
<property name="email_threshold">10</property>
<property name="sms_recipient">+429876547</property>
<property name="sms_recipient">+4212345</property>
<property name="sms_threshold">20</property>
<property name="user_email_recipient">john</property>
</propertySet>
<propertySet name="prop-for-order">
<property name="email_recipient">john@abc.com</property>
<property name="email_recipient">jill@xyz.com</property>
<property name="email_threshold">10</property>
<property name="sms_recipient">+42222</property>
<property name="sms_recipient">+423335</property>
<property name="sms_threshold">20</property>
</propertySet>
</Properties>
</faultPolicy>
<faultPolicy version="2.0.1"
id="Billing_ServiceFaults"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Conditions>
<faultName>
<condition>
<action ref="ora-manual"/>
</condition>
</faultName>
</Conditions>
<Actions>
<Action id="ora-manual">
<humanIntervention/>
</Action>
</Actions>
</faultPolicy>
</faultPolicies>

次の例に、fault-policies.xmlに定義されているフォルト・ポリシーを関連付ける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">
<composite faultPolicy="ConnectionFaults"/>
<component faultPolicy="ServiceFaults">
<name>Component1</name>
<name>Component2</name>
</component>
<!-- Below listed component names use polic CRM_SeriveFaults -->
<component faultPolicy="CRM_ServiceFaults">
<name>HelloWorld</name>
<name>ShippingComponent</name>
<name>AnotherComponent"</name>
</component>
<!-- Below listed reference names and port types use polic CRM_ServiceFaults
-->
<reference faultPolicy="CRM_ServiceFaults">
<name>creditRatingService</name>
<name>anotherReference</name>
<portType
xmlns:credit="http://services.otn.com">credit:CreditRatingService</portType>
<portType
xmlns:db="http://xmlns.oracle.com/pcbpel/adapter/db/insert/">db:insert_
plt</portType>
</reference>
<reference faultPolicy="test1">
<name>CreditRating3</name>
</reference>
</faultPolicyBindings>

12.4.3.4 複数の拒否ハンドラがあるフォルト・ポリシーの設計

拒否メッセージのアクション・ハンドラを使用するフォルト・ポリシーを設計する際は、実行できる書込みアクションが1つのみであることに注意してください。次の例に示すように、複数の拒否ハンドラを定義している場合も、複数の書込みアクションは実行できません。この場合、定義されている最初の拒否ハンドラ(この例ではora-queue)のみが実行されます。

<faultName xmlns:rjm="http://schemas.oracle.com/sca/rejectedmessages"
name="rjm:FileIn">
<condition>
<action ref="ora-queue"/>
</condition>
</faultName>
<faultName xmlns:rjm="http://schemas.oracle.com/sca/rejectedmessages"
name="rjm:FileIn">
<condition>
<action ref="ora-file"/>
</condition>
</faultName>

12.4.4 フォルト・ポリシーの実行方法

フォルト・ポリシーは、SOAコンポジット・アプリケーションの一部としてデプロイします。デプロイメント後は、フォルト・リカバリ・アクションをOracle Enterprise Manager Fusion Middleware Controlから実行できます。終了、再試行、再スロー、Javaなどのアクションは、コンポジットの実行の一部として再試行されます。ユーザーが明示的に実行する必要ありません。管理者操作アクションはOracle Enterprise Manager Fusion Middleware Controlから手動で実行できます。

- アクティビティの再試行

- 変数の変更(フォルトが発生したアクティビティに使用可能)

- インスタンスの続行(アクティビティを成功としてマーク)

- 例外の再スロー

- インスタンスの中断

- スコープの再実行例外のスロー

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

12.4.5 Javaアクション・フォルト・ポリシーの使用方法

Javaアクション・フォルト・ポリシーを使用する際は、次の点に注意してください。

- 用意されているJavaクラスは、特定のインタフェースに従っています。このインタフェースは文字列を戻します。実行後に取得する出力およびフォルト・ポリシーには、複数の値を指定できます。

- 実装されているメソッドの出力値(戻り値)からフォルト・ポリシーへのマッピングを指定することで、追加のフォルト・ポリシーを実行できます。

- ReturnValueが指定されていない場合は、次の例に示すように、デフォルトのフォルト・ポリシーが実行されます。

<Action id="ora-java">
<javaAction className="mypackage.myclass"
defaultAction="ora-human-intervention" propertySet="prop-for-billing">
<!--defaultAction is a required attribute, but propertySet is optional-->
<!-- attribute-->
<ReturnValue value="RETRY" ref="ora-retry"/>
<!--value is not nilable attribute & cannot be empty-->
<ReturnValue value="RETRHOW" ref="ora-rethrow-fault"/>
</javaAction>
</Action>

表12-7 に、ReturnValueの使用例を示します。

表12-7 システムによるJavaアクション・フォルト・ポリシーの解釈

コード

説明

<ReturnValue value="RETRY"
ref="ora-retry"/>

メソッドからRETRYという文字列が戻された場合にora-retryアクションを実行します。

<ReturnValue value=""
ref="ora-rethrow"/>

検証は失敗です。

<javaAction
className="mypackage.myclass"
defaultAction="ora-human-intervention">

Javaコード実行後にora-human-interventionを実行します。この属性は、メソッドからの戻り値が指定のReturnValueと一致しない場合に使用されます。

<ReturnValue value="RETRY"
ref="ora-retry"/>
<ReturnValue value="" ref=""/>

検証は失敗です。

<javaAction
className="mypackage.myclass"
defaultAction=" ora-human-intervention">
<ReturnValue></ReturnValue>

検証は失敗です。

Javaクラスを起動するには、IFaultRecoveryJavaClassインタフェースを実装しているクラスを指定できます。IFaultRecoveryJavaClassは、fabric-runtime.jarファイルにあります。パッケージ名は、oracle.integration.platform.faultpolicyです。

次の例に示すように、IFaultRecoveryJavaClassインタフェースには2つのメソッドがあります。

public interface IFaultRecoveryJavaClass
{
public void handleRetrySuccess( IFaultRecoveryContext ctx );
public String handleFault( IFaultRecoveryContext ctx );
}

次の詳細に注意してください。

- handleRetrySuccessは、再試行に成功した場合に起動されます。再試行ポリシーは、retrySuccessActionのJavaアクションにチェーンします。

- handleFaultは、javaActionタイプのポリシーを実行する際に起動されます。

- フォルト・ポリシー・クラスは、次の2つのいずれかの方法でパッケージ化およびデプロイされます。

- SOAコンポジット・アプリケーションを使用してJavaクラスをパッケージ化します。

- Javaクラスを複数のSOAコンポジット・アプリケーションで共有する必要がある場合は、共有場所($MW_HOME/soa/soa/ modules/oracle.soa.ext_11.1.1など)に置きます。共有場所には、クラス・パスで使用できるようにするためのJavaクラスの配置方法を説明するreadmeファイルが含まれています。

次の例にIFaultRecoveryContextで使用可能なデータを示します。

public interface IFaultRecoveryContext {

/**
* Gets implementation type of the fault.
* @return
*/
public String getType();

/**
* @return Get property set of the fault policy action being executed.
*/
public Map getProperties();

/**
* @return Get fault policy id of the fault policy being executed.
*/
public String getPolicyId();

/**
* @return Name of the faulted partner link.
*/
public String getReferenceName();

/**
* @return Port type of the faulted reference .
*/
public QName getPortType();
}

このインタフェースのサービス・エンジン実装では、さらに詳細な情報が提供されます(例: Oracle BPEL Process Manager)。次の例に詳細を示します。

public class BPELFaultRecoveryContextImpl extends BPELXExecLetUtil implements
IBPELFaultRecoveryContext,  IFaultRecoveryContext{
...
}

次の例に示すように、Oracle BPEL Process Manager固有のデータは、IBPELFaultRecoveryContextを使用して入手できます。

public interface IBPELFaultRecoveryContext {
public void addAuditTrailEntry(String message);

public void addAuditTrailEntry(String message, Object detail);

public void addAuditTrailEntry(Throwable t);
/**
* @return Get action id of the fault policy action being executed.
*/
public String getActionId();

/**
* @return Type of the faulted activity.
*/
public String getActivityId();

/**
* @return Name of the faulted activity.
*/
public String getActivityName();

/**
* @return Type of the faulted activity.
*/
public String getActivityType();

/**
* @return Correleation id of the faulted activity.
*/
public String getCorrelationId();

/**
* @return BPEL fault that caused the invoke to fault.
*/
public BPELFault getFault();

/**
* @return Get index value of the instance
*/
public String getIndex(int i);

/**
* @return get Instance Id of the current process instance of the faulted
*         activity.
*/
public long getInstanceId();

/**
* @return Get priority of the current process instance of the faulted
*         activity.
*/
public int getPriority();

/**
* @return Process DN.
*/
public ComponentDN getProcessDN();

/**
* @return Get status of the current process instance of the faulted
*         activity.
*/
public String getStatus();

/**
* @return Get title of the current process instance of the faulted
*         activity.
*/
public String getTitle();

public Object getVariableData(String name) throws BPELFault;

public Object getVariableData(String name, String partOrQuery)
throws BPELFault;

public Object getVariableData(String name, String part, String query)
throws BPELFault;

/**
* @param priority
*            Set priority of the current process instance of the faulted
*            activity.
* @return
*/
public void setPriority(int priority);

/**
* @param status
*            Set status of the current process instance of the faulted
*            activity.
*/
public void setStatus(String status);

/**
* @param title
*            Set title of the current process instance of the faulted
*            activity.
* @return
*/
public String setTitle(String title);

public void setVariableData(String name, Object value) throws BPELFault;

public void setVariableData(String name, String partOrQuery, Object value)
throws BPELFault;

public void setVariableData(String name, String part, String query,
Object value) throws BPELFault;
}

次の例は、javaActionの実装例を示しています。

public class TestJavaAction implements IFaultRecoveryJavaClass {
public void handleRetrySuccess(IFaultRecoveryContext ctx) {
System.out.println("This is for retry success");
handleFault(ctx);
}
public String handleFault(IFaultRecoveryContext ctx) {
System.out.println("-----Inside handleFault-----\n" + ctx.toString());

dumpProperties(ctx.getProperties());
/* Get BPEL specific context here */
BPELFaultRecoveryContextImpl bpelCtx = (BPELFaultRecoveryContextImpl) ctx;
bpelCtx.addAuditTrailEntry("hi there");
System.out.println("Policy Id" + ctx.getPolicyId());
...
}

12.4.6 Oracle BPM Suiteに対してフォルト・ポリシーを設計する方法

Oracle BPM Suiteに対してフォルト・ポリシーを設計し、実行できます。詳細は、Oracle Business Process Management Studioを使用したビジネス・プロセスの開発の「BPMでのフォルト処理の使用」を参照してください。

12.4.7 フォルト・ポリシーを同期BPELプロセスで設計する方法に関する必知事項

フォルト・ポリシーを同期プロセスで設計する際、次のアクションを指定しないでください。これらのアクションによりデハイドレーションが同期プロセスで発生し、タイムアウトになる場合があります。

- 再試行

- 管理者操作

- Terminate

12.4.8 インスタンス再試行回数を超過した場合のフォルト管理動作に関する必知事項

インスタンスをリカバリするフォルト・ポリシーをora-retryアクションで構成し、指定したインスタンス再試行回数を超過すると、そのインスタンスはopen.faulted(進行中)としてマークされます。このインスタンスは引き続きアクティブです。

インスタンスをopen.faultedとしてマークすることで、そのインスタンスの消失が防止されます。フォルト・ポリシー・ファイルのora-retryアクションの後には、次のような別のフォルト処理アクションを構成できます。

- ora-human-interventionアクションを構成して、インスタンスのリカバリをOracle Enterprise Manager Fusion Middleware Controlから手動で実行します。

- ora-terminateアクションを構成し、インスタンスをクローズ(closed.faultedとしてマーク)して再試行されないようにします。

ただし、フォルト・ポリシー・ファイルでora-retryアクションの後に実行されるアクションを設定していない場合に、インスタンス再試行回数を超過すると、インスタンスはopen.faultedとしてマークされたままになり、リカバリはインスタンスの処理を試行します。

たとえば、次のコードに示すフォルト・ポリシー・ファイルでは、ora-retryの後にアクションが定義されていません。

<Action id="ora-retry">
<retry>
<retryCount>2</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
</retry>
</Action>

この場合は、次のアクションが実行されます。

- (前述のフォルト・ポリシー・コードを使用してフォルトを処理する)invokeアクティビティが試行されます。

- 間隔を増やして2回の再試行(2秒後、次に4秒後)が実行されます。

- すべての再試行に失敗した場合は、次のアクションが実行されます。

- 詳細なフォルト・エラー・メッセージが監査証跡に記録されます。

- インスタンスがopen.faulted(進行中)としてマークされます。

- インスタンスが選択され、invokeアクティビティが再試行されます。

- リカバリにも失敗する場合があります。その場合は、invokeアクティビティが再実行されます。追加の監査メッセージが記録されます。

12.4.9 フォルト・ポリシー再試行中のバインディング・レベル再試行に関する必知事項

アウトバウンド方向のJCAレベルの再試行とフォルト・ポリシー・ファイル内の再試行アクションの両方を備えたアダプタで、アウトバウンド障害に対する再試行アクションをテストしている場合は、そのJCAレベル(またはバインディング・レベル)再試行がフォルト・ポリシー再試行の中で実行されます。たとえば、図12-22 に示すアプリケーションを設計したとします。

図12-22 SOAコンポジット・アプリケーション

composite.xmlファイルでは、次に示す再試行パラメータを指定します。

<property name="jca.retry.count" type="xs:int" many="false"
override="may">2</property>
<property name="jca.retry.interval" type="xs:int" many="false"
override="may">2</property>
<property name="jca.retry.backoff" type="xs:int" many="false"
override="may">2</property>

アウトバウンド方向のEQ参照バインディング・コンポーネントのフォルト・ポリシー・ファイルでは、次のコードに示すアクションを指定します。

<retryCount>3</retryCount>
<retryInterval>3</retryInterval>

アウトバウンド障害が発生する場合は、フォルト・ポリシー再試行中にJCA再試行が実行されることが想定されます。フォルト・ポリシーの1回目の再試行時に、JCA再試行がコールされます。この例では、フォルト・ポリシーの再試行ごとに、間隔が2秒で指数バックオフが2のJCA再試行が2回実行されます。

- フォルト・ポリシー再試行1:

- JCA再試行1 (2秒間隔)

- JCA再試行2 (4秒間隔)

- フォルト・ポリシー再試行2:

- JCA再試行1 (2秒間隔)

- JCA再試行2 (4秒間隔)

- フォルト・ポリシー再試行3:

- JCA再試行1 (2秒間隔)

- JCA再試行2 (4秒間隔)

12.5 BPEL実行時フォルトの捕捉

BPEL実行時フォルトは、名前付きのBPELフォルトとして捕捉できます。bindingFaultおよびremoteFaultはメッセージに関連付けることができます。このアクションにより、faultHandlerでフォルトの詳細を取得できます。

12.5.1 BPEL実行時フォルトの捕捉方法

次の手順は、与えられた例を使用して、フォルトを生成し、それを捕捉するためのフォルト・ハンドラを定義する方法を示します。ここでは、WSDLファイルを変更してフォルトを生成し、捕捉するためのcatch属性を作成します。

BPEL実行時フォルトを捕捉する手順は、次のとおりです。

1. RuntimeFault.wsdlをプロセスWSDLにインポートします。RuntimeFault.wsdlは、そのデプロイメント時にsoa-infra-wls.ear内のsoa.marからMDSリポジトリにシードされます。

Oracle WebLogic ServerドメインにデプロイされたSOAインフラストラクチャには、RuntimeFault.wsdlが格納されているJAR/ZIPファイルsoa.marのコピーが表示されます。

2. messageType bpelx:RuntimeFaultMessageを使用して変数を宣言します。

3. 次の構文を使用して捕捉します。

<catch faultName="bpelx:remoteFault"  | "bpelx:bindingFault" faultName="varName">

12.6 getFaultAsString XPath式関数によるフォルト詳細の取得

可能なフォルトを捕捉できるようにcatchAllアクティビティが用意されています。ただし、BPELには、取得されたフォルトの詳細情報を取得するためのメソッドが用意されていません。詳細情報を取得するにはgetFaultAsString() XPath拡張関数を使用します。

12.6.1 getFaultAsString XPath拡張関数によるフォルト詳細の取得方法

次の例は、この関数の使用方法を示しています。

<catchAll>
<sequence>
<assign>
<from expression="bpelx:getFaultAsString()"/>
<to variable="faultVar" part="message"/>
</assign>
<reply faultName="ns1:myFault" variable="faultVar" .../>
</sequence>
</catchAll>

詳細は、「getFaultAsString」を参照してください。

12.7 throwアクティビティによる内部フォルトのスロー

BPELアプリケーションでは、フォルト・メッセージの生成および受取りができます。throwアクティビティには3つの要素(それ自体の名前、フォルトの名前およびフォルト変数)があります。throwアクティビティによってスローされるフォルトはBPEL内部のフォルトです。throwアクティビティは、クライアントと通信する非同期プロセスには使用できません。throwアクティビティの構文には、スロー名、フォルト名およびフォルト変数を指定します。

<throw name="delay" faultName="nsPrefix:fault-1" faultVariable="fVar"/>

12.7.1 throwアクティビティの作成方法

throwアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. throwアクティビティをデザイナにドラッグします。

3. throwアクティビティをダブルクリックして定義します。

4. 名前を入力するか、デフォルト値をそのまま使用します。

5. 「ネームスペースURI」フィールドの右側にある「検索」アイコンをクリックし、監視するフォルトを選択します。

6. 「フォルト・チューザ」ダイアログでフォルトを選択し、「OK」をクリックします。

選択したフォルトのネームスペースURIが「ネームスペースURI」フィールドに表示されます。選択したフォルトも「ローカル・パート」フィールドに自動的に表示されます。

図12-23 に、完成した「Throw」ダイアログの例を示します。

図12-23 「Throw」ダイアログ

7. 「適用」をクリックし、「OK」をクリックします。

12.7.2 throwアクティビティ作成時の処理内容

次の例に、設計完了後の.bpelファイルのthrowアクティビティを示します。このthrowアクティビティの実行後にOrderProcessorプロセスが終了します。

<throw name="Throw_Fault_CC_Denied"
faultName="client:OrderProcessorFault"/>

12.8 rethrowアクティビティによるフォルトの再スロー

rethrowアクティビティは、すぐ外側を囲んでいるフォルト・ハンドラによって最初に捕捉されたフォルトを再スローします。フォルト・ハンドラ内(catchアクティビティ、catchAllアクティビティ内など)では、rethrowアクティビティのみ使用します。rethrowアクティビティは、捕捉されたフォルト(元のフォルトのフォルト名およびフォルト・データ(存在する場合))を再スローするために、フォルト・ハンドラで使用されます。rethrowアクティビティは、フォルト・データに対する変更を無視する必要があります。次に例を示します。

- フォルト・ハンドラがフォルト・データを変更した後、rethrowアクティビティをコールした場合、元のフォルト・データが再スローされ、変更されたフォルト・データは再スローされません。

- 要素を使用して1つのパーツが定義されたメッセージ・タイプ・フォルトが、同じ要素タイプを検索しているフォルト・ハンドラによって捕捉されるようにする機能を使用してフォルトが捕捉された場合、rethrowアクティビティは元のメッセージ・タイプ・データを再スローします。

注意:

このアクティビティは、BPELバージョン2.0プロジェクトでサポートされています。

12.8.1 rethrowアクティビティの作成方法

rethrowアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. rethrowアクティビティをデザイナにドラッグします。

3. rethrowアクティビティをダブルクリックして定義します。

4. 図12-24 に示すように、必要に応じて名前を入力するか、デフォルト値をそのまま使用します。

図12-24 「Rethrow」ダイアログ

5. 「適用」をクリックし、「OK」をクリックします。

完了後、設計は図12-25 のようになります。

図12-25 BPELプロセスのthrowアクティビティ

12.8.2 フォルト再スロー時の処理内容

次の例に、rethrowアクティビティの設計が完了した後の.bpelファイルを示します。rethrowアクティビティはフォルト・ハンドラ(catchアクティビティ)の内側にあります。

<scope name="scope1">
<faultHandlers>
<catch faultName="tns:error" faultVariable="tmpVar"
faultElement="tns:fault">
<sequence>
<assign>
<copy>
<from>concat('caught fault: ', $tmpVar)</from>
<to>$output.payload</to>
</copy>
</assign>
<rethrow name="Rethrow_1"/>
</sequence>
</catch>
</faultHandlers>
<throw faultName="tns:error" faultVariable="fault"/>
</scope>

12.9 外部フォルトを返す

BPELプロセス・サービス・コンポーネントは、内部フォルトのスローとは対照的に、別のアプリケーションにフォルトを送信して問題を提示できます。同期操作では、replyアクティビティがフォルトを返すことができます。非同期操作では、invokeアクティビティがこの機能を実行します。

12.9.1 同期相互作用でフォルトを返す方法

次の例に、同期相互作用でフォルトを返すreplyアクティビティの構文を示します。

<reply partnerlinke="partner-link-name"
portType="port-type-name"
operation="operation-name"
variable="variable-name" (optional)
faultName="fault-name">
</reply>

同期リクエストに対して常にフォルトを返すことはあまり有効ではありません。それよりも、アクティビティを条件分岐に組み込み、リクエストされたデータを使用できる場合に最初のブランチが実行されるようにする方が効果的です。リクエストされたデータを使用できない場合、BPELプロセス・サービス・コンポーネントはそのことを示すフォルトを返します。

詳細は、次の章を参照してください。

- 同期相互作用については、「BPELプロセスからの同期Webサービスの起動」を参照してください

- 条件構造の設定については、「BPELプロセスでの条件分岐の使用」を参照してください

12.9.2 非同期相互作用でフォルトを返す方法

非同期相互作用では、クライアントはリプライを待機しません。このため、フォルトを返すためにreplyアクティビティが使用されることはありません。かわりに、BPELプロセス・サービス・コンポーネントは通常はリクエストされた情報を受け取る同じポート・タイプのコールバック操作を使用して、invokeアクティビティによってフォルトを返します。

非同期相互作用の詳細は、「BPELプロセスからの非同期Webサービスの起動」を参照してください。

12.10 scopeアクティビティによるアクティビティ・グループの管理

scopeアクティビティは、他のアクティビティに対してコンテナおよびコンテキストを提供します。scopeは、フォルト、イベント、補正、データ変数および相関セットに対するハンドラを提供します。scopeアクティビティを使用すると、機能構造をグループ化することでBPELフローが単純化されます。このグループ化により、Oracle BPELデザイナでは機能構造を閉じて1つの要素として表示できます。

次の例は、名前がScope_FulfillOrderであるscopeを示します。このscopeは、注文品の出荷方法を判断するFulfillOrder Oracle Mediatorコンポーネントを起動します。

<scope name="Scope_FulfillOrder">
<variables>
<variable name="lFulfillOrder_InputVariable"
messageType="ns17:requestMessage"/>
</variables>
<sequence>
<assign name="Assign_OrderData">
<copy>
<from variable="gOrderInfoVariable"
query="/ns4:orderInfoVOSDO"/>
<to variable="lFulfillOrder_InputVariable"
part="request" query="/ns4:orderInfoVOSDO"/>
</copy>
</assign>
<invoke name="Invoke_FulfillOrder"
inputVariable="lFulfillOrder_InputVariable"
partnerLink="FulfillOrder.FulfillOrder"
portType="ns17:execute_ptt" operation="execute"/>
</sequence>
</scope>

12.10.1 scopeアクティビティの作成方法

scopeアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. scopeアクティビティをデザイナにドラッグします。

3. scopeアクティビティをダブルクリックするか、「拡張」アイコンをクリックして、アクティビティを開きます。

4. 「コンポーネント」ウィンドウからアクティビティをドラッグして定義し、scope内に機能を作成します。図12-26に詳細を示します。

図12-26 開いた状態のscopeアクティビティ

5. 「OK」をクリックします。

完了後、scopeアクティビティの設計は図12-27 のようになります。この例では、「Scope_AuthorizeCreditCard」scopeアクティビティが表示されています。

図12-27 設計完了後のscopeアクティビティ

12.10.2 scopeアクティビティへの説明ノートおよびイメージの追加方法

scopeアクティビティには、スコープの機能に関する簡単な説明を提供する説明ノートを追加できます。スコープのグラフィック・イメージを変更することもできます。説明ノートおよびイメージは、Oracle BPELデザイナに表示されます。これらの表示により、スコープをより簡単に理解できるようになります。

説明ノートおよびイメージをscopeアクティビティに追加する手順は、次のとおりです。

1. 次のいずれかの手順を実行します。

- スコープを右クリックし、「ユーザー・ドキュメント」を選択します。

- スコープをダブルクリックし、「ユーザー・ドキュメント」タブを選択します。

「ドキュメント」ダイアログが表示されます。

2. 「コメント」フィールドに、スコープの機能に関する簡単な説明を入力します。

3. 「イメージ」フィールドで、必要に応じて「検索」アイコンをクリックし、スコープのグラフィック・イメージを変更します。

4. 「OK」をクリックします。

図12-28 に示すように、変更した結果がOracle BPELデザイナに表示されます。

図12-28 説明ノートが記載され、イメージが変更されたscope

5. 説明ノートを編集する場合は、説明ノートをダブルクリックします。

12.10.3 scopeアクティビティ作成後の処理内容

次の例に、設計完了後の.bpelファイルのscopeアクティビティを示します。Scope_AuthorizeCreditCard scopeアクティビティは、次のアクションを実行する各アクティビティで構成されています。

- クレジット・カード番号がない、またはクレジット・タイプが有効でないためにフォルトになった注文を捕捉するcatchアクティビティ。

- 承認されない注文に対してフォルトをスローするthrowアクティビティ。

- クレジット・カード・タイプ、クレジット・カード番号および購入金額を取得し、この情報をCreditCardAuthorizationServiceサービスの入力変数に割り当てるassignアクティビティ。

- CreditCardAuthorizationServiceサービスをコールして顧客情報を取得するinvokeアクティビティ。

- クレジット・カード検証の結果を確認するswitchアクティビティ。

<scope name="Scope_AuthorizeCreditCard">
<variables>
<variable name="lCreditCardInput"
messageType="ns2:CreditAuthorizationRequestMessage"/>
<variable name="lCreditCardOutput"
messageType="ns2:CreditAuthorizationResponseMessage"/>
</variables>
<faultHandlers>
<catch faultName="bpws:selectionFailure">
<sequence>
<assign name="Assign_noCCNumber">
<copy>
<from expression="string('CreditCardCheck - NO
CreditCard')"/>
<to variable="gOrderProcessorFaultVariable"
part="code"/>
</copy>
</assign>
<throw name ="Throw_NoCreditCard"
faultVariable="gOrderProcessorFaultVariable"
faultName="ns9:OrderProcessingFault"/>
</sequence>
</catch>
<catch faultName="ns2:InvalidCredit">
<sequence>
<assign name="Assign_InvalidCreditFault">
<copy>
<from expression="concat(bpws:getVariableData
('gOrderInfoVariable','/ns4:orderInfoVOSDO/
ns4:CardTypeCode'), ' is not a valid
creditcard type')"/>
<to variable="gOrderProcessorFaultVariable"
part="summary"/>
</copy>
<copy>
<from expression="string('CreditCardCheck - NOT VALID')"/>
<to variable="gOrderProcessorFaultVariable"
part="code"/>
</copy>
</assign>
<throw name="Throw_OrderProcessingFault"
faultName="ns9:OrderProcessingFault"
faultVariable="gOrderProcessorFaultVariable"/>
</sequence>
</catch>
</faultHandlers>
<sequence>
<assign name="Assign_CreditCheckInput">
<copy>
<from variable="gOrderInfoVariable"
query="/ns4:orderInfoVOSDO/ns4:OrderTotal"/>
<to variable="lCreditCardInput" part="Authorization"
query="/ns8:AuthInformation/ns8:PurchaseAmount"/>
</copy>
<copy>
<from variable="gOrderInfoVariable"
query="/ns4:orderInfoVOSDO/ns4:CardTypeCode"/>
<to variable="lCreditCardInput" part="Authorization"
query="/ns8:AuthInformation/ns8:CCType"/>
</copy>
<copy>
<from variable="gOrderInfoVariable"
query="/ns4:orderInfoVOSDO/ns4:AccountNumber"/>
<to variable="lCreditCardInput" part="Authorization"
query="/ns8:AuthInformation/ns8:CCNumber"/>
</copy>
</assign>
<invoke name="InvokeCheckCreditCard"
inputVariable="lCreditCardInput"
outputVariable="lCreditCardOutput"
partnerLink="CreditCardAuthorizationService"
portType="ns2:CreditAuthorizationPort"
operation="AuthorizeCredit"/>
<switch name="Switch_EvaluateCCResult">
<case condition="bpws:getVariableData('lCreditCardOutput','status','
/ns8:status') != 'APPROVED'">
<bpelx:annotation>
<bpelx:pattern>status &lt;&gt; approved</bpelx:pattern>
</bpelx:annotation>
<throw name="Throw_Fault_CC_Denied"
faultName="client:OrderProcessorFault"/>
</case>
/switch>
</sequence>
</scope>

12.10.4 スコープに関する必知事項

スコープは、CPU能力とメモリーを大量に使用する可能性があるため、過度の使用は避けてください。sequenceアクティビティを使用することで、CPUとメモリーの使用量を抑制し、大きいBPELフローを見やすくできます。

12.10.5 スコープ内のフォルト・ハンドラの使用方法

フォルトが処理されていない場合、フォルト状態が作成されてアプリケーション全体に移行し、プロセス全体がフォルト状態になることがあります。これを防ぐには、フォルトを受け取る可能性があるプロセスの一部をスコープ内に配置します。scopeアクティビティには、次のフォルト処理機能が含まれています。

- スコープ内ではcatchアクティビティが動作し、プロセス全体がフォルト状態になる前に、フォルトおよび例外を捕捉します。catchアクティビティで特定のフォルト名を使用し、個々のフォルトに特定の方法で対応できます。

- catchAllアクティビティは、名前が指定されたcatchアクティビティでは処理されないフォルトを捕捉します。

次の例に、catchおよびcatchAllアクティビティの構文を示します。x:fooという名前のフォルトがスローされたとします。フォルトがフォルト・データを渡さない場合は、最初のcatchが選択されます。フォルトに関連付けられたフォルト・データがある場合、フォルトのデータ・タイプが変数barタイプに一致すると、3番目のcatchが選択されます。そうでない場合、デフォルトのcatchAllハンドラが選択されます。最後に、タイプがbarのタイプに一致し、名前がx:fooでないフォルト変数を持つフォルトは2番目のcatchで処理されます。その他のすべてのフォルトはデフォルトのcatchAllハンドラによって処理されます。

<faulthandlers>
<catch faultName="x:foo">
<empty/>
</catch>
<catch faultVariable="bar">
<empty/>
</catch>
<catch faultName="x:foo" faultVariable="bar">
<empty/>
</catch>
<catchAll>
<empty/>
</catchAll>
</faulthandlers>

12.10.6 idempotentプロパティとフォルト処理に関する必知事項

composite.xmlファイルでidempotentデプロイメント・ディスクリプタのプロパティがfalseに設定されている場合、パートナ・リンクの起動が失敗しても、invokeアクティビティからリカバリは開始されません。invokeアクティビティの再試行をidempotentプロパティに依存することはお薦めいたしません。かわりに、BPELプロセス内に設計したフォルト処理(catchAllアクティビティの場合など)によって、リカバリを試みます。ベスト・プラクティスとして、かわりにフォルト・ポリシーを使用してinvokeアクティビティを再試行することをお薦めします。

表12-8 は、idempotentプロパティがfalseに設定されていて、パートナ・リンクの起動が成功した場合と失敗した場合の動作を示しています。

表12-8 idempotentプロパティがfalseに設定されている場合のリカバリ動作

パートナ・リンクの起動

結果

成功

invokeアクティビティは実行直後にデハイドレーションされ、デハイドレーション・ストアに記録されます。

不成功、かつBPELプロセスにcatchAllアクティビティなどのフォルト処理が含まれている

リカバリはcatchAllアクティビティから開始され、invokeアクティビティからは開始されません。

不成功、かつBPELプロセスにフォルト・ポリシーが含まれている

フォルト・ポリシーが使用されて、invokeアクティビティのリカバリが試みられます。これは、推奨アプローチです。

たとえば、BPELプロセスに次の設計が含まれているとします。

- invokeアクティビティによってパートナ・リンク(この例では、myPartnerLinkという名前です)が起動されます。

- composite.xmlファイルで、idempotentデプロイメント・ディスクリプタのプロパティがfalseに設定されています。

<property name="bpel.partnerLink.myPartnerLink.idempotent">false</property>

この設定により、BPELプロセスはこのアクティビティの実行直後にデハイドレーションされ、デハイドレーション・ストアに記録されます。

このプロパティは、「パートナ・リンクの編集」ダイアログでfalseに設定することもできます。図12-29に詳細を示します。

図12-29 「パートナ・リンクの編集」ダイアログの「冪等性」タブ

詳細は、「パートナ・リンク操作レベルでの冪等性の管理」を参照してください。

- scopeアクティビティのcatchAllアクティビティ・エラー・ハンドラによってフォルトが捕捉され、ロールバック・フォルトがスローされます。

パートナ・リンクに対するinvokeアクティビティによる起動が失敗した場合、リカバリはcatchAllアクティビティ・エラー・ハンドラから開始され、invokeアクティビティからは開始されません。Oracle Enterprise Manager Fusion Middleware ControlのBPELプロセスのflowアクティビティで、catchAllアクティビティからのリカバリを監視できます。

これは設計によります。idempotentプロパティの設定は、invokeアクティビティの実行の後に確認されます。実行に失敗し、例外が発生した場合、idempotentプロパティの設定には到達しません。BPELプロセス・サービス・エンジンによって、catchAllアクティビティを開いた直後のインスタンスが保存されます。idempotentプロパティがfalseに設定されているため、このインスタンスを保存する必要があります。これが、リカバリがcatchAllアクティビティで再開される理由です。

かわりに、失敗したinvokeアクティビティをフォルト・ポリシーでリカバリすることをお薦めします。フォルト・ポリシーの作成の詳細は、「フォルト管理フレームワークを使用したフォルトの処理」を参照してください。

idempotentプロパティの詳細は、「デプロイメント・ディスクリプタのプロパティの概要」を参照してください。

12.10.7 スコープでのcatchアクティビティの作成方法

スコープでcatchアクティビティを作成する手順は、次のとおりです。

1. 開いた状態のscopeアクティビティで、「Catchの追加」をクリックします。図12-30に詳細を示します。

図12-30 Catchの追加

これにより、scopeアクティビティの右側にcatchアクティビティが作成されます。

2. catchアクティビティをダブルクリックします。

3. 必要に応じて名前を入力します。

4. 「ネームスペースURI」フィールドの右側にある「検索」アイコンをクリックし、フォルトを選択します。

5. 「フォルト・チューザ」ダイアログでフォルトを選択し、「OK」をクリックします。

選択したフォルトのネームスペースURIが「ネームスペースURI」フィールドに表示されます。選択したフォルトも「ローカル・パート」フィールドに自動的に表示されます。

図12-31 に、「Catch」ダイアログの例を示します。この例では、「Scope_AuthorizeCreditCard」scopeアクティビティの「selectionFailure」catchアクティビティが表示されています。このcatchアクティビティは、クレジット・カード番号がない注文を捕捉します。

図12-31 「Catch」ダイアログ

6. 追加のフォルト処理機能を設計します。

7. 「OK」をクリックします。

図12-32 に、「Scope_AuthorizeCreditCard」scopeアクティビティに2つのcatchアクティビティがある例を示します。2番目のcatchアクティビティは、有効でないクレジット・タイプを捕捉します。

図12-32 デザイナに表示されたcatchアクティビティ

12.10.8 スコープでのcatchアクティビティ作成時の処理内容

次の例に、設計完了後の.bpelファイルのcatchアクティビティを示します。selectionFailure catchアクティビティはクレジット・カード番号がない注文を捕捉し、InvalidCredit catchアクティビティは有効でないクレジット・タイプを捕捉します。

<faultHandlers>
<catch faultName="bpws:selectionFailure">
<sequence>
<assign name="Assign_noCCNumber">
<copy>
<from expression="string('CreditCardCheck - NO CreditCard')"/>
<to variable="gOrderProcessorFaultVariable"
part="code"/>
</copy>
</assign>
<throw name ="Throw_NoCreditCard"
faultVariable="gOrderProcessorFaultVariable"
faultName="ns9:OrderProcessingFault"/>
</sequence>
</catch>
<catch faultName="ns2:InvalidCredit">
<sequence>
<assign name="Assign_InvalidCreditFault">
<copy>
<from expression="concat(bpws:getVariableData
('gOrderInfoVariable','/ns4:orderInfoVOSDO/ns4:CardTypeCode'), '
is not a valid creditcard type')"/>
<to variable="gOrderProcessorFaultVariable"
part="summary"/>
</copy>
<copy>
<from expression="string('CreditCardCheck - NOT VALID')"/>
<to variable="gOrderProcessorFaultVariable"
part="code"/>
</copy>
</assign>
<throw name="Throw_OrderProcessingFault"
faultName="ns9:OrderProcessingFault"
faultVariable="gOrderProcessorFaultVariable"/>
</sequence>
</catch>
</faultHandlers>

catchまたはcatchAllアクティビティが選択されていない場合、フォルトが現在のスコープによって捕捉されず、すぐ外側を囲んでいるスコープにスローされます。グローバル・プロセス・スコープでフォルトが発生し(またはグローバル・プロセス・スコープに再スローされ)、グローバル・レベルでフォルトに適合するフォルト・ハンドラがない場合、プロセスが異常終了します。これは、terminateアクティビティ(「BPEL 1.1のterminateアクティビティによるビジネス・プロセス・インスタンスの停止」で説明)が実行されたような状況になります。

12.10.9 emptyアクティビティによる操作なしの命令のビジネス・プロセスへの挿入方法

何もしないアクティビティが必要になることがよくあります。たとえば、フォルトを捕捉して抑制する必要がある場合などです。この場合、emptyアクティビティを使用すると、操作なしの命令をビジネス・プロセスに挿入できます。

emptyアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. emptyアクティビティをデザイナにドラッグします。

3. emptyアクティビティをダブルクリックします。

図12-33 に示すように、「Empty」ダイアログが表示されます。

図12-33 emptyアクティビティ

4. 必要に応じて名前を入力します。

5. 「OK」をクリックします。

12.10.10 emptyアクティビティ作成時の処理内容

次の例に、emptyアクティビティの構文を示します。

<empty standard-attributes>
standard-elements
</empty>

12.11 replayアクティビティによるscopeアクティビティ内でのアクティビティの再実行

scopeアクティビティ内にreplayを作成すると、スコープ内のすべてのアクティビティを再実行できます。

12.11.1 replayアクティビティの作成方法

replayアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「Oracle Extensions」を展開します。

2. replayアクティビティをデザイナにドラッグします。

3. replayアクティビティをダブルクリックします。

4. オプション名を入力します。

5. 図12-34 に示すように、再実行するスコープを選択します。

図12-34 「Replay」ダイアログ

6. 「適用」をクリックし、「OK」をクリックします。

7. scopeアクティビティの設計を続行します。

完了後、scopeアクティビティの設計は図12-35 のようになります。

図12-35 scopeアクティビティ内のreplayアクティビティ

12.11.2 replayアクティビティ作成時の処理内容

次の例は、BPELバージョン2.0をサポートするBPELプロジェクトのreplayアクティビティの設計が完了した後の、.bpelファイルを示しています。BPEL 2.0では、replayアクティビティはextensionActivity要素にラップされます。

<scope name="scope2">
<sequence>
<assign>
<copy>
<from>$counter2 + 1</from>
<to>$counter2</to>
</copy>
</assign>
<scope name="scope3">
<sequence>
<assign>
<copy>
<from>$counter + 1</from>
<to>$counter</to>
</copy>
</assign>
<if>
<condition>$counter = 3</condition>
<empty/>
<else>
<extensionActivity>
<bpelx:replay name="ReplayScope" scope="Scope_RetrieveOrder"/>
</extensionActivity>
</else>
</if>
</sequence>
</scope>
</sequence>
</scope>

BPEL 1.1では、replayアクティビティはbpelx拡張要素としてコード化されます。

<bpelx:replay name="ReplayScope" scope="Scope2"/>

12.12 一連の操作を元に戻した後の補正の使用

補正は、BPELプロセス・サービス・コンポーネントが一部の操作を完了した後で一連の操作を完了できず、引き返して前に完了したトランザクションを取り消す必要がある場合に発生します。たとえば、レンタカー、ホテルおよび航空券を予約するようにBPELプロセス・サービス・コンポーネントが設計されている場合、車とホテルは予約でき、その日付の航空券を予約できない場合があります。この場合、BPELフローは戻って車とホテルをキャンセルすることによって、補正を実行します。

scopeアクティビティでは、補正ハンドラは以前に完了した処理ステップをリバースできます。補正ハンドラは、次のいずれかのアクティビティを使用して関連するスコープが正常に完了した後に呼び出すことができます。

- compensateアクティビティ(BPELバージョン1.1および2.0プロジェクト)
このアクティビティにより、正常に完了したすべての子スコープ、およびまだ補正されていない子スコープの補正ハンドラが、デフォルトの順序で実行されます。

- compensateScopeアクティビティ(BPELバージョン2.0プロジェクト)
このアクティビティにより、正常に完了した特定のスコープの補正ハンドラが実行されます。

12.12.1 compensateアクティビティの使用

補正ハンドラは、compensateアクティビティを使用することによって起動でき、補正が実行されるスコープ(補正ハンドラが起動されるスコープ)を指定します。スコープの補正ハンドラは、スコープが正常に完了した場合にのみ起動できます。インストールされていない補正ハンドラを起動することは、emptyアクティビティ(操作なし)を使用することと同じです。これにより、フォルト・ハンドラは、ネストされたどのスコープが正常に完了したかを判断するために、状態を使用しなくても済むようになります。インストールされた補正ハンドラが複数回起動されているプロセスのセマンティクスは定義されていません。

compensateアクティビティを明示的に呼び出す機能は、のアプリケーションで制御されたエラー処理フレームワークの基礎となります。このアクティビティは、ビジネス・プロセスの次の部分でのみ使用できます。

- 補正が実行されるスコープのすぐ外側を囲んでいるスコープのフォルト・ハンドラ内。

- 補正が実行されるスコープのすぐ外側を囲んでいるスコープの補正ハンドラ内。

次に例を示します。

<compensate scope="RecordPayment"/>

名前によって補正されているスコープがループでネストされている場合、BPELプロセス・サービス・コンポーネントは一連の反復内で補正ハンドラ・インスタンスを逆の順序で起動します。

スコープの補正ハンドラがない場合、デフォルトの補正ハンドラは、すぐ内側に囲まれているスコープの補正ハンドラを、これらのスコープの完了と逆の順序で起動します。

補正フォームでcompensateアクティビティのスコープ名が省略されると、このデフォルトの動作が明示的に起動されます。これは、囲んでいるフォルトまたは補正ハンドラで追加の作業(変数の更新や外部通知の送信、および内側のスコープに対するデフォルト補正の実行など)を実行する必要がある場合に便利です。外側のスコープに付加されたフォルトまたは補正ハンドラのcompensateアクティビティにより、そのスコープ内に直接ネストされた完了スコープに対する補正ハンドラがデフォルトの順序で起動されます。このアクティビティは、外側のスコープ内にネストされたスコープの明示的な起動を除く、その他のユーザー指定の動作と一緒に使用できます。外側のスコープ内にネストされたこのスコープの補正を明示的に起動すると、デフォルトの順序の補正は、適切に機能しません。

12.12.2 compensateアクティビティの作成方法

compensateアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. compensateアクティビティをデザイナにドラッグします。

3. compensateアクティビティをダブルクリックします。

4. 図12-36 に示すように、補正ハンドラを起動するscopeアクティビティを選択します。

図12-36 compensateアクティビティ

5. 「適用」をクリックし、「OK」をクリックします。

12.12.3 compensateアクティビティ作成時の処理内容

scopeアクティビティにインラインで定義された補正ハンドラがある場合、アクティビティの名前はcompensateアクティビティに使用されるスコープの名前です。構文を次の例に示します。

<compensate scope="ncname"? standard-attributes>
standard-elements
</compensate>

12.12.4 BPEL 2.0のcompensateScopeアクティビティの使用

compensateScopeアクティビティは、すでに正常に完了している特定の内側のスコープで補正を開始するために使用されます。このアクティビティは、フォルト・ハンドラ、別の補正ハンドラまたは終了ハンドラ内からのみ使用します。

compensateScopeアクティビティを作成する場合、すぐ内側に囲まれているスコープを参照する必要があるターゲットを選択します。スコープにはフォルト・ハンドラまたは補正ハンドラを含める必要があります。

12.12.5 compensateScopeアクティビティの作成方法

注意:

このアクティビティは、BPEL 2.0プロジェクトでサポートされています。

compensateScopeアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. compensateScopeアクティビティをデザイナにドラッグします。

3. compensateScopeアクティビティをダブルクリックします。

4. 「ターゲット」リストで、補正ハンドラを起動する特定のscopeアクティビティを選択します。図12-37に詳細を示します。

図12-37 compensateScopeアクティビティ

5. 「適用」をクリックし、「OK」をクリックします。

12.12.6 compensateScopeアクティビティ作成時の処理内容

次の例に、compensateScopeアクティビティの設計が完了した後の.bpelファイルを示します。compensateScopeアクティビティは、catchallフォルト・ハンドラで定義されます。補正ハンドラを起動するスコープが定義されます。

<scope name="ScopeAssignCreditRating">
<faultHandlers>
<catchAll>
<compensateScope target="ScopeAssignScreditRating2" />
</catchAll>
</faultHandlers>
<sequence>
<scope name="ScopeAssignScreditRating2">
<compensationHandler>
<!-- undo work -->
</compensationHandler>
<!-- do some work -->
</scope>
<!-- do more work -->
<!-- a fault is thrown here; results of ScopeAssignScreditRating2 must be undone -->
</sequence>
</scope>

12.13 terminateアクティビティまたはexitアクティビティによるビジネス・プロセス・インスタンスの停止

次のいずれかのアクティビティを使用して、ビジネス・プロセス・インスタンスを停止できます。

- exitアクティビティ(BPELバージョン2.0プロジェクト)

- terminateアクティビティ(BPELバージョン1.1プロジェクト)

12.13.1 BPEL 2.0のexitアクティビティによるビジネス・プロセス・インスタンスの即時終了

exitアクティビティを使用すると、終了処理、フォルト処理または補正処理メカニズムを起動しなくても、すべてのパラレル・ブランチで現在実行中のすべてのアクティビティをただちに終了できます。このアクティビティは、予期しない重大な障害を処理するための適切な理由がない環境で使用すると便利です。

注意:

未処理の対話もexitアクティビティの影響を受けます。たとえば、プロセスと対話している他のパートナは、到着することのないレスポンスを待機する可能性があります。

12.13.1.1 exitアクティビティの作成方法

exitアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. exitアクティビティを、exitアクティビティを実行するBPELプロセスのセクションにドラッグします。

3. 図12-38 に示すように、exitアクティビティをダブルクリックします。

図12-38 exitアクティビティ

4. 必要に応じて名前を入力します。

5. 「適用」をクリックし、「OK」をクリックします。

完了後、BPELプロセス内のexitアクティビティは図12-39 のようになります。

図12-39 BPELプロセスのexitアクティビティ

12.13.1.2 exitアクティビティ作成時の処理内容

次の例に、exitアクティビティの設計が完了した後の.bpelファイルを示します。

<sequence>
<!-- receive input from requester -->
<receive name="receiveInput" partnerLink="client" portType="tns:Test"
operation="process" variable="input" createInstance="yes"/>
<assign>
<copy>
<from>$input.payload</from>
<to>$output.payload</to>
</copy>
</assign>
<!-- respond output to requester -->
<reply name="replyOutput" partnerLink="client"
portType="tns:Test" operation="process" variable="output"/>
<exit/>
</sequence>

12.13.2 BPEL 1.1のterminateアクティビティによるビジネス・プロセス・インスタンスの停止

terminateアクティビティは、そのterminateアクティビティが実行されるビジネス・プロセス・インスタンスの動作をただちに終了します。現在実行中のすべてのアクティビティは、フォルト処理または補正動作を実行せずにできるだけ早く終了する必要があります。terminateアクティビティは、BPELプロセス・サービス・コンポーネントのステータスの通知を送信しません。terminateアクティビティを使用する場合は、先に関係ユーザーに通知するようにプログラムしてください。

12.13.2.1 terminateアクティビティの作成方法

terminateアクティビティを作成する手順は、次のとおりです。

1. Oracle JDeveloperの「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. terminateアクティビティをデザイナにドラッグします。図12-40 に例を示します。

図12-40 terminateアクティビティ

3. terminateアクティビティをダブルクリックします。

4. 必要に応じて名前を入力します。

5. 「OK」をクリックします。

12.13.2.2 terminateアクティビティ作成時の処理内容

次の例に、terminateアクティビティの構文を示します。このアクティビティによってビジネス・プロセス・インスタンスが停止します。

<terminate standard-attributes>
standard-elements
</terminate>

12.14 アサーション条件によるフォルトのスロー

リクエスト/レスポンスinvokeアクティビティ、receiveアクティビティ、replyアクティビティ、およびpickアクティビティとscopeアクティビティのonMessageブランチで、コールバック・メッセージの受信時に実行されるBPELバージョン1.1および2.0でのアサーション条件を指定できます。アサーションは、falseと評価された場合に、アクティビティからBPELフォルトがスローされるXPath式を指定します。この条件は、パートナ・コールバック後に多数のswitch、assignおよびthrowアクティビティを作成する可能性がある場合の代替手段として提供されています。

条件を実行するタイミングを次の中から選択できます。

- Preassert: この条件は、invokeアクティビティまたはreplyアクティビティがアウトバウンド・メッセージを送信する前に実行されます。

- Postassert: この条件は、invokeアクティビティ、receiveアクティビティまたはonMessageブランチがインバウンド・メッセージを受信した後に実行されます。

12.14.1 アサーション条件の作成方法

次のアクティビティでアサーション条件を作成できます。

- invokeアクティビティ、receiveアクティビティ、replyアクティビティ、OnMessageブランチなどのメッセージ交換アクティビティ

- XPath式を指定するためのスタンドアロンassertアクティビティ

12.14.1.1 invokeアクティビティ、receiveアクティビティ、replyアクティビティおよびOnMessageブランチでアサート条件を作成する手順:

1. で、BPELプロセス・サービス・コンポーネントをダブルクリックします。

2. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

3. receiveアクティビティ、invokeアクティビティ、pickアクティビティまたはor scopeアクティビティをデザイナにドラッグします。

4. receiveアクティビティ、invokeアクティビティ、またはpickアクティビティまたはscopeアクティビティのonMessageブランチを開きます。

5. 「アサーション」タブをクリックします。

6. BPEL 2.0プロジェクトに対してアサーションを作成する場合は、次のタスクを実行します。それ以外の場合は、手順6に進みます。

a. 条件を実行するタイミングを選択します。表12-9に詳細を示します。

表12-9 アサーション条件のタブ

作成対象

選択対象

アサート前条件

「アサート前」タブ

アサート後条件

「アサート後」タブ

b. 図12-41 に示すように、「追加」アイコンをクリックします。

図12-41 BPEL 2.0における「アサーション」タブの「追加」アイコン

「Assert」ダイアログが表示されます。

7. BPEL 1.1プロジェクトに対してアサーションを作成する場合は、次のタスクを実行します。

a. 図12-42 に示すように、「追加」アイコンをクリックします。

図12-42 BPEL 1.1における「アサーション」タブの「追加」アイコン

b. 条件を実行するタイミングを選択します。表12-10に詳細を示します。

表12-10 条件実行のオプション

要素

説明

アサート前

選択すると、invokeアクティビティまたはreplyアクティビティがアウトバウンド・メッセージを送信する前に条件が実行されます。

注意: フォルト・ポリシーではpreAssert条件からスローされたフォルトは処理されません。postAssert条件からスローされたフォルトのみがサポートされています。フォルト・ポリシーの詳細は、「フォルト管理フレームワークを使用したフォルトの処理」を参照してください。

アサート後

選択すると、invokeアクティビティ、receiveアクティビティまたはonMessageブランチがインバウンド・メッセージを受信した後に条件が実行されます。

選択内容に基づいて、「アサート前」または「アサート後」ダイアログが表示されます。

8. 図12-43 に示すように、アサーション条件に値を指定します。この例では、BPEL 2.0プロジェクトのreceiveアクティビティのアサーション条件に「アサート後」が選択されています。

a. 「検索」アイコンをクリックして「フォルト・チューザ」ダイアログから既存のフォルトを選択し、スローする「フォルトQName」を選択します。フォルトの「ネームスペースURI」および「ローカル・パート」フィールドに、独自の値を指定することもできます。「フォルトQName」の指定を省略した場合は、bpelx:assertFailureフォルトがスローされます。

図12-43 アサーション条件の値

9. 完了後に「OK」をクリックして、アクティビティの「アサーション」タブに戻ります。図12-44 に示すように、完成したアサーション条件が表示されます。

図12-44 「アサーション」タブとそのデータ

10. 「適用」をクリックし、「OK」をクリックします。

12.14.1.2 スタンドアロンassertアクティビティのアサーション条件を作成する手順:

1. で、BPELプロセス・サービス・コンポーネントをダブルクリックします。

2. 「コンポーネント」ウィンドウで、「Oracle Extensions」を展開します。

3. 図12-45 に示すように、assertアクティビティをデザイナにドラッグします。

図12-45 「コンポーネント」ウィンドウのAssertアクティビティ

4. assert アクティビティを開きます。

5. 「式」フィールドの右側にある「XPath式ビルダー」アイコンをクリックします。

6. 式を作成します。

7. 完了後に、「OK」をクリックします。
「アサート」ダイアログは図12-46 のようになります。

図12-46 「アサート」ダイアログ

8. 「適用」をクリックし、「OK」をクリックします。

12.14.2 アサーションを無効にする方法

アサーションは、次のいずれかの方法で無効にできます。

- Oracle Enterprise Manager Fusion Middleware ControlでシステムMBeanブラウザ・プロパティDisableAssertsをtrueに設定する方法。

- 次の例に示すように、SOAコンポジット・アプリケーションのcomposite.xmlファイルで、bpel.config.disableAssertsをtrueに設定する方法。

<component name="AsyncBPELClient">
<implementation.bpel src="AsyncBPELClient.bpel"/>
<property name="bpel.config.disableAsserts">true</property>
</component>

システムMBeanブラウザ・プロパティを設定する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

12.14.3 アサーション条件作成時の処理内容

.bpelファイルのコード・セグメントは、特定の操作に対する設計完了後の定義を示しています。

次のBPEL1.1の例では、invokeアクティビティのbpelx:assert条件がfalseと評価された場合(たとえば、0の信用格付けが発行された場合)は、Negative Creditメッセージが返されます。条件がtrueと評価された場合は、invokeアクティビティからフォルトはスローされず、BPELプロセス・フローの残りのアクティビティが通常どおりに実行されます。

<invoke name="callbackClient" partnerLink="internalwarehouseservice_client"
portType="client:InternalWarehouseServiceCallback" operation="processResponse"
inputVariable="outputVariable">
<bpelx:assert name="negativeCredit"
expression="$crOutput.payload/tns:rating > 0"
message="Negative Credit"/>
</invoke>

次のBPEL 1.1の例では、スタンドアロンassertアクティビティのbpelx:assert条件がfalseと評価された場合は、次のメッセージが返されます。

got assertion failure on true expression

条件がtrueと評価された場合は、assertアクティビティからフォルトはスローされず、BPELプロセス・フローの残りのアクティビティが通常どおりに実行されます。

<bpelx:assert expression="true()bpws:getLinkStatus()" message="'got assertion
failure on true expression'"

12.14.4 アサーション条件に関する必知事項

この項では、主要なアサーション条件の概念について説明します。

12.14.4.1 bpelx:postAssertおよびbpelx:preAssert拡張要素

アクティビティに応じて、条件を実行するタイミングを指定するには、invokeアクティビティ、receiveアクティビティ、replyアクティビティ、およびpickアクティビティとscopeアクティビティのonMessageブランチの「アサーション」タブで「追加」アイコンをクリックし、「アサート前」または「アサート後」を選択します。選択内容に基づいて、次のbpelx拡張要素が使用されます。

- bpelx:preAssert: 「アサート前」を選択すると、invokeアクティビティまたはreplyアクティビティがアウトバウンド・メッセージを送信する前に条件が実行されます。

- bpelx:postAssert: 「アサート後」を選択すると、invokeアクティビティ、receiveアクティビティまたはonMessageブランチがインバウンド・メッセージを受信した後に条件が実行されます。

次の例は、BPEL 1.1におけるreceiveアクティビティ内の複数のbpelx:postAssert拡張要素を示しています。

<receive name="Receive_1" createInstance="no"
variable="Receive_1_processResponse_InputVariable"
partnerLink="AsyncBPELService"
portType="ns1:AsyncBPELServiceCallback"
bpelx:for="'PT10S'"
operation="processResponse">
<bpelx:postAssert name="assert1" expression="true()" message="'assert
true failed'" faultName="client:fault1"/>
<bpelx:postAssert name="assert2" expression="false()" message="'assert
false failed'" faultName="client:fault2"/>
</receive>

次の例に、BPEL 1.1におけるinvokeアクティビティ内の複数のbpelx:preAssert拡張要素を示します。

<invoke name="Invoke_1" inputVariable="Invoke_1_process_InputVariable"
outputVariable="Receive_1_processResponse_InputVariable"
partnerLink="SyncBPELService" portType="ns1:SyncBPELService"
operation="process">
<bpelx:preAssert name="assert1" expression="true()" message="'assert true
failed'"/>
<bpelx:preAssert name="assert2"
expression="bpws:getVariableData('counter') = 3" message="concat('The value of
counter is ', $counter)"/>

「アサーション」タブの使用の詳細は、「アサーション条件の作成方法」を参照してください。

12.14.4.2 faultName属性とmessage属性の使用

BPEL 1.1では、次の例のスキーマ定義に示すように、bpelx:postAssert要素のfaultName属性およびmessage属性を指定できます。

<invoke | receive | onMessage>
standard-elements
<bpelx:postAssert name="ncname"? expression="boolean-expr" faultName="QName"+
message="generic-expr"+/> *
</invoke | receive | onMessage>

次の例に、faultname属性とmessage属性の構文を示します。

<bpelx:postAssert name="Assert_2"
message='multiple post assert Greater value fired'
faultName="ns2:GreaterValue"
expression="bpws:getVariableData('invar','payload','/ns1:process/ns1:input') <
500"/>

faultName属性の指定がない場合、フォルトはbpelx:postAssertFailureにデフォルト設定されます。message属性の指定がない場合、メッセージ値はアクティビティの名前にデフォルト設定されます。

<bpelx:postAssert expression="boolean-expr" />

アサーション条件がfalseと評価されるたびに、指定のフォルトがスローされます。分析は、パートナWSDL portTypeに定義されているフォルトに正しく変換できるように、faultName QNameに対して実行されます。メッセージ式は、任意のXPath値のタイプ(string、numberまたはboolean)に評価できる一般的な式です。文字列でない値が返された場合は、値の文字列評価が使用されます。

12.14.4.3 複数のアサーション

receiveアクティビティ、invokeアクティビティ、またはpickアクティビティとscopeアクティビティのonMessageブランチでは、複数のアサーションをネストできます。アサーションの評価は、式がfalseと評価されるまでアサーションの宣言順に続行されます。次の例に詳細を示します。

<invoke name="invokeCR" partnerLink="creditRatingService"
portType="services:CreditRatingService" operation="process"
inputVariable="crInput" outputVariable="crOutput">
<bpelx:postAssert name="negativeCredit" expression="$crOutput.payload/tns:rating >
0"
faultName="services:NegativeCredit" message="'Negative Credit'"
/>
<bpelx:postAssert name="insufficientCredit"
expression="$crOutput.payload/tns:rating > 600"
faultName="services:InsufficientCredit" message="'Insufficient
Credit'" />
</invoke>

前の例では、レスポンスの信用格付けがゼロより大きいことを確認する式のアサーションが最初に評価されます。表12-11 に、このアサーションの動作を示します。

表12-11 アサーションの動作

返されたレスポンスの信用格付け

結果

ゼロ未満

services:NegativeCreditフォルトがスローされます。

ゼロ以上

アサーションが正しいため、2番目のアサーションが評価されます。

600未満

services:InsufficientCreditフォルトがスローされます。

600以上

アサーションが正しいため、invokeアクティビティからフォルトはスローされません。

アサーションは、いくつでもネストできます。アクティビティからフォルトがスローされないためには、指定したすべてのアサーションがtrueと評価される必要があります。

このコンストラクトを使用して、Javaのif...else if...else文と同様に、着信ペイロードに対して様々なレベルの検証を適用できます。

検証ロジックに関係なく、フォルトが常にスローされるようにするには、false()のアサーション式を指定します。これは、Javaのelseコンストラクトと同じです。

12.14.4.4 組込みおよびカスタムのXPath関数と$variable参照の使用

アサーション条件には、組込みおよびカスタムのXPath関数と$variable参照も使用できます。次のコードは、いくつかの例を示しています。

<bpelx:postAssert expression="bpws:getVariableData( 'crOutput', 'payload',
'/tns:rating' ) > 0" ... />

<bpelx:postAssert expression="custom:validateRating()" ... />

<bpelx:postAssert xmlns:fn='http://www.w3.org/2005/xpath-functions'
expression="fn:false()" ... />

XPath式の評価でエラーがスローされると、そのエラーはBPELフォルトにラップされて、アクティビティからスローされます。

アサーションの評価の失敗に起因して、リクエスト/レスポンスinvokeアクティビティ、receiveアクティビティ、またはpickアクティビティやscopeアクティビティのonMessageブランチからスローされるフォルトは、BPELのフォルト管理フレームワークによって捕捉および処理されます。詳細は、「フォルト管理フレームワークを使用したフォルトの処理」を参照してください。

BPELプロセス・フロー内で捕捉および処理されないフォルトは、操作に対するフォルトがコンポーネントWSDLで宣言されている場合は、BPELコンポーネントからスローされます。操作に対するフォルトが宣言されていない場合、フォルトはFabricInvocationException(実行時フォルト)に変換されます。このフォルトは、いずれかのコール元コンポーネント(BPELコンポーネントを含む)によって捕捉されますが、フォルトのタイプは、当初スローされたタイプではなくなります(ただし、フォルト・メッセージ文字列については、当初のフォルト・メッセージのトレースが保持されます)。

実行時フォルトの詳細は、「BPELフォルトのビジネスおよび実行時のフォルト・カテゴリの概要」を参照してください。

フォルト・ポリシーの詳細は、「フォルト管理フレームワークを使用したフォルトの処理」を参照してください。

12.14.4.5 インスタンス監査証跡に対するイベントのアサーション条件評価ロギング

評価される各アサーション条件によって、イベントがインスタンス監査証跡に記録されます。イベントは、アサーションが無事通過したか、失敗したのかを示します(失敗の場合は、フォルト名とメッセージが出力されます)。イベントも、アサーション要素で指定されたname属性を含みます。name属性が指定されていない場合、BPELプロセス・フローのアサーション要素の行番号が使用されます。監査イベントで出力されるアサーション条件は、アサーションを識別するのに便利で、フローをより円滑にデバッグできるようになります。

12.14.4.6 XMLスキーマ・ブール値タイプに評価されない式によるフォルトのスロー

アサーション条件XPath式がXMLスキーマ・ブール値タイプに評価されない場合は、アクティビティからbpelx:postAssertFailureフォルトがスローされます。エラーを示すインスタンス監査証跡のイベントも記録されます。次の例に詳細を示します。

<bpelx:postAssert expression="bpws:getVariableData( 'crOutput', 'payload',
'/tns:rating' ) > 0" ... />

<bpelx:postAssert expression="custom:validateRating()" ... />

<bpelx:postAssert xmlns:fn='http://www.w3.org/2005/xpath-functions'
expression="fn:false()" ... />

アサーション式の分析は、BPELコンパイラによって実行され、式がXMLスキーマ・ブール・タイプに評価されない場合は、エラーが報告されます。カスタムXPath関数では、このタイプの分析は実行されません。

12.14.4.7 スタンドアロンassertアクティビティのアサーション条件

BPELプロセス・サービス・コンポーネントのスタンドアロンassertアクティビティで、アサーション条件を作成することもできます。アサーションは、falseと評価された場合に、アクティビティからBPELフォルトがスローされるXPath式を指定します。

bpelx:assert拡張要素は、スタンドアロンassertアクティビティでアサーションを実装します。

<bpelx:assert name="Assert1" expression="string" message="string"/>

スタンドアロンassertアクティビティの使用方法の詳細は、「アサーション条件の作成方法」を参照してください。

12.14.5 アサート後およびアサート前条件のスキーマおよび構文に関する必知事項

アサーション条件は、ネストされた拡張要素として指定されます。次の例に、BPEL 2.0におけるアサート後条件のスキーマ定義を示します。

<invoke | receive | onMessage>
standard-elements
<bpelx:postAsserts>
<bpelx:postAssert faultName="QName">
<bpelx:expression expressionLanguage="anyURI"?>expression
</bpelx:expression>
<bpelx:message expressionLanguage="anyURI"?>expression</bpelx:message>
</bpelx:postAssert>
</bpelx:postAsserts>
</invoke | receive | onMessage>

次の例に、BPEL 2.0におけるアサート後条件の構文を示します。

<bpelx:postAsserts>
<bpelx:postAssert faultName="ns2:InvalidInput">
<bpelx:expression>number(concat($inputVariable.payload/client:input,'2')) <
500</bpelx:expression>
<bpelx:message>"AssertXpathPostInvoke_20 assert fired"</bpelx:message>
</bpelx:postAssert>
</bpelx:postAsserts>

次の例に、BPEL 1.1におけるアサート後条件のスキーマ定義を示します。BPEL 1.1とBPEL 2.0の差異に注意します。

<invoke | receive | onMessage>
standard-elements
<bpelx:postAssert name="ncname" expression="boolean-expr" faultName="QName"+
message="generic-expr"+/>
</invoke | receive | onMessage>

次の例に、BPEL 1.1におけるアサート後条件の構文を示します。

<bpelx:postAssert name="Assert_1"
message='Post Invoke Multiple assert value fired'
faultName="ns2:NegativeValue"
expression="bpws:getVariableData('invar','payload','/ns1:process/ns1:input') >
0"/>

次の例に、BPEL 2.0におけるアサート前条件のスキーマ定義を示します。

<invoke | reply>
standard-elements
<bpelx:preAsserts>
<bpelx:preAssert faultName="QName">
<bpelx:expression expressionLanguage="anyURI"?>expression</bpelx:expression>
<bpelx:message expressionLanguage="anyURI"?>expression</bpelx:message>
</bpelx:preAssert>
</bpelx:preAsserts>
</invoke | reply>

次の例に、BPEL 2.0におけるアサート前条件の構文を示します。

<bpelx:preAsserts>
<bpelx:preAssert faultName="ns1:InvalidInput">
<bpelx:expression>concat($inputVariable.payload/client:input,'2') >
$inputVariable.payload/client:input</bpelx:expression>
<bpelx:message>"AssertXpathPreInvoke_20 Assert test"</bpelx:message>
</bpelx:preAssert>
</bpelx:preAsserts>

次の例に、BPEL 1.1におけるアサート前条件のスキーマ定義を示します。BPEL 1.1とBPEL 2.0の差異に注意します。

<invoke | reply>
standard-elements
<bpelx:preAssert name="NCName" expression="string" message="string"
faultName="QName"/>
</invoke | reply>

次の例に、BPEL 1.1におけるアサート前条件の構文を示します。

<bpelx:preAssert name="Assert_1"
expression="bpws:getVariableData('invar','payload','/ns1:process/ns1:input') >
0"
message='pre invoke assert NegativeInput fired'
faultName="ns4:NegativeInput"/>

bpelx:postAssert拡張要素には、パートナからのコールバック・メッセージの受信時に評価するXPath式を指定します。アサーション式でfalseのブール値が返された場合は、指定のフォルトがアクティビティからスローされます。アサーション式でtrueのブール値が返された場合、フォルトはスローされず、通常のBPELプロセス・フローの場合と同様に、invokeアクティビティ、receiveアクティビティ、またはpickアクティビティとscopeアクティビティのonMessageブランチに続くアクティビティが実行されます。

bpelx:preAssertまたはbpelx:postAssert拡張要素は、Javaのassert文と同じです。Javaでは、assert式がtrueと評価されない場合は、JVMによってエラーが報告されます。同様に、bpelx:preAssertまたはbpelx:postAssert拡張要素の式もtrueと評価される必要があります。そうでない場合は、指定のフォルトがスローされます。

たとえば、次の例に示すBPEL 1.1のinvokeアクティビティでは、アサーション条件に指定したXPath式でfalseが返されると、NegativeCreditフォルトがスローされます。

<scope>
<faultHandlers>
<catch faultName="services:NegativeCredit" faultVariable="crError">
<empty/>
</catch>
</faultHandlers>
<sequence>
<invoke name="invokeCR" partnerLink="creditRatingService"
portType="services:CreditRatingService" operation="process"
inputVariable="crInput" outputVariable="crOutput">
<bpelx:postAssert name="negativeCredit"
expression="$crOutput.payload/tns:rating > 0"
faultName="services:NegativeCredit" message="'Negative
Credit'" />
</invoke>
</sequence>
</scope>

bpelx:preAssertまたはbpelx:postAssertのオプションのname属性は、監査証跡イベント・メッセージの作成時に使用されます。このインスタンスの名前を使用すると、複数のアサーションが指定されている場合にアサーション要素を識別できます。name属性の指定がない場合は、BPELファイル内のアサーション要素の行番号が使用されます。

12.15 再試行可能とのSOAPフォルトの分類

12c以降、外部サービスから返されたフォルト・コードに基づいて、すべてのWebサービスSOAPフォルトは自動的に再試行されません。フォルト・コードがサーバー関連(受信者関連とも呼ばれます)と分類された場合のみ、SOAPフォルトは再試行されます。クライアント関連と分類されたフォルト・コードでは、再試行が行われません。これは11gリリース1 (11.1.1.x)と異なります。そのリリースのOracle SOA Suiteではフォルト・コードに関係なくすべてのSOAPフォルトが再試行されました(返されるフォルトのすべてがbpelx:remoteFaultにBPELで変換され、再試行可能でした)。

12cでは、参照バインディング・コンポーネントでフォルトが発生すると、フォルト・コードがBPELプロセスに返されます。フォルト・コードの設定に基づいてフォルトが再試行されます。フォルトを特定の状況(システム停止時間問題など)でのみ再試行する場合があるので、これはメリットがあります。他のすべてのフォルト発生(正しくない入力など)では、再試行を行わない場合があります。実際、すべてのSOAPフォルトにおける再試行では、正当なメッセージの処理を遅らせることができます。

Simple Object Access Protocol (SOAP) 1.1仕様(http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383510)に記載されているように、フォルトにはサーバー(受信者とも呼ばれます)またはクライアントのコードを持たせることができます。フォルトの分類により、フォルトが再試行できるかどうかが判別されます。

- サーバー
メッセージの処理ではなくメッセージの内容に直接関連していない理由により、メッセージを処理できないことをサーバーのエラーが示します。たとえば、応答しなかったサーバーとの通信を処理に含めることができます。メッセージは後で成功する場合があります。これは再試行可能フォルトと定義されます。

- クライアント
メッセージが適切に形成されていなかったり、成功するために適切な情報が格納されていなかったことをクライアントのエラーが示します。たとえば、メッセージに適切な認証や支払い情報が欠落している場合があります。これは一般的に、メッセージ再送前に最初に変更する必要があることを示します。これは再試行不能フォルトと定義されます。

このフォルト分類情報は、FabricInvocationExceptionエラーに伝播されます。クライアント関連と分類されたフォルト・コードでは、この例外内のretryTypeフラグがNO_RETRYに設定されます。

必要に応じて、再試行をすべてのフォルトで起動できます。composite.xmlファイルでbinding.wsプロパティのoracle.soa.always.retry.on.faultをtrueに設定します。これによって、フォルト・コードに関係なく、Oracle SOA SuiteではSOAPフォルトで必ず再試行できます。

<reference name="myreference"
. . .
<binding.ws port=". . . ."
location=". . ."
<property name="oracle.soa.always.retry.on.fault">true</property>
</binding.ws>

13 BPELプロセスでのトランザクションおよびフォルト伝播のセマンティクス

この章では、Oracle BPEL Process Managerでのトランザクションおよびフォルト伝播のセマンティクスについて説明します。ここでは、コールを開始するBPELインスタンスのトランザクション動作の構成および一方向の起動の実行方法について説明します。トランザクションなしでビジネス・プロセスを実行する方法についても説明します。

この章の内容は次のとおりです。

- トランザクション・セマンティクスの概要

- 一方向起動の実行の概要

- トランザクションなしのビジネス・プロセスの実行

- システム・パフォーマンスの向上のためのメモリー内SOAの使用

13.1 トランザクション・セマンティクスの概要

リリース12cのトランザクション・セマンティクスでは、コンポーネントの実行に使用される基礎となるJava Transaction API (JTA)インフラストラクチャを使用できます。この項では、Oracle BPEL Process Managerのトランザクション・セマンティクスについて説明します。

13.1.1 Oracle BPEL Process Managerのトランザクション・セマンティクス

以前のリリースと同様に、Oracle BPEL Process Managerでは、デフォルトの場合、リクエストに基づいて新規のトランザクションが作成されます。つまり、トランザクションが存在する場合は、そのトランザクションが一時停止され、新規のトランザクションが作成されます。子(新規)トランザクションが完了すると、マスター(一時停止された)トランザクションが再開します。

ただし、リクエストが非同期(一方向)の場合、トランザクションには次のいずれかの処理が適用されます。

- デハイドレーション・ストア(dlv_message表)に挿入するために継承されます。

- トランザクションに透過的に登録されます(トランザクションがある場合)。

メッセージの損失はありません。起動メッセージは、処理のためにデハイドレーション・ストアに挿入されるか、フォルトを介して顧客に通知されます。

リリース10.1.3.xでは、消費側プロセス(つまり、パートナ・リンク)および提供側プロセスに、複数のプロパティを設定していました。これらのプロパティを使用することで、実行を単一のグローバル・トランザクションにチェーンできました。消費側では、bpel.xmlファイルのパートナ・リンク・バインディングにtransaction=participateを設定しました。提供側では、bpel.xmlの<configurations>セクションにtransaction=participateを設定しました。

リリース11gおよび12cでは、コールされるBPELコンポーネント(コール先プロセスと呼ばれます)にのみ、新しいtransactionプロパティを設定する必要があります。次のようにbpel.config.transactionを追加します。

- 新規BPELプロセスのための「BPELプロセスの作成」ダイアログ内。

- 既存のBPELプロセスのcomposite.xmlファイル内のBPELプロセス・サービス・コンポーネント・セクション内(bpel.config.の必須接頭辞に注意)。

このプロパティは、コールを開始するBPELインスタンスのトランザクション動作を構成します。この設定を後で変更する必要がある場合は、プロパティ・インスペクタを使用できます。

次の例に詳細を示します。

<component name="InternalWareHouseService" version="2.0">
<implementation.bpel src="BPEL/InternalWareHouseService.bpel"/>
<property name="bpel.config.transaction" type="xs:string"
many="false">required | requiresNew | notSupported " </property>
</component>

表13-1 は、required値(デフォルト値)およびrequiresNew値について説明し、設定に基づいたBPELインスタンスの動作の要約を示しています。

表13-1 bpel.config.transactionプロパティの動作

説明

bpel.config.transactionがrequiredに設定されている場合

bpel.config.transactionがrequiresNewに設定されている場合

リクエスト/レスポンス(開始)起動

トランザクションがある場合はコール元トランザクションが結合され、トランザクションがない場合は新規トランザクションが作成されます。

常に新規トランザクションが作成され、既存のトランザクションがある場合はそのトランザクションが一時停止されます。

bpel.config.oneWayDeliveryPolicyがsyncに設定されている一方向開始起動

起動されたメッセージは、同じトランザクションの同一スレッドを使用して処理されます。

常に新規トランザクションが作成され、既存のトランザクションがある場合はそのトランザクションが一時停止されます。

注意:

bpel.config.transactionプロパティは、中間プロセスのreceiveアクティビティには適用されません。この場合は、別のトランザクションの別のスレッドを使用してメッセージが処理されます。これは、相関が必要で常に非同期で処理されるためです。

bpel.config.transactionプロパティの設定方法の詳細は、「BPELプロセス・サービス・コンポーネントの追加方法」および「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。

次の各項では、bpel.config.transactionをrequiredまたはrequiresNewに設定した場合のトランザクションおよびフォルト動作について説明します。

13.1.1.1 bpel.config.transactionがrequiresNewに設定されているBPELCalleeプロセスがBPELCallerプロセスによってコールされる

表13-2 では、BPELCallerプロセスがBPELCalleeプロセスをコールします。BPELCalleeプロセスでは、bpel.config.transactionプロパティがrequiresNewに設定されています。表13-2 は、bpel.config.transactionがこの値に設定されている場合のフォルト伝播とトランザクション動作を示しています。

表13-2 bpel.config.transactionがrequiresNewに設定されているBPELCalleeへのBPELCallerによるコール

BPELCalleeの状態

BPELCalleeトランザクションの処理

BPELCallerの動作

フォルトでリプライ(<reply>を使用)した場合

保存されます。

フォルトを取得して捕捉します。

処理されないフォルトをスロー(<throw>を使用)した場合

ロールバックされます。

フォルトを取得して捕捉します。

フォルト(FaultOne)でリプライ後、フォルト(FaultTwo)をスローした場合

ロールバックされます。

FaultTwoを取得します。

bpelx:rollbackフォルトをスロー(<throw>を使用)した場合

ロールバックされます。

リモート・フォルトを取得します。

13.1.1.2 bpel.config.transactionがrequiredに設定されているBPELCalleeプロセスがBPELCallerプロセスによってコールされる

表13-3 では、BPELCallerプロセスがBPELCalleeプロセスをコールします。BPELCalleeプロセスでは、bpel.config.transactionプロパティがrequiredに設定されています。表13-3 は、bpel.config.transactionがこの値に設定されている場合のフォルト伝播とトランザクション動作を示しています。

表13-3 bpel.config.transactionがrequiredに設定されているBPELCalleeへのBPELCallerによるコール

BPELCalleeの状態

BPELCallerの動作

フォルトでリプライ(<reply>を使用)した場合

フォルトを取得して捕捉します。BPELCallerがトランザクションを所有します。したがって、トランザクションを捕捉した場合、トランザクションはコミットされます。BPELCallerが処理しない場合は、グローバル・ロールバックが発生します。

フォルトをスロー(<throw>を使用)した場合

フォルトを取得して捕捉します。

フォルト(FaultOne)でリプライ後、フォルト(FaultTwo)をスローした場合

FaultTwoを取得します。

bpelx:rollbackフォルトをスロー(<throw>を使用)した場合

そのトランザクション・ロールバックを取得します。そのロールバックを捕捉する方法はありません。このフォルトは処理されません。

たとえば、2つの同期プロセス(BPELMasterとBPELChild)を作成し、同じレコードを挿入する際にそれぞれが同じデータベース・アダプタ参照を使用するとします(したがって、権限キー(PK)違反が発生します)。双方にxADatasourceNameが設定されます。

bpel.config.transaction設定がないと、発生したフォルトは処理されず、BPELChildはロールバックされます。BPELMasterにcatchブロックがある場合、そのトランザクションはコミットされます。したがって、データベースのBPELMasterからのレコードで終了します。

BPELMasterでのフォルトも捕捉しなかった場合は、(2つの異なるトランザクションで)第2のロールバックを取得します。

同じテスト・ケースで、bpel.config.transactionがrequiredに設定され、フォルト・ハンドラが適切でない場合は、BPELMasterの未処理のフォルトに基づいてトランザクション全体がロールバックされます。

BPELChildからフォルトを捕捉してロールバック・フォルトをスローするように、BPELMasterにフォルト・ハンドラを追加すると、トランザクションはグローバルにロールバックされます。

この機能を使用して、トランザクション境界を管理し、エンドツーエンド・トランザクション・フローをモデル化できます(ソースおよびターゲットがトランザクションの場合)。

13.2 一方向起動の実行の概要

次の例に示すように、一方向起動(および可能性のあるコールバック)は、一般的にWSDLファイルで公開されます。

<wsdl:operation name="process">
<wsdl:input message="client:OrderProcessorRequestMessage"/>
</wsdl:operation>

これにより、BPELプロセス・サービス・エンジンでは実行が2つの部分に分割されます。

- 第1の部分(常にコール元トランザクション内)では、デハイドレーション・ストアのdlv_message表への挿入が行われます(リリース10.1.3.xでは、inv_message表に挿入されていました)。

- 第2の部分では、トランザクションおよび新規スレッドで作業アイテムが実行され、新規インスタンスが作成されます。

スレッドが使用可能な場合はサービス・エンジンのスレッド・プール(インボーカ・スレッド)で実行されるため、スケーラビリティの点で様々なメリットがあります。一方で、即時に実行される保証がないというデメリットがあります。

一方向の操作に基づく同期タイプのコールが必要な場合は、onewayDeliveryPolicyプロパティを使用できます。これは、リリース10.1.3.xのdeliveryPersistPolicyプロパティと同じです。

bpel.config.oneWayDeliveryPolicyを次のように指定します。

- 新規BPELプロセスのための「BPELプロセスの作成」ダイアログ内。

- 既存のBPELプロセスのcomposite.xmlファイルのBPELプロセス・サービス・コンポーネント・セクション内。

この値がcomposite.xmlに設定されていない場合は、Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザのoneWayDeliveryPolicyの値が使用されます。使用可能な値は、次のとおりです。

- async.persist: メッセージはデータベースに保存されます。この設定の場合、信頼性は確保されますが、データベースのパフォーマンスに多少の影響が出ます。システムの全体的なパフォーマンスに影響が出ることもあります。

- async.cache: 受信した配信メッセージはインメモリー・キャッシュにのみ保存されます。信頼性よりパフォーマンスを優先する場合は、この設定を検討してください。async.cacheに設定すると、一方向メッセージの到着頻度が配信の頻度よりかなり高い場合や、サーバー障害が発生した場合には、メッセージが失われる可能性があります。また、システムが過負荷の状態になり(メッセージがスケジュール済キューにたまり)、メモリー不足エラーが発生することもあります。各自のユースケース・シナリオを検討し、この設定が適切かどうかを判断してください。
高可用性環境でoneWayDeliveryPolicyをasync.cacheに設定すると、サーバー・クラッシュ発生時に実行途中の起動メッセージおよびコールバック・メッセージが失われたり、重複したりすることがあります。async.cacheに対しては、サーバーのフェイルオーバーはサポートされていません。詳細は、『高可用性ガイド』を参照してください。

- sync: 同じスレッドで直接起動が発生します。呼出しキューのメッセージのスケジューリングはバイパスされ、BPELインスタンスが同期的に呼び出されます。この設定は、データベースのパフォーマンスに影響を与えることがあります。

bpel.config.oneWayDeliveryPolicyプロパティの設定方法の詳細は、「BPELプロセス・サービス・コンポーネントの追加方法」および「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。

表13-4 は、メイン・プロセスがサブプロセスを非同期でコールする場合の動作を示しています。表13-4 は、「bpel.config.transactionがrequiresNewに設定されているBPELCalleeプロセスがBPELCallerプロセスによってコールされる」および「bpel.config.transactionがrequiredに設定されているBPELCalleeプロセスがBPELCallerプロセスによってコールされる」に記載されているユースケースに基づいています。

表13-4 メイン・プロセスによる非同期でのサブプロセスのコール

条件

サブプロセスがフォルトをスローした場合

サブプロセスがbpelx:rollbackをスローした場合

onewayDeliveryPolicy=async.persist

(BPELCalleeプロセスが別のスレッド/別のトランザクションで実行)

メッセージは配信サービスに保存されるため、BPELCallerはレスポンスを取得しません。フォルトが処理されない場合は、BPELCalleeトランザクションがロールバックされます。

メッセージは配信サービスに保存されるため、BPELCallerはレスポンスを取得しません。フォルトが処理されない場合は、BPELCalleeインスタンスがロールバックされます。

onewayDeliveryPolicy=sync

および

transaction=requiresNew

(BPELCalleeが同じスレッド/別のトランザクションで実行)

BPELCallerはFabricInvocationExceptionを受信します。フォルトが処理されない場合は、BPELCalleeトランザクションがロールバックされます。

BPELCallerはFabricInvocationExceptionを受信します。BPELCalleeトランザクションがロールバックされます。

onewayDeliveryPolicy=sync

および

transaction=required

(BPELCalleeが同じスレッド/同じトランザクションで実行)

BPELCalleeがフォルト状態になります。BPELCallerはFabricInvocationExceptionを受信します。BPELCallerにはフォルトを処理する機会があります。

トランザクション全体がロールバックされます。

onewayDeliveryPolicy=async.cache

および

transaction=requiresNew

または

transaction=required

リクエストが処理される前にコール元のスレッドが戻されるため、BPELCallerはレスポンスを取得しません。フォルトが処理されない場合は、BPELCalleeトランザクションがロールバックされます。メッセージは、データベースに保存されていないため、失われます。

リクエストが処理される前にコール元のスレッドが戻されるため、BPELCallerはレスポンスを取得しません。フォルトが処理されない場合は、BPELCalleeトランザクションがロールバックされます。メッセージは、データベースに保存されていないため、失われます。

13.3 トランザクションなしのビジネス・プロセスの実行

トランザクションを必要とせずにビジネス・プロセスを実行できます。トランザクションは、プロセス実行の次の場合にのみ使用されます。

- 内部の処理状態をバックエンド・データ・ストアに格納する必要がある場合のデハイドレーション・ポイント。

- プロセスの実行中に監査証跡やインスタンスのトラッキング関連データを格納する場合。

13.3.1 トランザクションなしでBPELプロセスを使用するタイミング

トランザクションなしでビジネス・プロセスを実行することは、次のようなシナリオで役立ちます。

- たとえば、flowNアクティビティが2000個のブランチを生成するBPELプロセスがあると仮定します。各ブランチでは、応答時間が500msであるリモート同期Webサービスが起動されます。BPELプロセス・サービス・エンジンではflowNブランチを単一スレッドで個別に実行するため、2000個のブランチすべてを処理し、それぞれで同期Webサービスを起動すると、所要時間は1000秒近くかかり、この処理中にインスタンスはデハイドレーション・ポイントにアクセスしません。トランザクションの時間は1000秒に及ぶ可能性があり、タイムアウトが発生する場合があります(デフォルトのトランザクション・タイムアウトの設定は300秒です)。すべてを直接メモリーで実行できます。その際、トランザクションは不要です。

- トランザクション期間は、ビジネス・プロセス実行のライフ・サイクルと結び付きます。たとえば、非同期BPELプロセスにreceiveアクティビティが含まれ、その後にassignアクティビティが続き、そこでは複雑なXSLトランスフォーメーションが大規模ドキュメントで実行され、所要時間が30秒になると仮定します。この後、クライアントへのコールバックが続きます。トランザクションで実行される場合、BPELプロセス・サービス・エンジンがトランザクションをreceiveアクティビティで起動し、インスタンス実行中にインスタンスのデータベース内部でロックを保持します。
別の方法として、すべてのアクティビティはメモリーで実行でき、エラーが発生すると廃棄できます。インスタンス実行中にデータベースの更新が発生しないため、トランザクションは必要ありません。インスタンス実行でBPELプロセス・サービス・エンジンでインスタンス状態などを更新するデハイドレーション・ポイントに達した場合にのみ、トランザクションが必要です。

- BPELプロセスが、同期していて、BPELプロセス・サービス・エンジンのJTAトランザクションに参加している別のサービスまたはパートナ・リンクを起動すると仮定します(たとえば、BPELプロセスで、TransactionAttribute=REQUIREDが設定されているTaskServiceBeanを起動する場合に、TaskServiceBeanタイムアウトがあり、トランザクションがロールバックされるなど)。BPELプロセス・サービス・エンジンのJTAトランザクションがロールバックされても、BPELプロセスではTaskServiceBeanのエラーを処理できません。

- ビジネス・プロセスが同期サービスを起動した場合、そのサービスが複雑な処理を長時間実行すると、BPELプロセス・サービス・エンジンのトランザクションがタイムアウトする場合があります。同期サービスが適切に実行されても、ビジネス・プロセスでリモート・サービスからレスポンスを取得すると、BPELプロセス・サービス・エンジンはロールバックされます。

13.3.2 トランザクションなしの実行に関するガイドライン

トランザクションなしでビジネス・プロセスを実行するには、「BPELプロセスの作成」ダイアログでBPELプロセスを作成するときに、「トランザクション」リストから「notSupported」を選択します。

設定すると、次の動作が発生します。

- XA分散トランザクションの利点がすべて無効になります。

- トランザクションに参加することを期待されているパートナ(つまり、パートナはTransactionAttributeがMANDATORYに設定されている)をビジネス・プロセスで起動できません。

- ビジネス・プロセスからの起動はfire-and-forgetです。(つまり、起動が終了すると、パートナに配信されます。起動元のトランザクションが後でロール・バックされる場合でも、起動メッセージはロール・バックされません)。

bpel.config.transactionがnotSupportedに設定されていても、デハイドレーション・ポイントは、内部BPELプロセス・エンジンの状態をバック・エンドに保存するためにトランザクションを開始します。これは、デハイドレーションの概念が引き続きビジネス・プロセスに適用されることを意味します。この機能では、assign、invokeやその他のアクティビティがトランザクションなしで実行されることのみが保証されます。

このプロパティは、コールを開始する場合にBPELインスタンスのトランザクション動作を構成します。表13-5 に、bpel.config.transactionのプロパティ設定に基づいたBPELインスタンスの動作を説明します。

表13-5 トランザクションのプロパティ設定に基づくBPELプロセス・インスタンス動作

トランザクション・タイプ

トランザクション設定が「requiresNew」

トランザクション設定が「required」

トランザクション設定が「notSupported」

リクエスト/レスポンス(開始)

新しいトランザクションが実行用に作成されます。既存のトランザクションがある場合はそのトランザクションが一時停止されます。

プロセスがコール元トランザクション(存在する場合)に参加するか、新規トランザクション(トランザクションがない場合)を作成します。

ビジネス・トランザクションのアクティビティはトランザクションなしで実行されます。トランザクションは、内部サービス・エンジンおよびインスタンスの状態や監査の詳細を保存するためにのみ使用されます。bpelx:rollbackフォルトはクライアントに伝播されません。現在のインスタンスはクライアントのトランザクションに参加していないからです。

一方向(開始、bpel.config.oneWayDeliveryPolicy=sync)

新規トランザクションが実行のために作成され、既存のトランザクションがある場合はそのトランザクションが一時停止されます。

起動メッセージは、同じトランザクションの同一スレッドを使用して処理されます。

ビジネス・トランザクションのアクティビティはトランザクションなしで実行されます。トランザクションは、内部サービス・エンジンおよびインスタンスの状態や監査の詳細を保存するためにのみ使用されます。bpelx:rollbackフォルトはクライアントに伝播されません。

一方向非同期

適用不可。

適用不可。

ビジネス・トランザクションのアクティビティはトランザクションなしで実行されます。トランザクションは、内部サービス・エンジンおよびインスタンスの状態や監査の詳細を保存するためにのみ使用されます。

13.3.3 トランザクションなしの同期BPELプロセスの作成方法

「BPELプロセスの作成」ダイアログで、トランザクションなしの同期BPELプロセスを作成できます。

トランザクションなしの同期BPELプロセスを作成する手順は、次のとおりです。

1. 「BPELプロセス・サービス・コンポーネントの追加方法」に従って、SOAコンポジット・アプリケーションにBPELプロセス・サービス・コンポーネントを作成します。

2. 「テンプレート」リストから、「同期BPELプロセス」を選択します。

3. 「トランザクション」リストから、「notSupported」を選択します。図13-1に詳細を示します。

図13-1 「BPELプロセスの作成」ダイアログ

4. 「OK」をクリックします。

13.3.4 トランザクションなしの非同期BPELプロセスの作成方法

「BPELプロセスの作成」ダイアログで、トランザクションなしの非同期BPELプロセスを作成できます。

トランザクションなしの非同期BPELプロセスを作成する手順は、次のとおりです。

1. 「BPELプロセス・サービス・コンポーネントの追加方法」に従って、SOAコンポジット・アプリケーションにBPELプロセス・サービス・コンポーネントを作成します。

2. 「テンプレート」リストから、「非同期BPELプロセス」を選択します。

3. 「配信」リストから「同期」を選択します。

ダイアログがリフレッシュされ、「トランザクション」リストが表示されます。

4. 「トランザクション」リストから、「notSupported」を選択します。図13-2に詳細を示します。

図13-2 「BPELプロセスの作成」ダイアログ

5. 「OK」をクリックします。

13.4 システム・パフォーマンスの向上のためのメモリー内SOAの使用

WebLogic Serverに関連付けられたCoherenceキャッシュを利用して、メモリー内の非トランザクションのビジネス・プロセスを実行できます。これにより、読取りおよび書込み操作がキャッシュから実行されるため、これらのビジネス・プロセスのパフォーマンスとスケーラビリティが向上します。また、連続したディスク読取りおよび書込みに関連するコストが大幅に削減されるため、データベース・パフォーマンスと管理も改善されます。

注意:
このSOA Suite機能は、Oracle Integration Continuous Availabilityの一部です。Oracle SOA Suite for Middlewareのオプションの詳細は、Oracle Fusion Middlewareライセンス情報を参照してください。

メモリー内SOAにより、短時間実行プロセスをメモリーに保持できます。フォルトが発生した場合のみ、またはwrite-behindスレッドを使用して一定の遅延間隔で、プロセスの状態がデータベースに書き込まれます。BPEL状態情報は、Coherenceキャッシュに/からデハイドレーションおよびリハイドレーションされます。

13.4.1 インメモリー・フロー・インスタンスに対する永続性の設定

ビジネス・フローを構成するコンポーネントの永続性の設定により、フロー、状態および監査データがキャッシュまたはデータベースにいつ保持されるかが決まります。このことは、Enterprise Manager Fusion Middleware Controlに表示されるフロー・インスタンス・データにも影響します。

表13-6 に、様々な永続性の設定と、フロー、状態、監査およびセンサー・データにそれが及ぼす影響を示します。

表13-6 インメモリー・フロー・インスタンスに対する永続性の設定

完了永続ポリシー

説明

Enterprise Managerでのビジネス・フロー・インスタンス

即時

フロー・トレース、BPEL監査トレースおよびフロー・インスタンス状態データは、常にデータベースに保持されます。

この動作は、メモリー内SOAが有効でない場合と同じです。

遅延

フロー、監査および状態のすべてのデータは、最初にCoherenceキャッシュに保持されます。個別のwrite-behindスレッドが、データベースへのキャッシュの遅延書込みを実行します。write-behindスレッドは定期的にウェイクアップします(デフォルトは5分)。
データベース・ラウンドトリップ数が削減され、write-behindスレッドがウェイクアップするたびに、融合されたデータのみがデータベースに書き込まれます。

Enterprise Manager Fusion Middleware Controlですべてのフロー・インスタンスが表示されます。
ただし、write-behindスレッドによるデータベースへの書込みは遅延間隔ごとであるため、フロー・データの更新はwrite-behindスレッドで決定された間隔で発生します。Enterprise Managerは、データベースからそのデータを読み取ります。

フォルト

正常な実行の場合、フロー・トレース、BPEL監査トレースおよびフロー・インスタンス状態データは保持されません。フローにフォルトが発生した場合は、すべてのデータがデータベースに保持されます。フローがリカバリされると、フロー・データはすべてパージされます。
コンポーネントがデハイドレーション・ポイントに到達した場合は、状態データがCoherenceキャッシュに保持されます。

書込み遅延間隔をまたぐ長時間実行フローの場合、write-behindスレッドでは実行中インスタンスの状態をデータベースに一時的に保持します。インスタンスの実行が完了すると、これらはパージされます。

faulted完了永続ポリシーを使用するフローの場合、フォルト・フロー・インスタンスを除いて、Enterprise Manager Fusion Middleware Controlにフロー・インスタンスは表示されません。
長時間実行フロー・インスタンスがwrite-behindスレッドによってデータベースに保持されている場合は、Enterprise Managerに一時的に表示される可能性があることに注意してください。ただし、フロー・インスタンスが完了すると、このデータはパージされます。

文字列値 immediate、deferredおよびfaultedは、大/小文字の区別はありません。

ビジネス・フローはコンポジットおよびコンポーネントをまたぐことができるため、異なる永続性の設定を持つコンポーネントを含むフローの永続性は、保持するコンポーネントによって決まります。そのため、1つのコンポーネントがデータベースに保持されるように構成されている場合でも、フローのすべてのコンポーネントがデータベースに保持されます。

たとえば、あるBPELコンポーネントは永続性がdeferredに設定されていて、同じフロー内の別のBPELコンポーネントは永続性がimmediateに設定されている場合、immediate設定はdeferred設定をオーバーライドし、すべてのフロー・インスタンス状態およびフロー監査トレース・データはただちにデータベースに保持されます。同様に、1つのコンポーネントがdeferredに設定されていると、それ以外のすべてのコンポーネントがfaultedに設定されていても、永続性の設定のデフォルトはdeferredとなり、フロー、状態および監査データが保持されます。

注意:

- コンポーネントの状態およびコンポーネントの監査トレースは、コンポーネントに適用されている永続ポリシーに基づいて保持されます。フロー・インスタンス状態およびフロー監査トレースは、オーバーライド・ルールによって決定されます。このため、immediateはdeferredをオーバーライドし、deferredはfaultedをオーバーライドします。

- センサー・データはフロー・データごとに保持されます。フローがデータベースに保持される場合は、センサー・データもデータベースに保持されます。

インメモリー・フローに対する書込み遅延

write-delayスレッドで使用されるデフォルトの間隔は5分です。これは、5分ごとにキャッシュからデータベースにデータがコピーされることを意味します。

たとえば、ほとんどのBPELプロセスが5分ではなく6分で完了し、かつ、データベースの書込みを減らすためにwrite-delayを調整することが求められるなどの理由で、これを変更する場合は、次のサーバー起動引数をSOAサーバーに設定できます。

-Dsoa.cache.writebehindDelay=6m

WebLogic Server管理コンソールを使用して、サーバー起動引数を設定できます。

13.4.2 メモリー内SOAを有効にする手順

メモリー内SOAを有効にするには、Enterprise Managerでメモリー内SOAフラグを設定する必要があります。また、非トランザクション・ビジネス・プロセスを設計し、適切な完了永続ポリシー(faultedまたはdeferred)を使用する必要があります。

次の手順が必要です。

1. メモリー内SOAフラグの有効化

2. メモリー内で実行するビジネス・プロセスの設計

13.4.2.1 メモリー内SOAフラグの有効化

メモリー内で実行するように設計した1つ以上のビジネス・フローがある場合は、Enterprise Manager Fusion Middleware ControlでInMemoryEnvironmentフラグを設定する必要があります。InMemoryEnvironmentフラグをtrueに設定すると(デフォルトはfalse)、この機能を使用するように設計されているコンポーネント、コンポジットおよびフローに対して、メモリー内でSOA実行が行われます。

次の手順を使用して、Enterprise Manager Fusion Middleware ControlでSOAインメモリー環境を設定します。

1. 「SOAインフラストラクチャ」メニューから、「SOA管理」→「共通プロパティ」の順に選択します。

または、コンポジット・ページの「SOAコンポジット」メニューから、「SOAインフラストラクチャの共通プロパティ」を選択することもできます。

「SOAインフラストラクチャの共通プロパティ」ページが表示されます。

2. ページの下部の「詳細SOAインフラ拡張構成プロパティ...」リンクをクリックします。
システムMBeanブラウザ・ページが表示されます。「アプリケーション定義のMBean」の下のsoa-infra MBeanの属性がアルファベット順で表示されます。

3. 「InMemoryEnvironment」属性までスクロールします。「値」フィールドをtrueに設定します。

4. ページの上部の「適用」をクリックします。

これで、SOAインメモリー環境が有効になりました。

13.4.2.2 メモリー内で実行するビジネス・プロセスの設計

メモリー内で実行するビジネス・フローを構成するには、すべての構成BPELコンポーネントを非トランザクションとして設計する必要があります。この時点では、Coherenceキャッシュはトランザクション動作をサポートしていないため、非トランザクション・ビジネス・プロセスにのみメモリー内SOAを使用できます。また、すべてのBPELプロセスの完了永続ポリシーをdeferredまたはfaultedに設定する必要があります。

BPELプロセスをメモリー内で実行できるようにするために新しいBPELプロセスを追加する場合は、次の設定を使用します。

1. 「BPELプロセスの作成」ダイアログの「一般」タブで、「トランザクション」に「notSupported」を選択します。

2. 「メモリー内SOA」タブを選択し、完了永続ポリシーを指定します。

13.4.2.2.1 非トランザクションとしての既存のビジネス・プロセスの設定

ビジネス・プロセスがメモリー内SOAを使用できるようにするには、プロセスを非トランザクションとして設定する必要があります。

JDeveloperで次の手順を使用して、BPELプロセスを非トランザクションとして設定します。

BPELプロセスを含むSOAコンポジットがJDeveloperで開いていることを確認します。

1. コンポジット・ビューで、BPELコンポーネントを選択します。
選択したBPELコンポーネントのプロパティが「プロパティ」ウィンドウに表示されます。「プロパティ」ウィンドウが表示されていない場合は、JDeveloperの「ウィンドウ」メニューから「プロパティ」を選択します。

2. 「プロパティ」ウィンドウにbpel.config.transactionプロパティが表示される場合は、そのプロパティを選択して「編集」をクリックします。または、「追加」ボタンをクリックしてプロパティを追加します。
「プロパティの編集」または「プロパティの作成」ダイアログが表示されます。

3. プロパティを追加している場合は、「名前」にbpel.config.transactionと入力します。

4. 「値」にnotSupportedと入力します。

5. 「OK」をクリックします。

「プロパティ」ウィンドウに、bpel.config.transactionプロパティが表示されます。「値」列にnotSupportedと表示されていることを確認します。

13.4.2.2.2 既存のBPELプロセスの完了永続ポリシーの設定

ビジネス・プロセスがメモリー内SOAを使用できるようにするには、完了永続ポリシーをdeferredまたはfaultedに設定する必要があります。BPELプロセスがデハイドレーション・ポイントを検出すると、状態情報がデータベースではなくメモリーにキャッシュされます。

JDeveloperで次の手順を使用して、BPELプロセスの完了永続ポリシーを設定します。

BPELプロセスを含むSOAコンポジットがJDeveloperで開いていることを確認します。

1. コンポジット・ビューで、BPELコンポーネントを選択します。
選択したBPELコンポーネントのプロパティが「プロパティ」ウィンドウに表示されます。「プロパティ」ウィンドウが表示されていない場合は、JDeveloperの「ウィンドウ」メニューから「プロパティ」を選択します。

2. 「追加」ボタンをクリックして、bpel.config.completionPersistPolicyプロパティを追加します。
「プロパティの作成」ダイアログが表示されます。

3. 「名前」にbpel.config.completionPersistPolicyと入力します。

4. 「値」にdeferredまたはfaultedと入力します。

5. 「OK」をクリックします。

「プロパティ」ウィンドウに、bpel.config.completionPersistPolicyプロパティが表示されます。「値」列にdeferredまたはfaultedと表示されていることを確認します。

14 BPELプロセスへのJavaおよびJava EEコードの組込み

この章では、JavaコードのセクションをSOAコンポジット・アプリケーションのBPELプロセス・サービス・コンポーネントに組み込む方法について説明します。ここでは、カスタム・クラスとJARファイルの追加方法、Java Embeddingアクティビティの使用方法、bpelx:execを使用したサービス・データ・オブジェクト(SDO)の埋込み方法、およびBPELプロセスと共有されるカスタム接続マネージャ・クラスの実装方法について説明します。

この章の内容は次のとおりです。

- BPELプロセスのJavaおよびJava EEコードの概要

- BPELプロセスへのJavaおよびJava EEコードの組込み

- カスタム・クラスおよびJARファイルの追加

- Oracle JDeveloperのBPELプロセスでのJava埋込みの使用

- bpelx:execによるサービス・データ・オブジェクトの埋込み

- Oracle BPEL Process Managerとのクラスのカスタム実装の共有

Springコンポーネントを起動することもできます。詳細は、「Spring Frameworkを使用したSOAコンポジット・アプリケーションへの統合」を参照してください。

14.1 BPELプロセスのJavaおよびJava EEコードの概要

この項では、JavaコードのセクションをBPELプロセスに組み込む方法について説明します。この方法は、必要な関数を実行できるEnterprise JavaBeansのコードが存在していて、BPELで最初から始めずにその既存のコードを使用する場合に特に役立ちます。

14.2 BPELプロセスへのJavaおよびJava EEコードの組込み

JavaおよびJava EEコードをBPELプロセスに組み込む方法は数種類あります。

- Simple Object Access Protocol (SOAP)サービスとしてラップする方法

- bpelx:execタグを使用してBPELプロセスにJavaコード・スニペットを埋め込む方法

- XML Facadeを使用してDOM操作を単純化する方法

- bpelx:exec組込みメソッドを使用する方法

- サービス・インタフェースにラップされたJavaコードを使用する方法

14.2.1 JavaコードをSOAPサービスとしてラップする方法

Javaコードは、SOAPサービスとしてラップできます。この方法では、JavaアプリケーションにBPEL互換のインタフェースが必要です。SOAPサービスとしてラップされたJavaアプリケーションは、他のWebサービスと同じように表示され、多様なアプリケーションで使用できます。また、SOAPラッパーの記述に使用できるツールもあります。

14.2.2 SOAPサービスとしてのJavaコードのラップに関する必知事項

SOAPサービスとしてラップされたJavaアプリケーションには、次の短所があります。

- JavaとSOAP間での変換の性質により、パフォーマンスが低下する場合があります。

- SOAPはトランザクションを本質的にはサポートしていないため、この方法ではアトミック・トランザクション性が失われます。つまり、複数の操作を、すべて実行するか、まったく実行しないという機能(ある銀行口座で借方記入し、別の口座で貸方記入するなど、両方のトランザクションを完了するか、どちらも完了しないかのどちらかなど)がありません。

14.2.3 bpelx:execタグを使用してBPELプロセスにJavaコード・スニペットを埋め込む方法

Javaコード・スニペットは、Java BPEL exec拡張要素bpelx:execを使用してBPELプロセスに直接埋め込むことができます。この方法の利点は、パフォーマンスに優れていることとトランザクション性が維持されることです。小さいコード・セグメントのみを組み込むことをお薦めします。BPELは、ビジネス・ロジックを実装から切り離します。プロセスの多数のJavaコードを削除すると、この切離しを維持できなくなります。Java埋込みは、ビジネス・コードではなく、短いユーティリティ系の操作を対象としています。ビジネス・ロジックは別の場所に配置し、配置したロジックをBPELからコールします。

サーバーは、bpelx:execアクティビティ内のJavaコード・スニペットをそのJava Transaction API (JTA)トランザクション・コンテキスト内で実行します。このBPELタグbpelx:execは、Java例外をBPELフォルトに変換し、BPELプロセスに追加します。Javaスニペットは、コールするセッションBeanとエンティティBeanに、そのJTAトランザクションを伝播できます。

たとえば、SessionBeanSample.bpelファイルは、次のコードに示すbpelx:execタグを使用して、invokeSessionBean Java Beanを埋め込みます。

<bpelx:exec name="invokeSessionBean" language="java" version="1.5">
<![CDATA[
try {
Object homeObj = lookup("ejb/session/CreditRating");
Class cls = Class.forName(
"com.otn.samples.sessionbean.CreditRatingServiceHome");
CreditRatingServiceHome ratingHome = (CreditRatingServiceHome)
PortableRemoteObject.narrow(homeObj,cls);
if (ratingHome == null) {
addAuditTrailEntry("Failed to lookup 'ejb.session.CreditRating'"
+ ". Ensure that the bean has been"
+ " successfully deployed");
return;
}
CreditRatingService ratingService = ratingHome.create();

// Retrieve ssn from scope
Element ssn =
(Element)getVariableData("input","payload","/ssn");

int rating = ratingService.getRating( ssn.getNodeValue() );
addAuditTrailEntry("Rating is: " + rating);

setVariableData("output", "payload",
"/tns:rating", new Integer(rating));
} catch (NamingException ne) {
addAuditTrailEntry(ne);
} catch (ClassNotFoundException cnfe) {
addAuditTrailEntry(cnfe);
} catch (CreateException ce) {
addAuditTrailEntry(ce);
} catch (RemoteException re) {
addAuditTrailEntry(re);
}
]]>
</bpelx:exec>

14.2.4 BPEL 2.0プロセスにJavaコード・スニペットを埋め込む方法

この章の例では主に、bpelx:exec拡張要素を使用してJavaコード・スニペットを埋め込む方法に重点を置いています。BPEL仕様のバージョン2.0をサポートするBPELプロジェクトの場合、構文が多少異なります。bpelx:exec拡張要素とJavaコードは<extensionActivity>要素にラップされます。次の例に詳細を示します。

<extensionActivity>
<bpelx:exec language="java">
<![CDATA[
java code
]]>
</bpelx:exec>
</extensionActivity>

Java EmbeddingアクティビティをOracle BPELデザイナのBPELプロセスにドラッグすると、<extensionActivity>要素とbpelx:execタグが自動的に追加されます。

次の例は、BPEL 2.0のimport構文を示しています。

<import location="class/package name"
importType="http://schemas.oracle.com/bpel/extension/java"/>

注意:

BPEL 2.0のimport構文は、次の構文を使用するBPEL 1.1の場合とは異なります。

<bpelx:exec import="class/package name"/>

次の例は、BPELバージョン2.0をサポートするプロジェクトの2つのJava Embeddingアクティビティを含むBPELファイルを示しています。

<process name="Test" targetNamespace="http://samples.otn.com/bpel2.0/ch10.9"
. . .
. . .
<import location="oracle.xml.parser.v2.XMLElement"
importType="http://schemas.oracle.com/bpel/extension/java"/>
. . .
<sequence>
. . .
<extensionActivity>
<bpelx:exec language="java">
XMLElement elem = (XMLElement) getVariableData("output", "payload");
elem.setTextContent("set by java exec");
</bpelx:exec>
</extensionActivity>

<extensionActivity>
<bpelx:exec language="java">
<![CDATA[XMLElement elem = (XMLElement) getVariableData("output",
"payload");
String t = elem.getTextContent();
elem.setTextContent(t + ", set by java exec 2");]]>
</bpelx:exec>
</extensionActivity>
. . .
</sequence>
</process>

このアクティビティの使用方法の詳細は、「BPELプロセスでのJava埋込みの使用」を参照してください。

14.2.5 XML Facadeを使用してDOM操作を単純化する方法

XML Facadeを使用してDOM操作を単純化できます。には、XMLの他に、Java Architecture for XML Binding (JAXB)に類似した軽量のJavaオブジェクト・モデル(Facadeと呼ばれます)が用意されています。XML Facadeは、スキーマを持つXML文書またはXML要素に対して、Java Beanのようなフロント・エンドを提供します。Facadeクラスを使用すると、Javaプログラム内でXML文書またはXML要素を簡単に操作できます。

XML Facadeを追加するには、.bpelファイルのbpelx:exec文内でcreateFacadeメソッドを使用します。次に例を示します。

<bpelx:exec name= ...
<![CDATA
...
Element element = ...
(Element)getVariableData("input","payload","/loanApplication/"):
//Create an XMLFacade for the Loan Application Document
LoanApplication xmlLoanApp=
LoanApplicationFactory.createFacade(element);
...

14.2.6 bpelx:exec組込みメソッドを使用する方法

表14-1 に、スコープ変数、インスタンス・メタデータおよび監査証跡の読取りと更新に使用できる一連のbpelx:exec組込みメソッドを示します。

表14-1 bpelx:exec用の組込みメソッド

" title="bpelx:exec用の組込みメソッド" width="100%">

メソッド名

説明

Object lookup( String name )

JNDIアクセス

long getInstanceId( )

各インスタンスに関連付けられている一意のID

String setTitle( String title ) / String getTitle()

このインスタンスのタイトル

String setStatus( String status ) / String getStatus()

このインスタンスのステータス

void setCompositeInstanceTitle(String title)

コンポジット・インスタンス・タイトルの設定

void setIndex( int i, String value ) / String getIndex( int i )

検索には6つの索引を使用可能

void setCreator( String creator ) / String getCreator()

このインスタンスの開始ユーザー

void setCustomKey( String customKey ) / String getCustomKey()

2番目の主キー

void setMetadata( String metadata ) / String getMetadata ()

リストを生成するためのメタデータ

String getPreference( String key )

アクセス・プリファレンス

void addAuditTrailEntry(String message, Object detail)

監査証跡へのエントリの追加

void addAuditTrailEntry(Throwable t)

アーカイブに格納されたファイルへのアクセス

Object getVariableData(String name) throws BPELFault

スコープ内に格納された変数へのアクセスおよび更新

Object getVariableData(String name, String partOrQuery) throws BPELFault

変数のアクセスおよび更新

Object getVariableData(String name, String part, String query)

変数のアクセスおよび更新

void setVariableData(String name, Object value)

変数データの設定

void setVariableData(String name, String part, Object value)

変数データの設定

void setVariableData(String name, String part, String query, Object value)

変数データの設定

14.2.7 サービス・インタフェースにラップされたJavaコードを使用する方法

すべてのアプリケーションがサービス・インタフェースを公開するわけではありません。ビジネス・プロセスでカスタムJavaコードが必要なシナリオもあります。このシナリオの場合は、次の操作を実行できます。

- カスタムJavaコードを記述します。

- コードを埋め込むサービス・インタフェースを作成します。

- SOAP経由で、JavaコードをWebサービスとして起動します。

たとえば、SOAP参照バインディング・コンポーネントでサービス・インタフェースを起動するSOAコンポジット・アプリケーションに、BPELプロセス・サービス・コンポーネントを作成すると仮定します。この例の場合、使用されるサービス・インタフェースは、Oracle Application Development Framework (ADF) Business Componentです。

このシナリオの高レベルな手順を次に示します。

サービス・インタフェースにラップされたJavaコードを使用する手順は、次のとおりです。

1. Oracle JDeveloperでOracle ADF Business Componentサービスを作成します。
この操作により、このサービスに対するWSDLファイルとXSDファイルが生成されます。

2. BPELプロセス・サービス・コンポーネントを含むSOAコンポジット・アプリケーションを作成します。そのBPELプロセス・サービス・コンポーネントはコンポジット・サービスとして公開されている必要があります。これにより、BPELプロセスがインバウンドSOAPサービス・バインディング・コンポーネントに自動的に接続されます。

3. Oracle ADF Business ComponentサービスWSDLをSOAコンポジット・アプリケーションにインポートします。

4. Oracle ADF Business Componentサービス・インタフェースにバインディングするWebサービスを作成します。

5. 次のタスクを実行するBPELプロセスを設計します。

a. Oracle ADF Business ComponentサービスportTypeのパートナ・リンクを作成します。

b. assignアクティビティを作成します。この例では、この手順により、データ(たとえば静的なXMLフラグメント)がOracle ADF Business Componentサービスに渡される変数にコピーされます。

c. invokeアクティビティを作成し、ステップ5.aで作成したパートナ・リンクに接続します。

6. パートナ・リンク参照をコンポジット参照バインディング・コンポーネントに接続(ワイヤ)します。この参照は、Webサービス・バインディングを使用して、Oracle ADF Business Componentサービスをリモートでデプロイできるようにします。

7. SOAコンポジット・アプリケーションをデプロイします。

8. Oracle Enterprise Manager Fusion Middleware Controlの「Webサービスのテスト」ページから、このSOAアプリケーションを起動します。

Oracle ADF Business Componentを作成する方法の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。

SOAコンポジット・アプリケーションを起動する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

14.3 カスタム・クラスおよびJARファイルの追加

SOAコンポジット・アプリケーションには、カスタム・クラスおよびJARファイルを追加できます。拡張クラスおよびJARをSOAコンポジット・アプリケーションに追加するためのSOA拡張ライブラリは、$ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1ディレクトリにあります。Oracle JDeveloperでは、カスタム・クラスおよびJARはapplication_name/project/sca-inf/libディレクトリに追加されます。

14.3.1 カスタム・クラスおよびJARファイルの追加方法

bpelx:execにクラスが使用されている場合は、Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで、BpelcClasspathプロパティを使用してJARも追加する必要があります。

14.3.1.1 JARをBpelcClasspathに追加する手順

1. 「SOAインフラストラクチャ」メニューから、「SOA管理」→「BPELプロパティ」の順に選択します。

2. 「BPELサービス・エンジン・プロパティ」ページの下部で、「詳細BPEL構成プロパティ」をクリックします。

3. 「BpelcClasspath」をクリックします。

4. 「値」フィールドに、クラスパスを指定します。

5. 「適用」をクリックします。

6. 「戻る」をクリックします。

また、JARはSOAコンポジット・アプリケーションによってロードされていることも必要です。

14.3.1.2 カスタム・クラスを追加する手順

1. classesディレクトリにクラスをコピーします。

2. Oracle WebLogic Serverを再起動します。

14.3.1.3 カスタムJARを追加する手順

1. このディレクトリまたはそのサブディレクトリにJARファイルをコピーします。

2. antを実行します。

3. Oracle WebLogic Serverを再起動します。

14.4 Oracle JDeveloperのBPELプロセスでのJava埋込みの使用

Oracle JDeveloperでは、bpelx:execアクティビティを追加して、コード・スニペットをダイアログにコピーできます。

注意:

カスタム・クラスの場合は、Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで、BpelcClasspathプロパティに、埋込みJavaコードに必要なJARファイルを指定する必要があります。手順は、「カスタム・クラスおよびJARファイルの追加方法」を参照してください。これにより、JARファイルがBPELローダーのクラスパスに追加されます。複数のJARファイルを設定する場合は、UNIXではコロン(:)、Windowsではセミコロン(;)を使用して区切る必要があります。

14.4.1 Oracle JDeveloperのBPELプロセスでのJava埋込みの使用方法

Oracle JDeveloperのBPELプロセスでJava埋込みを使用する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「Oracle Extensions」を展開します。

2. Java Embeddingアクティビティをデザイナにドラッグします。

3. Java Embeddingアクティビティをクリックして、そのプロパティ・フィールドをプロパティ・インスペクタで表示するか、Java Embeddingアクティビティをダブルクリックし、「Java埋込み」ダイアログを表示します。

アクティビティをプロパティ・インスペクタで編集する方法の詳細は、「BPELアクティビティをプロパティ・インスペクタで編集する方法」を参照してください。

4. 「名前」フィールドに、名前を入力します。

5. 「コード・スニペット」フィールドにJavaコードを入力します(または切り取って貼り付けます)。図14-1に詳細を示します。

図14-1 bpel:execコード例

注意:

Java EmbeddingアクティビティにJavaコードを記述するかわりに、Javaコードを配置したJARファイルをクラスパスに設定し、Java Embeddingアクティビティ内からメソッドをコールすることもできます。

14.4.2 Java Embeddingアクティビティでのthread.sleep()の使用に関する必知事項

Java Embeddingアクティビティでthread.sleep()を使用するBPELプロセスを作成してデプロイすると、実行スレッドがブロックされ、そのスレッドに関連付けられているトランザクションをコミットできません。その結果、待機の終了後にのみBPELインスタンスが表示されますが、これは想定されている動作です。

かわりに、waitアクティビティを使用します。このアクティビティを使用すると、入力時にリソースが解放され、進行中のトランザクションのコミットと、データ・ストアへのBPELインスタンス・データのハイドレーションが可能になります。

14.5 bpelx:execによるサービス・データ・オブジェクトの埋込み

SDOコードは、bpelx:execタグを使用して.bpelファイルに埋め込むことができます。次の例の構文では、mytest.apps.SDOHelperがSDOを変更するJavaクラスです。

</bpelx:exec>
<bpelx:exec name="ModifyInternalSDO" version="1.5" language="java">
<![CDATA[try{
Object o = getVariableData("VarSDO");
Object out = getVariableData("ExtSDO");
System.out.println("BPEL:Modify VarSDO... " + o + " ExtSDO: " + out);
mytest.apps.SDOHelper.print(o);
mytest.apps.SDOHelper.print(out);
mytest.apps.SDOHelper.modifySDO(o);
System.out.println("BPEL:After Modify VarSDO... " + o + " ExtSDO: " + out);
mytest.apps.SDOHelper.print(o);
mytest.apps.SDOHelper.print(out);
}catch(Exception e)
{
e.printStackTrace();
}]]>
</bpelx:exec>

次の例は、BPELファイルに埋め込まれているmodifySDO(o)およびprint(o)というJavaクラスの例を示しています。

public static  void modifySDO(Object o){
if(o instanceof commonj.sdo.DataObject)
{
((DataObject)o).getChangeSummary().beginLogging();
SDOType type = (SDOType)((DataObject)o).getType();
HelperContext hCtx = type.getHelperContext();
List<DataObject>  lines =
(List<DataObject>)((DataObject)o).get("line");
for (DataObject  line: lines) {
line.set("eligibilityStatus", "Y");
}
} else {
System.out.println("SDOHelper.modifySDO(): " + o + " is not a
DataObject!");
}
}
. . .
. . .
public static  void print(Object o)    {
try{
if(o instanceof commonj.sdo.DataObject)
{
DataObject sdo = (commonj.sdo.DataObject)o;
SDOType type = (SDOType) sdo.getType();
HelperContext hCtx = type.getHelperContext();
System.out.println(hCtx.getXMLHelper().save(sdo, type.getURI(),
type.getName()));
} else {
System.out.println("SDOHelper.print(): Not a sdo " + o);
}
}catch(Exception e)
{
e.printStackTrace();
}          }

14.6 Oracle BPEL Process Managerとのクラスのカスタム実装の共有

Oracle BPEL Process Managerで使用されるクラスと同じ名前を持つカスタム接続マネージャ・クラスを実装する場合、カスタム・クラスがOracle BPEL Process Managerで使用されるクラスをオーバーライドしないことを確認する必要があります。

たとえば、次のことを想定します。

- BPELプロジェクトで埋込みJavaを使用しています。

- 接続マネージャ・カスタム・クラスは、BPEL接続マネージャ・クラスをオーバーライドしています。

- 実行時にjava.lang.NoClassDefFoundErrorが発生しています。

14.6.1 BPEL接続マネージャ・クラスが優先されるように構成する方法

BPEL接続マネージャ・クラスが優先されるように構成する手順は、次のとおりです。

1. Oracle JDeveloperを起動します。

2. BPELプロジェクトを強調表示します。

3. 「編集」メイン・メニューから、「プロパティ」を選択します。

4. 「ライブラリとクラスパス」を選択します。

5. 「JAR/ディレクトリの追加」をクリックします。

6. カスタムJARファイルのある場所まで移動し、「選択」をクリックします。

クラスパスにカスタム接続マネージャのJARファイルが追加されます。

7. 「OK」をクリックします。

8. BPELプロジェクトを再デプロイして再テストします。

15 BPELプロセスでのイベントおよびタイムアウトの使用

この章では、イベントおよびタイムアウトの使用方法について説明します。ここでは、プロセスの続行または待機を選択するpickアクティビティの作成、receiveアクティビティに対するリクエスト/レスポンス操作のタイムアウト設定、有効期限を設定するためのwaitアクティビティの作成、メッセージ着信を待機するためのBPEL 2.0でのOnEventブランチの作成、同期プロセスのタイムアウト設定およびBPELプロセスでのOracle Enterprise Schedulerジョブの起動を行う方法について説明します。

この章の内容は次のとおりです。

- イベントおよびタイムアウトの概念に関する概要

- 「pickアクティビティのプロセスの待機または継続の選択」

- 「receiveアクティビティのリクエスト/リプライ操作および入力専用操作に対するタイムアウトの設定」

- waitアクティビティによる有効期限の設定

- BPEL 2.0のOnEventブランチを使用してメッセージ着信を待機するためのイベントの指定

- 「永続同期プロセスに対するタイムアウトの設定」

- BPELプロセスにおけるOracle Enterprise Schedulerジョブの起動

15.1 イベントおよびタイムアウトの概念に関する概要

Webサービスはレスポンスを返すまでに長時間かかる場合があるため、BPELプロセス・サービス・コンポーネントでは一定の時間が経過した後、タイムアウトしてフローの残りを継続できることが必要です。

この章では、融資提案を提供するStar LoanというWebサービスからのレスポンスを1分間待機するBPELプロセス・サービス・コンポーネントのプログラミング例を説明します。Star Loanが1分以内にレスポンスを返さない場合、BPELプロセス・サービス・コンポーネントはUnited Loanという別のWebサービスからの融資提案を自動的に選択します。現実的には、時間の制限は48時間など1分より大きな値です。しかし、この例では、BPELプロセス・サービス・コンポーネントが正しく動作しているかどうかを確認するために、そのような長時間の待機は設定しません。

非同期Webサービスはレスポンスを返すまでに長時間かかる場合があるため、BPELプロセス・サービス・コンポーネントでは一定の時間が経過した後、タイムアウトしてフローの残りを継続できることが必要です。

pickアクティビティを使用して、指定された時間待機するか、作業の実行を続行するようにBPELフローを構成できます。有効期限を設定するには、waitアクティビティを使用します。

15.2 pickアクティビティのプロセスの待機または継続の選択

pickアクティビティには2つのブランチがあり、それぞれに条件があります。最初に条件が満たされたブランチが実行されます。次の例では、1つのブランチの条件は融資提案を受け取ることで、もう1つのブランチの条件は指定の時間待機することです。

図15-1 に概要を示します。(優先度に従って)次のアクティビティが発生します。

1. invokeアクティビティがサービス(この場合はStar Loanからの融資提案に対するリクエスト)を開始します。

2. 次に、pickアクティビティが開始されます。これには次の条件があります。

- onMessage
この条件には、Star Loan Webサービスからの融資提案の形式でリプライを受け取るためのコードが含まれています。onMessageコードは、タイムアウトが追加される前の、Star Loan Webサービスからのレスポンスを受け取るコードと一致します。

- onAlarm
この条件には、1分のタイムアウトのコードが含まれています。この時間はPT1Mとして定義されています。これは、タイムアウトまでに1分待機するという意味です。タイムアウト設定には、次の記号を使用します。

- Sは秒

- Mは分

- Hは時間

- Dは日

- Yは年

あまり一般的な例ではありませんが、時間制限が1年3日15秒の場合は、PT1Y3D15Sと入力します。コードの残りの部分では、融資変数selectedおよびapprovedをfalseに設定し、年率(APR)を0.0に設定して、この情報をloanOffer変数にコピーしています。

期間のフォーマットはBPEL標準によって指定されます。期間のフォーマットの詳細は、次の場所にある最新の「XML Schema Part 2: Datatypes」ドキュメントを参照してください。

http://www.w3.org/TR/xmlschema-2/#duration

3. 最初に条件が満たされたpickアクティビティのブランチが、BPELプロセス・サービス・コンポーネントにより実行されます。もう一方のブランチは実行されません。

図15-1 pickアクティビティの概要

onMessageブランチは、メッセージを受信するという点でreceiveアクティビティに似ています。ただし、類似したパートナ・リンクおよびポート・タイプを待機し、操作が異なる複数のonMessageブランチを持つpickアクティビティを定義できます。したがって、操作ごとに個別のスレッドおよびパラレル処理を起動できます。この点は、操作が1つのみのreceiveアクティビティとは異なります。もう1つの違いは、receiveアクティビティを使用して(「インスタンスの作成」チェック・ボックスを選択することで)ビジネス・プロセスの新しいインスタンスを作成できますが、これはpickアクティビティでは実行できません。

注意:

BPEL 1.1のscopeアクティビティにおけるonMessageブランチと、BPEL 1.1および2.0のscopeアクティビティにおけるonAlarmブランチも作成できます。Oracle JDeveloperでscopeアクティビティを開き、左側でアイコンを参照して追加するブランチを検索します。

15.2.1 pickアクティビティの作成方法

pickアクティビティを作成する手順は、次のとおりです。

1. で、BPELプロセス・サービス・コンポーネントをダブルクリックします。

2. 「コンポーネント」ウィンドウで、「BPELコンストラクト」→「構造化アクティビティ」の順に選択して開きます。

3. pickアクティビティをデザイナにドラッグします。

pickアクティビティにはOnMessageブランチが含まれています。図15-2 に例を示します。

図15-2 pickアクティビティ

4. OnMessageブランチをクリックして、そのプロパティ・フィールドをプロパティ・インスペクタで表示するか、OnMessageブランチをダブルクリックします。

アクティビティをプロパティ・インスペクタで編集する方法の詳細は、「BPELアクティビティをプロパティ・インスペクタで編集する方法」を参照してください。

5. 融資サービスからのレスポンスを受け取るように、その属性を編集します。図15-3 に例を示します。

図15-3 OnMessageブランチ

6. pickアクティビティを選択します。

OnMessageブランチおよびOnAlarmブランチを追加するためのアイコンが表示されます。

7. 図15-4 に示すように、「OnAlarmの追加」をクリックします。

図15-4 onAlarmブランチの作成

OnAlarmブランチが表示されます。

8. 表示されたpickアクティビティのonAlarmブランチをダブルクリックし、時間制限を1分に設定します。図15-5 に例を示します。

図15-5 onAlarmブランチ

9. 「OK」をクリックします。

15.2.2 pickアクティビティ作成時の処理内容

次の例のコード・セグメントは、この操作のpickアクティビティに対する設計完了後の定義を示しています。

<pick>
<!--  receive the result of the remote process -->
<onMessage partnerLink="LoanService"
portType="services:LoanServiceCallback"
operation="onResult" variable="loanOffer">

<assign>
<copy>
<from variable="loanOffer" part="payload"/>
<to variable="output" part="payload"/>
</copy>
</assign>

</onMessage>
<!--  wait for one minute, then timesout -->
<onAlarm for="PT1M">
<assign>
<copy>
<from>
<loanOffer xmlns="http://www.autoloan.com/ns/autoloan">
<providerName>Expired</providerName>
<selected type="boolean">false</selected>
<approved type="boolean">false</approved>
<APR type="double">0.0</APR>
</loanOffer>
</from>
<to variable="loanOffer" part="payload"/>
</copy>
</assign>
</onAlarm>
</pick>

15.2.3 BPEL 2.0の同時onMessageブランチに関する必知事項

BPEL 2.0のOracle BPEL Process Managerの実装では、pickアクティビティの同時onMessageブランチはサポートされていません。

開始アクティビティとして(どちらも相関定義でinitiateがjoinに設定されている)2つのonMessageブランチと、起動を次々に転送する起動プロセスを持つpickアクティビティがプロセスにある場合、どちらの起動も、起動されたプロセスの同じインスタンスに到達すると想定されます。ただし、Oracle BPEL Process ManagerのBPEL 2.0の実装では、起動されたプロセスの2つのインスタンスは起動ごとに作成されます。

これは想定されている動作ですが、BPEL 2.0仕様に記載されているものとは異なります。

たとえば、同期BPELプロセスAがあり、2つのパラレル・ブランチを持つflowアクティビティがあると仮定します。

- ブランチ1は、非同期BPELプロセスBで操作processMessage1を呼び出します。

- ブランチ2は、非同期BPELプロセスBで操作processMessage2を起動します。起動は5秒間待機した後に行われます。その後、BPELプロセスAはBPELプロセスBからのコールバックで待機し、出力をクライアントに返します。

起動されたプロセスの1つのインスタンスを作成し、最初のインスタンスがアクティブで実行中の状態になった後、2番目の起動が行われるという考えです。

BPELプロセスBには、createInstanceがyesに設定されたpickアクティビティがあります。pickアクティビティ内には2つのonMessageブランチがあります。

- 一方のブランチはprocessMessage1操作に使用されます。この操作では、約10秒間スリープ状態になります。

- もう一方のブランチはprocessMessage2操作に使用されます。この操作では、5秒間待機します。

どちらの操作も入力メッセージ・タイプは同じで、initiateをjoinに設定して相関が定義されています。processMessage1が直接呼び出されてBPELプロセスBのインスタンスが作成され、それが10秒間スリープすると想定します。5秒後に、起動プロセスはprocessMessage2の起動をBPELプロセスBに転送し、この起動は新しいインスタンスを作成するのではなく、既存のインスタンスに進みます(相関IDが同じで、initiateがjoinに設定されているため)。

ただし、起動ごとにBPELプロセスBの新しいインスタンスが作成され、結果は予測できません。

- processMessage2操作のブランチが先に完了した場合、後続の割当て操作は失敗します。これは、processMessage1からの入力変数はnullと想定されるためです(そのインスタンスの場合)。

- processMessage1操作のブランチが先に完了した場合、プロセスは一部の情報のみを含むコールバック・データを返します(processMessage2からの入力は含まれません)。

Oracle BPEL Process Managerの実装では、2つの操作(processMessage1またはprocessMessage2)のいずれかによって新しいインスタンスが作成されます。この実装により、すでに作成されたインスタンスがあるかどうかを確認するためにデータベース問合せを行う必要がなくなります。

この問題を解決するには、2つの異なる操作によって開始される2つのプロセスを作成します。

15.3 receiveアクティビティのリクエスト/リプライ操作および入力専用操作に対するタイムアウトの設定

BPELバージョン1.1および2.0における次のタイプの操作に対して、タイムアウト設定を指定できます。

- リクエスト/リプライ(同期)操作。

- 入力専用receive(非同期)操作。このシナリオでは、receiveアクティビティは中間プロセスのアクティビティであり、新しいインスタンスを作成する(つまり、「Receive」ダイアログの「インスタンスの作成」チェック・ボックスが選択されている)アクティビティではない必要があります。

この機能は、パートナ・コールバックのタイムアウト期間を指定する際に使用するpickアクティビティのonMessageブランチとonAlarmブランチの代替手段として提供されています。

図15-6 に、中間プロセスのreceiveアクティビティのタイムアウトを設定する「タイムアウト」タブを示します。

図15-6 receiveアクティビティの「タイムアウト」タブ

receiveアクティビティのリクエスト・リプライ操作および入力専用操作に対するタイムアウトを設定する前に理解しておく基本的な概念の詳細は、「リクエスト・リプライ操作および入力専用操作に対するタイムアウトの設定に関する必知事項」を参照してください。

Oracle JDeveloperでreceiveアクティビティのタイムアウトを設定する方法の詳細は、「receiveアクティビティのタイムアウトの設定方法」を参照してください。

15.3.1 receiveアクティビティのタイムアウトの設定方法

次のシナリオを使用して、タイムアウトを設定します。

- 「インスタンスの作成」チェック・ボックスを選択解除する

- receiveアクティビティは、BPELプロセス(ほとんどの場合)の処理中である

receiveアクティビティでタイムアウトを設定する手順は、次のとおりです。

1. で、BPELプロセス・サービス・コンポーネントをダブルクリックします。

2. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

3. receiveアクティビティをデザイナにドラッグします。

4. アクティビティを開きます。

5. 「タイムアウト」タブをクリックします。

図15-7 に示すように、このタブでリクエスト/レスポンス操作のタイムアウトを設定できます。

図15-7 「タイムアウト」タブ

6. 適切な値を指定し、「適用」をクリックします。次に例を示します。

- アクティビティの起動時からの相対的なタイムアウトを指定するには、「期間」ボタンをクリックして値を入力するか、「式」ボタンをクリックしてXPath式を指定します。

- リクエスト/レスポンス操作の絶対的な期限としてタイムアウトを指定するには、「期限」ボタンをクリックして値を入力するか、「式」ボタンをクリックしてXPath式を指定します。

7. 「適用」をクリックし、「OK」をクリックします。

15.3.2 receiveアクティビティのタイムアウト設定時の処理内容

.bpelファイルのコード・セグメントは、特定の操作に対する設計完了後の定義を示しています。

たとえば、アクティビティが実行開始後5分以内にインバウンド・メッセージの着信を予定していることを指定した場合は、次の例に示すような構文が表示されます。

<bpelx:for="'PT5M'"/>

たとえば、アクティビティが実行開始以降、インバウンド・メッセージの着信を遅くとも2010年1月24日午前11時(UTC+1)以前に予定していることを指定した場合は、次のコードに示すような構文が表示されます。

<bpelx:until="'2010-01-24T11:00:00-08:00'"/>

たとえば、アクティビティの起動時からの相対的なタイムアウトの値を取得するようにXPath式を指定した場合は、次のコードに示すような構文が表示されます。

<bpelx:for="bpws:getVariableData('inputVariable','payload','/tns:waitValue/tns:for
')"/>

15.3.3 リクエスト・リプライ操作および入力専用操作に対するタイムアウトの設定に関する必知事項

次の各項では、リクエスト・リプライおよび入力専用のタイムアウト操作の機能について説明します。

- アクティビティの起動時からの相対的なタイムアウト設定

- 絶対的な日時でのタイムアウト設定

- XPath式を使用して動的に計算されるタイムアウト設定

- アクティビティ・タイムアウト時にスローされるbpelx:timeoutフォルト

- アクティビティ・タイムアウト時にBPELインスタンス監査証跡に追加されるイベント

- サーバー再起動時にリカバリ可能なタイムアウト・アクティビティ

15.3.3.1 アクティビティの起動時からの相対的なタイムアウト設定

タイムアウト設定として、アクティビティの起動時からの相対的なタイムアウトを指定できます。この設定は、次の例に示すBPEL 1.1用の構文を使用して相対的な期間として指定されます。

<receive | bpelx:for="duration-expr">
standard-elements
</receive>

BPEL 2.0では、構文は次の例のようになります。

<receive | <bpelx:for>'duration-expr'</bpelx:for>
standard-elements
</receive>

このタイプでは、bpelx:for属性を使用して、XMLスキーマ・タイプ期間として評価される静的な値またはXPath式を指定します。アクティビティには、bpelx:for属性またはbpelx:until属性のいずれか一方のみを使用できます。

XPath式がマイナスの期間として評価された場合、タイムアウトは無視され、その期間の値が無効であることを示すインスタンス監査証跡にイベントが記録されます。

有効な期間の値が取得されると、アクティビティの有効期限は、現在のノード時間(そのノードが使用可能になってからのクラスタ時間)にその期間の値を加算した値に設定されます。たとえば、期間の値bpelx:for="'PT5M'"は、アクティビティが実行開始後5分以内にインバウンド・メッセージの着信を予定していることを示します。

注意:

現在、pickアクティビティのonMessageブランチにはタイムアウト設定属性が適用されません。これは、pickアクティビティのonMessageブランチとonAlarmブランチを使用した同じ機能が存在しているためです。

タイムアウト期間は、次のアクティビティにのみ指定できます。

- 中間プロセスのreceiveアクティビティ

- createInstance="true"の指定がないreceiveアクティビティ

receiveアクティビティは、インスタンス化された後にのみタイムアウトします。receiveアクティビティのエントリではタイムアウトになりません。

15.3.3.2 絶対的な日時でのタイムアウト設定

タイムアウト設定は、リクエスト/レスポンスreceiveアクティビティの絶対的な期限として指定できます。BPEL 2.0では、構文は次の例のようになります。

<receive <bpelx:until>"deadline-expr"</bpelx:until>
</receive>

BPEL 1.1では、構文は次の例のようになります。

<receive bpelx:until="deadline-expr">
standard-elements
</receive>

bpelx:until属性の予定有効期限は、現在時刻より少なくとも2秒後である必要があります。それ以外の場合は、タイマーが指定されていなかったかのように、タイマー・スケジュールを無視してスキップされます。

bpelx:until属性には、datetimeまたはdateのXMLスキーマ・タイプとして評価される静的な値またはXPath式を指定します。アクティビティには、bpelx:for属性またはbpelx:until属性のいずれか一方のみを使用できます。

XPathバージョン1.0は、XMLスキーマに対応していません。したがって、XPathバージョン1.0の組込み関数では、dateTime値やdate値を作成したり、操作することはできません。ただし、次のいずれかを実行できます。

- XMLスキーマ定義に準拠する定数(リテラル)の記述、および期限値としての使用。

- 使用可能ないずれかのタイプの変数(パート)からのフィールドの抽出、および期限値としての使用。

XPathバージョン1.0では、リテラルが文字列リテラルとして処理されますが、結果はdateTime値またはdate値の字句表記として解釈されます。

有効なdatetime値またはdate値が取得されると、アクティビティの有効期限が指定の日付に設定されます。たとえば、bpelx:until="'2009-12-24T18:00+01:00'"というdatetime値は、アクティビティが実行開始以降、インバウンド・メッセージの着信を遅くとも2009年12月24日午後6時(UTC+1)以前に予定していることを示します。

注意:

現在、pickアクティビティのonMessageブランチにはタイムアウト設定属性が適用されません。これは、pickアクティビティのonMessageブランチとonAlarmブランチを使用した同じ機能が存在しているためです。

タイムアウト日付は、次のアクティビティにのみ指定できます。

- 中間プロセスのreceive

- createInstance="true"の指定がないreceiveアクティビティ

receiveアクティビティは、インスタンス化された後にのみタイムアウトします。receiveアクティビティのエントリではタイムアウトになりません。

15.3.3.3 XPath式を使用して動的に計算されるタイムアウト設定

リクエスト/レスポンスreceiveアクティビティ、入力専用receive(コールバック)アクティビティおよびpickアクティビティのonMessageブランチに対するタイムアウト設定は、静的な期間またはdatetime値を入力するかわりに、XPath式を使用して設定できます。この場合は、次のいずれかを式の値として返す必要があります。

- XMLの静的な期間またはdatetime値と解釈される文字列

- XMLスキーマの期間またはdatetimeタイプ

次の例に、BPEL 1.1でXPath式を使用するための構文を示します。

<bpelx:for="bpws:getVariableData('input', 'payload',
'/tns:waitValue/tns:for')"/>

<bpelx:until="bpws:getVariableData('input', 'payload',
'/tns:waitValue/tns:until')"/>

返された式の値をXMLスキーマの期間またはdatetimeタイプと解釈できない場合は、無効な期間またはdatetimeの値が指定されたことを示すインスタンス監査証跡にイベントが記録され、アクティビティの有効期限は設定されません。

15.3.3.4 アクティビティ・タイムアウト時にスローされるbpelx:timeoutフォルト

bpelx:forまたはbpelx:until属性から、有効なXMLスキーマの期間またはdatetime値が返された場合は、タイムアウトしたアクティビティからbpelx:timeoutフォルトがスローされます。このフォルトはcatchまたはcatchAllブロックによって捕捉され、通常のBPELフォルトと同様に処理されます。フォルトのメッセージはアクティビティの名前になります。また、タイムアウト期間より前に、想定したコールバック・メッセージの受信に失敗したためにアクティビティがタイムアウトしたことを示すインスタンス監査証跡にイベントが記録されます。

タイムアウト時間より前にアクティビティがパートナからコールバックを受信した場合、フォルトはスローされません。コールバックを受信したときにアクティビティがタイムアウトしていた場合、コールバック・メッセージはアクティビティに配信されず、配信メッセージ表に取消しのマークが設定されます。コールバック・メッセージの処理と同時にタイムアウト・アクションが試行された場合、そのタイムアウト・アクションは無視されます。11g リリース1現在、インスタンスはオプティミスティックにロックされます(リリース10gのペシミスティック・ロックとは対照的です)。したがって、行の第2のアクションがそのまま実行されます。

操作に対するフォルトがコンポーネントWSDLに宣言されている場合は、BPELコンポーネントからbpelx:timeoutフォルトをスローできます。操作に対するフォルトが宣言されていない場合、フォルトはFabricInvocationException実行時フォルトに変換されます。このフォルトは、すべてのコール元コンポーネント(BPELコンポーネントを含む)によって捕捉されますが、フォルトのタイプは、bpelx:timeoutではなくなります。(ただし、フォルト・メッセージ文字列は、このフォルトが当初はタイムアウト・フォルトであったことを示します)。

15.3.3.5 アクティビティ・タイムアウト時にBPELインスタンス監査証跡に追加されるイベント

タイムアウトしたアクティビティからbpelx:timeoutフォルトがスローされると、想定したコールバック・メッセージをパートナから受信した場合とは対照的に、アクティビティがタイムアウトしたことを示すインスタンス監査証跡にイベントが記録されます。

15.3.3.6 サーバー再起動時にリカバリ可能なタイムアウト・アクティビティ(有効期限アラーム表のリフレッシュ)

有効なタイムアウトの期間またはdatetimeを指定するアクティビティは、基礎となる作業アイテム・オブジェクトの有効期限が設定されているwaitアクティビティおよびonAlarmアクティビティとほぼ同様の方法で実装されます。スケジューラを使用してこれらのアクティビティをスケジュールしたノードが(正常な停止または中途完了のいずれかで)停止した場合は、サーバー再起動時に、スケジューラを使用してこれらのアクティビティをすべて再スケジュールする必要があります。

ノードが停止した場合、これらのアクティビティをクラスタの単一のノード(マスター・ノード)で再スケジュールすることはできません。

15.4 waitアクティビティによる有効期限の設定

waitアクティビティを使用すると、プロセスは指定された期間または時間制限に達するまで待機できます。有効期限条件を1つのみ指定する必要があります。このアクティビティの典型的な用途は、一定の時間に操作を起動することです。通常は、プロセスの状態に依存する式を入力します。

待機期間を指定する場合は、次の点に注意してください。

- 処理を必要とする他のイベントとともにスケジュールされている場合、待機期間は保証されません。この追加処理のために、実際の待機期間は、BPELプロセスに指定されている待機期間より長くなる可能性があります。

- 2秒未満の待機期間はサーバーから無視されます。2秒以上1分未満の待機期間は、正確な指定時間で実行されないことがあります。ただし、分単位の待機期間は指定時間で実行されます。

- 待機時間2秒のデフォルト値は、Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザのMinBPELWaitプロパティで指定されます。このプロパティは任意の値に設定でき、MinBPELWait未満の待機の遅延は無視されます。

注意:

waitアクティビティの期限切れイベントのスケジュールには、Quartzバージョン1.6がサポートされています。

15.4.1 最小待機時間の指定方法

BPELプロセスがデハイドレーションに関連して待機する最小期間を指定できます。待機期間が指定値以下の場合、BPELはアクティビティの実行を同じスレッドの同じトランザクションで続行します。

最小待機時間を指定する手順は、次のとおりです。

1. 「SOAインフラストラクチャ」メニューから、「SOA管理」→「BPELプロパティ」の順に選択します。

2. 「BPELサービス・エンジン・プロパティ」ページの下部で、「詳細BPEL構成プロパティ」をクリックします。

3. 「MinBPELWait」をクリックします。

4. 「値」フィールドに値を秒単位で指定します。

5. 「適用」をクリックします。

6. 「戻る」をクリックします。

15.4.2 waitアクティビティの作成方法

waitアクティビティを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

2. waitアクティビティをデザイナにドラッグします。

3. waitアクティビティをダブルクリックし、「Wait」ダイアログを表示します。

4. 「期間」セクションに、待機する時間を入力します。

5. 図15-8 に示すように、「期限」セクションで、待機する期限を選択します。

図15-8 「Wait」ダイアログ

15.4.3 waitアクティビティ作成時の処理内容

BPEL 2.0では、次の例に示すように、有効期限条件を1つのみ指定する必要があります。

<wait <for>'duration-expr'</for> | <until>'duration-expr'</until>
standard-elements
</wait>

次の例はBPEL 1.1構文を示しています。

<wait (for="duration-expr" | until="deadline-expr") standard-attributes>
standard-elements
</wait>

15.5 BPEL 2.0のOnEventブランチを使用してメッセージ着信を待機するためのイベントの指定

指定されたイベントがメッセージの到着を待機するonEventブランチをscopeアクティビティ内に作成できます。たとえば、顧客のクレジット要求メッセージによって開始されるクレジット要求プロセスがあると仮定します。さらに顧客対応を行わなくても要求は完全に処理され、結果が顧客に送信されます。ただし、顧客がクレジット要求のステータスに関する問合せ、要求内容の変更、または処理中の要求の完全な取消を行う場合があります。このような顧客対応は、ビジネス処理の特定の時点でのみ発生するとはかぎりません。onEventブランチなどのイベント・ハンドラを使用すると、ビジネス・プロセスでは、プライマリ・ビジネス・ロジック・フローに並行して到着する要求(ステータス要求、変更要求、取消要求など)を受け入れることができます。

onEventイベント・ハンドラは、内側に囲まれているスコープと関連付けられます。onEventイベント・ハンドラはスコープが初期化されると有効になり、スコープが終了すると無効になります。有効になると、いくつものイベントが発生する可能性があります。イベントは、スコープのプライマリ・アクティビティおよびイベント相互に並行して処理されます。メッセージ・イベントも、プロセスによって公開されるサービス操作を表し、onEvent要素としてモデル化されます。イベント・ハンドラは新しいプロセス・インスタンスを作成できません。したがって、メッセージ・イベントは常に、すでにアクティブなプロセス・インスタンスで受信されます。

15.5.1 scopeアクティビティでのonEventブランチの作成方法

scopeアクティビティでonEventブランチを作成する手順は、次のとおりです。

1. 図15-9 に示すように、開いた状態のscopeアクティビティで、「OnEventの追加」をクリックします。

図15-9 「OnEventの追加」アイコン

これにより、OnEventブランチおよび内側に囲まれているscopeアクティビティが作成されます。

2. OnEventブランチをダブルクリックします。

図15-10 に示すように、「OnEvent」ダイアログが表示されます。

図15-10 「OnEvent」ダイアログ

3. 「パートナ・リンク」フィールドで、「検索」アイコンをクリックして、メッセージが到着するエンドポイント参照を含むパートナ・リンクを選択します。

「ポート・タイプ」フィールドおよび「操作」フィールドは、イベントを発生させるためにパートナによって呼び出されるポート・タイプおよび操作を定義します。

4. 変数または「送信元パート」要素を使用して、パートナからメッセージを受信するための方法を指定します。

5. 「適用」をクリックし、「OK」をクリックします。

6. BPELプロセスの設計を続行します。

15.5.2 OnEventブランチ作成時の処理内容

次の例に、設計完了後の.bpelファイル内のonEventブランチの概要を示します。onEventブランチは、クレジット要求のステータスの問合せ、要求内容の変更または処理中の要求の完全な取消しを行います。

<process name="creditRequestProcess" . . .>
. . .
<eventHandlers>
<onEvent partnerLink="requestCreditScore"
operation="queryCreditRequestStatus" ...>
<scope name="scopeStatus">...</scope>
</onEvent>
<onEvent partnerLink="requestCreditScore"
operation="modifyCreditRequest" ...>
<scope name="scopeRequest">...</scope>
</onEvent>
<onEvent partnerLink="requestCreditScore"
operation="cancelCreditRequest" ...>
<scope name="scopeCancel">...</scope>
</onEvent>
</eventHandlers>
. . .
</process>

15.6 永続同期プロセスに対するタイムアウトの設定

リモート・データベースに接続する永続同期プロセスについては、Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで、SyncMaxWaitTimeタイムアウト・プロパティの値を増加する必要があります。

このプロパティの設定方法の詳細は、「永続同期プロセスのトランザクションのタイムアウト値の指定」を参照してください。

15.7 BPELプロセスにおけるOracle Enterprise Schedulerジョブの起動

Oracle Enterprise SchedulerジョブをBPELプロセスで起動できます。Oracle Enterprise Schedulerジョブは、Java、データベースのストアド・プロシージャまたは実行可能ファイルの形態における作業の単位です。ジョブ定義はOracle Enterprise Schedulerに関連付けられ、ここでジョブの実行方法を記述します。Oracle Enterprise Schedulerでは、WebサービスがジョブをBPELプロセス内から発行し、スケジュールをそのジョブ・リクエストと関連付けます。

スケジュール済Oracle Enterprise Schedulerジョブはランタイム環境に格納され、データベース・ベースのアクセスを使用して、Oracle Metadata Servicesリポジトリ(MDSリポジトリ)接続でアクセスできます。

注意:

この項では、ジョブの完了を待機する方法ではなく、BPELプロセスからのジョブの発行方法を説明します。BPELプロセスでジョブの完了を待機するには、Webサービスを起動して、ジョブの完了時にコールバックを要求し、そのコールバックを取得するために受信を実行する必要があります。詳細は、『Oracle Enterprise Schedulerアプリケーションの開発』の「Oracle Enterprise Scheduler Webサービスの使用方法」を参照してください。

15.7.1 OracleデータベースとSOA-MDSの接続を作成する方法

OracleデータベースとSOA-MDSの接続を作成するには:

1. SOAコンポジット・アプリケーションを作成します。詳細は、「SOAアプリケーションの作成」を参照してください。

2. BPELプロセスをSOAコンポジット・エディタで作成します(この例では、同期BPELプロセスが作成されます)。詳細は、「BPELプロセス・サービス・コンポーネントの追加方法」を参照してください。

3. SOAコンポジット・エディタでBPELプロセスをダブルクリックします。
Oracle BPELデザイナが表示されます。

4. Oracleデータベース接続を作成します。これはOracle Enterprise Schedulerジョブの問合せで必要です。

a. 「ファイル」メイン・メニューから「新規」→「アプリケーション」の順に選択します。

b. 「カテゴリ」リストから、「接続」を選択します。

c. 「データベース接続」を選択します。
「データベース接続の作成」ウィザードが表示されます。

d. Oracle Enterprise Schedulerがデプロイされているランタイム・サーバーの、スケジューラOracle Metadata Services Repositoryデータベースとの接続を作成するためのデータベース接続の作成ウィザードのダイアログを完了し、「終了」をクリックします。

5. SOA-MDS接続を作成します。データベース・ベースのMDSリポジトリが、選択ジョブの取得で使用されます。

a. 「ファイル」メイン・メニューから「新規」→「アプリケーション」の順に選択します。

b. 「カテゴリ」リストから、「接続」を選択します。

c. 「SOA-MDS接続」を選択します。
「SOA-MDS接続の作成」ダイアログが表示されます。

d. 「接続タイプ」リストから、「DBベースMDS」を選択します。

e. 「接続」リストで、手順4で作成されたデータベース接続が表示されることを確認してください。

f. 「MDSパーティションの選択」リストから、Oracle Enterprise Schedulerジョブを含めるパーティションを選択します。ネイティブのホスティング・アプリケーションが事前デプロイ済のOracle Enterprise Schedulerに定義されているジョブの場合は、MDSパーティション名はessUserMetadataです。

g. SOA-MDS接続を作成するためのダイアログの残りのフィールドを完成し、「OK」をクリックします。

15.7.2 スケジュール・ジョブ・アクティビティを作成する方法

スケジュール・ジョブ・アクティビティを作成するには:

1. 「コンポーネント」ウィンドウで、「Oracle Extensions」を展開します。

2. 図15-11 に示すように、スケジュール・ジョブ・アクティビティをBPELプロセスにドラッグします。

図15-11 「ジョブのスケジュール」アイコン

3. アクティビティをダブルクリックし、スケジュール・ジョブの編集ダイアログを起動します。図15-12に詳細を示します。このダイアログにより、アプリケーション、説明、Oracle Enterprise Schedulerジョブ、ジョブ・スケジュールおよびジョブ開始時間を指定できます。

図15-12 スケジュール・ジョブの編集ダイアログ: 「一般」タブ

4. 表15-1 の説明に従って、環境に適した値を指定し、「OK」をクリックします。

表15-1 スケジュール・ジョブの編集ダイアログ: 「一般」タブ

フィールド

説明

アプリケーション

選択されたジョブのSYS_effectiveApplicationプロパティの値が表示されます。このプロパティを設定する必要があります。設定されていなと、エラー・メッセージが表示され、進むことができません。

このフィールドの編集可能状態は、選択されたジョブ定義によって異なります。

- 選択されたジョブ定義でSYS_effectiveApplicationが用意されていると、このプロパティの値が表示され、このフィールドは編集できません。

- ジョブ定義でSYS_effectiveApplicationが用意されていないと、このフィールドは編集でき、「システム・プロパティ」タブの「ユーザー定義プロパティ」セクションでアプリケーション名を指定する必要があります。

名前

ジョブの名前を指定します。

説明

リクエストの説明を指定します。

ジョブ

「検索」アイコンをクリックして、「エンタープライズ・スケジューラ・ブラウザ」ダイアログを起動し、ジョブをSOA-MDS接続から選択します。ジョブを選択すると、そのジョブ用に定義されたシステム・プロパティやアプリケーション・プロパティが、「アプリケーション・プロパティ」や「システム・プロパティ」のタブに表示されます。

スケジュール

「検索」アイコンをクリックして、「エンタープライズ・スケジューラ・ブラウザ」ダイアログを起動し、ジョブ・スケジュールを選択します。指定しない場合、ジョブはすぐに実行されます。

スケジュールをOracle Enterprise Manager Fusion Middleware Controlで定義します。これらのスケジュールは、「エンタープライズ・スケジューラ・ブラウザ」ダイアログの選択内容に表示されます。詳細は、『Oracle Enterprise Schedulerの管理』の事前定義済ジョブ・スケジュールの作成または編集に関する項を参照してください。

開始時間

「XPath式ビルダー」アイコンをクリックして、開始時間をXPath式として指定します。開始はスケジュールと別で、ジョブが有効であることを示します。開始時間を指定しない場合、開始時間は即時になります。

終了時間

「XPath式ビルダー」アイコンをクリックして、終了時間をXPath式として指定します。終了はスケジュールと別で、ジョブが終了する時期を示します。スケジュールを指定しない場合、このフィールドは表示されません。

5. 「アプリケーション・プロパティ」タブをクリックします。アプリケーション・プロパティは、特定のジョブに固有です。Oracle Enterprise Schedulerジョブをスケジュール・ジョブの編集ダイアログの「一般」タブで選択すると、ジョブで定義されたアプリケーション・プロパティがこのダイアログに表示されます。また、「ユーザー定義プロパティ」セクションで独自のアプリケーション・プロパティを指定できます。図15-13に詳細を示します。

図15-13 スケジュール・ジョブの編集ダイアログ: 「アプリケーション・プロパティ」タブ

6. 表15-2 の説明に従って、環境に適した値を指定し、「OK」をクリックします。

表15-2 スケジュール・ジョブの編集ダイアログ: 「アプリケーション・プロパティ」タブ

フィールド

説明

ジョブ・プロパティ

ジョブで定義したアプリケーション・プロパティが表示されます。値のみ変更できます。この表のプロパティは削除できません。プロパティをダブルクリックしてその値を編集するか、「値」フィールドの右側で「参照」アイコンをクリックして、XPath式を指定します。

ユーザー定義プロパティ

このリクエストで追加されたアプリケーション・プロパティが表示されます。この表にあるプロパティの追加、変更または削除ができます。

7. 「システム・プロパティ」タブをクリックします。システム・プロパティは、Oracle Enterprise Schedulerによって予約された名前を持つパラメータです。Oracle Enterprise Schedulerでは、SystemPropertyクラスで、システムによって認識され使用されるパラメータ名を表します。Oracle Enterprise Schedulerジョブをスケジュール・ジョブの編集ダイアログの「一般」タブで選択すると、ジョブで定義されたシステム・プロパティがこのダイアログに表示されます。また、「ユーザー定義プロパティ」セクションで独自のシステム・プロパティを指定できます。図15-14に詳細を示します。

図15-14 スケジュール・ジョブの編集ダイアログ: 「システム・プロパティ」タブ

システム・プロパティの詳細は、『Oracle Enterprise Schedulerアプリケーションの開発』の「パラメータとシステム・プロパティの使用方法」を参照してください。

8. 表15-3 の説明に従って、環境に適した値を指定し、「OK」をクリックして、構成を完成させます。

表15-3 スケジュール・ジョブの編集ダイアログ: 「システム・プロパティ」タブ

フィールド

説明

ジョブ・プロパティ

ジョブで定義したシステム・プロパティが表示されます。値のみ変更できます。プロパティをダブルクリックしてその値を編集するか、「参照」アイコンをクリックして、XPath式を「式ビルダー」ダイアログで指定します。

ユーザー定義プロパティ

このリクエストで追加されたシステム・プロパティが表示されます。この表にあるプロパティの追加、変更または削除ができます。この表にあるシステム・プロパティ名の固定リストから選択します。

図15-15 に示されるメッセージが表示されます。Oracle Enterprise SchedulerのWebサービスに抽象的なWSDLが含まれているためです。

図15-15 WSDLメッセージ

BPELプロセスでは次が必要です。

- 具体WSDL

- パートナ・リンクのあるWSDL

9. 「はい」をクリックします。

具体ラッパーWSDLが抽象的なWSDL用に作成されます。ラッパーWSDLには、BPELプロセスに追加されているOracle Enterprise Schedulerパートナ・リンクが含まれています。

10. スケジュール・ジョブ・アクティビティをBPELプロセスで展開して、その内容を表示します。図15-16に詳細を示します。

図15-16 BPELプロセスにおけるジョブ・スケジュール・アクティビティの展開

展開されたスケジュール・ジョブ・アクティビティは、自動的に構成された次のアクティビティで構成されています。

- EssAssignアクティビティ: システム・プロパティやアプリケーション・プロパティなどのジョブ情報のコピー・ルール操作が格納されます。

- EssInvokeアクティビティ: Oracle Enterprise Schedulerパートナ・リンクを起動します。

- EssServiceアクティビティ: Oracle Enterprise Scheduler Webサービス・パートナ・リンクが含まれています。

11. SOAコンポジット・エディタでSOAコンポジット・アプリケーションに移動します。

12. 「外部参照」スイムレーンで、「EssService」パートナ・リンクをダブルクリックします。

「参照の更新」ダイアログが表示されます。

13. 「WSDL URL」フィールドで、参照バインディング・コンポーネントの具体WSDLを指定して、「OK」をクリックします。

15.7.3 セキュリティ・ポリシーをサービス・バインディング・コンポーネントと参照バインディング・コンポーネントにアタッチする方法

セキュリティ・ポリシーをサービス・バインディング・コンポーネントと参照バインディング・コンポーネントにアタッチするには:

1. 「EssService」参照バインディング・コンポーネントを右クリックし、「SOA WSポリシーの構成」→「リクエスト対象」を選択します。

「SOA WSポリシーの構成」ダイアログが表示されます。

2. 「セキュリティ」セクションで「追加」アイコンをクリックします。

3. 「oracle/wss_username_token_client_policy」を選択し、「OK」をクリックします。

4. 「SOA WSポリシーの構成」ダイアログで「OK」をクリックします。

5. サービス・バインディング・コンポーネントを右クリックし、「SOA WSポリシーの構成」を選択します。

「SOA WSポリシーの構成」ダイアログが表示されます。

6. 「セキュリティ」セクションで「追加」アイコンをクリックします。

7. 「oracle/wss_username_token_service_policy」を選択して「OK」をクリックします。

これで、設計は完了します。

注意:

Oracle Enterprise SchedulerのWebサービスは、デフォルトでは保護されていません。WebサービスでBPELプロセスからジョブを発行する前に、WLSTコマンドまたはOracle Enterprise Manager Fusion Middleware ControlでOracle Web Services Managerポリシーを使用して、最初に保護する必要があります。

16 マスター・プロセスと詳細プロセスの調整

この章では、BPELプロセスでのマスター・プロセスと詳細プロセスの調整について説明します。この調整により、マスターBPELプロセスとそれに関連した詳細BPELプロセスで実行されるタスクを指定できます。これは、親子関係とも呼ばれます。

この章の内容は次のとおりです。

- マスター・プロセスと詳細プロセスの調整に関する概要

- Oracle JDeveloperでのマスター・プロセスと詳細プロセスの調整の定義

16.1 マスター・プロセスと詳細プロセスの調整に関する概要

マスター・プロセスと詳細プロセスの調整は、単一のマスター・プロセスと複数の詳細プロセス間の1対多の関係で構成されます。

たとえば、ビジネス・プロセスで受注をアプリケーションにインポートするとします。各受注は、単一のヘッダー(顧客情報、配送先など)と複数の明細(品目名、品目番号、数量、価格など)で構成されます。

この受注の実行には、次の各タスクが実行されます。

- ヘッダーを検証します。ヘッダーが無効な場合、処理は停止します。

- 各明細を検証します。無効な明細がある場合は、無効としてマークされ、処理が停止します。

- 各品目の在庫確認を実行します。品目が在庫にない場合は、作業指示が作成されて組み立てられます。

- 各明細の品目が入手可能になった場合は、その品目を出荷ドックに移動します。

- 注文品を顧客に発送します。

これらのタスクを実行するには、各ヘッダーの確認と検証を行う単一のマスター・プロセスと、各明細品目の確認と検証を行う複数のBPELプロセスを作成します。

考えられる調整のポイントは、次のとおりです。

- マスター・プロセスは、ヘッダーの検証が正常に終了した後、処理を続行することを詳細プロセスに通知する必要があります。

- 各詳細プロセスは、明細品目の検証を完了した場合、マスター・プロセスに通知する必要があります。

- 各詳細プロセスは、明細品目が在庫で入手可能な場合、マスター・プロセスに通知する必要があります。

- すべての明細品目が入手可能である場合、マスターは各詳細プロセスに通知して、明細品目を出荷ドックに移動する必要があります(入手可能になった明細品目をすべて移動した場合、ドックは一杯になる場合があります)。

- すべての品目を移動した後、マスター・プロセスは、履行された注文品を顧客に発送するロジックを実行します。

図16-1は、1つのマスター・プロセスと2つの詳細プロセス間の、ヘッダーと明細品目の検証調整ポイントの概要を示しています。

図16-1 マスター・プロセスと詳細プロセスの調整の概要(1つのBPELプロセスから2つの詳細プロセスへ)

次のBPELプロセス・アクティビティは、マスター・プロセスと詳細プロセス間のアクションを調整します。

- signal: 他のプロセス(マスターまたは詳細)に処理の続行を通知します。

- receive signal: 他のプロセス(マスターまたは詳細)から適切な通知シグナルを受信するまで待機してから、処理を続行します。

どちらのアクティビティも、BPELプロセス・ファイルに定義されているラベル属性によって調整されます。ラベルはマスター・プロセス定義ごとに宣言されます。

図16-2 は、BPELプロセス・フローの調整の概要を示しています。

図16-2 マスター・プロセスと詳細プロセスの構文の概要(1つのBPELプロセスから1つの詳細プロセスへ)

図16-2 に示すように、各マスター・プロセスと詳細プロセスには、signalアクティビティとreceive signalアクティビティが含まれています。表16-1 は、役割が定義されたプロセスのタイプに基づいて、アクティビティの役割について説明しています。

表16-1 マスター・プロセスと詳細プロセスの調整の役割

プロセス

アクティビティ

結果

マスター・プロセス

signalアクティビティ

マスター・プロセスは実行時に、関連するすべての詳細プロセスに通知します。

詳細プロセス

receive signalアクティビティ

詳細プロセスは、マスター・プロセスが実行したシグナルを受信するまで待機します。

詳細プロセス

signalアクティビティ

詳細プロセスは実行時に、関連するマスター・プロセスに処理が完了したことを通知します。

マスター・プロセス

receive signalアクティビティ

マスター・プロセスは、すべての詳細プロセスが実行したシグナルを受信するまで待機します。

signalアクティビティがreceive signalアクティビティの前に実行された場合は、そのsignalアクティビティによって設定された状態が継続され、その状態は後のreceive signalアクティビティを読み取るまで有効です。

16.1.1 マスター・プロセスに対するBPELファイル定義

マスター・プロセスに対するBPELファイルは、詳細プロセスとの調整を定義します。BPELファイルは、マスター・プロセスが様々な詳細プロセスのパートナ・リンクと相互作用することを示します。次に例を示します。

<process name="MasterProcess"
. . .
. . .
<partnerLinks>
<partnerLink name="client"
partnerLinkType="tns:MasterProcess"
myRole="MasterProcessProvider"
partnerRole="MasterProcessRequester"/>
<partnerLink name="DetailProcess"
partnerLinkType="dp:DetailProcess"
myRole="DetailProcessRequester"
partnerRole="DetailProcessProvider"/>
<partnerLink name="DetailProcess1"
partnerLinkType="dp1:DetailProcess1"
myRole="DetailProcess1Requester"
partnerRole="DetailProcess1Provider"/>
<partnerLink name="DetailProcess2"
partnerLinkType="dp2:DetailProcess2"
myRole="DetailProcess2Requester"
partnerRole="DetailProcess2Provider"/>
</partnerLinks>

signalアクティビティは、このマスター・プロセスと調整するラベル値と詳細プロセスを示します。このラベル値(startDetailProcess)は、すべての詳細プロセスのreceive signalアクティビティのラベル値と一致しています。これにより、シグナルは適切なプロセスに送信されます。シグナル受信プロセスごとに1つのシグナル・プロセスがあります。マスター・プロセスは、実行時にすべての詳細プロセスに通知します。次の例のこの構文は、BPELバージョン2.0をサポートするBPELプロセスのsignalアクティビティを示しています。

<extensionActivity>
<bpelx:signal name="notifyDetailProcess"
label="startDetailProcess" to="details"/>
</extensionActivity>

注意:

BPEL 1.1では、signalアクティビティの構文は多少異なります。

<bpelx:signal name="notifyDetailProcess" label="startDetailProcess" to="details"/>

assign、invokeおよびreceiveの各アクティビティには、マスター・プロセスと詳細プロセス間の相互作用が記述されます。この例は、マスター・プロセスと詳細プロセスの1つ(DetailProcess)との間の相互作用を示しています。同様の相互作用は、すべての詳細プロセスについて、BPELファイルに定義されています。

invokeアクティビティで、「詳細として呼出し」チェック・ボックスが選択されていることを確認します。図16-3に詳細を示します。

図16-3 「詳細として呼出し」チェック・ボックス

この選択は、詳細インスタンスとして、パートナ・プロセス・インスタンス(DetailProcess)を作成します。相互作用する各詳細プロセスに対するマスター・プロセスのinvokeアクティビティで、このチェック・ボックスを選択する必要があります。次の例に、「詳細として呼出し」チェック・ボックスを選択した後のBPELファイル・コンテンツの例を示します。

<assign>
<copy>
<from variable="input" part="payload" query="/tns:processInfo/tns:value"/>
<to variable="detail_input" part="payload" query="/dp:input/dp:number"/>
</copy>
</assign

<invoke name="receiveInput" partnerLink="DetailProcess"
portType="dp:DetailProcess"
operation="initiate"
inputVariable="detail_input"
bpelx:invokeAsDetail="true"/>

<!--  receive the result of the remote process -->
<receive name="receive_DetailProcess" partnerLink="DetailProcess"
portType="dp:DetailProcessCallback"
operation="onResult" variable="detail_output"/>

マスターBPELプロセスには、receive signalアクティビティが含まれています。このアクティビティは、すべての詳細プロセスからシグナルを受信するまでマスター・プロセスが待機することを示します。ラベル値(detailProcessComplete)は、各詳細プロセスのsignalアクティビティのラベル値と一致しています。これにより、シグナルは適切なプロセスに送信されます。次にコードの例を示します。次の構文は、BPELバージョン2.0をサポートするBPELプロセスのreceive signalアクティビティを示しています。

<extensionActivity>
<bpelx:receiveSignal name="waitForNotifyFromDetailProcess"
label="detailProcessComplete" from="details"/>
</extensionActivity>

注意:

BPEL 1.1では、receive signalアクティビティの構文は多少異なります。

<bpelx:receiveSignal name="waitForNotifyFromDetailProcess"
label="detailProcessComplete"
from="details"/>

16.1.1.1 マスター・プロセスと複数の詳細プロセスの相関

1つのマスター・プロセスと複数の詳細プロセスがある環境では、シグナル相関にbpelx:detailLabel属性を使用します。次の例は、この属性の使用方法を示しています。

最初のinvokeアクティビティは、DetailProcess詳細プロセスを起動し、それをdetailProcessComplete0のラベルに関連付けます。

<invoke name="invokeDetailProcess" partnerLink="DetailProcess"
portType="dp:DetailProcess"
operation="initiate"
inputVariable="detail_input"
bpelx:detailLabel="detailProcessComplete0"
bpelx:invokeAsDetail="true"/>

2番目のinvokeアクティビティは、DetailProcess1詳細プロセスを起動し、それをdetailProcessComplete1のラベルに関連付けます。次に例を示します。

<invoke name="invokeDetailProcess1" partnerLink="DetailProcess1"
portType="dp1:DetailProcess1"
operation="initiate"
inputVariable="detail_input1"
bpelx:detailLabel="detailProcessComplete1-2"
bpelx:invokeAsDetail="true"/>

3番目のinvokeアクティビティは、異なるポートと異なる入力変数を使用してDetailProcess2詳細プロセスを再度起動します。これにより、次の例に示すように、DetailProcess2詳細プロセスがdetailProcessComplete1-2のラベルに関連付けられます。

<invoke name="invokeDetailProcess2" partnerLink="DetailProcess2"
portType="dp2:DetailProcess2"
operation="initiate"
inputVariable="detail_input2"
bpelx:detailLabel="detailProcessComplete1-2"
bpelx:invokeAsDetail="true"/>

次の例に示すマスター・プロセスのreceive signalアクティビティは、詳細プロセスDetailProcess0からの返信シグナルを待機します。

<!-- This is a receiveSignal waiting for 1 child to signal back -->
<bpelx:receiveSignal name="waitForNotifyFromDetailProcess0"
label="detailProcessComplete0" from="details"/>

次の例に記載されているマスター・プロセスの2番目のreceive signalアクティビティも、DetailProcess1およびDetailProcess2からの返信シグナルを待機します。

<!-- This is a receiveSignal waiting for 2 child (detail) processes to signal back -->
<bpelx:receiveSignal name="waitForNotifyFromDetailProcess1-2"
label="detailProcessComplete1-2" from="details"/>

注意:

BPELプロセスのreceive signalアクティビティが1つのみの場合、invokeアクティビティには、bpelx:detailLabel属性を指定しないでください。このような状況では、デフォルトのbpelx:detailLabel属性が適用されるため、指定する必要はありません。

16.1.2 詳細プロセスに対するBPELファイル定義

各詳細プロセスのBPELプロセス・ファイルには、マスター・プロセスとの調整を定義します。

receive signalアクティビティは、次の例に示す詳細プロセスが、マスター・プロセスが実行したシグナルを受信するまで待機することを示します。ラベル値(startDetailProcess)は、マスター・プロセスのsignalアクティビティのラベル値と一致しています。

<bpelx:receiveSignal name="waitForNotifyFromMasterProcess"
label="startDetailProcess" from="master"/>

signalアクティビティは、次の例に示す詳細プロセスが、実行時に処理を完了したことを、関連するマスター・プロセスに通知することを示します。ラベル値(detailProcessComplete)は、各マスター・プロセスのreceive signalアクティビティのラベル値と一致しています。

<bpelx:signal name="notifyMAsterProcess" label="detailProcessComplete"
to="master"/>

16.2 Oracle JDeveloperでのマスター・プロセスと詳細プロセスの調整の定義

この項では、Oracle BPELデザイナでのマスター・プロセスと詳細プロセスの調整の定義方法の概要を説明します。この例では、1つのマスター・プロセスと1つの詳細プロセスが定義されています。

注意:

この項では、マスター・プロセスと詳細プロセスの調整に固有のタスクについてのみ説明します。変数の作成、assignアクティビティの作成など、BPELプロセスで定義する標準のアクティビティについては説明しません。

16.2.1 マスター・プロセスの作成方法

マスター・プロセスを作成する手順は、次のとおりです。

1. で、BPELプロセス・サービス・コンポーネントを作成します。この例では、プロセスはMasterProcessという名前です。

2. 「MasterProcess」BPELプロセスをダブルクリックします。

3. 「コンポーネント」ウィンドウで、「Oracle Extensions」→「シグナル」をクリックします。

4. signalアクティビティをデザイナにドラッグします。

5. signalアクティビティをクリックして、そのプロパティ・フィールドをプロパティ・インスペクタで表示するか、signalアクティビティをダブルクリックします。

アクティビティをプロパティ・インスペクタで編集する方法の詳細は、「BPELアクティビティをプロパティ・インスペクタで編集する方法」を参照してください。

このアクティビティは、実行時に処理を実行する詳細プロセスに通知します。

6. 表16-2 に記載されている詳細を入力します。

表16-2 「Signal」ダイアログのフィールドと値

フィールド

値

名前

名前(この例では、contactDetailProcess)を入力します。

ラベル

ラベル名(この例では、beginDetailProcess)を入力します。このラベルは、ステップ6で詳細プロセスに設定したreceive signalアクティビティのラベルと一致している必要があります。

To

このシグナルを受信するプロセスのタイプとして、「詳細」を選択します。

図16-4 は、「Signal」ダイアログを示しています。

図16-4 「Signal」ダイアログ

7. 「OK」をクリックします。

8. receive signalアクティビティをデザイナにドラッグします。

9. receive signalアクティビティをダブルクリックします。

このアクティビティにより、マスター・プロセスはすべての詳細プロセスが実行したシグナルを受信するまで待機できます。

10. 表16-3 に記載されている詳細を入力します。

表16-3 「Receive Signal」ダイアログのフィールドと値

フィールド

値

名前

名前(この例では、waitForDetailProcess)を入力します。

ラベル

ラベル名(この例では、completeDetailProcess)を入力します。このラベルは、ステップ10で詳細プロセスに設定したsignalアクティビティのラベルと一致している必要があります。

To

シグナルを受信するプロセスのタイプとして、「詳細」を選択します。

図16-5 は、「Receive Signal」ダイアログを示しています。

図16-5 「Receive Signal」ダイアログ

11. 「OK」をクリックします。

これで、マスター・プロセスは次のことを実行するように設計されました。

- 実行時に処理を実行する詳細プロセスに通知します。

- 詳細プロセスが実行したシグナルを受信するまで待機します。

16.2.2 詳細プロセスの作成方法

詳細プロセスを作成する手順は、次のとおりです。

1. で、2番目のBPELプロセス・サービス・コンポーネントを作成します。この例では、プロセスはDetailProcessという名前です。

2. 「DetailProcess」BPELプロセスをダブルクリックします。

3. 「コンポーネント」ウィンドウで、「Oracle Extensions」を展開します。

4. receive signalアクティビティをBPELプロセス・サービス・コンポーネントにドラッグします。

5. receive signalアクティビティをダブルクリックします。

このアクティビティにより、詳細プロセスはマスター・プロセスが実行したシグナルを受信するまで待機できます。

6. 表16-4 に記載されている詳細を入力します。

表16-4 「Receive Signal」ダイアログのフィールドと値

フィールド

値

名前

名前(この例ではWaitForContactFromMasterProcess)を入力します。

ラベル

ラベル名(この例では、beginDetailProcess)を入力します。このラベルは、ステップ6でマスター・プロセスに設定したsignalアクティビティのラベルと一致している必要があります。

To

シグナルを受信するプロセスのタイプとして「マスター」を選択します。

図16-6 は、「Receive Signal」ダイアログを示しています。

図16-6 「Receive Signal」ダイアログ

7. 「OK」をクリックします。

8. signalアクティビティをデザイナにドラッグします。

9. signalアクティビティをダブルクリックします。

このアクティビティにより、詳細プロセスは実行時に関連するマスター・プロセスに処理が完了したことを通知できます。

10. 表16-5 に記載されている詳細を入力します。

表16-5 「Signal」ダイアログのフィールドと値

フィールド

値

名前

名前(この例では、contactDetailProcess)を入力します。

ラベル

ラベル名(この例では、completeDetailProcess)を入力します。このラベルは、ステップ10でマスター・プロセスに設定したreceive signalアクティビティのラベルと一致している必要があります。

To

送信先として、「マスター」を選択します。

図16-7 は、「Signal」ダイアログを示しています。

図16-7 「Signal」ダイアログ

11. 「OK」をクリックします。

これで、詳細プロセスは次のこと実行するように設計されました。

- マスター・プロセスが実行したシグナルを受信するまで待機します。

- マスター・プロセスに実行時に処理が完了したことを通知します。

16.2.3 invokeアクティビティの作成方法

invokeアクティビティを作成する手順は、次のとおりです。

1. 「MasterProcess」マスター・プロセスに戻ります。

2. 「コンポーネント」ウィンドウで、「BPELコンストラクト」を展開します。

3. invokeアクティビティを、BPELプロセス・サービス・コンポーネントにドラッグします。

4. invokeアクティビティをダブルクリックします。

5. ステップ1で作成した「DetailProcess」BPELプロセスをパートナ・リンクとして選択します。

6. 「詳細として呼出し」チェック・ボックスを選択します。

7. 「Invoke」ダイアログの残りのすべてのフィールドを完成し、「OK」をクリックします。

8. デザイナで、「ソース」をクリックします。BPELファイルは次のようになります。

<invoke name="MyInvoke" partnerLink="DetailProcess"
portType="dp:DetailProcess"
operation="initiate"
inputVariable="detail_input"
bpelx:invokeAsDetail name="true"/>

この属性は、詳細インスタンスとしてパートナ・プロセス(DetailProcess)を作成します。

9. 1つのマスター・プロセスが複数の詳細プロセスと相互作用する環境では、次のタスクを実行します。

a. receive signalアクティビティと相関させるために、bpelx:detailLabel属性を指定します。

<invoke name="MyInvoke" partnerLink="DetailProcess"
portType="dp:DetailProcess"
operation="initiate"
inputVariable="detail_input"/>
bpelx:detailLabel="detailProcessComplete0"
<bpelx:invokeAsdetail name="true"/>

b. マスター・プロセスのreceive signalアクティビティのdetailProcessComplete0と同じラベル値を指定します。

<bpelx:receiveSignal name="waitForNotifyFromDetailProcess0-1"
label="detailProcessComplete0" from="details"/>

c. 他の詳細プロセスについてもこれらの手順を必要に応じて繰り返し、必ず異なるラベル値を指定してください。

10. 「ファイル」メイン・メニューから「すべて保存」を選択します。
これで、マスターと詳細の調整設計が完成しました。

17 通知サービスの使用

この章では、様々なチャネルを使用してBPELプロセスから通知を送信する方法について説明します。BPELプロセスは、電子メール、ボイス・メッセージ、インスタント・メッセージ(IM)またはショート・メッセージ・サービス(SMS)を送信するように設計できます。また、BPELプロセスは、実行時にエンド・ユーザーのチャネル・プリファレンスを考慮して通知チャネルを選択するように設計することもできます。

この章の内容は次のとおりです。

- 通知サービスの概要

- 通知チャネル設定の概要

- BPELプロセスの設計での通知チャネルの選択

- エンド・ユーザーによる通知チャネル選択の許可

17.1 通知サービスの概要

様々なシナリオで、プロセス・フローの一環として、電子メール・メッセージや他のタイプの通知をユーザーに送信する必要があります。たとえば、自動処理できない特定タイプの例外には、手動による操作が必要となる場合があります。この場合、BPELプロセスでは、通知サービスを使用して、ユーザーにボイス、IM、SMSまたは電子メールで警告できます。

受信者の連絡先情報(電子メール・アドレス、電話番号など)は、静的な情報(admin@yourcompany.comなど)または実行時に動的に取得する情報のいずれかです。連絡先情報を動的に取得するには、XPath式でアイデンティティ・ストア(LDAP)から取得するか、BPELペイロードから抽出します。

この章では、次の用語を使用します。

- 通知
特定のチャネルを通じてユーザーに送信される非同期メッセージです。このメッセージは、電子メール、ボイス、IMまたはSMSメッセージとして送信できます。

- アクション可能な通知
ユーザーが応答できる通知です。たとえば、ワークフローでは、注文書の承認または却下を担当するマネージャに電子メールを送信します。マネージャは、適切な内容を記載して電子メールに返信することで、リクエストを承認または却下します。

- ヒューマン・タスク電子メール通知レイヤー
電子メール通知を直接BPELプロセスから、または暗黙的にBPELプロセスのヒューマン・タスク部分から送信します。暗黙の通知は、ヒューマン・タスク・エディタによってモデル化されます。

電子メール通知をBPELプロセスから直接送信するには、BPELプロセスにユーザー情報を明示的に指定する必要があります。ヒューマン・タスクのスコープの内側または外側に指定できます。

電子メール通知をBPELプロセスのヒューマン・タスク部分から暗黙的に送信するには、タスクに関するユーザーとの関係(つまり、作成者、割当て先など)に基づいて、受信者のみを指定します。

注意:

暗黙的な通知は、明示的な通知に比べ、より多くのコードのレイヤーを介して処理されます。明示的な通知が正しく機能している場合でも、暗黙的な通知が正しく機能しているとはかぎりません。

- Oracle User Messaging Service
BPEL通知サービスは、Oracle User Messaging Serviceが提供する基礎となるインフラストラクチャを使用して通知を送信します。

Oracle User Messaging Serviceは、エンド・ユーザーの優先チャネルを実行時に取得するためのユーザー・プリファレンス・インフラストラクチャも提供します。

Oracle User Messaging Serviceの詳細は、『Oracle User Messaging Serviceによるアプリケーションの開発』を参照してください。

図17-1 は、Oracle User Messaging Serviceインタフェースとサポートされるサービス・タイプを示しています。

図17-1 サービス・インタフェースとサポートされるサービス・タイプ

通知の詳細は、次の各項を参照してください。

- ヒューマン・ワークフローからの通知

- 「参加者の通知プリファレンスの指定」(ヒューマン・タスク・エディタで電子メール通知を指定する手順)

- Oracle User Messaging Serviceによるアプリケーションの開発

17.2 通知チャネル設定の概要

通知の設定は、複数のユーザー・インタフェース・ツールを使用する多段階のプロセスです。表17-1 に、このプロセスの概要、実行するタスク、使用ツールおよび詳細の参照先を示します。

表17-1 通知のタスク

タスク

説明

ユーザー・インタフェース

参照先

SOAコンポジット・アプリケーションの通知を送信するチャネルの選択

通知の送信方法を選択します。

- 電子メール、IM、SMSまたはボイス・チャネルを明示的に選択して構成します。
または

- 通知チャネルは明示的に選択せずに、通知を送信する必要があることを単に選択します。チャネルは、後でユーザー・メッセージング・プリファレンス・ユーザー・インタフェースで選択します。

Oracle BPELデザイナでBPELプロセス設計者が選択および構成します。

BPELプロセスの設計での通知チャネルの選択

または

エンド・ユーザーによる通知チャネル選択の許可

通知チャネルに対するドライバの構成

ドライバは、SOAコンポジット・アプリケーションをデプロイするOracle WebLogic Serverで構成します。このアクションにより、参加者は通知を受信および転送できます。電子メール、IM、SMSおよびボイス・チャネルについてドライバがサポートされます。

Oracle Enterprise Manager Fusion Middleware Controlで管理者が構成します。

Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

通知モードおよびヒューマン・ワークフローのアクション可能なアカウントの構成

ヒューマン・ワークフローで通知を使用している場合は、通知モードと、電子メールのアクション可能なアカウントを構成します。

Oracle Enterprise Manager Fusion Middleware Controlで管理者が構成します。

Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

ユーザー・プリファレンスの指定によるメッセージへのアクセスに使用するデバイスの登録

このアクションにより、ワークフロー参加者は、通知メッセージを受信できます。たとえば、エンド・ユーザーは、電子メール・クライアントを登録し、受信するメッセージ・コンテンツとメッセージの受信に使用するチャネルを指定します。

チャネルが未指定の場合は、電子メールがデフォルトで使用されます。このアプリケーションに設定されているプリファレンスは、特定のエンド・ユーザーのみに適用され、他のユーザーには適用されません。

ユーザー・メッセージング・プリファレンス・ユーザー・インタフェースでエンド・ユーザーが登録します。このインタフェースには、Oracle BPM Worklistで「プリファレンス」→「通知」の順に選択してアクセスできます。

Oracle User Messaging Serviceによるアプリケーションの開発

17.3 BPELプロセスの設計での通知チャネルの選択

Oracle JDeveloperには、電子メール、IM、SMSおよびボイス・チャネルの通知チャネルが「コンポーネント」ウィンドウにあります。使用する通知チャネルは設計時に厳密に設定できます。たとえば、次の通知チャネルを使用するようにBPELプロセスを設計できます。

- 経費レポートの金額が$1000未満の場合は、電子メール通知チャネルを使用します。

- 経費レポートの金額が$1000以上$2000以下の場合は、SMS通知チャネルを使用します。

- 経費レポートの金額が$2000を超過する場合は、ボイス通知チャネルを使用します。

BPELプロセス設計で通知チャネルを選択する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「Oracle Extensions」を展開します。

2. 「通知」セクションに移動します。

3. 通知チャネルをデザイナにドラッグします。

- 電子メール

- IM

- SMS

- ボイス

4. 選択した通知チャネルに基づいて、表17-2 に示す項を参照してください。

表17-2 通知チャネル

選択内容

参照先

電子メール

「電子メール通知チャネルの構成方法」(電子メール通知の構成)

IM

「IM通知チャネルの構成方法」(IM通知の構成)

SMS

「SMS通知チャネルの構成方法」(SMS通知の構成)

ボイス

「ボイス通知チャネルの構成方法」(ボイス・メッセージ通知の構成)

注意:

電子メール、ボイス、SMSまたはIMのアクティビティを削除しても、そのアクティビティに統合されているパートナ・リンクは自動的には削除されません。

17.3.1 電子メール通知チャネルの構成方法

「コンポーネント」ウィンドウから「電子メール」アイコンをドラッグすると、「電子メール」ダイアログが表示されます。図17-2 に、電子メール通知の必須パラメータを示します。

図17-2「電子メール」ダイアログ

電子メール通知チャネルを構成する手順は、次のとおりです。

1. 表17-3 の説明に従って、各フィールドに情報を入力します。

注意:

「To」、「Cc」および「Bcc」フィールドでは、複数のアドレスをセミコロン(;)で区切ります。

表17-3 電子メール通知パラメータ

名前

説明

名前

名前を入力するか、デフォルト名であるEmailNumberをそのまま使用します。

送信元アカウント

このメッセージの送信に使用するアカウント名。デフォルトのアカウントは「デフォルト」という名前になります。この名前は、Oracle Enterprise Manager Fusion Middleware Controlの「ワークフロー通知プロパティ」ページの「メーラー」タブで編集できます。その他のアカウントを追加するには、Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザを使用する必要があります。

Oracle Enterprise Manager Fusion Middleware Controlでこのプロパティを編集する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

To

メッセージの送信先となる電子メール・アドレス。これは、次のいずれかです。

- メッセージの作成時に入力した静的な電子メール・アドレス

- アイデンティティ・サービスを使用して取得した電子メール・アドレス

- ペイロードからの動的アドレス

XPath式ビルダーで、入力から動的に電子メール・アドレスを取得できます。「電子メール・アドレスと電話番号を動的に選択する方法」を参照してください。

Cc/BCC

メッセージのコピー先およびブラインド・コピー先となる電子メール・アドレス。「To」アドレスで説明した静的アドレスまたは動的アドレスも使用できます。

返信先

返信に使用する電子メール・アドレス。「To」アドレスで説明した静的アドレスまたは動的アドレスも使用できます。

件名

電子メール・メッセージの件名。プレーン・テキストまたは動的テキストを入力できます。XPath式ビルダーで、指定したプロセス変数のデータに基づいて動的にテキストを設定できます。

本文

電子メール・メッセージのメッセージ本文。「件名」パラメータで説明したプレーン・テキスト、HTMLまたは動的テキストも使用できます。

2. 「OK」をクリックします。

電子メール・メッセージを送信するための通知サービスを起動するBPELフラグメントが作成されます。

3. Oracle JDeveloperの外側で実行するその他の構成手順は、「通知チャネル設定の概要」の表17-1 を参照してください。

次の例では、名前がScope_NotifyCustomerofCompletionであるスコープでemailアクティビティが使用されています。Oracle User Messaging Serviceは、注文の履行時に顧客に電子メールを送信します。「Email」ダイアログでは、次の詳細を指定します。

- 顧客の電子メール・アドレスを指定するXPath式。

bpws:getVariableData('gCustomerInfoVariable','parameters','/ns3:findCustome
rInfoVO1CustomerInfoVOCriteriaResponse/ns3:result/ns2:ConfirmedEmail')

- 注文のIDを指定する手動入力テキストとXPath式の組合せ。

Order with id
<%bpws:getVariableData('gOrderInfoVariable','/ns2:orderInfoVOSDO/ns2:OrderI
d')%> shipped!

- 電子メール・メッセージの本文を指定する手動入力テキストとXPath式の組合せ。

Dear<%bpws:getVariableData('gCustomerInfoVariable','parameters','/ns6:findCusto
merInfoVO1CustomerInfoVOCriteriaResponse/ns6:result/ns4:FirstName')%>,
your order has been shipped.

図17-3に詳細を示します。

図17-3 「電子メール」ダイアログ

17.3.1.1 電子メール添付ファイルの設定

emailアクティビティを使用して添付ファイルを送信できます。各添付ファイルには、名前、MIMEタイプおよび値の3つの要素があります。添付ファイルごとにこの3つの要素をすべて設定する必要があります。

電子メール・メッセージに添付ファイルを追加する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「電子メール」を通知チャネルとして選択します。

2. 「宛先」、「件名」および「本文」に値を指定します。

3. 「添付ファイル」タブをクリックします。図17-4に詳細を示します。

図17-4 「添付ファイル」タブ

4. 「追加」アイコンをクリックし、必要な数の添付ファイルを追加します。添付ファイル数に本体部分を含める必要はありません。

5. 「名前」フィールドで、名前を変更するか、デフォルト値Attachmentnumberをそのまま使用します。

6. 「MIMEタイプ」フィールドで、「参照」アイコンをクリックして、MIMEタイプ・コンテンツを追加するための「式ビルダー」ダイアログを起動します。

7. 完了後、「OK」をクリックして「添付ファイル」タブに戻ります。

8. 「値」フィールドで、「参照」アイコンをクリックして、添付ファイルのコンテンツを追加するための「式ビルダー」ダイアログを起動します。

9. 完了後、「OK」をクリックして「添付ファイル」タブに戻ります。

複数のcopyルールを含むassignアクティビティで構成されたBPELフラグメントが生成されます。copyルールの1つによって添付ファイルがコピーされます。

10. 「OK」をクリックします。

11. Oracle BPELデザイナでEmailアクティビティを開きます。

「EmailParamsAssign」という名前のassignアクティビティが表示されます。

12. 「EmailParamsAssign」をダブルクリックします。

図17-5 に示すように、EmailParamsAssignの設定を確認します。

図17-5 「EmailParamsAssign」assignアクティビティ

電子メールを使用した添付ファイル送信の詳細は、次のドキュメントを参照してください。

- Oracle User Messaging Serviceによるアプリケーションの開発

- Oracle User Messaging Serviceの管理

17.3.1.2 電子メール・メッセージ本文のHTMLとしての書式設定

電子メール・メッセージの本文は、プレーン・テキストではなくHTMLとして書式設定できます。このアクションを実行するには、XSLT transformを適用して電子メール本文を生成します。使用するXSLTタグを追加します。XMLSpyなどのツールを使用すると、XSLTの記述とテストが容易になります。MIMEタイプは、string('text/html;charset=UTF-8')である必要があります。

電子メール通知割当ては、次の例のようになります。

<copy>
<from
expression="ora:processXSLT('TransformPositionSummary7.xslt',bpws:
getVariableData('ClientPositionSummary'))"/>
<to variable="varNotificationReq" part="EmailPayload"
query="/EmailPayload/ns9:Content/ns9:ContentBody"/>
</copy>

17.3.1.3 CDATA関数を必要とするメッセージ・コンテンツに対する動的HTMLの使用

emailアクティビティのメッセージ・コンテンツについてHTMLが動的に生成される場合は、(XSLT、ファイルの読取りなどと同様に)そのHTMLをCDATA関数にラップする必要があります。これにより、メッセージ本文のXML/HTMLコンテンツとBPELの内部XMLデータ構造の間の競合が回避されます。

たとえば、次の例に示すように、emailアクティビティ内のメッセージ・コンテンツに対してappend操作を使用すると仮定します。

<bpelx:append>
<bpelx:from
expression="ora:processXSLT('xsl/email.xslt',bpws:getVariableData('Variable_1'
))"/>
<bpelx:to variable="varNotificationReq" part="EmailPayload"
query="/EmailPayload/ns1:Content/ns1:ContentBody/ns1:MultiPart/ns1:BodyPart[1]
/ns1:ContentBody"/>
</bpelx:append>

正しく機能するためには、次の例に示すように、processXSLT()関数の出力をCDATA()関数に渡す必要があります。

<%ora:toCDATA(xdk:processXSLT('xsl/email.xslt',
bpws:getVariableData('inputVariable','payload','/client:process/client:input')
))%>

17.3.2 IM通知チャネルの構成方法

「コンポーネント」ウィンドウから「IM」アイコンをドラッグすると、「IM」ダイアログが表示されます。図17-6 に、IM通知の必須パラメータを示します。

図17-6 「IM」ダイアログ

IM通知チャネルを構成する手順は、次のとおりです。

1. 表17-4 の説明に従って、各フィールドに情報を入力します。

表17-4 IM通知パラメータ

名前

説明

名前

名前を入力するか、デフォルト名であるIMNumberをそのまま使用します。

To

メッセージの送信先となるIMアドレス。アドレスを手動で入力するか、「XPath式ビルダー」アイコンをクリックして「式ビルダー」ダイアログを表示し、アカウントを動的に入力します。

本文

IMメッセージ本文。プレーン・テキストまたは動的テキストを入力できます。XPath式ビルダーで、指定したプロセス変数のデータに基づいて動的にテキストを設定できます。

2. 「OK」をクリックします。

IM通知のための通知サービスを起動するBPELフラグメントが作成されます。

3. Oracle JDeveloperの外側で実行するその他の構成手順は、「通知チャネル設定の概要」の表17-1 を参照してください。

17.3.3 SMS通知チャネルの構成方法

「コンポーネント」ウィンドウから「SMS」アイコンをドラッグすると、「SMS」ダイアログが表示されます。図17-7 に、SMS通知の必須パラメータを示します。

図17-7 「SMS」ダイアログ

SMS通知チャネルを構成する手順は、次のとおりです。

1. 表17-5 の説明に従って、各フィールドに情報を入力します。

表17-5 SMS通知パラメータ

名前

説明

名前

名前を入力するか、デフォルト名であるSMSNumberをそのまま使用します。

送信元番号

SMS通知の送信元となる電話番号。メッセージ作成時に入力した静的な電話番号、またはペイロードに基づく動的な電話番号を使用できます。XPath式ビルダーで、入力から動的に電話番号を取得できます。「電子メール・アドレスと電話番号を動的に選択する方法」を参照してください。

電話番号

メッセージの配信先電話番号の指定方法を選択します。

- メッセージの作成時に入力した静的な電話番号。

- アイデンティティ・サービスを使用して取得した電話番号。

- ペイロードからの動的な電話番号。XPath式ビルダーで、入力から動的に電話番号を取得できます。

件名

SMSメッセージの件名。プレーン・テキストまたは動的テキストを入力できます。XPath式ビルダーで、指定したプロセス変数のデータに基づいて動的にテキストを設定できます。

本文

SMSメッセージ本文。プレーン・テキストを使用する必要があります。「件名」パラメータで説明したプレーン・テキストまたは動的テキストを使用できます。

2. 「OK」をクリックします。

SMS通知のための通知サービスを起動するBPELフラグメントが作成されます。

3. Oracle JDeveloperの外側で実行するその他の構成手順は、「通知チャネル設定の概要」の表17-1 を参照してください。

17.3.4 ボイス通知チャネルの構成方法

「コンポーネント」ウィンドウから「ボイス」アイコンをドラッグすると、「ボイス」ダイアログが表示されます。図17-8 は、ボイス通知の必須パラメータを示しています。

図17-8 「ボイス」ダイアログ

ボイス通知チャネルを構成する手順は、次のとおりです。

1. 表17-6 の説明に従って、各フィールドに情報を入力します。

表17-6 ボイス通知パラメータ

名前

説明

名前

名前を入力するか、デフォルト名であるVoiceNumberをそのまま使用します。

電話番号

メッセージの送信先となる電話番号。次のいずれかの方法で番号を指定します。

- メッセージの作成時に入力した静的な電話番号

- アイデンティティ・サービスを使用して取得した電話番号

- ペイロードからの動的な電話番号

XPath式ビルダーで、入力から動的に電話番号を取得できます。

本文

メッセージ本文です。プレーン・テキスト、XMLまたは動的テキストを入力できます。XPath式ビルダーで、指定したプロセス変数のデータに基づいて動的にテキストを設定できます。

2. 「OK」をクリックします。

ボイス通知のための通知サービスを起動するBPELフラグメントが作成されます。

3. Oracle JDeveloperの外側で実行するその他の構成手順は、「通知チャネル設定の概要」の表17-1 を参照してください。

17.3.5 電子メール・アドレスと電話番号を動的に選択する方法

特定のプロセス変数に基づいて動的に電子メール・アドレスまたは電話番号を設定できます。また、アイデンティティ・サービス用の組込みXPath関数を使用して、特定ユーザーの連絡先情報をルックアップすることも可能です。

- 電子メール・アドレスまたは電話番号をペイロードから直接取得するには、次のXPath式を使用します。

bpws:getVariableData('<variable name>', '<part>','input_xpath_to_get_an_address')

たとえば、XPath /client/BPELProcessRequest/client/mailに基づいて変数inputVariableおよびパートpayloadから電子メール・アドレスを取得するには、次のようにします。

<%bpws:getVariableData('inputVariable','payload','/client:BPELProcessRequest/
client:email')%>

XPath式ビルダーを使用して関数を選択し、入力変数からアドレスを取得するXPath式を入力できます。

- 電子メール・アドレスまたは電話番号を、基礎となるアイデンティティ・ストア(LDAP)から動的に取得するには、次のXPath式を使用します。

ids:getUserProperty(userName, attributeName[, realmName])

最初の引数は、ユーザーIDに評価されます。2番目の引数はプロパティ名です。3番目の引数はレルム名です。表17-7 に、このXPath関数で使用できるプロパティ名を示します。

表17-7 動的ユーザーXPath関数のプロパティ

プロパティ名

説明

mail

ユーザーの電子メール・アドレスのルックアップ。

telephoneNumber

ユーザーの電話番号のルックアップ。

mobile

ユーザーの携帯電話番号のルックアップ。

homephone

ユーザーの自宅電話番号のルックアップ。

次の例では、変数inputVariable、パートpayloadおよび問合せ/client:BPELProcessRequest/client:userIDで識別されるユーザーの電子メール・アドレスを取得します。

ids:getUserProperty(bpws:getVariableData(‘inputVariable',
‘payload',‘/client:BPELProcessRequest/client:userid'), ‘mail')

realmNameが未指定の場合は、デフォルトのレルム名が使用されます。たとえば、デフォルトのレルム名がjazn.comの場合、次のXPath式ではjazn.comレルム内でユーザーが検索されます。

ids:getUserProperty('jcooper', 'mail');

次のXPath式は、前述の式と同じ機能を提供します。ただし、この場合はレルム名jazn.comが明示的に指定されています。

ids:getUserProperty('jcooper', 'mail', 'jazn.com');

17.3.6 ユーザー・ディレクトリの参照による通知受信者の選択方法

通知送信先となるOracle JDeveloperのユーザーやグループは、Oracle BPEL Process Managerで使用するように構成されたユーザー・ディレクトリ(たとえば、Oracle Internet Directory)を参照することで選択できます。次のフィールドの右側にある「検索」アイコンをクリックして、「アイデンティティ・ルックアップ」ダイアログを開きます。

- 「Email」および「IM」ダイアログの「To」フィールド

- 「SMS」および「ボイス」ダイアログの「電話番号」フィールド

「アイデンティティ・ルックアップ」ダイアログの使用方法の詳細は、「ヒューマン・ワークフロー・サービスの概要」を参照してください。

17.4 エンド・ユーザーによる通知チャネル選択の許可

BPELプロセスの設計では、設計時に通知チャネルを明示的に選択せずに、通知を送信する必要性のみを示すことができます。通知の送信に使用するチャネルは、Oracle User Messaging Serviceのユーザー・メッセージング・プリファレンス・ユーザー・インタフェースでエンド・ユーザーが定義したプリファレンスに基づいて、実行時に決定されます。したがって、通知チャネルの選択権は、Oracle BPELデザイナのBPELプロセスからエンド・ユーザーに移動します。エンド・ユーザーが優先チャネルまたはルールを選択していない場合、そのユーザーへの通知の送信には、デフォルトで電子メールが使用されます。使用するチャネルを誰が選択するかに関係なく、チャネルの使用は、管理者がOracle Enterprise Manager Fusion Middleware ControlのOracle User Messaging Serviceセクションで実行したドライバのインストールと構成に基づいています。

たとえば、エンド・ユーザーは、次のように各自のプリファレンスを設定できます。

- 経費レポートの金額が$153未満の場合は、電子メール通知を受け取ります。

- 経費レポートの金額が$153以上$3678以下の場合は、SMS通知を受け取ります。

- 経費レポートの金額が$3678を超過する場合は、ボイス通知を受け取ります。

注意:

送信通知のユーザー・プリファレンスは、ヒューマン・タスク・エディタのヒューマン・ワークフローで設定することもできます。これらのプリファレンスは、「通知設定」セクションの「通知フィルタ」で設定します。これらのプリファレンスは、タスクでルールを評価する際に使用されます。詳細は、「電子メール通知によるタスクの添付ファイルの送信方法」を参照してください。

Oracle User Messaging Serviceの詳細は、『Oracle User Messaging Serviceによるアプリケーションの開発』の「ユーザー通信プリファレンス」を参照してください。

Oracle User Messaging ServiceをOracle Enterprise Manager Fusion Middleware Controlで構成する方法の詳細は、『Oracle User Messaging Serviceの管理』を参照してください。

17.4.1 エンド・ユーザーによる通知チャネルの選択を許可する方法

通知チャネルの選択をエンド・ユーザーに許可する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウ・リストで、「Oracle Extensions」を展開します。

2. 「通知」セクションから、デザイナにuser notificationアクティビティをドラッグします。図17-9 に、ユーザー通知の必須パラメータを示します。

図17-9 「User Notification」ダイアログ

3. 表17-8 の説明に従って、各フィールドに情報を入力します。

表17-8 ユーザー通知パラメータ

名前

説明

名前

名前を入力するか、デフォルト名であるUserNotificationNumberをそのまま使用します。

To

次のいずれかの方法で、この通知メッセージの受信者に有効なユーザーを入力します。

- ユーザーを手動で入力します。

- 「検索」アイコンをクリックしてダイアログを表示し、アイデンティティ・サービスを介して構成されたユーザーを選択します。アイデンティティ・サービスを使用すると、ユーザー・プロパティ、ロールおよびグループ・メンバーシップのルックアップが可能になります。

- 「XPath式ビルダー」アイコンをクリックして「式ビルダー」ダイアログを表示し、ユーザーを動的に入力します。

注意: アドレスではなくユーザー名(jcooperなど)を指定する必要があります。

件名

メッセージ名を入力するか、「XPath式ビルダー」アイコンをクリックして「式ビルダー」ダイアログを表示し、件名を動的に入力します。電子メール経由で通知を送信する場合は、実行時にこのフィールドが使用されます。ボイス、SMSまたはIMチャネル経由で通知を送信する場合、このフィールドは無視されます。

通知メッセージ

通知メッセージを入力するか、「XPath式ビルダー」アイコンをクリックして「式ビルダー」ダイアログを表示し、送信するメッセージを動的に入力します。

4. 「適用」をクリックします。

17.4.1.1 通知のヘッダーの作成および送信方法

「User Notification」ダイアログの「詳細」タブを使用すると、ヘッダーと名前の情報を作成して送信できます。この情報は、エンド・ユーザーが、通知を受信するための独自のプリファレンス・ルールを作成する際に役立ちます。次に例を示します。

- Oracle BPELデザイナによって、「一般」タブで、jcooperおよびjsteinというユーザーが指定されます。

- Oracle BPELデザイナによって、「詳細」タブで、次のヘッダーと名前の情報が作成されます。

- Amount = payload->salary

- Application = HR-Application

- 管理者は、Oracle Enterprise Manager Fusion Middleware Controlで、プロセスをデプロイし、様々なチャネル・ドライバを構成します。

- エンド・ユーザーjcooperは、ユーザー・メッセージング・プリファレンス・ユーザー・インタフェースで、次のプリファレンス・ルールを作成します。

'Email if Amount < 30000" and "SMS if Amount is between 30000 and 100000' and
"Voice if Amount > 100000"

- エンド・ユーザーjsteinは、ユーザー・メッセージング・プリファレンス・ユーザー・インタフェースで、次のプリファレンス・ルールを作成します。

If "Application == HR-Application" and Amount > 2000000" send Voice

1. 各エンド・ユーザーが独自のプリファレンス・ルールを作成できるように、ヘッダーと名前の情報を作成して送信する場合は、「詳細」をクリックします。

図17-10 に、「User Notification」ダイアログの「詳細」タブを示します。

図17-10 ユーザー通知の詳細パラメータ

2. 「追加」アイコンをクリックし、「ヘッダー」列と「名前」列に行を追加します。

3. 値を選択するためのリストを表示するには、「ヘッダー」列でフィールドをクリックします。それ以外の場合は、手動で値を入力します。

4. 「名前」列に、値を入力します。

5. 「OK」をクリックします。

18 Oracle BPEL Process Managerセンサーと分析の使用

この章では、センサーを使用して、BPELプロセスでの実行時に監視するBPELアクティビティ、変数およびフォルトを選択する方法について説明します。また、センサー・アクションを作成して、エンドポイントにセンサーの値をパブリッシュする方法についても説明します。

この章の内容は次のとおりです。

- センサーの概要

- Oracle JDeveloperでのセンサーとセンサー・アクションの構成

- Oracle Enterprise Manager Fusion Middleware Controlでのセンサーの定義とセンサー・アクションの定義の表示

- BPELプロセス分析の構成

Oracle BPEL Process Managerセンサーの詳細は、「センサー・パブリック・ビューとセンサー・アクションXSDの理解」を参照してください。

18.1 Oracle BPEL Process Managerセンサーの概要

センサーは、BPELプロセス・インスタンスのライフ・サイクル全体を通じて特定のイベントに対する関心を宣言するために使用されます。ビジネス・プロセスでは、このようなイベントとして、特定のアクティビティのアクティブ化と完了、またはビジネス・プロセス内の変数値の変更があります。

センサーがトリガーされると、特定のセンサー値が作成されます。たとえば、センサーでBPELスコープの完了に対する関心を宣言した場合、センサー値は、BPELスコープの名前とアクティビティの完了時点のタイムスタンプ値で構成されます。センサー値でBPELプロセス変数に対する関心を宣言している場合、そのセンサー値は次のもので構成されます。

- 変数が変更された時点でのその変数の値

- 変数が変更されたときのタイムスタンプ

- BPEL変数を変更したアクティビティ名およびタイプ

センサー値のデータ・フォーマットは、XMLスキーマを使用して正規化され、適切に定義されます。

センサー・アクションは、センサー値の処理方法に関する指示です。Oracle BPEL Process Managerによってセンサーがトリガーされると、そのセンサーに新しいセンサー値が作成されます。その後、そのセンサーに関連付けられているすべてのセンサー・アクションが実行されます。通常、センサー・アクションは、センサー値をデータベースに保持するか、正規化されたセンサー値データをJMSキューまたはトピックに送信します。Oracle BAMと統合すると、センサー値をOracle BAMアダプタに送信できます。

Oracle JDeveloperを使用するか、センサー構成ファイルを手動で指定することで、次のタイプのセンサーを定義できます。

- アクティビティ・センサー
アクティビティ・センサーは、BPELプロセス内のアクティビティの実行を監視します。たとえば、invokeアクティビティの実行時間や、このアクティビティによるスコープ完了までの時間を監視できます。アクティビティ・センサーに加え、アクティビティの変数も監視できます。

- 変数センサー
変数センサーは、BPELプロセスの変数(または1つの変数の複数部分)を監視する際に使用します。たとえば、変数センサーで、BPELプロセスの入力データと出力データを監視できます。

- フォルト・センサー
フォルト・センサーは、BPELフォルトを監視する際に使用します。

センサーは、通常、アクティビティ、フォルトおよび変数のBPELモデリングの一環として追加または編集します。

これらのセンサーは、次のパブリックSQLビューを使用して公開されます。

- BPEL_ACTIVITY_SENSOR_VALUES

- BPEL_FAULT_SENSOR_VALUES

- BPEL_VARIABLE_SENSOR_VALUES

これらのビューをBPEL_PROCESS_INSTANCESビューと結合し、センサー値と、センサー値を作成したBPELプロセス・インスタンスを関連付けることができます。詳細は、「センサー・パブリック・ビューとセンサー・アクションXSDの理解」を参照してください。

Oracle JDeveloperでセンサーをモデル化すると、BPELプロセス・アーカイブの一部として、次の2つの新規ファイルが作成されます。

- bpel_process_name_sensor.xml
BPELプロセスのセンサー定義が格納されます。

- bpel_process_name_sensorAction.xml
BPELプロセスのセンサー・アクション定義が格納されます。

これらのファイルの作成方法の詳細は、「アクティビティ、変数、フォルトの各センサーの構成方法」および「センサー・アクションの構成方法」を参照してください。

BPELプロセスにセンサーを定義した後は、センサー・アクションを構成して、そのセンサー・データを指定された宛先にパブリッシュする必要があります。センサーにセンサー・アクションが定義されていない場合、実行時は何も行われません。

センサー・アクションには、次の情報が必要です。

- 名前

- パブリッシュ・タイプ
パブリッシュ・タイプは、センサー・データの送信が必要な宛先を指定します。次の宛先にセンサー・データをパブリッシュできます。

- データベース
センサー・データをデータベースのレポート・スキーマにパブリッシュします。これにより、センサー・データは、SQLを使用して問い合せることができます。

- JMSキュー
センサー・データをJMSキューにパブリッシュします。XMLデータは、Sensor.xsdファイルに従って転送されます。このファイルは、Oracle JDeveloperで次のディレクトリにあります。

/soa/integration/seed/soa/shared/bpel/Sensor.xsd

Sensor.xsdファイルは、次のディレクトリにもあります。

/soa/integration/jdeveloper/seed/soa/shared/bpel/Sensor.xsd

- JMSトピック
センサー・データをJMSトピックにパブリッシュします。XMLデータは、JMSキューで使用されるファイルと同じSensor.xsdファイルに従って転送されます。

- カスタム
データをカスタムJavaクラスにパブリッシュします。

- JMSアダプタ
JMSアダプタは、リモート・キューやトピックおよび様々なJMSプロバイダへのパブリッシュに使用します。「JMSキュー」および「JMSトピック」パブリッシュ・タイプでは、ローカルJMS宛先にのみパブリッシュします。

- センサーのリスト
センサー・アクションに対応するセンサーです。

18.1.1 コンポジット・センサー

BPELセンサーは、BPELプロセス・インスタンスのライフ・サイクル全体を通じて特定のイベントに対する関心を宣言するために使用されますが、コンポジット・センサーは、メッセージにトラッキング可能フィールドを実装する手段を提供します。コンポジット・センサーを使用すると、次のタスクを実行できます。

- 受信メッセージおよび送信メッセージを監視できます。

- 受信メッセージおよび送信メッセージから計算されたJMSデータをパブリッシュします。

- ビジネス・イベント・サブスクリプションによって開始されたコンポジット・インスタンスを追跡します。

コンポジット・センサーの詳細は、「コンポジット・センサーの定義」を参照してください。

18.2 Oracle JDeveloperでのセンサーとセンサー・アクションの構成

Oracle JDeveloperでは、センサー・アクションとセンサーは、「監視」ビューの一部として表示されます。

18.2.1 センサーとセンサー・アクションへのアクセス方法

センサーとセンサー・アクションにアクセスする手順は、次のとおりです。

1. 図18-1 に示すように、Oracle BPELデザイナの上部にある監視ビューに変更を選択します。

図18-1 「監視」ビュー

図18-2 は、「構造」ウィンドウのセンサー・アクションとセンサーを示しています。

図18-2 Oracle JDeveloperに表示されたセンサーとセンサー・アクション

センサーは、通常、アクティビティ、フォルトおよび変数のBPELモデリングの一環として追加または編集します。

2. 「センサー・アクション」フォルダを右クリックし、「作成」→「センサー・アクション」の順に選択し、センサー・アクションを追加します。

3. 次の手順に従って、アクティビティ・センサー、変数センサーまたはフォルト・センサーを追加します。

a. 「センサー」フォルダを開きます。

b. 適切な「アクティビティ」、「変数」または「フォルト」サブフォルダを右クリックします。

c. 「作成」をクリックします。

4. アクティビティを右クリックして「作成」→「センサー」の順に選択し、センサーを個々のアクティビティに追加します。図18-3に詳細を示します。

図18-3 アクティビティ・センサーの作成

次の各項では、センサーとセンサー・アクションの構成方法について説明します。

18.2.2 アクティビティ、変数、フォルトの各センサーの構成方法

この項では、アクティビティ・センサー、変数センサーおよびフォルト・センサーを構成する方法について説明します。

18.2.2.1 アクティビティ・センサーを構成する手順:

ここでは、融資フロー・アプリケーションを監視して、次の情報を把握すると仮定します。

- GetCreditRatingというスコープの開始時点

- このスコープの完了時点

- 完了時点での顧客の信用格付け

この問題を解決するには、図18-4 に示すように、Oracle BPELデザイナでGetCreditRatingスコープのアクティビティ・センサーを作成します。

1. Oracle BPELデザイナの上部にある監視ビューに変更を選択します。

2. 「構造」ウィンドウで、「センサー」フォルダを開きます。

3. 「アクティビティ」を右クリックし、「作成」を選択します。

4. 「アクティビティ名」フィールドの右側で、「参照」アイコンをクリックして、センサーを作成するアクティビティを選択します。これは必須フィールドです。

図18-4 アクティビティ・センサーの作成

センサーが関連付けられたアクティビティは、Oracle BPELデザイナでは拡大鏡で識別されます。

センサーの起動タイミングは、図18-4 に示す「評価時間」リストを使用して制御します。

5. 次の中から選択します。

- すべて:
アクティブ化、完了、フォルト、補正および再試行の各フェーズを通して監視します。

- アクティブ化
センサーは、アクティビティの実行直前に起動されます。

- 完了
センサーは、アクティビティの実行直後に起動されます。

- フォルト
センサーは、アクティビティの実行中にフォルトが発生した場合に起動されます。この値は、単純なアクティビティを監視するセンサーにのみ選択してください。

- 補正
センサーは、関連するscopeアクティビティが補正されたときに起動されます。この値は、スコープを監視するセンサーにのみ選択してください。

- 再試行
センサーは、関連するinvokeアクティビティが再試行されたときに起動されます。

bpel_process_name_sensor.xmlファイルに新規エントリが作成されます。

<sensor sensorName="CreditRatingSensor"

classname="oracle.tip.pc.services.reports.dca.agents.BpelActivitySensorAgent"
kind="activity"
target="GetCreditRating">

<activityConfig evalTime="all">
<variable outputNamespace="http://www.w3.org/2001/XMLSchema"
outputDataType="int"
target="$crOutput/payload//services:rating"/>
</activityConfig>
</sensor>

6. アクティビティで変数センサーを作成するには、「アクティビティ変数センサー」セクションで「追加」アイコンをクリックします。これはオプションのフィールドです。

7. アクティビティに対するセンサー・アクションを追加するには、「センサー・アクション」セクションで「追加」アイコンをクリックします。詳細は、「センサー・アクションの構成方法」を参照してください。

8. 「OK」をクリックします。

注意:

「アクティビティ変数センサー」と「センサー・アクション」のセクションで値を指定しなかった場合、Oracle JDeveloperの「ログ」ウィンドウやログ・ファイルで検証のエラー・メッセージや警告メッセージを受信しません。これは予想された動作です。

18.2.2.2 変数センサーを構成する手順:

すべての着信融資申請を記録する場合、変数センサーを作成できます。

1. Oracle BPELデザイナの上部にある監視ビューに変更を選択します。

2. 「構造」ウィンドウで、「センサー」フォルダを開きます。

3. 「変数」を右クリックし、「作成」を選択します。

4. 図18-5 に示すように、「ターゲット」フィールドの右側にある「編集」アイコンをクリックして、変数に変数センサー(この例ではinputという名前)を作成します。

図18-5 変数センサーの作成

「ターゲット」フィールドの選択内容に基づいて、「出力ネームスペース」フィールドと「出力データ型」フィールドは自動的に入力されます。

bpel_process_name_sensor.xmlファイルに新規エントリが作成されます。

<sensor sensorName="LoanApplicationSensor"
classname="oracle.tip.pc.services.reports.dca.agents.BpelVariableSensorAgent"
kind="variable"
target="$input/payload">
<variableConfig outputNamespace="http://www.autoloan.com/ns/autoloan"
outputDataType="loanApplication"/>
</sensor>

18.2.2.3 フォルト・センサーを構成する手順:

フォルトを監視(この例ではアイデンティティ・サービスから)する場合、フォルト・センサーを作成できます。

1. Oracle BPELデザイナの上部にある監視ビューに変更を選択します。

2. 「構造」ウィンドウで、「センサー」フォルダを開きます。

3. 「フォルト」を右クリックし、「作成」を選択します。

4. 図18-6 に示すように、「ネームスペース」 フィールドの上にある「参照」アイコンをクリックして、フォルト・センサーを作成します。

図18-6 フォルト・センサーの作成

選択内容に基づいて、「ネームスペース」フィールドと「ローカル・パート」フィールドは自動的に入力されます。

5. フォルトに対するセンサー・アクションを追加するには、「センサー・アクション」セクションで「追加」アイコンをクリックします。詳細は、「センサー・アクションの構成方法」を参照してください。

6. 「OK」をクリックします。

bpel_process_name_sensor.xmlファイルに新規エントリが作成されます。

<sensor sensorName="IdentityServiceFault"
classname="oracle.tip.pc.services.reports.dca.agents.BpelFaultSensorAgent"
kind="fault"
target="is:identityServiceFault">
<faultConfig/>
</sensor>

18.2.3 センサー・アクションの構成方法

センサーを作成する場合は、実行時に監視するアクティビティ、変数およびフォルトを識別します。エンドポイントにセンサーの値をパブリッシュする場合(たとえば、図18-5 で作成したLoanApplicationSensor変数センサーのデータをJMSキューにパブリッシュする場合)は、図18-7 に示すように、センサー・アクションを作成し、LoanApplicationSensor変数に関連付けます。

センサー・アクションを構成する手順は、次のとおりです。

1. Oracle BPELデザイナの上部にある監視ビューに変更を選択します。

2. 「構造」ウィンドウで、「センサー・アクション」フォルダを右クリックします。

3. 「作成」→「センサー・アクション」の順に選択します。

4. 表18-1 に記載されている詳細を入力します。

表18-1 「センサー・アクション」ダイアログ

フィールド

説明

名前

名前を入力するか、デフォルト名をそのまま使用します。

パブリッシュ・タイプ

センサー・データをパブリッシュする宛先を選択します。詳細は、「センサーの概要」を参照してください。

JMSコネクション・ファクトリ

パブリッシュ・タイプが「JMSキュー」、「JMSトピック」または「JMSアダプタ」の場合は、コネクション・ファクトリを指定します。

パブリッシュ・ターゲット

パブリッシュ・タイプが「JMSキュー」、「JMSトピック」、「カスタム」または「JMSアダプタ」の場合は、パブリッシュ・ターゲットを指定する必要があります。パブリッシュ・ターゲットは、指定されたパブリッシュ・タイプによって異なる内容を表します。

- パブリッシュ・タイプがデータベースの場合、このフィールドは空白のままになります。

- パブリッシュ・タイプが「JMSキュー」、「JMSトピック」または「JMSアダプタ」の場合は、JMS宛先のJNDI名を表します。

- パブリッシュ・タイプが「カスタム」の場合は、完全修飾されたJavaクラス名を表します。

フィルタ

フィルタ・ロジックはブール式で入力します。フィルタを使用すると、特定の範囲内のセンサー・データを監視できます。構成済のフィルタの例については、図18-9 を参照してください。

有効化

センサー・アクションを無効にする場合、このチェック・ボックスの選択を解除します。デフォルトでは、有効になっています。このチェック・ボックスの選択を解除してセンサー・アクションを無効にすると、センサー・アクションでデータがパブリッシュされません。

図18-7 センサー・アクションの作成

bpel_process_name_sensorAction.xmlファイルに新規エントリが作成されます。

<action name="BAMFeed"
enabled="true"
publishType="JMSQueue"
publishTarget="jms/bamTopic">
<sensorName>LoanApplicationSensor</sensorName>
<property name=“JMSConnectionFactory“>
weblogic.jms.ConnectionFactory
</property>
</action>

注意:

「センサー・アクション」ダイアログの「フィルタ」フィールドには、<(より小さい)記号は指定できません。指定すると、Oracle JDeveloperにより、bpel_process_name_sensorAction.xmlファイルの<記号が&lt;に変換されます。filename_sensorAction.xmlファイルを直接編集して<記号を指定することもできません。この操作ではエラーが発生します。

5. LoanApplicationSensorおよびCreditRatingSensorの値をデータベースのレポート・スキーマにパブリッシュする場合は、図18-8 に示すように、追加のセンサー・アクションを作成し、CreditRatingSensorとLoanApplicationSensorの両方に関連付けます。

図18-8 追加のセンサー・アクションの作成

bpel_process_name_sensorAction.xmlファイルに新規エントリが作成されます。

<action name="PersistingAction"
enabled="true"
publishType="BPELReportsSchema">
<sensorName>LoanApplicationSensor</sensorName>
<sensorName>CreditRatingSensor</sensorName>
</action

複数のエンドポイントに対して1つのセンサーのデータをパブリッシュできます。前述の2つのコード例では、LoanApplicationSensorのデータがJMSキューとデータベース・レポート・スキーマの両方にパブリッシュされました。

6. 融資金額が$100,000を超える融資申請を監視する場合は、図18-9 に示すように、フィルタ付きのセンサー・アクションを作成します。フィルタ問合せの設計時の検証はありません。問合せが正しいことを確認する必要があります。

図18-9 フィルタ付きのセンサー・アクションの作成

bpel_process_name_sensorAction.xmlファイルに新規エントリが作成されます。

<action name="BigMoneyBAMAction"
enabled='true'
filter="boolean(/s:actionData/s:payload
/s:variableData/s:data
/autoloan:loanAmount > 100000)"
publishType="JMSQueue"
publishTarget="jms/bigMoneyQueue">
<sensorName>LoanApplicationSensor</sensorName>
<property name=“JMSConnectionFactory“>
weblogic.jms.ConnectionFactory
</property>
</action>

注意:

- bpel_process_name_sensorAction.xml構成ファイルでアクション・フィルタを構成する必要があるすべてのネームスペースを指定する必要があります。たとえば、ネームスペースが"http://myCustomer"のcustomer XMLスキーマ要素があり、customer age要素に対してフィルタを作成すると仮定します。したがって、フィルタでネームスペースを使用する前に、ファイルで"http:/myCustomer"のネームスペースを宣言する必要があります。そうしないと、有効な問合せを作成できません。ファイルの属性宣言部分にxmlns:ns1="http://myCustomer"を追加します。これで、問合せで..../ns1:customer/ns1:age/...を使用できるようになります。

- フィルタは、ブール型のXPath式として指定する必要があります。

7. 組込みのパブリッシュ・タイプ(「データベース」、「JMSキュー」、「JMSトピック」および「JMSアダプタ」)では対応できない特殊なセンサー・アクション要件がある場合は、図18-10 に示すように、「カスタム」パブリッシュ・タイプでセンサー・アクションを作成できます。「パブリッシュ・ターゲット」フィールド内の名前は、実装する必要がある完全修飾Javaクラス名を示します。詳細は、「カスタム・データ・パブリッシャの作成方法」を参照してください。

図18-10 「カスタム」パブリッシュ・タイプの使用

18.2.4 リモート・トピックおよびキューへのパブリッシュ方法

「JMSキュー」および「JMSトピック」パブリッシュ・タイプでは、ローカルJMS宛先にのみパブリッシュします。センサー・データをリモート・トピックおよびキューにパブリッシュする場合は、図18-11 に示すように、「JMSアダプタ」パブリッシュ・タイプを使用します。

図18-11 「JMSアダプタ」パブリッシュ・タイプの使用

JMSアダプタでは、センサー・データをリモート・トピックおよびキューにパブリッシュでき、さらに、次のように様々なJMSプロバイダがサポートされます。

- サード・パーティJMSプロバイダ(Tibco JMS、IBM WebSphere MQ JMS、SonicMQなど)

- Oracle Enterprise Messaging Service (OEMS)プロバイダ(メモリー/ファイル、データベースなど)

「JMSアダプタ」パブリッシュ・タイプを選択した場合は、weblogic-ra.xmlファイルにエントリを作成する必要があり、このファイルはでの編集によって更新されます。このコンソールで作成されるJMSコネクション・ファクトリ(プール)の各エントリは、weblogic-ra.xmlの1つのJNDIエントリに相当します。「センサー・アクション」ダイアログは、JMSコネクション・ファクトリ(プール)の作成時に選択したJNDI名で更新してください。

JMSアダプタの詳細は、『テクノロジ・アダプタの理解』を参照してください。

18.2.5 カスタム・データ・パブリッシャの作成方法

カスタム・データ・パブリッシャを作成するには、次の各手順を実行します。

カスタム・データ・パブリッシャを作成する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「BPELプロジェクト」をダブルクリックします。

「プロジェクト・プロパティ」ダイアログが表示されます。

2. 「ライブラリとクラスパス」をクリックします。

3. 次のファイルを参照して選択します。

SOA_ORACLE_HOME/lib/java/shared/oracle.soainfra.common/11.1.1/orabpel.jar

図18-12に詳細を示します。

図18-12 「プロジェクト・プロパティ」ダイアログ

4. 新規Javaクラスを作成します。

パッケージとクラス名は、センサー・アクションのパブリッシュ・ターゲット名と一致している必要があります。

5. com.oracle.bpel.sensor.DataPublisherインタフェースを実装します。

これにより、ソース・ファイルが更新され、DataPublisherインタフェースのメソッドとimport文が組み込まれます。

6. Oracle JDeveloperを使用して、図18-13のサンプル・カスタム・データ・パブリッシャ・クラスに示すように、DataPublisher インタフェースのpublishメソッドを実装します。

図18-13 カスタム・データ・パブリッシャ・クラス

7. クラスは必ず正常にコンパイルされる必要があります。

次回BPELプロセスをデプロイする際に、JavaクラスがSOAアーカイブ(SAR)に追加され、デプロイされます。

注意:

データ・パブリッシャの実装に必要な追加のJavaライブラリがクラスパスに存在していることが必要です。

Oracle BPEL Process Managerでは、複数のプロセス・インスタンスを同時に実行できるため、データ・パブリッシャのコードをスレッド・セーフとするか、適切な同期ブロックを追加する必要があります。高いスループットを確保するには、同期が必要な共有データ・オブジェクトを使用しないでください。

18.2.6 composite.xmlファイルへのセンサーとセンサー・アクションの登録方法

Oracle JDeveloperは、composite.xmlファイルを自動的に更新し、次の例に示すように、センサーとセンサー・アクションの適切なプロパティを取り込みます。

<composite name="JMSQFComposite" applicationName="JMSQueueFilterApp"
revision="1.0" label="2007-04-02_14-41-31_553" mode="active" state="on">
<import namespace="http://xmlns.oracle.com/JMSQueueFilter"
location="JMSQueueFilter.wsdl" importType="wsdl"/>
<service name="client">
<interface.wsdl interface="http://xmlns.oracle.com/
JMSQueueFilter#wsdl.interface(JMSQueueFilter)"/>
<binding.ws
port="http://xmlns.oracle.com/JMSQueueFilter#wsdl.endpoint(client/
JMSQueueFilter_pt)"/>
</service>
<component name="JMSQueueFilter">
<implementation.bpel src="JMSQueueFilter.bpel"/>
<property name="configuration.sensorLocation" type="xs:string"
many="false">JMSQueueFilter_sensor.xml</property>
<property name="configuration.sensorActionLocation" type="xs:string"
many="false">JMSQueueFilter_sensorAction.xml</property>
</component>
<wire>
<source.uri>client</source.uri>
<target.uri>JMSQueueFilter/client</target.uri>
</wire>
</composite>

前の例のように、<property name= ...>を使用して追加のプロパティを指定できます。

18.3 Oracle Enterprise Manager Fusion Middleware Controlでのセンサーの定義とセンサー・アクションの定義の表示

Oracle Enterprise Manager Fusion Middleware Controlでは、センサーのメタデータ、センサー・アクション、およびプロセス実行の一部として作成されたセンサー・データの表示をサポートしています。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

注意:

関連するデータベース・センサー・アクションがあるセンサーのみが、Oracle Enterprise Manager Fusion Middleware Controlに表示されます。JMSキュー、JMSトピック、リモートJMSまたはカスタム・センサー・アクションに関連するセンサーは表示されません。

18.4 BPELプロセス分析の構成

BPELプロセス分析には次の機能があります。

- Oracle BPMN、ヒューマン・ワークフローおよびBPELプロセスなどのOracle SOA Suiteコンポーネントにおいて分散データを収集するための共通測定メカニズム。

- 測定イベントの評価、公開および合成を行うためのランタイム・インフラストラクチャ。

BPELプロセス分析のOracle Business Activity Monitoring (BAM)との統合の詳細は、『Oracle BAMでのビジネス・アクティビティのモニタリング』の「Oracle SOA Suiteとの統合」および『Oracle SOA Suiteの理解』の「Oracle Business Activity Monitoringによるビジネス・インサイトの取得」を参照してください。

18.4.1 ビジネス・インジケータの概要

ビジネス・インジケータがSOAコンポジット・アプリケーションで定義され、コンポーネントの分析とメトリック計算に寄与するオブジェクトを識別します。ビジネス・インジケータは、次のタイプで構成されています。

- メジャー
売上金額や従業員の給料などの変数の値を格納します。 メジャーは連続的なデータ型のみ有効で、一般的に数値です。

- ディメンション
グループをラベルしたりメジャーをフィルタします。

- カウンタ
マークされた要素をプロセス・インスタンスが完了した回数をトラッキングします。

メタデータが指定されたディメンションとメジャーが、測定の一部として取得されます。

コンポジット内にある複数のBPELプロセスで共有したりバインドできるようにビジネス・インジケータを設計します。分析実行時にコンポジットが実行する際、あるプロセスから別のプロセスへ変化する値をこれによって監視できます。

18.4.2 標準サンプリング・ポイントの概要

標準サンプリング・ポイントとは、コンポーネントでは本質的に測定イベントの作成を試行するコンポーネント・パスのポイントです。測定メタデータでは測定をこれらの標準サンプリング・ポイントで構成できます。適切な測定メタデータが存在すると、それによって標準サンプリング・ポイント測定イベントの一部またはすべてでこれらの測定イベントの生成、公開および処理ができます。たとえば、プロセスの標準サンプリング・ポイントは、次にできます。

- プロセスの起動と停止

- アクティビティの起動と停止

- フォルト

18.4.3 ユーザー定義のサンプリング・ポイントの概要

これらは、コンポーネントで指定可能なサンプリング・ポイントです。

- 測定マーク:
指定されたメジャーの測定における単一の点です。

- 測定間隔:
一般的にコンポーネントで取得されるパスに沿って開始点と終了点で構成される測定です(したがって、測定間隔名で識別される間隔を構成します)。

- 測定カウンタ:
コンポーネントで取得されるパスにおいて指定された点の出現を識別する測定です。

測定とは、実行時に実行される選択ビジネス・インジケータとサンプリング・ポイントの組合せです。測定の詳細は、「測定を定義する方法」を参照してください。

18.4.4 分析ビューにアクセスする方法

Oracle BPELデザイナにおいてビジネス・インジケータと測定をBPELプロセスの分析ビューで編集します。

分析ビューにアクセスするには:

1. SOAコンポジット・エディタで、BPELプロセスをダブルクリックします。

2. Oracle BPELデザイナのBPELプロセス上部で、分析ビューに変更をクリックします。図18-14に詳細を示します。

図18-14 Oracle BPELデザイナの分析ビュー・アイコン

図18-15 に示すように、これによってBPELプロセスが分析ビューに表示されます。

- 「コンポーネント」ウィンドウでは、BPELプロセス・アクティビティにドラッグできる測定マークと間隔のパレットが表示されます。

- 「構造」ウィンドウでは、カウンタ、ディメンションおよびメジャーを作成するためのビジネス・インジケータが表示されます。

図18-15 BPELプロセスの分析ビュー

ビジネス・インジケータと測定設計が完了すると、分析ビューは図18-16 のようになります。

- BPELプロセスで定義された測定(間隔とマーク)とビジネス・インジケータ(カウンタ、ディメンションおよびメジャー)は、「構造」ウィンドウに表示されます。ビジネス・インジケータの作成、編集および削除は、「構造」ウィンドウでできます。測定の編集および削除は「構造」ウィンドウでできますが、作成はできません。測定は、「コンポーネント」ウィンドウから適切なアイコンをドラッグすることで作成されます。

- 測定の間隔とマークはBPELプロセスの読取り専用アクティビティの上部でフロータと定義されます。測定フロータはBPELプロセスにおけるアクティビティの上部でマウスにより周囲に移動して、必要なトポロジを実現できます。

- Oracle BPELデザイナの下部にあるプロパティ・インスペクタにより、選択したビジネス・インジケータや測定を編集できます。変更は自動的にコミットされます。

図18-16 ビジネス・インジケータと測定の設計が完成した分析ビュー

18.4.4.1 ビジネス・インジケータを定義する方法

作成中にビジネス・インジケータをBPEL XPath式関数にバインドできます。コンポジット内にある複数のBPELプロセスで共有したりバインドできるようにビジネス・インジケータを設計します。分析実行時にコンポジットが実行する際、あるプロセスから別のプロセスへ変化する値をこれによって監視できます。

次のビジネス・インジケータをBPELプロセスで定義できます。

- BPELプロセスのカウンタ・バインディングを定義します。利用可能なカウンタが選択され、BPELプロセスにバインドされます。その際、XPathの指定は不要です。カウンタとは、BPELアクティビティが実行時に実行される回数をカウントするものです。バインドでXPath式の指定が不要であることをこれは意味します。

- BPELプロセスのディメンション・バインディングを定義します。利用可能なディメンションが選択され、BPEL XPath式にバインドされます。

- BPELプロセスのメジャー・バインディングを定義します。利用可能なメジャーが選択され、BPEL XPath式にバインドされます。

ビジネス・インジケータの詳細は、「ビジネス・インジケータの概要」を参照してください。

「ビジネス・インジケータをビジネス・インジケータ概要エディタで編集する方法」で説明されているように、定義後、ビジネス・インジケータ概要エディタでビジネス・インジケータの編集と削除ができます。

18.4.4.1.1 カウンタの定義

ビジネス・インジケータのカウンタを定義できます。

カウンタを定義する手順は、次のとおりです。

1. 「分析ビューにアクセスする方法」の説明に従って、BPELプロセスで分析ビューにアクセスします。

2. 「構造」ウィンドウで、「カウンタ」を右クリックして「作成」を選択します。

「カウンタのバインド」ダイアログが表示されます。

3. 名前を選択して「OK」をクリックします。バインドするカウンタがない場合、「追加」アイコンをクリックして、新しいカウンタを作成します。また、このダイアログにある選択で表示されるカウンタをビジネス・インジケータ概要エディタで作成できます。詳細は、「ビジネス・インジケータをビジネス・インジケータ概要エディタで編集する方法」を参照してください。

完了すると、「カウンタのバインド」ダイアログは図18-17 のようになります。

図18-17 「カウンタのバインド」ダイアログ

18.4.4.1.2 ディメンションの定義

ビジネス・インジケータのディメンションを定義できます。

ディメンションを定義する手順は、次のとおりです。

1. 「分析ビューにアクセスする方法」の説明に従って、BPELプロセスで分析ビューにアクセスします。

2. 「構造」ウィンドウで、「ディメンション」を右クリックして「作成」を選択します。

「ディメンションのバインド」ダイアログが表示されます。

3. 環境に適した値を入力し、「OK」をクリックします。表18-2に詳細を示します。

表18-2 「ディメンションのバインド」ダイアログ

要素

説明

名前

名前を選択します。バインドするディメンションがない場合、「追加」アイコンをクリックして、「ディメンションの作成」ダイアログを起動し、名前を入力してディメンションのデータ型(ブール、10進数、整数、文字列または時間)を選択します。

また、このダイアログにある選択で表示されるディメンションをビジネス・インジケータ概要エディタで作成できます。詳細は、「ビジネス・インジケータをビジネス・インジケータ概要エディタで編集する方法」を参照してください。

注意: オプションの範囲は、整数や10進数などのデータ型で指定できます。これによって適切にレポート処理するようにディメンションで分析実行時に範囲を表示できます。

XPath式

「編集」アイコンをクリックして、ディメンションにバインドするためにXPath式を構築する「式ビルダー」ダイアログを起動します。

完了すると、「ディメンションのバインド」ダイアログは図18-18 のようになります。

図18-18 「ディメンションのバインド」ダイアログ

18.4.4.1.3 メジャーの定義

ビジネス・インジケータのメジャーを定義できます。

メジャーを定義する手順は、次のとおりです。

1. 「分析ビューにアクセスする方法」の説明に従って、BPELプロセスで分析ビューにアクセスします。

2. 「構造」ウィンドウで、「メジャー」を右クリックして「作成」を選択します。

「メジャーのバインド」ダイアログが表示されます。

3. 環境に適した値を入力し、「OK」をクリックします。表18-3に詳細を示します。

表18-3 「メジャーのバインド」ダイアログ

要素

説明

名前

名前を選択します。バインドするメジャーがない場合、「追加」アイコンをクリックして、「メジャーの作成」ダイアログを起動し、名前を入力してメジャー(整数や10進数)を選択します。

また、このダイアログにある選択で表示されるメジャーをビジネス・インジケータ概要エディタで作成できます。詳細は、「ビジネス・インジケータをビジネス・インジケータ概要エディタで編集する方法」を参照してください。

XPath式

「編集」アイコンをクリックして、メジャーにバインドするためにXPath式を構築する「式ビルダー」ダイアログを起動します。

完了すると、「メジャーのバインド」ダイアログは図18-19 のようになります。

図18-19 「メジャーのバインド」ダイアログ

18.4.4.2 測定を定義する方法

「コンポーネント」ウィンドウは、図18-20 に示す測定タイプで構成されます。

図18-20 「コンポーネント」ウィンドウの測定タイプ

デザイナで初期作成を行うために測定タイプをBPELプロセス・アクティビティにドラッグします。測定はBPELプロセスの読取り専用アクティビティの上部でフロータと定義されます。測定は、プロパティ・インスペクタまたは測定をダブルクリックすることで、後で編集できます。測定フロータはBPELプロセスの上部でマウスにより周囲に移動して、必要なトポロジを実現できます。

各測定タイプには2つのタブが含まれています。

- 「一般」タブ: 影響されるアクティビティを定義するために、取得される測定をトリガーする評価イベント、測定の説明、および測定が有効にされているかどうかがあります。

- 「ビジネス・インジケータ」タブ: 測定のビジネス・インジケータを選択するためのものです。

18.4.4.2.1 カウンタ・マークを定義する方法

カウンタ・マークの測定を定義できます。

カウンタ・マークを定義するには:

1. 「分析ビューにアクセスする方法」の説明に従って、BPELプロセスで分析ビューにアクセスします。

2. 「コンポーネント」ウィンドウから、「カウンタ・マーク」アイコンをアクティビティにドラッグするか、アクティビティを右クリックして「カウンタ・マーク」を選択します。

3. 追加したアイコンをダブルクリックします。

「カウンタ・マーク」ダイアログが表示されます。

4. 環境に適した値を入力し、「OK」をクリックします。表18-4に詳細を示します。

表18-4 「カウンタ・マーク」ダイアログ: 「一般」タブ

要素

説明

名前

カウンタ・マーク名を入力します。

アクティビティ

カウンタ・マークが取得されるBPELアクティビティが表示されます。

評価イベント

カウンタ・マークをトリガーする特定アクティビティ・イベントを選択します。5つのアクティビティ・イベント(「アクティブ化」、「補正」、「完了」、「フォルト」および「再試行」)のうちのいずれかを指定できます。

説明

カウンタ・マークの説明(オプション)を入力します。

有効

カウンタ・マークを有効にするかどうかを選択します。デフォルトでは、この測定は有効にされます。

完了すると、「カウンタ・マーク」ダイアログの「一般」タブは図18-21 のようになります。

図18-21 「カウンタ・マーク」ダイアログの「一般」タブ

5. 「ビジネス・インジケータ」タブをクリックします。

6. 選択されたビジネス・インジケータを「選択済み」セクションに移動します。また、「追加」アイコンをクリックして、新しいビジネス・インジケータを作成できます。作成されたビジネス・インジケータは「選択済み」セクションに自動的に追加されます。

注意:

カウンタ・マークのカウンタの作成と選択のみができます。ディメンションは暗黙的にカウンタ・マークに追加され、カウンタ・マークではメジャーの作成と選択はできません。間隔の開始、間隔の停止および単一マークではメジャーの作成と選択のみができます。

完了すると、「ビジネス・インジケータ」タブは図18-22 のようになります。

図18-22 「ビジネス・インジケータ」タブ

18.4.4.2.2 間隔の開始を定義する方法

間隔の開始の測定を定義できます。

間隔の開始を定義するには:

1. 「分析ビューにアクセスする方法」の説明に従って、BPELプロセスで分析ビューにアクセスします。

2. 「コンポーネント」ウィンドウから、「間隔の開始」アイコンをアクティビティにドラッグするか、アクティビティを右クリックして「間隔の開始」を選択します。

3. 追加したアイコンをダブルクリックします。

「間隔の開始」ダイアログが表示されます。

4. 環境に適した値を入力し、「OK」をクリックします。表18-5に詳細を示します。

表18-5 「間隔の開始」ダイアログ: 「一般」タブ

要素

説明

名前

間隔の開始の名前を入力します。

アクティビティ

間隔が開始するBPELアクティビティが表示されます。

評価イベント

間隔の開始をトリガーする特定アクティビティ・イベントを選択します。5つのアクティビティ・イベント(「アクティブ化」、「補正」、「完了」、「フォルト」および「再試行」)のうちのいずれかを指定できます。

説明

間隔の開始の説明(オプション)を入力します。

有効

間隔の開始を有効にするかどうかを選択します。デフォルトでは、この測定は有効にされます。

注意:

名前の変更は対応する間隔の停止の測定に伝播されます。間隔名は、間隔の開始と間隔の停止の測定の両方で共有されるからです。

さらに、アクティビティが変更されると、デザイナで間隔の開始のフロータのアクティビティ・アンカーが更新されます。

完了すると、「間隔の開始」ダイアログの「一般」タブは図18-23 のようになります。

図18-23 「間隔の開始」ダイアログの「一般」タブ

5. 「ビジネス・インジケータ」タブをクリックします。

6. 選択されたビジネス・インジケータを「選択済み」セクションに移動します。また、「追加」アイコンをクリックして、新しいビジネス・インジケータを作成できます。作成されたビジネス・インジケータは「選択済み」セクションに自動的に追加されます。

注意:

間隔の開始のメジャーの作成と選択のみができます。ディメンションは暗黙的に間隔の開始に追加され、間隔の開始ではカウンタの作成と選択はできません。カウンタ・マークではカウンタの作成と選択のみができます。

間隔の開始でビジネス・インジケータに関する変更は、対応する間隔の停止に伝播されます。間隔の開始と停止の両方で同じビジネス・インジケータを共有するからです。

完了すると、「ビジネス・インジケータ」タブは図18-24 のようになります。

図18-24 「ビジネス・インジケータ」タブ

18.4.4.2.3 間隔の停止を定義する方法

間隔の停止の測定を定義できます。

間隔の停止を定義するには:

1. 「分析ビューにアクセスする方法」の説明に従って、BPELプロセスで分析ビューにアクセスします。

2. 「コンポーネント」ウィンドウから、「間隔の停止」アイコンをアクティビティにドラッグするか、アクティビティを右クリックして「間隔の停止」を選択します。

3. 追加したアイコンをダブルクリックします。

「間隔の終了」ダイアログが表示されます。

4. 環境に適した値を入力し、「OK」をクリックします。表18-6に詳細を示します。

表18-6 「間隔の終了」ダイアログ: 「一般」タブ

要素

説明

名前

間隔の停止の名前を入力します。

アクティビティ

間隔が停止するBPELアクティビティが表示されます。

評価イベント

間隔の停止をトリガーする特定アクティビティ・イベントを選択します。5つのアクティビティ・イベント(「アクティブ化」、「補正」、「完了」、「フォルト」および「再試行」)のうちのいずれかを指定できます。

説明

間隔の停止の説明(オプション)を入力します。

有効

間隔の停止を有効にするかどうかを選択します。デフォルトでは、この測定は有効にされます。

注意:

名前の変更は対応する間隔の開始に伝播されます。間隔名は、間隔の開始と間隔の停止の測定の両方で共有されるからです。

アクティビティが変更されると、デザイナで間隔の停止のフロータのアクティビティ・アンカーが更新されます。

完了すると、「間隔の終了」ダイアログの「一般」タブは図18-25 のようになります。

図18-25 「間隔の終了」ダイアログの「一般」タブ

5. 「ビジネス・インジケータ」タブをクリックします。

6. 選択されたビジネス・インジケータを「選択済み」セクションに移動します。また、「追加」アイコンをクリックして、新しいビジネス・インジケータを作成できます。作成されたビジネス・インジケータは「選択済み」セクションに自動的に追加されます。

注意:

間隔の停止のメジャーの作成と選択のみができます。ディメンションは暗黙的に間隔の停止に追加され、間隔の停止ではカウンタの作成と選択はできません。カウンタ・マークではカウンタの作成と選択のみができます。

間隔の停止でビジネス・インジケータに関する変更は、対応する間隔の開始に伝播されます。間隔の開始と停止の両方で同じビジネス・インジケータを共有するからです。

完了すると、「ビジネス・インジケータ」タブは図18-26 のようになります。

図18-26 「ビジネス・インジケータ」タブ

18.4.4.2.4 単一マークを定義する方法

単一マークの測定を定義できます。

単一マークを定義するには:

1. 「分析ビューにアクセスする方法」の説明に従って、BPELプロセスで分析ビューにアクセスします。

2. 「コンポーネント」ウィンドウから、「単一マーク」アイコンをアクティビティにドラッグするか、アクティビティを右クリックして「単一マーク」を選択します。

3. 追加したアイコンをダブルクリックします。

管理マーク・ダイアログが表示されます。

4. 環境に適した値を入力し、「OK」をクリックします。表18-7に詳細を示します。

表18-7 管理マーク・ダイアログ: 「一般」タブ

要素

説明

名前

単一マークの名前を入力します。

アクティビティ

単一マークが取得されるBPELアクティビティが表示されます。

評価イベント

単一マークをトリガーする特定アクティビティ・イベントを選択します。5つのアクティビティ・イベント(「アクティブ化」、「補正」、「完了」、「フォルト」および「再試行」)のうちのいずれかを指定できます。

説明

単一マークの説明(オプション)を入力します。

有効

単一マークを有効にするかどうかを選択します。デフォルトでは、この測定は有効にされます。

注意:

アクティビティが変更されると、デザイナで単一マーク・フロータのアクティビティ・アンカーが更新されます。

完了すると、管理マーク・ダイアログの「一般」タブは図18-27 のようになります。

図18-27 管理マーク・ダイアログの「一般」タブ

5. 「ビジネス・インジケータ」タブをクリックします。

6. 選択されたビジネス・インジケータを「選択済み」セクションに移動します。また、「追加」アイコンをクリックして、新しいビジネス・インジケータを作成できます。作成されたビジネス・インジケータは「選択済み」セクションに自動的に追加されます。

注意:

アクティビティが変更されると、デザイナで単一マーク・フロータのアクティビティ・アンカーが更新されます。

完了すると、「ビジネス・インジケータ」タブは図18-28 のようになります。

図18-28 「ビジネス・インジケータ」タブ

注意:

単一マークのメジャーの作成と選択のみができます。ディメンションは暗黙的に単一マークに追加され、単一マークではカウンタの作成と選択はできません。カウンタ・マークではカウンタの作成と選択のみができます。

18.4.4.3 コンポジット・レベル分析サンプリング・ポイントを構成する方法

分析サンプリング・ポイント(プロセスの起動/停止、アクティビティの起動/停止)をSOAコンポジット・アプリケーション・レベルで構成できます。コンポジット・レベル構成は、コンポジットですべてのBPELプロセスに適用されます。分析を特定BPELプロセス・レベルで構成する方法の詳細は、「プロセス・レベル分析サンプリング・ポイントを構成する方法」を参照してください。

コンポジット・レベル分析サンプリング・ポイントを構成するには:

1. 図18-29 に示すように、SOAコンポジット・エディタの上で、「分析の構成」アイコンをクリックします。

図18-29 SOAコンポジット・エディタの上にある「分析の構成」アイコン

図18-30 に示すように、「SOA分析メトリック」が表示されます。

図18-30 「SOA分析メトリック」ダイアログ

2. 適切なオプションを選択して「OK」をクリックします。表18-8に詳細を示します。

表18-8 「コンポジット分析設定」ダイアログ

要素

説明

すべてのアクティビティに対して生成

すべてのプロセス・イベントとアクティビティ・イベントに対して標準分析イベントを生成します。

ヒューマン・ワークフロー・アクティビティのみ

ヒューマン・タスク・イベントに対してのみ標準分析イベントを生成します。

BPELプロセスの開始および停止のみ

BPELプロセスの開始および停止に対して標準分析イベントを生成します。

生成しない

標準分析イベントは生成されません。

18.4.4.4 プロセス・レベル分析サンプリング・ポイントを構成する方法

分析サンプリング・ポイント(プロセスの起動/停止、アクティビティの起動/停止)を個々のBPELプロセス・レベルで構成できます。プロセス・レベル構成は、特定のBPELプロセスで標準分析イベントの生成にのみ適用されます。プロセスのユーザー定義測定イベントの生成に影響しません。有効にされている場合、ユーザー定義測定は必ず、測定イベントを生成します。

分析をSOAコンポジット・アプリケーション・レベルで構成する方法の詳細は、「コンポジット・レベル分析サンプリング・ポイントを構成する方法」を参照してください。

プロセス・レベル分析サンプリング・ポイントを構成するには:

1. 「分析ビューにアクセスする方法」の説明に従って、分析ビューでBPELプロセスにアクセスします。

2. 図18-31 に示すように、BPELプロセスの上で、「分析の構成」アイコンをクリックします。

図18-31 「分析の構成」アイコン

図18-32 に示すように、「BPELに対するコンポジット分析サンプリング・ポイント」ダイアログが表示されます。

図18-32 「BPELに対するコンポジット分析サンプリング・ポイント」ダイアログ

3. 適切なオプションを選択して「OK」をクリックします。表18-9に詳細を示します。

表18-9 「プロセス分析設定」ダイアログ

要素

説明

コンポジット・デフォルトから継承

「コンポジット・レベル分析サンプリング・ポイントを構成する方法」で説明されているコンポジット・レベル分析構成から分析設定を継承します。

ヒューマン・ワークフロー・アクティビティのみ

ヒューマン・タスク・アクティビティ・イベントに対して標準分析イベントを生成します。

Interactiveに対してのみ生成

対話型プロセス・イベントとアクティビティ・イベント(ヒューマン・タスク・イベントなど)に対してのみ標準分析イベントを生成します。

BPELプロセスの開始および停止のみ

BPELプロセスの開始および停止に対して標準分析イベントを生成します。

生成しない

標準分析イベントは生成されません。

プライマリ・プロセス

プロセスがSOAコンポジット・アプリケーション用プライマリ・プロセスの1つの場合に分析ランタイムに通知するように選択します。

18.4.5 ビジネス・インジケータをビジネス・インジケータ概要エディタで編集する方法

ビジネス・インジケータ概要エディタでSOAコンポジット・アプリケーション用ビジネス・インジケータの作成、編集および削除ができます。その際、これらのビジネス・インジケータが特定のBPELプロセスにバインドされたかどうかは関係ありません。このエディタではこれらのビジネス・インジケータのバインディングは、削除されていないかぎり変更されません。ビジネス・インジケータが削除されると、特定のBPELプロセスのバインディングもすべて削除されます。

ビジネス・インジケータ概要エディタは、ビジネス・インジケータの編集と削除を行うための唯一の方法です。「構造」ウィンドウまたはプロパティ・インスペクタからアクセスするカウンタ、ディメンションおよびメジャーの様々なダイアログからは、ビジネス・インジケータを編集または削除できません。BPELプロセスへのバインディングのみ編集できます。「構造」ウィンドウやプロパティ・インスペクタからのビジネス・インジケータのビューは実際、ビジネス・インジケータのバインド・ビューであり、すべてのビジネス・インジケータのビューでありません。バインドされていないビジネス・インジケータは、「構造」ウィンドウやプロパティ・インスペクタに表示されません。

ビジネス・インジケータ概要エディタにおける関連の変更は、「構造」ウィンドウやプロパティ・インスペクタに反映されます。「構造」ウィンドウやプロパティ・インスペクタにおける関連の変更は、ビジネス・インジケータ概要エディタに反映されます。

ビジネス・インジケータをビジネス・インジケータ概要エディタで編集するには:

1. 「アプリケーション」ウィンドウで、「ビジネス・インジケータ」をダブルクリックします。図18-33に詳細を示します。

図18-33 ビジネス・インジケータ概要エディタ

2. 必要に応じて、カウンタ、メジャーおよびディメンションのビジネス・インジケータの作成、編集および削除を行います。

注意:

属性と呼ばれるビジネス・インジケータの特殊タイプも作成できます。ただし、Oracle SOA Suite分析デザインタイムではBPELプロセスにバインディングする属性は、現時点ではサポートされていません。したがって、「構造」ウィンドウやプロパティ・インスペクタでBPELプロセスに属性を作成したりバインドできません。

18.4.6 BPEL分析のデプロイ

分析構成はSOAコンポジット・アプリケーションのデプロイメントに含まれています。コンポジットで定義されている分析がない場合、分析はデプロイされません。

SOA分析デプロイメントでは、次の手順が実行されます。

- 分析定義(コンポジット、プロセス、アクティビティおよびロール)データ・オブジェクトが移入されます。

- コンポジット固有の物理データ・オブジェクトと論理データ・オブジェクト(プロセスとアクティビティ)が作成されます。

データ移入がコンポジット・レベルまたはコンポーネント・レベル(BPELプロセス)で行われるかどうかに基づいて、分析デプロイメントは2つの手順に分かれています。

- コンポジット・レベルの分析デプロイメント
コンポジット定義データ・オブジェクトが移入され、コンポジット固有の物理データ・オブジェクトと論理データ・オブジェクトが作成されます(プロセスとアクティビティ)。コンポジットがデプロイされる際にコンポジット・レベルの分析デプロイメントが起動されます。このデプロイメント手順はコンポジットで一度実行されます。

- コンポーネント・レベルの分析デプロイメント
プロセス、アクティビティおよびロール定義データ・オブジェクトが移入されます。コンポーネントがデプロイされる際にコンポーネント・レベルの分析デプロイメントが起動されます。このデプロイメント手順はコンポジットの各コンポーネントで実行されます。

18.4.7 実行時におけるBPEL分析の表示

デプロイされた分析メタデータに基づいて、測定イベントがトリガーされます。開始や停止などのBPELプロセスおよびアクティビティ・イベントによって、測定イベントがトリガーされます。測定用に定義したビジネス・インジケータのすべての値をBPELプロセス・サービス・エンジンから測定イベントで取得し、合成してOracle BAMに公開できます。

BPELプロセスとアクティビティ・イベント自体は、分析サンプリング・コントロールに基づいて、Oracle BAMにも公開できます。BPELプロセスとアクティビティ・イベントでも、適用可能なビジネス・インテリジェンスの値が取得されます。

BPEL測定イベントは、SOA分析データ・オブジェクト(プロセスとアクティビティ)にBAMで公開されます。

BPELプロセス分析のOracle Business Activity Monitoring (BAM)との統合の詳細は、『Oracle BAMでのビジネス・アクティビティのモニタリング』の「Oracle SOA Suiteとの統合」および『Oracle SOA Suiteの理解』の「Oracle Business Activity Monitoringによるビジネス・インサイトの取得」を参照してください。

第III部 Oracle Mediatorサービス・コンポーネントの使用

この部では、Oracle Mediatorサービス・コンポーネントを構成する複数のコンポーネントについて説明します。

この部は、次の章で構成されています。

- Oracle Mediatorのスタート・ガイド

- Oracle Mediatorルーティング・ルールの作成

- Oracle Mediatorにおける複数パート・メッセージの使用

- Oracle Mediatorエラー処理の使用

- Oracle Mediatorにおける再順序付け

- Oracle Mediatorのメッセージ交換パターンの理解

19 Oracle Mediatorのスタート・ガイド

この章では、Oracle SOA Suiteアプリケーションにトランスフォーメーション、検証およびルーティング・ロジックを提供するOracle Mediatorについて説明します。また、この章では、Oracle JDeveloperでメディエータ・コンポーネントおよび関連するWSDLドキュメントを作成する方法についても説明します。

この章の内容は次のとおりです。

- Oracle Mediatorの概要

- メディエータの機能

- メディエータの作成

- 環境の概要

- メディエータのインタフェース定義の構成

- メディエータのインタフェースの定義

- WSDLファイルの生成

- 検証および優先度のプロパティの指定

- メディエータ・サービス・コンポーネントの変更

19.1 Oracle Mediatorの概要

Oracle SOA Suiteのサービス・コンポーネントであるOracle Mediatorは、様々なメッセージ交換パターン(同期、非同期、イベントの公開またはサブスクリプションなど)に加え、選択的なルーティング、トランスフォーメーションおよび検証の機能などの仲介機能を備えています。

メディエータは、Web Services Description Language (WSDL)ドキュメントをインタフェースとして使用してコンポジット・アプリケーション内の様々なコンポーネント間(ビジネス・プロセスやヒューマン・ワークフローなど)を仲介する軽量のフレームワークを提供します。また、様々なコンポーネントで公開される様々なインタフェース間での通信が容易になるようにデータを変換します。これらのコンポーネントは接続されて、SOAコンポジット・アプリケーションが構築されます。たとえば、メディエータでは、アプリケーションまたはサービスからテキスト・ファイルに格納されたデータを受け入れ、顧客リポジトリとして使用するデータベースの更新に適した書式に変換し、変換したデータをそのデータベースにルーティングおよび配信できます。

メディエータによって、イベントとサービス間の統合が容易になり、この統合によって、サービスの起動とイベントの組合せや調整が可能となります。メディエータ・サービス・コンポーネントを使用すると、ビジネス・イベントを処理したり、サービスの起動を受信できます。メディエータ・サービス・コンポーネントは、ルーティング・ルールの評価、変換の実行、検証を行い、別のサービスを起動したり、別のビジネス・イベントを発生させることができます。メディエータ・サービス・コンポーネントを使用すると、返されたレスポンス、コールバック、フォルトおよびタイムアウトを処理できます。

19.2 メディエータの機能

次の各項では、Oracle MediatorがOracle SOA Suiteアプリケーションに提供する主な機能について説明します。

19.2.1 コンテンツ・ベースおよびヘッダー・ベースのルーティング

メディエータでは、メッセージ・ペイロードまたはメッセージ・ヘッダーに基づいてルールを定義できます。メッセージ・ペイロードまたはメッセージ・ヘッダーから要素または属性を選択し、その要素または属性の値に基づいてアクションを指定できます。たとえば、メディエータで、新規顧客に関するデータが含まれているファイルをアプリケーションまたはサービスから受信したとします。顧客の住所に記載されている国に基づいて、その特定の国に関するデータが格納されているデータベースにデータをルーティングおよび配信できます。同様に、メッセージ・ヘッダーに基づいてメッセージをルーティングできます。

ヘッダーに基づいたルーティングの詳細は、「フィルタおよび割当てのためのヘッダー・アクセス方法」を参照してください。

19.2.2 同期および非同期の相互作用

メディエータでは、同期と非同期、両方のリクエストとレスポンスの相互作用がサポートされています。同期相互作用では、クライアントはサービスをリクエストした後、そのリクエストに対するレスポンスを待機します。非同期相互作用では、クライアントはサービスを起動しますが、そのレスポンスを待機しません。非同期相互作用に対してはタイムアウト時間を指定できます。このタイムアウト時間には、イベントの発生やプロセスの開始など、タイムアウト時間後に実行するアクションを指定できます。

メディエータでは、イベントベースの相互作用もサポートされています。イベントは、一方向(fire-and-forget)の非同期相互作用です。

同期および非同期の相互作用の詳細は、「レスポンス・メッセージの構成方法」および「Oracle Mediatorのメッセージ交換パターンの理解」を参照してください。

19.2.3 メッセージの順次およびパラレルのルーティング

メディエータでは、ルーティング・ルールをパラレルまたは順次のいずれかで実行するように指定できます。実行タイプは、メディエータ・エディタの「ルーティング・ルール」セクションから構成できます。

メッセージの順次およびパラレルのルーティングの詳細は、「順次実行またはパラレル実行の指定方法」を参照してください。

19.2.4 メッセージの再順序付け

メディエータの再シーケンサを使用すると、再シーケンサにより、関連がありながらも順序が正しくないメッセージは、使用されている再シーケンサのタイプと定義されているルールに基づいて適切な順序に並べ替えられます。受信メッセージがランダムな順番で着信した場合、再シーケンサは、メッセージを順次または時系列の情報に基づいて並べ替え、再順序付けの構成に基づいた正しい順序でメッセージをターゲット・サービスに送信します。

メッセージの再順序付けの詳細は、「Oracle Mediatorにおける再順序付け」を参照してください。

19.2.5 データ・トランスフォーメーション

メディエータでは、XMLスキーマ間のデータ・トランスフォーメーションを定義できます。この機能を使用することで、異なるスキーマを使用しているアプリケーション間でのデータ交換が可能になります。たとえば、カンマ区切りのファイルをデータベースと互換性のあるXMLスキーマに変換できます。

トランスフォーメーションの詳細は、「XSLTトランスフォーメーションの作成方法」を参照してください。

19.2.6 ペイロード検証

SchematronまたはXSDファイルを使用して受信メッセージ・ペイロードを検証するようにメディエータを構成できます。ユーザーは各インバウンド・メッセージ・パートに対してSchematronファイルを指定でき、メディエータはこれらのパートに対してSchematronファイル検証を実行します。

検証の詳細は、「検証および優先度のプロパティの指定」、「セマンティク検証の使用方法」およびhttp://www.schematron.com/を参照してください。

19.2.7 Javaコールアウト

メディエータでは、ルーティング・ルールにJavaコールアウトを追加できます。Javaコールアウトを使用すると、メディエータを介してフローするメッセージの操作に外部のJavaクラスを使用できます。

Javaコールアウトの詳細は、「Javaコールアウトの使用方法」を参照してください。

19.2.8 イベント処理

イベントは、ビジネス環境でアクティビティが発生すると送信されるメッセージです。メディエータでは、ビジネス・イベントのサブスクライブと発生の両方を実行できます。目的の状況が発生したときに生成されるビジネス・イベントをサブスクライブできます。たとえば、新規顧客の作成時に生成されるイベントをサブスクライブし、次にこのイベントを使用して、確認電子メールの送信などのビジネス・プロセスを開始できます。同様に、目的の状況が発生した場合は、ビジネス・イベントを生成することができます。たとえば、新規顧客プロファイルの作成後に顧客作成済イベントを生成できます。

イベント処理の詳細は、「ビジネス・イベントおよびイベント配信ネットワークの使用」を参照してください。

19.2.9 動的ルーティング

動的ルーティングは、プロセスの制御ロジックをプロセスの実行から分離します。制御ロジックは、プロセスが経由するパスを決定します。動的ルーティング・ルールは、メディエータ・エディタを使用して作成できます。

動的ルーティングの詳細は、「動的ルーティング・ルールの作成方法」を参照してください。

19.2.10 エラー処理

メディエータでは、手動によるエラー処理とフォルト・ポリシーに基づくエラー処理の両方がサポートされています。フォルト・ポリシーは複数の条件とアクションで構成され、条件によって、特定のエラー状態の場合に実行されるアクションを指定します。

エラー処理の詳細は、「Oracle Mediatorエラー処理の使用」を参照してください。

19.2.11 コール元へのメッセージの返信(エコー)

メディエータでは、他のターゲットにメッセージをルーティングすることなく、ソース・メッセージを最初のコール元にエコーして戻すことができます。メディエータでは、メッセージをコール元にエコーして戻す前に、トランスフォーメーション、検証、割当てまたは順序の操作を実行できます。

メディエータのエコー・サポートの詳細は、「メディエータ・サービスまたはイベントの指定方法」のサービスをエコーする手順を参照してください。

19.2.12 複数パート・メッセージ

メディエータでは、複数のパートで構成されたメッセージを処理できます。リモート・プロシージャ・コール(RPC) Webサービスの中には、SOAPメッセージに複数のパートが含まれているものがあります。

複数パート・メッセージのサポートに関する詳細は、「Oracle Mediatorにおける複数パート・メッセージの使用」を参照してください。

19.3 メディエータの作成

アプリケーション開発プロセスの現在の段階に応じて、複数の方法でメディエータを作成できます。コンポーネントを作成するには、次の項の該当する指示に従ってください。

19.3.1 メディエータの作成方法

開発サイクルの次のどの時点でも、Oracle JDeveloperでSOAコンポジット・アプリケーション内にメディエータを作成できます。

- コンポジット・アプリケーションの作成時

- 既存のコンポジット・アプリケーションの変更時

- プロジェクトの作成時

- 既存のプロジェクトの変更時

メディエータの作成時には、「メディエータの作成」ダイアログが表示され、メディエータの名前を決定してインタフェースのテンプレートを選択できます。

19.3.1.1 メディエータを使用するコンポジット・アプリケーションを作成する手順:

1. SOAアプリケーションの作成ウィザードを使用して、SOAアプリケーションおよびプロジェクトを作成し、名前を指定します。

2. 図19-1 に示すように、「SOA設定の構成」ページが表示されたら、「コンポジット・テンプレート」リストから「メディエータを使用するコンポジット」を選択します。

図19-1 「SOAプロジェクトの作成」ウィザードの「メディエータを使用するコンポジット」の選択

3. 「終了」をクリックします。
「メディエータの作成」ダイアログが表示されます。

4. 「メディエータのインタフェース定義の構成」の説明に従って、メディエータのインタフェースを構成します。

5. 「Oracle Mediatorルーティング・ルールの作成」の説明に従って、メディエータのルーティング・ルールを定義します。

19.3.1.2 既存のコンポジット・アプリケーション内にメディエータを作成する手順:

1. SOAコンポジット・エディタで、メディエータを追加するコンポジット・アプリケーションを開きます。

2. 「コンポーネント」ウィンドウ(図19-2 を参照)からエディタの「コンポーネント」セクションにメディエータをドラッグ・アンド・ドロップします。
または、エディタの「コンポーネント」セクションの空白領域を右クリックします。表示されるコンテキスト・メニューから「挿入」→「メディエータ」の順に選択します。

ヒント:

「コンポーネント」ウィンドウはSOAコンポジット・エディタの右側にあります。

図19-2 メディエータ・サービス・コンポーネントが表示された「コンポーネント」ウィンドウ

「メディエータの作成」ダイアログが表示されます。

3. 「メディエータのインタフェース定義の構成」の説明に従って、メディエータのインタフェースを構成します。

4. 「Oracle Mediatorルーティング・ルールの作成」の説明に従って、メディエータのルーティング・ルールを定義します。

19.3.1.3 メディエータを使用する新規プロジェクトを作成する手順:

1. 「アプリケーション」ウィンドウで右クリックしてから、「新規」を選択します。
新規ギャラリ・ウィザードが表示されます。

2. 「SOA層」カテゴリに新規SOAプロジェクトを作成し、名前を付けます。

3. 図19-3 に示すように、「新規ギャラリ」ダイアログの「SOA設定の構成」ページで、「コンポジット・テンプレート」リストから「メディエータを使用するコンポジット」を選択します。

図19-3 表示される「メディエータを使用するコンポジット」テンプレートを使用した「SOAプロジェクトの作成」ウィザード

4. 「終了」をクリックします。
「メディエータの作成」ダイアログが表示されます。

5. 「メディエータのインタフェース定義の構成」の説明に従って、メディエータのインタフェースを構成します。

19.3.1.4 既存のプロジェクト内にメディエータを作成する手順:

1. 「アプリケーション」ウィンドウで、メディエータを追加するプロジェクトを選択します。

2. ナビゲータ・ペインを右クリックし、「新規」を選択します。

3. 図19-4 に示すように、「カテゴリ」で「サービス・コンポーネント」を選択し、次に「項目」リストから「メディエータ」を選択します。

図19-4 メディエータ・サービス・コンポーネントが表示された「新規ギャラリ」ダイアログ

4. 「OK」をクリックします。
「メディエータの作成」ダイアログが表示されます。

5. 「メディエータのインタフェース定義の構成」の説明に従って、メディエータのインタフェースを構成します。

6. 「Oracle Mediatorルーティング・ルールの作成」の説明に従って、メディエータのルーティング・ルールを定義します。

19.4 メディエータ・エディタ環境の概要

Oracle JDeveloperのSOAコンポジット・アプリケーション内にメディエータ・サービス・コンポーネントを作成した後、そのメディエータ・サービス・コンポーネントはメディエータ・エディタを使用して構成できます。メディエータ・エディタを表示するには、で、メディエータ・サービス・コンポーネントをダブルクリックします。の詳細は、「SOAコンポジット・アプリケーションの開発のスタート・ガイド」を参照してください。

図19-5 には、メディエータ・エディタが「アプリケーション」ウィンドウ、「構造」および「メッセージ」の各ウィンドウとともに表示されています。

注意:

メディエータのグローバリゼーションを完全にサポートするために、Unicodeデータベースのデータベース文字セットには、AL32UTF8を使用することをお薦めします。

図19-5 メディエータ・エディタ・ウィンドウ

図19-5 のビューの各セクションで、特定の設計タスクやデプロイメント・タスクを実行できます。このビューのセクションは次のとおりです。

- 「アプリケーション」ウィンドウ
図19-5 の左上のセクションにある「アプリケーション」ウィンドウは、メディエータのmplanファイルを示しています。このファイルは、メディエータを作成したプロジェクトの「SOAコンテンツ」フォルダの下に表示されます。「アプリケーション」ウィンドウおよびコンポジット・ファイルの詳細は、表2-4 を参照してください。

- メディエータ・エディタ
図19-5 の中央に表示されているメディエータ・エディタでは、メディエータのビジュアル・ビューが提供されます。このビューは、次のいずれかの処理を実行すると表示されます。

- で、アイコンをダブルクリックした場合。

- 「アプリケーション」ウィンドウでメディエータの.mplanファイルをダブルクリックした場合。

- 「ソース」ビュー
「ソース」ビューに、メディエータのソース・コードが表示されます。メディエータ・エディタの下部にある「ソース」をクリックすると、ソース・コードが表示されます。「ソース」ビューのコードは即時に更新され、メディエータ内のすべての変更が反映されます。

次の例は、メディエータのソース・コードのサンプルを示しています。

<?xml version = '1.0' encoding = 'UTF-8'?>
<!--Generated by Oracle SCA Modeler version 1.0 at [4/16/07 10:05 PM].-->
<Mediator name="CustomerDataRouter" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/sca/1.0/mediator"/>

- 「履歴」ウィンドウ
「履歴」ウィンドウには、リビジョン履歴や、ファイルの読取り専用バージョンと編集可能バージョンを並べた比較など、メディエータ・ファイルの履歴情報を表示できます。図19-5 の「設計」ウィンドウ下部にある「履歴」をクリックすると、「履歴」ウィンドウが表示されます。図19-6 に、メディエータ・ファイルの「履歴」ビューを示します。

図19-6 「履歴」ウィンドウ

19.5 メディエータのインタフェース定義の構成

新規のメディエータを作成するときに、メディエータ・プロジェクトの基本的な一連のデフォルト・ファイルを生成するインタフェース・テンプレートを指定できます。これらのファイルは、メディエータを設計および構成できるフレームワークを提供します。次のインタフェース・オプションを使用して、メディエータを作成できます。

- インタフェース定義を使用しないメディエータ
空のメディエータを作成し、WSDLファイルは作成しません。この方法を使用すると、目的の順番でSOAコンポーネントを柔軟に作成できます。

インタフェース定義を使用せずにメディエータを作成した後、そのコンポーネントを起動するサービスまたはイベントを作成する必要があります。サービスまたは別のコンポーネントからの出力インタフェースをメディエータ入力にドラッグ・アンド・ドロップすることで、インタフェースを暗黙的に定義することもできます。

- WSDLファイルで定義されているインタフェースを使用したメディエータ
これは、メディエータのインタフェース(ポート・タイプ、操作、サービス、スキーマなど)が記述されているWSDLファイルのインタフェース定義に基づきます。WSDLファイルは、既存のものを使用するか、スキーマ・ファイルから生成できます。

- 一方向インタフェースを使用したメディエータ
クライアントはサービスにメッセージを送信するが、サービスからのリプライは不要の一方向相互作用のインタフェースを定義します。

- 同期インタフェースを使用したメディエータ
同期リクエスト/レスポンス相互作用のインタフェースを作成します。同期相互作用では、クライアントはサービスにリクエストを送信し、すぐにレスポンスを受信します。クライアントはレスポンスが届くまで次へ進みません。

- 非同期インタフェースを使用したメディエータ
非同期リクエスト/レスポンス相互作用のインタフェースを作成します。非同期相互作用では、クライアントはサービスにリクエストを送信しますが、リプライをブロックおよび待機しません。

- イベントをサブスクライブするメディエータ
目的の状況が発生したときに生成されるビジネス・イベントをサブスクライブするメディエータを作成します。ビジネス・イベントは、ビジネス環境における発生の結果として送信されるメッセージ・データで構成されています。ビジネス・イベントの詳細は、「ビジネス・イベントおよびイベント配信ネットワークの使用」を参照してください。

イベントをサブスクライブするには、イベント定義(EDL)ファイルでイベントを定義する必要があります。

19.5.1 メディエータのインタフェース定義の構成方法

メディエータのインタフェース定義の構成は、「メディエータの作成」ダイアログで行います。

メディエータのインタフェース定義を構成する手順は、次のとおりです。

1. 「メディエータの作成」に記載されているいずれかの方法で、メディエータを作成します。
「メディエータの作成」ダイアログが表示されます。

2. 「名前」フィールドに、メディエータ・サービス・コンポーネントの名前を入力します。

3. 「テンプレート」リストで、次のいずれかを選択します。それぞれの詳細は、この項の最初の説明を参照してください。

- インタフェースを後で定義

- WSDLからのインタフェース定義

- 一方向インタフェース

- 同期インタフェース

- 非同期インタフェース

- イベントのサブスクライブ

図19-7 および図19-8 は、インタフェース・タイプが異なる場合に「メディエータの作成」ダイアログのプロパティがどのように変わるかを示しています。

図19-7 「メディエータの作成」ダイアログの「同期インタフェース」テンプレートの選択

図19-8 「メディエータの作成」ダイアログの「WSDLからのインタフェース定義」テンプレートの選択

4. 「イベントのサブスクライブ」以外のインタフェース・タイプの場合は、適切なプロパティを構成します。各タイプで表示されるプロパティの詳細は、この手順の後の表19-1 を参照してください。

5. 「イベントのサブスクライブ」を選択した場合は、次の手順を実行します。

a. 「メディエータの作成」ダイアログで「追加」をクリックします。

図19-9 「メディエータの作成」ダイアログの「イベントのサブスクライブ」テンプレートの選択

「イベント・チューザ」ダイアログが表示されます。

b. 「イベント定義」フィールドの右側にある「検索」をクリックします。

「SOAリソース・ブラウザ」ダイアログが表示されます。

c. イベント定義ファイル(.edl)を選択し「OK」をクリックします。
「イベント」フィールドに、選択した.edlファイルに記述されているイベントが移入されます。.edlファイルの作成方法の詳細は、「ビジネス・イベントおよびイベント配信ネットワークの使用」を参照してください。

d. 図19-10 に示すように、「イベント」フィールドで1つ以上のイベントを選択し、「OK」をクリックします。

図19-10 「イベント・チューザ」ダイアログ

e. イベントと一貫性がある配信のレベルを選択します。
唯一: イベント配信にはグローバル(JTA)トランザクションが使用されます。イベント・コールが失敗した場合、トランザクションはロールバックされ、コールは構成可能な回数だけ再試行されます。

保証付き: 配信を保証するためにローカル・トランザクションが使用されます。失敗時の再試行はありません。

即時: イベントはコール元と同じスレッドおよび同じトランザクション上で配信されます。

f. 「パブリッシャとして実行」フィールドで、イベント・パブリッシャのセキュリティ下でイベント・サブスクリプションを実行するかどうかを選択します。
デフォルトでは、イベント・サブスクリプションはイベント・パブリッシャのセキュリティ下で実行します。

g. イベントをフィルタリングするには、選択したイベントの「フィルタ」列をダブルクリックするか、またはイベントを選択して「フィルタ」アイコン(最初のアイコン)をクリックします。
「式ビルダー」ダイアログが表示されます。

h. 「式」フィールドでXPath式を入力し、「OK」をクリックします。
図19-11 に、「式ビルダー」ダイアログのサンプルを示します。

図19-11 ビジネス・イベント・フィルタ

「メディエータの作成」ダイアログの「フィルタ」列に、作成した式が表示されます。

i. 「OK」をクリックします。

6. 「メディエータの作成」ダイアログで「OK」をクリックします。

7. インタフェースなしのメディエータを作成するように選択した場合は、「メディエータのインタフェースの定義方法」の説明に従って、後でインタフェースを作成する必要があります。

次の表に、インタフェースを定義するために構成可能なプロパティをリストして説明します。選択したインタフェース・タイプによって使用可能なプロパティは異なるため、リストされているすべてのプロパティがすべてのインタフェース・タイプに適用されるわけではありません。

表19-1 メディエータのインタフェースのプロパティ

プロパティ

説明

SOAPバインディングを持つコンポジット・サービスの作成

このオプションを選択すると、インタフェースが生成されたときに自動的にメディエータに接続されるSOAPバインディングを使用した公開されたサービスが作成されます。

WSDL URL

WSDLファイルからインタフェースを作成する場合に、使用するWSDLファイルの場所を入力します。次のいずれかを行います:

- 既存のWSDLファイルを使用するには、ファイルの名前を入力するか、「既存のWSDLを検索します。」をクリックしてファイルを参照します。

- 新規のWSDLファイルを作成するには、「スキーマからWSDLを生成します。」をクリックします。

これらのオプションに関する詳細は、「WSDLファイルの生成」を参照してください。

ポート・タイプ

リストからポート・タイプ名を選択します。使用可能なポート・タイプは、「WSDL URL」フィールドに指定したWSDLファイルから解析されます。

コールバック・ポート・タイプ

非同期通信のレスポンス・メッセージが送信されるポート・タイプ名を選択します。使用可能なポート・タイプは、「WSDL URL」フィールドに指定したWSDLファイルから解析されます。

入力

入力メッセージ用のスキーマ要素を入力します。フィールドの右側にある「検索」をクリックして、要素を選択します。デフォルトでは、入力メッセージ用にsingleStringスキーマ要素が選択されています。

サンプル・スキーマについては、この表の下のスキーマをご覧ください。

出力

出力メッセージ用のスキーマ要素を入力します。フィールドの右側にある「検索」をクリックして、要素を選択します。デフォルトでは、入力メッセージ用にsingleStringスキーマ要素が選択されています。

メディエータで処理する入力文書の形式は、XSDスキーマを使用して指定できます。次にスキーマのサンプルを示します。

<xsd:schema attributeFormDefault="qualified"
elementFormDefault="qualified"
targetNamespace="http://samples.otn.com/helloworld"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://samples.otn.com/helloworld">
<include namespace="http://samples.otn.com/helloworld"
schemaLocation="helloworld.xsd" />
<xsd:element name="name1" type="xsd:string" />
<xsd:element name="result1" type="xsd:string"/>
</xsd:schema>

19.5.2 メディエータ作成時の処理内容

メディエータ・ファイルは「アプリケーション」ウィンドウで指定されたアプリケーションおよびプロジェクトの下に生成され、新しいメディエータは設計ビューのメディエータ・エディタに表示されます。インタフェース定義を使用したメディエータを作成し、WSDLファイルが存在しなかった場合は、新しいWSDLファイルがメディエータと同じ名前で一緒に生成されます。指定したWSDLファイルがプロジェクト・ファイルと異なるディレクトリに格納されている場合は、ファイルおよび関連するスキーマ・ファイルがメディエータ・プロジェクトにコピーされます。

19.5.2.1 インタフェース定義を使用しない

このメディエータはWSDLファイル、ポート・タイプまたは操作に関連付けられていません。「メディエータのインタフェースの定義」の説明に従って、これらを個別に定義する必要があります。図19-12 は、インタフェース定義を使用せずに作成したメディエータがメディエータ・エディタ内でどのように表示されるかを示しています。

図19-12 メディエータ・エディタでインタフェース定義を使用しないメディエータ

19.5.2.2 WSDLベースのインタフェースを使用

このメディエータの外観およびソース・コードは、WSDLファイルの名前、およびWSDLファイルで定義されているポート・タイプおよび操作によって異なります。図19-13 は、WSDLファイルから作成されたメディエータのサンプルを示しています。

図19-13 メディエータ・エディタ内のWSDLからのメディエータ

19.5.2.3 一方向インタフェース定義を使用

図19-14 は、一方向インタフェースを使用して作成したメディエータがメディエータ・エディタ内でどのように表示されるかを示しています。「execute」操作の左側にある矢印は、一方向操作を表しています。

図19-14 メディエータ・エディタ内の一方向インタフェース

19.5.2.4 同期インタフェース定義を使用

同期相互作用ではレスポンスがリクエストと同じポートに送信されるため、ポートは1つのみ定義されます。図19-15 は、同期インタフェースを使用して作成したメディエータがメディエータ・エディタ内でどのように表示されるかを示しています。図19-15 の「execute」操作の左側にある矢印は、同期操作を表しています。

図19-15 メディエータ・エディタ内の同期メディエータ

19.5.2.5 非同期インタフェース定義を使用

図19-16 は、非同期インタフェースを使用して作成したメディエータがメディエータ・エディタ内でどのように表示されるかを示しています。「ポート・タイプ」フィールドには、リクエスト・メッセージが送信されるポートが表示されます。「コールバック・ポート・タイプ」フィールドには、レスポンスが送信されるポートが表示されます。図19-16 の「execute」操作の左側にある矢印は、非同期操作を表しています。

図19-16 メディエータ・エディタ内の非同期メディエータ

19.5.2.6 イベント・サブスクリプションを使用

SOAコンポジット・エディタでメディエータを表示すると、図19-17 に示すように、メディエータの左側にあるアイコンにより、そのメディエータがイベント・サブスクリプション用に構成されていることが示されます。

図19-17 「イベントのサブスクライブ」テンプレートを使用して作成されたメディエータ

メディエータをダブルクリックすると、図19-18 に示すように、メディエータ・エディタが表示されます。

図19-18 メディエータ・エディタ内のイベント・サブスクリプション・メディエータ

19.6 メディエータのインタフェースの定義

インタフェース定義を使用せずにメディエータを作成した後、イベントのサブスクライブまたはサービスの定義によって、インタフェースを定義する必要があります。サービスの定義は、次の2つの方法で行えます。

- SOAコンポジット・エディタのワイヤを通じてメディエータをサービスに接続します。

- メディエータ・エディタの「サービスの定義」オプションまたは「イベント・サブスクリプションの追加」オプションを使用します。

19.6.1 メディエータのインタフェースの定義方法

次の手順は、既存のメディエータのインタフェースを定義するために、イベントをサブスクライブして定義する方法、コンポジット内にワイヤを作成するサービスを定義して定義する方法、メディエータ・エディタを使用してサービスを定義して定義する方法を示しています。

19.6.1.1 イベントをサブスクライブする手順:

イベントをサブスクライブするには、イベント定義(EDL)ファイルでイベントを定義する必要があります。

1. メディエータ・エディタで編集するメディエータを開きます。

2. 「ルーティング・ルール」セクションで、「イベント・サブスクリプションの追加」をクリックします。
「サブスクライブ済イベント」ダイアログが表示されます。

3. 「追加」をクリックします。
「イベント・チューザ」ダイアログが表示されます。

4. 既存のEDLファイルを使用するには、「メディエータのインタフェース定義の構成」の手順5.b以降の手順に従います。

注意:

または、新しいEDLファイルを作成できます。新しいEDLファイルを作成するには、「EDLファイルの作成」をクリックします。表示される「イベント定義の作成」ダイアログにイベントの詳細を入力します。

5. 「OK」をクリックします。

19.6.1.2 ワイヤを使用してメディエータのサービスを定義する手順:

- で、メディエータからサービスにワイヤをドラッグします。
ワイヤの詳細、およびサービス・コンポーネントをサービスに接続する方法については、「サービスとサービス・コンポーネントの接続方法」を参照してください。

注意:

定義済サービス・インタフェースを使用して、メディエータを別のインタフェースに接続することもできます。ただし、メディエータをサービスに接続するには、そのメディエータとサービスのインタフェースが一致している必要があります。

ワイヤを使用してサービスを定義した場合、メディエータのサービスは、ワイヤのソースのWSDLファイルを使用して自動的に定義されます。たとえば、図19-19 に示すReadFileサービスをCustomerDataRouterメディエータに接続すると、そのCustomerDataRouterメディエータでは自動的にReadFileサービスのサービス定義が継承されます。

図19-19 メディエータからサービスへの接続

2つのメディエータ・サービス・コンポーネントを接続したときに無限ループが発生するケースに関する必知事項は、「ワイヤの追加と削除に関する必知事項」を参照してください。

19.6.1.3 メディエータ・エディタでメディエータのサービスを定義する手順:

1. メディエータ・エディタで編集するメディエータを表示します。

2. 「WSDL URL」フィールドの右側にある「サービスの定義」をクリックします。
図19-20 に示すように、「サービスの定義」ダイアログが表示されます。

図19-20 「サービスの定義」ダイアログ

3. 次のいずれかを行います:

- 既存のWSDLファイルを使用するには、「WSDL URL」フィールドの右側にある「既存のWSDLを検索します。」をクリックします。

- WSDLファイルを作成するには、「WSDL URL」フィールドの右側にある「スキーマからWSDLを生成します。」をクリックします。

WSDLファイルの生成方法は、「WSDLファイルの生成」を参照してください。

4. 「ポート・タイプ」リストから、ポートを選択します。

5. 「コールバック・ポート・タイプ」リストから、非同期相互作用のレスポンス・メッセージのポートを選択します。

6. 「OK」をクリックします。

19.7 WSDLファイルの生成

メッセージに対するWSDLファイルは、XMLスキーマ定義(XSD)ファイルを使用して生成できます。メディエータを使用する場合は、次のいずれかのタイミングでWSDLファイルを生成できます。

- メディエータの作成時に「メディエータの作成」ダイアログの「WSDLからのインタフェース定義」テンプレートを選択した場合は、「WSDL URL」フィールドの横にある「スキーマからWSDLを生成します。」を選択すると、「WSDLの作成」ダイアログが開きます。

- インタフェース定義を使用しないメディエータで、メディエータ・エディタの「WSDL URL」フィールドの横にある「サービスの定義」をクリックした場合は、「WSDL URL」フィールドの横にある「スキーマからWSDLを生成します。」を選択すると、「WSDLの作成」ダイアログが開きます。

「WSDLの作成」ダイアログでファイル名、ディレクトリ、ネームスペースなどの標準フィールドが移入され、選択するインタフェース・タイプに応じてダイアログが変更されます。入力メッセージに対して、同一または異なるスキーマ・ファイルを指定できます。

19.7.1 WSDLファイルの生成方法

WSDLファイルの構成方法は、WSDLファイルで定義されているインタフェースのタイプによって異なります。一方向インタフェース、同期インタフェースまたは非同期インタフェースを定義できます。

19.7.1.1 XSDファイルから一方向インタフェース用のWSDLファイルを生成する手順:

メディエータを作成する場合や、メディエータのサービスを定義する場合は、「WSDLの作成」ダイアログが表示された後に、これらの手順を実行します。

1. 「WSDLの作成」ダイアログで、デフォルト値を受け入れるか、WSDLファイルに次の情報を入力します。

表19-2 WSDLのプロパティ

プロパティ

説明

ファイル名

WSDLファイルの一意の名前。

ディレクトリ

WSDLファイルを格納するディレクトリ。デフォルトでは、プロジェクト・フォルダの下にあるSOA/WSDLsフォルダに格納されています。

ネームスペース

WSDLファイルのネームスペース・アドレス。例: http://oracle.com/esb/namespaces/Mediator。デフォルトのネームスペースは、JDeveloperのアプリケーション名、プロジェクト名およびメディエータ名に基づきます。

指定するネームスペースは、WSDLファイルでtnsネームスペースとして定義されます。

ポート・タイプ

使用する操作が含まれるWSDLファイルのポート・タイプの名前。

操作

実行するアクションの名前。例: executeQuery。

注意:

操作名やポート・タイプで、空白や特殊文字は使用できません。アルファベットおよび数字のみがサポートされますが、最初の文字に数字は使用できません。

2. 「インタフェース・タイプ」フィールドで、「一方向インタフェース」を選択します。
図19-21 に示すように、「入力」フィールドが表示されます。

図19-21 一方向インタフェースの「WSDLの作成」ダイアログ

3. 「入力」フィールドの右上の「新規メッセージ・パートを追加します。」をクリックします。

図19-22 に示すように、「メッセージ・パートの追加」ダイアログが表示されます。

図19-22 「メッセージ・パートの追加」ダイアログ

4. 「パート名」フィールドに、メッセージ・パートの名前を入力します。

5. 「URL」フィールドの右側にある「スキーマ・ファイルを参照」アイコンをクリックして、URLを参照します。
図19-23 に示すように、「タイプ・チューザ」ダイアログが表示され、これにはスキーマ・ファイル(XSDファイル)のリストが含まれます。

図19-23「タイプ・チューザ」ダイアログ

6. 「タイプ・エクスプローラ」ツリーを開き、検索して使用するスキーマ要素を選択します。
使用するスキーマが、作業しているプロジェクトにない場合、「スキーマ・ファイルのインポート」またはダイアログの右上隅にある「WSDLのインポート」アイコンを使用して、スキーマXSDファイルまたはWSDLファイルをプロジェクトにインポートできます。

ファイルを指定すると、Oracle JDeveloperによってファイルが解析されて定義済のスキーマ要素が決定され、選択するリストに表示されます。

7. XSDファイルのルート要素を選択し、「OK」をクリックします。
「メッセージ・パートの追加」ダイアログが再度表示され、「URL」と「スキーマ要素」フィールドに「タイプ・チューザ」ダイアログからのデータが移入されます。XSDの単純型を選択した場合、これらのフィールドは、「単純型」フィールドに置換されます。

8. 「メッセージ・パートの追加」ダイアログで、「OK」をクリックします。

「WSDLの作成」ダイアログの「入力」フィールドに、入力情報が表示されます。

9. 必要に応じて、前述の手順を繰り返して、追加のメッセージ・パートを定義します。

10. 「OK」をクリックします。

注意:

パートナ・リンク・タイプは通常BPELで使用されるため、メディエータに「partnerlinkType拡張機能の生成」を選択する必要はありません

19.7.1.2 XSDファイルから同期インタフェース用のWSDLファイルを生成する手順:

メディエータを作成する場合や、メディエータのサービスを定義する場合は、「WSDLの作成」ダイアログが表示された後に、これらの手順を実行します。

1. 「WSDLの作成」ダイアログで、表19-2 にリストされているプロパティの情報を入力します。

2. 「インタフェース・タイプ」フィールドで、「同期インタフェース」を選択します。
図19-24 に示すように、「入力」、「出力」および「フォルト」フィールドが表示されます。

図19-24 同期インタフェースの「WSDLの作成」ダイアログ

3. 前述の手順の手順3から8を繰り返します。

4. 同じ手順を繰り返して、「出力」フィールドおよび「フォルト」フィールドのメッセージ・パートを定義します。
出力はレスポンス・メッセージを表し、同期トランザクションに必要です。「フォルト」はオプションです。

5. 「OK」をクリックします。

注意:

パートナ・リンク・タイプは通常BPELで使用されるため、メディエータに「partnerlinkType拡張機能の生成」を選択する必要はありません

19.7.1.3 XSDファイルから非同期インタフェース用のWSDLファイルを生成する手順:

メディエータを作成する場合や、メディエータのサービスを定義する場合は、「WSDLの作成」ダイアログが表示された後に、これらの手順を実行します。

1. 「WSDLの作成」ダイアログで、表19-2 にリストされているプロパティの情報を入力します。

2. 「インタフェース・タイプ」フィールドで、「非同期インタフェース」を選択します。
図19-25 に示すように、「入力」フィールドおよび「コールバック」セクションが表示されます。

図19-25 「非同期インタフェース」の「WSDLの作成」ダイアログ

3. 前述の手順の手順3から8を繰り返します。

4. 同じ手順を繰り返して、「コールバック」セクションの入力メッセージ・パートを定義します。

注意:

コールバック入力はレスポンス・メッセージを表し、非同期トランザクションに必要です。

5. 「コールバック」セクションで、レスポンス・メッセージに関する次の情報を指定します。

- ポート・タイプ: 使用する操作が含まれるWSDLファイルのポート・タイプの名前。

- 操作: 実行するアクションの名前。例: executeResponse。

注意:

操作名やポート・タイプで、空白や特殊文字は使用できません。アルファベットおよび数字のみがサポートされますが、最初の文字に数字は使用できません。これらのフィールドの両方が必要です。

6. 「OK」をクリックします。

注意:

パートナ・リンク・タイプは通常BPELで使用されるため、メディエータに「partnerlinkType拡張機能の生成」を選択する必要はありません

19.8 検証および優先度のプロパティの指定

メディエータを作成した後は、そのコンポーネントに指定されている操作またはイベント・サブスクリプションのプロパティを構成できます。メディエータ・エディタで、インバウンド・メッセージのスキーマを検証するかどうかを指定し、操作またはイベント・サブスクリプションの優先度を指定できます。

インバウンド・メッセージのスキーマを検証するには、メディエータ・エディタの「ルーティング・ルール」セクションで、操作またはイベント・サブスクリプションの「有効な構文(XSD)の検証」チェック・ボックスを選択します。メディエータ・エンジンは、関連するXMLスキーマに対してXMLインバウンド・ペイロードの構文構造を検証します。不適切な要素名や場所などの構文エラーによって、フォルトが発生し、ルーティング・ルールが処理されません。

コンポーネントの優先度を指定するには、メディエータ・エディタの「ルーティング・ルール」セクションの「優先度」フィールドで0から9の間の値を選択します。これにより、すべてのサービス・コンポーネントにおいてメッセージが取得される順序が決まります。このプロパティは、パラレルのルーティング・ルールの場合のみ有効で、順次ルーティング・ルールの場合は無効です。優先度の詳細は、「パラレルのルーティング・ルールの基本原則」を参照してください。

19.9 メディエータ・サービス・コンポーネントの変更

メディエータの操作またはイベント・サブスクリプションは、メディエータ・エディタを使用して変更できます。

19.9.1 メディエータの操作の変更方法

操作を追加または削除することで、のWSDLファイルを変更できます。WSDLファイルの変更後、「WSDLのリフレッシュ」ダイアログを使用して変更を同期化します。

操作を変更する手順は、次のとおりです。

1. メディエータ・エディタで、「WSDL URL」フィールドの右側にある「WSDLからの操作のリフレッシュ」アイコンをクリックします。

「WSDLのリフレッシュ」ダイアログが表示されます。WSDLファイルが変更された場合、「WSDLのリフレッシュ」ダイアログには削除または追加される操作がすべて一覧表示されます。「リフレッシュにより、次のメディエータ操作が削除されます」フィールドには、WSDLファイルから削除された操作がすべて一覧表示されます。「リフレッシュにより、次のメディエータ操作が追加されます」フィールドに、WSDLファイルに追加された新規操作がすべて一覧表示されます。図19-26 に、「WSDLのリフレッシュ」ダイアログを示します。

図19-26 「WSDLのリフレッシュ」ダイアログ

2. 別のWSDLファイルを指定するには、「WSDL URL」フィールドの右側にある「既存のWSDLを検索します。」をクリックして既存のWSDLファイルを使用するか、または「スキーマからWSDLを生成します。」をクリックしてWSDLファイルを作成します。

「WSDLのリフレッシュ」ダイアログは、指定のWSDLファイルで定義された操作に基づいて更新されます。

3. 「OK」をクリックします。

4. 「ファイル」メニューから「すべて保存」を選択します。

19.9.2 メディエータのイベント・サブスクリプションの変更方法

メディエータ・エディタの「イベント・サブスクリプションの管理」オプションを使用すると、新規イベントのサブスクライブ、既存イベント・サブスクリプションの変更およびサブスクライブ済イベントからのサブスクライブ解除などを実行できます。

イベント・サブスクリプションを変更する手順は、次のとおりです。

1. メディエータ・エディタで、「イベント・サブスクリプション」の右側にある「イベント・サブスクリプションの管理」アイコンをクリックします。

図19-27 に示すように、「サブスクライブ済イベント」ダイアログが表示されます。

図19-27 「サブスクライブ済イベント」ダイアログ

2. 次の機能のいずれも実行できます。

- 新規イベントをサブスクライブします。

- イベントからサブスクライブ解除します。

- イベントのフィルタ基準を変更または指定します。

- イベント・サブスクリプションの「一貫性」または「ロールとして実行」プロパティを変更します。
イベントの「一貫性」、「ロールとして実行」および「フィルタ」フィールドの詳細は、「メディエータのインタフェース定義の構成方法」を参照してください。

3. 「OK」をクリックします。

4. 「ファイル」メニューから「すべて保存」を選択します。

20 Oracle Mediatorルーティング・ルールの作成

この章では、Oracle Mediatorルーティング・ルール、およびメディエータ・サービス・コンポーネントに対してルーティング・ルールを指定する方法について説明します。ルーティング・ルールには、トランスフォーメーション、フィルタリング、検証、マッピングおよびルーティング・ロジックが含まれます。

この章の内容は次のとおりです。

- ルーティング・ルールの概要

- 再順序付けルール

- ルーティング・ルールの定義

- メディエータ・ルーティングのユースケース

次の章で、特定のシナリオのためのルーティング・ルールの定義に関する追加情報を説明しています。

- Oracle Mediatorにおける複数パート・メッセージの使用

- Oracle Mediatorエラー処理の使用

- Oracle Mediatorにおける再順序付け

20.1 ルーティング・ルールの概要

ルーティング・ルールは、必要な仲介を実行するために定義する仲介ロジックまたは実行ロジックです。メディエータを使用すると、サービス・コンシューマとサービス・プロバイダの間でデータをルーティングできます。データはサービス間をフローするため、トランスフォーメーションが必要です。ルーティングとトランスフォーメーションの2つのタスクは、メディエータの中核となる処理内容です。ルーティング・ルールにより、メディエータで処理されたメッセージを次の宛先にどのように送信するかを指定できます。ルーティング・ルールは、メディエータによるメッセージの送信先、メッセージの送信方法、およびターゲット・サービスへの送信前にメッセージ構造に加える必要がある変更の内容を指定します。

ルーティング・ルールは、サービス操作またはイベント・サブスクリプションのいずれかでトリガーできます。サービス操作は、同期、非同期または一方向のいずれかです。ルーティング・ルールには、次の2つのタイプがあります。

- 静的ルーティング・ルール
起動コンテキストによって変更されることのない一貫して適用される静的ルールです。

- 動的ルーティング・ルール
Oracle Rules Dictionaryへのルーティング・ロジックの外部化を可能にする動的ルールです。Oracle Rules Dictionaryは、ルーティング・ロジックの動的変更を可能にします。

ルーティング・ルールの作成の詳細は、「静的ルーティング・ルールの作成方法」および「動的ルーティング・ルールの作成方法」を参照してください。標準のメッセージ交換パターンの詳細とそれらのメディエータでの処理方法は、「Oracle Mediatorのメッセージ交換パターンの理解」を参照してください。

20.1.1 静的ルーティング・ルール

起動コンテキストによって変更されることのない静的ルーティング・ルールです。この場合のルーティングは、エコー、別のサービスへのルーティングまたはイベントの公開のいずれかです。

静的ルールを定義するときは、次のタイプの情報を指定できます。

- ターゲット・サービス
メディエータにより、指定するターゲット・サービスにメッセージが送信されます。このサービスは、WSDLインタフェースまたはJavaインタフェースとして定義できます。ターゲット・サービスの起動の詳細は、「メディエータ・サービスまたはイベントの指定方法」を参照してください。

- 実行タイプ
メディエータは、ルーティング・ルールを順次(同じスレッド内で実行)またはパラレル(異なるスレッドで実行)のいずれかで実行します。実行タイプの指定方法の詳細は、「順次実行またはパラレル実行の指定方法」を参照してください。

注意:

同期サービス起動の場合、ルーティング・ルールは必ず順次にする必要があります。

- リプライ、コールバックおよびフォルト・ハンドラ
同期リプライ、コールバックおよびフォルト・メッセージをメディエータで処理する方法を定義できます。ハンドラの詳細は、「レスポンス・メッセージの構成方法」、「フォルトの処理方法」および「静的ルーティング・ルール・コンポーネント」を参照してください。

20.1.1.1 静的ルールのタイプ

次のタイプのメディエータの静的ルールを定義できます。

- フィルタ式
メッセージのコンテンツ(ペイロードまたはヘッダー)に適用するフィルタ式を定義できます。フィルタを定義する場合、コンテンツはサービスの起動前に分析されます。たとえば、メッセージに顧客IDが含まれている場合、またはその顧客IDの値が特定のパターンと一致する場合のみサービスを起動することを指定する、フィルタ式を適用できます。フィルタ式の指定方法の詳細は、「メッセージをフィルタリングする式の指定方法」を参照してください。

- トランスフォーメーション
メディエータでは、メッセージをサービスに転送する前にメッセージ・データを変換できます。データのマッピングまたは値の割当てにより、ターゲット・ペイロードで値を設定するようトランスフォーメーションを定義できます。

XSLTマッパーを使用すると、XMLスキーマ間でメッセージを変換するために、メッセージ本文全体に適用するトランスフォーメーションを定義できます。値の割当て機能では個々のフィールドを処理します。このダイアログを使用すると、メッセージ(ペイロード、ヘッダーなど)、定数または様々なシステム・プロパティ(データ・パスに存在するアダプタのプロパティなど)から値を割り当てることができます。トランスフォーメーションの定義の詳細は、「XSLTトランスフォーメーションの作成方法」および「値の割当て方法」を参照してください。

- 式にあるヘッダー変数へのアクセス
メディエータは、現在のルーティング・ルール操作用の式の作成に使用したSOAPヘッダーを検出できます。ヘッダー・アクセスの詳細は、「フィルタおよび割当てのためのヘッダー・アクセス方法」および「フィルタおよび割当てのためのプロパティ・アクセスに使用する式の手動作成」を参照してください。

- Schematronベースの検証
インバウンド・メッセージの様々な部分を検証するためにメディエータが使用する必要のあるSchematronファイルを指定できます。Schematronをベースにした検証の実行方法の詳細は、「セマンティク検証の使用方法」を参照してください。

- Javaコールアウト
メディエータでは、ルーティング・ルールにJavaコールアウトを追加できます。Javaコールアウトを使用すると、メディエータを介してフローするメッセージの操作に外部のJavaクラスを使用できます。Javaコールアウトの使用方法の詳細は、「Javaコールアウトの使用方法」を参照してください。

- ユーザー定義拡張関数
XSLTマッパーで使用可能な独自の関数セットです。ユーザー定義拡張関数の使用方法の詳細は、「ユーザー定義拡張関数を追加する手順:」を参照してください。

20.1.1.2 静的ルーティング・ルール・コンポーネント

静的ルーティング・ルールでは、次のコンポーネントを定義します。

- リクエスト・ハンドラ: メディエータでの受信リクエストの処理方法を定義します。

- リプライ・ハンドラ: コールしたサービスからの同期レスポンスをメディエータが処理する方法を定義します。

- フォルト・ハンドラ: コールしたサービスからの名前付きフォルトまたは宣言済フォルトをメディエータが処理する方法を定義します。

- コールバック・ハンドラ: コールしたサービスからの非同期レスポンスとコールバックをメディエータが処理する方法を定義します。

- コールバックのタイムアウト・ハンドラ: 特定の非同期リクエストに対するタイムアウト処理を実行するまでに、メディエータが、非同期レスポンスとコールバックを待機する時間を定義します。

- イベントの公開およびサービスの起動: ハンドラの構成に応じて、他のサービスのコールまたはイベントの公開を実行します。

20.1.2 動的ルーティング・ルール

動的ルーティング・ルールは、Oracle Rules DictionaryまたはDomain Value Map (DVM)へのルーティング・ロジックの外部化を可能にし、これらは、ルーティング・ルール内のルーティング・ロジックの動的変更を可能にします。動的ルーティングにより、メッセージの内容に基づいて、実行時にメッセージをメディエータから複数のターゲット・サービスに動的にルーティングできます。

動的ルーティング・ルールについては、「動的ルーティング・ルールの作成方法」で詳しく説明します。

20.1.3 順次実行およびパラレル実行

ルーティング・ルールは、順次またはパラレルで実行できます。この項では、両方の実行タイプの基本原則について説明します。操作またはイベントに順次およびパラレルの両方のルーティング・ルールがある場合は、最初に順次ルーティング・ルールが評価されてアクションが実行され、次にパラレルのルーティングがパラレル実行のためにキューに入れられます。

注意:

リクエスト/レスポンス・インタフェースを使用するメディエータ・サービス・コンポーネントにパラレルのルーティング・ルールのみが設定されている場合、そのメディエータ・サービス・コンポーネントはコール元にレスポンスを返信しません。このタイプのメディエータ・サービス・コンポーネントは作成できますが、メディエータ・サービス・コンポーネントのコール元が、実行時にレスポンスを受信することはありません。

20.1.3.1 順次ルーティング・ルールの基本原則

メディエータは、次の原則に基づいて順次ルーティング・ルールを処理します。

- メディエータは、ルーティングを評価し、結果の処理を順次実行します。順次ルーティングは、コール元と同じスレッドとトランザクションで評価されます。

- メディエータは常に、受信メッセージを処理しているスレッドを介して伝播されたグローバル・トランザクションにメディエータ自体を登録します。たとえば、インバウンドJCAアダプタがメディエータを起動すると、そのメディエータは、JCAアダプタが開始したトランザクションにメディエータ自体を登録します。

- メディエータは、順次ルーティング・ルールの実行中に、ターゲット・コンポーネントと同じスレッドを介してトランザクションを伝播します。

- 外部エンティティによって伝播されたトランザクションを、メディエータがコミットまたはロールバックすることはありません。

- メディエータがトランザクションを管理するのは、スレッド起動メディエータにアクティブなトランザクションが存在していない場合のみです。たとえば、メディエータがインバウンドSOAPサービスから起動された場合、そのメディエータはトランザクションを開始し、成功および失敗に応じてトランザクションをコミットまたはロールバックします。

20.1.3.2 パラレルのルーティング・ルールの基本原則

メディエータは、次の原則に基づいてルーティング・ルールをパラレルで処理します。

- メディエータは、ルーティングをキューに入れ、別々のスレッドでパラレルに評価します。
各メディエータ・サービス・コンポーネントのメッセージは、重み付けラウンド・ロビン方式で取得され、すべてのメディエータ・サービス・コンポーネントで確実にパラレル処理サイクルが受け入れられます。これは、1つ以上のメディエータ・サービス・コンポーネントで、他のコンポーネントよりも多くのメッセージが生成される場合でも同様です。使用される重み付けは、メディエータ・サービス・コンポーネントの設計時に設定されたメッセージ優先度です。メッセージ優先度の高いコンポーネントほど、多数のパラレル処理サイクルが割り当てられます。

メディエータ・サービス・コンポーネントの優先度を指定するには、メディエータ・エディタで「優先度」フィールドを設定します。優先度は0から9までの範囲で、9が最高優先度です。デフォルトの優先度は4です。

注意:

「優先度」プロパティの適用対象は、パラレルのルーティング・ルールのみです。

- メディエータは、各パラレル・ルールを処理するための新規トランザクションを開始します。開始されたトランザクションは、メディエータのパラレル・メッセージ・デハイドレーション・ストアへのエンキューで終了します。
たとえば、メディエータ・サービス・コンポーネントにパラレルのルーティング・ルールが1つある場合は、1つのメッセージがメディエータのパラレル・メッセージ・デハイドレーション・ストアにエンキューされます。次に、ストアに対するパラレル・メッセージ・ディスパッチャがトランザクションを開始し、データベース・ストアからメッセージを読み取り、このルーティング・ルールのターゲット・コンポーネントまたはサービスを起動します。リスナー・スレッドによって開始されるトランザクションは、完全に新規のトランザクションであり、ターゲット・コンポーネントに伝播されます。

注意:

メッセージのデハイドレーションでは、パラレル・ルーティング・ルール対象の受信メッセージがデータベースに格納されるため、ワーカー・スレッドはそれらのメッセージを後で処理できます。

- メディエータはトランザクションのイニシエータであるため、これらのトランザクションをコミットまたはロールバックします。

20.1.3.3 パラレル・ルーティングにおけるスレッド割当ての精細制御

専用ワーク・マネージャを指定して、メディエータ・コンポーネントのパラレル・ルーティングとエラー処理メッセージを処理できます。Oracle WebLogic Server管理コンソールを使用して、ワーク・マネージャを構成できます。ワーク・マネージャを構成する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のワーク・マネージャのプロパティの表示と構成に関する項を参照してください。

NameWorkManagerMappingsメディエータ・サービス・エンジン・プロパティを使用して、メディエータ・コンポーネントとその関連ワーク・マネージャをOracle Enterprise Manager Fusion Middleware Controlで指定します。メディエータ・ランタイム・プロパティを構成する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle Mediatorサービス・エンジン・プロパティの構成に関する項を参照してください。

NameWorkManagerMappingsプロパティには、次のキーが含まれています。

- parallelRoutingWorkManagerName: パラレル・ルーティング用に構成されるワーク・マネージャの名前です。指定されないと、デフォルトのSOAワーク・マネージャが使用されます。

- fullyQualifiedComponentDistinguishedName: メディエータ・コンポーネントの完全修飾名です。使用される形式は、PartitionName/CompositeName!Revision/ComponentNameです。たとえば、soaInfra/MyProject!1.0/Mediator1です。

20.2 再順序付けルール

メディエータには再シーケンサが含まれており、これは、関連がありながらも順序が正しくないメッセージを、使用されている再シーケンサのタイプと定義されているルールに基づいて適切な順序に並べ替えます。受信メッセージがランダムな順番で着信した場合、再シーケンサは、メッセージを順次または時系列の情報に基づいて並べ替え、再順序付けの構成に基づいた正しい順序でメッセージをターゲット・サービスに送信します。

メッセージの再順序付けの詳細は、「Oracle Mediatorにおける再順序付け」を参照してください。

20.3 ルーティング・ルールの定義

ルーティング・ルールは、インタフェースが定義されているメディエータにのみ定義できます。インタフェースの定義方法の詳細は、「メディエータのインタフェースの定義方法」を参照してください。

20.3.1 「ルーティング・ルール」セクションへのアクセス方法

メディエータ・エディタの「ルーティング・ルール」セクションで、ルーティング・ルールを定義します。

図20-1 に、メディエータ・エディタの「ルーティング・ルール」セクションを示します。

図20-1 メディエータ・エディタ - 「ルーティング・ルール」セクション

図20-2 では、「ルーティング・ルール」セクションのアイコンをリストして説明します。

図20-2 「ルーティング・ルール」セクションのアイコン

次のいずれかの方法を使用して、メディエータ・エディタの「ルーティング・ルール」セクションにアクセスできます。

20.3.1.1 SOAコンポジット・エディタから:

1. ルーティング・ルールを指定するメディエータを示すアイコンをダブルクリックします。

2. 「ルーティング・ルール」セクションが表示されない場合は、「ルーティング・ルール」セクションの横のプラス(+)アイコンをクリックします。

20.3.1.2 「アプリケーション」ウィンドウから:

1. 「アプリケーション」ウィンドウで、SOAプロジェクトを開き、次に「SOAコンテンツ」フォルダを開きます。

2. 「SOAコンテンツ」フォルダで、ルーティング・ルールを指定するメディエータ・ファイルの名前をダブルクリックします。
メディエータ・ファイルには、MPLAN拡張子が付きます。

3. 「ルーティング・ルール」セクションが表示されない場合は、「ルーティング・ルール」セクションの横のプラス(+)アイコンをクリックします。

20.3.2 静的ルーティング・ルールの作成方法

この後の各項では、メディエータの静的ルーティング・ルールの定義(サービスおよびイベントの指定、ハンドラ、トランスフォーメーション、式、フィルタなどの定義)に関する情報および手順について説明します。

20.3.2.1 メディエータ・サービスまたはイベントの指定方法

メディエータ・コンポーネントを作成した後は、そのメディエータをインバウンド・サービス操作またはイベント・サブスクリプション、およびアウトバウンド・ターゲットに関連付けます。ターゲットは、アウトバウンド・サービス操作またはイベントの公開です。ターゲットはメディエータがメッセージを送信する次のサービスまたはイベントを指定し、起動するサービス操作も指定します。サービスまたはイベントをターゲット・タイプとして指定できます。

ソース・メッセージは、トランスフォーメーション、検証、割当てまたは順序操作の実行後に、初期のコール元にエコーして戻すこともできます。エコーは、メディエータ・コンポーネントに同期または非同期のインタフェースがある場合にのみ指定できます。エコーが同期、非同期のいずれで行われるかは、コール元のWSDLファイルによって決まります。エコー・オプションは、インバウンド・サービス操作に対してのみ使用可能で、イベント・サブスクリプションには使用できません。

エコー・オプションの目的は、メディエータのすべての機能をコール可能なサービスとして公開することによって、他のサービスへのルーティングの必要性をなくすことです。たとえば、メディエータをコールしてトランスフォーメーション、検証または割当てを実行した後、別の場所にルーティングすることなくアプリケーションにメディエータをエコーして戻すことができます。

1つのインバウンド操作またはイベントに複数のルーティングを指定できます。各ルーティングは、1つのターゲット・サービス起動またはイベントにマップされます。したがって、特定のターゲット・サービスに対して複数のサービス起動を指定したり、複数イベントを発生させるには、各ターゲットに1つのルーティング・ルールを指定する必要があります。たとえば、メッセージ・ペイロードに基づいて、サービスに定義された次の操作から、ある操作を起動できます。

- insert

- update

- updateid

- delete

このアクションを実行するため、各操作に1つずつ、4つのルーティング・ルールを作成する必要があります。その後、各ルールにフィルタ式を指定する場合は、図20-3 に示すように、メッセージ・ペイロードに基づいて各メッセージ・インスタンスに適用するターゲットおよび操作を指定できます。

図20-3 インバウンド操作に対する複数のルーティング

20.3.2.1.1 サービスを起動する手順:

この手順を実行するには、WSDLドキュメントまたはJavaインタフェースでターゲット・サービスを定義する必要があります。

1. 「ルーティング・ルール」セクションで、ルーティング・ルールを定義中の操作の横にある「追加」をクリックし、次に「静的ルーティング・ルール」を選択します。
図20-4 に示すように、「ターゲット・タイプ」ダイアログが表示されます。

図20-4 「ターゲット・タイプ」ダイアログ

2. 「サービス」をクリックします。
図20-5 に示すように、「ターゲット・サービス」ダイアログが表示されます。

図20-5 「ターゲット・サービス」ダイアログ

3. 「ターゲット・サービス」ダイアログで、サービスが提供する操作に移動し、選択します。

注意:

WSDLファイルまたはJavaインタフェースで定義されているサービスを選択できます。図20-5 に示すように、サービスは複数の操作で構成できます。

4. 「OK」をクリックします。

5. Javaインタフェースで定義されたターゲット・サービスを選択した場合、「必要なインタフェース」ダイアログが表示されます。「はい」をクリックして必要なWSDLファイルを作成し、次に確認ダイアログで「OK」をクリックします。
ルーティング・ルールを定義できる新規の「静的ルーティング」セクションが表示されます。

6. この章の後続の項の説明に従って、ルーティング・ルールを構成します。

20.3.2.1.2 イベントをトリガーする手順:

1. 「ルーティング・ルール」セクションで、ルーティング・ルールを定義中の操作の横にある「追加」をクリックし、次に「静的ルーティング・ルール」を選択します。
図20-4 に示すように、「ターゲット・タイプ」ダイアログが表示されます。

2. 「イベント」をクリックします。
「イベント・チューザ」ダイアログが表示されます。

3. 「イベント定義」フィールドの右側にある「検索」をクリックします。
「SOAリソース・ブラウザ」ダイアログが表示されます。

4. イベント(.edl)・ファイルを選択し、「OK」をクリックします。
図20-6 に示すように、選択したファイルに定義されているイベントが「イベント」フィールドに移入されます。

図20-6 「イベント・チューザ」ダイアログ

注意:

既存のイベント定義ファイルを参照するかわりに、「新規イベント定義(edl)ファイルを作成します。」をクリックし、「イベント定義ファイルの作成」ダイアログのフィールドを完了して、新規ファイルを作成できます。

5. イベントを選択します。

6. 「OK」をクリックします。
ルーティング・ルールを定義できる新規の「静的ルーティング」セクションが表示されます。

7. この章の後続の項の説明に従って、ルーティング・ルールを構成します。

20.3.2.1.3 サービスをエコーする手順:

1. 「ルーティング・ルール」セクションで、ルーティング・ルールを定義中の操作の横にある「追加」をクリックし、次に「静的ルーティング・ルール」を選択します。

図20-7 に示すように、「ターゲット・タイプ」ダイアログが表示されます。

図20-7 「ターゲット・タイプ」ダイアログ

2. 「エコー」をクリックします。

注意:

インタフェースが同期または非同期の場合は、「エコー」ボタンのみが「ターゲット・タイプ」ダイアログに表示されます。

図20-8 に、同期エコーのルーティング・ルールを示します。非同期エコーの場合は、戻りのアイコンが点線になります。

図20-8 エコー操作をサポートするメディエータのサンプル

20.3.2.2 サービスのエコーに関する必知事項

エコー・オプションには次の制限があります。

- サービスのエコーは、メディエータのインタフェースが、次のタイプのWSDLファイルの場合のみサポートされます。

- リクエスト/リプライ

- リクエスト/リプライ/フォルト

- リクエスト/コールバック

注意:

エコー・オプションは、メディエータのインタフェースがリクエスト/リプライ/フォルト/コールバックのWSDLファイル、または一方向WSDLファイルの場合には使用できません。

- エコー・オプションは、リクエスト/リプライおよびリクエスト/リプライ/フォルトのような同期操作で使用できます。

注意:

同期操作のメディエータでは、パラレルのルーティング・ルールはサポートされないため、エコー・オプションを同期操作で使用できるのは、ルーティング・ルールが順次実行の場合のみです。

- 条件フィルタ付きの同期操作の場合は、フィルタ条件をfalseに設定していると、エコー・オプションではレスポンスがコール元に返されません。かわりに、nullレスポンスが返されます。

- エコー・オプションを非同期操作で使用できるのは、メディエータのインタフェースにコールバック操作が指定されている場合のみです。この場合、エコーは別のスレッドで実行されます。

注意:

非同期のエコー・オプションを使用できるのは、ルーティング・ルールがパラレル実行の場合のみです。エコー・オプションを使用する場合、非同期操作のメディエータでは、順次実行のルーティング・ルールはサポートされません。

20.3.2.3 順次実行またはパラレル実行の指定方法

ルーティング・ルールは、パラレルまたは順次のいずれかで実行できます。ルーティング・ルールの実行タイプを指定するには、「ルーティング・ルール」セクションで、「順次」または「パラレル」実行タイプを選択します。

20.3.2.4 レスポンス・メッセージの構成方法

メディエータ・ルーティング・ルールでは、レスポンス・メッセージを同期および非同期の相互作用内で処理する方法を指定できます。同期相互作用の場合は、レスポンスとフォルト・メッセージのトランスフォーメーションと割当てを指定できます。レスポンスとフォルト・メッセージを別のサービスまたはイベントに転送するか、または初期のコール元にレスポンスおよびフォルトを受信する用意がある場合は、それらを初期のコール元に戻すことができます。

非同期相互作用の場合は、トランスフォーメーションと割当て、およびレスポンスを受信するまでのタイムアウト時間を指定できます。タイムアウト時間は、秒、時、日、月または年で指定できます。タイムアウト時間のデフォルト値は無限です。コールバック・レスポンスが指定したタイムアウト時間内に返されない場合、タイムアウトしたレスポンスは別のサービス、別のイベントに転送されるか、初期のコール元に戻されます。

メディエータのレスポンスを双方向サービスにルーティングすることはできません。レスポンスを双方向サービスにルーティングする場合は、最初のメディエータと双方向サービスの間に一方向のメディエータを使用する必要があります。レスポンスを最初に一方向のメディエータに転送し、その一方向のメディエータが双方向サービスをコールする必要があります。

注意:

- 0(ゼロ)のタイムアウト時間指定はサポートされていません。

- コールバックを受信し、そのコールバックの処理に失敗した場合は、タイムアウト・ハンドラに指定されているアクションを処理するために、タイムアウト・ハンドラがデフォルトで起動されます。

- 通常、コール元は、100ミリ秒待機した後でコールバックを受信します。ただし、順次ルーティング・ルールと同期インタフェース・サービスへの接続を使用するブリッジ・メディエータがある場合は、ルーティング・ルールがすべて順次であるプログラムのフローが複雑となるため、コール元でのコールバックの受信準備にさらに時間がかかる場合があります。この問題は、ブリッジ・メディエータのルーティング・ルールをパラレルに変更することで回避できます。

非同期処理のタイムアウト時間を指定する手順は、次のとおりです。

メディエータ・エディタの「ルーティング・ルール」セクションで、次の手順を実行します。

1. 「コールバック」セクションで、「タイムアウト期間」フィールド側の「<<ターゲット操作>>」フィールドの横にある「ターゲット・サービス操作を参照します。」アイコンをクリックします。

「ターゲット・タイプ」ダイアログが表示されます。

2. 「サービス」、「イベント」または「初期コール元」を選択します。

「サービス」または「イベント」を選択した場合は、選択した内容によって「ターゲット・サービス」または「イベント・チューザ」が表示されます。

3. サービスまたはイベントを選択します。

4. 「OK」をクリックします

5. 「タイムアウト期間」フィールドで、タイムアウト期間の単位数を入力し、ドロップダウン・リストから時間の単位を選択します。

タイムアウトしたレスポンスが、指定したサービスまたはイベントに転送されます。

注意:

ルーティング・ルールの数が多く、ルーティング・ルールの実行に要する時間がトランザクション・タイムアウトを超える場合は、トランザクション・タイムアウトの値を、すべてのルーティング・ルールの実行に要する時間より長い時間に設定する必要があります。

20.3.2.5 早すぎるコールバックの処理方法

コールバック・メッセージは、トランザクションの開始が完了する前に着信する場合があります。この場合、メディエータでの相関は失敗します。早すぎるコールバックの問題がある場合は、oracle.tip.mediator.callback.correlationWaitDuratino_in_secondsプロパティを使用して、コールバックを再試行する前にコールバック・スレッドが待機する期間(秒単位)を設定できます。

このプロパティは、composite.xmlファイル内のMediatorコンポーネントを定義するcomponent要素で定義します。次に示す例では、再試行前の待機時間は15秒です。

<component name="Mediator1">
<implementation.mediator src="Mediator1.mplan"/>
<property name="oracle.tip.mediator.callback.correlationWaitDuration_in_
seconds">15</property>
</component>

20.3.2.6 複数コールバックの処理方法

1つのメディエータで複数のコールバックを処理することはできません。複数のコールバックを受信するメディエータが含まれているコンポジット・アプリケーションがある場合、そのコンポジット・アプリケーションの動作は不明です。たとえば、図20-9 に示したシナリオでは、AsyncMediatorがAsyncEchoMediator1およびAsyncEchoMediator2からのコールバック・レスポンスをFileInMediatorに転送します。このようなフローでは、AsyncMediatorは、AsyncEchoMediator1とAsyncEchoMediator2の両方からのコールバックを返すか、またはいずれか一方のコールバックを返す可能性があります。正確な動作はランダムであり、予測できません。

図20-9 複数のコールバックを処理するメディエータのサンプル

20.3.2.7 フォルトの処理方法

ターゲット・サービスの操作に1つ以上のフォルトがある新規ルーティング・ルールを作成する場合でも、メディエータ・エディタには、単一フォルトのルーティング・セクションが表示されます。ソース・メディエータ・サービス・コンポーネントが1つ以上のフォルトをサポートしている場合、デフォルトでは、フォルトはコール元に戻されます。ただし、ルーティングするソース・フォルト名およびターゲット・フォルト名を指定できます。サービス・ブラウザを使用して、フォルトを別のターゲットにルーティングすることもできます。

20.3.2.7.1 追加のフォルト・ルーティングを定義する手順:

メディエータ・エディタの「ルーティング・ルール」セクションで、次の手順を実行します。

1. 図20-10 に示すように、「フォルト」セクションで、「別のフォルト・ルーティングを追加します。」ボタンをクリックします。

図20-10 2番目のフォルトの追加

別のフォルト・セクションがルーティング・ルール・ボックスに表示されます。

2. 新規フォルトに対して、ターゲット・サービス、トランスフォーメーションおよび値の割当てを構成します。
図20-11 に、ファイル・アダプタ・サービスにルーティングされている2番目のフォルトを示します。

図20-11 ルーティング・ルールに追加された2番目のフォルト

注意:

異なるトランスフォーメーションを使用して、複数のターゲットに同じフォルトをルーティングできます。

20.3.2.7.2 フォルト・ルーティング・セクションを削除する手順:

メディエータ・エディタの「ルーティング・ルール」セクションで、次の手順を実行します。

- 図20-12 に示すように、ターゲット・サービス・フィールドをクリックして削除するフォルト・ルーティングをハイライト表示し、「選択したフォルト・ルーティングを削除します。」をクリックします。

図20-12 フォルト・ルーティングの削除

20.3.2.8 メッセージをフィルタリングする式の指定方法

フィルタ式ルーティング・ルールを使用すると、ペイロードに基づいてメッセージをフィルタリングできます。特定のメッセージ・インスタンスに対してフィルタ式がtrueと評価されると、そのメッセージはルーティング・ルールに指定されているターゲット・サービスまたはイベントに送信されます。

たとえば、アメリカとカナダのような異なる2国にいる顧客にデータをルーティングする場合、アメリカの顧客には携帯の製品系列に関する通知のみを、カナダの顧客には固定電話の製品系列の通知のみを送信するとします。このルーティングのためには、メッセージをターゲット顧客に送信するコンポーネントと操作の各組合せについてルーティング・ルールを定義する必要があります。さらに、アメリカまたはカナダの顧客にメッセージを送信するルーティング・ルールには、フィルタ式を指定します。

フィルタ式のメッセージ・プロパティまたはメッセージ・ヘッダーを定義することもできます。

フィルタ式のメッセージ・プロパティ

次に、フィルタ式のメッセージ・プロパティの例を2つ示します。

$in.property.custom.Priority = '1'

$in.property.tracking.ecid = '2'

フィルタ式のメッセージ・ヘッダー

次に、フィルタ式のメッセージ・ヘッダーの2つ例を示します。

$in.header.wsse_Security/wsse:Security/Priority = '234'

$in.header.wsse_Security/wsse:Security/Priority = '234'

このフィルタ式のメッセージ・ヘッダーが機能するには、.mplanファイルのルート要素に次の例に示す属性を追加する必要があります。

wsse = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd"

20.3.2.8.1 メッセージをフィルタリングする式を指定する手順:

式ビルダーを使用すると、フィルタ式をグラフィカルに作成できます。「式ビルダー」ダイアログには、フィルタ式の設計を支援するコンポーネントやコントロールが含まれています。

1. 「ルーティング・ルール」セクションの「フィルタ式」フィールドの右側にある「式ビルダーの起動」アイコンをクリックします。
図20-13 に示すように、「式ビルダー」ダイアログが表示されます。

図20-13 「式ビルダー」ダイアログ

2. 「式」フィールドに値を追加するには、「変数」フィールドまたは「関数」パレットで、必要な値をダブルクリックします。変数要素、関数および手動で入力したテキストの組合せを使用して、このウィンドウで、特定のルーティング・ルールに対してメッセージ・ペイロードをフィルタリングする式を作成できます。
次の表で、「式ビルダー」ダイアログの各フィールドについて説明します。

表20-1 「式ビルダー」フィールド

フィールド

説明

式

このフィールドには、メッセージのフィルタに使用される実際の式が含まれます。フィルタ式は手動、または「変数」フィールドおよび「関数」パレットを使用して入力できます。

このフィールドの右上部に表示されている各アイコンを使用すると、最後に行った編集の取消し、最後に行った編集の再実行、または「式」フィールド全体の消去を実行できます。

変数

このフィールドには、メディエータ・コンポーネントに対して定義されたメッセージが含まれます。Oracle JDeveloperはメディエータのWSDLファイルを解析し、メッセージ定義を「変数」フィールドに表示します。入力メッセージは$in変数に格納され、$in.propertiesを使用して入力メッセージのプロパティにアクセスすることができます。

入力メッセージが複数のパートで構成されている場合は、$in.partnameを使用して、入力メッセージのパートにアクセスします。

「関数」パレット

このリストには、式に挿入できる関数のリストが表示されます。関数を選択すると、その関数が「式」フィールドに追加されたときにどのように表示されるかを示すプレビューが「コンテンツのプレビュー」フィールドに表示され、その関数の説明が「説明」フィールドに表示されます。

コンテンツのプレビュー

このフィールドには、「変数」フィールドまたは「関数」パレットで選択した値が「式」フィールドに挿入されたときの表示状態で示されます。

説明

このフィールドには、「変数」フィールドまたは「関数」パレットで選択した値の説明が表示されます。

20.3.2.8.2 メッセージ・ペイロードのフィルタ式を指定する手順:

1. 「ルーティング・ルール」セクションの「フィルタ式」フィールドの右側にある「式ビルダーの起動」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

2. 「変数」フィールドで、メッセージ定義を開き、式の基になるメッセージ要素を選択します。
たとえば、図20-14 で選択されたCustomerId要素が表示されます。

図20-14 「式ビルダー」ダイアログ – 変数要素の選択

3. 「式に挿入」をクリックします。
図20-15 に示すように、式が「式」フィールドに追加されます。

図20-15 「式ビルダー」ダイアログ – 変数要素の挿入

4. 「関数」リストから、メッセージ・ペイロードに適用する関数を選択します。たとえば、equalsを選択します。
関数は、「関数」リストの下矢印をクリックすると表示されるカテゴリ別にグループ化されます。たとえば、下矢印をクリックして「Logical Functions」を選択すると、図20-15 に示すようにリストが表示されます。

5. 「式に挿入」をクリックします。
選択した関数のXPath式が「式」フィールドに挿入されます。

6. 式を完成します。
この例では、図20-16 に示すように、顧客IDがtrueと評価されるには1001である必要があります。

図20-16 サンプルの「式ビルダー」ダイアログ – 値の入力後

7. エラーが検出された場合、式は手動で編集するか、式の編集アイコンを使用できます。図20-17 には、これらのアイコンがまとめられています。

図20-17 式の編集アイコン

8. 「OK」をクリックします。
式が「ルーティング・ルール」セクションに追加されます。

フィルタ式の変更または削除は、「フィルタ式の追加」アイコンをダブルクリックし、「式ビルダー」の「式」フィールドで実行します。

20.3.2.9 ネイティブXSDフォーマットとXMLフォーマットとの間における変換方法

メディエータにより、インバウンド・データでは、ネイティブ・フォーマット・データをXMLデータに変換でき、アウトバウンド変換では、XMLデータをネイティブ・フォーマット・データに変換できます。そのため、たとえば、インバウンド変換を使用して、入力カンマ区切りネイティブ・データ・ファイルをXMLデータ・ファイルに変換できます。アウトバウンド変換を使用して、XMLデータをネイティブ・データ・フォーマットにターゲット・サービスで変換できます。

メディエータには次の変換機能があります。

- インバウンド変換: インバウンド・データをネイティブ・データ・フォーマットからXMLに変換します。インバウンド変換は操作レベルで構成されます。変換されたデータは変換と割当ての操作で利用できます。

- アウトバウンド変換: アウトバウンド・データをXMLからネイティブ・データ・フォーマットに変換します。アウトバウンド変換を各ルーティング・ルールで構成できます。ネイティブ・データはターゲット・サービスにルーティングされます。

- 変換とルーティングのみ: インバウンド・データをネイティブ・データ・フォーマットからXMLに変換し、ターゲット・サービスにルーティングします。アウトバウンドWSDLファイルがターゲット・サービスに対して作成されます。この機能は、一方向(レスポンスなし)操作を行うメディエータのみにサポートされています。

20.3.2.10 インバウンド変換を使用する方法

この項ではインバウンド変換を使用する方法について説明します。図20-18 は、インバウンドWebサービスに接続したメディエータ(Mediator1)を示します。メディエータでネイティブ文字列をインバウンドWebサービスから受信し、インバウンド変換を使用してネイティブ文字列をXMLに変換します。

図20-18 インバウンド・データを受信するメディエータ

インバウンド・データをネイティブXSDからXMLフォーマットに変換するには:

1. メディエータ(Mediator1)を右クリックし、「編集」を選択します。

2. 「操作」セクションの下で、「ネイティブからの変換」フィールドの右側にあるアイコンをクリックします。図20-19 に、Mediator1の「操作」セクションを示します。

図20-19 「ネイティブからの変換」オプション

3. 表示される「翻訳の追加」ダイアログで、「入力」フィールドの右側にあるアイコンをクリックします。「式ビルダー」ダイアログが表示されます。

4. 入力文字列を「変数」ツリーでダブルクリックします。string()関数で「式」フィールドに表示される入力文字列をラップ(キャスト)します。図20-20 に、完了した入力文字列がある「式ビルダー」ダイアログを示します。「OK」をクリックします。

図20-20 「式ビルダー」で完了した入力文字列

5. 「NXSDスキーマ」フィールドの右側で、「検索」アイコンを選択し、スキーマを選択するために「タイプ・チューザ」ダイアログを起動します。スキーマが存在しない場合、2番目のアイコンをクリックすると、スキーマを作成できます。

6. スキーマを選択して「OK」をクリックします。「要素」フィールドは、選択スキーマから移入されます。「出力」フィールドは、メディエータにより作成される中間出力変数で移入されます。この変数は、translateFromNative.out.some_name形式である必要があります。

図20-21 は、完了した「翻訳の追加」ダイアログを示しています。

図20-21 「Add Translation」ダイアログ

7. 「OK」をクリックします。「ネイティブからの変換」フィールドが移入されます。

20.3.2.11 アウトバウンド変換を使用する方法

この項ではアウトバウンド変換を使用する方法について説明します。図20-22 は、BPELプロセスに接続したメディエータ(Mediator1)を示します。メディエータによりアウトバウンド変換を使用して、XMLデータをネイティブ文字列に変換し、この文字列をBPELプロセスにルーティングします。

図20-22 アウトバウンド・データを送信するメディエータ

アウトバウンド・データをXMLからネイティブXSDフォーマットに変換するには:

1. メディエータ(Mediator1)を右クリックし、「編集」を選択します。

2. データをメディエータからBPELプロセス(ターゲット・サービス)にルーティングするルーティング・ルールの下で、「ネイティブへの変換」フィールドの右側にあるアイコンをクリックします。図20-23 に、Mediator1のルーティング・ルール・セクションを示します。

図20-23 「ネイティブへの変換」オプション

3. 表示される「翻訳の追加」ダイアログで、「入力」フィールドのデフォルト入力変数をオプションで編集します。「入力」フィールドには、メディエータにより作成される中間入力変数が移入されます。この変数は、translateToNative.in.some_name形式である必要があります。

注意:

関連するルーティング・ルールの割当てアクションや変換アクションを使用して、後で値を中間入力変数に割り当てることができます。

図20-24 に、「翻訳の追加」ダイアログ・ボックスを示します。

図20-24 「Add Translation」ダイアログ

4. 「NXSDスキーマ」フィールドの右側で、「検索」アイコンを選択し、スキーマを選択するために「タイプ・チューザ」ダイアログを起動します。スキーマが存在しない場合、2番目のアイコンをクリックすると、スキーマを作成できます。

5. スキーマを選択して「OK」をクリックします。「要素」フィールドは、選択スキーマから移入されます。

6. 「出力」フィールドの右側にあるアイコンをクリックします。「式ビルダー」ダイアログが表示されます。

7. 出力文字列を「変数」ツリーでダブルクリックします。「OK」をクリックします。

図20-25 「式ビルダー」で完了した出力文字列

8. 「翻訳の追加」ダイアログ・ボックスで、「OK」をクリックします。

20.3.2.12 XSLTトランスフォーメーションの作成方法

Oracle JDeveloperには、XSLTマッパーが用意されています。XSLTマッパーを使用すると、データをXMLスキーマ(XSDファイルで表されます)間で変換するためのマッパー・ファイル(XSLファイル)を指定できます。XSLTマッパーを使用することで、異なるスキーマを使用しているアプリケーション間でのデータ交換が可能になります。たとえば、受信する発注スキーマを、送信する請求書スキーマにマップできます。XSLファイルを定義した後は、そのファイルを複数のルーティング・ルール仕様で再利用できます。

20.3.2.12.1 トランスフォーメーションを作成する手順:

1. 「ルーティング・ルール」セクションで、「次を使用して変換」フィールドの右側にある「既存のマッパー・ファイルを選択するか、新規マッパー・ファイルを作成します。」アイコンをクリックします。「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

2. 次のいずれかを行います:

- XSLTマップ・ファイル(.xsl)が存在する場合、「参照」をクリックして、使用するXSLTファイルを検索して選択します。「OK」をクリックします。

- 新しいXSLTマップ・ファイルを作成している場合は、「マッピングの作成」アイコンをクリックします。「トランスフォーメーション・マップの作成」ダイアログが表示されます。

3. 「トランスフォーメーション・マップの作成」ダイアログで、「タイプ」の下で「XSLT」を選択します。

4. XSLTの「ファイル名」を適切に編集します。

5. XSLTの「ディレクトリ」を適切に編集します。デフォルト・ディレクトリは、SOA_Project/SOA/Transformationsディレクトリです。「参照」をクリックして参照し、ディレクトリを選択します。

6. 同期リプライ、コールバック・レスポンスまたはフォルト・メッセージに対して、前述の手順を繰り返します。
図20-26 に示すように、同期リプライまたはフォルト・メッセージの場合、「リプライ・トランスフォーメーション・マップ」ダイアログまたは「フォルト・トランスフォーメーション・マップ」ダイアログには、「リクエストをリプライ・ペイロードに含める」オプションがあります。

図20-26 「リプライ・トランスフォーメーション・マップ」ダイアログ

7. 同期相互作用の元のメッセージを含む$initial変数を作成するには、「リクエストをリプライ・ペイロードに含める」オプションを選択します。
図20-27 に示すように、変数が作成されます。

図20-27 XSLファイルの初期変数

注意:

初期メッセージも複数のパートで構成されます。$initial.partnameを使用して、初期メッセージのパートにアクセスします。インバウンド・メッセージとアウトバウンド・メッセージのパートが同じ場合、データ交換にトランスフォーメーションは必要ありません。

XSLTマッパーの詳細は、「XSLTマップ・エディタを使用したトランスフォーメーションの作成」を参照してください。

20.3.2.12.2 ユーザー定義拡張関数を追加する手順:

式ビルダーを使用すると、ユーザー定義拡張関数を含めることができます。

1. XPath関数を作成します。

2. Jaxen XPath関数を、サーバーのxpath-function.xmlファイルのメディエータ・サービス・コンポーネントに登録します。

3. Oracle JDeveloperを起動します。

4. 式ビルダーで式をカスタマイズします。

5. Oracle JDeveloperプロジェクトをOracle WebLogic Serverにデプロイします。

6. ユーザー定義拡張関数を格納したJARファイルを$BEAHOME/user_projects/domains/soainfra/autodeploy/soa-infra/APP-INF/libディレクトリにコピーします。

7. プロジェクトの.mplanファイルを、次のように変更します。

- 拡張関数用に定義した関数ネームスペースをMediator要素の下に追加します。

- 関数名をExpression要素に追加します。

これは、図20-28 に示されています。

図20-28 プロジェクトの.mplanファイル – ユーザー定義拡張関数を使用するように変更済

8. 適切なペイロードでテスト・ページを起動します。

20.3.2.13 XQueryトランスフォーメーションを作成する方法

Oracle Mediatorでは、複数のXMLスキーマ間のXQueryトランスフォーメーションがサポートされています。XQuery 1.0仕様がサポートされています。

20.3.2.13.1 XQueryトランスフォーメーションを作成する手順:

1. 「ルーティング・ルール」セクションで、「次を使用して変換」フィールドの右側にある「既存のマッパー・ファイルを選択するか、新規マッパー・ファイルを作成します。」アイコンをクリックします。「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

2. 次のいずれかを行います:

- XQueryマップ・ファイル(.xqy)が存在する場合、「参照」をクリックして、使用するXQueryファイルを検索および選択します。「OK」をクリックします。

- 新しいXQueryマップ・ファイルを作成する場合、「マッピングの作成」アイコンをクリックします。「トランスフォーメーション・マップの作成」ダイアログが表示されます。

3. 「トランスフォーメーション・マップの作成」ダイアログで、「XQuery」を「タイプ」の下で選択します。
図20-29 に、「トランスフォーメーション・マップの作成」ダイアログを示します。

図20-29 「トランスフォーメーション・マップの作成」ダイアログ

4. XQueryの「ファイル名」を適切に編集します。

5. XQueryの「ディレクトリ」を適切に編集します。デフォルト・ディレクトリは、SOA_Project/SOA/Transformationsディレクトリです。「参照」をクリックして参照し、ディレクトリを選択します。

6. 「外部変数」セクションの下で、外部変数をXQuery用に定義できます。「変数の追加」をクリックして、新しい外部変数を追加します。「外部変数の追加」ダイアログが表示されます。

注意:

トランスフォーメーション入力として利用可能な暗黙メディエータ変数で外部変数が自動的に作成されます。たとえば、メディエータ入力リクエストのin.requestは自動的に外部変数を持ちます。

図20-30 に、「外部変数の追加」ダイアログを示します。

図20-30 「外部変数の追加」ダイアログ

7. 外部変数の「名前」、「スキーマ」およびスキーマの「要素」を指定します。

8. 「元」の下で、外部変数の値をマップする方法を選択します。次のいずれかから選択します。

- プロパティ: 選択可能なプロパティがリストされます。

- 式: メディエータ暗黙変数、プロパティ、および式で使用できる関数のリストを使用して式を構築できます。「式ビルダーの起動」アイコンをクリックすると、式ビルダーを起動できます。
式ビルダーの使用方法の詳細は、「メッセージをフィルタリングする式の指定方法」および「の式ビルダーでのXPath式の構築」を参照してください。

- 定数: 外部変数のリテラル値を指定できます。

- XMLフラグメント: 外部変数のXMLデータを指定できます。

9. 「OK」を「外部変数の追加」ダイアログでクリックして、外部変数を追加します。「トランスフォーメーション・マップの作成」ダイアログは、外部変数で移入されます。

注意:

外部変数を編集するには、リストから選択し「変数の更新」をクリックします。

外部変数を削除するには、リストから選択し「変数の削除」をクリックします。

10. 「トランスフォーメーション・マップの作成」ダイアログで、「OK」をクリックします。「リクエスト・トランスフォーメーション・マップ」ダイアログが表示され、定義された外部変数と「マッパー・ファイル」名で移入されます。
図20-31 に、「リクエスト・トランスフォーメーション・マップ」ダイアログを示します。

図20-31 「リクエスト・トランスフォーメーション・マップ」ダイアログ

11. 「リクエスト・トランスフォーメーション・マップ」ダイアログで、「OK」をクリックします。トランスフォーメーション・アクション詳細がメディエータのmplanファイルに追加されます。

20.3.2.13.2 XQueryトランスフォーメーションを編集する手順:

1. 「ルーティング・ルール」セクションで、「次を使用して変換」フィールドの右側にある「既存のマッパー・ファイルを選択するか、新規マッパー・ファイルを作成します。」アイコンをクリックします。「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

注意:

既存のXQuery (.xqy)マップで外部変数の追加や削除はできません。ただし、外部変数を選択して、「変数の更新」をクリックし、外部変数に関連する式や値を変更できます。

2. 「マッパー・ファイル」フィールドの右側にある「マッピングの編集」アイコンをクリックします。XQueryマップがXQueryマッパーで開きます。

3. XQueryマッパーを使用する方法の詳細は、「XQueryマッパーを使用したトランスフォーメーションの作成」を参照してください。

20.3.2.14 値の割当て方法

メッセージのヘッダー、ペイロードおよびプロパティは、「値の割当て」フィールドを使用してソースからターゲットに伝播できます。図20-32 に、「値の割当て」ダイアログを示します。このダイアログは、「ルーティング・ルール」セクションの「値の割当て」アイコンをクリックすると表示されます。

図20-32 「値の割当て」ダイアログ

「値の割当て」ダイアログの左ペインにソース変数が含まれ、右ペインにターゲット変数が表示されます。値をソース変数からターゲット変数にコピーできます。また、複雑な式を作成してターゲット変数に割り当てることができます。また、リテラル(定数やXMLフラグメント)をターゲット変数に割り当てることができます。

「値の割当て」ダイアログの下部ペインに、作成した割当てが表示されます。割当ての選択と編集ができます。

20.3.2.14.1 ソース・ノードをターゲット・ノードにコピーする手順:

1. ソース・ノードの横にあるプラス記号(+)をクリックして、左ペインのソース・ツリーを展開します。単純にターゲット・ツリーを右ペインで展開します。

2. 次のいずれかの方法で、ソース変数をターゲット変数にコピーします。

- 適切なソース・ノードをターゲット・ノードにドラッグします。ソース・ノードとターゲット・ノードを接続する行が表示されます。割当ても下部ペインに表示されます。図20-33 は、ソース・ノードをターゲット・ノードにコピーした後の「値の割当て」ダイアログを示します。

- 左ペインのソース・ノードと右ペインのターゲット・ノードを選択します。下部ペインの上にある「選択したノードからルールを作成」アイコン(緑のプラス・アイコン)をクリックして、割当てを作成します。

図20-33 ターゲット変数へのソース変数のコピー

3. 「OK」をクリックして割当てを作成します。

20.3.2.14.2 複雑な式を割り当てる手順:

1. 「ソース式の割当て」アイコンを右上隅からターゲット・ノードかキャンバス(中央ペイン)にドラッグします。「式ビルダー」が表示されます。

2. 利用可能なソース変数と関数を使用して式を作成します。
必要に応じて「ヘルプ」をクリックして、「式ビルダー」ダイアログの詳細を参照してください。

3. 「OK」をクリックして式ビルダーを閉じます。

4. 手順1で式をキャンバスや中央ペインにドラッグした場合、式アイコンをキャンバスで適切なターゲット・ノードにドラッグします。これによって、式がターゲット変数にマップされます。

注意:

割当てを編集するには、割当てを下部ペインで右クリックします。「ソース式の編集」または「ターゲット式の編集」を選択して、ソースやターゲットをそれぞれ編集します。

5. 「OK」をクリックして割当てを作成します。

20.3.2.14.3 定数値とXMLフラグメントを割り当てる手順:

1. 「ソース・リテラルの割当て」アイコンを右上隅からターゲット・ノードかキャンバス(中央ペイン)にドラッグします。「ソース・リテラルの割当て」ダイアログが表示されます。

2. 割り当てる定数値またはXMLフラグメントを入力します。

3. 定数値が有効なXMLの場合、「リテラルはXMLフラグメントです」を選択します。

4. 「OK」をクリックします。

5. 手順1でソース・リテラルをキャンバスや中央ペインにドラッグした場合、ソース・リテラル・アイコンをキャンバスで適切なターゲット・ノードにドラッグします。これによって、ソース・リテラルがターゲット変数にマップされます。

注意:

- イベントの公開時に特定のメディエータ・プロパティに値を割り当てた場合、その値はサブスクライブするイベントに伝播されません。
この問題を回避するには、トランスフォーメーションを使用して、イベント本体の一部としてプロパティを含めます。

- Oracle WebLogic Serverのjca.db.userNameおよびjca.db.passwordプロパティに値を割り当てることはできません。これは、これらのデータ・ソースでは、getConnectionメソッドへのユーザー名またはパスワードの動的な設定がサポートされていないためです。

表20-2 から表20-4 に、メッセージの定数とプロパティ、ペイロードおよびヘッダーに関するソースからターゲットへの考えられる様々な割当てを示します。

表20-2 定数とプロパティの場合の考えられる割当て

ソース

ターゲット

例

プロパティ

プロパティ

<copy expression="$in.property.jca.file.FileName" target="$out.property.jca.file.FileName"/>

定数

プロパティ

<copy value="ConstantNameAssigned.xml" target="$out.property.jca.file.FileName"/>

表20-3 ペイロードの場合の考えられる割当て

ソース

ターゲット

例

XPath式

プロパティ

<copy expression="concat('ExprPropMed','-',oraext:generate-guid())" target="$out.property.jca.file.FileName" xmlns:oraext="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc"/>

XPath式(パート・レベルより下)

プロパティ

<copy expression="$in.body/imp1:request/ProductReq/Make" target="$out.property.jca.file.FileName" xmlns:imp1="http://xmlns.oracle.com/psft"/>

プロパティ

XPath式(パート・レベルより下)

<copy value="$in.property.jca.file.FileName" target="$out.request/inp1:request/ProductReq/Model" xmlns:inp1="http://xmlns.oracle.com/psft"/>

定数

XPath式(パート・レベルより下)

<copy value="ConstantModel" target="$out.request/inp1:request/ProductReq/Model" xmlns:inp1="http://xmlns.oracle.com/psft"/>

XPath式

XPath式

<copy expression="$in.body" target="$out.request"/>

XPath式(パート・レベルより下)

XPath式(パート・レベルより下)

<copy expression="$in.body/imp1:request/ProductReq/Make" target="$out.request/imp1:request/ProductReq/Model" xmlns:imp1="http://xmlns.oracle.com/psft"/>

表20-4 ヘッダーの場合の考えられる割当て

ソース

ターゲット

例

XPath式(パート・レベルより下)

プロパティ

<copy expression="$in.header.inp1_header/inp1:header/Name" target="$out.property.jca.file.FileName" xmlns:inp1="http://xmlns.oracle.com/psft"/>

プロパティ

XPath式(パート・レベルより下)

<copy value="$in.property.jca.file.FileName" target="$out.header.inp1_header/inp1:header/Name" xmlns:inp1="http://xmlns.oracle.com/psft"/>

定数

XPath式(パート・レベルより下)

<copy value="NewID.xml" target="$out.header.inp1_header/inp1:header/Id" xmlns:inp1="http://xmlns.oracle.com/psft"/>

定数

XPath式(パート・レベルより下)

<copy value="sampleusername" xmlns:wsse1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" target="$out.header.wsse1_Security/wsse1:Security/wsse1:UsernameToken/wsse1:Username"/>

XPath式

XPath式

<copy target="$out.header.inp1_header" expression="$in.header.inp1_header" xmlns:inp1="http://xmlns.oracle.com/psft"/>

XPath式(パート・レベルより下)

XPath式(パート・レベルより下)

<copy target="$out.header.inp1_header/inp1:header/Name" expression="$in.header.inp1_header/inp1:header/Id" xmlns:inp1="http://xmlns.oracle.com/psft"/>

20.3.2.15 assignアクティビティに関する必知事項

assignアクティビティについては、次の点に注意してください。

- assignアクティビティは、<copy>要素がメディエータのmplanに記述されている順序で実行されます。

- 割当ての順序は、「値の割当て」ダイアログの下部ペインで割当てを選択し、「上」または「下」矢印をクリックして割当てリスト内でその割当てを移動することで変更できます。

- 新しい割当てを作成する場合は、割当てリストの任意の位置に割当てを挿入できます。「値の割当て」ダイアログの下部ペインで既存の割当てを選択し、ダイアログの左上にあるリストから「新規ルールを後に挿入」または「新規ルールを前に挿入」を選択します。

- 「ネイティブからの変換」アクティビティからの出力変数および「ネイティブへの変換」アクティビティへの入力変数も、「値の割当て」ダイアログの割当てに対して使用できます。

- 「値の割当て」ダイアログの下部ペインに表示されるすべての割当ては、「OK」をクリックした後にのみメディエータのmplanに適用されます。

- ソースがターゲットのプロパティに割り当てられている場合でも、そのソースのXPath式は常にリーフ・ノードを参照する必要があります。そうでない場合、ソースの子ノードの値はすべて連結されて、ターゲットのプロパティに割り当てられます。次の例に詳細を示します。

<copy target="$out.property.jca.file.FileName"
expression="$in.body/imp1:request/ProductReq/Make"
xmlns:imp1="http://xmlns.oracle.com/psft"/>

注意:

リーフ・ノードとは、子ノードのないノードです。

- 定数またはプロパティがターゲットのXPath式に割り当てられる場合でも、そのターゲットのXPath式は常にリーフ・ノードを指し示す必要があります。そうでない場合、リーフ以外のノードには文字列値のみが含まれ、 .xsdファイルに従って無効なXMLが生成される可能性があります。次の例に詳細を示します。

<copy target="$out.request/inp1:request/ProductReq/Make" value="NewMakeValue"
xmlns:inp1="http://xmlns.oracle.com/psft"/>

この例では、$out.request/inp1:request/ProductReq/Makeがリーフ・ノードを参照しています。

- トランスフォーメーションが使用可能な場合は、ソース・パートをターゲット・パートに割り当てても、そのターゲットは上書きされます。これは、トランスフォーメーションの最初にassignアクティビティが発生するためです。トランスフォーメーションが使用不可の場合は、assignアクティビティによってターゲットが作成されます。次の例に詳細を示します。

<copy target="$out.request" expression="$in.body"/>

<copy target="$out.header.inp1_header" expression="$in.header.inp1_header"
xmlns:inp1="http://xmlns.oracle.com/psft"/>

- ターゲット・ペイロードのいずれかの子ノードを変更する必要がある場合は、次のような2つのユースケースがあります。

- トランスフォーメーションが使用可能な場合は、ターゲットの子ノードを指し示しているターゲットのXPath式にソース式を直接割り当てます。次の例に詳細を示します。

<copy value="ConstantModel"
target="$out.request/inp1:request/ProductReq/Model"
xmlns:inp1="http://xmlns.oracle.com/psft"/>

- トランスフォーメーションが使用不可の場合は、次の2つのステップを実行します。最初に、ソース・パートをターゲット・パートに割り当て、次にターゲットの子ノードを指し示しているターゲットのXPath式にソース式を直接割り当てます。次の例に詳細を示します。

<copy target="$out.request" expression="$in.body"/> and <copy
value="ConstantModel" target="$out.request/inp1:request/ProductReq/Model"
xmlns:inp1="http://xmlns.oracle.com/psft"/>

- ソースの子ノードの1つのみをターゲットに伝播する必要がある場合は、最初にトランスフォーメーションが起動されていないことを確認します。次に、必要な子ノードを指し示すソースのXPath式を割り当てます。次の例に詳細を示します。

<copy target="$out.request/imp1:ProductReq"
expression="$in.body/imp1:request/ProductReq"
xmlns:imp1="http://xmlns.oracle.com/psft"/>

このケースで、$in.body/imp1:request/ProductReqから評価されるソース要素には、子ノードのみが含まれ、ルート要素から始まる完全なツリー構造は含まれていません。次の例に詳細を示します。

<ProductReq>
<Make>MAKE</Make>
<Model>MODEL</Model>
</ProductReq>

- メディエータに複数のassignアクティビティがあり、各ソースのXPath式が別々の子ノードを指し示している場合は、次のような2つのユースケースがあります。

- トランスフォーメーションが使用可能な場合は、ターゲットの対応する子ノードが更新されます。

- トランスフォーメーションが使用不可の場合、ターゲットは複数パートのターゲットであり、各パートがソースの子ノードを参照している必要があります。

- ヘッダーの場合、passThroughHeaderプロパティが設定されている場合は、次のようになります。

- トランスフォーメーションのヘッダー操作は、ターゲットのヘッダーで更新されます。

- パート・レベルのassignアクティビティによって、ターゲットのヘッダー・パートが上書きされます。

- パート・レベルより下のノードのassignアクティビティによって、ターゲットの対応するノードが更新されます。

- (パート・レベルより下の)複数のソース・ノードが(パート・レベルより下の)同じターゲット・ノードに割り当てられている場合、そのターゲット・ノードには、assignアクティビティの最後のcopy要素の値が含まれます。次の例に詳細を示します。

<copy target="$out.request/imp1:request/ProductReq/Make"
expression="$in.body/imp1:request/ProductReq/Model"
xmlns:imp1="http://xmlns.oracle.com/psft"/>

<copy target="$out.request/imp1:request/ProductReq/Make"
expression="$in.body/imp1:request/Description"
xmlns:imp1="http://xmlns.oracle.com/psft"/>

前の例で、最初のcopy要素は、2番目のcopy要素によって上書きされるため何も効果がありません。

- XPath式の結果がリスト(複数発生)になる場合は、次の2つのユースケースがあります。

- リストに単一の要素が含まれる場合は、XPath式が伝播されます。

- リストに複数の要素が含まれる場合、XPath式はサポートされません。

- ソースの子ノードをターゲットの子ノードに割り当てると、次のアクティビティが発生します。

1. ソースの子ノードの名前とネームスペースが、ターゲットのノード名とネームスペースによってそれぞれ上書きされます。

2. ターゲットの子ノードは、ターゲット・ノードの親ノードにあるソースの子ノードによって置換されます。

20.3.2.16 フィルタおよび割当てのためのヘッダー・アクセス方法

フィルタを定義するため、または割当てソースや割当てターゲットを定義するためにメディエータから式ビルダーを起動すると、WSDLファイルが解析されます。その際に、図20-34 に示すように、現在のルーティング・ルール操作のSOAPヘッダーが自動的に検出され、このSOAPヘッダーが変数として、inフォルダまたはoutフォルダにheader./ns_elementName/のように表示されます。ここで、nsはネームスペース接頭辞、elementNameはヘッダー・スキーマのルート要素名です。

次のシナリオで詳細を説明します。

シナリオ1: ネームスペース接頭辞wsseおよびns1がすでに定義されている場合

ネームスペース接頭辞wsseおよびns1がWSDLファイルまたは.mplanファイルにすでに定義されているとします。この場合、XPath式は次のように記述できます。

$in.header.wsse_Security/wsse:Security/ns1:Foo/Priority

シナリオ2: WSDLファイルにネームスペースが事前定義されていないスキーマの場合

WSDLファイルにネームスペースが事前定義されていないスキーマを使用するとします。この場合、式ビルダーでは、接頭辞のかわりに{full_namespace}を入力できる機能が提供されます。さらに、式ビルダーによって一意の接頭辞が生成され、接頭辞の定義が.mplanファイルに追加されます。

たとえば、式ビルダーに次の例に示す式を入力するとします。

$in.header.{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-sec
ext-1.0.xsd}_Security/
{"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xs
d"}:
Security/{"http://www.globalcompany.com/ns/OrderBooking"}:Foo/Priority

.mplanファイルには、次の例に示すコンテンツが含まれています。

xmlns:ns1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd"
xmlns:ns2="http://www.globalcompany.com/ns/OrderBooking"
...
expression="$in.header.ns1_Security/ns1:Security/ns2:Foo/Priority"

図20-34 「式ビルダー」ダイアログ - 自動ヘッダー検出

デフォルトでは、SOAPヘッダーはメディエータを介して渡されません。passThroughHeaderエンドポイント・プロパティを、対応するメディエータ・ルーティング・サービスに追加する必要があります。

<property name="passThroughHeader">true</property>

たとえば、このプロパティを追加するには、composite.xmlファイルを次の例に示すように変更できます。

<component name="Mediator1">
<implementation.mediator src="Mediator1.mplan"/>
<property name="passThroughHeader">true</property>
</component>

ヘッダーを渡すには、ソースとターゲットのQName(名前とネームスペース)が同じである必要があります。ソースとターゲットのQNameが異なる場合は、トランスフォーメーションまたはパートレベルの割当てのいずれかを実行する必要があります。

(トランスフォーメーションまたはassignを使用しない)passthroughメディエータの場合、ソースとターゲットのパートQNameが同じでない場合は、メディエータがメッセージ・ペイロードをターゲット・サービスに渡す際にエラーが発生していない点に注意する必要があります。ただし、この処理はターゲット・サービスでエラーになる場合があります。これは、メッセージ・ペイロードはターゲット・サービスのメッセージ構造に従って再構築されていないためです。

注意:

- このユーザー・インタフェースはSOAP 1.1およびSOAP 1.2の両方をサポートします。

- 自動ヘッダー検出のためには、メディエータ・サービス・コンポーネントの作成時に具体的なWSDLファイルを使用する必要があります。

- 割当てはフィルタの後に実行されます。このため、カスタム・ヘッダーで値を割り当てている場合、特定の割当てはフィルタに対して表示されません。

20.3.2.16.1 フィルタおよび割当てのためのヘッダー・アクセスに使用する式の手動作成

ユースケースによっては、WSDLファイルからヘッダー・スキーマを識別できない場合があります。たとえば、メッセージに付加されたセキュリティ・ヘッダーや、抽象的なWSDLファイルを使用して作成されるメディエータのヘッダーなどです。そのようなヘッダーにアクセスするには、式ビルダーにXPath式を手動で入力する必要があります。

次の例は、ヘッダー式の構文を示しています。

$in.header.<header root element namespace prefix>_<header root element name>/<xpath>

次の例に示すヘッダーがあるとします。

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-sec
ext-1.0.xsd">
<Priority>234</Priority>
</wsse:Security>

フィルタ式は次のようになります。

$in.header.wsse_Security/wsse:Security/Priority = '234'

割当て式は次の例に示すようになります。

<copy target="$out.property.jca.jms.priority"
expression="$in.header.wsse_Security/wsse:Security/Priority"/>

これらの式が機能するには、.mplanファイルのルート要素に次の例に示す属性を追加する必要があります。

wsse = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd"

20.3.2.16.2 フィルタおよび割当てのためのプロパティ・アクセスに使用する式の手動作成

フィルタ式の例は、次のとおりです。

$in.property.tracking.ecid = '2'

割当て式の例は、次のとおりです。

<copy target="$out.property.tracking.ecid"  value="$in.property.tracking.ecid"/>

20.3.2.17 セマンティク検証の使用方法

インバウンド・メッセージとその様々なパートは、Schematronファイルを指定して検証できます。Schematronバージョン1.5がサポートされているバージョンです。

Schematronスキーマを指定して、インバウンド・メッセージとその様々なパートを検証する手順は、次のとおりです。

セマンティク検証を使用する手順は、次のとおりです。

1. 「セマンティックの検証」フィールドの右側にある検証ファイルの選択アイコンをクリックします。

「検証」ダイアログが表示されます。

2. 「追加」をクリックします。

「検証の追加」ダイアログが表示されます。

3. 「パート」リストから、メッセージ・パートを選択します。

4. 「ファイル」フィールドの右側にある「検索」をクリックします。

「SOAリソース・ブラウザ」ダイアログが表示されます。

5. Schematronファイルを選択し、「OK」をクリックします。

注意:

- 通常、Schematronファイルの拡張子は.schです。

- 選択したSchematronファイルが空の場合、エラー・メッセージまたは警告は表示されません。

図20-35 に示すように、「検証の追加」ダイアログが更新されます。

図20-35 「検証の追加」ダイアログ

6. 「OK」をクリックします。

図20-36 に示すように、「検証」ダイアログが更新されます。

図20-36 「検証」ダイアログ

7. 「追加」をクリックして別のメッセージ・パートのSchematronファイルを指定するか、「OK」をクリックします。

Schematronスキーマの作成方法の詳細は、次の場所から入手できるリソースを参照してください。

http://www.schematron.com

注意:

セマンティク検証では、各要素名の長さをチェックした場合、異なる入力セットに対して要素名が変わる場合があります。これは、パーサーが空白をテスト・ノードとして処理するため、ノード間に空白がある場合に発生します。

20.3.2.18 添付ファイルの処理方法

プロジェクトのcomposite.xmlファイルにプロパティを追加することによって、メディエータが添付ファイルを処理する方法を構成できます。添付ファイルの処理の詳細は、「アタッチメント・ストリームの送信」および「Oracle Mediatorでの添付ファイルのパス・スルー設定のオーバーライド」を参照してください。

20.3.2.19 Javaコールアウトの使用方法

Javaコールアウトを使用すると、メディエータを介してフローするメッセージの操作に外部のJavaクラスを使用できます。操作またはイベント・サブスクリプションごとに、Javaコールアウトは1つのみサポートされます。コールアウト・クラスは、oracle.tip.mediator.common.api.IjavaCalloutインタフェースを実装する必要があります。コールアウトは、静的ルーティングおよび動的ルーティングの両方に使用できます。図20-37 に、2つの操作が指定されたメディエータのサンプルを示します。2つの操作には、それぞれルーティング・ルールが1つあり、最初の操作にはコールアウト・クラスが指定されています。

図20-37 Javaコールアウトをサポートするメディエータのサンプル

20.3.2.19.1 Javaコールアウト・クラスを使用できるようにする手順:

サーバーでJavaコールアウト・クラスが使用できることが必要です。このためには、次のいずれかの方法を使用します。

- JavaクラスをSCA-INF/classesフォルダにコピーします。

- Javaクラスが含まれているJARファイルをSCA-INF/libフォルダにコピーします。

- Javaクラスが含まれているJARファイルを$DOMAIN_HOME/libフォルダにコピーします。

Javaコールアウト・クラスを複数のメディエータで使用できるようにするには、Javaクラスが含まれているJARファイルを$DOMAIN_HOME/libフォルダにコピーします。

20.3.2.19.2 コールアウトのJavaクラスを入力する手順:

Javaクラスを手動で入力するか、「クラス・ブラウザ」からクラスを選択できます。

- 図20-38 に示すように、Javaコールアウト・クラスの名前を手動で入力するには、「コールアウト先」フィールドにクラス名を入力し始めます。Oracle JDeveloperのオートコンプリート機能によって、現在のプロジェクトのアドレスとクラスが挿入されます。

図20-38 「コールアウト先」フィールド

- 使用可能なクラスをリストから選択するには、「Javaコールアウト・クラスを選択します。」アイコンをクリックします。
図20-39 に示すように、標準のOracle JDeveloperクラス・ブラウザが表示されます。

図20-39 「クラス・ブラウザ」ダイアログ

クラス・ブラウザは、oracle.tip.mediator.common.api.IjavaCalloutインタフェースを実装するクラスのみが表示されるようにフィルタリングされます。

20.3.2.19.3 ペイロードのルート要素を設定する手順(フィルタ式を使用している場合):

メディエータにJavaコールアウトがあり、同じメディエータでフィルタ式を使用している場合は、ペイロードのルート要素を次の例に示すように設定する必要があります。

changexmldoc = XmlUtils.getXmlDocument(ChangedDoc);
String mykey = "request";
message.addPayload(mykey,changexmldoc.getDocumentElement());

20.3.2.19.4 ドメイン値マップと相互参照関数を有効にする手順:

Javaコールアウトでドメイン値マップ関数または相互参照関数を使用するには、soa-xpath-exts.jarファイルをプロジェクトに追加し、コードに必要なJavaクラスをインポートする必要があります。

1. Oracle JDeveloperプロジェクト・エクスプローラで、Javaコールアウトを含むプロジェクトの名前を右クリックします。

2. 「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログが表示されます。

3. 図20-40 に示すように、左側のパネルで、「ライブラリとクラスパス」を選択します。

図20-40 「プロジェクト・プロパティ」ダイアログのライブラリとクラス

4. 「JAR/ディレクトリの追加」をクリックします。
図20-41 に示すように、「アーカイブまたはディレクトリの追加」が表示されます。

図20-41 「アーカイブまたはディレクトリの追加」ダイアログ

5. エクスプローラ・ツリーで、ディレクトリを展開して<JDEV_HOME>/jdeveloper/soa/modules/oracle.soa.fabric_11.1.1/soa-xpath-exts.jarを選択し、次に「選択」をクリックします。
JARファイルが「クラスパス・エントリ」リストに表示されます。

6. 「OK」をクリックします。

注意:

ドメイン値マップ関数を使用する場合は、Javaクラスに次をインポートします。

- oracle.tip.dvm.LookupValue

- oracle.tip.dvm.exception.DVMException

相互参照(xref)関数を使用する場合は、Javaクラスに次をインポートします。

- oracle.tip.xref.xpath.XRefXPathFunctions

- oracle.tip.xref.exception.XRefException

20.3.2.19.5 メディエータのJavaコールアウトAPI

JavaコールアウトAPIでは、oracle.tip.mediator.common.api.IjavaCalloutおよびoracle.tip.mediator.common.api.CalloutMediatorMessageという2つのインタフェースを定義します。

表20-5 では、oracle.tip.mediator.common.api.IjavaCalloutインタフェースのメソッドをリストして説明します。

表20-5 IjavaCalloutインタフェースのメソッドの説明

メソッド

説明

initialize

コールアウト実装クラスが初めてインスタンス化されるときに起動されます。

preRouting

メディエータがケースの実行を開始する前にコールされます。このメソッドをカスタマイズすると、検証および拡張機能を組み込むことができます。

preRoutingRule

メディエータが特定のケースの実行を開始する前にコールされます。このメソッドをカスタマイズすると、ケース固有の検証および拡張機能を組み込むことができます。

preCallbackRouting

メディエータがコールバック処理の実行を終了する前にコールされます。このメソッドをカスタマイズすると、コールバックの監査およびカスタムのフォルト・トラッキングを実行できます。

postRouting

メディエータがケースの実行を終了した後にコールされます。このメソッドをカスタマイズすると、レスポンスの監査およびカスタムのフォルト・トラッキングを実行できます。

後処理メソッドは、すべての順次ルーティングが実行された後にコールされますが、パラレルのルーティング・ルールの完了は待機しません。

postRoutingRule

メディエータがケースの実行を開始した後にコールされます。このメソッドをカスタマイズすると、レスポンスの監査およびカスタムのフォルト・トラッキングを実行できます。

postCallbackRouting

メディエータがコールバック処理の実行を終了した後にコールされます。このメソッドをカスタマイズすると、コールバックの監査およびカスタムのフォルト・トラッキングを実行できます。

注意:

preRoutingRuleメソッドまたはpreRoutingメソッドで、Javaコールアウトを使用してメディエータのメッセージ・プロパティを変更した場合は、メディエータの割当て機能を使用して、変更したプロパティをアウトバウンド・メッセージに明示的にコピーする必要があります。たとえば、Javaコールアウトでjca.file.FileNameを変更している場合は、メディエータの割当て文を次のように更新する必要があります。

<assign>
<copy target="$out.property.jca.file.FileName"
expression="$in.property.jca.file.FileName"/>
</assign>

表20-6 で、CalloutMediatorMessageインタフェースのメソッドについて説明します。

表20-6 CalloutMediatorMessageインタフェースのメソッドの説明

メソッド

説明

addPayload

メディエータ・メッセージのペイロードを設定します。

addProperty

メディエータ・メッセージにプロパティを追加します。

addHeader

メディエータ・メッセージにヘッダーを追加します。

getProperty

プロパティ名を指定してメディエータ・メッセージのプロパティを取得します。

getProperties

メディエータ・メッセージのプロパティを取得します。

getId

メディエータ・メッセージのインスタンスIDを取得します。このインスタンスIDは、該当する特定のメッセージに対して作成されたメディエータ・インスタンスIDです。

getPayload

メディエータ・メッセージのペイロードを取得します。

getHeaders

メディエータ・メッセージのヘッダーを取得します。

getComponentDN

メディエータ・サービス・コンポーネントのcomponentDNを取得します。

注意:

- oracle.tip.mediator.common.api.AbstractJavaCalloutImplクラスは、IJavaCalloutインタフェースのダミー実装です。このクラスによって、IJavaCalloutインタフェースに存在するすべてのメソッドが定義されます。このため、このクラスの拡張によって、IJavaCalloutインタフェースのいくつかの特定メソッドのみをオーバーライドできます。
インタフェースのダミー実装は、実装クラスによって、特定のインタフェースで宣言されているすべてのメソッドの定義が提供されることを意味しますが、空のメソッド本体を1つ以上の定義済メソッドに指定することはできます。ダミー実装クラスの拡張は、インタフェースを実装してすべてのメソッドを定義する場合と異なり、メソッドのサブセットのみをオーバーライドできるためより簡単です。

- Javaコールアウト内で発生する処理の詳細は、メディエータの「監査証跡」画面には表示されません。

20.3.2.19.6 Javaコールアウト・クラスのサンプル

次の例は、Javaコールアウト・クラスのサンプルを示しています。

package qa.as11tests.javacallout;

import com.collaxa.cube.persistence.dto.XmlDocument;

import com.oracle.bpel.client.NormalizedMessage;

import java.util.logging.Logger;
import java.util.Map;
import java.util.Iterator;

import oracle.tip.mediator.common.api.CalloutMediatorMessage;
import oracle.tip.mediator.common.api.ExternalMediatorMessage;
import oracle.tip.mediator.common.api.IJavaCallout;
import oracle.tip.mediator.common.api.MediatorCalloutException;
import oracle.tip.mediator.metadata.CaseType;
import oracle.tip.mediator.utils.XmlUtils;

import oracle.tip.pc.services.functions.ExtFunc;

import oracle.xml.parser.v2.XMLDocument;

import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.Node;

public class JavaCalloutSanity implements IJavaCallout {
Logger logger = Logger.getLogger("Callout");
public JavaCalloutSanity() {    }

public void initialize(Logger logger) throws MediatorCalloutException {
this.logger = logger;
this.logger.info("Initializing...");
}
public boolean preRouting(CalloutMediatorMessage calloutMediatorMessage) {
System.out.println("Pre routing...");
String sPayload = "null";
String sPayload_org = "null";
for (Iterator msgIt = calloutMediatorMessage.getPayload().entrySet().iterator();
msgIt.hasNext(); ) {
Map.Entry msgEntry = (Map.Entry)msgIt.next();
Object msgKey = msgEntry.getKey();
Object msgValue = msgEntry.getValue();
if (msgKey.equals("request"))
sPayload = XmlUtils.convertDomNodeToString((Node)msgValue);
}
sPayload_org = sPayload;
String tobeReplaced = "CHANGE_THIS";
String replaceWith = "JAVA_CALLOUT_||_PRE_ROUTING";
int start = sPayload.indexOf(tobeReplaced);
StringBuffer sb = new StringBuffer();
sb.append(sPayload.substring(0, start));
sb.append(replaceWith);
sb.append(sPayload.substring(start + tobeReplaced.length()));
String changedPayload = sb.toString();
String uid;
try {
uid = ExtFunc.generateGuid();
} catch (Exception e) {
}
XMLDocument changedoc;
try {
changedoc = XmlUtils.getXmlDocument(changedPayload);
String mykey = "request";
calloutMediatorMessage.addPayload(mykey,
changedoc.getDocumentElement());
//calloutMediatorMessage.getPayload().put(mykey, changedoc);
} catch (Exception e) {
}
System.out.println("Changed from : \n"+sPayload_org+"\nTo\n"+changedPayload);
System.out.println("End Pre routing...\n\n");
return false;
}
public boolean postRouting(CalloutMediatorMessage calloutMediatorMessage,
CalloutMediatorMessage calloutMediatorMessage1,
Throwable throwable) throws MediatorCalloutException {
System.out.println("Start Post routing...");
String sPayload = "null";
String sPayload_org = "null";
for (Iterator msgIt = calloutMediatorMessage1.getPayload().entrySet().iterator();
msgIt.hasNext(); ) {
Map.Entry msgEntry = (Map.Entry)msgIt.next();
Object msgKey = msgEntry.getKey();
Object msgValue = msgEntry.getValue();
if(msgKey.equals("reply"))
sPayload = XmlUtils.convertDomNodeToString((Node)msgValue);
}

sPayload_org = sPayload;
String tobeReplaced = "POST_ROUTING_RULE_REQUEST_REPLY";
String replaceWith = "POST_ROUTING_RULE_REQUEST_REPLY_||_POSTROUTING_||_JAVA_CALLOUT_WORKING";
int start = sPayload.indexOf(tobeReplaced);
StringBuffer sb = new StringBuffer();
sb.append(sPayload.substring(0, start));
sb.append(replaceWith);
sb.append(sPayload.substring(start + tobeReplaced.length()));
String changedPayload = sb.toString();
XMLDocument changedoc;
try {
changedoc = XmlUtils.getXmlDocument(changedPayload);
String mykey = "reply";
calloutMediatorMessage1.addPayload(mykey,changedoc.getDocumentElement());
// calloutMediatorMessage1.getPayload().put(mykey, changedoc.getDocumentElement());
} catch (Exception f) {
}
System.out.println("Changed from : \n"+sPayload_org+"\nTo\n"+
changedPayload);
System.out.println("End Post routing...\n\n");
return false;
}
public boolean preRoutingRule(CaseType caseType,
CalloutMediatorMessage calloutMediatorMessage) {
System.out.println("\nStart PreRoutingRule.\n");
String sPayload = "null";
String sPayload_org = "null";
for (Iterator msgIt =
calloutMediatorMessage.getPayload().entrySet().iterator();
msgIt.hasNext(); ) {

Map.Entry msgEntry = (Map.Entry)msgIt.next();
Object msgKey = msgEntry.getKey();
Object msgValue = msgEntry.getValue();
if(msgKey.equals("request"))
sPayload = XmlUtils.convertDomNodeToString((Node)msgValue);
}
sPayload_org = sPayload;
String tobeReplaced = "PRE_ROUTING";
String replaceWith = "PRE_ROUTING_||_PRE_ROUTING_RULE";
int start = sPayload.indexOf(tobeReplaced);
StringBuffer sb = new StringBuffer();
sb.append(sPayload.substring(0, start));
sb.append(replaceWith);
sb.append(sPayload.substring(start + tobeReplaced.length()));
String changedPayload = sb.toString();
XMLDocument changedoc;
try {
changedoc = XmlUtils.getXmlDocument(changedPayload);
String mykey = "request";
calloutMediatorMessage.addPayload(mykey,
changedoc.getDocumentElement());
// calloutMediatorMessage.getPayload().put(mykey, changedoc);
} catch (Exception e) {
}
System.out.println("Changed from : \n"+sPayload_org+"\nTo\n"+changedPayload);
System.out.println("End PreRoutingRule.\n\n");
return true;
}
public boolean postRoutingRule(CaseType caseType,
CalloutMediatorMessage calloutMediatorMessage,
CalloutMediatorMessage calloutMediatorMessage1,
Throwable throwable) {
System.out.println("Start PostRoutingRule.");
String req_sPayload = "null";
String req_sPayload_org = "null";
String rep_sPayload = "null";
String rep_sPayload_org = "null";
for (Iterator msgIt =
calloutMediatorMessage.getPayload().entrySet().iterator();
msgIt.hasNext(); ) {
Map.Entry msgEntry = (Map.Entry)msgIt.next();
Object msgKey = msgEntry.getKey();
Object msgValue = msgEntry.getValue();
if(msgKey.equals("request"))
req_sPayload = XmlUtils.convertDomNodeToString((Node)msgValue);
}
req_sPayload_org = req_sPayload;
String tobeReplaced = "PRE_ROUTING_RULE";
String replaceWith = "PRE_ROUTING_RULE_||_POST_ROUTING_RULE_REQUEST";
int start = req_sPayload.indexOf(tobeReplaced);
StringBuffer sb = new StringBuffer();
sb.append(req_sPayload.substring(0, start));
sb.append(replaceWith);
sb.append(req_sPayload.substring(start + tobeReplaced.length()));
String changedPayload = sb.toString();
XMLDocument changedoc;
try {
changedoc = XmlUtils.getXmlDocument(changedPayload);
String mykey = "request";
calloutMediatorMessage.addPayload(mykey,
changedoc.getDocumentElement());
// calloutMediatorMessage.getPayload().put(mykey, changedoc);
} catch (Exception e) {
}
for (Iterator msgIt =
calloutMediatorMessage1.getPayload().entrySet().iterator();
msgIt.hasNext(); ) {
Map.Entry msgEntry = (Map.Entry)msgIt.next();
Object msgKey = msgEntry.getKey();
Object msgValue = msgEntry.getValue();
if(msgKey.equals("reply"))
rep_sPayload = XmlUtils.convertDomNodeToString((Node)msgValue);
}
rep_sPayload_org = rep_sPayload;
tobeReplaced = "PRE_ROUTING_RULE";
replaceWith = "PRE_ROUTING_RULE_||_POST_ROUTING_RULE_REQUEST_REPLY";
start = rep_sPayload.indexOf(tobeReplaced);
sb = new StringBuffer();
sb.append(rep_sPayload.substring(0, start));
sb.append(replaceWith);
sb.append(rep_sPayload.substring(start + tobeReplaced.length()));
changedPayload = sb.toString();
try {
changedoc = XmlUtils.getXmlDocument(changedPayload);
String mykey = "reply";
calloutMediatorMessage1.addPayload(mykey,changedoc.getDocumentElement());
// calloutMediatorMessage1.getPayload().put(mykey, changedoc.getDocumentElement());
} catch (Exception e) {
}
System.out.println("Changed from : \n"+req_sPayload_org+"\nTo\n"+changedPayload);
System.out.println("End postRoutingRule\n\n");
return true;
}
}

20.3.3 動的ルーティング・ルールの作成方法

動的ルーティングの基本的な考え方は、プロセスが経由するパスを決定する制御ロジックを、そのプロセスの実行から分離することです。動的ルーティングにより、メッセージの内容に基づいて、実行時にメッセージをメディエータから複数のターゲット・サービスに動的にルーティングできます。ドメイン値マップ(DVM)やデシジョン・コンポーネント(ビジネス・ルール)を使用すると、静的ルーティングを実行時にオーバーライドできます。

20.3.3.1 DVMを使用して静的ルーティング・ルールを動的にオーバーライドする方法

ドメイン値マップ(DVM)を使用すると、既存の静的ルーティング・ルールを動的にオーバーライドできます。新規DVMを作成したり、既存のDVMを使用すると、メディエータ・ルーティング・オプションをオーバーライドできます。

20.3.3.1.1 DVMを使用して静的ルートをオーバーライドする手順:

1. メディエータ・コンポーネントをダブルクリックして、メディエータ・エディタを開きます。

2. 「ルーティング・ルール」セクションの下で、変更するルーティング・ルールまで下にスクロールします。

3. 「次を使用してオーバーライド」フィールドの右側で、緑色の矢印で識別されるボタンをクリックします。図20-42 に、「次を使用してオーバーライド」フィールドを示します。

図20-42 「ルーティング・ルール」の下にある「次を使用してオーバーライド」フィールド

「ルーティングのオーバーライド」ダイアログが表示されます。

4. 「ドメイン値マップの使用」を選択して、ドメイン値マップを作成したり使用します。図20-43 に、「ルーティングのオーバーライド」ダイアログを示します。

図20-43 「ルーティングのオーバーライド」ダイアログ

5. 「場所」フィールドの右側で、「新しいDVMファイルを作成します。」(緑のプラス(+)アイコン)をクリックし、新しいDVMファイルを作成します。ドメイン・マップ値の作成ダイアログが表示されます。

注意:

また、「検索」アイコンで識別される「既存のDVMファイルを検索します。」をクリックすることで、既存のDVMファイルを選択できます。

6. ドメイン・マップ値の作成ダイアログで、「DVM名」を指定し、「ディレクトリ」を選択してDVMファイルを格納します。「OK」をクリックします。「DVMファイル作成済」ダイアログが表示されます。

7. 「OK」をクリックして確定します。「ルーティングのオーバーライド」ダイアログが、新しいDVMの詳細で移入されます。新しいDVMを作成した後「ルーティングのオーバーライド」ダイアログが表示されます。

図20-44 新規ドメイン値マップの詳細

オーバーライド可能なメディエータの機能ごとに新規ドメインが作成されます。たとえば、図20-44 に示すように、メディエータのフィルタ式でフィルタ・ドメインが作成されます。

8. DVMの参照列に対応する「キー・ドメイン」を選択します。

9. 「値式」フィールドの右側で、「式ビルダーの起動」アイコンをクリックし、キー・ドメインに対応する値式を指定します。「式ビルダー」ダイアログが表示されます。

図20-45 式ビルダー

10. ドメイン・キーの値式に対応する式を構築して、「OK」をクリックします。式ビルダーの詳細を調べるには、「ヘルプ」ボタンを使用できます。

11. 「ルーティングのオーバーライド」ダイアログで、「OK」をクリックします。

20.3.3.1.2 新規ドメインをDVMに追加する手順:

1. 「ルーティングのオーバーライド」ダイアログ(図20-44 )で、「場所」フィールドの右側にある「DVMファイル・エディタを開きます」アイコンをクリックします。「メディエータ・オーバーライドDVMの編集」ダイアログが表示されます。図20-46 は、「メディエータ・オーバーライドDVMの編集」ダイアログを示しています。

図20-46 「メディエータ・オーバーライドDVMの編集」ダイアログ

2. 必要に応じて、DVMの「説明」と「名前」を編集します。

3. 「マップ表」の下で、「ドメイン/値の追加」アイコン(緑のプラス(+)アイコン)をクリックします。ポップアップ・メニューが表示されます。

4. 新しいドメインや列を追加するには、「ドメインの追加」を選択します。「ドメインの作成」ダイアログが表示されます。

5. 新規ドメインの「名前」を指定します。「ドメインの作成」プロセスの詳細を調べるには、「ヘルプ」ボタンを使用します。
「OK」をクリックします

20.3.3.1.3 新規行をDVMに追加する手順:

1. 「ルーティングのオーバーライド」ダイアログ(図20-44 )で、「場所」フィールドの右側にある「DVMファイル・エディタを開きます」アイコンをクリックします。「メディエータ・オーバーライドDVMの編集」ダイアログが表示されます(図20-46 )。

2. 「マップ表」の下で、「ドメイン/値の追加」アイコン(緑のプラス(+)アイコン)をクリックします。表示されるポップアップ・メニューから「ドメイン値の追加」を選択します。

3. それぞれの行項目をクリックすると編集できます。または、行を選択し、「ドメイン/値の編集」アイコンをクリックして行を編集します。「メディエータ・オーバーライド行の編集」ダイアログが表示されます。図20-47 は、「メディエータ・オーバーライド行の編集」ダイアログを示しています。

図20-47 「メディエータ・オーバーライド行の編集」ダイアログ

4. 必要に応じてフィールドを編集します。通常のメディエータ・ツールが編集支援で利用できます。たとえば、「変換」ドメインの隣にある「変換」ボタンをクリックすると、トランスフォーメーション・マップを作成できます。編集が完了したら、「OK」をクリックします。

20.3.3.1.4 ドメインをDVMから削除する手順:

1. 「ルーティングのオーバーライド」ダイアログ(図20-44 )で、「場所」フィールドの右側にある「DVMファイル・エディタを開きます」アイコンをクリックします。「メディエータ・オーバーライドDVMの編集」ダイアログが表示されます(図20-46 )。

2. DVM行を削除するには、行を選択して「ドメイン/値の削除」アイコンをクリックします。

20.3.3.1.5 行をDVMから削除する手順:

1. 「ルーティングのオーバーライド」ダイアログ(図20-44 )で、「場所」フィールドの右側にある「DVMファイル・エディタを開きます」アイコンをクリックします。「メディエータ・オーバーライドDVMの編集」ダイアログが表示されます(図20-46 )。

2. DVM列を削除するには、列を選択して「ドメイン/値の削除」アイコンをクリックします。

20.3.3.2 デシジョン・コンポーネントを使用して静的ルーティング・ルールを動的にオーバーライドする方法

デシジョン・コンポーネントやビジネス・ルールを使用すると、既存の静的ルーティング・ルールを動的にオーバーライドできます。新規デシジョン・コンポーネントを作成したり、既存のデシジョン・コンポーネントを使用すると、メディエータ・ルーティング・オプションをオーバーライドできます。

20.3.3.2.1 デシジョン・コンポーネントを使用して静的ルートをオーバーライドする手順:

1. メディエータ・コンポーネントをダブルクリックして、メディエータ・エディタを開きます。

2. 「ルーティング・ルール」セクションの下で、変更するルーティング・ルールまで下にスクロールします。

3. 「次を使用してオーバーライド」フィールドの右側で、緑色の矢印で識別されるボタンをクリックします。図20-48 に、「次を使用してオーバーライド」フィールドを示します。

図20-48 「ルーティング・ルール」の下にある「次を使用してオーバーライド」フィールド

「ルーティングのオーバーライド」ダイアログが表示されます。

4. 「デシジョン・コンポーネントの使用」を選択して、デシジョン・コンポーネントを作成したり使用します。

5. 「デシジョン・コンポーネント」フィールドの右側で、「デシジョン・サービスの作成」(緑のプラス(+)アイコン)をクリックし、新しいデシジョン・サービス・コンポーネントを作成します。「デシジョン・サービスの作成」ダイアログが表示されます。

注意:

また、「検索」アイコンで識別される「既存のデシジョン・サービス・コンポーネントを検索します。」をクリックすることで、既存のデシジョン・サービス・コンポーネント・ファイルを選択できます。

6. デシジョン・コンポーネントで「コンポーネント名」を指定し、サービスで「サービス名」を指定します。「OK」をクリックします。新しいデシジョン・サービス・コンポーネントが作成され、「ルーティングのオーバーライド」ダイアログに戻ります。ダイアログには、デシジョン・サービス・コンポーネントの詳細が格納されます。
このウィンドウで、新しいビジネス・ルール・サービス・コンポーネントが作成され、メディエータ・サービス・コンポーネントのSOAコンポジット内のメディエータ・サービス・コンポーネントに接続されます。

コンポジットの設計ビューを表示する場合、静的な参照接続に加えて、メディエータに接続されたビジネス・ルール・コンポーネントを表示できます。図20-49 に、サンプル・コンポジットの設計ビューを示します。

図20-49 ビジネス・ルール・コンポーネントに接続したメディエータ

ビジネス・ルール・サービス・コンポーネントには、ルール・ディクショナリが含まれています。ルール・ディクショナリは、ファクト・タイプ、ルールセット、ルール、デシジョン表など、ルール・エンジン・アーティファクトに対するメタデータ・コンテナです。ルール・ディクショナリは、ビジネス・ルール・サービス・コンポーネントの作成過程で、次のデータを使用して事前に初期化されます。

- ファクト・タイプ・モデル
ファクト・タイプ・モデルは、ルールのモデル化に使用できるデータ・モデルです。ルール・ディクショナリには、BPELプロセスのphaseアクティビティの入力に対応するファクト・タイプ・モデルと、メディエータ・サービス・コンポーネントとビジネス・ルール・サービス・コンポーネント間の規定の一部として必要な固定データ・モデルの一部が移入されます。

- ルールセット
ルールセットは、ルールのグループ化メカニズムとして使用されるルールのコンテナです。ルールセットはサービスとして公開できます。ビジネス・ルール・サービス・コンポーネントの作成過程で、1つのルールセットがルール・ディクショナリ内に作成されます。

- デシジョン表(またはマトリックス)
ルール・エンジンから見ると、デシジョン表は、ルールの条件およびアクション部分のファクト・タイプ・モデルの要素が同じであるルールの集合です。デシジョン表を使用すると、ルールを表形式で表示できます。ビジネス・ルール・サービス・コンポーネントの作成過程で、ルールセット内に新規デシジョン表が作成されます。

- デシジョン・サービス
デシジョン・サービスは、ビジネス・ルール・サービス・コンポーネントの作成過程で作成され、ルールセットをビジネス・ルール・サービス・コンポーネントのサービスとして公開します。メディエータ・サービス・コンポーネントでは、サービス・インタフェースを使用してデシジョン表を評価します。

20.3.3.2.2 デシジョン・コンポーネントを編集する手順:

1. 「ルーティングのオーバーライド」ダイアログ(図20-44 )で、「デシジョン・コンポーネント」フィールドの右側にある「デシジョン・コンポーネント・エディタを開く」アイコンをクリックします。図20-50 に示すようなデシジョン・コンポーネント・エディタが表示されます。

図20-50 デシジョン・コンポーネント・エディタ

2. 「デシジョン表」の下で、デシジョン表を選択し、「編集」をクリックし、デシジョン表を編集します。
デシジョン表とビジネス・ルールの使用の詳細は、「Oracle Business Rulesのスタート・ガイド」を参照してください。

20.3.3.3 既存の動的ルーティング・ルールの削除方法

DVMまたはデシジョン・コンポーネントに基づくルーティング・ルール・オーバーライドを削除できます。

動的ルーティング・ルール・オーバーライドを削除する手順は、次のとおりです。

1. メディエータ・コンポーネントをダブルクリックして、メディエータ・エディタを開きます。

2. 「ルーティング・ルール」セクションの下で、変更するルーティング・ルールまで下にスクロールします。

3. 「次を使用してオーバーライド」フィールドの右側で、緑色の矢印で識別されるボタンをクリックします。図20-48 に、「次を使用してオーバーライド」フィールドを示します。

「ルーティングのオーバーライド」ダイアログが表示されます。

4. 「オーバーライドの削除」を選択して、任意の静的ルーティング・ルール・オーバーライドを削除します。

5. 「OK」をクリックします。

20.3.4 動的ルーティング・ルールの使用に関する必知事項

メディエータで動的ルーティング・ルールを使用する場合は、次の制限に注意してください。

- すべての指定可能メッセージ・パターン(同期、非同期、同期-非同期および一方向)がサポートされています。

- イベントのパブリッシャおよびエコーは、関連付けられた動的ルーティング・ルールを持つことができません。

- 静的ルール・オーバーライドはリクエストに対してのみ適用されますが、レスポンスには適用されません。レスポンスをオーバーライドする必要がある場合、別のメディエータにルーティングし、リクエストとしてオーバーライドする必要があります。

- ターゲット・ポートをオーバーライドする場合、オーバーライドするポートは同じポート・タイプである必要があります。

20.3.5 デフォルト・ルーティング・ルールの定義方法

メディエータでは、ルーティング・ルールで指定された条件に従ってメッセージが処理されます。ルーティング・ルールで指定されたいずれの条件も満たさないために、受信メッセージが処理されない場合もあります。このようなメッセージに使用するデフォルト・ルーティング・ルールを定義できます。デフォルト・ルーティング・ルールは、他のルーティング・ルールの条件がいずれも満たされない場合に実行されます。

デフォルト・ルーティング・ルールは、「静的ルーティング・ルールの作成方法」で説明したルーティング・ルールと同じです。デフォルト・ルーティング・ルールが他のルーティング・ルールと異なる唯一の点は、デフォルト・ルーティング・ルールには関連する条件がないことです。それ以外は、ターゲット・サービス、レスポンス処理、フォルト処理などすべてにおいて、デフォルト・ルーティング・ルールは他のルーティング・ルールと同じです。

注意:

- デフォルト・ルールは、静的ルーティング・ルールに対してのみ使用できます。

- 動的ルーティング・ルールを使用するメディエータ・サービス・コンポーネントにデフォルト・ルーティング・ルールを指定することはできません。これは、同じメディエータ・サービス・コンポーネントに静的ルーティング・ルールと動的ルーティング・ルールの両方を定義することはできないためです。

20.3.5.1 デフォルト・ルールのシナリオ

デフォルト・ルーティング・ルールは、順次ルールまたはパラレル・ルールのいずれかに設定できます。順次またはパラレルに関係なく、デフォルト・ルーティング・ルールは、他のルーティング・ルールの条件が満たされない場合に実行されることが保証されています。デフォルト・ルールが実行された場合、メディエータの監査証跡には、すべてのルーティング・ルールのフィルタ条件が満たされず、デフォルト・ルーティング・ルールのフィルタ条件が満たされて実行されたことが示されます。次の例に詳細を示します。

ActivityJan 7, 2010 4:35:15 PM
Message onCase "fileout2.Write"
Jan 7, 2010 4:35:15 PM
Message Evaluation of xpath condition " No Filter (DEFAULT CASE) " resulted
true

デフォルト・ルーティング・ルールも含めて、すべてのルーティング・ルールは順次またはパラレルのルーティング・ルールとして定義できるため、想定されるルーティング・ルールの動作は多数あります。次の各項では、各組合せと想定される動作について説明します。

順次のデフォルト・ルーティング・ルール

順次のデフォルト・ルーティング・ルールでは、次のシナリオが考えられます。

- メディエータの他のルーティング・ルールがすべて順次の場合: これは、デフォルト・ルーティング・ルールも含めて、すべてのルーティング・ルールのタイプが順次である最も単純なケースです。すべてのルーティング・ルールのフィルタ条件が実行時に評価され、いずれのフィルタ条件も一致しない場合は、順次のデフォルト・ルーティング・ルールが実行されます。順次のデフォルト・ルーティング・ルールは、受信メッセージと同じトランザクションで実行されます。デフォルト・ルールの実行後に、事後Javaコールアウトが発生します。

- メディエータのルーティング・ルールの少なくとも1つがパラレルである場合: これは、デフォルト・ルーティング・ルールが順次であり、他のルーティング・ルールの少なくとも1つがパラレルである複雑なケースです。実行時のデフォルトの動作では、最初に順次ルーティング・ルールがすべて実行された後で、パラレルのルーティング・ルールが実行されます。したがって、デフォルト・ルールは、他のすべてのルーティング・ルールがfalseであると評価された後でのみ実行する必要があるため注意が必要です。
この場合、サーバーでは、最初にパラレル・ルールのフィルタ条件が評価された後でデフォルト・ルーティング・ルールのフィルタ条件が評価されます。他のいずれのフィルタ条件も一致しない場合は、順次のデフォルト・ルーティング・ルールが実行されます。

パラレルのデフォルト・ルーティング・ルール

パラレルのデフォルト・ルーティング・ルールでは、次のシナリオが考えられます。

- メディエータの他のルーティング・ルールがすべてパラレルの場合: これは簡単なケースです。デフォルト・ルーティング・ルールは、他のルーティング・ルールで指定されたいずれかのフィルタ条件が一致する場合は実行されません。フィルタ条件がいずれも一致しない場合は、デフォルト・ルーティング・ルールが非同期で実行されます。

- メディエータの他のルーティング・ルールが順次またはパラレルである場合: これは複雑ですが一般的なユースケースです。使用可能な他の順次またはパラレルのルーティング・ルールがあり、デフォルト・ルーティング・ルールがパラレルの場合です。デフォルト・ルーティング・ルールは、他の順次またはパラレルのルーティング・ルール基準のいずれかが一致した場合は実行されません。条件がいずれも一致しない場合は、デフォルト・ルーティング・ルールが非同期で実行されます。

注意:

デフォルト・ルーティング・ルールが自動的に実行されるということは、デフォルト・ルーティング・ルールが、特定のメディエータ・サービス・コンポーネントに対して実行された唯一のケースであることを意味します。同様に、メディエータ・サービス・コンポーネントに、フィルタ条件が指定されていない1つのルーティング・ルールがあり、デフォルト・ルーティング・ルールもある場合、そのデフォルト・ルーティング・ルールが実行されることはありません。

20.3.5.2 デフォルト・ルールのターゲット

デフォルト・ルーティング・ルールのターゲットは、他の既存ルーティング・ルールのサポートされているターゲットと同じです。つまり、ターゲットにはサービス、イベントまたはエコーを設定できます。同様に、デフォルト・ルーティング・ルールのターゲット・サービスからのレスポンスは、コール元に転送するか、返すことができます。ターゲット・サービスからフォルトが返された場合は、他のルーティング・ルールで処理される場合と同様に処理されます。

注意:

他のルーティング・ルールの評価または実行時に例外が発生した場合、デフォルト・ルーティング・ルールは実行されません。

20.3.5.3 デフォルト・ルール: 検証、トランスフォーメーションおよび割当て機能

デフォルト・ルーティング・ルールのSchematron検証、トランスフォーメーションおよび割当機能は、他のルーティング・ルールと同様に動作します。

20.3.5.4 デフォルト・ルール: Javaコールアウト

事前Javaコールアウトまたは事後Javaコールアウトの現在の動作は、他のルーティング・ルールの場合と同様です。Javaコールアウト場合は、デフォルト・ルーティング・ルールは別のルーティング・ルールとみなされます。したがって、デフォルト・ルーティング・ルールが実行されるシナリオの場合、postRouting()コールバック・メソッドは、デフォルト・ルーティング・ルールが実行された後でのみ発生します。

注意:

事後Javaコールアウトは、順次ルールの実行後に発生し、パラレル・ルールの実行の完了は待機しません。したがって、デフォルト・ルーティング・ルールが順次の場合、postRouting()コールバック・メソッドは、デフォルト・ルーティング・ルールの実行後に発生します。デフォルト・ルーティング・ルールがパラレルの場合、postRouting()コールバックは、すべての順次ルールが実行された後に発生し、パラレルのデフォルト・ルーティング・ルールの実行は待機しません。

20.3.5.5 デフォルト・ルール: メディエータ.mplanファイル

ルーティング・ルールをデフォルト・ルーティング・ルールとして設定するには、図20-2 に示す「デフォルト・ルーティング・ルールとして設定」アイコンをクリックします。.mplanファイルは、図20-51 に示すように変わります。

図20-51 デフォルト・ルーティング・ルールが設定されたメディエータの.mplanファイル

20.4 メディエータ・ルーティングのユースケース

2つのチュートリアルが入手可能であり、それらでは、Oracle SOA Suiteサンプル・ページで提供されているメディエータ・サンプル・プロジェクトのうちの2つを作成する手順を示しています。作成したメディエータにルーティング・ルールを定義する方法を説明しています。それらのチュートリアルは、http://java.net/projects/oraclesoasuite11g/downloads/download/Mediator/Tutorials/med_rr_tutorial.pdfからダウンロードできます。

21 Oracle Mediatorにおける複数パート・メッセージの使用

この章では、サービス・コンポーネント用の複数パート(マルチパート)メッセージのルーティング・ルール(フィルタやトランスフォーメーション、検証など)を定義する方法について説明します。

この章の内容は次のとおりです。

- メディエータのマルチパート・メッセージ・サポートの概要

- マルチパートのリクエスト・メッセージの使用

ルーティング・ルールの詳細は、「Oracle Mediatorルーティング・ルールの作成」を参照してください。

21.1 メディエータのマルチパート・メッセージ・サポートの概要

メディエータには、マルチパートのソース・メッセージとターゲット・メッセージの操作のサポートが組み込まれており、この操作には、マルチパートのフィルタ式の作成、マルチパートのスキーマ検証およびリクエスト、リプライ、フォルト、コールバック用のマルチパートのソース・メッセージとターゲット・メッセージ間のトランスフォーメーションが含まれます。

メディエータ・エディタでマルチパートのソースは、図21-1 のように表示されます。

図21-1 マルチパートのソースに対するメディエータ・エディタ

21.2 マルチパートのリクエスト・メッセージの使用

この項では、様々なタイプのマルチパート・メッセージの使用方法について説明します。

21.2.1 マルチパートのリクエスト・メッセージに対するフィルタ式の指定方法

マルチパートのメッセージに対してフィルタ式を指定すると、図21-2 に示すように、式ビルダーには、in変数の下にすべてのメッセージ・パートが表示されます。

図21-2 マルチパートのリクエストのソースに対する式ビルダー

21.2.2 マルチパートのリクエスト・メッセージに対する検証の追加方法

マルチパートのメッセージに対して検証を追加すると、図21-3 に示すように、「検証の追加」ダイアログにパートを選択できるパート・リストが表示されます。リクエスト・メッセージ・パートごとにSchematronファイルを指定します。次に、Oracle Mediatorでは、パートに対応するSchematronファイルが処理されます。

図21-3 マルチパートのリクエストのソースに対する「検証の追加」ダイアログ

21.2.3 マルチパートのリクエスト・メッセージに対するトランスフォーメーションの作成方法

マルチパートのメッセージに対して新しいマッパー・ファイルを作成すると、図21-4 に示すように、XSLTマッパーでは、生成されたマッパー・ファイルに複数のソース・パートが表示されます。

図21-4 マルチパートのリクエストのソースに対するXSLTマッパー

21.2.4 マルチパートのリクエスト・メッセージに対する値の割当て方法

ソース式を使用して値を割り当て、「値の割当て」ダイアログから式ビルダーを起動すると、式ビルダーには、in変数の下にすべてのメッセージ・パートが表示されます(図21-2 を参照)。これは、フィルタ式を指定した場合と同じです。

21.2.5 マルチパートのリプライ、フォルトおよびコールバック用ソース・メッセージの使用方法

トランスフォーメーションの作成方法、およびマルチパートのリプライ、フォルト、コールバック用ソース・メッセージへの値の割当て方法は、リクエスト用ソース・メッセージの場合と同じです。

注意:

リプライ、フォルトおよびコールバック用の各メッセージに対しては、フィルタ式の指定や検証の追加はできません。

21.2.6 マルチパートのターゲット・メッセージの使用方法

ルーティングのターゲット(つまり、リクエスト、リプライ、フォルトまたはコールバック)にマルチパートのメッセージがある場合、トランスフォーメーションは多少異なる方法で処理されます。これは、XSLTマッパーではマルチパートのターゲットがサポートされていないためです。このような場合は、図21-5 に示すように、メディエータによって、ターゲット・パートごとに別々のマッパー・ファイルが作成されて調整されます。

図21-5 マルチパートのルーティングのターゲットに対するリクエスト・トランスフォーメーション・マップ

22 Oracle Mediatorエラー処理の使用

この章では、Oracle Mediatorのエラー処理機能について説明し、ビジネス・フォルトとシステム・フォルトの両方のエラー処理を定義する手順を示します。

この章の内容は次のとおりです。

- メディエータのエラー処理の概要

- メディエータによるエラー処理の使用

- Oracle Enterprise Manager Fusion Middleware Controlを使用したフォルト・リカバリ

- XMLスキーマ定義ファイルのエラー処理

22.1 メディエータのエラー処理の概要

メディエータに用意されている高度なエラー処理機能を使用すると、エラーの発生とそれに対応する修正アクション用のメディエータ・サービス・コンポーネントを構成できます。エラー処理によって、メディエータはメッセージ処理中に発生するエラーや外部のWebサービスから戻される例外を処理できます。メディエータでは、ビジネス・フォルトとシステム・フォルトの両方を処理できます。

ビジネス・フォルトはアプリケーション固有のフォルトであり、サービスWSDLファイルで明示的に定義されます。設計時にOracle JDeveloperでフォルト・ハンドラを定義することでビジネス・フォルトを処理できます。システム・フォルトは、ネットワークが利用できないような基本システムにおける問題によって発生します。メディエータでは、システム・フォルト用のフォルト・ポリシーをベースとしたエラー処理を提供します。

フォルト・ポリシーにより、エラーを自動または管理者操作で処理できるようになります。メディエータのフォルト・ポリシーをベースとしたエラー処理は、次の3つのコンポーネントで構成されています。

- フォルト・ポリシー

- フォルト・バインディング

- エラー・グループ

22.1.1 フォルト・ポリシー

フォルト・ポリシーは、エラー状態および対応するアクションを定義したものです。フォルト・ポリシーは、「fault-policies.xmlのスキーマ定義ファイル」に示すXMLスキーマに基づいて作成したfault-policies.xmlファイルで定義します。

順次ルーティング・ルールのフォルト・ポリシーは、次に示すようにパラレルのルーティング・ルールの場合とは異なる方法で処理されます。

- 順次ルーティング・ルールがシングル・スレッド処理であるため、エラー処理に対して3つのアクション(中断、再スロー、およびJava)のみがサポートされており、指定されたアクションがコール元のスレッドでただちに実行されます。

- メディエータ・メッセージは、順次ルーティングで保持されません。

- 非同期および一方向メディエータ・コンポーネントは、BPELビジネス・プロセスなど他のSOA Suiteコンポーネントからスローされるシステム・フォルトを処理できません。

使用可能なエラー処理アクションの詳細は、「アクション」を参照してください。

注意:

次の場合は、フォルト・ポリシーはサポートされません。

- コールバックの実行失敗

- フォルト・ハンドラ・アクションの失敗

- 再シーケンサの失敗

フォルト・ポリシー・ファイルのサンプルを次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies>
<faultPolicy version="2.0.1" id="CRM_ServiceFaults">
<Conditions>
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
name="medns:mediatorFault">
<condition>
<test>contains($fault.mediatorErrorCode, "TYPE_FATAL_MESH")</test>
<action ref="ora-retry"/>
</condition>
</faultName>
</Conditions>
<Actions>
<Action id="ora-retry">
<retry>
<retryCount>3</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
<retryFailureAction ref="ora-java"/>
<retrySuccessAction ref="ora-terminate"/>
</retry>
</Action>
</Actions>
</faultPolicy>
</faultPolicies>

次の各項では、フォルト・ポリシーの2つのコンポーネント(条件とアクション)について説明します。

22.1.1.1 条件

条件によって、エラーまたはフォルト条件を識別し、特定のエラーやフォルト条件が発生した際に、実行するアクションを指定できます。たとえば、サービスを利用できないことで発生する特定のエラーに対しては、再試行などを実行できます。同様に、Schematron検証に失敗して発生するエラーに対しては、管理者操作のアクションを実行できます。このフォルトは、Oracle Enterprise Manager Fusion Middleware Controlを使用して、ペイロードを編集して再送信することによって手動でリカバリできます。

条件は、次の例に示すようにfault-policies.xmlファイルに定義されます。

<Conditions>
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
name="medns:mediatorFault">
<condition>
<test>contains($fault.mediatorErrorCode,"TYPE_DATA_TRANSFORMATION")</test>
<action ref="ora-java"/>
</condition>
</faultName>
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
name="medns:mediatorFault">
<condition>
<test>contains($fault.mediatorErrorCode, "TYPE_FATAL_MESH")</test>
<action ref="ora-retry"/>
</condition>
</faultName>
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
name="medns:mediatorFault">
<condition>
<test>contains($fault.mediatorErrorCode,"TYPE_DATA_ASSIGN")</test>
<action ref="ora-retry-crm-endpoint"/>
</condition>
</faultName>
</Conditions>

条件を使用したフォルト・タイプの識別

条件を使用して取得可能なフォルトは、次のタイプに分類できます。

- メディエータ固有のフォルト
すべてのメディエータ固有のフォルトに対して、メディエータ・サービス・エンジンは1つのフォルト({http://schemas.oracle.com/mediator/faults}mediatorFault)のみをスローします。すべてのメディエータ・フォルトがこのフォルトにラップされています。メディエータによって生成されたエラーまたはフォルトは、次の例に示す形式を使用して取得できます。

<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault">
<!-- mediatorFault is a bucket for all the mediator faults -->
<condition>
<test>
contains($fault.mediatorErrorCode, "TYPE_FATAL_MESH")
</test>
<!-- Captures TYPE_FATAL_MESH errors -->
<action ref="ora-retry"/>
</condition>
</faultName>

- ビジネス・フォルトおよびSOAPフォルト
エラーまたはフォルトは、フォルト・ペイロードに基づいたXPath条件を定義することで取得できます。次の例に詳細を示します。

<faultName xmlns:ns1="http://xmlns.oracle.com/Customer"
name="ns1:InvalidCustomer"> <!-- Qname of Business/SOAP fault -->
<condition>
<test>
contains($fault.<PART_NAME>/custid, 1011)
</test>
<!-- xpath condition based on fault payload -->
<action ref="ora-retry"/>
</condition>
</faultName>

参照サービスがビジネス・フォルトを返した場合、そのフォルトはメディエータ・サービス・コンポーネントで処理できます。返されたフォルトは別のコンポーネントに転送したり、ファイル・アダプタなどのアダプタ・サービスにリダイレクトできます。また、イベントを発生させることもできます。ただし、ビジネス・フォルトに対してフォルト・ポリシーとフォルト・ハンドラの両方が定義されている場合は、フォルト・ポリシーがフォルト・ハンドラより優先されます。この場合、フォルト・ポリシーが正常に実行されると、メディエータ・サービス・コンポーネント内のフォルト・ハンドラは無視されます。

- アダプタ固有のフォルト
アダプタによって生成されたエラーまたはフォルトは、次の例に示す形式を使用して取得できます。

<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault">
<condition>
<test>$fault.faultCode = "1"</test> <!-- unique constraint violation in DB adapter-->
<action ref="ora-retry"/>
</condition>
</faultName>

22.1.1.2 アクション

アクションは、エラー発生時に実行するタスクを指定します。メディエータは、パラレルのルーティング・ルールに対する再試行、管理者操作、中断、Javaコードの各アクションをサポートしています。順次ルーティング・ルールの場合、フォルト・ポリシーに、中断、再スロー、およびJavaコードのアクションを含めることができます。

順次ルーティング・ルールで再試行または管理者操作アクションが選択されている場合、フォルトは直接コール元に戻され、ポリシーは適用されません。互換性がないアクションが選択されていた場合は、それがログに記録されます。これは、BPELフォルト・ポリシーの動作と一貫しています。フォルトの処理はコール元が担当します。コール元がアダプタの場合は、拒否ハンドラをインバウンド・アダプタに定義して、エラーになったメッセージ(拒否メッセージ)を処理できます。拒否ハンドラの詳細は、『テクノロジ・アダプタの理解』を参照してください。

フォルト・ポリシー・アクションについては、後続の各項で説明します。

22.1.1.2.1 再試行アクション

停止したJMSキューへのメッセージのエンキューや一意キー制約エラーがあるレコードの挿入などの再試行アクションを使用すると、エラーの原因となったタスクを再試行できます。新規スレッドが各再試行アクションとともに開始されます。したがって、各再試行アクションでは、新規トランザクションが開始されます。表22-1 に、再試行アクションに使用可能なオプションを示します。再試行アクションの適用対象は、パラレルのルーティング・ルールのみです。

表22-1 再試行アクションのオプション

オプション

説明

再試行数

N回再試行します。

再試行間隔

再試行を秒単位で遅延します。

指数関数的バックオフ

指数バックオフを使用して再試行間隔を増加します。

再試行失敗アクション

N回の再試行に失敗した場合は、このアクションにチェーンします。

再試行成功アクション

再試行に成功した場合は、このアクションにチェーンします。

注意:

指数バックオフでは、次の再試行が2倍のdelayでスケジュールされます。ここでのdelayは、現在の再試行間隔です。たとえば、現在の再試行間隔が2秒の場合、次の再試行間隔は4秒にスケジュールされ、その次は8秒、16秒と、retryCount値に達するまで増分されます。

次の例は、再試行アクションの指定方法を示しています。

<Action id="ora-retry">
<retry>
<retryCount>3</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
<retryFailureAction ref="ora-java"/>
<retrySuccessAction ref="ora-java"/>
</retry>
</Action>

フォルト・ポリシーの再試行間隔に30秒未満の期間を設定すると、指定した間隔内に再試行が実行されない場合があります。これは、org.quartz.scheduler.idleWaitTimeプロパティのデフォルト値が30秒であり、スケジューラがアイドル状態の場合でも、使用可能なトリガーを再試行するまでに30秒待機するためです。再試行間隔を30秒未満の値に設定した場合は、待機時間が発生する可能性があります。

30秒未満の再試行間隔を使用する場合は、fabric-config-core.xmlファイルのセクション<property name="quartzProperties">の下に次のプロパティを追加します。

org.quartz.scheduler.idleWaitTime=<value>

22.1.1.2.2 再スロー・アクション

再スローは、コール元のスレッドでフォルト・ポリシーを実行し、元の例外をユーザーに返します。

再スロー・アクションの例を次に示します。

<Action id="ora-rethrow-fault"><rethrowFault/></Action>

22.1.1.2.3 管理者操作アクション

管理者操作アクションによって、エラーを訂正し(たとえば、ペイロードを変更し)、手動でメッセージを再試行することでフォルトを手動でリカバリできます。このアクションは、パラレルのルーティング・ルールにのみ適用できます。

管理者操作アクションの例を、次に示します。

<Action id="ora-human-intervention"><humanIntervention/></Action>

22.1.1.2.4 中断アクション

中断アクションによって、メッセージ・フローを終了することができます。このアクションは、パラレルと順次の両方のルーティング・ルールに適用できます。

中断アクションを順次ルーティング・ルールに対して実行すると、例外FabricInvocationExceptionが、コール元にスローされ、メディエータ・コンポーネントの状態が終了に変わります。フォルト・ポリシーは、コール元のスレッド内で実行されます。

中断アクションの例を、次に示します。

<Action id="ora-terminate"><abort/></Action>

22.1.1.2.5 Javaコード・アクション

Javaコードアクションにより、oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClassインタフェースを実装するカスタマイズJavaクラスをコールできます。このアクションは、パラレルと順次の両方のルーティング・ルールに適用できます。次の例は、Javaコード・アクションの実装方法を示しています。

注意:

実装済Javaクラスは、文字列を戻すメソッドを実装している必要があります。ポリシーは、戻された文字列に基づいて新しいアクションにチェーンできます。

Javaコード・アクションは、最初に、ドメイン・クラス・ライブラリ内の実装済クラスを検索します。そこでクラスが見つからない場合は、コンポジット・アプリケーションのクラス・ライブラリが検索されます。

<Action id="ora-java">
<javaAction className="mypackage.myClass" defaultAction="ora-terminate">
<returnValue value="ABORT" ref="ora-terminate"/>
<returnValue value="RETRY" ref="ora-retry"/>
<returnValue value="MANUAL" ref="ora-human-intervention"/>
</javaAction>
</Action>

順次ルーティング・ルール・フォルト・ポリシーの場合、returnValueアクションは、中断、再スロー、またはJavaアクションの1つである必要があります。returnValueが、これらの有効な値以外である場合、defaultActionがチェックされます。defaultActionも有効なアクション(中断、再スロー、またはJavaアクション)でない場合、デフォルトではアクションは実行されず、元のフォルトがコール元にスローされます。

oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass {

public void handleRetrySuccess(IFaultRecoveryContext ctx);
public String handleFault(IFaultRecoveryContext ctx);
}

public interface IFaultRecoveryContext {

/**
* Gets implementation type of the fault.
* @return
*/
public String getType();

/**
* @return Get property set of the fault policy action being executed.
*/
public Map getProperties();

/**
* @return Get fault policy id of the fault policy being executed.
*/
public String getPolicyId();

/**
* @return Name of the faulted reference.
*/
public String getReferenceName();

/**
* @return Port type of the faulted reference link.
*/
public QName getPortType();
}

メディエータ・サービス・エンジンの実装

次の例は、IFaultRecoveryContextインタフェースのOracle Mediatorサービス・エンジンの実装を示しています。

package oracle.tip.mediator.common.error.recovery;
public class MediatorRecoveryContext implements IFaultRecoveryContext{
...
}

次の例に示すメソッドを使用すると、MediatorRecoveryContextクラスで使用可能なメディエータ固有の追加データを取得できます。

public CommonFault getACommonFault()
public CalloutMediatorMessage getMediatorMessage()

次の例は、CalloutMediatorMessageインタフェースを使用したデータの取得方法を示しています。

/**
* Accessing Mediator Message properties by providing the property name
* @param propertyName
* @return
* @throws MediatorException
*/
public Object getProperty(String propertyName);

/**
* Accessing Mediator Message properties
* @return
* @throws MediatorException
*/
public Map getProperties();

/**
* Accessing instance id of the mediator message
* This will be the mediator instance id created for that particular message
* object
* @return
* @throws MediatorException
*/
public String getId() throws MediatorException;

/**
* Accessing payload of the mediator message
* object
* @return
* @throws MediatorException
*/
public Map getPayload();

/**
* Accessing header of the mediator message
* object
* @return
* @throws MediatorException
*/
public List<Element> getHeaders();

/**
* Accessing componentDN for mediator component
* @return
* @throws MediatorException
*/
public String getComponentDN(
/**
* Setting payload to the mediator message
* @return
* @throws MediatorCalloutException
*/
public void addPayload(String partName,Object payload) throws MediatorCalloutException;

/**
* Adding property to the mediator message
* @return
* @throws MediatorCalloutException
*/
public void addProperty(String name,Object value) throws MediatorCalloutException;

/**
* Adding header to the mediator message
* @return
* @throws MediatorCalloutException
*/
public void addHeader(Object header) throws MediatorCalloutException;

22.1.2 フォルト・バインディング

フォルト・バインディングは、フォルト・ポリシーをコンポジットまたはコンポーネントと関連付けるもので、fault-bindings.xmlファイルで定義されています。fault-bindings.xmlファイルは、「fault-bindings.xmlのスキーマ定義ファイル」で定義されているXMLスキーマに基づいて作成します。

フォルト・ポリシーは次のレベルで作成できます。

- コンポジット: コンポジット内のすべてのメディエータ・コンポーネントに対してフォルト・ポリシーを1つ定義できます。このレベルは、次の方法で指定できます。

<composite faultPolicy="ConnectionFaults"/>

- コンポーネント: メディエータ・サービス・コンポーネントに対するフォルト・ポリシーを排他的に定義できます。コンポーネント・レベルのフォルト・ポリシーは、コンポジット・レベルのフォルト・ポリシーをオーバーライドします。このレベルは、次の例に示すように、指定できます。

<component faultPolicy="ConnectionFaults">
<name>Component1</name>
<name>Component2</name>
</component>

- 参照: メディエータ・コンポーネントの参照に対するフォルト・ポリシーを定義できます。このレベルは、次の例に示すように、指定できます。

<reference faultPolicy="policy1">
<name>DBAdapter3</name>
</reference>

注意:

フォルト・ポリシーの優先順位のレベルは、参照、コンポーネント、コンポジットの順です。

注意:

管理者操作は、フォルト・ポリシーが定義されていないエラーに対するデフォルト・アクションです。

次の例は、フォルト・バインディング・ファイルのサンプルを示しています。

<?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">
<composite faultPolicy="ConnectionFaults"/>
</faultPolicyBindings>

22.1.3 メディエータのエラー・グループ

フォルト・ポリシーに条件を定義する一方で、エラー・タイプやエラー・グループにはアクションを指定できます。前述の例にあるmedns:mediatorFaultは、エラーがメディエータ・エラーであることを表しているのに対し、medns:TYPE_FATAL_MESHは、エラー・グループを表しています。エラー・グループは、1つ以上の子エラー・タイプで構成されています。TYPE_ALLは、すべてのメディエータ・エラーを含むエラー・グループです。

次のリストでは、TYPE_ALLエラー・グループに含まれる様々なエラー・グループについて説明します。

- TYPE_DATA: データ処理に関するエラーが含まれます。

- TYPE_DATA_ASSIGN: データの割当に関するエラーが含まれます。

- TYPE_DATA_FILTERING: データのフィルタ処理に関するエラーが含まれます。

- TYPE_DATA_TRANSFORMATION: トランスフォーメーション中に発生したエラーが含まれます。

- TYPE_DATA_VALIDATION: ペイロード検証中に発生したエラーが含まれます。

- TYPE_METADATA: メディエータのメタデータに関するエラーが含まれます。

- TYPE_METADATA_FILTERING: フィルタ処理の条件の処理中に発生したエラーが含まれます。

- TYPE_METADATA_TRANSFORMATION: トランスフォーメーション用のメタデータの取得中に発生したエラーが含まれます。

- TYPE_METADATA_VALIDATION: メディエータ用のメタデータ(.mplanファイル)の検証中に発生したエラーが含まれます。

- TYPE_METADATA_COMMON: メタデータの処理中に発生したその他のエラーが含まれます。

- TYPE_FATAL: 容易にリカバリできない致命的なエラーが含まれます。

- TYPE_FATAL_DB: Datasource not foundエラーなど、データベース関連の致命的なエラーが含まれます。

- TYPE_FATAL_CACHE: メディエータのキャッシュ関連の致命的なエラーが含まれます。

- TYPE_FATAL_ERRORHANDLING: Resubmission queues not availableなど、エラー処理中に発生した致命的なエラーが含まれます。

- TYPE_FATAL_MESH: Invoke service not availableなど、サービス・インフラストラクチャから発生した致命的なエラーが含まれます。

- TYPE_FATAL_MESSAGING: サービス・インフラストラクチャから発生した致命的なメッセージ・エラーが含まれます。

- TYPE_FATAL_TRANSACTION: Commit can't be called on a transaction which is marked for rollbackなど、トランザクションに関する致命的なエラーが含まれます。

- TYPE_FATAL_TRANSFORMATION: トランスフォーメーション時に使用するXPath関数によって発生したエラーなど、致命的なトランスフォーメーション・エラーが含まれます。

- TYPE_TRANSIENT: 再試行でリカバリできる一時エラーが含まれます。

- TYPE_TRANSIENT_MESH: サービス・インフラストラクチャに関するエラーが含まれます。

- TYPE_TRANSIENT_MESSAGING: エンキューやデキューなど、JMSに関するエラーが含まれます。

- TYPE_INTERNAL: 内部エラーが含まれます。

22.2 メディエータによるエラー処理の使用

Oracle Mediatorのエラー処理は、fault-policies.xmlおよびfault-bindings.xmlファイルを使用して有効にできます。

22.2.1 メディエータ・サービス・コンポーネントに対するエラー処理の使用方法

メディエータ・サービス・コンポーネントに対してエラー処理を使用する手順は、次のとおりです。

1. 「fault-policies.xmlのスキーマ定義ファイル」で定義されているスキーマに基づいて、fault-policies.xmlファイルを作成します。

2. 「fault-bindings.xmlのスキーマ定義ファイル」で定義されているXMLスキーマに基づいて、fault-bindings.xmlファイルを作成します。

3. fault-policies.xmlおよびfault-bindings.xmlファイルをSOAコンポジット・アプリケーション・プロジェクトのディレクトリにコピーします。

4. SOAコンポジット・アプリケーション・プロジェクトをデプロイします。

22.2.2 実行時の処理内容

コンポジットに対するフォルト・ポリシーはすべて、最初のエラーが発生したときにロードされます。エラーが発生した場合、メディエータ・サービス・エンジンによってフォルト・ポリシー・ファイル(fault-policies.xmlおよびfault-bindings.xml)が存在しているかどうかがチェックされます。フォルト・ポリシー・バインディングがチェックされ、そのコンポーネントまたはコンポジットと関連付けられているフォルト・ポリシーが判別されます。フォルト・ポリシーがコンポーネントまたはコンポジットと関連付けられている場合、メディエータによって、そのフォルト条件に対応したフォルト・ポリシーで定義されているアクションが実行されます。コンポーネントまたはコンポジットに対してフォルト・ポリシー・バインディングが見つからない場合、アクションは実行されず、動作はフォルト・ポリシーが存在しない場合と同じになります。

定義されているフォルト・ポリシーがなく、ルーティング・ルールが平行して実行される場合、管理者操作のデフォルト・アクションが実行されます。定義されているフォルト・ポリシーがなく、ルーティング・ルールが順次実行される場合、コール元にエラーがスローされます。

注意:

エラーが発生した順次ルーティング・トランザクションはすべて、フォルト・ポリシーがそのエラーの処理に使用された場合でも、ロールバックされます。

フォルト・ポリシーの処理方法の詳細は、「アクション」を参照してください。

22.3 Oracle Enterprise Manager Fusion Middleware Controlを使用したフォルト・リカバリ

フォルト・ポリシー・ファイルを使用するポリシーベースのリカバリとは別に、Oracle Enterprise Manager Fusion Middleware Controlでは、リカバリ可能として識別されたOracle Mediatorフォルトに対して、フォルト・リカバリ・アクションを実行することもできます。次のうちの任意の方法を使用して、フォルトをリカバリします。

- Oracle Enterprise Manager Fusion Middleware Controlを使用してペイロードを変更する手動リカバリ

- Oracle Enterprise Manager Fusion Middleware Controlを使用してペイロードを変更しないバルク・リカバリ

- Oracle Enterprise Manager Fusion Middleware Controlを使用した、失敗したインスタンスの強制終了(インスタンスの処理を続行しない場合)。
Oracle Enterprise Manager Fusion Middleware Controlを使用してフォルトをリカバリする方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

22.4 XMLスキーマ定義ファイルのエラー処理

この項では、fault-policies.xmlおよびfault-bindings.xmlファイルのスキーマ・ファイルについて説明します。

22.4.1 fault-policies.xmlのスキーマ定義ファイル

fault-policies.xmlファイルは、次の例に示すように、XSDファイルに基づいている必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:tns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<!-- Conditions contain a list of fault names -->
<xs:element name="Conditions">
<xs:complexType>
<xs:sequence>
<xs:element name="faultName" type="tns:faultNameType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- action Ref must exist in the same file -->
<xs:complexType name="actionRefType">
<xs:attribute name="ref" type="xs:string" use="required"/>
</xs:complexType>
<!-- one condition has a test and action, if test is missing, this is the
catch all condition -->
<xs:complexType name="conditionType">
<xs:all>
<xs:element name="test" type="tns:idType" minOccurs="0"/>
<xs:element name="action" type="tns:actionRefType"/>
</xs:all>
</xs:complexType>
<!-- One fault name match contains several conditions -->
<xs:complexType name="faultNameType">
<xs:sequence>
<xs:element name="condition" type="tns:conditionType"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:QName"/>
</xs:complexType>
<xs:complexType name="ActionType">
<xs:choice>
<xs:element name="retry" type="tns:RetryType"/>
<xs:element ref="tns:rethrowFault"/>
<xs:element ref="tns:humanIntervention"/>
<xs:element ref="tns:abort"/>
<xs:element ref="tns:replayScope"/>
<xs:element name="javaAction" type="tns:JavaActionType">
<xs:key name="UniqueReturnValue">
<xs:selector xpath="tns:returnValue"/>
<xs:field xpath="@value"/>
</xs:key>
</xs:element>
</xs:choice>
<xs:attribute name="id" type="tns:idType" use="required"/>
</xs:complexType>
<xs:element name="Actions">
<xs:annotation>
<xs:documentation>Fault Recovery Actions</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="Action" type="tns:ActionType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="JavaActionType">
<xs:annotation>
<xs:documentation>This action invokes java code
provided</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="returnValue" type="tns:ReturnValueType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="className" type="tns:idType" use="required"/>
<xs:attribute name="defaultAction" type="tns:idType" use="required"/>
<xs:attribute name="propertySet" type="tns:idType"/>
</xs:complexType>
<xs:complexType name="RetryType">
<xs:annotation>
<xs:documentation>This action attempts retry of activity
execution</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element ref="tns:retryCount"/>
<xs:element ref="tns:retryInterval"/>
<xs:element ref="tns:exponentialBackoff" minOccurs="0"/>
<xs:element name="retryFailureAction"
type="tns:retryFailureActionType" minOccurs="0"/>
<xs:element name="retrySuccessAction"
type="tns:retrySuccessActionType" minOccurs="0"/>
</xs:all>
</xs:complexType>
<xs:simpleType name="idType">
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="ReturnValueType">
<xs:annotation>
<xs:documentation>Return value from java code can chain another action
using
return values</xs:documentation>
</xs:annotation>
<xs:attribute name="value" type="tns:idType" use="required"/>
<xs:attribute name="ref" type="xs:string" use="required"/>
</xs:complexType>
<xs:element name="exponentialBackoff">
<xs:annotation>
<xs:documentation>Setting this will cause retry attempts to use
exponentialBackoff algorithm</xs:documentation>
</xs:annotation>
<xs:complexType/>
</xs:element>
<xs:element name="humanIntervention">
<xs:annotation>
<xs:documentation>This action causes the activity to
freeze</xs:documentation>
</xs:annotation>
<xs:complexType/>
</xs:element>
<xs:element name="replayScope">
<xs:annotation>
<xs:documentation>This action replays the immediate enclosing
scope</xs:documentation>
</xs:annotation>
<xs:complexType/>
</xs:element>
<xs:element name="rethrowFault">
<xs:annotation>
<xs:documentation>This action will rethrow the
fault</xs:documentation>
</xs:annotation>
<xs:complexType/>
</xs:element>
<xs:element name="retryCount" type="xs:positiveInteger">
<xs:annotation>
<xs:documentation>This value is used to identify number of
retries</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="retryFailureActionType">
<xs:annotation>
<xs:documentation>This is the action to be chained if retry attempts
fail</xs:documentation>
</xs:annotation>
<xs:attribute name="ref" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="retrySuccessActionType">
<xs:annotation>
<xs:documentation>This is the action to be chained if retry attempts
is successful</xs:documentation>
</xs:annotation>
<xs:attribute name="ref" type="xs:string" use="required"/>
</xs:complexType>
<xs:element name="retryInterval" type="xs:unsignedLong">
<xs:annotation>
<xs:documentation>This is the delay in milliseconds of retry
attempts</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="abort">
<xs:annotation>
<xs:documentation>This action terminates the
process</xs:documentation>
</xs:annotation>
<xs:complexType/>
</xs:element>
<xs:element name="Properties">
<xs:annotation>
<xs:documentation>Properties that can be passes to a custom java
class</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="propertySet" type="tns:PropertySetType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="PropertySetType">
<xs:sequence>
<xs:element name="property" type="tns:PropertyValueType"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="tns:idType" use="required"/>
</xs:complexType>
<xs:complexType name="PropertyValueType">
<xs:simpleContent>
<xs:extension base="tns:idType">
<xs:attribute name="name" type="tns:idType" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="faultPolicy">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:Conditions"/>
<xs:element ref="tns:Actions"/>
<xs:element ref="tns:Properties" minOccurs="0"/>
<!--Every policy has on Conditions and and one Actions, however,
Properties is optional -->
</xs:sequence>
<xs:attribute name="id" type="tns:idType" use="required"/>
<xs:attribute name="version" type="xs:string" default="2.0.1"/>
</xs:complexType>
<xs:key name="UniqueActionId">
<xs:selector xpath="tns:Actions/tns:Action"/>
<xs:field xpath="@id"/>
</xs:key>
<xs:key name="UniquePropertySetId">
<xs:selector xpath="tns:Properties/tns:property_set"/>
<xs:field xpath="@id"/>
</xs:key>
<xs:keyref name="RetryActionRef" refer="tns:UniqueActionId">
<xs:selector xpath="tns:Actions/tns:Action/tns:retry/tns:retryFailureAction"/>
<xs:field xpath="@ref"/>
</xs:keyref>
<xs:keyref name="RetrySuccessActionRef" refer="tns:UniqueActionId">
<xs:selector
xpath="tns:Actions/tns:Action/tns:retry/tns:retrySuccessAction"/>
<xs:field xpath="@ref"/>
</xs:keyref>
<xs:keyref name="JavaActionRef" refer="tns:UniqueActionId">
<xs:selector
xpath="tns:Actions/tns:Action/tns:javaAction/tns:returnValue"/>
<xs:field xpath="@ref"/>
</xs:keyref>
<xs:keyref name="ConditionActionRef" refer="tns:UniqueActionId">
<xs:selector
xpath="tns:Conditions/tns:faultName/tns:condition/tns:action"/>
<xs:field xpath="@ref"/>
</xs:keyref>
<xs:keyref name="JavaDefaultActionRef" refer="tns:UniqueActionId">
<xs:selector xpath="tns:Actions/tns:Action/tns:javaAction"/>
<xs:field xpath="@defaultAction"/>
</xs:keyref>
<xs:keyref name="JavaPropertySetRef" refer="tns:UniquePropertySetId">
<xs:selector xpath="tns:Actions/tns:Action/tns:javaAction"/>
<xs:field xpath="@property_set"/>
</xs:keyref>
</xs:element>
<xs:element name="faultPolicies">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:faultPolicy" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

22.4.2 fault-bindings.xmlのスキーマ定義ファイル

fault-bindings.xmlファイルは、次の例に示すように、XSDファイルに基づいている必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:tns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="faultPolicyBindings">
<xs:annotation>
<xs:documentation>Bindings to a specific fault policy
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="composite" type="tns:compositeType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="component" type="tns:componentType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="reference" type="tns:referenceType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string" default="2.0.1"/>
</xs:complexType>
<xs:key name="UniquePartnerLinkName">
<xs:selector xpath="tns:reference/tns:name"/>
<xs:field xpath="."/>
</xs:key>
<xs:key name="UniquePortType">
<xs:selector xpath="tns:reference/tns:portType"/>
<xs:field xpath="."/>
</xs:key>
<xs:key name="UniquePolicyName">
<xs:selector xpath="tns:reference"/>
<xs:field xpath="@faultPolicy"/>
</xs:key>
</xs:element>
<xs:simpleType name="nameType">
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="propertyType">
<xs:simpleContent>
<xs:extension base="tns:nameType">
<xs:attribute name="name" type="xs:string" use="required"
fixed="faultPolicy"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>

<xs:complexType name="referenceType">
<xs:annotation>
<xs:documentation>Bindings for a partner link. Overrides composite
level binding.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:annotation>
<xs:documentation>Specification at partner link name overrides
specification for a port type</xs:documentation>
</xs:annotation>
<xs:element name="name" type="tns:nameType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="portType" type="xs:QName" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="faultPolicy" type="tns:nameType" use="required"/>
</xs:complexType>

<xs:complexType name="componentType">
<xs:annotation>
<xs:documentation>Binding for a component </xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="name" type="tns:nameType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="faultPolicy" type="tns:nameType" use="required"/>
</xs:complexType>
<xs:complexType name="compositeType">
<xs:annotation>
<xs:documentation>Binding for the entire composite</xs:documentation>
</xs:annotation>
<xs:attribute name="faultPolicy" type="tns:nameType" use="required"/>
</xs:complexType>
</xs:schema>

23 Oracle Mediatorにおける再順序付け

この章では、Oracle Mediatorにおけるメッセージの再順序付けの概念について説明し、標準の再順序付け、先入れ/先出し再順序付けおよびベスト・エフォート再順序付けを構成する手順を示します。

この章の内容は次のとおりです。

- 再シーケンサの概要

- 再順序付けの順序

- 再シーケンサの構成

23.1 再シーケンサの概要

メディエータの再シーケンサは、関連がありながらも順序が正しくないメッセージを適切な順序に並べ替えます。受信メッセージが到着すると、それらはランダムな順序になっています。リシーケンサは、順次または時系列の情報に基づきメッセージを順序付け、メッセージをターゲット・サービスに対して正しい手順で送信します。順序付けは、選択した順序付け戦略に基づき実行されます。

23.1.1 グループおよび順序ID

リシーケンサでは、グループと順序IDの2つの中心的な概念が使用されます。順序IDはメッセージの識別子の部分で、メッセージはこの識別子に基づいて再編成されます。再順序付けのために着信したメッセージは、複数のグループに分割され、各グループ内のメッセージは順序IDに従って順序付けされます。グループ内の順序付けは、他のグループのメッセージの順序とは独立して実行されます。グループ自体は相互に依存していないため、独立して処理できます。

たとえば、特定のグループに添付されているメッセージは、次の順序でメディエータ・サービス・コンポーネントに着信します。

msg9(a)、msg8(b)、msg7(a)、msg6(c)、msg5(a)、msg4(b)、msg3(c)、msg2(b)、msg1(a)

表23-1 に、メディエータがメッセージを複数のグループにソートする方法を示します。各グループ内のメッセージの順序は、使用している再シーケンサのタイプによって異なります。

表23-1 複数のグループにソートされるメッセージ

グループc

グループb

グループa

msg6(c)、msg3(c)

msg8(b)、msg4(b)、msg2(b)

msg9(a)、msg7(a)、msg5(a)、msg1(a)

すべてのグループは相互に独立して処理され、あるグループで発生したエラーが、他のグループの処理に影響を与えることはありません。

23.1.2 グループIDと順序IDの識別

グループIDと順序IDは、メッセージ・ペイロードおよびヘッダーのXPath式を介して識別されます。グループ化および順序付けが完了したメッセージ・ペイロードの要素を指し示すXPath式を指定します。

図23-1 に示すメッセージ・ペイロードでは、CustomerIdがインスタンス順序付けのベースとなるフィールドで、Typeがグループ化のベースとなるフィールドです。

図23-1 メッセージ・ペイロード

注意:

再順序付けは、同期操作ではサポートされません。

23.2 再順序付けの順序

メディエータでは、ユーザーが指定した順序で着信メッセージを再順序付けできます。この実装によって、3種類の再順序付けの順序を指定できます。

- 標準再シーケンサ

- FIFO再シーケンサ

- ベスト・エフォート再シーケンサ

23.2.1 標準再シーケンサ

標準再シーケンサは、標準再シーケンサ・パターンをサポートしています。次の各項では、標準再シーケンサおよびメッセージの処理方法について説明します。

23.2.1.1 標準再シーケンサの概要

標準再シーケンサは、メッセージ内の単純な識別子の連番から識別子を使用するアプリケーションに役立ちます。標準再シーケンサは一連のメッセージを受信しますが、これらのメッセージは順序に従って着信しない可能性があります。この場合、順序IDに基づいた完全な順序を受信するまで、メッセージは順不同で格納されます。正しい順序のメッセージは、そのメッセージの順序IDに基づいて非同期で処理されます。

標準再シーケンサであるメディエータ・サービス・コンポーネントのアウトバウンド・サービスへのメッセージは、順番に着信することが保証されている点に注意してください。

23.2.1.2 標準の再順序付けに必要な情報

メディエータの標準の再シーケンサを使用する場合は、常にグループXPath式と順序ID XPath式を指定する必要があります。これらは、メディエータの再シーケンサがメッセージでグループおよび順序IDを検索できる場所を指定します。また、開始順序IDと順序IDの増分デルタに関して順序番号を指定する必要があります。この番号付けは、各グループを形成する際に使用されます。グループ、順序IDおよび増分プロパティに加えて、予期されているメッセージを待機するタイムアウト時間(秒単位)を指定することもできます。

メディエータの標準再シーケンサでは、様々なグループに対して適切な順序を作成できるようになるまで、メディエータの再シーケンサ・データベースにメッセージが保持されます。この状況は、指定のグループについて、特定の順序IDのメッセージがタイムアウト時間内に着信しない場合は、そのグループの後続のメッセージが永久に保持されることを意味します。このような場合は、Oracle Enterprise Manager Fusion Middleware Controlを介してグループのロックを手動で解除して次のメッセージに進み、保留中のメッセージをスキップする必要があります。

23.2.1.3 標準再シーケンサの例

表23-2 に、複数のグループが、増分デルタの2つの異なる値に対してどのように形成されるかを示します。

表23-2 2つの異なる値に対する複数グループの形成

開始順序ID

増分デルタ

Group1

Group2

...

グループn

1

1

1,2,3,4,5,...

1,2,3,4,5,...

...

1、2、3、4、5、...n

1

5

1,5,10,15,...

1,5,10,15,...

...

1,5,10,15,...

注意:

様々なグループで順序番号が異なり(たとえば、各グループに同じ増分デルタまたは開始順序IDがない場合)、メッセージも正しい順序で着信しない場合は、メッセージを再編成するためにベスト・エフォート再シーケンサを使用できます。

23.2.2 FIFO再シーケンサ

FIFO再シーケンサは、標準の先入れ先出し(FIFO)パターンをサポートしています。次の各項では、FIFO再シーケンサおよびメッセージの処理方法について説明します。

23.2.2.1 FIFO再シーケンサの概要

FIFO再シーケンサは、メディエータへのメッセージの着信時刻に基づいて順序付けする必要があるアプリケーションに役立ちます。FIFO再シーケンサは、順序に従って一連のメッセージを受信し、メッセージの着信時刻に基づいて、各グループのメッセージを順に処理します。

FIFO再シーケンサとして機能するメディエータのアウトバウンド・サービスへのメッセージは、着信時刻に基づいて順に着信することが保証されている点に注意してください。したがって、メッセージは、再シーケンサ・データ・ストアに格納された順に配信されます。

23.2.2.2 FIFO再順序付けに必要な情報

FIFO再シーケンサを使用する場合は、常にグループXPath式を指定する必要があります。ただし、メッセージはFIFO再シーケンサとして構成されているメディエータ・サービス・コンポーネントへの着信時刻に従って処理されるため、順序IDを指定する必要はありません。グループXPath式では、FIFO再シーケンサがメッセージのグループ化のために、メッセージ内のグループ情報を検索する場所を指定します。FIFOパターンに必要な構成は他にはありません。

23.2.2.3 FIFO再シーケンサの例

表23-3 に、FIFO再シーケンサの動作を示します。msgX(Y,Z)は、メッセージがメディエータ・サービス・コンポーネントへのメッセージ番号Xとして着信し、そのメッセージにsequenceID YとグループZが格納されていることを意味します。

表23-3 FIFO 再シーケンサの動作

着信メッセージ

順序付けされたメッセージ

msg12(4,c)

msg05(9,a)

msg02(7,a)

msg10(3,c)

msg10(3,a)

msg07(5,a)

msg06(1,c)

msg03(2,c)

msg12(4,c)、msg10(3,c)、msg06(1,c)、msg03(2,c)

msg05(9,a)、msg02(7,a)、msg10(3,a)、msg07(5,a)

表23-3 に示すように、メッセージは着信時刻に基づいて順序付けされ、sequenceIDは順序付けに使用されません。

注意:

FIFO再シーケンサを使用する場合は、シングル・スレッドのインバウンド・アダプタを使用して不測の結果を回避してください。たとえば、FIFO再シーケンサとして構成されているメディエータ・サービス・コンポーネントの前で、ファイル/FTPアダプタ、データベース・アダプタまたはAQアダプタを使用する場合、シングル・スレッド処理のアダプタを構成してください。シングル・スレッド用に構成しないと、各メッセージの着信時刻がアダプタ・サービスへのメッセージ着信時ではなく、メディエータ・サービス・コンポーネントへの着信時に計算されるため、不測の結果が発生します。

23.2.3 ベスト・エフォート再シーケンサ

メディエータの再シーケンサは、ベスト・エフォート・パターンをサポートしています。次の各項では、ベスト・エフォート再シーケンサおよびメッセージの処理方法について説明します。

23.2.3.1 ベスト・エフォート再シーケンサの概要

短期間に多数のメッセージを生成し、順序付けに使用する識別子の情報を再シーケンサに提供できないアプリケーションには、ベスト・エフォート・パターンが役立ちます。通常、このようなシナリオで順序付けに使用される識別子は、dateTimeタイプまたはnumericタイプです。dateTimeフィールドを順序ID XPathとして使用すると、順序付けを制御できます。メッセージはアプリケーションから順に送信されることが想定されるため、メッセージの送信日時を使用して順序付けができます。メディエータは、メッセージが順序に従って配信されるように最善の方法を取ります。

ベスト・エフォート再シーケンサでは、順序IDの増分に関する認識に基づくことなくメッセージを並べ替えることができます。この状況は、標準再シーケンサとは異なり、ベスト・エフォート再シーケンサには、順序IDの増分を事前に定義する必要がないことを意味します。本来の順序を受信しても、メッセージの処理時には、メッセージは指定した順序IDと着信したメッセージに基づいて順に処理されます。順序IDは、numericまたはdateTimeのいずれかです。したがって、順序付けは、順序IDの数値またはdateTimeの順に発生します。

23.2.3.2 ベスト・エフォート再シーケンサ・メッセージ選択戦略

ベスト・エフォート再シーケンサは、2つのメッセージ選択方法である最大行数選択または時間ウィンドウのいずれかに基づいて、メッセージを非同期で処理します。同時に選択および処理されたメッセージは、指定する最大行数またはメッセージが着信する時間ウィンドウのいずれかに基づいて処理されます。

23.2.3.2.1 最大行数選択

ベスト・エフォート再シーケンサが最大行数を使用するように構成されていると、再シーケンサ・データベースで新しいメッセージが使用可能な場合は常に、次の手順が実行されます。

1. 再シーケンサは、指定した順序ID (通常は、日付およびタイム・スタンプ)に従ってメッセージを順序付けします。

2. 再シーケンサは、前述の順序付けメッセージからmaxRowsRetrievedパラメータの値と等しいメッセージ数をロックして選択します。

3. 再シーケンサは、選択したメッセージを自身のトランザクションで1つずつ順に処理します。

23.2.3.2.2 時間ウィンドウ

ベスト・エフォート再シーケンサが最大行数ではなく時間ウィンドウを使用するように構成されていると、一度に選択および処理するメッセージは、指定する一定の期間に加えてオプションのバッファ時間に基づいて処理されます。各メッセージは特定の時間ウィンドウに属し、ある時間ウィンドウにあるメッセージは異なる時間ウィンドウに属しているメッセージとは別に処理されます。

時間ウィンドウに加えてバッファ時間を指定できます。バッファ時間は、連続する2つの時間ウィンドウの重複部分で、最初の時間ウィンドウに関連するメッセージを少し後で着信させることができます。デフォルトでは、バッファ時間は指定した時間ウィンドウの10%です。

ベスト・エフォート再シーケンサが時間ウィンドウを使用するように構成されていると、グループは反復方法で処理され、メッセージは次の手順で処理されます。

1. 最初のメッセージが着信すると、タイム・ウィンドウが開始されます。

2. バッファが時間ウィンドウに追加され、バッファ時間の後に処理が開始されます。

3. 再シーケンサは時間ウィンドウ内に着信したメッセージを取得し、すべてのメッセージから最大順序ID (通常は、日付およびタイム・スタンプ)を識別します。

4. 再シーケンサは、バッファ時間内に着信し、上で識別した最大順序IDより小さい順序IDを持つすべてのメッセージを取得します。

5. 再シーケンサは、前述の手順で取得したすべてのメッセージを順序IDの昇順でソートし、メッセージを処理します。

23.2.3.3 ベスト・エフォート再シーケンサ・メッセージ配信

ベスト・エフォート再順序付け用に構成されたメディエータ・サービス・コンポーネントのアウトバウンド・サービスへのメッセージは、順序IDの順に着信することが保証されていない点に注意してください。任意の時点で、使用可能なメッセージのスナップショットが取得され、それらのメッセージのみを対象として順序付けが実行されます。したがって、標準再シーケンサとは異なり、先に着信した大きい順序ID値のメッセージより前に、小さい順序ID値のメッセージが送信される保証はありません。後に到着した小さい順序ID値のメッセージは、使用可能なメッセージのスナップショットの再取得とメッセージの再順序付けが行われる次のサイクルで処理される場合があります。

23.2.3.4 ベスト・エフォート再順序付けに必要な情報

ベスト・エフォート再シーケンサを使用する場合は、グループXPath式、順序ID XPath式、および順序IDのデータ型(numericまたはdateTime)を指定する必要があります。これらは、再シーケンサがメッセージでグループと順序IDを検索する場所、および順序IDの処理方法を指定します。また、各順序付けバッチを選択するための最大行数、または1つのバッチに含まれるメッセージが着信する時間ウィンドウを指定する必要もあります。

標準再シーケンサとは異なり、ベスト・エフォート再シーケンサには、順序の作成方法に関する認識はありません。ベスト・エフォート再シーケンサでの処理に使用される情報は他にはありません。

23.2.3.5 最大行数に基づいたベスト・エフォート再順序付けの例

表23-4 に、ベスト・エフォート再シーケンサが処理するメッセージを判別するために最大行数を使用するよう構成されている場合の動作を示します。この例では、msgX(Y,Z)は、メッセージがメディエータ・サービス・コンポーネントへのメッセージ番号Xとして着信し、そのメッセージにsequenceID Yとgroup Zが格納されていることを示しています。

表23-4 最大行数に基づいたベスト・エフォート再シーケンサの動作

グループC

順序付けされたメッセージ

msg03(1,c)

msg06(2,c)

msg10(3,c)

msg12(4,c)

msg12(4,c)、msg10(3,c)、msg06(2,c)、msg03(1,c)

注意:

ベスト・エフォート再シーケンサが正しく機能するには、メッセージが順番に、またはほぼ順番に着信する必要があります。そうでない場合、正しく再順序付けされません。メッセージが短い間隔で着信しない場合は、maxRowsRetrievedの値を1に設定すると、次のメッセージは着信までの時間の余裕ができ、次の処理ループで取得されます(したがって、順に配信されます)。

23.2.3.6 時間ウィンドウに基づいたベスト・エフォート再順序付けの例

表23-5 に、ベスト・エフォート再シーケンサがメッセージの着信期間に基づいて処理するよう構成されている場合の動作を示します。この例では、時間帯は10分、バッファは10% (1分)で、msgX(Y)は、メッセージがメディエータ・サービス・コンポーネントへのメッセージ番号Xとして着信し、そのメッセージに順序ID Yが格納されていることを示しています。最初のメッセージが2:00:00に着信すると、時間ウィンドウが開始されます。時間ウィンドウはバッファ時間を追加することで2:10:00まで継続され、2:11:00までに着信したメッセージが処理されます。

表23-5 時間ウィンドウに基づいたベスト・エフォート再シーケンサの動作

グループCメッセージ/時間

順序付けされたメッセージ

msg01(04)/2:00:00

msg02(05)/2:00:20

msg03(01)/2:00:30

msg04(03)/2:00:50

msg05(07)/2:04:20

msg06(02)/2:04:45

msg07(13)/2:05:10

msg08(08)/2:05:40

msg09(06)/2:08:40

msg10(12)/2:09:20

msg11(10)/2:10:30

msg12(09)/2:10:40

msg13(14)/2:10:50

msg14(11)/2:13:00

msg03(01)、msg06(02)、msg04(03)、msg01(04)、msg02(05)、msg09(06)、msg05(07)、msg08(08)、msg12(09)、msg11(10)、msg10(12)、msg07(13)

注意:

前述の例で、再シーケンサは時間ウィンドウの最大順序IDを13(メッセージ7から)と識別しました。メッセージ13はバッファ時間内に着信しましたが、14の順序IDを持っています。メッセージは元のグループで処理されるかわりに、2:10:50の着信時間で新しい時間ウィンドウが開始されます。メッセージ14の着信は遅すぎたため、2番目の時間ウィンドウに含められます。

23.3 再シーケンサの構成

再シーケンサは、Oracle JDeveloperを使用して構成できます。この項では、Oracle JDeveloperでの再シーケンサの構成方法について説明します。

23.3.1 再順序付けレベルの指定方法

サービス・コンポーネント・レベルまたは操作レベルのいずれかで再順序付けを定義できます。1つの操作のみを使用するメディエータ・サービス・コンポーネントの場合、操作またはサービス・コンポーネント・レベルで再順序付けを構成しても、動作は同じになります。複数の操作を持つメディエータ・サービス・コンポーネントの場合は、サービス・コンポーネント・レベルで再順序付けを指定すると、すべての操作に同じ再順序付けルールが適用され、すべての操作に着信するメッセージが再順序付けされます。デフォルトの再順序レベルは操作です。

再順序レベルを指定する手順は、次のとおりです。

1. 図23-2 に示すように、メディエータ・エディタで「再順序レベル」ドロップダウン・リストから再順序レベルを選択します。

図23-2 メディエータ・エディタと「再順序レベル」フィールド

コンポーネントを選択した場合、各操作で「再順序」フィールドは表示されなくなり、「再順序モード」フィールドが「再順序レベル」フィールド下に表示されるため、サービス・コンポーネントに再順序付けモードを設定できます。デフォルトの再順序モードは「オフ」に設定されています。

再順序モードを選択すると、図23-3 に示すように、サービス・コンポーネントまたは操作で「再順序オプション」ボックスが表示されます。操作の「再順序モード」フィールドが「オフ」に設定されている場合、「再順序オプション」ボックスは表示されません。

図23-3 メディエータ・エディタと「再順序オプション」セクション

「再順序オプション」セクションのオプションは、選択する再順序付けモードによって変更されます。

23.3.2 再順序付け戦略の構成方法

この項では、3つの異なるタイプの再順序付け戦略を構成する手順を示します。

23.3.2.1 標準再シーケンサを構成する手順:

1. 「再順序付けレベルの指定方法」の説明に従って、再順序レベルを設定してください。

2. 構成する各メディエータ・コンポーネントまたは操作のメディエータ・エディタで、「再順序モード」ドロップダウン・リストから「標準」を選択します。
図23-4 に示すように、「再順序オプション」ボックスが表示され、標準再シーケンサのオプションが含まれています。

図23-4 「再順序モード」が「標準」に設定されている状態のOracle Mediator

3. 表23-6 にリストされたフィールドに入力します。

注意:

「グループ」フィールドおよび「ID」フィールドに値を指定するには、各フィールドの右にある「式ビルダーの起動」ボタンをクリックしてください。これにより式ビルダーが起動し、フィールド式を作成したり関数を追加する際にグラフィカルなサポートが提供されます。

表23-6 標準の再順序付けオプション

フィールド名

説明

デフォルト値

必須

グループ

グループ化が行われる着信メッセージのフィールドを指し示すXPath。

component_name-operation

N

ID

再順序付けが行われる着信メッセージのフィールドを指し示すXPath。

なし

Y

タイムアウト

予期されているメッセージを待機する期間(秒単位)。タイムアウトが発生すると、再シーケンサはグループをタイムアウトとしてロックします。

0[1]

N

開始

ID順序の開始番号。

1

N

増分

ID順序の増分。

1

N

23.3.2.2 FIFO再シーケンサを構成する手順:

1. 「再順序付けレベルの指定方法」の説明に従って、再順序レベルを設定してください。

2. 構成する各Oracle Mediatorコンポーネントまたは操作のメディエータ・エディタで、「再順序モード」ドロップダウン・リストから「FIFO」を選択します。
図23-5 に示すように、「再順序オプション」ボックスが表示され、標準再シーケンサのオプションが含まれています。

図23-5 「再順序モード」が「FIFO」に設定されている状態のOracle Mediator

3. 「グループ」フィールドで、グループ化が実行される着信メッセージのフィールドを指し示すXPath式を入力します。

23.3.2.3 ベスト・エフォート再シーケンサを構成する手順:

1. 「再順序付けレベルの指定方法」の説明に従って、再順序レベルを設定してください。

2. 構成する各メディエータ・コンポーネントまたは操作のメディエータ・エディタで、「再順序モード」ドロップダウン・リストから「ベスト・エフォート」を選択します。
図23-6 に示すように、「再順序オプション」ボックスが表示され、標準再シーケンサのオプションが含まれています。

図23-6 「再順序モード」が「ベスト・エフォート」に設定されている状態のOracle Mediator

3. 表23-7 にリストされているフィールドを入力して、ベスト・エフォート再シーケンサを構成します。

注意

メッセージの一度に処理する最大行数または時間ウィンドウのいずれかを指定できます。両方を指定することはできません。一方の制御を有効にするには、もう片方を0に設定する必要があります。

4. 必要に応じて、バッファとして追加された時間ウィンドウの割合を変更できます。Oracle Enterprise Manager Fusion Middleware Controlを使用してバッファを構成します。
詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の再順序付けされたメッセージの構成に関する項を参照してください。

表23-7 ベスト・エフォート再順序付けオプション

フィールド名

説明

デフォルト値

必須

グループ

グループ化が実行される着信メッセージのフィールドを指し示すXPath。

component_name-operation

N

ID

再順序付けが実行され、IDを含む着信メッセージのフィールドを指し示すXPath。

なし

Y

データ型

順序IDのデータ型。注文プロセスはデータ型に基づいています。サポートされる値は、日時または数値です。

数値

Y

最大行数

再シーケンサが一度にデータ・ストアから取得する、順に従ったメッセージの数。

時間ウィンドウまたは最大行数を指定する必要がありますが、両方は指定できません。一方の制御を有効にするには、もう片方を0に設定する必要があります。

5

N

時間ウィンドウ

メッセージの着信後、再順序付けのためデータ・ストアからメッセージを選択するのに待機する時間の長さ(分単位)。

時間ウィンドウまたは最大行数を指定する必要がありますが、両方は指定できません。一方の制御を有効にするには、もう片方を0に設定する必要があります。

0

N

[1]
このデフォルト値の場合、デフォルトではグループに対してタイムアウトが発生することはありません。

24 Oracle Mediatorのメッセージ交換パターンの理解

この章では、Oracle Mediatorサービス・コンポーネントと他のアプリケーションとの間の一般的なメッセージ交換パターンについて説明します。

この章の内容は次のとおりです。

- 一方向メッセージ交換パターン

- リクエスト・リプライ・メッセージ交換パターン

- リクエスト・リプライ・フォルト・メッセージ交換パターン

- リクエスト・コールバック・メッセージ交換パターン

- リクエスト・リプライ・コールバック・メッセージ交換パターン

- リクエスト・リプライ・フォルト・コールバック・メッセージ交換パターン

注意:

次の交換パターンは、ルーティング・ルールが作成された際のレスポンス、フォルトおよびコールバックに対するOracle JDeveloperのデフォルト処理を示しています。すべてのケースについて、次の点を考慮してください。

- レスポンス、フォルトまたはコールバックがコール元に返信される場合は、同じメッセージを別のターゲット・サービスまたはイベントにルーティングすることもできます。これを実行するには、ターゲットの横にあるボタンをクリックし、別のターゲットを選択します。

- メディエータのコール元がレスポンスを想定する場合、1つ以上のルーティング・ルールにより、レスポンスを返さないターゲットにリクエストがルーティングされる可能性がありますが、レスポンスを返す順次ルーティング・ルールが少なくとも1つ必要です。

- リクエスト・レスポンス・パターンに複数のルーティング・ルールが含まれ、複数のルールで最初のコール元に対してレスポンスが返される場合、受信した最初のレスポンスがコール元に配信されるレスポンスになります。その他のレスポンスは無視されます。したがって、レスポンスを送信するルーティング・ルールは、レスポンスを転送する他のルーティング・ルール(存在する場合)よりも前に実行される必要があります。

24.1 一方向メッセージ交換パターン

一方向相互作用では、メディエータは起動されますが、コール元にはレスポンスを返信しません。表24-1 に示すように、ルーティング・ルール・ターゲットのタイプに基づいて、レスポンス、フォルトおよびコールバックが処理されます。

注意:

イベント・サブスクリプションには、一方向相互作用と同じ変換パターンが適用されます。

表24-1 メディエータのWSDLが一方向相互作用の場合のレスポンス

ルーティング・ルール・ターゲットのタイプ

レスポンス

リクエスト

レスポンスはありません。

リクエスト・レスポンス

レスポンスは、別のターゲットまたはイベントに転送されます。

リクエスト・レスポンス・フォルト

レスポンスおよびフォルトは、別のターゲットまたはイベントに転送されます。

リクエスト・コールバック

コールバックは、別のターゲットまたはイベントに転送されます。

リクエスト・レスポンス・コールバック

レスポンスおよびコールバックは、別のターゲットまたはイベントに転送されます。

リクエスト・レスポンス・フォルト・コールバック

レスポンス、フォルトおよびコールバックは、別のターゲットまたはイベントに転送されます。

図24-1 は、一方向メッセージ交換パターンを示しています。

図24-1 一方向メッセージ交換パターン

24.1.1 one.way.returns.faultプロパティ

one.way.returns.faultプロパティは、一方向インタフェースのSOAPコールについて、フォルトおよび一方向メッセージの処理方法を制御します。このプロパティは、composite.xmlファイルの一方向Webサービスに関するWebサービス・セクションのサービス・バインディング・コンポーネントに追加できます。このプロパティを、参照に適用することはできません。適用できるのは、サービスとbinding.wsバインディング・タイプに対してのみです。表24-2 に、このプロパティの詳細を示します。

表24-2 one.way.returns.faultプロパティ

one.way.returns.faultの設定

結果

trueに設定した場合

. . .
<service name="Mediator1_2"
ui:wsdlLocation="ReadFile.wsdl">
<interface.wsdl
interface="http://xmlns.oracle.com/pcbpel/adapter/file
/LocalSandbox/Project1/ReadFile%2F#wsdl.interface(Read_
ptt)"/>
<binding.ws
port="http://xmlns.oracle.com/pcbpel/adapter/file
/LocalSandbox/Project1/ReadFile%2F#wsdl.endpoint
(Mediator1/Read_pt)">
<property name="one.way.returns.fault" type="xs:string" many="false"
override="may">true</property>
</binding.ws>
</service>
. . .

後続処理で発生するフォルトは、クライアントへのSOAPフォルトと、HTTPレスポンス・コード500を返します。(11g リリース1と同じ動作。)

falseに設定した場合

. . .
<service name="Mediator1_2"
ui:wsdlLocation="ReadFile.wsdl">
<interface.wsdl
interface="http://xmlns.oracle.com/pcbpel/adapter/file/
Local Sandbox/Project1/ReadFile%2F#wsdl.interface(Read_
ptt)"/>
<binding.ws
port="http://xmlns.oracle.com/pcbpel/adapter/file/LocalSan
dbox/Project1/ReadFile%2F#wsdl.endpoint(Mediator1/Read_
pt)">
<property name="one.way.returns.fault"
type="xs:string" many="false"
override="may">false</property>
</binding.ws>
</service>
. . .

後続処理で発生するフォルトは、HTTPレスポンス・コード500のみを返します。クライアントにはSOAPフォルトを返しません。

未設定の場合(デフォルト)

後続処理で発生するフォルトは、クライアントへのSOAPフォルトと、HTTPレスポンス・コード500を返します。(11g リリース1と同じ動作。)

24.1.1.1 one.way.returns.faultプロパティを追加する手順:

1. SOAコンポジット・エディタで、one.way.returns.faultプロパティを追加するサービス・バインディング・コンポーネントを選択します。

2. エディタの右下部にある「プロパティ・インスペクタ」セクションに移動します。

3. 「バインディング・プロパティ」セクションで、「追加」アイコンをクリックします。
「プロパティの作成」ダイアログが表示されます。

4. 「名前」フィールドに、one.way.returns.faultと入力します。

5. 「値」フィールドに、trueまたはfalseを入力します。

6. 「OK」をクリックします。

24.2 リクエスト・リプライ・メッセージ交換パターン

リクエスト・リプライ相互作用では、メディエータが起動され、コール元にリプライを送信します。表24-3 に示すように、ルーティング・ルール・ターゲットのタイプに基づいて、レスポンス、フォルトおよびコールバックが処理されます。

表24-3 メディエータのWSDLがリクエスト・リプライの場合のレスポンス

ルーティング・ルール・ターゲットのタイプ

レスポンス

リクエスト

ターゲットからのレスポンスはありませんが、リクエスト・レスポンス・サービスが含まれる順次ルーティング・ルールが少なくとも1つ必要です。

リクエスト・レスポンス

レスポンスは、コール元に返信されます。レスポンスは別のターゲットまたはイベントに転送できますが、コール元にレスポンスを返す順次ルーティング・ルールが少なくとも1つ必要です。

リクエスト・レスポンス・フォルト

レスポンスは、コール元に返信されます。フォルトは、別のターゲットまたはイベントに転送されます。

リクエスト・コールバック

ターゲットからのレスポンスはありませんが、リクエスト・レスポンス・サービスが含まれる順次ルーティング・ルールが少なくとも1つ必要です。コールバックは、別のターゲットまたはイベントに転送されます。

リクエスト・レスポンス・コールバック

レスポンスは、コール元に返信されます。コールバックは、別のターゲットまたはイベントに転送されます。

リクエスト・レスポンス・フォルト・コールバック

レスポンスは、コール元に返信されます。コールバックおよびフォルトは、別のターゲットまたはイベントに転送されます。

図24-2 は、リクエスト/リプライ・メッセージ交換パターンを示しています。

図24-2 リクエスト/リプライ・メッセージ交換パターン

24.3 リクエスト・リプライ・フォルト・メッセージ交換パターン

リクエスト・リプライ・フォルト相互作用では、メディエータが起動され、コール元にリプライと1つ以上のフォルトを返信します。表24-4 に示すように、ルーティング・ルール・ターゲットのタイプに基づいて、レスポンス、フォルトおよびコールバックが処理されます。

表24-4 メディエータのWSDLがリクエスト・リプライ・フォルトの場合のレスポンス

ルーティング・ルール・ターゲットのタイプ

レスポンス

リクエスト

リクエスト・レスポンス・フォルト・サービスが含まれる順次ルーティング・ルールが少なくとも1つ必要です。送信するレスポンスがない場合、メディエータはnullを返します。

リクエスト・レスポンス

レスポンスは、コール元に返信されます。メディエータによるメッセージ処理での例外によってフォルトが発生する場合があります。

リクエスト・レスポンス・フォルト

レスポンスおよびフォルトがコール元に返信されます。メディエータによるメッセージ処理での例外によってフォルトが発生する場合があります。

リクエスト・コールバック

ターゲットからのレスポンスはありませんが、リクエスト・レスポンス・サービスが含まれる順次ルーティング・ルールが少なくとも1つ必要です。送信するレスポンスがない場合、メディエータはnullを返します。コールバックは、別のターゲットまたはイベントに転送されます。

リクエスト・レスポンス・コールバック

レスポンスは、コール元に返信されます。メディエータによるメッセージ処理での例外によってフォルトが発生する場合があります。

リクエスト・レスポンス・フォルト・コールバック

レスポンスおよびフォルトがコール元に返信されます。メディエータによるメッセージ処理での例外によってフォルトが発生する場合があります。

図24-3 は、リクエスト・リプライ・フォルト・メッセージ交換パターンを示しています。

図24-3 リクエスト・リプライ・フォルト・メッセージ交換パターン

24.4 リクエスト・コールバック・メッセージ交換パターン

リクエスト・コールバック相互作用では、メディエータが起動され、コール元に非同期リプライを送信する場合があります。表24-5 に示すように、ルーティング・ルール・ターゲットのタイプに基づいて、レスポンス、フォルトおよびコールバックが処理されます。

表24-5 メディエータのWSDLがリクエスト・コールバックの場合のレスポンス

ルーティング・ルール・ターゲットのWSDL

レスポンス

リクエスト

リクエスト・コールバック・サービスが含まれる順次ルーティング・ルールが少なくとも1つ必要です。コールバックが定義されたルーティング・ルールがない場合、コールバックはコール元に送信されません。

リクエスト・レスポンス

レスポンスは、独立したスレッドでコールバックとしてコール元に返信されます。追加のルーティング・ルールを作成して、レスポンスを別のターゲットまたはイベントに転送できます。

リクエスト・レスポンス・フォルト

レスポンスは、独立したスレッドでコールバックとしてコール元に返信されます。フォルトは、別のターゲットまたはイベントに転送されます。前項と同様に、追加のルーティング・ルールを作成して、レスポンスを別のターゲットまたはイベントに転送できます。

リクエスト・コールバック

コールバックは、コール元に返信されます。

リクエスト・レスポンス・コールバック

コールバックはコール元に返信され、レスポンスは別のターゲットまたはイベントに転送されます。

リクエスト・レスポンス・フォルト・コールバック

コールバックは、コール元に返信されます。レスポンスおよびフォルトは、別のターゲットまたはイベントに転送されます。

図24-4 は、リクエスト・コールバック・メッセージ交換パターンを示しています。

図24-4 リクエスト・コールバック・メッセージ交換パターン

24.5 リクエスト・リプライ・コールバック・メッセージ交換パターン

リクエスト・リプライ・コールバック相互作用では、メディエータが起動され、最初のコール元にレスポンスと非同期リプライを送信します。表24-6 に示すように、ルーティング・ルール・ターゲットのタイプに基づいて、レスポンス、フォルトおよびコールバックが処理されます。

表24-6 メディエータのWSDLがリクエスト・レスポンス・コールバックの場合のレスポンス

ルーティング・ルール・ターゲットのタイプ

レスポンス

リクエスト

レスポンスを返す順次ルーティング・ルールが少なくとも1つ必要です。コールバックが定義されたルーティング・ルールがない場合、コールバックはコール元に送信されません。

リクエスト・レスポンス

レスポンスを返す順次ルーティング・ルールが少なくとも1つ必要です。コールバックが定義されたルーティング・ルールがない場合、コールバックは送信されません。

リクエスト・レスポンス・フォルト

レスポンスを返す順次ルーティング・ルールが少なくとも1つ必要です。コールバックが定義されたルーティング・ルールがない場合、コールバックはコール元に送信されません。フォルトは、別のターゲットまたはイベントに転送されます。

リクエスト・コールバック

レスポンスを返す順次ルーティング・ルールが少なくとも1つ必要です。送信するレスポンスがない場合、メディエータはnullを返します。

リクエスト・レスポンス・コールバック

レスポンスおよびコールバックがコール元に返信されます。

リクエスト・レスポンス・フォルト・コールバック

レスポンスおよびコールバックがコール元に返信されます。フォルトは、別のターゲットまたはイベントに転送されます。

図24-5 は、リクエスト・リプライ・コールバック・メッセージ交換パターンを示しています。

図24-5 リクエスト・リプライ・コールバック・メッセージ交換パターン

24.6 リクエスト・リプライ・フォルト・コールバック・メッセージ交換パターン

リクエスト・リプライ・フォルト・コールバック相互作用では、メディエータが起動され、最初のコール元にレスポンス、非同期リプライおよび1つ以上のフォルト・タイプを返信します。表24-7 に示すように、ルーティング・ルール・ターゲットのタイプに基づいて、レスポンス、フォルトおよびコールバックが処理されます。

表24-7 リクエスト・レスポンス・フォルト・コールバックのメディエータへのレスポンス

ルーティング・ルール・ターゲットのWSDL

レスポンス

リクエスト

リクエスト・コールバック・サービスが含まれる順次ルーティング・ルールと、レスポンスを返す順次ルーティング・ルールが、それぞれ少なくとも1つずつ必要です。必要なルーティング・ルールが定義されていない場合、コールバックおよびレスポンスは送信されません。

リクエスト・レスポンス

リクエスト・コールバック・サービスが含まれる順次ルーティング・ルールと、レスポンスを返す順次ルーティング・ルールが、それぞれ少なくとも1つずつ必要です。必要なルーティング・ルールが定義されていない場合、コールバックおよびレスポンスは送信されません。

リクエスト・レスポンス・フォルト

リクエスト・コールバック・サービスが含まれる順次ルーティング・ルールと、レスポンスを返す順次ルーティング・ルールが、それぞれ少なくとも1つずつ必要です。必要なルーティング・ルールが定義されていない場合、コールバックおよびレスポンスは送信されません。

リクエスト・コールバック

レスポンスを返す順次ルーティング・ルールが少なくとも1つ必要です。送信するレスポンスがない場合、メディエータはnullを返します。

リクエスト・レスポンス・コールバック

レスポンスおよびコールバックがコール元に返信されます。メディエータによるメッセージ処理での例外によってフォルトが発生する場合があります。

リクエスト・レスポンス・フォルト・コールバック

レスポンス、フォルトおよびコールバックがコール元に返信されます。

図24-6 は、リクエスト・リプライ・フォルト・コールバック・メッセージ交換パターンを示しています。

図24-6 リクエスト・リプライ・フォルト・コールバック・メッセージ交換パターン

第IV部 ビジネス・ルール・サービス・コンポーネントの使用

この部では、ビジネス・ルール・サービス・コンポーネントの使用方法について説明します。

この部は、次の章で構成されています。

- Oracle Business Rulesのスタート・ガイド

- 宣言コンポーネントおよびタスク・フローの使用

25 Oracle Business Rulesのスタート・ガイド

この章では、ビジネス・ルール・サービス・コンポーネントを使用して、SOAコンポジット・アプリケーションをに統合する方法について説明します。ビジネス・ルール・サービス・コンポーネントはデシジョン・コンポーネントとも呼ばれます。ビジネス・ルールは、SOAコンポジット・アプリケーションの一部またはBPELプロセスの一部として追加できます。

この章の内容は次のとおりです。

- ビジネス・ルール・サービス・コンポーネントの概要

- ルール・デザイナ・エディタ環境の概要

- ビジネス・ルールの作成および編集の概要

- BPELプロセスへのビジネス・ルールの追加

- SOAコンポジット・アプリケーションへのビジネス・ルールの追加

- コンポジット・アプリケーションでのビジネス・ルールの実行

- ビジネス・ルールとファクト・タイプの使用

のその他の例は、『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

一部のスクリーン・ショットは以前のバージョンを表している場合がありますが、内容は適用できます。

25.1 ビジネス・ルール・サービス・コンポーネントの概要

デシジョン・コンポーネント(ビジネス・ルール・サービス・コンポーネントとも呼ばれます)は、SOAコンポジット・アプリケーションでのの使用をサポートしています。デシジョン・コンポーネントは、次のようにSOAコンポジットで使用できます。

- デシジョン・コンポーネントは、SOAコンポジット内で使用してBPELコンポーネントに接続できます。

- デシジョン・コンポーネントは、SOAコンポジット内で使用してビジネス・ルールの実行に直接使用できます。

- デシジョン・コンポーネントは、メディエータの動的ルーティング機能とともに使用できます。
詳細は、「Oracle Mediatorルーティング・ルールの作成」を参照してください。

- デシジョン・コンポーネントは、ヒューマン・ワークフローの拡張ルーティング・ルールとともに使用できます。
詳細は、「ヒューマン・タスクとBPELプロセスの関連付け」を参照してください。

25.1.1 BPELプロセス、ビジネス・ルールおよびヒューマン・タスクの統合

BPELプロセス、ビジネス・ルールおよびヒューマン・タスク・コンポーネントを含むSOAコンポジット・アプリケーションを作成できます。これらのコンポーネントは補完的な技術です。BPELプロセスではシステム、サービスおよびユーザーのオーケストレーションにフォーカスが置かれます。ビジネス・ルールでは、意思決定とポリシーにフォーカスが置かれます。ヒューマン・タスクを使用すると、エンドツーエンド・プロセス・フローの一部として実行するタスクをユーザーまたはグループに対して説明するワークフローをモデリングできます。

ビジネス・ルールを使用できる状況の例を次に示します。

- 動的処理
ルールにより、サービス・レベル合意や他のガイドラインに基づいて、ビジネス・プロセス内でインテリジェント・ルーティングを実行できます。たとえば、顧客が1日以内のレスポンスを必要とする場合は、融資申請をQuickLoan融資エージェントにのみ送信します。顧客に1日以上の余裕がある場合は、申請を3つの異なる融資エージェントにルーティングします。

- プロセスのビジネス・ルールの外部化
通常ビジネス・プロセスの一部として評価する必要がある条件が多くあります。ただし、これらの条件のパラメータはプロセスに関係なく変更できます。たとえば、信用度が650以上の顧客にのみ融資を提供するとします。この値は、ビジネス・アナリストが設定した新規ガイドラインに基づいて動的に変更できます。

- データ検証および制約チェック
ルールは、入力データを検証したり、リクエストに対して追加制約を適用できます。たとえば、新規顧客リクエストには、常に雇用確認書と銀行勘定詳細を添付する必要があります。

- ヒューマン・タスクのルーティング
ビジネス・プロセスでは、次のようにヒューマン・タスクでルールが頻繁に使用されます。

- ポリシー・ベースのタスク割当てでは、タスクが特定のロールやユーザーにディスパッチされます。たとえば、ポータルからの着信リクエストを処理するプロセスでは、融資申請と見積保険料を異なるロール・セットにルーティングできます。

- ユーザー間のタスクのロード・バランシング。タスクが一連のユーザーまたはロールに割り当てられると、そのロールの各ユーザーはタスク・セットを取得して、指定された時間内にタスクの処理を行います。新規タスクを受け取った場合は、ポリシーを適用してタスクに優先度が設定され、特定のユーザー・キューに入れられます。たとえば、特定の1人の融資エージェントに対して割り当てる融資を、常に最大で10件にするなどです。

ヒューマン・タスク・コンポーネントのヒューマン・タスク・エディタでのビジネス・ルール作成の詳細は、「ビジネス・ルールを使用した詳細タスク・ルーティングの指定方法」を参照してください。

25.2 ルール・デザイナ・エディタ環境の概要

Oracle JDeveloperのSOAコンポジット・アプリケーションにビジネス・ルール・サービス・コンポーネントを作成した後は、そのサービス・コンポーネントをビジネス・ルール・デザイナを使用して設計できます。このデザイナは、SOAコンポジット・エディタでビジネス・ルールをダブルクリックすると表示されます。

ビジネス・ルール・デザイナは、図25-1 に示す主要なセクションで構成されています。これらのセクションでは、Oracle JDeveloperのビジネス・ルールを使用できます。

図25-1 Oracle JDeveloperのルール・デザイナ

SOAインストールには、動詞ルールおよびビジネス・フレーズがないことに注意してください。これはBPMの機能です。

25.2.1 「アプリケーション」ウィンドウ

「アプリケーション」ウィンドウには、プロジェクトのファイルが表示されます。各プロジェクトに格納できるのは、1つのコンポジットのみです。ただし、各コンポジットには、同じタイプまたは異なるタイプ(ビジネス・ルール、BPELプロセス、Oracle Mediatorおよびヒューマン・ワークフロー)の複数のコンポーネントを指定できます。

ビジネス・ルールの設計時には、追加ファイル、フォルダおよび要素を「アプリケーション」ウィンドウに表示できます。

25.2.2 ルール・デザイナ・ウィンドウ

ルール・デザイナ・ウィンドウには、選択したディクショナリ・コンポーネントのビジュアル・ビューが表示されます。ルール・デザイナのナビゲーション・タブを使用して、使用するディクショナリの様々な部分を選択します。ルール・デザイナ・ウィンドウは、次のいずれかの処理を実行すると表示されます。

- コンポジット内でビジネス・ルール・コンポーネントをダブルクリックした場合

- SOAコンポジット・エディタでビジネス・ルール・コンポーネントをダブルクリックした場合

- BPELプロセス内でビジネス・ルールをダブルクリックした場合

- 「アプリケーション」ウィンドウで、ビジネス・ルールのディクショナリ・ファイル(.rules拡張子付きのファイル)をダブルクリックした場合。

- .rulesファイルが選択されている状態の「設計」タブをクリックした場合

表25-1 では、ルール・デザイナでディクショナリを使用する際の情報を検索できるナビゲーション領域について説明します。

表25-1 ルール・デザイナのナビゲーション領域の説明

ルール・デザイナのナビゲーション・タブ

説明

ファクト

olink:ASRUG243ファクトは、ルールによる推論対象のオブジェクトです。

関数

olink:ASRUG296Oracle Business Rulesでは、関数は標準の算術関数を指します。

グローバル

olink:ASRUG277Oracle Business Rulesでは、グローバルはJavaにおけるパブリックな静的変数に類似しています。

値セット

olink:ASRUG243値セットは、デシジョン表の値または値の範囲の選択内容に制約を付加します。

リンク

olink:ASRUG271リンクは、同じアプリケーションまたは別のアプリケーション内のディクショナリにリンクする際に使用します。

デシジョン関数

olink:ASRUG99955デシジョン関数は、宣言的に構成される関数です。構成されているルールセットに基づいて入力に推論を行い出力で受信する他のコンポーネント(BPEL、タスク)により起動できます。

変換

これは、ルールおよびそれらのアーティファクトのローカライズに役立ちます。

ルールおよびを含むルールセット

ルールセットは、ルールおよびデシジョン表の実行単位を提供します。デシジョン表は、表形式で記述された一連のルールです。デシジョン表は、表内でグループ化されたルールに追加機能を提供します(競合、完全度など)。

ルール・デザイナのナビゲーション領域の詳細および説明は、『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

25.2.3 「構造」ウィンドウ

「構造」ウィンドウには、ルール・デザイナ・ウィンドウで現在選択しているビジネス・ルール・ディクショナリのデータが構造的に表示されます。このセクションで要素を選択または右クリックすると、次のような様々なタスクを実行できます。

- ファクト、関数、グローバル、値セット、ディクショナリ・リンク、デシジョン関数などの要素の管理(作成、編集、リフレッシュおよび削除)

- ルールセット、ルールおよびへのアクセス

図25-2 に、「構造」ウィンドウを示します。

図25-2 ルール・デザイナ・ディクショナリが表示された「構造」ウィンドウ

25.2.4 「ビジネス・ルール検証 - ログ」ウィンドウ

ルール・デザイナでは、図25-3 に示すように、ビジネス・ルール検証ログにディクショナリ検証のステータスが表示されます。

ディクショナリが無効な場合、ルール・デザイナでは警告メッセージのリストが生成されて関連ディクショナリ・オブジェクトがリスト表示されるため、ディクショナリ・オブジェクトの検索と問題の解決に使用できます。ルール・デザイナを使用したルールの作成時に表示される検証警告は、無視しても問題ありません。検証警告はルールを作成すると削除されますが、ルール作成時の中間ステップ中は表示されます。ルールをテストまたはデプロイする際は、関連ディクショナリに警告が表示されていない必要があります。

ビジネス・ルールの検証の詳細は、『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

図25-3 ルール・デザイナの「ビジネス・ルール検証 - ログ」

25.3 ビジネス・ルールの作成および編集の概要

この項では、ビジネス・ルールを開始する方法について説明し、ビジネス・ルールの設計に使用するOracle JDeveloperの主要なセクションについて簡単に紹介します。

25.3.1 ビジネス・ルール・コンポーネントの作成方法

ビジネス・ルール・コンポーネントは、を使用して追加できます。

ビジネス・ルール・コンポーネントを作成する手順は、次のとおりです。

1. 表25-2 の説明に従って、Oracle JDeveloperを起動します。

表25-2 Oracle JDeveloperの起動

起動対象

Windowsの場合

UNIXの場合

Oracle JDeveloper

JDev_Oracle_Home\JDev\bin\jdev.exeをクリックするか、ショートカットを作成します。

$ORACLE_HOME/jdev/bin/jdev

2. 次のいずれかの方法を使用して、ビジネス・ルール・サービス・コンポーネントを作成します。
既存のSOAコンポジット・アプリケーションのサービス・コンポーネントとして、「ビジネス・ルール」サービス・コンポーネントを「コンポーネント」ウィンドウからにドラッグします

新規アプリケーションに追加する方法:

a. 「アプリケーション」ウィンドウから、「ファイル」→「新規」→「アプリケーション」→「SOAアプリケーション」の順に選択します。
これにより、SOAアプリケーションの作成ウィザードが起動します。

b. 「アプリケーションの名前付け」ページで、「名前」フィールドにアプリケーション名を入力します。

c. 「ディレクトリ」フィールドに、SOAコンポジット・アプリケーションおよびプロジェクトを作成するディレクトリ・パスを入力します。

d. 「次へ」をクリックします。

e. 「プロジェクトの名前付け」ページで、「プロジェクト名」フィールドに一意のプロジェクト名を入力します。プロジェクト名は、SOAコンポジット・アプリケーション間で一意である必要があります。これは、コンポジットの一意性は、そのコンポジットのプロジェクト名によって確定されるためです。たとえば、表25-3 に説明するような操作は実行しないでください。

表25-3 SOAプロジェクトの名前付けに関する制限

作成するアプリケーションの名前

作成するSOAプロジェクト名

Application1

Project1

Application2

Project1

デプロイ時に、2番目にデプロイされたプロジェクト(コンポジット)で最初にデプロイされたプロジェクト(コンポジット)が上書きされます。

f. 「次へ」をクリックします。

g. 「SOA設定の構成」ページで、「ビジネス・ルールを使用するコンポジット」を選択します。

h. 「終了」をクリックします。

それぞれの方法を実行すると、「ビジネス・ルールの作成」ダイアログが表示されます。

3. 必要な詳細を指定します。入力および出力に関する情報およびこのダイアログで「ディクショナリのインポート」オプションを使用する方法の詳細は、『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

4. 「OK」をクリックします。

25.3.2 ルール・デザイナでのビジネス・ルールの使用

ビジネス・ルールを使用している場合は、Oracle JDeveloperにルール・デザイナが表示されます。

25.4 BPELプロセスへのビジネス・ルールの追加

デシジョン・コンポーネント(ビジネス・ルール・サービス・コンポーネントとも呼ばれます)を使用すると、BPELプロセスでビジネス・ルールを実行できます。

ビジネス・ルールは、「Business Rule」コンポーネントを使用してBPELプロセスに追加します。ビジネス・ルール・コンポーネントをBPELプロセスに追加する場合は、ルールに対して入力を提供し、ビジネス・ルールから結果を取得するために、入力変数と出力変数を指定する必要があります。

ビジネス・ルール・コンポーネントを使用して、ビジネス・ルールを実行し、ルールに基づいてビジネス上の意思決定を作成できます。ビジネス・ルール・コンポーネント(デシジョン・コンポーネントとも呼ばれます)を作成するには、「コンポーネント」ウィンドウから「ビジネス・ルール」をBPELプロセスにドラッグ・アンド・ドロップします。

ビジネス・ルールをBPELプロセスに追加する手順は、次のとおりです。

1. BPELプロセス・サービス・コンポーネントを作成します。詳細は、「BPELプロセス・サービス・コンポーネントの概要」を参照してください。

2. プロセス項目をダブルクリックして、BPELプロセスを開きます。たとえば、図25-4に示すように、BPELプロセスを開いてreceiveInputおよびcallbackClient を表示します。

図25-4 BPELプロセスへのビジネス・ルールの追加

3. 「コンポーネント」ウィンドウにある「SOAコンポーネント」セクションで「ビジネス・ルール」を選択し、ビジネス・ルールを必要としている場所まで「ビジネス・ルール」をドラッグ・アンド・ドロップします。たとえば、図25-5 に示すようにreceiveInputとcallbackClientの間に「Business Rule」をドラッグ・アンド・ドロップします。

図25-5 BPELプロセスへの「Business Rule」のドラッグ・アンド・ドロップ

4. ビジネス・ルールがOracle JDeveloperのダイアグラムに表示されます。ビジネス・ルール・コンポーネントをダブルクリックすると、「ルール」ダイアログ・ボックスが表示されます。

「ルール」ダイアログ・ボックスには、「一般」、「ディクショナリ」、「相関セット」などのタブがあり、既存のディクショナリを選択するか、新たに作成するディクショナリの名前を入力できます。「一般」タブの「名前」フィールドに、ビジネス・ルールの名前を入力します。たとえば、図25-6 に示すように、GetCreditRatingと入力します。事前にディクショナリを作成した場合は、「ディクショナリ」タブの「ディクショナリ」フィールドで、既存のディクショナリを選択します。

図25-6 自動融資BPELプロセスに追加されたビジネス・ルール

5. ビジネス・ルール領域の「ビジネス・ルール ディクショナリ」で、「ディクショナリの作成」アイコンをクリックし、「ビジネス・ルールの作成」ダイアログを表示します。

6. 「ビジネス・ルールの作成」ダイアログで、次の操作を実行します。

- ディクショナリの名前とパッケージ名を指定します。

- ビジネス・ルールの入力および出力データ要素を指定します。たとえば、GetCreditRatingというサンプル・デシジョン・コンポーネントでは、入力は信用格付け申込書です。出力はビジネス・ルールの実行時に生成されます。この例では信用格付け文書です。たとえば、GetCreditRatingルールの入力および出力データを受け渡すRatingRequestとRatingという新しい2つの変数をBPELで作成できます。

ディクショナリの名前を入力します。たとえば、図25-7 に示すように、GetCreditRatingと入力します。

図25-7 GetCreditRatingビジネス・ルール・ディクショナリの追加

25.4.1 ビジネス・ルールの入力の追加方法

ビジネス・ルールの入力を追加する手順は、次のとおりです。

1. 「ビジネス・ルールの作成」ダイアログで、「追加」アイコンの横にあるメニューから「入力変数の追加...」を選択し、入力変数を作成します。

「入力変数の追加」ダイアログ・ボックスが表示されます。

2. 「入力変数の追加」ダイアログ・ボックスで、「プロセス」フォルダを開き、「プロセス」のすぐ下の「変数」フォルダを選択します。

3. 図25-8 に示すように、「変数」フォルダを右クリックし、リストから「変数の作成...」を選択します。

図25-8 入力変数の追加

「変数の作成」ダイアログ・ボックスが表示されます。

4. 「変数の作成」ダイアログ・ボックスで、「名前」フィールドに値を入力します。たとえば、図25-9に示すように、RatingRequest と入力します。

図25-9 「変数の作成」ダイアログ

5. 「変数の作成」の「タイプ」領域で、「要素の参照」アイコンをクリックします。ナビゲータを使用して、入力変数のスキーマ要素タイプを検索します。たとえば、ratingrequestタイプを選択します。タイプ・チューザを使用して必要なタイプを追加します。

6. 「スキーマ・ファイルのインポート」アイコンをクリックし、スキーマをインポートします。たとえば、CreditRatingTypes.xsdをインポートします。アプリケーションに必要なその他のスキーマもインポートします。

7. 「タイプ・チューザ」ダイアログで「ratingrequest」を選択し、「OK」をクリックします。

8. 「変数の作成」ダイアログで「OK」をクリックします。

9. 「入力変数の追加」ダイアログで「OK」をクリックします。

25.4.2 ビジネス・ルールの出力の追加方法

ビジネス・ルールの出力を追加する手順は、次のとおりです。

1. 「ビジネス・ルールの作成」ダイアログで、「追加」アイコンの横にあるドロップダウン・メニューから「出力変数の追加...」を選択します。「出力変数の追加」ダイアログが表示されます。このダイアログを使用して出力変数を作成します。たとえば、入力変数の作成と同様の方法でGetCreditRatingの出力変数を作成します。

2. 「出力変数の追加」ダイアログで、「プロセス」の下の「変数」フォルダを選択することで、スコープを選択します。

3. 右クリックして、ドロップダウン・リストから「変数の作成...」を選択します。「変数の作成」ダイアログが表示されます。

4. 「変数の作成」ダイアログで、「名前」フィールドに出力変数名を入力します。たとえば、Ratingと入力します。

5. 「変数の作成」ダイアログの「タイプ」領域で、「要素の参照」アイコンを選択し、「タイプ・チューザ」ダイアログを使用して出力変数のタイプを入力します。たとえば、CreditRatingTypes.xsdを開き、ratingという要素タイプを選択します。

6. 「タイプ・チューザ」ダイアログで「OK」をクリックします。

7. 「変数の作成」ダイアログで「OK」をクリックします。

8. 「出力変数の追加」ダイアログで「OK」をクリックします。
図25-10 に示すように、「ビジネス・ルールの作成」ダイアログが表示されます。

図25-10 入力変数と出力変数が指定された「ビジネス・ルールの作成」ダイアログ

25.4.3 オプションを設定してデシジョン・サービスとビジネス・ルール・ディクショナリを作成する方法

デシジョン・サービスとビジネス・ルール・ディクショナリを作成する手順は、次のとおりです。

1. デフォルトのサービス名を使用しない場合は、「詳細」タブを選択し、「サービス名」フィールドにサービス名を入力します。たとえば、CreditRatingServiceというサービス名を入力します。

2. デシジョン・コンポーネントがステートフルかステートレスかの判断は、「セッションのリセット」を使用して行います。詳細は、「デシジョン・コンポーネントのステートフル操作に関する必知事項」を参照してください。

3. 「ビジネス・ルールの作成」ダイアログで「OK」をクリックします。図25-11 に示すように、Oracle JDeveloperでデシジョン・コンポーネントとディクショナリが作成され、ルール・デザイナが表示されます。

図25-11 ビジネス・ルールを使用するルール・デザイナのキャンバス

ルール・デザイナの詳細は、『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

25.4.4 BPELプロセスへのビジネス・ルール追加時の処理内容

ビジネス・ルールをBPELプロセスに追加すると、Oracle JDeveloperによってデシジョン・コンポーネントが作成され、ビジネス・ルール・サービス・エンジンを使用してビジネス・ルールが制御および実行されます。

デシジョン・コンポーネントの構成内容は次のとおりです。

- を使用して評価されるルールまたは。これらはルール・デザイナを使用して定義され、ビジネス・ルール・ディクショナリに格納されます。

- 特定のルールを評価する際に必要なファクト、およびコールするデシジョン関数の説明。ルールまたはが格納される各ルールセットは、入力および出力されるファクトとデシジョン関数の名前が指定されているサービスとして公開されます。ファクトは、ビジネス・ルールの入力および出力を定義する際に、XSD定義を介して公開されます。デシジョン関数は、ディクショナリに格納されます。詳細は、『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

- 入力、出力および基礎となるビジネス・ルール・サービス・エンジンのコールがラップされているWebサービス。
ビジネス・プロセスでは、このWebサービスを使用して、プロセスの一環としてファクトをアサートしたり取り消すことができます。すべてのファクトをビジネス・プロセスから1単位としてアサートできる場合があります。また、ビジネス・プロセスでファクトを増分アサートし、最終的にルール・エンジンによる推論を参照する場合もあります。したがって、サービスはステートレスとステートフルの両方の相互作用をサポートしています。

このような様々なデシジョン・コンポーネントを作成できます。

詳細は、『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

25.4.5 ビジネス・ルール・ディクショナリ作成時の処理内容

アプリケーション、プロジェクトおよびルール・ディクショナリを作成すると、Oracle JDeveloperの構造ペインにルール・ディクショナリが表示され、メイン・キャンバスにルール・デザイナが開きます。

「ビジネス・ルールの作成」ダイアログの一環として選択した既存のディクショナリまたは新規ルール・ディクショナリは、事前にロードされている次のデータを使用して作成されます。

- ビジネス・ルールの入力および出力情報に基づいたXMLファクト・タイプ・モデル。

- ルールまたはを追加して完成させる必要があるルールセット。既存のディクショナリでは、インポート・オプションを使用して、ルールまたはがすでに組み込まれているディクショナリを指定します。

- デシジョン・コンポーネントの入力および出力が規定されているサービス・コンポーネント。

- ルール・ディクショナリのデシジョン・コンポーネント、およびBPELプロセスへのワイヤ。

注意:

ビジネス・ルールの入出力を作成すると、関連ディクショナリに作成されるXMLファクト・タイプには、「ビジネス・ルールの作成」ダイアログで指定した入出力のスキーマ・タイプに基づいて名前が指定されます。入力と出力のスキーマ・タイプを指定すると、ルール・デザイナでは、入力と出力のタイプ選択に関連するファクト・タイプと別名が定義されます。入力と出力の両方に単一のタイプを使用した場合にのみ、デシジョン・コンポーネントで単一のファクトが作成され、ルール・デザイナの「ファクト」タブに表示されます。このファクトには、指定したファクト・タイプが示され、入力変数名と出力変数名を連結した別名が使用されます。ファクト・タイプのデフォルトの命名方式を使用しない場合は、この別名をルール・デザイナで変更できます。

25.4.6 BPELプロセスでのビジネス・ルールの起動に関する必知事項

ビジネス・ルールをBPELプロセスに追加すると、Oracle JDeveloperによって、指定の入力情報を使用したのコールと、結果が格納された出力の取得をサポートするデシジョン・サービスが作成されます。デシジョン・サービスは、実行時にWebサービスとしてエンジンへのアクセスを提供します。詳細は、『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

25.4.7 デシジョン・コンポーネントのステートフル操作に関する必知事項

ビジネス・ルール・サービス・エンジンで実行されるデシジョン・コンポーネントは、ステートフルまたはステートレス操作をサポートしています。これら2つの操作モードの切替えは、「ビジネス・ルールの作成」ダイアログの「セッションのリセット」チェック・ボックスで提供されています。

デフォルトでは、「セッションのリセット」チェック・ボックスが選択されており、これはステートレス操作を示します。ステートレス操作とは、実行時にデシジョン・コンポーネントが起動した後、ルール・セッションがリリースされることを意味します。

「セッションのリセット」の選択が解除されている場合は、基礎となるオブジェクトが独立した場所にあるビジネス・ルール・サービス・エンジンのメモリーに保持されます(したがって、オブジェクトは操作終了時にルール・セッション・プールに返されません)。その後のデシジョン・コンポーネントの使用では、callFunctionStatefulの起動以降にキャッシュされたすべてのRuleSessionオブジェクトとその状態の情報が再利用され、callFunctionStateless操作の終了後にルール・セッション・プールにリリースされて戻されます。したがって、「セッションのリセット」の選択が解除されている場合は、後続リクエストのためにルール・セッションが保存され、同じBPELプロセスからの一連のデシジョン・サービスの起動が常にステートレス起動で終了する必要があります。

25.5 SOAコンポジット・アプリケーションへのビジネス・ルールの追加

をSOAコンポジット・アプリケーションで使用するには、アプリケーションを作成してビジネス・ルールを追加します。

ビジネス・ルール・サービス・コンポーネントを使用して、SOAコンポジット・アプリケーションとビジネス・ルールを統合できます。これにより、ビジネス・ルール・ディクショナリが作成され、ビジネス・ルールを実行し、ルールに基づいてビジネス上の決定を下すことができます。

Oracle JDeveloperでプロジェクトを作成した後は、そのプロジェクト内にビジネス・ルール・サービス・コンポーネントを作成する必要があります。ビジネス・ルールを追加する際、入力変数および出力変数を作成して、サービス・コンポーネントに入力を提供し、サービス・コンポーネントから結果を取得できます。

ビジネス・ルールをOracle JDeveloperで使用する手順は、次のとおりです。

- ビジネス・ルール・サービス・コンポーネントを追加します。

- サービス・コンポーネントの入力変数および出力変数を作成します。

- ディクショナリを作成します

25.5.1 SOAコンポジット・アプリケーションへのビジネス・ルールの追加方法

SOAコンポジット・アプリケーションでを使用するには、Oracle JDeveloperを使用してアプリケーションとプロジェクトを作成し、ビジネス・ルール・コンポーネントを追加します。

ビジネス・ルールを使用するSOAアプリケーションを作成する手順は、次のとおりです。

1. SOAアプリケーションおよびプロジェクトを作成します。詳細は、「SOAアプリケーションおよびプロジェクトの作成方法」を参照してください。ビジネス・ルールを使用するSOAコンポジットでは、アプリケーションに必要なテクノロジを選択します。たとえば、ビジネス・ルールを使用するSOAアプリケーションには、ADF Business Components、Java、XMLなどが必要な場合があります。「プロジェクト・テクノロジ」タブで、これらの項目を「選択済」領域に移動します。

2. 「アプリケーション」ウィンドウにSOAコンポジット・エディタが表示されていない場合は、プロジェクトの「SOAコンテンツ」フォルダを開き、「composite.xml」をダブルクリックしてSOAコンポジット・エディタを起動します。

3. 図25-12 に示すように、「コンポーネント」ウィンドウで、「SOA」メニューの「サービス・コンポーネント」領域から、SOAコンポジット・エディタの「コンポーネント」レーンに、「ビジネス・ルール」をドラッグ・アンド・ドロップします。

図25-12 SOAコンポジット・アプリケーションへのビジネス・ルールの追加

4. 「ビジネス・ルール」をドラッグ・アンド・ドロップすると、図25-13 に示すように、Oracle JDeveloperの「ビジネス・ルールの作成」ダイアログが表示されます。

図25-13 SOAコンポジットへのビジネス・ルールの追加およびディクショナリの作成

25.5.1.1 ビジネス・ルールへの入力の追加方法

ビジネス・ルールに入力を追加する手順は、次のとおりです。

1. 「ビジネス・ルールの作成」ダイアログ・ボックスで、「追加」アイコンの横にあるメニューから「入力...」を選択し、ビジネス・ルールの入力を追加します。「タイプ・チューザ」ダイアログが表示されます。

2. 「タイプ・チューザ」ダイアログで入力を追加します。「プロジェクトのスキーマ・ファイル」でスキーマが使用可能になっている場合は、ステップ9に移動して適切なスキーマを選択します。

3. 「スキーマ・ファイルのインポート...」アイコンをクリックします。「スキーマ・ファイルのインポート」ダイアログが表示されます。

4. 「スキーマ・ファイルのインポート」ダイアログで、「リソースの参照」をクリックし、入力するXMLスキーマ要素を選択します。「SOAリソース・ブラウザ」ダイアログが表示されます。

5. 「SOAリソース・ブラウザ」ダイアログで、ナビゲートしてビジネス・ルールを入力するスキーマを検索します。たとえば、order.xsdスキーマ・ファイルを選択して、「OK」をクリックします。

6. 図25-14 に示すように、「スキーマ・ファイルのインポート」ダイアログで、「プロジェクトにコピー」を選択します。

図25-14 ビジネス・ルールを入力するスキーマのインポート

7. 「スキーマ・ファイルのインポート」ダイアログで「OK」をクリックします。

8. 「ファイルのローカライズ」ダイアログで「OK」をクリックします。

9. 「タイプ・チューザ」ダイアログのナビゲータを使用して、スキーマから入力を検索して選択し、「OK」をクリックします。たとえば、入力としてCustomerOrder要素を選択します。

25.5.1.2 ビジネス・ルールへの出力の追加方法

ビジネス・ルールに出力を追加する手順は、次のとおりです。

1. 「ビジネス・ルールの作成」ダイアログで、「追加」アイコンの横にあるドロップダウン・メニューから「出力...」を選択します。

2. 「タイプ・チューザ」ダイアログで、入力の追加と同様の方法で出力を追加します。たとえば、order.xsdからOrderApprovalを選択し、「OK」をクリックします。

3. 図25-15 に示すように、「ビジネス・ルールの作成」ダイアログが表示されます。

図25-15 入力と出力が指定された「ビジネス・ルールの作成」ダイアログ

25.5.1.3 オプションを設定してデシジョン・サービスとビジネス・ルール・ディクショナリを作成する方法

デシジョン・サービスとビジネス・ルール・ディクショナリを作成する手順は、次のとおりです。

1. 「ビジネス・ルールの作成」ダイアログで、「コンポジット・サービスとして公開」を選択します。

2. デフォルトのサービス名を使用しない場合は、「詳細」タブを選択し、「サービス名」フィールドにサービス名を入力します。

3. 「ビジネス・ルールの作成」ダイアログで「OK」をクリックします。これにより、ビジネス・ルール・コンポーネント(デシジョン・コンポーネントとも呼ばれます)が作成され、図25-16 に示すように、Oracle JDeveloperのキャンバス・ワークスペースにビジネス・ルール・コンポーネントが表示されます。

図25-16 SOAコンポジットのビジネス・ルール・コンポーネント

4. 図25-17 に示すように、デシジョン・コンポーネントをダブルクリックすると、ルール・デザイナが開きます。検証ログには、入力および出力ファクトに関する検証警告が表示されます。ルール・デザイナを使用してルールまたはデシジョン表を定義することで、これらの警告メッセージを取り除きます。

図25-17 SOAコンポジット・アプリケーションの新規ディクショナリが表示されているルール・デザイナ

ルール・デザイナの詳細は、『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

SOAインストールには、動詞ルールおよびビジネス・フレーズがないことに注意してください。これはBPMの機能です。

25.5.2 ビジネス・ルール・コンポーネントでのデシジョン関数の選択および変更方法

をコンポジット・アプリケーションのコンポーネントとしてコールするために、1つ以上のデシジョン関数を入力として指定できます。たとえば、ディクショナリで複数のデシジョン関数が使用可能な場合は、特定のデシジョン関数を入力として指定できます。

コンポジット・アプリケーションでデシジョン関数を指定する手順は、次のとおりです。

1. デシジョン関数をディクショナリに追加します。詳細は、『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

2. ビジネス・ルール・コンポーネントをコンポジット・アプリケーションに追加します。詳細は、「SOAコンポジット・アプリケーションへのビジネス・ルールの追加方法」を参照してください。

3. 図25-18 に示すように、ビジネス・ルール・コンポーネントを選択します。

図25-18 コンポジット・アプリケーションでのビジネス・ルール・コンポーネントの選択

4. 目的のデシジョン関数ポートを選択します。たとえば、図25-19 に示すように、DF_2のポートを選択します。

図25-19 ビジネス・ルール・コンポーネントでのデシジョン関数ポートの選択

5. ポートを選択すると、Oracle JDeveloperの「プロパティ・インスペクタ」にポート情報が表示されます。

6. ポートをダブルクリックすると、図25-20 に示すように、そのポートの「インタフェースの更新」ダイアログが表示されます。

図25-20 ビジネス・ルール・デシジョン・ポートのデシジョン関数に対する「インタフェースの更新」ダイアログ

25.6 コンポジット・アプリケーションでのビジネス・ルールの実行

ビジネス・ルールは、SOAコンポジット・アプリケーションのデシジョン・コンポーネントの一部として実行します。ビジネス・ルールは、ビジネス・ルール・サービス・エンジンによって実行されます。Oracle Enterprise Manager Fusion Middleware Controlを使用して、ビジネス・ルール・サービス・エンジンを監視したり、デシジョン・コンポーネントが含まれているSOAコンポジット・アプリケーションをテストできます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

25.6.1 スタンドアロン・デシジョン・サービス・コンポーネントのテストに関する必知事項

Oracle Enterprise Manager Fusion Middleware Controlを使用してスタンドアロン・デシジョン・サービス・コンポーネントをテストするには、図25-21 に示すように、「Webサービスのテスト」ページのペイロード名フィールドの値としてデシジョン・サービスの名前を指定する必要があります。

図25-21 スタンドアロン・デシジョン・サービスのテストの起動

ペイロードのnameは、図25-22 のサンプル.decsファイルに示すように、デシジョン・サービス名にする必要があります。

図25-22 サンプル.decsファイル

デシジョン・サービス名がない場合、ペイロードおよびエンドポイントの詳細のみではスタンドアロン・デシジョン・サービスを起動できません。

25.7 ビジネス・ルールとOracle ADF Business Componentsファクト・タイプの使用

Oracle ADF Business Componentsファクト・タイプおよびActionTypesは、ビジネス・ルール・サービス・エンジンから使用できます。通常、デシジョン・コンポーネントはSOAコンポジット内で使用され、BPELコンポーネントおよびXMLタイプに関するのルールに接続できます。ビジネス・ルール・サービス・エンジンは、XMLスキーマ・タイプのインスタンスを含むペイロードが指定されたWebサービスとしてコールされ、同様の方法でレスポンスを返します。

Oracle ADF Business Componentsファクト・タイプはデシジョン・コンポーネントから使用することもできます。Oracle ADF Business Componentsファクト・タイプ・インスタンスをロードしてビジネス・ルール・サービス・エンジンに渡すかわりに、Oracle ADF Business Componentsビュー・オブジェクト行のロード方法を記述した構成情報を指定してビジネス・ルール・サービス・エンジンをコールします。その結果、DecisionPointDictionaryの特別なデシジョン関数および APIのクラスによって行がロードされ、Oracle ADF Business Componentsファクト・タイプ・インスタンスがアサートされます。Oracle ADF Business Componentsファクト・タイプを使用する場合は、基礎となるデータベース行を更新するようなOracle ADF Business Componentsファクト・タイプ・インスタンスの変更など、操作に影響を与えるActionTypeから継承するユーザー定義Javaクラスを使用するルールを記述します。

デシジョン・コンポーネントには、入力としてXML文書が必要です。 ディクショナリには、この入力として機能するSimpleDecisionPointInputというXMLファクト・タイプが用意されています。ビジネス・ルール・サービス・コンポーネントには、Oracle ADF Business Componentsの主キーが渡されます。ビジネス・ルール・サービス・コンポーネントはユーザー定義のデシジョン関数を起動します。このデシジョン関数は、Oracle ADF Business Componentsビュー・オブジェクト・インスタンスをロードし、ルール・エンジンでアサートし、結果を次の順にマーシャリングします。

1. DecisionPointDictionary.DecisionPoint_Preprocessing_Webserviceルールセット: 事前処理ルールセットがデータベースからビジネス・コンポーネントを読み取り、ファクトとしてアサートします。

2. ユーザー定義ルールセット: ユーザー・ルールセットがこれらのファクトを照合し、ビジネス・コンポーネントを更新するためにActionTypeを拡張するファクトをアサートします。

3. DecisionPointDictionary.DecisionPoint_Postprocessing_Webserviceルールセット: 実際の更新は、事後処理ルールセットによって実行されます。ActionTypesの使用はオプションです。

ビジネス・ルール・サービス・エンジンからOracle ADF Business Componentsファクト・タイプおよびActionTypesを使用する方法の詳細は、Oracle SOA Suiteサンプルに使用可能な固有のサンプルのソース・コードを参照してください。

26 宣言コンポーネントおよびタスク・フローの使用

この章では、の様々な宣言コンポーネントおよびタスク・フローを使用して、高性能で保守しやすい対話型の多層アプリケーションを開発する方法について説明します。ここでは、Oracle Business Rulesエディタの宣言コンポーネントおよびOracle Business Rulesディクショナリ・エディタの宣言コンポーネントとタスク・フローを使用する方法について説明します。また、ADFベースのWebアプリケーションをローカライズする方法についても説明します。

この章の内容は次のとおりです。

- 宣言コンポーネントおよびタスク・フローの概要

- Oracle Business Rulesエディタの宣言コンポーネントの概要

- Oracle Business Rulesディクショナリ・エディタの宣言コンポーネントの概要

- Oracle Business Rulesディクショナリ・エディタのタスク・フローの概要

- ADFベースのWebアプリケーションのローカライズ

- 翻訳の使用

26.1 宣言コンポーネントおよびタスク・フローの概要

宣言コンポーネントは再利用可能なコンポジット・ユーザー・インタフェース(UI)コンポーネントで、他の既存のApplication Development Framework (ADF) Facesコンポーネントで構成されています。ここでは、複数のJSFページが含まれているアプリケーションを考えてみます。特定ページの複数の部分では、一連の固有のコンポーネントが使用されます。このシナリオで、一連のコンポーネントのいずれかに変更を加えた場合、通常は、該当するページの複数の部分にその変更を複製する必要があります。このアプローチでは、ページの構造とレイアウトの一貫性を維持することが困難です。一方、一連の指定コンポーネントで構成した宣言コンポーネントを定義すると、そのコンポジット宣言コンポーネントを複数の場所またはページで再利用できます。このため、宣言コンポーネントによって、時間の節約とページ間の一貫性が確保されます。これは、コンポーネントに変更を加えると、そのコンポーネントを使用しているJSFページが自動的に更新されるためです。

ADFタスク・フローは、アプリケーションに制御フローを指定する際、モジュラおよびトランザクション・メソッドを提供する再利用可能なコンポーネントです。再利用可能な一連のタスク・フローは、アプリケーションを単一の大きなJSFページ・フローとして表現する代替手段として使用でき、これによって、モジュール性が提供されます。各タスク・フローには、アプリケーションの全体的なナビゲーション計画の一部が含まれています。タスク・フローのノードはアクティビティと呼ばれます。ナビゲーションとは別に、タスク・フロー・アクティビティは、マネージドBeanでメソッドをコールしたり、特定のページを起動せずに別のタスク・フローをコールすることもできます。このため、表示されているページとは独立してビジネス・ロジックを起動できるため、再利用が容易になります。

26.2 Oracle Business Rulesエディタの宣言コンポーネントの概要

この項では、Oracle Business Rulesエディタの宣言コンポーネントについて説明します。ルール・エディタ・コンポーネントを使用してアプリケーションを作成および実行し、アプリケーションをデプロイする方法についても説明します。また、この項では、サポートされているタグや、アプリケーションのローカライズ・プロセスのリストも示します。

26.2.1 Oracle Business Rulesエディタ・コンポーネントの使用

Oracle Business Rulesエディタは、ADFベースのWebアプリケーションに埋め込むことができる宣言コンポーネントです。このコンポーネントによって、ルール編集のユーザー・インタフェースが表示され、ルール編集に関連付けられているすべてのイベントが処理されます。ルール・エディタでは、ルールの作成と編集にRules SDK2 APIが使用されます。

注意:

ルール・エディタをルール・ディクショナリ・エディタと混同しないでください。ルール・エディタは、指定したルールセット内のルールを編集するために使用されます。実際には、ルール・エディタはルール・ディクショナリ・エディタに埋め込まれています。ルール・ディクショナリ・エディタの詳細は、「Oracle Business Rulesディクショナリ・エディタの宣言コンポーネントの概要」を参照してください。

ルール・エディタを使用すると、単一のルールセットの一部である一般的なルール、動詞ルールおよびデシジョン表を作成、削除および編集できます。RuleSetModelオブジェクトを指定する必要があります。このオブジェクトは、ルール・エディタ・コンポーネントへのパラメータとして、Rules SDKルールセット・オブジェクトを囲むラッパーです。複数のルールセットを変更する必要がある場合は、複数のルール・エディタ・コンポーネントを(ルールセットごとに1つ)インスタンス化する必要があります。

ルール・エディタ・コンポーネントは、次の機能を実行します。

- 次の要素を作成、更新および削除します。

- ルールセット内のルール(図26-1 を参照)

- ルール内の簡単なテストまたは条件(「IF」領域を参照)

- ルール内のアクション(「THEN」領域を参照)

図26-1 ルールセット内の一般的なルール

- ルールセット内の動詞ルール(図26-2 を参照)

図26-2 ルールセット内の動詞ルール

- デシジョン表(図26-3 を参照)

図26-3 デシジョン表

- ルールセットおよびルールの有効日と優先度を設定します。

- ユーザー定義演算子のサポートを提供します。

- 「左の値」または「右の値」オプションを表示する「条件ブラウザ」ポップアップを提供します(図26-4 を参照)。

図26-4 条件ブラウザ

- 日付タイプを選択するための「日付」ブラウザを提供します。

- 右側の複数の式を処理する「右のオペランド」ブラウザを提供します。

- ネストされたルールのサポートを提供します。

- ルール・アクションのプロパティを編集するための「プロパティ」ブラウザを提供します(図26-5 を参照)。

図26-5 「プロパティ」ブラウザ

- カスタム式を作成する「式ビルダー」ウィンドウを提供します。

- エラー・メッセージを管理する検証パネルを提供します(図26-6 を参照)。

図26-6 エラー・メッセージを管理する検証パネル

注意:

すべての編集の完了後、コンポーネント・ユーザーはルールセットを保存する必要があります。

26.2.2 ルール・エディタ・コンポーネントを使用したサンプル・アプリケーションの作成および実行方法

この項では、ルール・エディタ・コンポーネントを使用してサンプル・アプリケーションを作成および実行するための手順を示します。

ルール・エディタ・コンポーネントを使用してADFベースのWebアプリケーションを作成するための前提条件は、使用しているコンピュータでOracle SOA SuiteとOracle JDeveloperのインストールが実行されていることです。

ルール・エディタを使用してサンプル・アプリケーションを作成する手順は、次のとおりです。

1. Oracle JDeveloperを開きます。

2. 「file」メニューから、「新」を選択します。

3. 図26-7 に示すように、「ADF Fusion Webアプリケーション」を選択して、新しいアプリケーションを作成します。

図26-7 Fusion Webアプリケーションの作成

4. 図26-8 に示すように、「アプリケーション名」フィールドにアプリケーションの名前(useRulesDCAppなど)を入力し、「次へ」をクリックします。

図26-8 汎用アプリケーションの作成

5. 他のすべてにはデフォルトを使用します。

6. 「終了」をクリックします。

7. 「ViewController」プロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。

8. 左側のメニューで「ライブラリとクラスパス」を選択します。

a. 「ライブラリの追加」ボタンをクリックします。

b. 「拡張機能」リストから「Oracle Rules」および「Oracle Rules Dictionary Component」をクリックし、「OK」をクリックします。これにより、図26-9 に示すように、コンポーネント・タグ・ライブラリRules SDKおよびRules ADFがプロジェクトに追加されます。

c. もう一度「OK」をクリックして、「プロジェクト・プロパティ」を終了します。

図26-9 ライブラリの追加

注意:

「拡張機能」リストに「Oracle Rules」および「Oracle Rules Dictionary Component」が表示されない場合は、JDeveloper内でSOA/BPMプロジェクトを開いて、必要なライブラリをロードしてください。

10. 「すべて保存」をクリックして、プロジェクトを保存します。

11. 必要なすべてのタグ・ライブラリが追加されたことを確認します。

a. 「ViewController」プロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。

b. 左側のメニューで「JSPタグ・ライブラリ」を選択し、すべてのタグ・ライブラリが追加されたかどうかを確認します(図26-10 )。

図26-10 必要なタグ・ライブラリの確認

26.2.2.1 RuleSetModelオブジェクトの作成方法

ルール・エディタ・コンポーネントには、oracle.bpel.rulesdc.model.impl.RuleSetModelオブジェクトが必要です。

RuleSetModelオブジェクトを作成する手順は、次のとおりです。

1. Javaクラス(SomeBean.javaなど)をプロジェクトに作成します。

2. Oracle JDeveloperを開きます。

3. 「ファイル」メニューから、「新規」を選択して「Javaクラス」を作成します。

4. SomeBean.javaで、RuleSetModelオブジェクトを返すメソッドを指定します。ルール・ファイルの場所およびパスを指定する必要があります。SomeBean.javaファイルの例を次に示します。

package view;import java.io.BufferedReader;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.Serializable;

import java.net.MalformedURLException;
import java.net.URL;

import oracle.bpel.rulesdc.model.decisiontable.impl.DecisionTablePrefsImpl;
import oracle.bpel.rulesdc.model.decisiontable.interfaces.DecisionTablePrefs;
import oracle.bpel.rulesdc.model.impl.IfThenPreferencesImpl;
import oracle.bpel.rulesdc.model.impl.RuleSetModel;
import oracle.bpel.rulesdc.model.interfaces.IfThenPreferences;
import oracle.bpel.rulessharedutils.impl.RulesSharedUtils;

import oracle.rules.sdk2.decisionpoint.DecisionPointDictionaryFinder;
import oracle.rules.sdk2.dictionary.DictionaryFinder;
import oracle.rules.sdk2.dictionary.RuleDictionary;
import oracle.rules.sdk2.exception.SDKException;
import oracle.rules.sdk2.ruleset.RuleSet;
import oracle.rules.sdk2.ruleset.RuleSetTable;

public class SomeBean {
//on windows
private static final String RULES_FILE1 =
"file:///D:/scratch/asuraj/system_MAIN/rules_files/ApprovalRules.rules";
/*
* on linux
private static final String RULES_FILE1 =
"file:////scratch/asuraj/backup/rules_files/ApprovalRules.rules";
*/
private RuleSetModel ruleSetModel = null;

private boolean viewOnly = true;
private DecisionTablePrefs dtPrefs;

private IfThenPreferences ifThenPrefs;

public SomeBean() {
super();
}

public RuleSetModel getRuleSetModel() {
if (ruleSetModel != null)
return ruleSetModel;
ruleSetModel = new RuleSetModel(getRuleSet());
System.out.println("ruleSetModel = " + ruleSetModel);
return ruleSetModel;
}

public RuleSet getRuleSet() {

RuleDictionary dict =
openRulesDict(RULES_FILE1, new DecisionPointDictionaryFinder());
if (dict == null)
return null;

RuleSetTable ruleSetTable = dict.getRuleSetTable();
if (ruleSetTable == null || ruleSetTable.isEmpty())
return null;

return ruleSetTable.get(0);
}

public void saveDictionary() {

RuleDictionary dict = null;
String rulesFile = null;

if (this.ruleSetModel == null)
return;
dict = this.ruleSetModel.getRuleSet().getDictionary();

if (dict == null)
return;

if (dict.isModified())
RulesSharedUtils.updateDictionary(dict);
if (!dict.isTransactionInProgress())
saveDictionary(dict, RULES_FILE1);
}

public void validate() {
if (this.ruleSetModel == null)
return;

this.ruleSetModel.validate();
}

//utility methods

public static RuleDictionary openRulesDict(String fileName,
DictionaryFinder finder) {
URL url = null;
try {
url = new URL(fileName);
} catch (MalformedURLException e) {
System.err.println(e);
return null;
}
RuleDictionary dict = null;

try {
dict = readFromDisk(url, finder);
} catch (Exception e) {
System.err.println(e);
return null;
}
return dict;
}

public static RuleDictionary readFromDisk(URL dictURL, DictionaryFinder
finder) {
BufferedReader buf = null;
try {
buf = new BufferedReader(new
InputStreamReader(dictURL.openStream(), "UTF-8"));
return RuleDictionary.readDictionary(buf, finder);
} catch (SDKException e) {
System.err.println(e);
} catch (IOException e) {
System.err.println(e);
} finally {
if (buf != null)
try {
buf.close();
} catch (IOException e) {
System.err.println(e);
}
}

return null;
}

public static boolean saveDictionary(RuleDictionary dict, String
ruleFileName) {
if (dict == null || ruleFileName == null)
return false;

if (dict.isTransactionInProgress())
System.out.println("Transaction in progress, cannot save
dictionary");

try {
writeToDisk(dict, new URL(ruleFileName));
} catch (MalformedURLException e) {
System.err.println(e);
return false;
} catch (Exception e) {
System.err.println(e);
return false;
}
return true;
}

public static void writeToDisk(RuleDictionary dic, URL dictURL) {
OutputStreamWriter writer = null;
try {
writer = new OutputStreamWriter(new
FileOutputStream(dictURL.getPath()), "UTF-8");
dic.writeDictionary(writer);
} catch (IOException e) {
System.err.println(e);
} catch (SDKException e) {
System.err.println(e);
} finally {
if (writer != null)
try {
writer.close();
} catch (IOException e) {
System.err.println(e);
}
}
}

public void toggleMode() {
viewOnly = !viewOnly;
}

public boolean isViewOnly() {
return viewOnly;
}

public DecisionTablePrefs getDtPreferences() {
if (dtPrefs == null)
dtPrefs = new DTPreferences();
return dtPrefs;
}

public IfThenPreferences getIfThenPreferences() {
if (ifThenPrefs == null)
ifThenPrefs = new MyIfThenPrefs();
return ifThenPrefs;
}
public class MyIfThenPrefs extends IfThenPreferencesImpl implements
Serializable {

@Override
public boolean isGenericAction() {
return true;
}

@Override
public boolean isGenericCondition() {
return true;
}
}

public class DTPreferences extends DecisionTablePrefsImpl implements
Serializable {

@Override
public boolean isShowDTButtons() {
return true;
}
}
}

5. adfc-config.xmlのSomeBean.javaを指します(Bean名はsomeBeanで、スコープはsessionです)。adfc-config.xmlの例を次に示します。

<?xml version="1.0" encoding="UTF-8" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2">
<managed-bean id="__1">
<managed-bean-name>someBean</managed-bean-name>
<managed-bean-class>view.SomeBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
</adfc-config>

6. ADF/JSFフレームワークによって、SomeBean.javaへのコールが複数回実行され、ユーザー・インタフェースがレンダリングされます。たとえば、someBean.ruleSetModelが複数回コールされます。そのため、毎回再作成するのではなく、ruleSetModelを一度作成したら、それをキャッシュして返すことは、より効率的です。

26.2.2.2 .jspxファイルの作成方法

次のタスクは、ルール・エディタ・コンポーネント・タグを挿入する.jspxファイルの作成です。

ルール・エディタ・コンポーネント・タグを含めるための.jspxファイルの作成手順は、次のとおりです。

1. Oracle JDeveloperを開きます。

2. 「ファイル」メニューから、「新規」を選択し、次に「JSF」を選択します。

3. 「JSFページ」を選択して、「OK」をクリックします。

4. ドキュメント・タイプに「JSP XML」を選択します。

5. ファイル名にrulesEditor.jspxを入力します。「OK」をクリックします。

6. JDeveloperの「コンポーネント」ウィンドウに「RulesEditor」が表示されます。

7. 「RulesEditor」を選択すると、「Rulesdc」タグが表示されます。

8. 「rulesdc」タグをJSPXファイルにドラッグ・アンド・ドロップします。次のようにして、「rulesDC」タグを手動でjspxファイルに追加することもできます。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1" xmlns:f="http://java.sun.com/jsf/core"
xmlns:af="http://xmlns.oracle.com/adf/faces/rich" xmlns:rdc="http://xmlns.oracle.com/bpel/rules/editor">
<jsp:directive.page contentType="text/html;charset=UTF-8"/>
<f:view>
<af:document title="rulesEditor" id="d1">
<af:form id="f1">
<af:panelGridLayout id="pgl1" inlineStyle="margin:15px;" styleClass="AFStretchWidth"
partialTriggers="cb1 cb3 cb4">
<af:gridRow id="gr2">
<af:gridCell marginStart="5px" marginEnd="5px" width="100%" halign="stretch" id="gc1">
<af:panelGroupLayout id="pgl2" layout="horizontal">
<af:commandButton text="Save Dict" action="#{someBean.saveDictionary}" id="cb1"/>
<af:spacer width="10" height="10" id="s2"/>
<af:commandButton text="Validate" id="cb3" action="#{someBean.validate}"
partialSubmit="true"/>
<af:spacer width="10" height="10" id="s8"/>
<af:commandButton text="Toggle Mode" id="cb4" action="#{someBean.toggleMode}"
partialSubmit="true"/>
</af:panelGroupLayout>
</af:gridCell>
</af:gridRow>
<af:gridRow height="100%" id="gr1">
<af:gridCell marginStart="5px" marginEnd="5px" width="100%" halign="stretch" valign="stretch"
id="gc2">
<rdc:rulesdc rulesetModel="#{someBean.ruleSetModel}" id="r1"
ifThenPreferences="#{someBean.ifThenPreferences}"
dtPreferences="#{someBean.dtPreferences}" viewOnly="#{someBean.viewOnly}"
disableVerbalRules="false"></rdc:rulesdc>
</af:gridCell>
</af:gridRow>
</af:panelGridLayout>
</af:form>
</af:document>
</f:view>
</jsp:root>

26.2.2.3 Oracle Rules共有ライブラリの参照方法

.jspxファイルを作成した後に、weblogic-application.xmlファイルから共有ライブラリoracle.rulesおよびoracle.soa.rules_dict_dc.webappを参照する必要があります。

oracle.rulesおよびoracle.soa.rules_dict_dc.webapp共有ライブラリを参照する手順は、次のとおりです。

1. Oracle JDeveloperで、「アプリケーション・リソース」から「ディスクリプタ」を開き、次に「META-INF」を開きます。weblogic-application.xmlファイルを編集して、次の行を追加します(これによってoracle.rules共有ライブラリが参照されます)。

<library-ref>
<library-name>oracle.rules</library-name>
</library-ref>

2. Oracle JDeveloperで、次のようにします。

a. 「ファイル」メニューから、「新規」を選択し、次に「デプロイメント・ディスクリプタ」を選択します。

b. 「WebLogicデプロイメント・ディスクリプタ」を選択し、リストから「weblogic.xml」を選択します。

c. 「version 12.1.2」を選択して、「終了」をクリックします。

d. weblogic.xmlの「概要」モードで、左側から「ライブラリ」を選択し、oracle.soa.rules_dict_dc.webappをライブラリ名として追加します。weblogicogic.xmlファイルの例を次に示します。

<?xml version = '1.0' encoding = 'UTF-8'?>
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app
http://xmlns.oracle.com/weblogic/weblogic-web-app/1.5/weblogic-web-app.xsd"
xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
<library-ref>
<library-name>oracle.soa.rules_dict_dc.webapp</library-name>
</library-ref>
</weblogic-web-app>

e. 「すべて保存」をクリックします。

注意:

共有ライブラリoracle.rulesおよびoracle.soa.rules_dict_dc.webappは、埋込みWLSサーバーにデプロイされている必要があることに注意してください。

3. すべての共有ライブラリは、埋込みWLSのweblogicコンソールを使用してデプロイされる必要があります。

a. WLSコンソール(http://host:port/console/login/LoginForm.jsp)を起動して、ログインします。

b. 「デプロイメント」をクリックします。
共有ライブラリoracle.rulesおよびoracle.soa.rules_dict_dc.webappが、図26-11 に示すようにデプロイされているかどうかを確認します。

図26-11 デプロイメント

4. これらの共有ライブラリがデプロイされていない場合は、手動でデプロイします。
WLS埋込みサーバーを起動する手順は、次のとおりです。

a. JDeveloperを開きます。

b. 図26-12 に示すように、「実行」を選択して、次に「サーバー・インスタンスの起動」を選択します。

図26-12 埋込みWLSの起動

共有ライブラリがすでにデプロイされている場合は、この手順をスキップします。

注意:

共有ライブラリをデプロイできるように、JDeveloper上でWLS埋込みサーバーが実行中である必要があります。

5. oracle.rules共有ライブラリをWLSにデプロイする手順は、次のとおりです。

a. WLSコンソール(http://host:port/console/login/LoginForm.jsp)を起動して、ログインします。

b. 「デプロイメント」を選択して「インストール」をクリックします。

c. 「<SOA_INSTALL>/soa/soa/modules/oracle.rules_11.1.1/rules.jar」を選択します。

d. 「次へ」をクリックし、「終了」をクリックします。

6. oracle.soa.rules_dict_dc.webapp共有ライブラリをWLSにデプロイする手順は、次のとおりです。

a. WLSコンソールで、「デプロイメント」を選択し、「インストール」をクリックします。

b. 「<SOA_INSTALL>/soa/soa/modules/oracle.soa.rules_dict_dc.webapp_11.1.1/oracle.soa.rules_dict_dc.webapp.war」を選択します。

c. 「次へ」をクリックし、「終了」をクリックします。

d. 「このデプロイメントをライブラリとしてインストールする」を選択します。

e. 「終了」をクリックします。

f. 図26-11 に示すように、oracle.soa.rules_dict_dc.webappがデプロイメントのリストに追加されます。

26.2.2.4 サンプル・アプリケーションの実行方法

最後のタスクは、サンプル・アプリケーションの実行です。

サンプル・アプリケーションを実行する手順は、次のとおりです。

1. サンプル・アプリケーションを実行するには、JDeveloperで「rulesEditor.jspx」ファイルを右クリックします。

2. 「実行」を選択します。

これにより、図26-13 に示すように、サンプル・アプリケーションがブラウザで開始されます。

図26-13 ルール・エディタの実行

26.2.3 スタンドアロンWLSへのルール・エディタ・アプリケーションのデプロイ方法

アプリケーションEARファイルをスタンドアロンOracle WebLogic Serverにデプロイする準備が整った場合は、次の手順を実行します。

1. 共有ライブラリが、スタンドアロンWLSのweblogicコンソールを使用してデプロイされているかどうかを確認します。

a. WLSコンソール(http://host:port/console/login/LoginForm.jsp)を起動して、ログインします。

b. 「デプロイメント」をクリックします。共有ライブラリoracle.rulesおよびoracle.soa.rules_dict_dc.webappが、図26-11 に示すようにデプロイされているかどうかを確認します。

2. 共有ライブラリがデプロイされていない場合は、前述の手順を参照して共有ライブラリを手動でデプロイします。

3. ルール・エディタ・コンポーネントを使用するプロジェクトで、次の手順を実行します。

a. 「Oracle Rules Dictionary Component」を「ライブラリとクラスパス」に含めます。

これによってこれらのライブラリがデフォルトでデプロイされることはないため、JARはプロジェクトのWARファイルには含まれません。

4. デプロイするプロジェクト(EARファイルを作成する場所)で、次の手順を実行します。

a. weblogic-application.xmlに次を追加します。

<library-ref>
<library-name>oracle.rules</library-name>
</library-ref>

b. プロジェクトのWARファイルのweblogic.xmlに、次を追加します。

<library-ref>
<library-name>oracle.soa.rules_dict_dc.webapp</library-name>
</library-ref>

5. WLSでEARファイルをデプロイします。

EARの作成方法の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Java EE開発者ガイド』のデプロイメントのためのEARファイルの作成方法に関する項を参照してください。

26.2.4 ルール・エディタ・コンポーネントのカスタム権限に関する必知事項

ロールベースの認可について、Rules DCはカスタムJAAS権限を実装しています(oracle.adf.share.security.authorization.ADFPermissionクラスを拡張し、ADFセキュリティで権限を使用できるようにします)。

ルール・エディタ・アプリケーションでADFセキュリティがサポートされている場合は、ロールベースの認証および認可がサポートされていることになりますが、この場合、セキュリティはカスタムJAAS権限を実装して施行します(oracle.adf.share.security.authorization.ADFPermissionクラスを拡張してADFセキュリティで権限が使用されるようにします)。アプリケーション要件に基づいてユーザー・ロールに次の権限を付与してADFセキュリティ・ポリシーを作成する必要があります。

- oracle.rules.adf.permission.AddRulePermission: 「ルールの追加」ボタンが表示されますが、この権限が付与されていない場合、「ルールの追加」ボタンはユーザーに表示されません。

- oracle.rules.adf.permission.DeleteRulePermission: 「ルールの削除」ボタンが表示されますが、この権限が付与されていない場合、「ルールの削除」ボタンはユーザーに表示されません。

- oracle.rules.adf.permission.EditRulePermission: ルールセット内のルールについて「ルールの編集」ボタンが表示されますが、この権限が付与されていない場合、ルールは表示のみとなります。

- oracle.rules.adf.permission.AddDTPermission: 「デシジョン表の追加」ボタンが表示されますが、この権限が付与されていない場合、「デシジョン表の追加」ボタンはユーザーに表示されません。

- oracle.rules.adf.permission.DeleteDTPermission: 「デシジョン表の削除」ボタンが表示されますが、この権限が付与されていない場合、「デシジョン表の削除」ボタンはユーザーに表示されません。

- oracle.rules.adf.permission.EditDTPermission: ルールセット内のデシジョン表について「デシジョン表の編集」ボタンが表示されますが、この権限が付与されていない場合、デシジョン表は表示のみとなります。

- oracle.rules.adf.permission.RulesEditorPermission: 前述の権限をすべてtrueに設定するグローバル権限。

たとえば、「ルールの削除」権限をロールに付与するには、アプリケーションのjazn-data.xmlファイルに次のコードを指定します。

<policy-store>
<applications>
<application>
<name>UseRuleDictDCWtPerm</name>
<app-roles>
<app-role>
<name>Admin</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<display-name>Admin</display-name>
<members>
<member>
<name>admin</name>
<class>oracle.security.jps.internal.core.principals.JpsXmlUserImpl</class>
</member>
</members>
</app-role>
<app-role>
<name>BusinessUser</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<display-name>BusinessUser</display-name>
<members>
<member>
<name>buser</name>
<class>oracle.security.jps.internal.core.principals.JpsXmlUserImpl</class>
</member>
</members>
</app-role>
</app-roles>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>Admin</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.rules.adf.permission.RulesEditorPermission</class>
<name>RulesEditorPermission</name>
<actions>access</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>

AddRulePermissionまたはDeleteRulePermissionなど、個々の権限を使用しない場合は、jazn-data.xmlファイルにRulesEditorPermissionを設定し、グローバル権限を設定します。

26.2.5 ルール・エディタ・コンポーネントのサポートされているタグに関する必知事項

この項では、ルール・エディタ・コンポーネントでサポートされているタグおよび属性のリストを示します。

表26-1 に、サポートされている属性のリストを示します。

表26-1 ルール・エディタ・コンポーネントのサポートされている属性

名前

タイプ

必要

デフォルト値

ELをサポートしているかどうか

説明

rulesetModel

oracle.bpel.rulesdc
.model.interfaces.R
uleSetInterface

はい

ELのみ

Rules SDKルールセット・オブジェクトのラッパーです。ユーザーは、ルール・エディタ・コンポーネントの一部として提供されているRuleSetModelオブジェクトを使用できます。

ruleModel

java.lang.String

いいえ

oracle.bpel.
rulesdc.mode
l.impl.RuleM
odel

はい

デフォルトのRuleModelのカスタマイズに使用します。ユーザーは、RuleModelクラスを拡張して、特定のメソッドをオーバーライドできます。非推奨。ifThenPreferences属性を使用して、getRuleModel()をオーバーライドします。

simpleTestModel

java.lang.String

いいえ

oracle.bpel
.rulesdc.mo
del.impl.Si
mpleTestMod
el

はい

デフォルトのSimpleTestModelのカスタマイズに使用します。ユーザーは、SimpleTestModelクラスを拡張して、特定のメソッドをオーバーライドできます。非推奨。ifThenPreferences属性を使用して、getSimpleTestModel()をオーバーライドします。

viewOnly

java.lang.Boolean

いいえ

true

はい

viewOnlyモードで、ユーザーは、ルールセット内の既存のルールを表示できます。falseの場合、ユーザーは、「編集」モードで、ルールを新規に追加したり、既存のルールを編集できます。

genericPattern

java.lang. Boolean

いいえ

true

はい

非推奨であり使用されません。

genericAction

java.lang.Boolean

いいえ

true

はい

非推奨であり使用されません。

locale

java.util.Locale

いいえ

Locale.getDe
fault()

はい

ローカライズに使用します。

timezone

java.util.TimeZone

いいえ

TimeZone.get
Default()

はい

ローカライズに使用します

displayRuleSetEffDate

java.lang.Boolean

いいえ

true

はい

非推奨であり使用されません。

discloseRules

java.lang.Boolean

いいえ

false

はい

非推奨であり使用されません。

displayRuleSetName

java.lang.Boolean

いいえ

false

はい

非推奨であり使用されません。

disableRuleSetName

java.lang.Boolean

いいえ

false

はい

非推奨であり使用されません。

dtColumnPageSize

java.lang. Integer

いいえ

5

はい

非推奨であり使用されません。

dtHeight

java.lang. Integer

いいえ

16

はい

非推奨であり使用されません。

dateStyle

java.lang.String

いいえ

ロケールから取得

はい

指定された場合、その日付スタイルがすべてのinputDateコンポーネントで使用されます。例: yyyy.MM.dd

timeStyle

java.lang.String

いいえ

ロケールから取得

はい

指定された場合、その時間スタイルがすべてのinutDateコンポーネントで使用されます(例: HH:mm:ss)。

showValidationPanel

java.lang.Boolean

いいえ

true

はい

検証パネルがデフォルトで表示されます。ユーザーは、これをfalseに設定することで、非表示にできます。

showDTButtons

java.lang.Boolean

いいえ

true

はい

非推奨であり使用されません。

rulesPageSize

java.lang.Integer

いいえ

5

はい

非推奨であり使用されません。

decimalSeparator

java.lang. Character

いいえ

ロケールに基づく

はい

小数セパレータの指定に使用します。これは数値書式に使用されます。指定された場合、ロケールに基づく小数セパレータをオーバーライドします。

groupingSeparator

java.lang.Character

いいえ

ロケールに基づく

はい

グループ化セパレータの指定に使用します。これは数値書式に使用されます。指定された場合、ロケールに基づくグループ化セパレータをオーバーライドします。

disableVerbalRules

java.lang.Boolean

いいえ

true

はい

trueの場合、言語化UIを無効化します。

vldnPanelCollapsed

java.lang.Boolean

いいえ

false

はい

検証パネルがデフォルトで縮小されているかどうかを指定するために使用されます。

vldnTabTitle

java.lang. String

いいえ

-

はい

検証パネルのタイトルを指定するために使用されます。

genericDTAddActionMenu

java.lang.Boolean

はい

true

はい

trueの場合、デシジョン表ツールバーに、汎用のアクションの追加メニューが表示されます。falseの場合、コンシューマは、dtAddActionMenuDDC属性を使用してアクションの追加メニューを指定する必要があります。非推奨。dtPreferences属性を使用し、isGenericDTAddActionMenu()をオーバーライドします。

genericDTEditAction

java.lang.Boolean

いいえ

true

はい

trueの場合、デシジョン表でアクション行を編集するときに表示されるアクション・エディタ・ブラウザに汎用アクションUIが表示されます。falseの場合、コンシューマは、dtEditActionDDC属性を使用して編集アクションUIを指定する必要があります。非推奨。dtPreferences属性を使用し、isGenericDTEditAction()をオーバーライドします。

genericDTActionParam

java.lang.Boolean

いいえ

true

はい

trueの場合、デシジョン表のアクション・パラメータ・セルに汎用UIが表示されます。falseの場合、コンシューマは、dtActionParamCellDDC属性を使用してアクション・パラメータ・セルUIを指定する必要があります。非推奨。dtPreferences属性を使用し、isGenericDTActionParam()をオーバーライドします。

dtAddActionMenuDDC

jjava.lang.String

いいえ

-

はい

genericDTAddActionMenuがtrueの場合にのみ使用されます。コンシューマは、デシジョン表ツールバーで追加メニュー項目を指定するコンテキスト・パスなどのDDC (動的宣言コンポーネント)を渡す必要があります。たとえば、/userulesdc/decisiontable/dtAddActionMenu.jsffです。非推奨。dtPreferences属性を使用し、getDtAddActionMenuDDC()をオーバーライドします。

dtEditActionDDC

java.lang. String

いいえ

-

はい

genericDTEditActionがtrueの場合にのみ使用されます。コンシューマは、デシジョン表でアクション行を編集するときに表示されるアクション・エディタ・ブラウザに表示されるアクションUIを指定するコンテキスト・パスなどのDDC (動的宣言コンポーネント)を渡す必要があります。たとえば、/userulesdc/decisiontable/actionEditor.jsffです。非推奨。dtPreferences属性を使用し、getDtEditActionDDC()をオーバーライドします。

dtActionParamCellDDC

java.lang. String

いいえ

-

はい

genericDTActionParamがtrueの場合にのみ使用されます。コンシューマは、デシジョン表のアクション・パラメータ・セルに表示されるUIを指定するコンテキスト・パスなどのDDC (動的宣言コンポーネント)を渡す必要があります。たとえば、/userulesdc/decisiontable/actionParamCell.jsffです。非推奨。dtPreferences属性を使用し、getDtActionParamCellDDC()をオーバーライドします。

dtActionNameCustomizer

oracle.bpel.rulesdc
.model.interfaces.A
ctionNameCustomizer

いいえ

-

はい

デシジョン表ヘッダーでアクション名およびアクション・パラメータ名を指定するために使用されます。非推奨。dtPreferences属性を使用し、getDtActionNameCustomizer()をオーバーライドします。

dtPreferences

oracle.bpel.rulesdc
.model.decisiontabl
e.interfaces.Decisi
onTablePrefs

いいえ

oracle.bpel.
rulesdc.mode
l.decisionta
ble.impl.Dec
isionTablePr
efsImpl

はい

デシジョン表プリファレンスを指定するために使用されます。コンシューマは、デフォルトの実装(oracle.bpel.rulesdc.model.decisiontable.impl.DecisionTablePrefsImpl)を拡張し、必要なプリファレンスのみをオーバーライドできます。

ifThenPreferences

oracle.bpel.rulesdc
.model.interfaces.I
fThenPreferences

いいえ

oracle.bpel.
rulesdc.mode
l.impl.IfThe
nPreferences
Impl

はい

検証パネルがデフォルトで縮小されているかどうかを指定するために使用されます。

resourceManager

joracle.bpel.ruless
hareddc.model.inter
faces.ResourceManag
erInterface

いいえ

-

はい

翻訳UIのリソース・マネージャを指定するために使用されます。変換に関する項を参照してください。

verbalRuleGotoDSLListener

oracle.bpel.rulessh
areddc.model.interf
aces.VerbalRuleGoto
LinkListener

いいえ

-

はい

動詞ルールで「フレーズに移動」リンクがクリックされると、リスナー・オブジェクトがトリガーされます。

26.3 Oracle Business Rulesディクショナリ・エディタの宣言コンポーネントの概要

この項では、Oracle Business Rulesディクショナリ・エディタの宣言コンポーネントについて説明します。ルール・ディクショナリ・エディタ・コンポーネントを使用してアプリケーションを作成および実行し、アプリケーションをデプロイする方法についても説明します。また、この項では、サポートされているタグや、アプリケーションのローカライズ・プロセスのリストも示します。

26.3.1 Oracle Business Rulesディクショナリ・コンポーネントの使用

ルール・ディクショナリ・エディタ・コンポーネントはADF宣言コンポーネントであり、Rules SDK2 APIを使用して、ルールセット、値セット、グローバル、デシジョン関数などのBusiness Rulesメタデータ・アーティファクトを編集できます。

ルール・ディクショナリ・エディタ・コンポーネントを、主に指定したルールセット内でルールの編集に使用されるルール・エディタ・コンポーネントと混同しないでください。ルール・ディクショナリ・コンポーネントは、グローバル、値セット、ルールセットなどの編集が可能なコンポジット・コンポーネントです。ルール・ディクショナリ・エディタのタスク・フローでは、ルール・ディクショナリ・エディタ・コンポーネントを使用します。

ルール・ディクショナリ・エディタ・コンポーネントには、次の機能があります。

- ルールセットおよびルールセット内の一般的なルール、動詞ルールおよびデシジョン表でのCRUD (作成/読取り/更新/削除)操作

- ビジネス・フレーズ(言語化で使用される)でのCRUD (作成/読取り/更新/削除)操作

- 値セットでのでのCRUD (作成/読取り/更新/削除)操作

- グローバル/変数でのCRUD (作成/読取り/更新/削除)操作

- デシジョン関数でのCRUD (作成/読取り/更新/削除)操作

- RLファクトおよびXMLファクトでのCRUD (作成/読取り/更新/削除)操作、およびその他すべてのファクト・タイプの表示

- リンクされたディクショナリの表示。

- ユーザー定義の変換のサポート

- すべてのディクショナリ・コンポーネントのカット/コピー/ペースト

- ディクショナリの異なるバージョンの比較およびマージ(diff/mergeのサポート)

- デシジョン表のExcelへのエクスポート

ルール・ディクショナリ・エディタのタスク・フローでは、ルール・ディクショナリ・エディタ・コンポーネントを使用してアプリケーションを作成します。通常は、ルール・ディクショナリ・エディタ・コンポーネントまたはルール・ディクショナリ・エディタのタスク・フローのいずれかを使用します(両方は使用しません)。ルール・ディクショナリ・エディタのタスク・フローの詳細は、「Oracle Business Rulesディクショナリ・エディタのタスク・フローの概要」を参照してください。

ルール・ディクショナリ・エディタ・コンポーネントでは、次のことが実行できます。

- グローバル・エディタを使用して、final属性がtrueに設定されているグローバルまたは変数を編集します(図26-14 を参照)。

図26-14 グローバル・エディタ

グローバル・エディタでは、名前、説明、値を作成、削除、編集し、値セットを変更し、タイプを変更し、グローバル・ファイナルを作成できます。グローバルの検証がサポートされています。

- 値セット・エディタを使用して、値セットを編集します(図26-15 を参照)。

図26-15 値セット・エディタ

値セット・エディタでは、値セットおよび値セット内の範囲でCRUD (作成、読取り、更新および削除)操作を実行できます。値セットの検証もサポートされています。

- ルールセットを編集します(図26-16 を参照)。

図26-16 ルールセットの編集

ルール・ディクショナリ・エディタで編集できるのは、選択したルールセット内のルールのみです。ルールセットを作成または削除することはできません。

- 一般的なルールを編集します(図26-17 を参照)。

図26-17 一般的なルール

- 動詞ルールを編集します(図26-18 を参照)。

図26-18 動詞ルール

- デシジョン表を編集します(図26-19 を参照)。

図26-19 デシジョン表

- ビジネス・フレーズを編集します(図26-20 を参照)。

図26-20 「ビジネス・フレーズ」タブ

- エクスプローラを表示します(図26-21 を参照)。

図26-21 「エクスプローラ」タブ

- ファクトを編集します(図26-22 を参照)。

図26-22 「ファクト」タブ

- デシジョン関数を編集します(図26-23 を参照)。

図26-23 「デシジョン関数」タブ

- 変換を編集します(図26-24 を参照)。

図26-24 「変換」タブ

- ルールを検証するためにテストを作成して実行します(図26-25 を参照)。

図26-25 「テスト」タブ

これらの機能およびタブの詳細は、『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

26.3.2 ルール・ディクショナリ・エディタ・コンポーネントを使用したサンプル・アプリケーションの作成および実行方法

この項では、ルール・ディクショナリ・エディタ・コンポーネントを使用してサンプル・アプリケーションを作成および実行するための手順を示します。

ルール・ディクショナリ・エディタ・コンポーネントを使用してADFベースのWebアプリケーションを作成するための前提条件は、JDeveloperとSOAがインストールされていることです。最初のタスクはサンプル・アプリケーションの作成です。

ルール・ディクショナリ・エディタ・コンポーネントを使用してサンプル・アプリケーションを作成する手順は、次のとおりです。

1. Open JDeveloperを開いて、図26-26 に示すように、「ファイル」メニューから、「新規」を選択し、次に「ADF Fusion Webアプリケーション」を選択して新しいアプリケーションを作成します。

図26-26 Fusion Webアプリケーションの作成

2. 図26-27 に示すように、「アプリケーション名」フィールドにアプリケーションの名前(たとえば、UseRuleDictDCApp)を入力し、「次へ」をクリックします。

図26-27 汎用アプリケーションの作成

3. 他のすべてにはデフォルトを使用します。

4. 「終了」をクリックします。

5. 「ViewController」プロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。左側のメニューで「ライブラリとクラスパス」を選択します。

a. 「ライブラリの追加」をクリックします。

b. 「拡張機能」リストから「Oracle Rules」および「Oracle Rules Dictionary Component」を選択し、「OK」をクリックします。これにより、図26-28 に示すように、コンポーネント・タグ・ライブラリRules SDKおよびRules ADFがプロジェクトに追加されます。

図26-28 ライブラリの追加

注意:

「拡張機能」リストに「Oracle Rules」および「Oracle Rules Dictionary Component」が表示されない場合は、JDeveloper内でSOA/BPMプロジェクトを開いて、必要なライブラリをロードしてください。

c. もう一度「OK」をクリックして、「プロジェクト・プロパティ」を終了します。

6. 「すべて保存」をクリックして、プロジェクトを保存します。

7. 必要なすべてのタグ・ライブラリが追加されたことを確認します。

a. 「ViewController」プロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。

b. 左側のメニューで「JSPタグ・ライブラリ」を選択し、図26-29 に示すように、すべてのタグ・ライブラリが追加されたかどうかを確認します。

図26-29 JSPタグ・ライブラリ

26.3.2.1 RuleDictionaryModelオブジェクトの作成方法

ルール・ディクショナリ・エディタ・コンポーネントには、RuleDictionaryModelオブジェクトを作成するために、oracle.bpel.ruledictionarydc.model.impl.RuleDictionaryModelオブジェクトが必要です。

RuleDictionaryModelオブジェクトを作成する手順は、次のとおりです。

1. プロジェクトにJavaクラス(たとえばSomeBean.java)を作成するには、「ファイル」メニューから、「新規」を選択し、次に「Javaクラス」を選択します。

2. SomeBean.javaで、RuleDictionaryModelオブジェクトを返すメソッドを指定します。このルール・ファイルの場所およびパスを指定する必要があります。SomeBean.javaの例を次に示します。

package view;

import java.io.BufferedReader;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.Serializable;

import java.net.MalformedURLException;
import java.net.URL;

import oracle.bpel.ruledictionarydc.model.impl.RuleDictionaryModel;
import oracle.bpel.ruledictionarydc.model.impl.RulesEditorPreferencesImpl;
import oracle.bpel.ruledictionarydc.model.interfaces.RulesEditorPreferences;
import oracle.bpel.rulesdc.model.decisiontable.impl.DecisionTablePrefsImpl;
import oracle.bpel.rulesdc.model.decisiontable.interfaces.DecisionTablePrefs;
import oracle.bpel.rulesdc.model.impl.IfThenPreferencesImpl;
import oracle.bpel.rulesdc.model.interfaces.IfThenPreferences;
import oracle.bpel.rulessharedutils.impl.RulesSharedUtils;

import oracle.rules.sdk2.decisionpoint.DecisionPointDictionaryFinder;
import oracle.rules.sdk2.dictionary.DictionaryFinder;
import oracle.rules.sdk2.dictionary.RuleDictionary;
import oracle.rules.sdk2.exception.SDKException;

public class SomeBean {
private RuleDictionaryModel ruleDictModel;
private RulesEditorPreferences rulesEditorPrefs;
private boolean viewOnly = true;

//on windows
//private static final String RULES_FILE1 =
"file:///D:/scratch/asuraj/system_MAIN/rules_
files/insurancequoteproject/CarInsuranceRules.rules";

// on linux
private static final String RULES_FILE1 =
"file:////scratch/asuraj/backup/rules_files/ApprovalRules.rules";

public SomeBean() {
super();
}

public RuleDictionaryModel getRuleDictModel() {
if (ruleDictModel != null)
return ruleDictModel;

ruleDictModel = new RuleDictionaryModel(openRulesDict(RULES_FILE1, new
DecisionPointDictionaryFinder()));
return ruleDictModel;
}

public void saveDictionary() {
RuleDictionary dict = null;

if (this.ruleDictModel == null)
return;
dict = this.ruleDictModel.getRuleDictionary().getDictionary();

if (dict == null)
return;

if (dict.isModified())
RulesSharedUtils.updateDictionary(dict);
if (!dict.isTransactionInProgress())
saveDictionary(dict, RULES_FILE1);
}

public void validate() {
if (this.ruleDictModel == null)
return;

this.ruleDictModel.validate();
}

public void toggleMode() {
viewOnly = !viewOnly;
}

public boolean isViewOnly() {
return viewOnly;
}

public RulesEditorPreferences getRulesEditorPrefs() {
if (rulesEditorPrefs == null)
rulesEditorPrefs = new MyRulesEditorPrefs();
return rulesEditorPrefs;
}

//utility methods

public static RuleDictionary openRulesDict(String fileName, DictionaryFinder finder) {
URL url = null;
try {
url = new URL(fileName);
} catch (MalformedURLException e) {
System.err.println(e);
return null;
}
RuleDictionary dict = null;

try {
dict = readFromDisk(url, finder);
} catch (Exception e) {
System.err.println(e);
return null;
}
return dict;
}

public static RuleDictionary readFromDisk(URL dictURL, DictionaryFinder
finder) {
BufferedReader buf = null;
try {
buf = new BufferedReader(new
InputStreamReader(dictURL.openStream(), "UTF-8"));
return RuleDictionary.readDictionary(buf, finder);
} catch (SDKException e) {
System.err.println(e);
} catch (IOException e) {
System.err.println(e);
} finally {
if (buf != null)
try {
buf.close();
} catch (IOException e) {
System.err.println(e);
}
}
return null;    }    public static boolean saveDictionary(RuleDictionary dict, String
ruleFileName) {
if (dict == null || ruleFileName == null)
return false;

if (dict.isTransactionInProgress())
System.out.println("Transaction in progress, cannot save
dictionary");

try {
writeToDisk(dict, new URL(ruleFileName));
} catch (MalformedURLException e) {
System.err.println(e);
return false;
} catch (Exception e) {
System.err.println(e);
return false;
}
return true;
}

public static void writeToDisk(RuleDictionary dic, URL dictURL) {
OutputStreamWriter writer = null;
try {
writer = new OutputStreamWriter(new
FileOutputStream(dictURL.getPath()), "UTF-8");
dic.writeDictionary(writer);
} catch (IOException e) {
System.err.println(e);
} catch (SDKException e) {
System.err.println(e);
} finally {
if (writer != null)
try {
writer.close();
} catch (IOException e) {
System.err.println(e);
}
}
}

public class MyRulesEditorPrefs extends RulesEditorPreferencesImpl
implements Serializable {

private DecisionTablePrefs dtPrefs;
private IfThenPreferences ifThenPrefs;

@Override
public DecisionTablePrefs getDecisionTablePreferences() {
if (dtPrefs == null)
dtPrefs = new DTPreferences();
return dtPrefs;
}

@Override
public IfThenPreferences getIfThenPreferences() {
if (ifThenPrefs == null)
ifThenPrefs = new MyIfThenPrefs();
return ifThenPrefs;
}

@Override
public boolean isShowRSButtons() {
return true;
}
}

public class MyIfThenPrefs extends IfThenPreferencesImpl implements
Serializable {

@Override
public boolean isGenericAction() {
return true;
}

@Override
public boolean isGenericCondition() {
return true;
}
}    public class DTPreferences extends DecisionTablePrefsImpl implements
Serializable {

@Override
public boolean isShowDTButtons() {
return true;
}
}
}

3. adfc-config.xmlのSomeBean.javaを指します(Bean名はsomeBeanで、スコープはsessionです)。adfc-config.xmlの例を次に示します。

4. 「項目」で「Javaクラス」が選択されていることを確認し、「OK」をクリックして「Javaクラスの作成」ダイアログ・ボックスを表示します。

<?xml version="1.0" encoding="UTF-8" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2">
<managed-bean id="__1">
<managed-bean-name>someBean</managed-bean-name>
<managed-bean-class>view.SomeBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
</adfc-config>

5. ADF/JSFフレームワークによって、SomeBean.javaへのコールが複数回実行され、ユーザー・インタフェースがレンダリングされます。たとえば、someBean.ruleDictModelが複数回コールされます。そのため、毎回再作成するのではなく、ruleDictModelを一度作成したら、それをキャッシュして返すことは、より効率的です。

26.3.2.2 ルール・ディクショナリ・エディタ・コンポーネントの.jspxファイルの作成手順

次のタスクは、ルール・ディクショナリ・エディタ・コンポーネント・タグを挿入する.jspxファイルの作成です。

ルール・ディクショナリ・エディタ・コンポーネント・タグの.jspxファイルを作成する手順は、次のとおりです。

1. Oracle JDeveloperを開きます。

2. 「ファイル」メニューから、「新規」を選択し、次に「JSF/Facelets」を選択します。

3. 「JSFページ」を選択して、「OK」をクリックします。

4. ドキュメント・タイプに「JSP XML」を選択します。

5. ファイル名にruleDictEditor.jspxを入力します。「OK」をクリックします。

6. JDeveloperの「コンポーネント」ウィンドウに「RuleDictionaryDC」が表示されます(図26-30 を参照)。

図26-30 「コンポーネント」ウィンドウ

7. 「RuleDictionaryDC」を選択すると、「RuleDictionaryDC」タグが表示されるはずです。「RuleDictionaryDC」タグをJSPXファイルにドラッグ・アンド・ドロップします(図26-31 )。

図26-31 ルール・ディクショナリのDCタグ

次のようにして、「RuleDictionaryDC」タグを手動でjspxファイルに追加することもできます。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1" xmlns:f="http://java.sun.com/jsf/core"
xmlns:af="http://xmlns.oracle.com/adf/faces/rich"
xmlns:rddc="http://xmlns.oracle.com/bpel/rules/dictionaryEditor">
<jsp:directive.page contentType="text/html;charset=UTF-8"/>
<f:view>
<af:document title="ruleDictEditor" id="d1">
<af:form id="f1">
<af:panelGridLayout id="pgl1" inlineStyle="margin:15px;" styleClass="AFStretchWidth"
partialTriggers="cb2 cb3 cb6">
<af:gridRow id="dc_gr1" marginTop="5px" marginBottom="5px">
<af:gridCell marginStart="5px" marginEnd="5px" width="100%" halign="stretch" id="gc1">
<af:panelGroupLayout id="pgl3" layout="horizontal">
<af:button text="Save Dictionary" id="cb2" action="#{someBean.saveDictionary}"/>
<af:spacer width="10" height="10" id="s1"/>
<af:button text="Validate" id="cb3" action="#{someBean.validate}"/>
<af:spacer width="10" height="10" id="s3"/>
<af:button text="Toggle Mode" id="cb6" action="#{someBean.toggleMode}"/>
</af:panelGroupLayout>
</af:gridCell>
</af:gridRow>
<af:gridRow height="100%" id="gr2">
<af:gridCell width="100%" halign="stretch" valign="stretch" id="gc2">
<!-- Content -->
<rddc:ruleDictionaryDC ruleDictModel="#{someBean.ruleDictModel}" id="rddc1"
rulesEditorPrefs="#{someBean.rulesEditorPrefs}"
viewOnly="#{someBean.viewOnly}" disableVerbalRules="false"/>
</af:gridCell>
</af:gridRow>
</af:panelGridLayout>
</af:form>
</af:document>
</f:view>
</jsp:root>

26.3.2.3 oracle.rulesおよびoracle.soa.rules_dict_dc.webapp共有ライブラリの参照方法

.jspxファイルを作成した後に、weblogic-application.xmlファイルから共有ライブラリoracle.rulesおよびoracle.soa.rules_dict_dc.webappを参照する必要があります。

oracle.rulesおよびoracle.soa.rules_dict_dc.webapp共有ライブラリを参照する手順は、次のとおりです。

1. JDeveloperで、「アプリケーション・リソース」から「ディスクリプタ」を選択し、次に「META-INF」を選択します。weblogic-application.xmlファイルを編集して、次の行を追加します(これによってoracle.rules共有ライブラリが参照されます)。

<library-ref>
<library-name>oracle.rules</library-name>
</library-ref>

2. JDeveloperで、「ファイル」、「新規」、次に「デプロイメント・ディスクリプタ」の順に選択します。

a. 「WebLogicデプロイメント・ディスクリプタ」を選択し、次にリストから「weblogic.xml」を選択します。

b. 「version 12.1.2」を選択して、「終了」をクリックします。

c. weblogic.xmlの「概要」モードで、左側から「ライブラリ」を選択し、oracle.soa.rules_dict_dc.webappをライブラリ名として追加します。weblogic.xmlファイルの例を次に示します。

<?xml version = '1.0' encoding = 'UTF-8'?>
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app
http://xmlns.oracle.com/weblogic/weblogic-web-app/1.5/weblogic-web-app.xsd"
xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
<library-ref>
<library-name>oracle.soa.rules_dict_dc.webapp</library-name>
</library-ref>
</weblogic-web-app>

d. 「すべて保存」をクリックします。

注意:

共有ライブラリoracle.rulesおよびoracle.soa.rules_dict_dc.webappは、埋込みWLSサーバーにデプロイされている必要があることに注意してください。

3. 共有ライブラリが、埋込みWLSのweblogicコンソールを使用してデプロイされていることを確認します。

a. WLSコンソール(http://host:port/console/login/LoginForm.jsp)を起動して、ログインします。

b. 「デプロイメント」をクリックして、共有ライブラリoracle.rulesおよびoracle.soa.rules_dict_dc.webappが、図26-32 に示すようにデプロイされているかどうかを確認します。

図26-32 デプロイメント

4. 共有ライブラリがデプロイされていない場合は、次の手順を参照して共有ライブラリを手動でデプロイします。

a. WLS埋込みサーバーを起動するには、図26-33 に示すように、JDeveloperで「実行」を選択して、次に「サーバー・インスタンスの起動」を選択します。

図26-33 サーバー・インスタンスの起動

共有ライブラリがすでにデプロイされている場合は、この手順をスキップします。

注意:

共有ライブラリをデプロイできるように、JDeveloper上でWLS埋込みサーバーが実行中である必要があります。

5. oracle.rules共有ライブラリをWLSにデプロイする手順は、次のとおりです。

a. WLSコンソール(http://host:port/console/login/LoginForm.jsp)を起動して、ログインします。

b. 「デプロイメント」を選択して「インストール」をクリックします。

c. 「<SOA_INSTALL>/soa/soa/modules/oracle.rules_11.1.1/rules.jar」を選択して、「次へ」および「終了」をクリックします。

6. oracle.soa.rules_dict_dc.webapp共有ライブラリをWLSにデプロイする手順は、次のとおりです。

a. WLSコンソールで、「デプロイメント」を選択し、「インストール」をクリックします。

b. 「<SOA_INSTALL>/soa/soa/modules/oracle.soa.rules_dict_dc.webapp_11.1.1/oracle.soa.rules_dict_dc.webapp.war」を選択します。

c. 「次へ」をクリックし、「終了」をクリックします。

d. 「このデプロイメントをライブラリとしてインストールする」を選択します。

e. 「終了」をクリックします

f. これで、図26-32 に示すように、oracle.soa.rules_dict_dc.webappがデプロイメントのリストに追加されました。

26.3.2.4 ルール・ディクショナリ・エディタ・サンプル・アプリケーションの実行方法

最後のタスクは、サンプル・アプリケーションの実行です。

ルール・ディクショナリ・エディタ・サンプル・アプリケーションを実行する手順は、次のとおりです。

1. サンプル・アプリケーションを実行するには、JDeveloperで「ruleDictEditor.jspx」ファイルを右クリックします。

2. 「実行」を選択します。

これにより、図26-34 に示すように、サンプル・アプリケーションがブラウザで開始されます。

図26-34 ルール・ディクショナリ・エディタ・サンプル・アプリケーション

26.3.3 スタンドアロンOracle WebLogic Serverへのルール・ディクショナリ・アプリケーションのデプロイ方法

アプリケーションのEARファイルをスタンドアロンWLSにデプロイする準備ができたら、次の手順に従ってすべてが順調に動作することを確認します。

1. 共有ライブラリが、スタンドアロンWLSのweblogicコンソールを使用してデプロイされていることを確認します。

a. WLSコンソール(http://host:port/console/login/LoginForm.jsp)を起動して、ログインします。

b. 「デプロイメント」をクリックして、共有ライブラリoracle.rulesおよびoracle.soa.rules_dict_dc.webappが、図26-11 に示すようにデプロイされているかどうかを確認します。

2. 共有ライブラリがデプロイされていない場合は、前述の手順を参照して共有ライブラリを手動でデプロイします。

3. ルール・ディクショナリ・エディタ・コンポーネントを使用するプロジェクトで、「Oracle Rules Dictionary Component」を「ライブラリとクラスパス」に含めます。これによってこれらのライブラリがデフォルトでデプロイされることはないため、JARはプロジェクトのWARファイルには含まれません。

4. 最後にデプロイするプロジェクト(EARファイルを作成する場所)で、次の手順を実行します。

a. weblogic-application.xmlに次を追加します。

<library-ref>
<library-name>oracle.rules</library-name>
</library-ref>

b. プロジェクトのWARファイルのweblogic.xmlに、次を追加します。

<library-ref>
<library-name>oracle.soa.rules_dict_dc.webapp</library-name>
</library-ref>

5. これで、EARファイルをWLSにデプロイでき、動作させることができます。

26.3.4 ルール・ディクショナリ・エディタ・コンポーネントのサポートされている属性に関する必知事項

この項では、ルール・ディクショナリ・エディタ・コンポーネントでサポートされている属性のリストを示します。

表26-2 に、サポートされている属性のリストを示します。

表26-2 ルール・ディクショナリ・エディタのサポートされている属性

名前

タイプ

必要

デフォルト値

ELをサポートしているかどうか

説明

ruleDictModel

oracle.bpel.ruledict
ionarydc.model.inter
faces.RuleDictionary
Interface

はい

-

ELのみ

Rules SDKディクショナリ・オブジェクトのラッパー。ユーザーは、ルール・ディクショナリ・エディタ・コンポーネントjarファイル(adflibRuleDictionaryDC.jar)の一部として提供されるRuleDictionaryModelオブジェクトを使用できます。

viewOnly

java.lang.Boolean

いいえ

true

はい

viewOnlyモードで、ユーザーは、既存のディクショナリ・データを表示できますが、編集はできません。falseの場合(つまり「編集」モードで)、ユーザーは、ディクショナリを編集できます。

locale

java.util.Locale

いいえ

Locale.getD
efault()

はい

ローカライズに使用します。

timezone

java.util.TimeZone

いいえ

TimeZone.ge
tDefault()

はい

ローカライズに使用します

ruleModel

java.lang.String

いいえ

oracle.bpel
.rulesdc.mo
del.impl.Ru
leModel

はい

デフォルトのRuleModelのカスタマイズに使用します。ユーザーは、RuleModelクラスを拡張して、特定のメソッドをオーバーライドできます。非推奨。rulesEditorPrefsを使用し、getIfThenPreferences().getRuleModel()をオーバーライドします。

simpleTestModel

java.lang.String

いいえ

oracle.bpel
.rulesdc.mo
del.impl.Si
mpleTestMod
el

はい

デフォルトのSimpleTestModelのカスタマイズに使用します。ユーザーは、SimpleTestModelクラスを拡張して、特定のメソッドをオーバーライドできます。rulesEditorPrefsを使用し、getIfThenPreferences().getSimpleTestModel()をオーバーライドします。

selectedTab

java.lang.String

いいえ

-

はい

指定のタブ名(GLOBALS、FACTS、VALUESETS、LINKS、DESC_FUNCS、DSL_DEFNS、TESTS、TRANSLATIONSまたはルールセットの名前)に切り替えます。

selectedRulesetIdx

java.lang.String

いいえ

-

はい

デフォルトで選択されるルールセット索引を指定するために使用されます。selectedRulesetIdxが指定されている場合、selectedTab属性がオーバーライドされます。

dtColumnPageSize

java.lang.Integer

いいえ

5

はい

非推奨であり使用されません。

dtHeight

java.lang.Integer

いいえ

16

はい

非推奨であり使用されません。

dateStyle

java.lang.String

いいえ

ロケールから取得

はい

指定された場合、その日付スタイルがすべてのinputDateコンポーネントで使用されます。例: yyyy.MM.dd

timeStyle

java.lang.String

いいえ

ロケールから取得

はい

指定された場合、その時間スタイルがすべてのinutDateコンポーネントで使用されます(例: HH:mm:ss)。

showValidationPanel

java.lang.Boolean

いいえ

true

はい

検証パネルがデフォルトで表示されます。ユーザーは、これをfalseに設定することで、非表示にできます。

discloseRules

java.lang.Boolean

いいえ

false

はい

非推奨であり使用されません。

displayRuleSetName

java.lang.Boolean

いいえ

true

はい

非推奨であり使用されません。

disableRuleSetName

java.lang.Boolean

いいえ

false

はい

非推奨であり使用されません。

showDTButtons

java.lang.Boolean

いいえ

true

はい

非推奨であり使用されません。

disableDFName

java.lang.Boolean

いいえ

false

はい

trueの場合、デシジョン関数エディタのポップアップでデシジョン関数名が無効化されます。非推奨。dfEditorPrefsを使用し、isDisableDFName()をオーバーライドします。

displayWSName

java.lang.Boolean

いいえ

true

はい

trueの場合、デシジョン関数エディタのポップアップで、デシジョン・サービス名が表示されます。サービス名は「ルール・サービスとして呼出し」がチェックされている場合にのみ有効になります。非推奨。dfEditorPrefsを使用し、isDisplayWSName()をオーバーライドします。

displayWSCheck

java.lang.Boolean

いいえ

true

はい

trueの場合、デシジョン関数エディタのポップアップの「ルール・サービスとして呼出し」チェック・ボックスが表示されます。非推奨。dfEditorPrefsを使用し、isDisplayWSCheck()をオーバーライドします。

disableInputOps

java.lang.Boolean

いいえ

false

はい

デシジョン関数エディタのポップアップの「入力」表で、追加、編集および削除の各操作が無効になります。非推奨。dfEditorPrefsを使用し、isDisableInputOps()をオーバーライドします。

disableOutputOps

java.lang.Boolean

いいえ

false

はい

デシジョン関数エディタのポップアップの「出力」表で、追加、編集および削除の各操作が無効になります。非推奨。dfEditorPrefsを使用し、isDisableOutputOps()をオーバーライドします。

displayAddDF

java.lang.Boolean

いいえ

true

はい

「デシジョン関数の追加」ボタンが表示されます。非推奨。dfEditorPrefsを使用し、isDisableAddDF()をオーバーライドします。

displayDeleteDF

java.lang.Boolean

いいえ

true

はい

「デシジョン関数の削除」ボタンが表示されます。非推奨。dfEditorPrefsを使用し、isDisableDeleteDF()をオーバーライドします。

rulesPageSize

java.lang.Integer

いいえ

5

はい

非推奨であり使用されません。

decimalSeparator

java.lang.Character

いいえ

ロケールに基づく

はい

小数セパレータの指定に使用します。これは数値書式に使用されます。指定された場合、ロケールに基づく小数セパレータをオーバーライドします。

groupingSeparator

java.lang.Character

いいえ

ロケールに基づく

はい

グループ化セパレータの指定に使用します。これは数値書式に使用されます。指定された場合、ロケールに基づくグループ化セパレータをオーバーライドします。

vldnPanelCollapsed

java.lang.Boolean

いいえ

false

はい

検証パネルがデフォルトで縮小されているかどうかを指定するために使用されます。

vldnTabTitle

java.lang.String

いいえ

ローカライズされたテキスト:ビジネス・ルール検証 - ログ

はい

検証パネルのタイトルを指定するために使用されます。

resourceManager

oracle.bpel.rulessha
reddc.model.interfac
es.ResourceManagerIn
terface

いいえ

-

はい

翻訳UIのリソース・マネージャを指定するために使用されます。変換に関する項を参照してください。

rulesEditorPrefs

oracle.bpel.ruledict
ionarydc.model.inter
faces.RulesEditorPre
ferences

いいえ

oracle.bpel
.ruledictio
narydc.mode
l.impl.Rule
sEditorPref
erencesImpl

はい

ルール・エディタのプリファレンスを指定するために使用されます。コンシューマは、デフォルトの実装(oracle.bpel.ruledictionarydc.model.impl.RulesEditorPreferencesImpl)を拡張し、必要なプリファレンスのみをオーバーライドできます。

dfEditorPrefs

oracle.bpel.ruledict
ionarydc.model.inter
faces.DFEditorPrefer
ences

いいえ

oracle.bpel
.ruledictio
narydc.mode
l.impl.DFEd
itorPrefere
ncesImpl

はい

デシジョン関数エディタのプリファレンスを指定するために使用されます。コンシューマは、デフォルトの実装(oracle.bpel.ruledictionarydc.model.impl.DFEditorPreferencesImpl)を拡張し、必要なプリファレンスのみをオーバーライドできます。

showRSButtons

java.lang.Boolean

いいえ

true

はい

非推奨であり使用されません。

dfListener

oracle.bpel.decision
funceditordc.listene
r.DecisionFuncListen
er

いいえ

-

はい

デシジョン関数エディタの更新の通知に使用します。非推奨。dfEditorPrefsを使用し、getDfListener()をオーバーライドします。

dfActionListener

oracle.bpel.ruledict
ionarydc.listener.De
cisionFuncActionList
ener

いいえ

-

はい

デシジョン関数が追加または削除された際の通知に使用します。非推奨。dfEditorPrefsを使用し、getDfActionListener()をオーバーライドします。

dfServiceNameCustomize

oracle.bpel.decision
funceditordc.listene
r.DecisionFuncServic
eNameCustomizer

いいえ

-

はい

デシジョン関数のサービス名のカスタマイズに使用します。非推奨。dfEditorPrefsを使用し、getDfServiceNameCustomizer()をオーバーライドします。

dictVersionInfo

oracle.bpel.ruledict
ionarydc.model.inter
faces.DictVersionInf
o

いいえ

-

はい

比較用にディクショナリ・バージョンのリストを取得するための差分またはマージで使用します。非推奨。dfEditorPrefsを使用し、getDfServiceNameCustomizer()をオーバーライドします。

testExecutor

oracle.bpel.testedit
ordc.interfaces.Test
Executor

いいえ

-

はい

テスト・スイート、テスト・テンプレートおよびテスト・ケースに使用します。

disableRulesTesting

java.lang.Boolean

いいえ

false

はい

trueの場合、ルールのテスト機能は無効になります。

disableVerbalRules

java.lang.Boolean

いいえ

true

はい

trueの場合、言語化機能は無効になるため、「ビジネス・フレーズ」タブは表示されず、動詞ルールでのCRUD操作は無効になります。

boUpdateListener

oracle.bpel.ruledict
ionarydc.listener.BO
UpdateListener

いいえ

-

はい

ビジネス・オブジェクトの同期に使用します。

26.4 Oracle Business Rulesディクショナリ・エディタのタスク・フローの概要

この項では、Oracle Business Rulesディクショナリ・エディタのタスク・フローについて説明します。ルール・ディクショナリ・エディタのタスク・フローを使用してアプリケーションを作成および実行し、アプリケーションをデプロイする方法についても説明します。

26.4.1 Oracle Business Rulesディクショナリ・タスク・フローの使用

Oracleルール・ディクショナリ・エディタのタスク・フローは、基本的にはルール・ディクショナリ・エディタの宣言コンポーネントを囲むラッパーです。このタスク・フローは、タスク・フローが必要なADFベースのWebアプリケーションで、宣言コンポーネントのかわりに使用されます。ルール・ディクショナリ・エディタ・コンポーネントの詳細は、「Oracle Business Rulesディクショナリ・エディタの宣言コンポーネントの概要」を参照してください。

26.4.2 ルール・ディクショナリ・エディタのタスク・フローを使用したサンプル・アプリケーションの作成および実行方法

この項では、Oracleルール・ディクショナリ・エディタのタスク・フローを使用してサンプル・アプリケーションを作成および実行するための手順を示します。

Oracleルール・ディクショナリ・エディタのタスク・フローを使用してADFベースのWebアプリケーションを作成するための前提条件は、使用しているコンピュータでOracle SOA SuiteとOracle JDeveloperのインストールが実行されていることです。

最初のタスクはサンプル・アプリケーションの作成です。

Oracleルール・ディクショナリ・エディタのタスク・フローを使用してサンプル・アプリケーションを作成する手順は、次のとおりです。

1. Oracle JDeveloperを開きます。

2. 「ファイル」メニューから、「新規」を選択し、次に「カスタム・アプリケーション」を選択して、アプリケーションを作成します。

3. 図26-35 に示すように、「アプリケーション名」フィールドにアプリケーションの名前(useRuleDictTaskFlowAppなど)を入力し、「次へ」をクリックします。

図26-35 汎用タスク・フロー・アプリケーションの作成

4. 図26-36 に示すように、「プロジェクト名」フィールドにuseRuleDictTaskFlowと入力し、「プロジェクト・テクノロジ」タブで「ADF Faces」が選択されていることを確認します。

図26-36 タスク・フロー・プロジェクトの作成

5. 「終了」をクリックしてプロジェクトを作成します。

6. Oracle JDeveloperの「アプリケーション」ウィンドウで「useRuleDictTaskFlow」プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択して「プロジェクト・プロパティ」ダイアログ・ボックスを表示します。
「プロジェクト・プロパティ」ダイアログ・ボックスでは、次の手順に従います。

a. 左側のパネルから「JSPタグ・ライブラリ」を選択します。

b. 「追加」をクリックし、図26-37 に示すように、「タグ・ライブラリの選択」ダイアログ・ボックスの「拡張機能」リストから「ADF Faces Components」を選択し、「OK」をクリックします。

図26-37 タスク・フロー・アプリケーションのタブ・ライブラリの選択

c. 左側のパネルから「ライブラリとクラスパス」を選択し、「ライブラリの追加」をクリックして「ライブラリの追加」ダイアログ・ボックスを表示します。

d. 図26-38 に示すように、「ライブラリ」リストでOracle RulesおよびOracle Rules Dictionaryタスク・フローを選択し、「OK」をクリックします。これにより、Rules SDKおよびルール・ディクショナリ・タスク・フローのJARがプロジェクトに追加されます。

図26-38 Rules SDKおよびルール・ディクショナリ・タスク・フローの追加

e. 「OK」をクリックして、「プロジェクト・プロパティ」ダイアログ・ボックスを閉じます。

7. Oracle JDeveloperの「ファイル」メニューから「すべて保存」をクリックし、プロジェクトを保存します。

8. soaComposerTemplates.jarに定義されているoracle.integration.console.metadata.model.share.MetadataDetailsインタフェースを実装するJavaクラスを作成しますMetadataDetailsインタフェースの詳細は、「MetadataDetailsインタフェース」を参照してください。
手順は、次のとおりです。

a. Oracle JDeveloperを開きます。

b. 「ファイル」メニューから「新規」を選択して、「新規ギャラリ」ダイアログ・ボックスを表示します。

c. 「新規ギャラリ」ダイアログ・ボックスの「カテゴリ」パネルから、「一般」の下にある「Java」を選択します。「項目」で「Javaクラス」が選択されていることを確認し、「OK」をクリックして「Javaクラスの作成」ダイアログ・ボックスを表示します。

d. Javaクラスの名前(MyMetaDataDetailsなど)を入力します。

e. 図26-39 に示すように、「オプション属性」の下の「実装」ボックスにMetadataDetailsインタフェースを追加し、「OK」をクリックして、プロジェクトにJavaクラスを作成します。

図26-39 MetadataDetailsインタフェースを実装するJavaクラスの作成

MyMetaDataDetails.javaファイルのサンプル・コンテンツを次に示します。

package useruledicttaskflow;

import java.io.BufferedReader;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.UnsupportedEncodingException;
import java.io.Writer;

import java.net.MalformedURLException;
import java.net.URL;

import oracle.integration.console.metadata.model.share.MetadataDetails;
import oracle.integration.console.metadata.model.share.RelatedMetadataPath;

public class MyMetaDataDetails implements MetadataDetails {
public MyMetaDataDetails() {
super();
}

private static final String RULES_FILE1 =
"file:///<path of Rules file>";

public String getDocument() {
URL url = null;
try {
url = new URL(RULES_FILE1);
return readFile(url);
} catch (IOException e) {
System.err.println(e);
}
return "";
}

public void setDocument(String string) {
URL url = null;

try {
url = new URL(RULES_FILE1);
} catch (MalformedURLException e) {
System.err.println(e);
return;
}
Writer writer = null;
try {
//os = new FileWriter(url.getPath());
writer =
new OutputStreamWriter(new FileOutputStream(url.getPath()),
"UTF-8");
} catch (FileNotFoundException e) {
System.err.println(e);
return;
} catch (IOException e) {
System.err.println(e);
return;
}
try {
writer.write(string);
} catch (IOException e) {
System.err.println(e);
} finally {
if (writer != null) {
try {
writer.close();
} catch (IOException ioe) {
System.err.println(ioe);
}
}
}
}

private String readFile(URL dictURL) {
InputStream is;
try {
is = dictURL.openStream();
} catch (IOException e) {
System.err.println(e);
return "";
}
BufferedReader reader;
try {
reader = new BufferedReader(new InputStreamReader(is, "UTF-8"));
} catch (UnsupportedEncodingException e) {
System.err.println(e);
return "";
}
String line = null;
StringBuilder stringBuilder = new StringBuilder();
String ls = System.getProperty("line.separator");
try {
while ((line = reader.readLine()) != null) {
stringBuilder.append(line);
stringBuilder.append(ls);
}
} catch (IOException e) {
System.err.println(e);
return "";
} finally {
try {
reader.close();
} catch (IOException e) {
System.err.println(e);
}
}
return stringBuilder.toString();
}

public String getRelatedDocument(RelatedMetadataPath relatedMetadataPath) {
String currPath =
RULES_FILE1.substring(0, RULES_FILE1.indexOf("oracle/rules"));
String relatedDoc =
currPath + "oracle/rules/" + relatedMetadataPath.getValue();

URL url = null;
try {
url = new URL(relatedDoc);
return readFile(url);
} catch (IOException e) {
System.err.println(e);
}
return "";
}
}

9. oracle.integration.console.metadata.model.share.NLSPreferencesインタフェースを実装するMyNLSPreferencesと呼ばれるJavaクラスを作成します。このインタフェースはsoaComposerTemplates.jarに定義されています。
NLSPreferencesインタフェースの詳細は、「NLSPreferencesインタフェース」を参照してください。

次のMyNLSPreferences.javaのサンプルでは、NLSPreferencesインタフェースを実装します。

package useruledicttaskflow;

import java.util.Locale;
import java.util.TimeZone;

import oracle.integration.console.metadata.model.share.NLSPreferences;

public class MyNLSPreferences implements NLSPreferences {
private static final String DATE_STYLE = "yyyy-MM-dd";
private static final String TIME_STYLE = "HH-mm-ss";

public MyNLSPreferences() {
super();
}

public Locale getLocale() {
return Locale.getDefault();
}

public TimeZone getTimeZone() {
return TimeZone.getTimeZone("America/Los_Angeles");
}

public String getDateFormat() {
return DATE_STYLE;
}

public String getTimeFormat() {
return TIME_STYLE;
}
}

10. MetadataDetailsおよびNLSPreferencesの実装を返すMyBean.javaというマネージドBeanを作成します。また、oracle.integration.console.metadata.model.share.MetadataDetailsModeオブジェクトを返し、toggleMode()、saveDictionary()、saveNoValidateDictionary()、validate()などのイベント・ハンドラも提供します。
次に、MyBean.javaファイルのサンプルを示します。

package useruledicttaskflow;

import javax.el.ELContext;
import javax.el.ExpressionFactory;
import javax.el.MethodExpression;

import javax.faces.context.FacesContext;
import javax.faces.event.PhaseId;

import oracle.adf.view.rich.component.rich.fragment.RichRegion;

import oracle.integration.console.metadata.model.share.MetadataDetails;
import oracle.integration.console.metadata.model.share.MetadataDetailsMode;
import oracle.integration.console.metadata.model.share.NLSPreferences;

public class MyBean {
private MyMetaDataDetails details = null;
private MetadataDetailsMode mode = MetadataDetailsMode.VIEW;
private RichRegion regionComp;
private NLSPreferences nlsPrefs;

public MyBean() {
super();
}

public MetadataDetails getMetaDataDetails() {
if (details != null)
return details;

details = new MyMetaDataDetails();
return details;
}

public MetadataDetailsMode getDetailsMode() {
return mode;
}

public void toggleMode() {
if (mode.equals(MetadataDetailsMode.EDIT))
mode = MetadataDetailsMode.VIEW;
else
mode = MetadataDetailsMode.EDIT;
}

public void saveDictionary() {
if (regionComp == null)
return;
FacesContext fc = FacesContext.getCurrentInstance();
ExpressionFactory ef = fc.getApplication().getExpressionFactory();
ELContext elc = fc.getELContext();
MethodExpression me =
ef.createMethodExpression(elc, "doMetadataUpdate", String.class,
new Class[] { });
regionComp.queueActionEventInRegion(me, null, null, false, -1, -1,
PhaseId.ANY_PHASE);
}

public void saveNoValidateDictionary() {
if (regionComp == null)
return;
FacesContext fc = FacesContext.getCurrentInstance();
ExpressionFactory ef = fc.getApplication().getExpressionFactory();
ELContext elc = fc.getELContext();
MethodExpression me =
ef.createMethodExpression(elc, "doNoValidateMetadataUpdate",
String.class, new Class[] { });
regionComp.queueActionEventInRegion(me, null, null, false, -1, -1,
PhaseId.ANY_PHASE);
}

public void validate() {
if (regionComp == null)
return;
FacesContext fc = FacesContext.getCurrentInstance();
ExpressionFactory ef = fc.getApplication().getExpressionFactory();
ELContext elc = fc.getELContext();
MethodExpression me =
ef.createMethodExpression(elc, "doValidate", String.class,
new Class[] { });
regionComp.queueActionEventInRegion(me, null, null, false, -1, -1,
PhaseId.ANY_PHASE);
}

public void setRegionComp(RichRegion regionComp) {
this.regionComp = regionComp;
}
public RichRegion getRegionComp() {
return regionComp;
}

public NLSPreferences getNlsPrefs() {
if (nlsPrefs != null)
return nlsPrefs;

nlsPrefs = new MyNLSPreferences();
return nlsPrefs;
}
}

11. faces-config.xmlファイルを概要モードで開き、「マネージドBean」の下の「+」ボタンをクリックして「マネージドBeanの作成」ダイアログ・ボックスを表示します。

12. 図26-40 に示すように、「Bean名」フィールドにMyBeanと入力し、「スコープ」リストでsessionを選択して、MyBean.javaを指し示します。

図26-40 タスク・フロー・アプリケーションでのBean名とスコープの指定

26.4.2.1 ルール・ディクショナリ・エディタのタスク・フローの追加方法

次のタスクは、ルール・ディクショナリ・エディタ・コンポーネント・タグを挿入する.jspxファイルの作成です。

ルール・ディクショナリ・エディタのタスク・フローを.jspxファイルに追加する手順は、次のとおりです。

1. Oracle JDeveloperを開きます。

2. 「ファイル」メニューから「新規」を選択して、「新規ギャラリ」ダイアログ・ボックスを表示します。

3. 「新規ギャラリ」ダイアログ・ボックスの「カテゴリ」パネルから、「Web層」の下にある「JSF」を選択します。

4. 図26-41 に示すように、「項目」で「JSFページ」を選択し、「OK」をクリックして「JSFページの作成」ダイアログ・ボックスを表示します。

図26-41 ルール・ディクショナリ・エディタのタスク・フローを挿入するJSFページ・ファイルの作成

5. 図26-42 に示すように、「JSFページの作成」ダイアログ・ボックスで、「ファイル名」にuseRuleDictTaskFlow.jspxと入力します。

図26-42 タスク・フローのJSFページ名の指定

Oracle JDeveloperの「コンポーネント」ウィンドウに「adflibRuleDictionaryTaskFlow.jar」が表示されます(図26-43 を参照)。

図26-43 「コンポーネント」ウィンドウのルール・ディクショナリ・タスク・フローJAR

これは、サンプル・アプリケーションの作成時にOracle Rules Dictionaryタスク・フローの共有ライブラリを追加したためです。

6. 「adflibRuleDictionaryTaskFlow.jar」を選択して、「コンポーネント」ウィンドウの「リージョン」でrule-dict-flow-definitionが使用可能になるようにします。図26-44 に示すように、rule-dict-flow-definitionリージョンを.jspxファイルにドラッグ・アンド・ドロップすると、必要なすべてのパラメータを指定できます。

図26-44 リージョンのドラッグ・アンド・ドロップ

次に、タスク・フローが追加されたuseRuleDictTaskFlow.jspxファイルのサンプルを示します。

<f:view>
<af:document id="d1">
<af:form id="f1">
<af:panelStretchLayout id="psl1" inlineStyle="margin:8px;">
<f:facet name="top">
<af:menuBar id="mb1">
<af:commandMenuItem text="Toggle Mode" id="cmi1"
action="#{MyBean.toggleMode}"
partialSubmit="true"/>
<af:commandMenuItem text="Save Dict" id="cmi2"
action="#{MyBean.saveDictionary}"
partialSubmit="true"/>
<af:commandMenuItem text="Save Dict No Validate" id="cmi3"
action="#{MyBean.saveNoValidateDictionary}"
partialSubmit="true"/>
<af:commandMenuItem text="Validate" id="cmi4"
action="#{MyBean.validate}"
partialSubmit="true"/>
</af:menuBar>
</f:facet>
<f:facet name="center">
<af:region value="#{bindings.rulesdictflowdefinition1.regionModel}"
id="r2" binding="#{MyBean.regionComp}"
partialTriggers="::cmi1 ::cmi2 ::cmi3 ::cmi4"/>
</f:facet>
</af:panelStretchLayout>
</af:form>
</af:document>
</f:view>

前述のサンプルでは、次のボタンをページに表示するためのコード・スニペットがあります。

- トグル・モード: Oracle SOAコンポーザの読取り専用モードと編集可能モードを切り替えます。

- ディクショナリの保存: ディクショナリを(検証付きで、または検証なしで)保存します。

26.4.2.2 pagedef.xmlファイルの編集方法

タスク・フローを.jspxファイルに追加した後、useRuleDictTaskFlowPageDef.xmlファイルを編集する必要があります。pagedef.xmlファイルは、ルール・ディクショナリ・タスク・フローを.jspxページにドロップすると作成されます。

次に、pagedef.xmlファイルのサンプルと、ルール・ディクショナリ・タスク・フローに渡す必要があるすべてのパラメータを示します。

<?xml version="1.0" encoding="UTF-8" ?>
<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel"
version="11.1.1.55.99" id="useRuleDictTaskFlowPageDef"
Package="useruledicttaskflow.pageDefs">
<parameters/>
<executables>
<variableIterator id="variables"/>
<taskFlow id="rulesdictflowdefinition1"
taskFlowId= "/WEB-INF/rule-dict-flow-definition.xml#rules-dict-flow-definition"
activation="deferred"
xmlns="http://xmlns.oracle.com/adf/controller/binding">
<parameters>
<parameter id="details" value="#{MyBean.metaDataDetails}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="mode" value="#{MyBean.detailsMode}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="dtHeight" value="10"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="selectedTab" value="Ruleset_1"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="dtColumnPageSize" value="6"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="nlsPrefs" value="#{MyBean.nlsPrefs}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="discloseRules" value="true"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
</parameters>
</taskFlow>
</executables>
<bindings/>
</pageDefinition

26.4.2.3 oracle.rulesおよびoracle.soa.rules_dict_dc.webapp共有ライブラリの参照方法

次のタスクは、weblogic-application.xmlファイルからoracle.rulesおよびoracle.soa.rules_dict_dc.webapp共有ライブラリを参照することです。

共有ライブラリの参照方法は、「ルール・ディクショナリ・エディタ・コンポーネントを使用したサンプル・アプリケーションの作成および実行方法」を参照してください。

26.4.2.4 タスク・フロー・サンプル・アプリケーションの実行方法

最後のタスクは、埋込みOracle WebLogic Serverでのサンプル・アプリケーションの実行です。

タスク・フロー・サンプル・アプリケーションを実行する手順は、次のとおりです。

1. サンプル・アプリケーションを実行するには、Oracle JDeveloperで、useRulesDictTaskFlow.jspxファイルを右クリックします。

2. 「実行」を選択します。

図26-45 に示すように、Webブラウザでサンプル・アプリケーションが開始します。

図26-45 ルール・ディクショナリ・エディタのタスク・フロー・サンプル・アプリケーションの実行

26.4.3 スタンドアロンOracle WebLogic Serverへのルール・ディクショナリ・エディタのタスク・フロー・アプリケーションのデプロイ方法

アプリケーションEARファイルをスタンドアロンOracle WebLogic Serverにデプロイする準備が整った場合は、次の手順を実行します。

1. Oracle WebLogic Server管理コンソール(http://host:port/console/login/LoginForm.jsp)を起動します。

2. デプロイメント・リストにoracle.rulesが表示されていることを確認します。

3. デプロイメント・リストにoracle.soa.rules_dict_dc.webappが表示されていることを確認します。

4. 表示されていない場合は、「インストール」をクリックしてJDEV_INSTALL/jdeveloper/soa/modules/oracle.soa.rules_dict_dc.webapp_11.1.1/oracle.soa.rules_dict_dc.webapp.warファイルを選択します。

5. デプロイする必要があるプロジェクト(EARファイルを作成する場所)で、次の手順を実行します。

a. 次の行をweblogic-application.xmlに追加します。

<library-ref>
<library-name>oracle.rules</library-name>
</library-ref>

b. 次の行をプロジェクトWARファイルのweblogic.xmlに追加します。

<library-ref>
<library-name>oracle.soa.rules_dict_dc.webapp</library-name>
</library-ref>

c. EARファイルをOracle WebLogic Serverにデプロイします。

26.5 ADFベースのWebアプリケーションのローカライズ

ルール・エディタ・コンポーネント、ルール・ディクショナリ・エディタ・コンポーネントまたはルール・ディクショナリ・エディタのタスク・フローを使用して作成されたアプリケーションは、ローカライズできます。

アプリケーションをローカライズする手順は、次のとおりです。

1. ルール・ディクショナリ・エディタ・コンポーネントを使用して、アプリケーションでfaces-config.xmlを変更します。faces-config.xmlファイルには、使用可能なリソース・バンドルをサポートするために、次のコードを<application>タグ内に指定する必要があります。

<locale-config>
<default-locale>en</default-locale>
<supported-locale>en</supported-locale>
<supported-locale>ar</supported-locale>
<supported-locale>cs</supported-locale>
<supported-locale>da</supported-locale>
<supported-locale>de</supported-locale>
<supported-locale>el</supported-locale>
<supported-locale>es</supported-locale>
<supported-locale>fi</supported-locale>
<supported-locale>fr</supported-locale>
<supported-locale>hu</supported-locale>
<supported-locale>it</supported-locale>
<supported-locale>iw</supported-locale>
<supported-locale>ja</supported-locale>
<supported-locale>ko</supported-locale>
<supported-locale>nl</supported-locale>
<supported-locale>no</supported-locale>
<supported-locale>pl</supported-locale>
<supported-locale>pt-BR</supported-locale>
<supported-locale>pt</supported-locale>
<supported-locale>ro</supported-locale>
<supported-locale>ru</supported-locale>
<supported-locale>sk</supported-locale>
<supported-locale>sv</supported-locale>
<supported-locale>th</supported-locale>
<supported-locale>tr</supported-locale>
<supported-locale>zh-CN</supported-locale>
<supported-locale>zh-TW</supported-locale>
</locale-config>

2. ブラウザ言語を任意のロケールに変更します。

3. ブラウザで提供されるロケールをオーバーライドして特定のロケールでUIを表示する場合は、そのロケールを属性としてコンポーネントに渡し、コンポーネントを使用してアプリケーションでf:viewタグを次のように変更します。

<f:view locale="#{someBean.locale}">

注意:

ここで渡したロケールは、locale属性を使用してコンポーネントに渡した内容と同じである必要があります。

26.6 翻訳の使用

この機能は、ビジネス・ルールWeb UIの別名の翻訳をサポートしています。ロケールに従った別名を設定できます。ビジネス・ルールWeb UIで「変換」タブまたはリソース・エディタ・ポップアップを介して様々なロケール向けに別名の翻訳を編集することもできます。

26.6.1 再利用可能なルールUI ADFタスク・フロー・コンポーネントのコンシューマに対する翻訳の有効化

別名の翻訳をサポートするために、再利用可能なルールUI ADFタスク・フロー・コンポーネントのコンシューマは、ルールUI ADFタスク・フローをコールする際に、追加のパラメータとしてロケール固有のリソース・アーティファクトを提供する必要があります。ただし、これらの追加のパラメータはオプションであり、コンシューマが拡張翻訳サポートを使用する場合にのみ必要です。

追加パラメータは次のとおりです。

property-name: relatedDetails
property-class: oracle.integration.console.metadata.model.share.IRelatedMetadataDetails

<taskFlow id="rulesdictflowdefinition1"
taskFlowId="/WEB-INF/rule-dict-flow-definition.xml#rules-dict-flow-definition"
activation="deferred" Refresh="default"
RefreshCondition="${MyBean.refreshReqd}"
xmlns="http://xmlns.oracle.com/adf/controller/binding">
<parameter id="relatedDetails"
value="#{MyBean.relatedMetadataDetails}"/>
</taskflow>

26.6.1.1 IRelatedMetadataDetailsの実装を渡すサンプル・コード

コンシューマは、oracle.integration.console.metadata.model.share.IRelatedMetadataDetailsの実装を渡す必要があります。

IRelatedMetadataDetailsの実装には、リポジトリからリソース・バンドルをロードするためのコードおよびユーザーがルール・アプリケーションに対する変更をコミットするときにバンドル・ファイルを保存するためのコードが含まれます。

コンシューマは、dictionaryName + "Translations_" + locale.toString() + ".xml"規則を使用して、リソース・バンドル・ファイルの名前を構築する必要があります。

public class MyRelatedMetadataDetails implements IRelatedMetadataDetails {

private static final Locale[] LOCALES = { Locale.US, Locale.FRENCH };

private static final String RESOURCE_PATH =
"file:///C:/scratch/sumit/system/rules/";
private static final String RESOURCE_BASE = "SimpleRule";

public MyRelatedMetadataDetails() {
super();
}

public String getDocument(IRelatedMetadataPath relatedPath) {
String resourceSuffix = relatedPath.getValue();
try {
return loadResource(resourceSuffix);
} catch (IOException e) {
return "";
}
}

private static String loadResource(String resourceSuffix) throws IOException {

FileInputStream fis = null;
FileChannel fc = null;
try {
URL url = new URL(RESOURCE_PATH + RESOURCE_BASE + resourceSuffix);
fis = new FileInputStream(url.getFile());
fc = fis.getChannel();
ByteBuffer bb = ByteBuffer.allocate((int)fc.size());
fc.read(bb);
bb.rewind();
return Charset.defaultCharset().decode(bb).toString();
} finally {
if (fis != null) {
fis.close();
}
if (fc != null) {
fc.close();
}
}
}

public void createDocument(IRelatedMetadataPath relatedPath,
String document) {
try {
storeResource(relatedPath.getValue(), document);
} catch (IOException e) {
e.printStackTrace();
}
}

public void saveDocument(IRelatedMetadataPath path, String document) {
try {
storeResource(path.getValue(), document);
} catch (IOException e) {
e.printStackTrace();
}
}

private static void storeResource(String resourceSuffix,
String document) throws IOException {
FileOutputStream fos = null;
FileChannel fc = null;
try {
URL url = new URL(RESOURCE_PATH + RESOURCE_BASE + resourceSuffix);
fos = new FileOutputStream(url.getFile());
fc = fos.getChannel();
ByteBuffer bb = ByteBuffer.allocateDirect(1024);
bb.clear();
bb.put(Charset.defaultCharset().encode(document));
bb.flip();
while (bb.hasRemaining()) {
fc.write(bb);
}
} finally {
if (fos != null) {
fos.close();
}
if (fc != null) {
fc.close();
}
}
}

public IRelatedMetadataPathFinderFactory getFinderFactory() {
return new RelatedMetadataPathFinderFactory();
}

public List<IRelatedMetadataPath> getExisting(IRelatedMetadataPathFinder finder) {

List<IRelatedMetadataPath> paths = new ArrayList<IRelatedMetadataPath>();
for (Locale locale : LOCALES) {
paths.add(RelatedResourceMetadataPath.buildFromLocale(locale));
}
return paths;
}

public class RelatedMetadataPathFinderFactory implements IRelated`MetadataPathFinderFactory {

public IRelatedMetadataPathFinder getResourceFinder() {
return new RelatedMetadataPathFinder();
}
}

public class RelatedMetadataPathFinder implements IRelatedMetadataPathFinder {

public String getType() {
return null;
}

public IRelatedMetadataPath matches(oracle.integration.console.metadata.model.share.MetadataPath srcPath,
oracle.integration.console.metadata.model.share.MetadataPath matchPath) {
return null;
}
}

}

26.6.2 ルールWeb UIアプリケーションのコンシューマに対する翻訳の有効化

別名の翻訳をサポートするために、ルールWeb UIアプリケーションのコンシューマは、ルール・ディクショナリDCまたはルールDCに属性を渡す必要があります。この属性は、タイプoracle.bpel.rulesshareddc.model.interface.ResourceManagerInterface.javaのインスタンスを受け入れるresourceManagerです。ただし、これらの追加のパラメータはオプションであり、コンシューマが拡張翻訳サポートを使用する場合にのみ必要です。

<rddc:ruleDictionaryDC ruleDictModel="#{SomeBean.ruleDictModel1}"
id="rddc1"
resourceManager="#{SomeBean.resourceManager}">
</rddc:ruleDictionaryDC>

26.6.2.1 resourceManagerのインスタンスを作成するためのサンプル・コード

ResourceManagerInterfaceの実装は、oracle.bpel.rulesshareddc.model.impl.ResourceManagerとして提供されています。コンシューマは、ResourceManagerのインスタンスを作成し、それを対応するUIコンポーネントに渡すことができます。

注意:

コンシューマは、保存されているリソース・バンドルすべてをリポジトリからロードする必要があり、java.util.Map (resourceMap)を構築する必要があります。その場合、リソース・バンドルのjava.util.Localeは、キーとして保持され、リソース・バンドル・ファイルの内容はjava.lang.Stringタイプの値として保持されます。

コンシューマは、dictionaryName + "Translations_" + locale.toString() + ".xml"規則を使用して、リソース・バンドル・ファイルの名前を構築する必要があります。

コンシューマは、アプリケーション内でユーザーが変更をコミットするたびに、これらのリソース・バンドルをリポジトリに保存する必要があります。

public ResourceManagerInterface getResourceManager() {
if (resourceManager == null) {
resourceManager =
new ResourceManager(loadResources(), ruleDictionary);
}
return resourceManager;
}

private Map<Locale, String> loadResources() {

Map<Locale, String> resourceMap = new HashMap<Locale, String>();

for (Locale locale : LOCALES) {
try {
URL url =
new URL(RULES_FILE_PATH + "Translations_" + locale.toString() +
".xml");
String content =
new Scanner(new File(url.getFile()), "UTF-8").useDelimiter("\\A").next();
resourceMap.put(locale, content);
} catch (IOException e) {
resourceMap.put(locale, "");
LOG.severe("Failed to load resource:" + e.getMessage());
}
}
if (!resourceMap.keySet().contains(getLocale())) {
resourceMap.put(getLocale(), "");
}
return resourceMap;
}

private void storeResources(Map<Locale, String> resourceMap) {
for (Locale locale : resourceMap.keySet()) {
try {
URL url =
new URL(RULES_FILE_PATH + "Translations_" + locale.toString() +
".xml");
BufferedWriter out = new BufferedWriter(new FileWriter(url.getFile()));
out.write(resourceMap.get(locale));
out.close();
} catch (IOException e) {
LOG.severe("Failed to store resource:" + e.getMessage());
}
}
}

第V部 ヒューマン・ワークフロー・サービス・コンポーネントの使用

この部では、ヒューマン・ワークフロー・サービス・コンポーネントの使用方法について説明します。

この部は、次の章で構成されています。

- ヒューマン・ワークフローのスタート・ガイド

- ヒューマン・タスクの作成

- ヒューマン・タスクの構成

- ヒューマン・タスク用のタスク・フォームの設計

- ヒューマン・ワークフローのチュートリアル

- Oracle BPM Worklistの使用

- カスタム・ワークリスト・クライアントの作成

- ヒューマン・ワークフロー・サービスの概要

27 ヒューマン・ワークフローのスタート・ガイド

この章では、開発者を対象として、ヒューマン・ワークフローの概念、機能およびアーキテクチャについて説明します。ヒューマン・ワークフローには、ユースケースが用意されています。ワークフロー全体を初めて設計する際の手順についても説明します。

この章の内容は次のとおりです。

- ヒューマン・ワークフローの概要

- ヒューマン・ワークフローの概要

- ヒューマン・ワークフローのユースケースの概要

- ヒューマン・ワークフロー・アーキテクチャの概要

- Oracle SOA SuiteとOracle BPM Suiteの間のヒューマン・ワークフローとビジネス・ルールの相違

警告:

SOAヒューマン・タスク・データベース表を直接変更しないでください。これらの表の列名およびデータの後方互換性は保証されません。

27.1 ヒューマン・ワークフローの概要

多くのエンドツーエンドのビジネス・プロセスでは、プロセスに人的な操作が必要です。たとえば、承認や例外管理、またはビジネス・プロセスの進行に必要なアクティビティの実行には、人的な操作が必要です。ヒューマン・ワークフロー・コンポーネントには、次の機能があります。

- プロセスの人的な操作。適切なユーザーまたはグループへのタスクの割当てやルーティングなどがあります。

- 期限、エスカレーション、通知および他の機能。タスク(ヒューマン・アクティビティ)の適時実行を保証するために必要です。

- エンド・ユーザーへのタスクの提示。ワークリスト・アプリケーション(Oracle BPM Worklist)などの様々な方法を使用します。

- 編成、フィルタ処理、優先度設定および他の機能。エンド・ユーザーがタスクを効率的に実行するために必要です。

- レポート、再割当、ロード・バランシングおよび他の機能。監督者およびビジネス所有者がタスクのパフォーマンスを管理するために必要です。

図27-1 に、ヒューマン・ワークフローの概要を示します。

図27-1 ヒューマン・ワークフロー

図27-1 では、次のアクションが発生しています。

- BPELプロセスは、タスクの実行に人的な操作が必要になると、ヒューマン・タスク・タイプの特別なアクティビティを起動します。

- このアクティビティによって、ヒューマン・タスク・サービス・コンポーネントにタスクが作成されます。このプロセスは、タスクが完了するまで待機します。プロセスでは、タスクからのその他のコールバックを監視し、そのコールバックに対応することも可能です。

- タスクにはメタデータが関連付けられています。このメタデータは、タスクのライフサイクルを管理するために、ヒューマン・タスク・サービス・コンポーネントで使用されます。このメタデータには、次の指定が含まれています。

- タスクを実行するユーザー。タスクの実行に複数のユーザーが必要な場合は、その順序。

- 他のステークホルダー。

- タスクの完了期限。

- ユーザーによるタスクの実行方法、ユーザーに提示する情報、ユーザーの入力内容と実行可能なアクション。

- ヒューマン・タスク・サービス・コンポーネントでは、アイデンティティ・ディレクトリを使用して、ユーザーのロールと権限を判断します。
アイデンティティ・ストアを構成して、埋込みWebLogic LDAP、Oracle Virtual Directory、サード・パーティのLDAPおよびActive Directory RDBMSを使用できます。詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

- ヒューマン・タスク・サービス・コンポーネントでは、次のような様々なチャネルを使用してユーザーにタスクを提示します。

- Oracle BPM Worklist。監督者やプロセス所有者の考え方をサポートするロール・ベースのアプリケーションで、タスクを検索、編成、管理および実行するための機能を提供します。

- ワークリスト機能。エンタープライズ・ポータルに公開可能なポートレットとして使用することもできます。

- 通知。電子メール、電話、SMSおよびその他のチャネルで送信できます。電子メール通知はアクション可能で、ユーザーは、Oracle BPM WorklistまたはOracle WebLogic Serverに接続しないで、電子メール・クライアント内からタスクに対してアクションを実行できます。

27.2 ヒューマン・ワークフローの概要

この項では、ヒューマン・ワークフローの主要な設計時および実行時の概念について説明します。ヒューマン・ワークフロー設計の主要な3つのステージの概要についても説明します。

27.2.1 設計時および実行時の概念の概要

ヒューマン・タスクを設計するには、その前に、設計時および実行時の概念を理解することが重要です。タスクは通常、件名、優先度、タスク参加者、タスク・パラメータまたはデータ、期限、通知またはリマインダ、およびタスク・フォームで構成されています。この項では、主要な概念に関する概要を説明します。

注意:

ヒューマン・ワークフローの設計時タスクは、ヒューマン・タスク・エディタと呼ばれるグラフィカル・エディタで実行されます。「ヒューマン・ワークフローのチュートリアル」のチュートリアルで、このエディタの使用方法を説明しています。

27.2.1.1 タスクの割当ておよびルーティング

ヒューマン・ワークフローでは、タスクの宣言的な割当ておよびルーティングをサポートしています。最も簡単なケースでは、タスクは単一の参加者(ユーザーまたはグループ)に割り当てられます。ただし、多くの場合は、複雑なタスク割当てとルーティングが必要です(たとえば、図27-2 に示すように、タスクに管理チェーンによる承認が必要な場合や、タスクを一連のユーザーがパラレルで作業したり、投票する必要がある場合です)。ヒューマン・ワークフローでは、このようなシナリオに対して宣言的なパターン・ベースのサポートを提供します。

図27-2 タスクの参加者

27.2.1.1.1 参加者

参加者は、割当ておよびルーティング・ポリシー定義内のユーザーまたは一連のユーザーです。図27-2 では、ユーザーを表すアイコンの各ブロックが参加者です。

27.2.1.1.2 参加者タイプ

簡単なケースでは、参加者はユーザー、グループまたはロールにマップされます。ただし、「タスクの割当ておよびルーティング」で説明したように、ワークフローでは、管理チェーンやグループ投票などの一般的なルーティング・シナリオに対して宣言的なパターンをサポートしています。使用可能な参加者タイプは、次のとおりです。

- 単一の承認者
これは、1人の参加者を単一のユーザー、グループまたはロールにマップする単純なケースです。

たとえば、休暇申請がマネージャに割り当てられているとします。マネージャは、休暇が始まる3日前までに申請タスクを操作する必要があります。マネージャが申請を正式に承認または却下すると、その決定が従業員に通知されます。マネージャがタスクを操作しない場合、申請は却下として処理されます。正式な却下の場合と同様に通知アクションが実行されます。

- パラレル
この参加者タイプは、一連のユーザーがパラレルで作業する必要があることを示します。このパターンは通常、投票で使用されます。

たとえば、雇用に関して複数のユーザーが応募者の採否を票決する必要がある場合です。結果が有効になるために必要な得票率(多数決や満場一致など)を指定します。

- シリアル
この参加者タイプは、一連のユーザーが順番に作業する必要があることを示します。ルーティング・ポリシーには、複数の参加者を順番に使用した順番による作業を指定できますが、このパターンは一連のユーザーが動的である場合に有用です。このシリアル・タイプの一般的なシナリオは、管理チェーン・エスカレーションです。このエスカレーションは、このパターンの指定内にある管理チェーンに基づいてリストを指定することで実行されます。

- FYI (情報専用)
この参加者は、単一の承認者と同様に、単一のユーザー、グループまたはロールにマップされます。ただし、このパターンは、参加者が通知タスクを単に受信し、ビジネス・プロセスではこの参加者のレスポンスを待機しないことを示します。FYIの参加者は、タスクの結果に直接影響を与えることはできませんが、場合によっては、コメントを提供したり、添付ファイルを追加できます。

たとえば、採用候補者の採用について地域マネージャが承認し、その候補が承認または却下のために州全体の統括マネージャに渡されたことが、地域の営業所に通知される場合です。FYIはタスクの結果を直接左右できませんが、コメントを提供したり添付ファイルを追加できる場合があります。

詳細は、「タスク参加者の割当て」を参照してください。

27.2.1.1.3 参加者の割当て

タスクは、ユーザーによる実行が必要な作業です。タスクを作成する場合は、そのタスクに参加して操作するユーザーを割り当てます。実行時に、参加者はOracle BPM Worklistからタスクに対してアクションを実行できます。これらのアクションには、休暇申請の承認、発注の却下、ヘルプ・デスク・リクエストへのフィードバックの提供などがあります。参加者には次の3つのタイプがあります。

- ユーザー
タスクの操作に個別のユーザーを割り当てることができます。たとえば、特定のタスクに対してユーザーjlondonやjsteinを割り当てることができます。ユーザーは、SOAインフラストラクチャで構成されたアイデンティティ・ストアに定義されます。これらのユーザーは、Oracle WebLogic Serverの組込みLDAP、Oracle Internet Directoryまたはサード・パーティのLDAPディレクトリで定義できます。

- グループ
タスクの操作にグループを割り当てることができます。グループには、タスクを要求して操作できる個別のユーザーが含まれています。たとえば、ユーザーjcooperとfkafkaは、タスクの操作を割り当てたグループLoanAgentGroupのメンバーである可能性があります。

ユーザーと同様に、グループはSOAインフラストラクチャのアイデンティティ・ストアに定義されます。

- アプリケーション・ロール
タスクの要求と操作に、アプリケーション・ロールのメンバーであるユーザーを割り当てることができます。

アプリケーション・ロールは、アプリケーション・レベルで認可するように論理的にグループ化されたユーザーまたは他のロールで構成されます。これらのロールは、アプリケーション固有のもので、アプリケーションJavaポリシー・ストア(アイデンティティ・ストアではなく)で定義されます。これらのロールは、アプリケーションが直接使用するもので、Java EEコンテナによって把握されているとはかぎりません。

アプリケーション・ロールはポリシーを定義します。アプリケーション・ロールにはJava権限を付与できます。したがって、アプリケーション・ロールは、直接的または他のロールを介して間接的に付与される一連の権限を定義します。ポリシーには、エンタープライズ・グループまたはユーザーに対するアプリケーション・ロールの付与を含めることができます。ファイル・ベースのポリシー・ストアのjazn-data.xmlファイルには、これらのロールが<policy-store>の下の<app-role>要素に定義され、デプロイメント時にファーム・レベルでsystem-jazn-data.xmlに書き込まれます。これらのロールは、デプロイメント後にOracle Enterprise Manager Fusion Middleware Controlを使用して定義することもできます。ロールが事前にデプロイされている場合は、設計時に、タスク所有者または承認者をアプリケーション・ロールに設定できます。

Oracle BPM Worklistの詳細は、「タスク・フォーム」を参照してください。

27.2.1.1.4 非定型ルーティング

多様性に対応するプロセスでは、すべての参加者を常に決定できるわけではありません。ヒューマン・ワークフローを使用すると、参加者がタスク実行の一部として他の参加者を招待できるように指定できます。

詳細は、「全参加者による他の参加者の招待または新しい参加者の編集の許可」を参照してください。

27.2.1.1.5 ルーティング・フローの結果ベースの完了

デフォルトでは、タスクは、ルーティング・ポリシーに定義したフローに従って(図27-2 に示すように)、開始参加者から最終参加者へ移行します。ただし、タスクのルーティング・フロー内の特定ステップでの特定結果によっては、次の参加者へのタスクの提示を続行することが不要になったり、望ましくない場合があります。たとえば、最初のマネージャが承認を却下した場合は、2番目のマネージャにルーティングする必要はありません。ヒューマン・ワークフローでは、特定の結果が発生した場合にタスクまたはサブタスクを完了するように指定することをサポートしています。

詳細は、「次の参加者へのタスクのルーティングの停止」を参照してください。

27.2.1.2 静的、動的およびルールベースのタスク割当て

タスクへのユーザー、グループおよびアプリケーション・ロールの割当てには様々な方法があります。

- 静的タスク割当て

- 動的タスク割当て

27.2.1.2.1 静的タスク割当て

ユーザー、グループおよびアプリケーション・ロールを静的に(または、アイデンティティ・サービスを参照して)割り当てることができます。値は次のいずれかです。

- 単一のユーザー、グループまたはアプリケーション・ロール(jstein、CentralLoanRegionまたはApproverRoleなど)。

- ユーザー、グループまたはアプリケーション・ロールのデリミタ付き文字列(jstein, wfaulk, cdickensなど)。

27.2.1.2.2 動的タスク割当て

ユーザー、グループおよびアプリケーション・ロールを動的に割り当てるには、次の方法があります。

- タスク割当てパターンを使用します。このパターンを使用すると、次の操作を実行できます。

- 簡単に参加者が手動でタスクを申請できるようにします。これはデフォルトの動作です。タスク割当てパターンは適用されません。

- 参加者タイプが「単一」または「FYI」のいずれかの場合は、タスク割当てパターンを割り当てて、リクエストされたタイプの単一の割当て先を参加者のすべての割当て先候補から選択できます。
たとえば、割当て先候補がユーザーjcooper、グループLoanAgentおよびアプリケーション・ロールDevelopersで構成されているとします。さらに、リクエストされたタイプがuserであるとします。このタスク割当てパターンを適用すると、単一のユーザーが、ユーザーjcooper、グループLoanAgentのすべてのメンバー、およびアプリケーション・ロールDevelopersを付与されているすべてのユーザーから選択されます。

- 参加者タイプが「パラレル」または「シリアル」の場合は、タスク割当てパターンを割り当てて、リクエストされたタイプの単一の割当て先を参加者のそれぞれの割当て先候補から選択できます。
たとえば、割当て先候補がユーザーjcooper、グループLoanAgentおよびアプリケーション・ロールDevelopersで構成されているとします。さらに、リクエストされたタイプがuserであるとします。このタスク割当てパターンを適用すると、ユーザーjcooper、グループLoanAgent内の1人のユーザー、およびアプリケーション・ロールDevelopersを付与されている1人のユーザーが選択されます。

- XPath式を使用します。これらの式を使用すると、参加者タイプに含まれていないユーザーに対する割当てを動的に決定できます。この場合、割当て先候補のリストを作成して、そのうちの1人がタスクを申請する必要があります。
たとえば、ペイロード変数で指定されたタスク承認者の動的リストを作成するというビジネス要件を設定できます。このXPath式は、0(ゼロ)個以上のXMLノードに解決できます。各ノード値には、単一のユーザー、グループまたはアプリケーション・ロールか、デリミタで区切られたユーザー、グループまたはアプリケーション・ロールの文字列を指定できます。割当て先のデリミタ付き文字列のデフォルト・デリミタはカンマ(,)です。

たとえば、タスクに、タスク承認者が格納されているpoという名前のペイロード・メッセージ属性がある場合は、次のXPath式を使用できます。

/task:task/task:payload/po:purchaseOrder/po:approvers

ids:getManager('jstein', 'jazn.com')

この式は、jsteinのマネージャを返します。

ids:getReportees('jstein', 2, 'jazn.com')

この式は、jsteinの2レベルまでの報告先すべてを返します。

ids:getUsersInGroup('LoanAgentGroup', false, 'jazn.com')

この式は、グループLoanAgentGroupのすべての直接ユーザーと間接ユーザーを返します。

両方のオプションを同時に使用できます(たとえば、XPath式を使用してグループを動的に選択してから、タスク割当てパターンを適用して、そのグループからユーザーを動的に選択できます)。

27.2.1.2.3 ビジネス・ルールを使用したタスク割当て

複雑な式を使用してタスク参加者のリストを作成できます。ビジネス・ルールの使用結果は、XPath式の使用結果と同じです。ビジネス・ルールを使用して作成された参加者リストにタスク割当てパターンを適用することもできます。

27.2.1.3 タスクのステークホルダ

タスクには複数のステークホルダーが含まれます。参加者は、タスク定義の割当ておよびルーティングのセクションに定義されたユーザーです。これらのユーザーは、タスクに対してアクションを実行する主要なステークホルダーです。

割当ておよびルーティング・ポリシーに指定されている参加者に加えて、ヒューマン・ワークフローでは次の追加のステークホルダーがサポートされています。

- 所有者
この参加者には、タスクに対するビジネス管理権限があります。この参加者は、タスク定義の一部として指定したり、起動プロセスから(および特定のインスタンスに)指定することができます。タスク所有者は、所有するタスクを操作したり、他の参加者のかわりにタスクを操作することもできます。タスク所有者は、タスクの結果と割当ての両方を変更できます。

ヒューマン・タスク・エディタで所有者を指定するには「タスク所有者の指定方法」、または「ヒューマン・タスク」ダイアログ・ボックスの「詳細」タブで所有者を指定するには「タスク所有者の指定」を参照してください。

- イニシエータ
プロセスを開始するユーザーです(たとえば、イニシエータは承認用の経費レポートを提出します)。このユーザーは、開始したタスクのフィルタを使用してタスクのステータスを確認できます。また、他の参加者による情報のリクエストに関する潜在的候補者としてイニシエータを含めることは、有用な考え方です。

詳細は、「タスク・イニシエータとタスク優先度の指定」を参照してください。

- レビューア
この参加者は、タスクのステータスを確認して、コメントおよび添付ファイルを追加できます。プロセス・インスタンスの属性レビューアおよびreviewerTypeを使用して実行時に参加者にレビューア・ロールを付与できます。レビューア・プロセス属性には、レビューアの名前が格納され、そのデフォルト値はProcessReviewerまたはヒューマン・タスク構成で割り当てられた値です。reviewerTypeプロセス属性には、レビューアのタイプが格納され、それらはユーザー、ロールまたはグループです。これらの属性を動的に設定して有効なレビューアを変更することができます。

- 管理者
この参加者は、すべてのタスクを表示して、テストの再割当てやエラーを処理するためのタスクの一時停止などの特定のアクションを実行できます。タスク管理者は、タスクの結果を変更できます。

タスク管理者は、タスク参加者が実行できる承認、却下などのアクション・タイプは実行できませんが、この参加者タイプは再割当て、取消しなどのアクションを実行できるため最も強力なタイプです。

- エラー割当て先
エラーが発生すると、タスクはこの参加者に割り当てられます(存在しないユーザーにタスクが割り当てられた場合など)。エラーの割当て先は、Oracle BPM Worklistからタスク・リカバリ・アクションを実行できます。Oracle BPM Worklistは、実行時にタスク・アクションを実行するタスク・フォームです。

詳細は、「エラー割当て先とレビューアの構成方法」を参照してください。

27.2.1.4 タスク期限

ヒューマン・ワークフローでは、タスクに関連する期限の指定がサポートされています。期限には、次のアクションを関連付けることができます。

- リマインダ:
割当て後の時刻または有効期限前の時刻に基づいて、タスクのリマインダを複数回送信できます。

- エスカレーション:
タスクは、管理階層にエスカレートされます。

- 期限切れ:
タスクは期限切れです。

- 更新:
タスクは、自動的に更新されます。

詳細は、「タスクのエスカレート、期限更新または終了」を参照してください。

27.2.1.5 通知

ヒューマン・タスクは、通知を使用するように構成できます。通知を使用すると、関連するユーザーに、タスクのライフ・サイクル期間にタスクの状態が変化したことを警告できます。たとえば、タスクの承認や取消しの際は、通知が割当て先に送信されます。

異なるアクションについて様々なタイプの参加者に通知を送信するように指定できます。たとえば、次のように指定できます。

- タスクの所有者は、タスクがエラー状態の場合(存在しないユーザーに送信された場合など)通知メッセージを受信します。

- タスク割当て先は、タスクがエスカレートされた場合通知メッセージを受信します。

通知メッセージのコンテンツと、メッセージの送信に使用する通知チャネルを指定できます。

- Email
アクション可能な電子メール通知メッセージを構成できます。つまり、タスク割当て先は、その電子メール内からタスクを操作できます。

- ボイス・メッセージ

- インスタント・メッセージ(IM)

- ショート・メッセージ・サービス(SMS)

たとえば、タスク割当て先がタスクを操作する前に追加の情報をリクエストした場合は、次に示すようなメッセージを電子メールで送信できます。

For me to approve this task, more information is required to justify the need
for this business trip

実行時には、メッセージ送信者のアドレスをスパムとしてマークし、不正または無効なアドレス・リストを表示することもできます。これらのアドレスは、不正アドレス・リストに自動的に追加されます。

通知の詳細は、次を参照してください。

- 通知サービスの使用

- 参加者の通知プリファレンスの指定

- 第XI部「Oracle User Messaging Serviceの使用」

27.2.1.6 タスク・フォーム

タスク・フォームは、タスクと相互作用する方法を提供します。Oracle BPM Worklistのタスク・フォームには、タスク割当て先に割り当てられたすべてのワークリスト・タスクが表示されます。特定のタスクに移動すると、タスク・フォームには、ユーザーのワークリストに対するタスクのコンテンツが表示されます。たとえば、経費承認タスクでは様々な経費の明細項目が記載されたフォームが表示され、ヘルプ・デスク・タスク・フォームでは重大度や問題の場所などの詳細が表示されます。

このため、Oracle SOA Suiteの統合開発環境には、Oracle Application Development Framework (Oracle ADF)が含まれています。Oracle ADFを使用すると、SOAコンポジット・アプリケーションのヒューマン・タスクを表すタスク・フォームを設計できます。

ADFベースのタスク・フォームは自動的に生成できます。上級ユーザーは、ADFデータ・コントロールを使用して独自のタスク・フォームを設計して、ページ上にコンテンツをレイアウトし、実行時にはワークフロー・サービス・エンジンに接続して、タスク・コンテンツを取得し、タスクを操作できます。

タスク・フォームは、JSF、.NET、またはAPIを使用する他のクライアント・テクノロジで作成できます。

詳細は、次を参照してください。

- 「ヒューマン・タスク用のタスク・フォームの設計」。

- Oracle BPM Worklistの使用

27.2.1.7 拡張概念

この項では、ヒューマン・ワークフローの拡張概念について説明します。

- ルールベースのルーティング
Oracle Business Rulesを使用すると、ルーティング・フローを動的に変更できます。使用すると、参加者がそれぞれの手順を完了するたびに、関連付けられているルールが起動し、そのルールからルーティング・フローをオーバーライドできます。

詳細は、「ビジネス・ルールを使用した詳細タスク・ルーティングの指定方法」を参照してください。

- ルールベースの参加者割当て
Oracle Business Rulesを使用すると、参加者に関連付けるユーザー、グループおよびロールのリストを動的に作成できます。

詳細は、「タスク参加者の割当て」を参照してください。

- ステージ
ステージは、参加者タイプの各ブロックに対して承認プロセスを編成するための1方法です。1つ以上のステージを順番に、またはパラレルで指定できます。各ステージ内で、1つ以上の参加者タイプ・ブロックを順番に、またはパラレルで指定できます。

詳細は、「タスク参加者の割当て」を参照してください。

- アクセス・ルール
割当て先が表示および更新できるタスクの部分を決定するアクセス・ルールを指定できます。たとえば、割当て先が読み取るタスク・ペイロード・データを構成できます。このアクションを使用できるのは、読取り権限のある割当て先のみです。割当て先も含めて、誰にも書込み権限はありません。

詳細は、「アクセス・ルールの概要」を参照してください。

- コールバック
ヒューマン・ワークフローでは、宣言的に指定可能な詳細な動作がサポートされていますが、一部の高度な状況では、さらに拡張可能な動作が必要になる場合があります。このような拡張性はタスク・コールバックによって可能となり、これらのコールバックは、BPELプロセスまたはJavaクラスの起動時に処理できます。

詳細は、「Javaコールバックの指定」を参照してください。

27.2.1.8 レポートおよび監査証跡

Oracle BPM Worklistには、タスク分析用の組込みレポートが複数用意されています。

- 不参加タスク
ユーザーのグループまたは報告先のグループに割り当てられたタスクの中で、まだ獲得されていないタスクが分析されます。

- タスクの優先度
ユーザー、報告先またはそのグループに割り当てられたタスクが優先度に基づいて分析されます。

- タスクのサイクル・タイム
ユーザーのグループまたは報告先のグループに基づいて、タスクの割当てから完了までの所要時間が分析されます。

- タスクの生産性
ユーザー、報告先またはグループについて、特定期間中に割り当てられたタスク数と完了したタスク数が分析されます。

- タスク時間分布
割当て先がタスクを実行するために要した時間が表示されます。

タスクの参加者が実行したアクションの監査証跡、およびワークフローの様々な時点におけるタスク・ペイロードと添付ファイルのスナップショットを表示できます。タスクの短い履歴には、次のタスクによって作成されたすべてのバージョンが表示されます。

- タスクの開始

- タスクの再開始

- タスクの結果の更新

- タスクの完了

- タスクのエラー処理

- タスクの期限切れ

- タスクの取消し

- エラー割当て先に対するタスクのアラート

詳細は、「Oracle BPM Worklistの使用」を参照してください。

27.2.2 ヒューマン・ワークフローの設計ステージの概要

ヒューマン・ワークフローのモデリングは、3つのモデリング・ステージで構成されます。

- ステージ1: ヒューマン・タスクのコンテンツは、ヒューマン・タスク・エディタで作成および定義します。これには、参加者タイプ、ルーティング・ポリシー、エスカレーションと有効期限のポリシー、通知などの定義が含まれます。詳細は、「ヒューマン・タスク定義の作成の概要」を参照してください。

- ステージ2: ヒューマン・タスク定義をBPELプロセスに関連付けます。BPELプロセスは、一連のアクティビティ(ヒューマン・タスク・アクティビティを含む)とサービスをエンドツーエンドのプロセス・フローに統合します。詳細は、「ヒューマン・タスク定義とBPELプロセスの関連付けの概要」を参照してください。

- ステージ3: タスク・フォームを作成します。このフォームでは、実行時にOracle BPM Worklistで操作するタスクの詳細が表示されます。詳細は、「タスク・フォームの生成の概要」を参照してください。

27.3 ヒューマン・ワークフローのユースケースの概要

この項では、ヒューマン・ワークフローのユースケースとサービスの概要を説明します。この項の後で、ヒューマン・タスク全体の設計をチュートリアルで説明します。

27.3.1 ユーザーまたはロールへのタスクの割当て

休暇申請プロセスは、ユーザーから休暇の詳細を取得し、承認担当のマネージャにその申請をルーティングすることから開始されます。ユーザーの詳細と組織階層は、ユーザー・ディレクトリまたはアイデンティティ・ストアからルックアップできます。図27-3 に、このシナリオを示します。

図27-3 ディレクトリ内のユーザーまたはロールに対するタスクの割当て

27.3.2 様々な参加者タイプの使用

タスクは、「グループ投票」、「管理チェーン」または「承認者の順序リスト」参加者タイプの複数のユーザーを介してルーティングできます。たとえば、融資承認フローの一部として融資申請が考えられます。融資申請は、初めに融資エージェント・ロールに割り当てることができます。融資金額が$100,000を超えている場合は、特定の融資エージェントが融資を取得して承認した後で、さらに複数の管理レベルにその融資をルーティングさせることが可能です。図27-4 に、このシナリオを示します。

図27-4 フロー・パターンとルーティング・ポリシー

これらのタイプをビルディング・ブロックとして使用することで、複雑なワークフローを作成できます。

27.3.3 エスカレーション、有効期限および委任

カスタム・エスカレーション機能を使用すると、タスク・タイプに基づいて、優先度の高いタスクを特定のユーザーまたはロールに割り当てることができます。ただし、ユーザーが一定期間内にタスクを操作しない場合は、そのタスクを期限切れとし、追加アクションのためにマネージャにエスカレートできます。エスカレーションの一環として、電子メール、電話ボイス・メッセージまたはSMSでユーザーに通知することも可能です。同様に、マネージャは、様々なタスク割当て間で負荷を分散するために、ある報告先から別の報告先にタスクを委任できます。BPELで定義されるすべてのタスクには、関連する有効期限があります。また、図27-5 に示すように、エスカレーション・ポリシーまたは期限更新ポリシーを指定する場合もあります。たとえば、ヘルプ・デスク・サービス・リクエストのプロセスの一部としてサポート・コールが考えられます。優先度の高いタスクを特定のユーザーに割り当て、そのユーザーが2日以内に対応しない場合、そのタスクは、追加アクションのためにマネージャにルーティングされます。

図27-5 エスカレーションと通知

27.3.4 自動割当ておよび委任

ユーザーは、自分のかわりに他のユーザーにタスクを実行させるように決定できます。タスクは、Oracle BPM Worklistから明示的または自動的に委任することができます。たとえば、マネージャは、自分が担当する高優先度のタスクを、休暇中はすべて自動的に直属の部下の1人にルーティングするという休暇ルールを設定します。タスクをその内容に基づいて別のユーザーにルーティングできる場合もあります。自動ルーティングのもう1つの例は、グループに属する複数のユーザー間でタスクを割り当てることです。たとえば、ヘルプ・デスクの監督者は、西部地域のすべてのタスクをラウンド・ロビン方式で割り当てたり、未処理タスクの最も少ないユーザー(最もビジーでない箇所)にタスクを割り当てるように決定します。

27.3.5 タスク・コンテンツに基づいたユーザーの動的割当て

人事部のJamesという従業員が$5000の新しいハードウェアの購入を申請します。この会社には、$3000を超えるすべてのハードウェアの購入はマネージャおよび副社長の承認が必要で、ITの取締役が確認するというポリシーがあります。このシナリオでは、ワークフローを、Jamesのマネージャ、人事部の副社長およびITの取締役を自動的に判断するように構成できます。ハードウェアの購入前に、発注書がこれら3人の承認者にルーティングされます。

27.4 ヒューマン・ワークフロー・アーキテクチャの概要

この項では、ヒューマン・ワークフロー・アーキテクチャの概要を説明します。次の内容について説明します。

- タスクのライフ・サイクル中に様々な操作を実行するサービス。これには、ユーザーのタスクの問合せ、タスクに関連したメタデータ情報の取得などがあります。

- ヒューマン・タスクは、次の2つの方法で使用します。

- BPELプロセス・サービス・コンポーネントへの関連付け

- スタンドアロン・モードでの使用

- ヒューマン・タスクの期間におけるサービス・エンジンの役割。

27.4.1 ヒューマン・ワークフロー・サービス

リリース11g 以降、すべてのヒューマン・タスク・メタデータはメタデータ・サービス(MDS)リポジトリに保存されて管理されます。ワークフロー・サービスは、ビジネス・プロセスと人間の相互作用の様々な側面を処理する多数のサービスで構成されています。

図27-6 は、次のワークフロー・サービス・コンポーネントを示しています。

- タスク・サービス:
タスク・サービスにより、タスク状態の管理およびタスクの永続性が提供されます。これらのサービスに加え、タスク・サービスでは、タスクの更新、完了、エスカレート、再割当てなどの操作が公開されます。タスク・サービスは、ユーザーに割り当てられているタスクを取得するためにOracle BPM Worklistで使用されます。また、このサービスでは、タスク状態が変化したときにユーザーやグループに通知を送信するかどうかも決定されます。タスク・サービスは、次のサービスで構成されます。

- タスク・ルーティング・サービス
タスク・ルーティング・サービスは、タスクのルーティング、エスカレートおよび再割当てを実行するサービスを提供します。サービスでは、宣言的な指定をルーティング・スリップ形式で解析することで、これらの決定が行われます。

- タスク問合せサービス
タスク問合せサービスでは、様々な検索基準(キーワード、カテゴリ、ステータス、ビジネス・プロセス、属性値、タスクの履歴情報など)に基づいて、ユーザーのタスクを問い合せます。

- タスク・メタデータ・サービス
タスク・メタデータ・サービスにより、タスク関連のメタデータ情報を取得するための操作が公開されます。

- アイデンティティ・サービス
アイデンティティ・サービスは、11gのセキュリティ・インフラストラクチャまたはカスタム・ユーザー・リポジトリの上部に位置するWebサービスのシン・レイヤーです。これにより、ユーザーの認証および認可と、ユーザー・プロパティ、ロール、グループ・メンバーシップ、権限のルックアップが可能になります。

- 通知サービス
通知サービスは、電子メール、電話ボイス・メッセージ、IMおよびSMSのいずれかのチャネルを通じて、指定のユーザーに対して特定のコンテンツを含む通知を配信します。詳細は、「ヒューマン・ワークフローからの通知」を参照してください。

- ユーザー・メタデータ・サービス
ユーザー・メタデータ・サービスにより、ワークフロー・ユーザー関連のメタデータ(ユーザー作業キュー、プリファレンス、休暇、委任ルールなど)が管理されます。

- ランタイム構成サービス
ランタイム構成サービスは、タスク・サービスのランタイム環境で使用されるメタデータの管理メソッドを提供します。主に、タスク・ペイロード・マップ済属性マッピングの管理をサポートします。

- エビデンス・サービス
エビデンス・サービスはデジタル署名されたワークフロー・タスクの保存と否認防止をサポートします。

図27-6 ワークフロー・サービス・コンポーネント

図27-7 は、サービスとビジネス・プロセス間の相互作用を示しています。

図27-7 ワークフロー・サービスとビジネス・プロセス間の相互作用

27.4.2 ヒューマン・タスクの使用

ヒューマン・タスクは、次の方法で使用できます。

- BPELプロセスへのヒューマン・タスクの関連付け
ヒューマン・タスクをBPELプロセスに関連付けることができます。BPELプロセスは、一連のアクティビティ(ヒューマン・タスク・アクティビティを含む)とサービスをエンドツーエンドのプロセス・フローに統合します。

- BPMNプロセスへのヒューマン・タスクの関連付け
ヒューマン・タスクをBPMNプロセスに関連付けることができます。BPMNプロセスには、プロセスのフローの一部として他のタイプのBPMNフロー・オブジェクトが含まれる場合があります。ヒューマン・タスクは、BPMNユーザー・タスクの実装です。

- スタンドアロンのヒューマン・タスク
では、BPELプロセスに関連付けないスタンドアロン・コンポーネントとしてのヒューマン・タスクを作成することもできます。スタンドアロン・ヒューマン・タスク・サービス・コンポーネントは、アプリケーションで自動化されたアクティビティが必要のない環境で役に立ちます。スタンドアロンの場合、クライアントは独自にタスクを作成できます。

27.4.3 サービス・エンジン

実行時、ヒューマン・タスク・サービス・コンポーネントのビジネス・ロジックおよび処理ルールは、ヒューマン・ワークフロー・サービス・エンジンによって実行されます。各サービス・コンポーネント(BPELプロセス、ヒューマン・ワークフロー、デシジョン・サービス(ビジネス・ルール)およびOracle Mediator)には、タスクを実行するための独自のサービス・エンジン・コンテナがあります。すべてのヒューマン・タスク・サービス・コンポーネントは、属しているSOAコンポジット・アプリケーションに関係なく、単一のヒューマン・タスク・サービス・エンジンで実行されます。

ヒューマン・ワークフロー・サービス・エンジンの構成、監視および管理を行う方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

27.5 Oracle SOA SuiteとOracle BPM Suiteの間のヒューマン・ワークフローとビジネス・ルールの相違

Oracle SOA SuiteとOracle Business Process Management (BPM) Suiteは、どちらもビジネス・ルールとヒューマン・ワークフローのサポートを提供しています。ただし、Oracle BPM Suiteには、Oracle SOA Suiteでは使用できない追加のビジネス・ルールおよびヒューマン・ワークフロー機能があります。表27-1 は、各スイートでサポートされるビジネス・ルールおよびヒューマン・ワークフロー機能を示しています。

表27-1 Oracle SOA SuiteおよびOracle BPM Suiteにおけるビジネス・ルールおよびヒューマン・ワークフロー機能

機能

Oracle BPM Suiteでサポートされているか

Oracle SOA Suiteでサポートされているか

ワークスペース、プロセス・トラッキング、標準ダッシュボード、ケース管理およびアプリケーション・メニュー

はい

いいえ

承認グループ(参加者リスト)

はい

いいえ

ヒューマン・ワークフローおよびビジネス・ルール(参加者リスト、ルーティング・ルール)

はい

はい

動詞ルール

はい

いいえ

ルール・ビジネス・フレーズ

はい

いいえ

Oracle BPM Composer - デザインタイム・ルール編集

はい

いいえ

Oracle BPM StudioとOracle BPM Composerとの間のソース管理のためのプロセス・アセット・カタログ(PAM)

はい

いいえ

拡張されたユーザビリティ機能を持つOracle JDeveloperとSOA Composerの両方でのルール・テスト

はい

はい

ルール・デシジョン表に対するMicrosoft Excelのインポート/エクスポート

はい

はい

Oracle BPM Suiteの詳細は、Oracle Business Process Management Studioを使用したビジネス・プロセスの開発を参照してください。

28 ヒューマン・タスクの作成

この章では、ヒューマン・タスクの作成方法、保存方法、およびヒューマン・タスクをBPELプロセスに関連付ける方法について説明します。また、ヒューマン・タスクの削除方法と、ヒューマン・タスクとBPELプロセスの関連付けを削除する方法についても説明します。

この章の内容は次のとおりです。

- ヒューマン・タスクの概要

- ヒューマン・タスクの作成

- ヒューマン・タスクの構成

- ヒューマン・タスク・エディタの終了と変更の保存

- ヒューマン・タスクとBPELプロセスの関連付け

ヒューマン・タスクの概念の詳細は、「ヒューマン・ワークフローのスタート・ガイド」を参照してください。

ヒューマン・ワークフロー問題のトラブルシューティングの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のヒューマン・ワークフローのトラブルシューティングに関する項を参照してください。

デモ・ユーザー・コミュニティと呼ばれるユーザーおよびグループの組織階層のインストールおよび使用方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の付録「データベースでのデモ・ユーザー・コミュニティのインストール」を参照してください。

28.1 ヒューマン・タスクの概要

Oracle SOA Suiteには、タスク・メタデータをモデリングするための、ヒューマン・タスク・エディタと呼ばれるグラフィカル・ツールが用意されています。モデリング・プロセスは、次のタスクで構成されています。

- でのヒューマン・タスク・サービス・コンポーネントの作成とモデリング

- BPELプロセスとの関連付け

- 実行時にOracle BPM Worklistにヒューマン・タスクを表示するためのタスク・フォームの生成。

ヒューマン・タスク・エディタを使用するには、次の内容も含めてヒューマン・タスクの設計概念を理解する必要があります。

- タスクを割り当てるユーザーのタイプ

- ユーザーをタスクに割り当てる方法(静的、動的またはルールベース)

- ユーザーを割り当てるタスクのモデリングに使用可能なタスクの参加者タイプ

- タスク参加者のリストを作成するためのオプション

- タスクのライフ・サイクル全体に関与する参加者

この項では、これらのモデリング・タスクの概要について説明し、特定のモデリング手順の参照先を示します。

の使用方法の詳細は、「SOAコンポジット・アプリケーションの開発のスタート・ガイド」を参照してください。

使用可能なサンプルの詳細は、「ヒューマン・ワークフローのチュートリアル」を参照してください。

28.1.1 ヒューマン・タスク定義の作成の概要

ヒューマン・タスク・エディタでは、ヒューマン・タスク・メタデータ(タスクの結果、ペイロード構造、割当ておよびルーティング・ポリシー、有効期限およびエスカレーション・ポリシー、通知設定など)を指定できます。この情報は、メタデータ・タスク構成ファイル(拡張子.task)に保存されます。また、ワークフロー・パターンによっては、Oracle Business Rulesデザイナを使用して、タスクのルーティング・ポリシーまたは承認者のリストを定義する必要があります。

ヒューマン・タスクの作成後に、ヒューマン・タスクのメタデータを構成するには、ヒューマン・タスク・エディタを使用します。メタデータの詳細および構成手順は、「ヒューマン・タスクの構成」を参照してください。

ヒューマン・タスクのメタデータは、次の2つのいずれかの方法で定義します。

- ヒューマン・タスクを「コンポーネント」ウィンドウからOracle BPELデザイナのBPELプロセスにドラッグし、自動的に表示される「ヒューマン・タスクの作成」ダイアログで「追加」アイコンをクリックする方法。この操作で、ヒューマン・タスク・サービス・コンポーネントを作成するためのダイアログが表示されます。作成を完了すると、ヒューマン・タスク・エディタが表示されます。

- ヒューマン・タスク・サービス・コンポーネントを「コンポーネント」ウィンドウからSOAコンポジット・エディタにドラッグする方法。この操作で、ヒューマン・タスク・コンポーネントを作成するためのダイアログが表示されます。作成を完了すると、ヒューマン・タスク・エディタが表示されます。

詳細は、「ヒューマン・タスクの作成」を参照してください。

28.1.2 ヒューマン・タスク定義とBPELプロセスの関連付けの概要

ヒューマン・タスク設定を構成する.taskファイルは、Oracle BPELデザイナで、BPELプロセスに関連付けることができます。図28-1 に示すように、構成のためにBPELプロセス・フローにドラッグしたヒューマン・タスクとの関連が作成されます。

図28-1 BPELプロセスへのヒューマン・タスクのドラッグ

タスク定義、タスク・イニシエータ、タスク優先度、およびBPEL変数に入力データを渡すタスク・パラメータ・マッピングも指定します。さらに、拡張機能も定義できます。たとえば、スコープとグローバル・タスク変数名(デフォルト名をそのまま使用しない場合)、タスク所有者、識別キー、BPELコールバックのカスタマイズ、およびヒューマン・タスクを拡張して他のワークフロー・タスクを追加するかどうかなどです。

関連付けが完了すると、タスク・サービス・パートナ・リンクが作成されます。タスク・サービスでは、タスクの操作に必要な操作が公開されます。

では、BPELプロセスに関連付けないスタンドアロン・コンポーネントとしてのヒューマン・タスクを作成することもできます。スタンドアロン・ヒューマン・タスク・サービス・コンポーネントは、アプリケーションで自動化されたアクティビティが必要のない環境で役に立ちます。スタンドアロンの場合、クライアントは独自にタスクを作成できます。

詳細は、「ヒューマン・タスクとBPELプロセスの関連付け」を参照してください。

28.1.3 タスク・フォームの生成の概要

タスク・フォームは、Oracle Application Development Framework (ADF)を使用して生成できます。このフォームは、実行時にOracle BPM Worklistで操作するタスクの詳細を表示するために使用されます。

タスク・フォームの生成の詳細は、「ヒューマン・タスク用のタスク・フォームの設計」を参照してください。

28.2 ヒューマン・タスクの作成

ヒューマン・タスク・エディタを使用すると、タスクのメタデータを定義できます。エディタでは、ヒューマン・タスク設定(タスクの結果、ペイロード構造、割当ておよびルーティング・ポリシー、有効期限およびエスカレーション・ポリシー、通知設定など)を指定できます。

ヒューマン・タスク・サービス・コンポーネントは、またはOracle BPELデザイナで作成します。作成後に、ヒューマン・タスク・エディタでコンポーネントを設計します。ヒューマン・タスク・サービス・コンポーネントを作成する方法によって、後でそのコンポーネントをBPELプロセス・サービス・コンポーネントに関連付けるのか、でスタンドアロン・コンポーネントとして存在するのかが決まります。

28.2.1 SOAコンポジット・エディタを使用してヒューマン・タスクを作成する方法

SOAコンポジット・エディタを使用して、ヒューマン・タスクを作成できます。この方法は、ヒューマン・タスクを作成し、後でBPELプロセッサに関連付けるか、スタンドアロン・コンポーネントとして使用する場合に使用できます。

SOAコンポジット・エディタでヒューマン・タスク・サービス・コンポーネントを作成する手順は、次のとおりです。

1. でヒューマン・タスク・サービス・コンポーネントを作成するSOAプロジェクトに進みます。

2. 「コンポーネント」ウィンドウのリストから、「SOA」を選択します。
リストがリフレッシュされ、サービス・コンポーネントおよびサービス・アダプタが表示されます。

3. リストからデザイナに「Human Task」をドラッグします。
「ヒューマン・タスクの作成」ダイアログが表示されます。

4. 「名前」フィールドに、名前を入力します。
入力した名前は、.taskファイル名になります。

5. 「SOAPバインディングを持つコンポジット・サービスの作成」チェック・ボックスに注目します。このチェック・ボックスの選択によって、ヒューマン・タスク・サービス・コンポーネントの作成方法が決まります。

a. 後でBPELプロセス・サービス・コンポーネントに関連付けるヒューマン・タスク・サービスを作成する場合は、「SOAPバインディングを持つコンポジット・サービスの作成」チェック・ボックスを選択しないでください。ヒューマン・タスク・サービス・コンポーネントは、BPELプロセス・サービス・コンポーネントに明示的に関連付けられるコンポーネントとして作成されます。図28-2に詳細を示します。

図28-2 ヒューマン・タスク・コンポーネント

b. ヒューマン・タスク・サービス・コンポーネントをでスタンドアロン・コンポーネントとして作成するには、「SOAPバインディングを持つコンポジット・サービスの作成」チェック・ボックスを選択します。これにより、Simple Object Access Protocol (SOAP) Webサービスと自動的に接続されるヒューマン・タスク・サービス・コンポーネントが作成されます。図28-3に詳細を示します。

図28-3 スタンドアロン・ヒューマン・タスク・コンポーネント

このWebサービスは、外部の顧客に、SOAコンポジット・アプリケーションのヒューマン・タスク・サービス・コンポーネントへのエントリ・ポイントを提供します。

6. 「OK」をクリックします。

におけるヒューマン・タスク・サービス・コンポーネントの作成方法の詳細は、「SOAコンポジット・アプリケーションの開発のスタート・ガイド」を参照してください。

28.2.2 Oracle BPELデザイナを使用してヒューマン・タスクを作成する方法

Oracle BPELデザイナを使用して、ヒューマン・タスクを作成できます。通常、この方法は、BPELプロセスで使用するヒューマン・タスクを作成する場合に使用します。

Oracle BPELデザイナでヒューマン・タスクを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOAコンポーネント」を開きます。

2. リストからデザイナに「Human Task」をドラッグします。

「ヒューマン・タスクの作成」ダイアログが表示されます。

3. 「追加」アイコンをクリックして、ヒューマン・タスクを作成します。

4. 「名前」フィールドに、名前を入力します。

入力した名前は、.taskファイル名になります。

5. 「タイトル」フィールドにタスクを入力します。

6. 「OK」をクリックします。

ヒューマン・タスク・エディタが表示されます。

注意:

後でBPELプロセスに関連付けるヒューマン・タスクも作成できますが、その場合は、「ファイル」メイン・メニューから「新規」を選択し、次に「SOA層」→「サービス・コンポーネント」→「ヒューマン・タスク」の順に選択してください。

28.2.3 ヒューマン・タスク作成時の処理内容

ヒューマン・タスクが作成されると、次のフォルダとファイルが表示されます。

- ヒューマン・タスク・エディタで指定したヒューマン・タスク設定が、メタデータ・サービス(MDS)リポジトリのメタデータ・タスク構成ファイル(拡張子.task)に保存されます。このファイルは、「SOA_Project_Name」→「SOA」の下にある「アプリケーション」ウィンドウに表示されます。次をダブルクリックすると、このファイル内の設定を再編集できます。

- またはOracle BPELデザイナの「アプリケーション」ウィンドウにある.taskファイル

- 、またはOracle BPELデザイナのBPELプロセスにある「ヒューマン・タスク」アイコン。

これにより、.taskファイルがヒューマン・タスク・エディタで再び開きます。

- 作成したヒューマン・タスクを含む「ヒューマン・タスク」フォルダは、の「構造」ウィンドウに表示されます。

図28-4 に、これらのフォルダとファイルを示します。

図28-4 ヒューマン・タスクのフォルダとファイル

使用可能なサンプルの詳細は、「ヒューマン・ワークフローのチュートリアル」を参照してください。

28.3 ヒューマン・タスクの構成

ヒューマン・タスクの作成後、ヒューマン・タスク・エディタを使用して設定を変更します。ヒューマン・タスクの構成方法の詳細は、「ヒューマン・タスクの構成」を参照してください。

28.4 ヒューマン・タスク・エディタの終了と変更の保存

ヒューマン・タスクの変更は、いつでも保存できます。「アプリケーション」ウィンドウでメタデータ・タスク構成ファイル(.task)をダブルクリックすると、後からタスクを再編集できます。

ヒューマン・タスク・エディタを終了し、変更内容を保存する手順は、次のとおりです。

1. 「ファイル」メイン・メニューから「保存」を選択するか、「X」記号(図28-5 を参照)をクリックして、.taskメタデータ・タスク構成ファイルを閉じます。

図28-5 ファイルのクローズ

2. 「X」記号をクリックして、変更内容の保存を求めるプロンプトが表示された場合は「はい」を選択します。

28.5 ヒューマン・タスクとBPELプロセスの関連付け

で作成したヒューマン・タスク・サービス・コンポーネントをBPELプロセスに関連付けるには、次の指示に従います。関連付けが完了すると、Oracle BPELデザイナにタスク・サービス・パートナ・リンクが作成されます。タスク・サービスでは、タスクの実行に必要な操作が公開されます。

ヒューマン・タスクの作成方法の詳細は、「ヒューマン・タスクの作成」を参照してください。

28.5.1 ヒューマン・タスクをBPELプロセスに関連付ける方法

ヒューマン・タスク・サービス・コンポーネントをBPELプロセスに関連付ける方法は2種類あります。

- SOAコンポジット・アプリケーションでヒューマン・タスク・サービス・コンポーネントを作成した場合は、Oracle BPELデザイナでヒューマン・タスク・アクティビティをBPELプロセスにドラッグします。次に、「ヒューマン・タスクの作成」ダイアログの「タスク定義」リストから既存のヒューマン・タスク・サービス・コンポーネントを選択します。次に、タスクのタイトル、イニシエータ、パラメータ値およびその他の値を指定します。

- ヒューマン・タスク・サービス・コンポーネントを作成していない場合は、Oracle BPELデザイナのBPELプロセスにヒューマン・タスク・アクティビティをドラッグします。次に、「ヒューマン・タスクの作成」ダイアログの「タスク定義」リストの右側にある「追加」アイコンをクリックします。これで、新しいヒューマン・タスク・サービス・コンポーネントの名前、パラメータおよび結果を指定できます。次に、残りのタスク・メタデータを設計するためのヒューマン・タスク・エディタが開きます。設計完了後、ヒューマン・タスク・エディタを閉じます。

ヒューマン・タスクをBPELプロセスに関連付ける手順は、次のとおりです。

1. に移動します。

2. ヒューマン・タスク・サービス・コンポーネントの.taskファイルを関連付ける先のBPELプロセス・サービス・コンポーネントをダブルクリックします。

3. 「コンポーネント」ウィンドウで、「SOAコンポーネント」を開きます。

4. 新規のHuman TaskアクティビティをBPELプロセスにドラッグ・アンド・ドロップします。

5. ヒューマン・タスク・アクティビティをダブルクリックします。

「Human Task」ダイアログが表示されます。

6. 「一般」タブの「タスク定義」リストから、ヒューマン・タスクを選択します(図28-6 を参照)。

図28-6 「タスク定義」リストの選択

ヒューマン・タスク・サービス・コンポーネントの.taskファイルがBPELプロセスに関連付けられます。

注意:

ヒューマン・タスク・アクティビティをBPELプロセスに関連付けて「ヒューマン・タスクの作成」ダイアログを閉じた後は、そのヒューマン・タスク・アクティビティをOracle BPELデザイナでダブルクリックして、このダイアログにいつでも再アクセスできます。

28.5.2 ヒューマン・タスクとBPELプロセス間のワイヤの削除に関する必知事項

BPELプロセスとそのプロセスが起動するヒューマン・タスク・サービス・コンポーネント間のワイヤを削除すると、ヒューマン・ワークフローのinvokeアクティビティがBPELプロセスから削除されます。ただし、アクションを実行する(承認、却下、その他のタスクの結果を含む)「taskSwitch」switchアクティビティはそのまま残ります。このように設計されている理由は、次のとおりです。

- switchアクティビティには、ユーザーが入力したBPELコードが格納されています。

- このswitchは、ワイヤの削除が単に別のヒューマン・タスクを指すことを意図している場合は再利用できます。

- switchの削除はシングルステップのアクションです。

次に、同じ「taskSwitch」switchアクティビティを使用するためにヒューマン・タスク・サービス・コンポーネントをBPELプロセスにドラッグ・アンド・ドロップすると、新しい「taskSwitch」switchアクティビティが作成されます。BPELプロセスに同じ名前の2つのswitchアクティビティが存在する状態になります。どちらを削除するかを判断するには、「taskSwitch」switchアクティビティの承認、却下および他の結果を調査し、修正した古いswitchと新しいswitchを判断する必要があります。

28.5.3 ヒューマン・タスク・アクティビティのタイトル、イニシエータ、優先度およびパラメータ変数の定義方法

図28-7 に、ヒューマン・タスクを選択した後に表示される「一般」タブを示します。

図28-7 「Human Task」 - 「一般」タブ(選択後)

「Human Task」アクティビティ・ダイアログの「一般」タブでは、表28-1 に示す操作を実行できます。

表28-1 「Human Task」 - 「一般」タブ

フィールド

参照先

タスクのタイトル

タスクのタイトルの指定

イニシエータ

優先度

タスク・イニシエータとタスク優先度の指定

タスク・パラメータ

タスク・パラメータの指定

28.5.3.1 タスクのタイトルの指定

タスクのタイトルは、実行時にOracle BPM Worklistに表示されます。これは必須フィールドです。「タスクのタイトルの指定方法」の説明に従ってヒューマン・タスク・エディタの「一般」セクションの「タスクのタイトル」フィールドに入力したタスクのタイトルは、このフィールドに入力したタイトルによってオーバーライドされます。

「一般」タブの「タスクのタイトル」フィールドに、手動でタスクのタイトルを入力します。または、フィールドの右側にあるアイコンをクリックして「式ビルダー」ダイアログを表示し、タイトルを動的に作成します。

同じタイトルに静的なテキストと動的な式を併用することもできます。動的なテキストを使用するには、テキストの適切な位置にカーソルを置き、右側にあるアイコンをクリックして「式ビルダー」ダイアログを起動します。

28.5.3.2 タスクの起案者と優先度の指定

タスク・イニシエータを指定できます。イニシエータとは、タスクを開始するユーザーです。イニシエータは、作成したタスクをOracle BPM Worklistで参照したり、特定のタスク(タスクの取下げや一時停止など)を実行することができます。

タスク・イニシエータとタスク優先度を指定する手順は、次のとおりです。

1. 「一般」タブの「イニシエータ」フィールドに、イニシエータ(たとえばjcooper)を入力するか、右側にあるアイコンをクリックして「式ビルダー」ダイアログを表示し、イニシエータを動的に指定します。このフィールドはオプションです。イニシエータが指定されていない場合は、「Human Task」ダイアログの「詳細」タブで指定したタスク所有者にデフォルト設定されます。タスク所有者も指定されていない場合、イニシエータはbpeladminにデフォルト設定されます。

2. 「優先度」リストで1 (最高値)から5の優先度値を選択します。これはユーザーが参照するためのフィールドで、このタスクの優先度が実行時に高くなることはありません。優先度を使用して、Oracle BPM Worklistでタスクをソートします。ヒューマン・タスク・エディタの「一般」セクションの「優先度」リストで選択した優先度値は、この優先度値によってオーバーライドされます。

ヒューマン・タスク・エディタの優先度の指定の詳細は、「タスクのタイトルの指定方法」を参照してください。

28.5.3.3 タスク・パラメータの指定

「タスクのタイトル」および「イニシエータ」フィールドを完了すると、タスク・パラメータ表(図28-8 を参照)にタスク・パラメータのリストが表示されます。

図28-8 タスク・パラメータ表

タスク・パラメータを指定する手順は、次のとおりです。

1. 「BPEL変数」列で、「...」をダブルクリックして、タスク・パラメータをBPEL変数にマップします。選択するためにこの「...」を表示するには、データ・パラメータがすでに指定されている必要があります。データ・パラメータの指定方法の詳細は、「タスク・ペイロード・データ構造の指定方法」を参照してください。マップする必要があるのは、入力データを使用するタスク・パラメータのみです。Oracle BPM Worklistから入力された出力データの場合、対応する変数のマップは不要です。

「タスク・パラメータ」ダイアログが表示されます。

2. 「変数」ツリー(図28-9 を参照)を開き、適切なタスク変数を選択します。

図28-9 「変数」ツリー

3. 「OK」をクリックします。

図28-10 に示す「Human Task」ダイアログが次のように表示されます。

図28-10 「Human Task」ダイアログ

4. ヒューマン・タスク・アクティビティの拡張機能を定義するには、「詳細」タブをクリックして「ヒューマン・タスク・アクティビティの拡張機能の定義方法」に進みます。それ以外の場合は、「OK」をクリックしてヒューマン・タスク・ダイアログを閉じます。

28.5.4 ヒューマン・タスク・アクティビティの拡張機能の定義方法

図28-11 に、「詳細」タブを示します。

図28-11 ヒューマン・タスクの作成 - 「詳細」タブ

「Human Task」アクティビティ・ダイアログの「詳細」タブでは、表28-2 に示す操作を実行できます。

表28-2 「Human Task」 - 「詳細」タブ

フィールド

参照先

スコープ名

グローバル・タスク変数名

スコープ名とグローバル・タスク変数名の指定

所有者

タスク所有者の指定

識別キー

識別キーの指定

アイデンティティ・コンテキスト

アイデンティティ・コンテキストの指定

アプリケーション・コンテキスト

アプリケーション・コンテキストの指定

タスク履歴の追加元

他のヒューマン・タスクのタスク履歴の追加

28.5.4.1 スコープ名とグローバル・タスク変数名の指定

デフォルトのスコープ名とグローバル・タスク変数名は、ヒューマン・タスク・アクティビティの作成時に自動的に入力されます。ただし、ヒューマン・タスク・アクティビティの作成時にスコープとグローバル変数に名前を指定するためのカスタム名は指定できます。

スコープ名およびグローバル・タスク変数名を指定する手順は、次のとおりです。

1. 「詳細」タブの「スコープ名」フィールドに、生成するBPELスコープの名前を入力します。

このBPELスコープにより、ワークフロー・サービスとBPEL変数の操作を使用する相互作用全体がカプセル化されます。

2. 「詳細」タブの「グローバル・タスク変数名」フィールドに、グローバル・タスク変数名を入力します。

これは、ワークフローの相互作用に使用されるBPELタスク変数の名前です。

28.5.4.2 タスク所有者の指定

タスク所有者は、所有するビジネス・プロセスに属するタスクを参照し、タスク割当て先のユーザーにかわって操作を実行できます。また、所有者は、タスクの再割当て、取消しまたはエスカレートも実行できます。

「Human Task」ダイアログの「一般」タブでタスク・イニシエータを指定しない場合は、ここで指定した所有者にデフォルト設定されます。「詳細」タブの「所有者」フィールドに、タスク所有者名を入力するか、右側にあるアイコンをクリックし、「式ビルダー」を使用してこのタスクの所有者を動的に指定します。

28.5.4.3 識別キーの指定

識別キーは、タスクのユーザー定義IDとして使用できます。たとえば、注文書の承認に関するタスクの場合は、タスクの識別キーとして注文書IDを設定できます。タスクは、識別キーを使用してOracle BPM Worklistで検索できます。この属性にデフォルト値はありません。

「詳細」タブの「識別キー」フィールドに、必要に応じて識別キー値を入力し、キーを指定します。

28.5.4.4 アイデンティティ・コンテキストの指定

複数のレルムが構成されている場合は、タスクに対してアイデンティティ・レルム名が使用されます。同じタスクを実行している複数のレルムから割当て先を指定することはできません。複数のレルムを使用している場合、このフィールドは必須です。アイデンティティ・コンテキストを指定するには、「詳細」タブの「アイデンティティ・コンテキスト」フィールドに、値を入力します

28.5.4.5 アプリケーション・コンテキストの指定

アプリケーションのストライプ名には、タスクで使用されるアプリケーション・ロールが含まれます。アプリケーション・コンテキストを指定するには、「詳細」タブの「アプリケーション・コンテキスト」フィールドに、値を入力します。

28.5.4.6 他のヒューマン・タスクのタスク履歴の追加

この機能を使用すると、あるヒューマン・タスクを別のヒューマン・タスクで継続できるようになります。単一のBPELプロセス内に複数の関連タスクを持つシナリオは多数あります。たとえば、次のようなヒューマン・タスクがあると想定します。

- コンピュータに対するマネージャの承認を取得するための調達プロセス

- 間にある複数のBPELアクティビティ

- IT部門がコンピュータを購入するための別のタスク

2番目のタスクの参加者が、マネージャが購入を承認したときに作成された承認履歴、コメントおよび添付ファイルを表示する必要があるとします。このオプションを使用して2番目のタスクを最初のタスクに連鎖すると、BPELプロセスでこれらの異なるタスクをリンクできます。

連鎖したタスクの場合は、新しいタスクのタイトルをタスク・メタデータ(.taskファイル)から設定することはできません。たとえば、既存のタスクAが新しいタスクBに連鎖し、タスクBにヒューマン・タスク・エディタで新しいタイトルが設定されている場合、このタイトルは認識されません。したがって、連鎖したタスクに異なるタイトルが必要な場合、そのタイトルは、タスク・サービスreinitiate操作をコールする前に、タスク・インスタンスに設定する必要があります。BPELプロセスがタスクを開始する場合は、ワークフロー・サービスAPIがコールされる前にタスクのタイトルを設定します。JavaプログラムがワークフローAPIをプログラムでコールしている場合は、タイトルを設定する必要があります。

タスクの履歴を他のタスクに追加する手順は、次のとおりです。

1. 「詳細」タブの「タスク履歴の追加元」チェック・ボックスを選択して、BPELプロセス内の前のワークフロー・タスクを拡張します。このチェック・ボックスを選択すると、前のタスクからタスク履歴、コメントおよび添付ファイルが追加されます。これにより、完全なエンドツーエンドの監査証跡が得られます。

ヒューマン・タスクを別のヒューマン・タスクで続行する場合は、次の情報が新規ワークフローに引き継がれます。

- タスク・ペイロードと、前のワークフローでペイロードに追加された変更内容

- タスク履歴

- 前のワークフローでタスクに追加されたコメント

- 前のワークフローでタスクに追加された添付ファイル

- 期日

「タスク履歴の追加元」リストに、既存のワークフローがすべて表示されます。

2. 特定のヒューマン・タスクを選択し、選択したヒューマン・タスクを拡張し(続け)ます。

たとえば、雇用プロセスを使用して、新規従業員を採用します。各面接担当者は、候補者を雇用するかどうか投票します。投票者の75%が雇用に賛成の場合、候補者は採用されます。このパーセントに満たない場合、候補者は採用されません。候補者が採用されると、HRデータベースにエントリが作成され、人事担当者は雇用プロセスを完了します。人事担当者は、各面接担当者と、候補者に関するコメントを確認する必要があります。このプロセスは、雇用にパラレル参加者タイプを使用することでモデリングできます。候補者が採用された場合は、データベース・アダプタを使用してHRデータベースにエントリが作成されます。その後は、単純ワークフローにパラレル参加者タイプのタスク履歴を追加して、応募申込み書、履歴書および面接担当者のコメントを引き継ぐことができます。この単純ワークフローは、人事担当者に割り当てられます。

3. 使用するペイロードを次の中から選択します。

- 古いペイロードの消去と再作成
このオプションは、この拡張されたワークフローに含まれるヒューマン・タスクのXMLファイル内のペイロード属性が異なる場合に適用できます。たとえば、履歴を含めるヒューマン・タスクのペイロード属性に、他のヒューマン・タスクのペイロードにはない属性が3個ある場合などです。

- 既存のペイロードの使用
このオプションは、この拡張されたワークフローに含まれるヒューマン・タスクのXMLファイル内のペイロード属性が同じ場合に適用できます。

28.5.5 生成されたヒューマン・タスク・アクティビティの表示方法

ヒューマン・タスク・アクティビティのモデリングを完了すると、デザイナでヒューマン・タスクが生成されます。

図28-12 に、ワークフロー相互作用のモデリング方法を示します。図28-12 は、BPELコールバックがモデリングされていない場合の相互作用も示しています。この場合、タスクが完了した後、完了したタスクを使用してBPELプロセスがコールバックされます。中間のイベントはBPELプロセス・インスタンスに伝播されません。ユーザー・カスタマイズは、最初のassignであるAssignTaskAttributesで実行し、AssignSystemTaskAttributesを変更しないことをお薦めします。

図28-12 ワークフロー相互作用のモデリング

図28-13 に示すように、Oracle BPELデザイナのヒューマン・タスク・アクティビティの横にある「拡張」アイコンをクリックして、その内容を表示します。

図28-13 ヒューマン・タスク・アクティビティの拡張

28.5.5.1 BPELコールバックの起動

中間のイベントをBPELプロセス・インスタンスに伝播する必要がある場合は、ヒューマン・タスク・エディタの「イベント」セクションにある「BPELコールバックのタスクとルーティング・カスタマイズを許可」チェック・ボックスを選択します。このオプションが選択されている場合、ワークフロー・サービスはタスクの更新ごとにBPELインスタンス内でコールバックを起動します。次に説明するコールバックがTaskService.wsdlファイルにリストされます。

- onTaskCompleted
このコールバックは、タスクの完了、期限切れ、取消しまたはエラー時に起動されます。

- onTaskAssigned
このコールバックは、次のアクションが原因でタスクが一連の新規の割当て先に割り当てられるときに起動されます。

- 結果の更新

- 現在の割当てのスキップ

- ルーティング・スリップのオーバーライド

- onTaskUpdated
このコールバックは、onTaskCompleteまたはonTaskAssignedコールバックに該当しないタスクに対する他の更新の際に起動されます。これには、情報のリクエスト、情報の発行、エスカレーション、再割当てなどによるタスクの更新が含まれます。

- onSubTaskUpdated
このコールバックは、サブタスクに対する更新の際に起動されます。

図28-14 に、コールバックを使用したワークフロー相互作用のモデリング方法を示します。このタスクが開始されると、タスクが完了するまでwhileループを使用してメッセージが受信されます。whileループには、4つのonMessageブランチ(前述したコールバック操作ごとに1つずつ)を備えたpickアクティビティが含まれています。ワークフロー相互作用は、onMessageブランチに何も変化がなくても正常に機能します。つまり、onMessageブランチでのカスタマイズは不要です。

このシナリオでは、ワークフロー・コンテキストはBPELインスタンスで取得されます。このコンテキストは、ワークフロー・サービスとのすべての相互作用に使用できます。たとえば、グループに割り当てられているタスクを再度割り当てる場合、タスク・サービスには、reassignTask操作のワークフロー・コンテキストが必要です。

ユーザー・カスタマイズは、最初のassignであるAssignTaskAttributesで実行し、AssignSystemTaskAttributesを変更しないことをお薦めします。

図28-14 ワークフロー相互作用のモデリング(コールバックを使用)

28.5.6 生成されたヒューマン・タスク・アクティビティの変更に関する必知事項

生成されたヒューマン・タスク・アクティビティを変更する必要がある場合は、次の詳細に注意してください。

- ヒューマン・タスクをBPELプロセス・フローに追加するときに、switchアクティビティで自動的に作成されたassignタスクを変更しないでください。かわりに、switchアクティビティの外側に新しいassignアクティビティを追加してください。

- ヒューマン・タスクに渡されるパラメータを変更した場合(たとえば、「タスク・パラメータの編集」ダイアログでパラメータ・タイプを変更した場合)は、BPELプロセス・フローのヒューマン・タスク・アクティビティを開いて「OK」をクリックし、ペイロード変数の参照を修正する必要があります。修正しないと、パラメータ名が変わり、編集不可になります。
ヒューマン・タスク・エディタでタスクの結果を変更した場合は、ヒューマン・タスク・アクティビティを編集し、「OK」をクリックする必要があります。switch caseは、結果に対する変更に基づいて更新されます。

- リソース・バンドルのタスクのタイトルまたはカテゴリの翻訳可能文字列になんらかの変更を加えても、すでに開始されたタスクのインスタンスには変更が表示されません。ただし、変更後に開始されたタスクのインスタンスには変更が表示されます。

- コメントをヒューマン・タスクにコピーするときは、それらのコメントにタスクIDが含まれていないことを確認してください。taskId要素は、空であることが必要です。

28.5.7 ヒューマン・タスクで生成されたパートナ・リンクの削除に関する必知事項

ヒューマン・タスクで生成されたパートナ・リンク(たとえば、「パートナ・リンク」スイムレーンのhuman_task_name.TaskService)を削除すると、ヒューマン・タスクが使用不可になります。パートナ・リンクを削除した場合は、Oracle BPELデザイナでヒューマン・タスク・アクティビティを削除して、再起動する必要があります。

28.5.8 結果ベース・モデリングの定義方法

多くの場合、ビジネス・プロセスのフローは、タスクの結果によって決定されます。ビジネス・ロジックのモデリングを容易にするため、ユーザー・タスクの生成時には、BPELのswitchアクティビティがビルトインのcaseアクティビティとともに生成されます。デフォルトでは、タスクの作成時に選択した結果ごとに1つのcaseブランチが作成されます。また、タスクの取消し、期限切れ、エラー発生の各状態に対応するotherwiseブランチもswitchに生成されます。

28.5.8.1 ペイロード更新の指定

転送されるタスクには、ペイロードが含まれます。ペイロードがビジネス・プロセス変数から設定されている場合は、ペイロードをタスクからソースにコピーして戻すために、copyPayloadFromTaskという名前のassignアクティビティが各caseおよびotherwiseブランチに作成されます。ペイロードが他のXPath式(ora:getNodes(...)など)で表現されている場合は、ペイロードをコピーするためのプロセス変数が存在しないため、このassignは作成されません。ペイロードを変更する必要がない場合は、タスクのscope後にswitch caseで生成されたassignを削除できます。

28.5.8.2 その他のタスクの結果に対応するcase文の使用

デフォルトでは、switchアクティビティには通常の結果のみに対応するcase文が含まれています。その他のタスクの結果は、otherwiseブランチで取得されます。これらの結果は、次のとおりです。

- タスクが取り消されます。

- タスクがエラーになります。

- タスクが期限切れになります。

ビジネス・ロジックをその他の結果にそれぞれ追加する必要がある場合は、case文をこれらの各条件に追加できます。case文は、次のBPELセグメントのように作成できます。その他の結果に対応する各caseアクティビティのXPath条件は、次の例の中で太字で示されています。

<switch name="taskSwitch">
<case condition="bpws:getVariableData('SequentialWorkflowVar1',
'/task:task/task:state') = 'COMPLETED' and
bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:conclusion') = 'ACCEPT'">
<bpelx:annotation>
<bpelx:pattern>Task outcome is ACCEPT
</bpelx:pattern>
</bpelx:annotation>
...
</case>
<case condition=
"bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:state') =
'WITHDRAWN'">
<bpelx:annotation>
<bpelx:pattern>Task is withdrawn
</bpelx:pattern>
</bpelx:annotation>
...
</case>
<case condition=
"bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:state') =
'EXPIRED'">
<bpelx:annotation>
<bpelx:pattern>Task is expired
</bpelx:pattern>
</bpelx:annotation>
...
</case>
<case condition=
"bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:state') =
'ERRORED'">
<bpelx:annotation>
<bpelx:pattern>Task is errored
</bpelx:pattern>
</bpelx:annotation>
...
</case>
<otherwise>
<bpelx:annotation>
<bpelx:pattern>Task is EXPIRED, WITHDRAWN or ERRORED
</bpelx:pattern>
</bpelx:annotation>
...
</otherwise>
</switch>

28.5.9 添付ファイルのエンコーディングに関する必知事項

テキスト・ファイルをヒューマン・タスクに添付できるようにするには、テキスト添付ファイルのコンテンツがエンコードされているかどうかを記述するフラグを設定する必要があります。このフラグはisContentEncodedという名前です。このフラグを設定するには、ヒューマン・タスクを含む任意のヒューマン・ワークフローのサンプルで、BPELコードをカスタマイズします。このカスタマイズを行うには、サンプル内の.bpelファイルで、次のコピー・ルールをBPEL assignアクティビティ・コードに入力します。

<copy>
<from>true()</from>
<to>$initiateTaskInput.payload/task:task/task:attachment/task:isContentEncoded
</to>
</copy>

このコピー・ルールを入力した後は、ファイルを保存してBPELプロセスの設計を続行するか、または設計が終了している場合にはプロセスをデプロイできます。

29 ヒューマン・タスクの構成

この章では、ヒューマン・タスクの異なるプロパティを構成する方法について説明します。基本的なプロパティ、タスク・ペイロード・データ構造、参加者の割当て、ルーティング・ポリシー、ローカライズ、エスカレーション、通知プリファレンス、アクセス・ポリシーとタスク・アクション、制限、およびJavaコールバックとビジネス・イベント・コールバックについて説明します。

この章の内容は次のとおりです。

- ヒューマン・タスク・エディタのセクションへのアクセス

- タイトル、説明、結果、優先度、カテゴリ、所有者およびアプリケーション・コンテキストの指定

- タスク・ペイロードのデータ構造の指定

- タスク参加者の割当て

- ルーティング・ポリシーの選択

- 多言語設定とスタイルシートの指定

- ワークリストでの「タスクの詳細」に表示するものの指定

- タスクのエスカレート、期限更新または終了

- 参加者の通知プリファレンスの指定

- タスク・コンテンツへのアクセス・ポリシーとタスク・アクションの指定

- タスク割当てに対する制限の指定

- Javaコールバックまたはビジネス・イベント・コールバックの指定

ヒューマン・ワークフロー問題のトラブルシューティングの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のヒューマン・ワークフローのトラブルシューティングに関する項を参照してください。

29.1 ヒューマン・タスク・エディタのセクションへのアクセス

この項では、ヒューマン・タスク・エディタのセクションにアクセスする方法について説明します。各セクションについて簡単に説明し、詳細の参照先を示します。

ヒューマン・タスク・エディタのセクションにアクセスする手順は、次のとおりです。

1. SOAコンポジット・エディタで「ヒューマン・タスク」アイコンをダブルクリックするか、Oracle BPEL Designerで「ヒューマン・タスク」アイコンをダブルクリックします。

ヒューマン・タスク・エディタは、図29-1 の左側に示す主要なセクションで構成されています。これらのセクションを使用すると、ヒューマン・タスクのメタデータを設計できます。

図29-1 ヒューマン・タスク・エディタ

表29-1 に、ヒューマン・タスク・エディタのこれらの主要なセクションを使用してワークフロー・タスクを作成する方法を示します。

表29-1 ヒューマン・タスク・エディタ

セクション

説明

参照先

一般

(「タイトル」、「説明」、「結果」、「カテゴリ」、「優先度」、「所有者」および「アプリケーション・コンテキスト」)

タスクの詳細(タイトル、タスクの結果、所有者、その他の属性など)を定義できます。

タイトル、説明、結果、優先度、カテゴリ、所有者およびアプリケーション・コンテキストの指定

データ

タスク・ペイロード(タスクのデータ)の構造(メッセージ要素)を定義できます。

タスク・ペイロードのデータ構造の指定

割当て

参加者をタスクに割り当て、そのタスクをワークフローを使用してルーティングするためのポリシーを作成できます。

タスク参加者の割当て

ルーティング・ポリシーの選択

プレゼンテーション

次の設定を指定できます。

- 多言語設定

- 添付用WordMLおよびカスタム・スタイル・シート

多言語設定とスタイルシートの指定

期限

タスクの有効期間、カスタム・エスカレーションJavaクラスおよび期日を指定できます。

タスクのエスカレート、期限更新または終了

通知

ユーザーにタスクが割り当てられたとき、またはタスクのステータスが変化したときの通知を作成して送信できます。

参加者の通知プリファレンスの指定

アクセス

タスク・コンテンツとタスク・アクションのアクセス・ルール、ワークフロー署名ポリシーおよび割当て制限を指定できます。

タスク・コンテンツへのアクセス・ポリシーとタスク・アクションの指定

「ワークフロー・デジタル署名ポリシーの指定方法」

タスク割当てに対する制限の指定

イベント

コールバック・クラスおよびBPELコールバックでのタスクとルーティングの割当てを指定できます。

Javaコールバックまたはビジネス・イベント・コールバックの指定

29.2 タイトル、説明、結果、優先度、カテゴリ、所有者およびアプリケーション・コンテキストの指定

この項では、タイトル、説明、結果、優先度、カテゴリ、所有者およびアプリケーション・コンテキストなどのタスクの詳細を指定する方法について説明します。

タスクの詳細を指定する手順は、次のとおりです。

1. ヒューマン・タスク・エディタにアクセスします。

2. 「一般」タブをクリックします。

図29-2 に、ヒューマン・タスク・エディタの「一般」セクションを示します。

このセクションでは、タスクのタイトル、説明、結果、カテゴリ、優先度、所有者などの詳細を指定できます。

図29-2 ヒューマン・タスク・エディタ - 「一般」セクション

表29-2 に、「一般」セクションの各サブセクションの構成方法を示します。

表29-2 ヒューマン・タスク・エディタ - 「一般」セクション

サブセクション

参照先

タイトル

「タスクのタイトルの指定方法」

説明

「タスクの説明の指定方法」

結果

「タスクの結果の指定方法」

優先度

「タスク優先度の指定方法」

カテゴリ

「タスク・カテゴリの指定方法」

所有者

「タスク所有者の指定方法」

アプリケーション・コンテキスト

「アプリケーション・コンテキストの指定方法」

29.2.1 タスクのタイトルの指定方法

タスクのタイトルを入力します(オプション)。開始したタスクにタイトルが設定されていない場合のみ、この値がタイトルにデフォルト設定されます。このタイトルによって、タスクが視覚的に識別されます。タスクのタイトルはOracle BPM Worklistに表示されます。タイトルは、Oracle BPM Worklistで検索することもできます。

タスクのタイトルを指定する手順は、次のとおりです。

1. 「一般」セクションの「タスクのタイトル」フィールドで、タスクのタイトルを指定する方法を選択します。

- プレーン・テキスト: 名前(承認された休暇申請など)を手動で入力します。

- テキストとXPath: 手動によるテキストと動的な式の組合せを入力します。タイトルの一部(注文IDに必要な承認:など)を手動で入力した後、テキストの右側の空白にカーソルを置き、このフィールドの右側にあるアイコンをクリックします。この操作によって、タイトルの残りの部分を動的に作成するための式ビルダーが表示されます。名前の動的部分を完成した後は、「OK」をクリックし、このフィールドに戻ります。完全な名前が表示されます。次に例を示します。

Approval Required for Order Id: <%/task:task/task:payload/task:orderId%>

式は、実行時にタスク・ペイロードからの正確な注文ID値を使用して解決されます。

- 変換: 「ルックアップ」ボタンをクリックし、タイトルの指定に使用する変換バンドルを見つけます。

- リソースXPath: 「ルックアップ」ボタンをクリックし、タイトルの指定に使用するリソース・バンドルを見つけます。

2. 「タスクのタイトルの指定」で説明する、「ヒューマン・タスクの作成」ダイアログ・ボックスの「一般」タブで「タスクのタイトル」フィールドにタイトルを入力すると、ここで入力したタイトルは上書きされます。

29.2.2 タスクの説明の指定方法

必要に応じて、「一般」セクションの「説明」フィールドにタスクの説明を指定できます。説明を使用すると、タスクに関する補足的な詳細を提供できます。たとえば、タスクのタイトルがコンピュータのアップグレード・リクエストの場合、このフィールドには、コンピュータのモデル、CPUの能力、RAM容量などの補足的な詳細を記載できます。この説明は、Oracle BPM Worklistには表示されません。

タスクの説明を追加する手順は次のとおりです。

1. ドロップダウン・メニューを選択し、「プレーン・テキスト」と「変換」のいずれかを選択します。

2. 説明を入力します。
プレーン・テキスト:

a. ダイアログ・ボックスに説明を入力します。

b. 「OK」をクリックします。

変換:

a. 「ルックアップ」ボタンをクリックします。

b. リソース・バンドルを見つけ、説明を入力します。

c. 「OK」をクリックします。

29.2.3 タスクの結果の指定方法

タスクの結果により、タスクに可能な結果が取得されます。Oracle BPM Worklistには、ここで指定した結果が実行時に実行可能なタスク・アクションとして表示されます。図29-3に詳細を示します。

図29-3 Oracle BPM Worklist内の結果

次のタイプのタスクの結果を指定できます。

- シード済結果の選択

- カスタム結果の入力

タスクの結果には、ここで指定した実際の結果値とは異なる実行時の表示値を割り当てることもできます。これにより、Oracle BPM Worklistでは、結果を異なる言語で表示できます。国際化の詳細は、「多言語設定の指定方法」を参照してください。

タスクの結果を指定する手順は、次のとおりです。

1. 「一般」セクションの「結果」フィールドの右側にある「検索」アイコンをクリックします。

タスクに予想される結果が「結果」ダイアログ・ボックス(図29-4 を参照)に表示されます。「APPROVE」および「REJECT」はデフォルトで選択されています。

図29-4 結果ダイアログ

2. 表29-3 に示す情報を入力します。

表29-3 結果ダイアログ

フィールド

説明

1つ以上の結果の選択

追加するタスク結果を選択するか、デフォルトの結果を選択解除します。

「追加」アイコン

クリックすると、カスタム結果を追加するダイアログ・ボックスが起動されます。

ダイアログ・ボックスの「名前」フィールドにカスタム名を入力し、「OK」をクリックします。結果が「結果」フィールドに表示されます。

注意: 次のネーミング制限を考慮してください。

- ヒューマン・タスク・エディタの「アクセス」セクションの「アクション」タブにリストされている名前と一致するカスタム名は指定しないでください(たとえば、削除を指定しないでください)。同じ名前を指定すると、実行時に問題が発生する可能性があります。

- 空白を含むカスタム名(たとえば、On Hold)を指定しないでください。このようにすると、Oracle BPM Worklistでカスタム結果にアクセスするときにエラーが発生します。空白を含む結果を指定する必要がある場合は、リソース・バンドルを使用します。詳細は、「ヒューマン・ワークフロー・サービスの概要」を参照してください。

- カスタム・タスクの結果は、大文字か小文字の英字で始まる必要があります。使用できるのは、英字とゼロ(0)から9までの数字のみです。

コメントが必要な結果

クリックすると、実行時にOracle BPM Worklistで割当て先がコメントを追加する結果を選択できます。割当て先は、実行時にタスクを保存しないでコメントを追加し、アクションを実行する必要があります。

デフォルトの結果

この結果に対するデフォルトの結果を選択します。

ここで選択したシード済結果とカスタム結果が、パラレル参加者タイプの「多数決の結果」セクションに表示され、選択できます。

3. 詳細は、「投票結果の指定」を参照してください。

29.2.4 タスク優先度の指定方法

タスクの優先度を指定します。優先度は、1から5までで、1が最高値です。タスクの優先度は、デフォルトで3に設定されています。この優先度値は、「ヒューマン・タスクの作成」ダイアログ・ボックスの「一般」タブで優先度値を選択するとオーバーライドされます。優先度に基づいてタスクをフィルタ処理し、Oracle BPM Worklistで優先度のビューを作成できます。

「一般」セクションの「優先度」リストで、タスクの優先度を選択して優先度を指定します。

「ヒューマン・タスクの作成」ダイアログ・ボックスでの優先度値の指定の詳細は、「タスク・イニシエータとタスク優先度の指定」を参照してください。

29.2.5 タスク・カテゴリの指定方法

タスク・カテゴリは、必要に応じて、「一般」セクションの「カテゴリ」フィールドに指定できます。この指定によって、システムで作成されるタスクのカテゴリが決まります。たとえば、ヘルプ・デスク環境では、顧客のリクエストをソフトウェア関連またはハードウェア関連として分類できます。カテゴリはOracle BPM Worklistに表示されます。カテゴリに基づいてタスクをフィルタ処理し、Oracle BPM Worklistでカテゴリのビューを作成できます。

タスク・カテゴリを指定する手順は、次のとおりです。

1. 「一般」セクションの「カテゴリ」フィールドでタスク・カテゴリを指定する方法を選択します。

- 名前別: 名前を手動で入力します。

- 式別: このフィールドの右側にあるアイコンをクリックし、カテゴリを動的に作成するための式ビルダーを表示します。

- 変換: コンポジットにリソース・バンドル・ファイルが含まれている場合、「ルックアップ」ボタンを使用して、リソース・バンドル・ファイルを見つけ、カテゴリを指定します。

29.2.6 タスク所有者の指定方法

タスク所有者は、所有するビジネス・プロセスに属するタスクを参照し、割当て済タスクの参加者タイプのいずれかにかわって操作を実行できます。また、所有者は、タスクの再割当て、取消しまたはエスカレートも実行できます。タスク所有者は、タスクのビジネス管理者と見なすことができます。また、タスク所有者は、「タスク所有者の指定」の説明に従って、「ヒューマン・タスクの作成」ダイアログ・ボックスの「詳細」タブで指定することもできます。ここに入力したタスク所有者は、「詳細」タブで指定したタスク所有者によって上書きされます。

タスク所有者の詳細は、「タスクのステークホルダ」を参照してください。

タスク所有者を指定する手順は、次のとおりです。

1. タスク所有者の指定方法を選択します。

- アイデンティティ・サービスのユーザー・ディレクトリまたはアプリケーション・ロールのリストを介して静的に指定

- XPath式を介して動的に指定
例: タスクに、ownerが格納されているpoという名前のペイロード・メッセージ属性がある場合は、次のようなXPath式を指定できます。

/task:task/task:payload/po:purchaseOrder/po:owner

ids:getManager('jstein', 'jazn.com')

jsteinのマネージャがタスク所有者です。

ユーザー、グループおよびアプリケーション・ロールの詳細は、「タスクの割当ておよびルーティング」を参照してください。

29.2.6.1 ユーザー・ディレクトリまたはアプリケーション・ロールのリストを介したタスク所有者の静的な指定

タスク所有者は、Oracle SOA Suiteで使用するように構成されたユーザー・ディレクトリ(Oracle Internet Directory、Java AuthoriZatioN (JAZN)/XML、LDAPなど)またはアプリケーション・ロールのリストを参照することで選択できます。

ユーザー・ディレクトリまたはアプリケーション・ロールのリストを介してタスク所有者を静的に指定する手順は、次のとおりです。

1. 「一般」セクションの「所有者」フィールドの右側にある最初のリストで、タスク所有者のタイプとして「ユーザー」、「グループ」または「アプリケーション・ロール」を選択します。図29-5に詳細を示します。

注意:

デフォルトで、ヒューマン・タスク内のグループ名は大/小文字を区別します。したがって、Groupを選択した場合に大文字の名前(たとえば、LOANAGENTGROUP)を入力すると、Oracle BPM Worklistの「管理タスク」タブにはタスクが表示されません。グループ名で大/小文字を不可知にする(大/小文字を区別しない)には、システムMBeanブラウザでcaseSensitiveGroupsプロパティをfalseに設定する必要があります。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

図29-5 ユーザー・ディレクトリまたはアプリケーション・ロールの参照によるタスク所有者の指定

2. 「一般」セクションの「所有者」フィールドの右側にある2番目のリストで、「静的」を選択します。

3. 選択した所有者のタイプに基づいて、表29-4 の手順を参照してください。

表29-4 所有者のタイプ

選択内容

手順

「ユーザー」または「グループ」

4

アプリケーション・ロール

5

4. 「ユーザー」または「グループ」を選択した場合は、図29-6 に示す「アイデンティティ・ルックアップ」ダイアログ・ボックスが表示されます。

図29-6 「アイデンティティ・ルックアップ」ダイアログ

ユーザーまたはグループを選択するには、最初にアプリケーション・サーバー接続を作成する必要があります。そのためには「追加」アイコンをクリックします。以下の制限に注意してください。

- アイデンティティ・サービス・レルムのリストを取得するOracle WebLogic管理サーバーに対して、アプリケーション・サーバー接続を作成しないでください。これは、この管理サーバーには、実行するアイデンティティ・サービスがないためです。したがって、「アイデンティティ・ルックアップ」ダイアログ・ボックスで検索パターンを使用して検索を実行した場合は、レルム情報もユーザーも表示されません。かわりに、管理対象のOracle WebLogic Serverに対してアプリケーション・サーバー接続を作成してください。

- 完全なドメイン名(myhost.us.example.comなど)を使用して構成されているアプリケーション・サーバー接続を選択する必要があります。ホスト名(myhostなど)のみで構成されている接続を選択すると、使用可能なレルムが「レルム」リストに表示されない可能性があります。既存の接続にドメイン名が含まれていない場合は、次の手順を実行します。

- 「リソース・パレット」で、アプリケーション・サーバー接続を右クリックします。

- 「プロパティ」を選択します。

- 「構成」タブで、適切なドメインをホスト名に追加します。

- 「アイデンティティ・ルックアップ」ダイアログ・ボックスに戻り、接続を再度選択します。

a. アプリケーション・サーバー接続を選択または作成し、選択用のレルムを表示します。レルムには、ユーザーおよびロール(グループ)のポリシー・ストアへのアクセスが用意されています。

b. 検索文字列(jcooper、j*、*など)を入力して所有者を検索します。「ユーザー名」フィールドの右側にある「ルックアップ」アイコンをクリックすると、検索基準と一致するすべてのユーザーがフェッチされます。図29-7に詳細を示します。「選択」をクリックすると、1つ以上のユーザーまたはグループをハイライトして選択できます。

図29-7 レルムが選択された状態の「アイデンティティ・ルックアップ」

c. ユーザーをハイライトして「階層」をクリックし、そのユーザーの階層を表示します。同様に、「報告先」をクリックすると、選択したユーザーまたはグループの報告先が表示されます。図29-8に詳細を示します。

図29-8 「アイデンティティ・ルックアップ」ダイアログのユーザー階層

d. ユーザーまたはグループをハイライトして「詳細」をクリックし、そのユーザーまたはグループの詳細を表示します。図29-9に詳細を示します。

図29-9 ユーザーまたはグループの詳細

e. 「OK」をクリックして「アイデンティティ・ルックアップ」ダイアログ・ボックスに戻ります。

f. 「選択」をクリックして、ユーザーを「選択したユーザー」セクションに追加します。

g. 「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
選択内容が「所有者」フィールドに表示されます。

5. 「アプリケーション・ロール」を選択した場合は、「アプリケーション・ロールの選択」ダイアログ・ボックスが表示されます。

a. 「アプリケーション・サーバー」リストで、アプリケーション・ロールが設定されているアプリケーション・サーバーのタイプを選択するか、「追加」アイコンをクリックして接続を作成するための「アプリケーション・サーバー接続の作成」ウィザードを起動します。

b. 「アプリケーション」リストで、アプリケーション・ロールが設定されているアプリケーションを選択します(カスタム・アプリケーションまたはSOAインフラストラクチャ・アプリケーション(soa-infra)など)。

c. 「選択可能」セクションで、適切なアプリケーション・ロールを選択し、「>」ボタンをクリックします。すべてを選択するには、「>>」ボタンをクリックします。図29-10に詳細を示します。

図29-10 アプリケーション・ロール

d. 「OK」をクリックします。

29.2.6.2 XPath式によるタスク所有者の動的な指定

タスク所有者を「式ビルダー」ダイアログ・ボックスで動的に選択できます。

タスク所有者を動的に指定する手順は、次のとおりです。

1. 「一般」セクションの「所有者」フィールドの右側にある最初のリストで、タスク所有者のタイプとして「ユーザー」、「グループ」または「アプリケーション・ロール」を選択します。図29-11に詳細を示します。

図29-11 タスク所有者の動的な指定

2. 「一般」セクションの「所有者」フィールドの右側にある2番目のリストで、「XPath」を選択します。

3. アイコンをクリックして、式ビルダーを起動します。

図29-12 に示す「式ビルダー」ダイアログ・ボックスが表示されます。

図29-12 式ビルダー

4. 使用可能な変数のスキーマおよび関数を参照してタスク所有者を作成します。

5. 「OK」をクリックしてヒューマン・タスク・エディタに戻ります。

選択内容が「所有者」フィールドに表示されます。

詳細は、次を参照してください。

- 「式ビルダー」ダイアログ・ボックスとXPathビルディング・アシスタントの使用手順については、「ヘルプ」をクリックしてください。

- ワークフロー・サービスのDynamic Assignment Function、アイデンティティ・サービス関数およびXPathビルディング・アシスタントの使用手順の詳細は、「XPath拡張関数」を参照してください

29.2.7 アプリケーション・コンテキストの指定方法

タスクで使用するアプリケーション・ロールが含まれているアプリケーションの名前を指定できます。これによって、アプリケーション・ロールが操作するコンテキストが指定されます。タスクを明示的に作成しなくても結果的に所有した場合は、このコンテキストを設定できます。

注意:

Oracle Process WorkspaceおよびOracle BPM Worklistアプリケーションでアプリケーション・ロールにタスクを再割り当てできるようにするために、タスク定義にアプリケーション・コンテキストを設定する必要があります。

「一般」セクションの「アプリケーション・コンテキスト」フィールドに、名前を入力してアプリケーション・コンテキストを指定します。

29.3 タスク・ペイロードのデータ構造の指定

このセクションでは、XSDファイルに定義されているタスク・ペイロード(タスクのデータ)の構造(メッセージ要素)を指定できます。XSDファイルの要素を表すパラメータを作成します。これにより、ペイロード・データがワークフロー・タスクで使用できるようになります。次に例を示します。

- ストアフロント・アプリケーションから注文するための注文ID要素に対してパラメータを作成します。

- ヘルプ・デスク・リクエストを作成するための場所、タイプ、問題の説明、重大度、ステータスおよび解決の各要素に対してパラメータを作成します。

図29-13 に、ヒューマン・タスク・エディタの「データ」セクションを示します。タスクのペイロード・データは、1つ以上の要素またはタイプで構成されます。選択内容に基づいてタスク・ペイロードのXMLスキーマ定義が作成されます。

図29-13 ヒューマン・タスク・エディタ - 「パラメータ」セクション

29.3.1 タスク・ペイロード・データ構造の指定方法

タスク・ペイロード・データ構造を指定する手順は、次のとおりです。

1. 「データ」タブをクリックします。

2. 「追加」アイコンをクリックして、ペイロード・タイプを選択します。

- 文字列

- 整数

- ブール

- その他

図29-14 に示すように、「タスク・パラメータの追加」ダイアログ・ボックスが表示されます。

図29-14 「タスク・パラメータの追加」ダイアログ

3. 表29-5 に記載されている詳細を入力します。

表29-5 「タスク・パラメータの追加」ダイアログのフィールドと値

フィールド

説明

パラメータ・タイプ

「タイプ」または「要素」を選択し、「検索」アイコンをクリックすると、タスク・パラメータ選択用の「タイプ・チューザ」ダイアログ・ボックスが表示されます。

パラメータ名

デフォルト名をそのまま使用するか、カスタムの名前を入力します。このフィールドが表示されるのは、パラメータ・タイプとして「タイプ」を選択した場合のみです。

ワークリストにより編集可能

このチェック・ボックスを選択すると、タスク・ペイロードのこの部分をOracle BPM Worklistで編集できます。たとえば、融資承認タスクの場合、APR属性は、タスクをレビューするユーザーによる更新が必要な場合がありますが、SSNフィールドは編集できません。

参加者が表示および更新できるタスクの部分を決定するアクセス・ルールも指定できます。詳細は、「タスク・コンテンツへのアクセス・ポリシーとタスク・アクションの指定」を参照してください。

コレクションの使用

タスクでコレクションが使用される場合、このパラメータを定義してコレクションを使用します。「追加」ボタンをクリックし、コレクション名およびコレクション・タイプのXpath式を指定します。式ビルダーを使用して、スキーマからコレクション・タイプを検索します。

注意:

Oracle BPM Worklistで定義できるのは、単純なXMLタイプ(文字列、整数など)または複雑なタイプ(注文書など)のペイロード・パラメータに対するペイロード・マップ済属性(以前はフレックス・フィールド・マッピングと呼ばれていました)のみです。キーワードを使用してタスクを検索する必要がある場合、またはタスク・コンテンツに基づいてビューまたは委任ルールを定義する必要がある場合は、単純なXMLタイプに基づいたペイロード・パラメータを使用する必要があります。これらの単純なタイプは、Oracle BPM Worklistでフレックス列にマップできます。

4. 図29-15 に示すように、タイプを選択します。

図29-15 パラメータ・タイプ

5. 「OK」をクリックしてヒューマン・タスク・エディタに戻ります。

選択内容が「データ」セクションに表示されます。

6. 選択内容を編集するには、対象項目を選択して「データ」セクションの右上にある「編集」アイコンをクリックします。

29.4 タスク参加者の割当て

図29-16 に、ヒューマン・タスク・エディタの「割当て」セクションを示します。このセクションでは、ビジネス要件を満たす参加者タイプを選択できます。参加者タイプを構成するときは、タスクを操作するユーザー、グループおよびアプリケーション・ロールのリストを作成します。

図29-16 ヒューマン・タスク・エディタ - 「割当て」セクション

単純または複雑なワークフロー・ルーティング・ポリシーを作成するためには、参加者タイプを簡単に組み合せて調整できます。以前に構成したヒューマン・タスクの機能を拡張して、より複雑なワークフローをモデリングすることもできます。

参加者タイプはステージの下のブロックにグループ化されます(たとえば、図29-16 ではStage1という名前です)。ステージは、参加者タイプの各ブロックに対して承認プロセスを編成するための1方法です。1つ以上のステージを順番に、またはパラレルで指定できます。各ステージ内で、1つ以上の参加者タイプ・ブロックを順番に、またはパラレルで指定できます。参加者タイプ・ブロックの順序は、[↑]キーと[↓]キーを使用して再配置できます。

次に例を示します。

- すべての参加者タイプ・ブロックを単一のステージに作成できます(たとえば、注文のすべての内容が全体として承認または却下される注文書リクエスト)。

- より複雑な承認タスクを作成して、1つ以上のステージを含めることができます。たとえば、最初のステージに参加者タイプ・ブロックのグループを配置し、2番目のステージに他のブロックを配置できます。第1ステージに配置した参加者のリストでは明細入力の承認が処理され、第2ステージに配置した参加者のリストではヘッダー入力の承認が処理されます。

参加者タイプごとに、構成タスクに使用するエディタが関連付けられています。割当て先の追加順序は、実行順序を示します。

別のステージ名を指定したり、追加ステージの作成が必要なビジネス要件を指定するには、次の手順を実行します。追加ステージの作成は高度な要件で、自社の環境には必要がない場合があります。

参加者タイプの詳細は、「タスクの割当ておよびルーティング」を参照してください。

29.4.1 ステージ名を指定してパラレルおよび順次ブロックを追加する方法

デフォルトでは、ステージに「Stage1」という名前が指定されます。ただし、この名前は変更できます。

ステージ名を指定し、パラレルおよび順次ブロックを追加する手順は、次のとおりです。

1. 名前をダブルクリックします。「編集」ダイアログ・ボックスが表示されます。

2. 「編集」ダイアログ・ボックスで、次の詳細を入力し、「OK」をクリックします。

- ステージ: ステージの名前。

- 非繰返し: コレクション内の各アイテムのステージを並行して処理しません。

- 繰返し: コレクション内の各アイテムのステージを並行して処理します。ドロップダウン・リストから1つのコレクションを選択し、繰り返されるステージに使用するコレクション・タイプを指定します。

3. 図29-17 に示すように、ステージとその参加者タイプ・ブロックを選択します。

4. タイプ「ステージ」の参加者を、現在のステージの右側にドラッグ・アンド・ドロップします。

コンポーネント・パレットのワークフロー・エディタからタイプ「ステージ」の参加者を選択できます。

5. 「追加」アイコンをクリックします。

図29-17 第2ステージの追加

6. リストからオプションを選択します(たとえば、「パラレル・ステージ」)。

図29-18 に示すように、第2ステージが第1ステージに対してパラレルに追加されます。

図29-18 パラレル・ステージ

7. 「コンポーネント」ウィンドウからステージの参加者を「ステージ1」の下にドラッグ・アンド・ドロップします。

新しいステージを現在のステージの下に移動すると、現在のステージの周囲に緑色の点が4つ表示されます。現在のステージの下にある緑色の点を選択します。

第2ステージ(たとえば、図29-19ではStage1 という名前です)を選択するのではなく、参加者タイプ・ブロック(たとえば、図29-19ではEdit Participant という名前です)のみを選択した場合は、「追加」アイコンの下にあるすべてのオプションが無効になります。

8. 「順次ステージ」を選択します。

順次ステージが、選択したブロックの下に追加されます。

図29-19 順次ステージ

これらのブロック内に参加者タイプを作成します。

29.4.2 タスク参加者の割当て方法

タスク参加者を割り当てる手順は、次のとおりです。

1. 「割当て」セクションで、次のいずれかのタスクを実行します。

- 「コンポーネント」ウィンドウから参加者を「ステージ」上にドラッグ・アンド・ドロップします。タスク参加者を初めて作成すると、このボックスには「<参加者の編集>」のラベルが付きます。

- 参加者のボックスをダブルクリックします。

「参加者タイプの編集」ダイアログ・ボックスが表示されます。このダイアログ・ボックスでは、特定の参加者タイプを選択できます。

2. 「タイプ」リストから、図29-20 に示す参加者タイプを選択します。

図29-20 「タイプ」リスト

3. 選択内容に応じて、表29-6 に示す項を参照してください。

表29-6 参加者タイプ

参加者タイプ

この参加者タイプの説明参照先

この参加者タイプの構成手順参照先

- 単一

- パラレル

- シリアル

- FYI

「タスクの割当ておよびルーティング」

「単一参加者タイプの構成方法」

「パラレル参加者タイプの構成方法」

「シリアル参加者タイプの構成方法」

「FYI参加者タイプの構成方法」

29.4.3 単一参加者タイプの構成方法

図29-21 に、単一参加者タイプの「参加者タイプの編集」ダイアログ・ボックスを示します。図29-22 に、展開された「詳細」セクションを示します。

図29-21 参加者タイプの編集 - 「単一」タイプ

図29-22 「参加者タイプの編集」 — 「詳細」タブ

タスクに対して動的に割り当てるために、単一参加者をグループ、アプリケーション・ロールまたは参加者リストから選択できます。

単一参加者タイプを構成する手順は、次のとおりです。

1. 「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル(Approval Manager、Primary Reviewersなど)は、タスク定義のすべての参加者の中で一意にする必要があります。

表29-7 に、単一参加者タイプの「参加者タイプの編集」ダイアログ・ボックスの各サブセクションの構成方法を示します。

表29-7 参加者タイプの編集 - 「単一」タイプ

サブセクション

参照先

参加者リスト

「単一タスク参加者リストの作成」

割当て済期間の制限の設定(「詳細」セクション)

「タスクの操作に対する時間制限の指定」

この参加者による他の参加者の招待を許可(「詳細」セクション)

「タスクへの他の参加者の招待」

スキップ・ルールの指定(「詳細」セクション)

「タスク参加者のバイパス」

割当て制御(「詳細」セクションの下)

この参加者が特定の割当てコンテキストと関連付けられている場合、その名前をここに追加します。「追加」ボタンを使用して新しいエントリを追加します。ドロップダウン・リストを使用して、割当てコンテキストの名前を選択し、この割当てコンテキストの値を指定します。

参加者に手動によるタスクの要求を許可 (「一般」セクションの下)

値ベースの名前と式で構成される参加者リストの作成

単一ユーザー/グループ/アプリケーション・ロールへのタスクの自動割当て(「一般」セクションの下)

値ベースの名前と式で構成される参加者リストの作成

29.4.3.1 単一タスク参加者リストの作成

参加者リストに割り当てられているユーザーは、タスクを操作できます。単一タスク参加者リストでは、タスクの操作に必要なユーザーは1人のみです。単一のユーザーか、このパターンのユーザー、グループまたはアプリケーション・ロールのリストを指定できます。リストが指定されている場合、リスト上のすべてのユーザーがタスクに割り当てられています。このうちの1人が手動でタスクを申告して操作する必要があるか、または割当てパターンによっていずれかのユーザーがリストから自動的に選択されるようにするかを指定できます。1人のユーザーがタスクを操作する場合、このタスクは他の割当て先のタスク・リストから取り消されます。

単一ユーザー参加者やパラレル、シリアルおよびFYIユーザー参加者に対して、次のような様々なタイプのリストを作成できます。

- 値ベースの名前と式のリスト
これらのリストでは、ユーザー、グループまたはアプリケーション・ロールをタスク割当て先として静的または動的に選択できます。

- 値ベースの管理チェーンのリスト
管理チェーンは通常、管理チェーン階層内の複数のユーザーからシリアル承認を得るために使用されます。したがって、このリストは多くの場合、シリアル参加者タイプに有効です。通常は、階層内のすべてのユーザーがタスクを操作する場合に使用します。管理チェーンは単一参加者タイプでも使用できます。ただし、この場合は、階層内のすべてのユーザーにタスクが同時に割り当てられます。1人のユーザーがタスクを操作すると、そのタスクは、他のユーザーから取り消されます。

たとえば、注文書がマネージャに割り当てられているとします。マネージャが承認した注文は、上位のマネージャに割り当てられます。そのマネージャが承認すると、さらに上位のマネージャに割り当てられ、3人のマネージャが注文を承認するまで上位へと順番にルーティングされます。条件付き中途完了を指定した場合は、マネージャのいずれかがリクエストを却下するか、リクエストの期限が切れると、注文は却下されます。それ以外の場合、タスク・フローは引き続きルーティングされます。

- ルールベースの名前と式のリストおよび管理チェーンのリスト
ビジネス・ルールを使用すると、複雑な式でタスク参加者のリストを作成できます。たとえば、$5000未満の注文書リクエストは承認のためにマネージャに送信するというビジネス・ルールを作成します。一方、$5000以上の注文書リクエストは、承認のためにマネージャのマネージャに送信します。ビジネス・ルールの2つの主要な機能は、ファクトとアクション・タイプです。詳細は、「ビジネス・ルールを使用した詳細タスク・ルーティングの指定方法」を参照してください。

参加者タイプを選択すると、図29-23 に示すように、ダイアログ・ボックスを使用してタスク参加者の割当て先(ユーザー、グループまたはアプリケーション・ロール)のリストを作成するためのオプションを選択できます。前述の3つの選択肢(「名前および式」、「管理チェーン」および「ルールベース」)を使用できます。

図29-23 参加者のリストの作成

オプションを選択した後は、図29-24 に示すように、タスク参加者割当て先(ユーザー、グループまたはアプリケーション・ロール)およびデータ型を動的に割り当てます。

図29-24 タスク割当て先の割当て

この項では、これらの参加者リストの作成方法について説明します。

29.4.3.1.1 値ベースの名前と式で構成される参加者リストの作成

ユーザー、グループまたはアプリケーション・ロールをタスク参加者として静的または動的に割り当てる方法を選択します。参加者リストにユーザーが含まれている場合、グループまたはアプリケーション・ロールを選択すると、動的割当てが失敗します。

概念的な情報は、次を参照してください。

- ユーザー、グループまたはアプリケーション・ロールについては、「タスクの割当ておよびルーティング」を参照してください。

- タスク参加者の静的および動的割当てについては、「静的、動的およびルールベースのタスク割当て」を参照してください。

値ベースの名前と式で構成される参加者リストを作成する手順は、次のとおりです。

1. 「参加者のリストの作成で使用」リストから「名前および式」を選択します。

2. 次のいずれかを行います。

- 「参加者が手動でタスクを申告」を選択します。このオプションを選択すると、タスクはリスト内のすべての参加者に割り当てられます。タスク割当て先の個別のユーザーは、タスクを手動で申告して作業できます。

- 「単一への自動割当て」リストを選択して、「ユーザー」、「グループ」または「アプリケーション・ロール」を選択し、割当てパターンを選択します。
各割当てパターンの詳細を確認し、割当てパターンを選択して構成するには、「割当てパターン」をクリックします。「割当てパターン」ダイアログ・ボックスが表示されます。図29-25 に、「割当てパターン」ダイアログ・ボックスの例を示します。

図29-25 「割当てパターン」の選択および構成

「アプリケーション・サーバー」フィールドでアプリケーション・サーバー接続を指定すると、「割当てパターン」リストに割当てパターンがロードされます。「割当てパターン」リストからいずれかのパターンを選択すると、その選択の説明がテキスト・ボックスに表示されます。

その割当てパターンですべてのタイプのタスクが考慮されるようにするには、「すべてのタイプのタスクを使用してパターン条件を評価」を選択します。それ以外の場合、そのパターンでは、選択ユーザーを決定するときに、このタスク・タイプのみが考慮されます。たとえば、休暇申請タスクを最もビジーでないユーザーに割り当てる場合に、「すべてのタイプのタスクを使用してパターン条件を評価」を選択すると、最もビジーでないユーザーを決定するときに、割り当てられたすべてのタスクが考慮されます。「すべてのタイプのタスクを使用してパターン条件を評価」を選択しない場合は、最もビジーでないユーザーを決定するときに、割り当てられている休暇申請タスクのみが考慮されます。

特定のパターンを使用すると、パターンの評価方法を制御する入力パラメータを指定できる場合があります。たとえば、図29-25 に示すように、「最も生産性の高い箇所」パターンを使用すると、生産性が計算される「時間間隔」(日数)を指定できます。入力値は静的な値とするか、またはXPath式を使用して動的に設定できます。パターンによってはパラメータを使用できない場合があります。

3. 「属性の指定で使用」リストから、「値ベース」を選択します。

ダイアログ・ボックスがリフレッシュされ、図29-26 に示すように、フィールドが表示されます。

図29-26 値ベースの名前と式

4. 「追加」アイコンをクリックし、ユーザー、グループまたはアプリケーション・ロールをタスク参加者として選択します。

「参加者名」表の「識別タイプ」列に、選択したユーザー、グループまたはアプリケーション・ロールが表示されます。

5. 「識別タイプ」列での選択を変更するには、その列をクリックしてドロップダウン・リストを表示します。

6. 「データ型」列で、現在選択されている値をクリックし、値を割り当てるドロップダウン・リストを表示します。

- 名前別: 識別タイプがユーザーまたはグループの場合は、右側の「参照」アイコン(...)をクリックし、アイデンティティ・サービスを介して構成されたユーザーまたはグループを選択するためのダイアログ・ボックスを表示します。アイデンティティ・サービスを使用すると、ユーザー・プロパティ、ロールおよびグループ・メンバーシップのルックアップが可能になります。ユーザー情報は、Oracle Internet DirectoryなどのLDAPサーバーから取得します。IDの検索にはワイルドカード(*)を使用できます。
アプリケーション・ロールを選択する場合は、「参照」アイコンをクリックし、アプリケーション・ロールを選択するための「アプリケーション・ロールの選択」ダイアログ・ボックスを表示します。アプリケーション・ロールを検索するには、最初にアプリケーション・サーバーへの接続を作成する必要があります。検索する際は、ロール名を見つけるためにアプリケーション名を指定する必要があります。タスク定義で参照できるのは、単一のアプリケーション名のみです。割当て先またはタスク所有者は、異なるアプリケーションのアプリケーション・ロールを使用できません。

- 式別: ユーザー、グループまたはアプリケーション・ロールの識別タイプについて、「参照」アイコンをクリックし、「式ビルダー」ダイアログ・ボックスでタスク割当て先を動的に選択します。bpws:getVariableData(...)式またはids:getManager() XPath関数を使用します。

指定した値が「値」列に表示されます。

7. 値を手動で入力するには、「値」列のフィールドをクリックし、値を指定します。

29.4.3.1.2 値ベースの管理チェーンで構成される参加者リストの作成

管理チェーン・パラメータをタスク参加者として静的または動的に割り当てる方法を選択します。

概念的な情報については次を参照してください。

- ユーザー、グループまたはアプリケーション・ロールについては、「タスクの割当ておよびルーティング」を参照してください。

- タスク参加者の静的および動的割当てについては、「静的、動的およびルールベースのタスク割当て」を参照してください。

- 管理チェーンについては、「単一タスク参加者リストの作成」を参照してください。

値ベースの管理チェーンに基づいて参加者リストを作成する手順は、次のとおりです。

1. 「参加者のリストの作成で使用」リストから、「管理チェーン」を選択します。

2. 次のいずれかを行います。

- 「参加者が手動でタスクを申告」を選択します。このオプションを選択すると、タスクはリスト内のすべての参加者に割り当てられます。タスク割当て先の個別のユーザーは、タスクを手動で申告して作業できます。

- 「単一への自動割当て」リストを選択して「ユーザー」を選択し、割当てパターンを選択します。
各割当てパターンの詳細を確認し、割当てパターンを選択して構成するには、「割当てパターン」をクリックします。「割当てパターン」ダイアログ・ボックスが表示されます。図29-25 に、「割当てパターン」ダイアログ・ボックスの例を示します。

「アプリケーション・サーバー」フィールドでアプリケーション・サーバー接続を指定すると、「割当てパターン」リストに割当てパターンがロードされます。「割当てパターン」リストからいずれかのパターンを選択すると、その選択の説明がテキスト・ボックスに表示されます。

その割当てパターンですべてのタイプのタスクが考慮されるようにするには、「すべてのタイプのタスクを使用してパターン条件を評価」を選択します。それ以外の場合、そのパターンでは、選択ユーザーを決定するときに、このタスク・タイプのみが考慮されます。たとえば、休暇申請タスクを最もビジーでないユーザーに割り当てる場合に、「すべてのタイプのタスクを使用してパターン条件を評価」を選択すると、最もビジーでないユーザーを決定するときに、割り当てられたすべてのタスクが考慮されます。「すべてのタイプのタスクを使用してパターン条件を評価」を選択しない場合は、最もビジーでないユーザーを決定するときに、割り当てられている休暇申請タスクのみが考慮されます。

特定のパターンを使用すると、パターンの評価方法を制御する入力パラメータを指定できる場合があります。たとえば、図29-25 に示すように、「最も生産性の高い箇所」パターンを使用すると、生産性が計算される「時間間隔」(日数)を指定できます。入力値は静的な値とするか、またはXPath式を使用して動的に設定できます。パターンによってはパラメータを使用できない場合があります。

3. 「属性の指定で使用」リストから、「値ベース」を選択します。

ダイアログ・ボックスがリフレッシュされ、図29-27 に示すように、フィールドが表示されます。

図29-27 値ベースの管理チェーン

4. 「開始参加者」表のリストにユーザー、グループまたはアプリケーション・ロールを割り当てる手順の詳細は、「単一タスク参加者リストの作成」のステップ4からステップ7を参照してください。

5. 「最上位の参加者」リストで、タスク参加者のレベル数を割り当てる方法を選択します。

- 役職別: 管理チェーンの最終(最高)承認者の役職を選択します。

- XPath: 「式ビルダー」ダイアログ・ボックスを介して最上位の参加者を動的に入力する場合に選択します。

6. 「レベル数」リストで、最上位参加者を割り当てる方法を選択します。

- 番号別: このタスクに含める管理チェーンのレベル数の値を入力します。たとえば、2を入力して、タスクが最初にユーザーjcooperに割り当てられている場合は、ユーザーjstein (jcooperのマネージャ)とユーザーwfaulk (jsteinのマネージャ)の両方がリストに(最初の割当て先であるjcooperとは別に)含まれます。

- XPath: 「式ビルダー」ダイアログ・ボックスを介して値を動的に入力する場合に選択します。

29.4.3.1.3 ルールセットで構成される参加者リストの作成

ルールセットは、ルールおよびデシジョン表の実行単位を提供します。また、ルールの共有単位でもあり、ルールはルールセットに属します。複数のルールセットを順番に実行できます。この処理は、ルール・フローと呼ばれます。順序はルールセット・スタックによって決まります。この順序は、スタック上でルールセットをプッシュおよびポップするルール・アクションによって操作できます。ルールセットでは、ルールの優先度を適用することで、ルールセット内でのルールの起動順序を指定します。また、ルールセットは、ルールセットが常にアクティブであること、またはルールセットが日時の範囲や開始日時または終了日時に基づいて制限されることを識別する、有効日指定も提供します。

ルールセットの作成方法は、そのルールセットへのアクセス方法に基づいています。これについては、次の項で説明しています。

注意:

ルール・ディクショナリが作成された後は、ファクトを更新できません。

ルールセットに基づいて参加者リストを指定する手順は、次のとおりです。

ビジネス・ルールによって、参加者リストを定義できます。ビジネス・ルールの使用については、2つのオプションがあります。

- ルールによって、特定のリスト・ビルダー(「名前および式」、「管理チェーン」など)のパラメータが定義されます。この場合、タスク・ルーティング・パターンは、特定のリスト・ビルダーを使用するようにモデリングされます。このリスト・ビルダーには、ルールで作成されたパラメータがリストされます。ルールは、Oracle JDeveloperでモデリングされたタイプと同じタイプのリスト・ビルダーを返します。

1. 「参加者のリストの作成で使用」リストから、「名前および式」または「管理チェーン」を選択します。

2. 「属性の指定で使用」リストから、「ルールベース」を選択します。

3. 「ルールセットのリスト」フィールドに、名前を入力します。
図29-28に詳細を示します。

図29-28 ルールセット

4. 次のいずれかの操作を行います。

- 「参加者が手動でタスクを申告」を選択します。このオプションを選択すると、タスクはリスト内のすべての参加者に割り当てられます。タスク割当て先の個別のユーザーは、タスクを手動で申告して作業できます。

- 「単一への自動割当て」リストを選択して、「ユーザー」、「グループ」または「アプリケーション・ロール」を選択し、割当てパターンを選択します。
各割当てパターンの詳細を確認し、割当てパターンを選択して構成するには、「割当てパターン」をクリックします。「割当てパターン」ダイアログ・ボックスが表示されます。図29-25 に、「割当てパターン」ダイアログ・ボックスの例を示します。

「アプリケーション・サーバー」フィールドでアプリケーション・サーバー接続を指定すると、「割当てパターン」リストに割当てパターンがロードされます。「割当てパターン」リストからいずれかのパターンを選択すると、その選択の説明がテキスト・ボックスに表示されます。

その割当てパターンですべてのタイプのタスクが考慮されるようにするには、「すべてのタイプのタスクを使用してパターン条件を評価」を選択します。それ以外の場合、そのパターンでは、選択ユーザーを決定するときに、このタスク・タイプのみが考慮されます。たとえば、休暇申請タスクを最もビジーでないユーザーに割り当てる場合に、「すべてのタイプのタスクを使用してパターン条件を評価」を選択すると、最もビジーでないユーザーを決定するときに、割り当てられたすべてのタスクが考慮されます。「すべてのタイプのタスクを使用してパターン条件を評価」を選択しない場合は、最もビジーでないユーザーを決定するときに、割り当てられている休暇申請タスクのみが考慮されます。

特定のパターンを使用すると、パターンの評価方法を制御する入力パラメータを指定できる場合があります。たとえば、図29-25 に示すように、「最も生産性の高い箇所」パターンを使用すると、生産性が計算される「時間間隔」(日数)を指定できます。入力値は静的な値とするか、またはXPath式を使用して動的に設定できます。パターンによってはパラメータを使用できない場合があります。

5. 「OK」をクリックします。

- ルールによって、リスト・ビルダーおよびリスト・ビルダー・パラメータが定義されます。この場合は、リスト自体がルールを使用して作成されます。ルールによって、リスト・ビルダーとパラメータが定義されます。

1. 「参加者のリストの作成で使用」リストから、「ルールベース」を選択します。

2. 「ルールセットのリスト」フィールドに、名前を入力します。
図29-29に詳細を示します。

図29-29 ルールセット

3. 次のいずれかの操作を行います。

- 「参加者が手動でタスクを申告」を選択します。このオプションを選択すると、タスクはリスト内のすべての参加者に割り当てられます。タスク割当て先の個別のユーザーは、タスクを手動で申告して作業できます。

- 「単一への自動割当て」リストを選択して、「ユーザー」、「グループ」または「アプリケーション・ロール」を選択し、割当てパターンを選択します。
各割当てパターンの詳細を確認し、割当てパターンを選択して構成するには、「割当てパターン」をクリックします。「割当てパターン」ダイアログ・ボックスが表示されます。図29-25 に、「割当てパターン」ダイアログ・ボックスの例を示します。

「アプリケーション・サーバー」フィールドでアプリケーション・サーバー接続を指定すると、「割当てパターン」リストに割当てパターンがロードされます。「割当てパターン」リストからいずれかのパターンを選択すると、その選択の説明がテキスト・ボックスに表示されます。

その割当てパターンですべてのタイプのタスクが考慮されるようにするには、「すべてのタイプのタスクを使用してパターン条件を評価」を選択します。それ以外の場合、そのパターンでは、選択ユーザーを決定するときに、このタスク・タイプのみが考慮されます。たとえば、休暇申請タスクを最もビジーでないユーザーに割り当てる場合に、「すべてのタイプのタスクを使用してパターン条件を評価」を選択すると、最もビジーでないユーザーを決定するときに、割り当てられたすべてのタスクが考慮されます。「すべてのタイプのタスクを使用してパターン条件を評価」を選択しない場合は、最もビジーでないユーザーを決定するときに、割り当てられている休暇申請タスクのみが考慮されます。

4. 「OK」をクリックします。

ルール・ディクショナリが未作成で、参加者リストを簡単に指定するために複数のルール関数とファクトが事前にシードされている場合は、いずれのオプションでもルール・ディクショナリが作成されます。ルール・ディクショナリには、参加者リストを作成するための次のルール関数がシードされています。

- CreateResourceList

- CreateManagementChainList

Taskファクトはタスク・サービスによってアサートされ、ルール条件のベースとなります。

29.4.3.1.3.1 ルール辞書の表示

ルール・ディクショナリが作成されると、Oracle Business Rulesデザイナが表示されます。

1. ルール条件をモデリングします。アクション部分で、前述の関数のいずれか1つをコールして、リストの作成を完了します。図29-30に詳細を示します。

図29-30 ビジネス・ルール

ルール関数のパラメータは、Oracle JDeveloperモデリングでのパラメータに類似しています。Oracle JDeveloperでの構成に加え、Oracle Business Rulesデザイナでは、次の属性について複数の追加オプションを使用できます。

- responseType: レスポンス・タイプが「REQUIRED」の場合は、割当て先がタスクを操作する必要があります。それ以外の場合、割当てはFYI割当てに変換されます。

- ruleName: ルール名で割当ての理由を作成できます。

- lists: このオブジェクトは、作成されるリストの所有者です。このオプションをクリックすると、事前にアサートされたファクトのListsオブジェクトが表示されます。このオブジェクトはパラメータとして使用されます。

図29-31 に、管理チェーンベースの参加者を指定するルールの例を示します。

図29-31 ビジネス・ルール

複数のルールが起動されると、最も高い優先度のルールに基づいて作成されたリスト・ビルダーが選択されます。

29.4.3.2 タスクの操作に対する時間制限の指定

ユーザー、グループまたはアプリケーション・ロールには、タスクの操作に関して与えられる時間を指定できます。ユーザー、グループまたはロールが指定の時間内に操作しないと、ヒューマン・タスク・エディタの「期限」セクション(ルーティング・スリップ・レベル)で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されているときに、この参加者が指定の期間内に操作しない場合、そのタスクは必要に応じてマネージャまたは他のユーザーにエスカレートされます。

タスク操作に時間制限を指定する手順は、次のとおりです。

1. 図29-32 に示すように、単一タイプの「参加者タイプの編集」ダイアログ・ボックスの「詳細」セクションを開きます。

図29-32 「参加者タイプの編集」の「詳細」セクション - 「単一」タイプ

2. 「割当て済期間の制限の設定」を選択します。

3. 時間を指定します。

ヒューマン・タスク・エディタの「期限」セクションで、グローバルなエスカレーションおよび期限更新ポリシーを設定する方法の詳細は、「タスクのエスカレート、期限更新または終了」を参照してください。

29.4.3.3 タスクへの他の参加者の招待

このワークフロー内の次の割当て先にタスクをルーティングする前に、他の参加者をタスク割当て先として招待できます。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。

これは非定型ルーティングとも呼ばれます。このオプションが選択されている場合は、実行時にOracle BPM Worklistの「アクション」リストに「非定型ルート」が追加されます。

注意:

FYI参加者の上下に非定型割当て先を追加しないでください。

他の参加者をタスクに招待する手順は、次のとおりです。

1. 図29-32 に示すように、単一タイプの「参加者タイプの編集」ダイアログ・ボックスの「詳細」セクションを開きます。

2. 「この参加者による他の参加者の招待を許可」を選択します。

29.4.3.4 タスク参加者のバイパス

特定の条件が満たされている場合は、タスク参加者(ユーザー、グループまたはアプリケーション・ロール)をバイパスできます。たとえば、ユーザーが発行した出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。

タスクをバイパスする手順は、次のとおりです。

1. 図29-32 に示すように、単一タイプの「参加者タイプの編集」ダイアログ・ボックスの「詳細」セクションを開きます。

2. 「スキップ・ルールの指定」を選択します。

これにより、「式ビルダー」ダイアログ・ボックスにアクセスして条件を作成するためのアイコンが表示されます。

タスク参加者をバイパスするための式は、ブール値に評価される必要があります。たとえば、/task:task/task:payload/order:orderAmount < 1000は、参加者をスキップするための有効なXPath式です。

動的なルール条件の作成の詳細は、「ビジネス・ルールを使用した詳細タスク・ルーティングの指定方法」を参照してください。

29.4.4 パラレル参加者タイプの構成方法

パラレル参加者タイプは、パラレルで作業する複数のユーザーが同時にタスクを操作する(たとえば、雇用に関するフローで複数のユーザーが応募者の採否を票決する)必要がある場合に使用します。結果が有効になるために必要な得票率(多数決や満場一致など)を指定します。パラレル参加者によるパラレル・ルーティングの場合、親タスクの最終結果の決定に、投票および割合のルールが優先されます。

たとえば、ビジネス・プロセスでは、雇用プロセス中に面接担当者全員からフィードバックを収集し、それをとりまとめて各面接担当者に採用または不採用リクエストを割り当てます。最後に、面接担当者の大多数が不採用ではなく採用に投票すると、候補者が雇用されます。

図29-33 および図29-34 は、「パラレル」ダイアログ・ボックスの上部および下部のセクションを示しています。

図29-33 参加者タイプの編集 - 「パラレル」タイプ(ダイアログの上部セクション)

図29-34 参加者タイプの編集 - 「パラレル」タイプ(ダイアログの下部セクション)

参加者をパラレル参加者タイプに割り当てる手順は、次のとおりです。

1. 「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル(Approval Manager、Primary Reviewersなど)は、タスク定義のすべての参加者の中で一意にする必要があります。

表29-8 に、パラレル参加者タイプの「参加者タイプの編集」ダイアログ・ボックスの各サブセクションの構成方法を示します。

表29-8 参加者タイプの編集 - 「パラレル」タイプ

サブセクション

参照先

投票結果

「投票結果の指定」

参加者リスト

「パラレル・タスク参加者リストの作成」

割当て済期間の制限の設定(「詳細」セクション)

「タスクの操作に対する時間制限の指定」

この参加者による他の参加者の招待を許可(「詳細」セクション)

「タスクへの他の参加者の招待」

スキップ・ルールの指定(「詳細」セクション)

「タスク参加者のバイパス」

割当てコンテキストの追加(「詳細」セクションの下)

この参加者が特定の割当てコンテキストと関連付けられている場合、その名前をここに追加します。「追加」ボタンを使用して新しいエントリを追加します。ドロップダウン・リストを使用して、割当てコンテキストの名前を選択し、この割当てコンテキストの値を指定します。

29.4.4.1 投票結果の指定

「デフォルトの結果」リストで選択したデフォルトの結果をオーバーライドする投票結果を指定できます。この結果は、必要なパーセンテージに達した場合に有効になります。結果はこの表にリストされている順序で評価されます。

グループ投票詳細を指定する手順は、次のとおりです。

1. パラレル・タイプの「参加者タイプの編集」ダイアログ・ボックスの「投票結果」セクションに移動します。

2. 「投票結果」列のリストから、タスクの結果(「Any」、「ACCEPT」、「REJECT」、「タスクの結果の指定方法」で指定した他の結果など)を選択します。

「Any」結果を使用すると、実行時に結果を動的に決定できます。たとえば、「Any」を選択して、結果パーセントを60に設定した場合は、実行時に60%に到達した結果が最終投票結果になります。割当て先の60%が結果の却下に投票すると、その結果は却下されます。

3. 「結果タイプ」列のリストから、最終タスクの結果の決定方法を選択します。

- 式別: XPath式を使用して詳細を動的に指定します。

- パーセンテージ別: このタスクの結果が有効であると決定するパーセント値を指定します。

4. ステップ3での選択内容に基づいて、「値」列のリストに値を指定します。

- 「式別」を選択した場合は、このフィールドの右側にある「参照」アイコンをクリックし、式を作成するための「式ビルダー」ダイアログ・ボックスを表示します。

- 「パーセンテージ別」を選択した場合は、このタスクの結果が有効になるために必要なパーセント値を入力します。たとえば、多数決(51)や満場一致(100)などです。たとえば、予想される2つの結果(「ACCEPT」および「REJECT」)と、5つのサブタスクがあるとします。2つのサブタスクが承認され、3つが却下された場合に、承認に必要なパーセントが50に設定されていると、タスクの結果は却下になります。図29-35に詳細を示します。
この機能は非決定性です。たとえば、サブタスクが2つある場合に30%を選択することは無意味です。

図29-35 「投票結果」セクション

5. 「追加」アイコンをクリックして、追加の結果を指定します。

6. 「デフォルトの結果」リストで、同意パーセントの値に達しない場合にこのタスクで有効にするデフォルトの結果を選択するか、XPath式を入力します。この状況が発生するのは、得票数が同数の場合、またはタスクの有効期限が切れる前に応答しない参加者がいる場合です。「タスクの結果の指定方法」で「結果」ダイアログ・ボックスに入力したシード済結果とカスタム結果は、このリストに表示されます。

29.4.4.2 パラレル・タスク参加者リストの作成

参加者のリストに割り当てられているユーザーは、タスクを操作できます。様々なタイプのリストを作成できます。

- 値ベースの名前と式のリスト

- 値ベースの管理チェーンのリスト

- ルールベースの名前と式のリスト

- ルールベースの管理チェーンのリスト

- ルールベースのリンク

これらの参加者リストの作成方法の詳細は、「単一タスク参加者リストの作成」を参照してください。

29.4.4.3 タスクの操作に対する時間制限の指定

ユーザー、グループまたはアプリケーション・ロールには、タスクの操作に関して与えられる時間を指定できます。ユーザー、グループまたはロールが指定の時間内に操作しないと、ヒューマン・タスク・エディタの「期限」セクション(ルーティング・スリップ・レベル)で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されているときに、この参加者が指定の期間内に操作しない場合、そのタスクは必要に応じてマネージャまたは他のユーザーにエスカレートされます。

タスク操作に時間制限を指定する手順は、次のとおりです。

1. パラレル・タイプの「参加者タイプの編集」ダイアログ・ボックスの「詳細」セクション(図29-34を参照)で、「詳細」 タブをクリックしてセクションを開きます。

2. 「割当て済期間の制限の設定」を選択します。

3. 時間を指定します。

ヒューマン・タスク・エディタの「期限」セクションで、グローバルなエスカレーションおよび期限更新ポリシーを設定する方法の詳細は、「タスクのエスカレート、期限更新または終了」を参照してください。

29.4.4.4 タスクへの他の参加者の招待

このワークフロー内の次の割当て先にタスクをルーティングする前に、他の参加者をタスク割当て先として招待できます。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。

他の参加者をタスクに招待する手順は、次のとおりです。

1. パラレル・タイプの「参加者タイプの編集」ダイアログ・ボックスの「詳細」セクションで、「詳細」アイコンをクリックしてセクションを開きます(開いていない場合)。

2. 「この参加者による他の参加者の招待を許可」を選択します。

29.4.4.5 タスク参加者のバイパス

特定の条件が満たされている場合は、タスク参加者(ユーザー、グループまたはアプリケーション・ロール)をバイパスできます。たとえば、ユーザーが発行した出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。

タスク参加者をバイパスする手順は、次のとおりです。

1. パラレル・タイプの「参加者タイプの編集」ダイアログ・ボックスで、「スキップ・ルールの指定」チェック・ボックスを選択します。

これにより、「式ビルダー」ダイアログ・ボックスにアクセスして条件を作成するためのアイコンが表示されます。式はブール値に評価される必要があります。

参加者をスキップするための有効なXPath式の詳細は、「タスク参加者のバイパス」を参照してください。

29.4.5 シリアル参加者タイプの構成方法

この参加者タイプを使用すると、ワークフロー用に参加者の順序リストを作成できます。たとえば、文書をJohn、MaryおよびScottに順番にレビューさせる場合は、この参加者タイプを使用します。シリアル参加者タイプの場合、参加者はユーザーまたはグループのリストになります。

図29-36 に、「シリアル」ダイアログ・ボックスを示します。図29-37 に、展開された「詳細」セクションを示します。

図29-36 参加者タイプの編集 - 「シリアル」タイプ

図29-37 「参加者タイプの編集」 — 「シリアル」タイプ(「詳細」タブ)

シリアル参加者タイプを構成する手順は、次のとおりです。

1. 「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル(Approval Manager、Primary Reviewersなど)は、タスク定義のすべての参加者の中で一意にする必要があります。

表29-9 に、シリアル参加者タイプの「参加者タイプの編集」ダイアログ・ボックスの各サブセクションの構成方法を示します。

表29-9 参加者タイプの編集 - 「シリアル」タイプ

サブセクション

参照先

参加者リスト

「シリアル・タスク参加者リストの作成」

割当て済期間の制限の設定(「詳細」セクション)

「タスクの操作に対する時間制限の指定」

シリアル参加者のレベルでタスク有効期間を指定する場合、その期間が切れたときにそのシリーズ内の次の参加者にタスクが移動しません。むしろ、そのタスク全体が期限切れになります。

この参加者による他の参加者の招待を許可(「詳細」セクション)

「タスクへの他の参加者の招待」

スキップ・ルールの指定(「詳細」セクション)

「タスク参加者のバイパス」

割当てコンテキスト(「詳細」セクションの下)

この参加者が特定の割当てコンテキストと関連付けられている場合、その名前をここに追加します。「追加」ボタンを使用して新しいエントリを追加します。ドロップダウン・リストを使用して、割当てコンテキストの名前を選択し、この割当てコンテキストの値を指定します。

29.4.5.1 シリアル・タスク参加者リストの作成

参加者のリストに割り当てられているユーザーは、タスクを操作できます。様々なタイプのリストを作成できます。

- 値ベースの名前と式のリスト

- 値ベースの管理チェーンのリスト

- ルールベースの名前と式のリスト

- ルールベースの管理チェーンのリスト

- ルールベースのリスト

これらの参加者リストを作成する方法は、「単一タスク参加者リストの作成」を参照してください。

29.4.5.2 タスクの操作に対する時間制限の指定

ユーザー、グループまたはアプリケーション・ロールには、タスクの操作に関して与えられる時間を指定できます。ユーザー、グループまたはロールが指定の時間内に操作しないと、ヒューマン・タスク・エディタの「期限」セクション(ルーティング・スリップ・レベル)で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されているときに、この参加者が指定の期間内に操作しない場合、そのタスクは必要に応じてマネージャまたは他のユーザーにエスカレートされます。

タスク操作に時間制限を指定する手順は、次のとおりです。

1. シリアル・タイプの「参加者タイプの編集」ダイアログ・ボックスの「詳細」タブ(図29-36を参照)で、「詳細」 アイコンをクリックしてセクションを開きます。

2. 「割当て済期間の制限の設定」をクリックします。

3. 時間を指定します。

注意:

シリアル参加者のレベルでタスク有効期間を指定する場合、指定した期限に達したときにそのシリーズ内の次の参加者にタスクが移動しません。むしろ、そのタスク全体が期限切れになります。

ヒューマン・タスク・エディタの「期限」セクションで、グローバルなエスカレーションおよび期限更新ポリシーを設定する方法の詳細は、「タスクのエスカレート、期限更新または終了」を参照してください。

29.4.5.3 タスクへの他の参加者の招待

このワークフロー内の次の割当て先にタスクをルーティングする前に、他の参加者をタスク割当て先として招待できます。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。

他の参加者をタスクに招待する手順は、次のとおりです。

1. シリアル・タイプの「参加者タイプの編集」ダイアログ・ボックスの「詳細」セクションで、「詳細」アイコンをクリックしてセクションを開きます(まだ開いていない場合)。

2. 「この参加者による他の参加者の招待を許可」を選択します。

注意:

シリアル参加者タイプでは、次のようにして他の参加者を招待できます。

- 不定参加者をいつでも招待できることをグローバルに指定します。この場合、順次ワークフロー内であっても、承認者は順次ワークフローのあらゆるレベルで他の参加者を招待できます。

- ワークフローの特定の地点のみで他の参加者を臨時的に招待できることを指定します。この場合、他の不定参加者は、1つのシリーズが完了したときにのみ招待されます。

29.4.5.4 タスク参加者のバイパス

特定の条件が満たされている場合は、タスク参加者(ユーザー、グループまたはアプリケーション・ロール)をバイパスできます。たとえば、ユーザーが発行した出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。

シリアル・タイプの「参加者タイプの編集」ダイアログ・ボックスの「詳細」セクションで、「スキップ・ルールの指定」チェック・ボックスを選択して、タスク参加者をバイパスします。これにより、「式ビルダー」ダイアログ・ボックスにアクセスして条件を作成するためのアイコンが表示されます。式はブール値に評価される必要があります。

参加者をスキップするための有効なXPath式の詳細は、「タスク参加者のバイパス」を参照してください。

29.4.6 FYI参加者タイプの構成方法

この参加者タイプは、ユーザーにタスクを送信するが、ビジネス・プロセスでユーザーのレスポンスを待機しない場合に使用します。プロセスは単に継続されます。FYIはタスクの結果を直接左右できませんが、コメントを提供したり添付ファイルを追加できる場合があります。

たとえば、雑誌の購読契約の更新期日がきているとします。ユーザーが期日までに現在の購読契約を取り消さない場合は、購読契約の期限が更新されます。リクエストが期限切れになるかユーザーが操作するまで、このユーザーに週に1回ずつリマインダが送信されます。

図29-38 に、「FYI」タイプの「参加者タイプの編集」ダイアログ・ボックスを示します。このダイアログ・ボックスの下部には、「参加者除外リスト」が含まれています(図29-38 には表示されていません)。

図29-38 参加者タイプの編集 - 「FYI」タイプ

FYI参加者タイプを構成するには、「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル(Approval Manager、Primary Reviewersなど)は、タスク定義のすべての参加者の中で一意にする必要があります。

29.4.6.1 FYIタスク参加者リストの作成

参加者のリストに割り当てられているユーザーは、タスクを操作できます。様々なタイプのリストを作成できます。

- 値ベースの名前と式のリスト

- 値ベースの管理チェーンのリスト

- ルールベースの名前と式のリスト

- ルールベースの管理チェーンのリスト

- ルールベースのリスト

これらの参加者リストを作成する方法は、「単一タスク参加者リストの作成」を参照してください。

29.5 ルーティング・ポリシーの選択

参加者タイプを構成してヒューマン・タスク・エディタに戻った後に、図29-39 に示す「タスクは開始参加者から最終参加者へ移行します」アイコンをクリックします。

図29-39 ヒューマン・タスク・エディタ - 「割当て」セクション

これによって、図29-40 に示す「割当ての構成」ダイアログ・ボックスが表示され、ワークフローを介してタスクをルーティングする方法を指定できます。

図29-40 割当ての構成

表29-10 に、用意されているルーティング・ポリシー・メソッドを示します。

表29-10 ルーティング・ポリシー・メソッド

ルーティング・ポリシーの選択

このポリシーを使用する環境

セクション

- 全参加者による他の参加者の招待を許可

参加者は、タスクを承認する際に、ユーザーまたはグループを次の割当て先(臨時)として選択できます。

「全参加者による他の参加者の招待または新しい参加者の編集の許可」

- 参加者が次を選択するとタスクを完了: <結果>

タスクの参加者が、タスクを承認または却下できます。したがって、他の参加者にタスクが送信されずにワークフローが終了します。たとえば、マネージャが却下した注文書は、レビューのためにそのマネージャのマネージャに送信されません。

「他の参加者へのタスクのルーティングの停止」

- パラレル・サブタスクで早期完了を有効化

注意: このオプションは、複数のステージがあり、参加者がパラレルで作業する環境を意図しています。

参加者はサブタスクをパラレルで実行し、あるグループでのサブタスクの却下または承認が、他のグループでのサブタスクの却下または承認の原因になることはありません。

パラレル・サブタスクで早期完了を有効化

- 早期完了するサブタスクの親タスクを完了

注意: このオプションは、複数のステージがあり、参加者がパラレルで作業する環境を意図しています。

参加者はサブタスクをパラレルで実行し、あるグループでのサブタスクの却下または承認が、他のグループでのサブタスクの却下または承認の原因となります。

早期完了するサブタスクの親タスクを完了

拡張ルールの使用

タスクのルーティング先の参加者は、モデリングしたビジネス・ルール・ロジックによって判断されます。たとえば、融資申請タスクは、融資エージェント、そのマネージャおよびシニア・マネージャを経由するように設計されているとします。この場合、融資エージェントは承認したが、そのマネージャが却下すると、その融資申請タスクは融資エージェントに戻されます。

「ビジネス・ルールを使用した詳細タスク・ルーティングの指定方法」

外部ルーティングを使用

タスクの参加者は動的に決定されます。たとえば、ある企業のルールでは、タスク参加者は、実行時に決定しバックエンド・データベースから取得する必要があります。

「外部ルーティングの使用方法」

「割当て」タブ

参加者に、失敗したタスクがリカバリの目的で割り当てられます。

「エラー割当て先とレビューアの構成方法」

29.5.1 指定した順序でタスクを全参加者にルーティングする方法

選択された参加者全員がタスクをレビューするように選択できます。これは、表示された順序で各参加者にタスクがルーティングされるデフォルト・ルーティングです。このタイプのルーティングは、ステート・マシン・ベースのルーティングとは異なります。

指定した順序でタスクを全参加者にルーティングする手順は、次のとおりです。

1. 「割当て」セクションで、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。

2. 図29-41 に示すように、リストから「指定した順序で全参加者へタスクをルート」を選択します。

図29-41 全参加者へのタスクのルーティング

ルーティング・ポリシーの定義方法は、次の各タスクを参照してください。

- 全参加者による他の参加者の招待の許可

- 参加者の選択によるタスクの完了

- パラレル・サブタスクでの早期完了の有効化

- 早期完了するサブタスクの親サブタスクの完了

29.5.1.1 全参加者による他の参加者の招待または新しい参加者の編集の許可

このチェック・ボックスは、以前の10.1.3 Oracle BPEL Process Managerリリースの非定型ワークフロー・パターンに相当します。これは、参加者が1人以上存在する場合に適用されます。この場合は、各ユーザーがタスクの承認時に次の割当て先としてユーザーまたはグループを選択します。

全参加者に対して他の参加者の招待を許可する手順は、次のとおりです。

1. 「指定した順序で全参加者へタスクをルート」を選択します。

2. 「非定型ルーティング」の下で、「全参加者による他の参加者の招待を許可」チェック・ボックスを選択し、このタスクの割当て先がこのワークフローの次の割当て先にルーティングする前に、他の参加者をワークフローに招待できるようにします。

3. 「参加者による新規参加者の編集を許可」チェック・ボックスを選択し、このタスクの割当て先が、ルーティング・スリップに追加された他の非定型参加者を編集できるようにします。

注意:

FYI参加者の上下に非定型割当て先を追加しないでください。

29.5.1.2 イニシエータによる参加者の追加の許可

「非定型ルーティング」の下で、「すべての起案者による参加者の追加を許可」チェック・ボックスを選択し、このタスクの起案者がこのワークフローの次の割当て先にルーティングする前に、他の参加者をワークフローに招待できるようにします。

29.5.1.3 他の参加者へのタスクのルーティングの停止

ワークフローの他の参加者に関係なくタスクを早期完了させる条件を指定できます。

たとえば、経費レポートがマネージャに送信されてから取締役に送信されるとします。最初の参加者(マネージャ)がレポートを却下した場合は、次の参加者(取締役)に送信せずにワークフローを終了できます。

条件付き中途完了を設定する手順は、次のとおりです。

1. 「早期完了」の下の「参加者が次を選択するとタスクを完了: <結果>」チェック・ボックスを選択します。

「中途完了の詳細」ダイアログ・ボックスが表示されます。タスクの中途完了を指定するには、次の2つの方法があります。

- 結果

- XPath式のルーティング条件

結果を指定した場合は、選択したタスクの結果が発生すると、そのタスクが完了します。結果とルーティング条件の両方を指定した場合は、ワークフロー・サービスにより2つの条件の論理OR演算子が実行されます。

2. 図29-42 に示すように、適切な結果を選択して「>」ボタンをクリックします。すべてを選択するには、「>>」ボタンをクリックします。

図29-42 中途完了の詳細

3. 「ルーティング条件」フィールドの右側にあるアイコンをクリックして「式ビルダー」ダイアログ・ボックスを表示すると、このダイアログで、このタスクを早期完了させる条件を動的に作成できます。たとえば、ユーザーが発行した出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。

早期完了のXPath式は、少なくとも一人のユーザーのタスク操作が完了するまで評価されません。

4. 早期完了を有効化するには、「パラレル・サブタスクで早期完了を有効化」をクリックします。詳細は、「パラレル・サブタスクでの早期完了の有効化」を参照してください。

5. 親タスクの早期完了を有効化するには、「早期完了するサブタスクの親タスクを完了」をクリックします。詳細は、「早期完了するサブタスクの親サブタスクの完了」を参照してください。

6. 「OK」をクリックしてヒューマン・タスク・エディタに戻ります。

「参加者が次を選択するとタスクを完了: <結果>」チェック・ボックスの右側にあるアイコンをクリックすると、この情報を編集できます。

29.5.1.4 パラレル・サブタスクでの早期完了の有効化

このオプションは、次の環境で使用できます。

- 複数のステージがあり、参加者のグループがパラレルでサブタスクを実行する環境。

- 1グループの参加者がサブタスクを承認または却下する環境。この場合、同じグループ内の他の参加者によるタスクの操作は停止されます。ただし、他のパラレル・グループによるサブタスクの操作は停止されません。このグループでは、タスクの操作が続行されます。

たとえば、それぞれが別のステージにある2つのパラレル・サブグループがあるとします。一方のグループは、注文の明細を操作します。他方のグループは、同じ注文のヘッダーを操作します。第1グループの参加者ApproveLines.Participant2が明細を却下すると、第1グループの他のすべてのタスク参加者は、タスクの操作を停止します。一方、第2パラレル・グループは注文ヘッダーの操作を続行します。このシナリオでは、タスク全体は早期完了しません。図29-43に詳細を示します。

図29-43 パラレル・サブタスクの早期完了

29.5.1.5 早期完了するサブタスクの親サブタスクの完了

このオプションは、次の環境で使用できます。

- 複数のステージがあり、参加者のグループがパラレルでサブタスクを実行する環境。

- 1グループの参加者がサブタスクを承認または却下する環境。この場合、同じグループ内の他の参加者によるタスクの操作は停止されます。これにより、他のパラレル・グループによるサブタスクの操作も停止されます。

たとえば、図29-43 に示すように、それぞれが別のステージにある2つのパラレル・サブグループがあるとします。一方のグループは、注文の明細を操作します。他方のグループは、同じ注文のヘッダーを操作します。第1グループの参加者ApproveLines.Participant2が明細を却下すると、第1グループの他のすべてのタスク参加者は、タスクの操作を停止します。さらに、第2パラレル・グループも注文ヘッダーの操作を停止します。このシナリオでは、タスク全体が早期完了します。

29.5.2 ビジネス・ルールを使用した詳細タスク・ルーティングの指定方法

複雑なワークフロー・ルーティング・シナリオを作成するには、拡張ルーティング・ルールを使用します。参加者タイプ(単一、パラレル、シリアル、FYI)は、中途完了、割当て先のスキップなどの基本条件を使用して、一連のユーザーから別のユーザーに直線的なフローを作成する際に使用されます。ただし、多くの場合、ワークフローの複数のユーザー間で、より複雑な前後へのルーティングを実行することが必要になります。1つの選択肢は、これらのタスクの調整として、BPELプロセスを使用することです。もう1つの選択肢は、ビジネス・ルールを使用して宣言的にルーティングを指定することです。この項では、ヒューマン・タスク・エディタとビジネス・ルールを使用して、これらの複雑な相互作用をモデリングする方法について説明します。

29.5.2.1 ビジネス・ルールを使用した詳細タスク・ルーティングの概要

ステート・マシン・ルーティング・ルールは、Oracle Business Rulesを使用して定義できます。このアクションによって、評価されるOracle Business Rulesを作成できます。

- その前に、ルーティング・スリップ・タスク参加者がタスクの結果を設定します。

- その後に、タスクが次のルーティング・スリップ参加者に割り当てられます。

このアクションにより、「指定した順序でタスクを全参加者にルーティングする方法」に説明されている標準的なタスク・ルーティング・スリップのメソッドをオーバーライドし、タスクに対して複雑なルーティング動作を作成できます。

Oracle Business Rulesを使用して、ビジネス・オブジェクト(ファクトと呼ばれる)に依存する一連のルール(ルールセットと呼ばれる)を定義し、実行するアクションを判断します。

29.5.2.2 ファクト

ファクトとは、特定のビジネス・データを備えたオブジェクトです。ルーティング・スリップの割当て先がタスクの結果を設定するたびに、タスクを次の割当て先に自動的にルーティングするかわりに、タスク・サービスが次のステップを実行します。

- ファクトをデシジョン・サービスにアサートします。

- 拡張ルーティング・ルールセットを実行します。

ルールでは、アサートされたファクトの値をテストし、TaskActionファクト・タイプに値を設定することで、ルーティングの動作を指定できます。

表29-11 は、タスク・サービスによりアサートされたファクト・タイプを示しています。

表29-11 タスク・サービスによりアサートされたファクト・タイプ

ファクト・タイプ

説明

Task

このファクトには、ワークフロー・タスク・インスタンスの現在の状態が含まれます。すべてのタスク属性がタスクに対してテストされます。タスク・ファクトには現在のタスク・ペイロードも含まれます。このファクトを使用すると、ペイロード値およびタスク属性値との照合テストを構築できます。

PreviousOutcome

このファクトには、前回のタスクの結果と、結果を設定した割当て先が記述されます。このファクトには、次の属性が含まれます。

- actualParticipant(実際の参加者): タスクの結果を設定した参加者の名前(jsteinなど)。

- logicalParticipant(論理上の参加者): タスクの結果を設定する責任があるルーティング・スリップ参加者の論理名またはラベル(assignee1など)。

- outcome(結果): 設定された結果(approve、rejectなど)。

- level(レベル): 前の参加者が管理チェーンの一部の場合、この属性にはそのレベルが記録されます(1は、チェーンの第1レベルを示します)。他の参加者タイプの場合、値は-1です。

- totalNumberOfApprovals(承認の総数): 現在のタスクの結果を設定したユーザーの総数。

TaskAction

このファクトは、書込みルールのテストを意図したものではありません。かわりに、このファクトはルールセットによって更新され、タスクのルーティング方法を示すためにタスク・サービスに返されます。ルールでTaskActionファクトを直接更新することはできません。かわりに、「アクション・タイプ」に記載されているRL関数の1つをコールします。これらの関数によって、TaskActionファクトの更新が適切な値で処理されます。

ワークフロー・ルーティング・ルールのみで使用できるファクト・タイプと、ワークフロー参加者ルールのみで使用できるファクト・タイプがあります。表29-12 に、それぞれのタイプを使用できるルールを示します。

表29-12 ファクト・タイプの使用

ファクト・タイプ

ルーティング・ルールでの使用

参加者ルールでの使用

Task

はい

はい

PreviousOutcome

はい

いいえ

TaskAction

はい

いいえ

Lists

いいえ

はい

RoutingSlipObjectFactory

いいえ

はい

ResourceListType

いいえ

はい

ManagementChainListType

いいえ

はい

ResourceType

いいえ

はい

ParameterType

いいえ

はい

AutoActionType

いいえ

はい

ResponseType

いいえ

はい

29.5.2.3 アクション・タイプ

タスクのルーティング方法をタスク・サービスに指示するために、ルールでは多数のタスク・アクションの1つを指定できます。この指定は、ルール・セッションにアサートされたTaskActionファクトを更新することによって実行されます。ただし、ルールでTaskActionファクトを直接更新することはできません。かわりに、アクションRL関数の1つをコールし、TaskActionファクトをパラメータとして渡す必要があります。これらの関数によって、ファクトへの実際の更新が処理されます。たとえば、先に進むアクションを指定するには、call GO_FORWARD(TaskAction)をルールのアクション部分に追加する必要があります。

ステート・マシン・ルーティング・ルールが評価されるたびに、ルールは表29-13 に記載されているアクションの1つを実行します。

表29-13 ビジネス・ルールのアクション

アクション

説明

パラメータ

GO_FORWARD

ルーティング・スリップの次の参加者に進みます(デフォルト動作)。

なし

PUSHBACK

ルーティング・スリップの前の参加者(直前にタスクの結果を設定した前の参加者)に戻ります。

注意: プッシュバックは、グループ投票ではなく単一承認者で機能するように設計されています。グループ投票(またはパラレル)シナリオを含むステージから別ステージへのプッシュバックは、許可されません。同様に、単一の割当て先からグループ投票(またはパラレル)シナリオにプッシュバックすることもできません。

なし

GOTO

ルーティング・スリップでの特定の参加者に進みます。

participant'

タスクをルーティングする参加者のラベルを識別する文字列です(Approver1など)。

COMPLETE

ルーティングを終了し、タスクを完了します。タスクが完了としてマークされ、ルーティングがさらに要求されることはありません。

なし

ESCALATE

タスク・エスカレーション・ポリシーに従って(通常は現在の割当て先のマネージャに)タスクをエスカレートし、再割当てします。

なし

29.5.2.4 サンプル・ルールセット

この項では、簡単な例でカスタム・ルーティングの動作を実装するルールの使用方法を説明します。費用請求の承認を管理するためのヒューマン・ワークフロー・タスクが作成されます。タスクの結果には、承認と却下があります。タスク定義には、ExpenseRequestペイロードの要素が含まれます。ExpenseRequestのフィールドの1つは、費用請求の総額です。タスクのルーティング・スリップは、単一参加者3人(assignee1、assignee2、assignee3)で構成されます。

デフォルトでは、タスクは各割当て先にルーティングされ、各割当て先ではタスクの承認または却下が選択されます。

このデフォルト動作のかわりに、次のように必要なルーティング動作を指定します。

- 費用請求の総額が$100未満の場合は、参加者のいずれか1人の承認が必要です。それ以外の場合は、3人全員が承認する必要があります。

- 参加者のいずれかが費用請求を却下した場合は、再評価のために前の参加者に費用請求を戻す必要があります。最初の参加者によって却下されると、費用請求は却下され完了としてマークされます。

次のルールを使用して、この動作を実装します。拡張ルーティング・ルールに対してルール・ディクショナリが生成されている場合、その拡張ルーティング・ルールはデフォルトのGO_FORWARD動作を実装するテンプレート・ルールを使用して作成されます。Oracle Business Rulesデザイナで「ルールのコピー」を右クリックして選択すると、このルールを編集し、テンプレート・ルールをコピーできます。

金額が$100より大きく、前の割当て先がタスクを承認した場合は、各割当て先に順番にタスクをルーティングするルールを指定する必要はありません。これは、ルールセットのルールがトリガーされない場合の戻り先のデフォルト動作となります。

- 早期承認ルール(図29-44 ):

図29-44 早期承認ルール

- 却下されたルールのプッシュバック(図29-45 ):

図29-45 却下されたルールのプッシュバック

- Assignee1が却下したルールの完了(図29-46 ):

図29-46 Assignee1が却下したルールの完了

反復設計の詳細は、Oracle SOA Suiteサンプルで使用可能なworkflow-106-IterativeDesignのサンプルを参照してください。

29.5.2.5 リンク・ディクショナリのサポート

ヒューマン・ワークフローで、ビジネス・ルール・アーティファクトが2つのルール・ディクショナリに格納されるようになりました。これは、アプリケーションをカスタマイズする必要があるシナリオで役立ちます。たとえば、アプリケーションのバージョン1を作成して、顧客に発送するとします。顧客は、Oracle SOAコンポーザを使用してアプリケーションのルールセットをカスタマイズできます。このカスタマイズされたルールセットが、ベース・ルール・ディクショナリとは別のルール・ディクショナリに格納されるようになりました。カスタマイズされたルールセットが格納されるルール・ディクショナリは、ベース・ディクショナリのルールとリンクしています。後でアプリケーションのバージョン2を発送するときに、製品に導入された追加の変更がベース・ルール・ディクショナリに含まれている場合があります。顧客が以前に行ったルールセットのカスタマイズによる変更も保持されているため、ベース・ディクショナリの新規の変更で使用できます。ルールを使用するタスクを含む既存のアプリケーションが開かれたときに、そのルールが1つのディクショナリを使用する古い形式の場合、ルールは自動的にアップグレードされ、次の2つのルール・ディクショナリに分割されます。

- ベース・ディクショナリ

- カスタム・ディクショナリ

カスタマイズの詳細は、「SOAコンポジット・アプリケーションのカスタマイズ」を参照してください。

29.5.2.6 拡張ルーティング・ルールの作成

拡張ルーティング・ルールを作成する手順は、次のとおりです。

1. 「割当て」セクションで、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。

2. リストから「拡張ルールの使用」を選択します。

3. 「動的ルーティング・ルール」を選択します。

「拡張ルールの使用」編集ボックスが表示されます。

4. 図29-47 に示すように、「ルール・ディクショナリ」の右側にある「編集」アイコンをクリックします。

図29-47 ルール・ディクショナリの作成

これにより、必要なすべてのファクト定義を含むリポジトリが事前にシードされたOracle Business Rules Designerが起動されます(図29-48 を参照)。ディクショナリ用のデシジョン・サービス・コンポーネントが作成され、タスク・サービス・コンポーネントに関連付けられます。

図29-48 ヒューマン・タスク・ルール・ディクショナリ

5. Oracle Business Rulesを使用して、タスクのステート・マシン・ルーティング・ルールを定義します。

これにより、ヒューマン・タスク内で完全に接続されたデシジョン・サービスと、関連するルール・リポジトリとデータ・モデルが自動的に作成されます。

ビジネス・ルールの詳細は、次のドキュメントを参照してください。

- 「サンプル・ルールセット」(ヒューマン・タスク・ルールセットの例)

- Oracle Business Process Managementを使用したビジネス・ルールの設計

- Oracle Business Process Management Rulesランゲージ・リファレンス

29.5.3 外部ルーティングの使用方法

ワークフローの参加者を動的に決定する外部ルーティング・サービスを構成します。このルーティング・ポリシーを指定すると、他の参加者タイプはすべて無視されます。タスクのルーティングを決定する参加者タイプ(単一承認者、シリアル承認者、パラレル承認者など)のリストを実行時に提供するのは、外部ルーティング・サービスとみなされています。

このオプションは、タスク割当て先の決定にルーティング・ルールを使用しない場合に使用します。この場合、タスク割当てのすべてのロジックは、外部ルーティング・サービスに委任されます。

注意:

「割当ての構成」ダイアログ・ボックスで「外部ルーティングを使用」を選択した場合は、Javaクラスを指定し、「OK」をクリックして終了します。次回、このダイアログ・ボックスを開くと、ドロップダウン・リストには、他の2つの選択肢(「指定した順序で全参加者へタスクをルート」および「拡張ルールの使用」)は表示されません。3つの選択肢すべてに再度アクセスするには、割当て全体を削除する必要があります。

外部ルーティングを使用する手順は、次のとおりです。

1. ワークフロー・エディタの「コンポーネント」ウィンドウから「外部ルーティング・サービス」をドラッグ・アンド・ドロップします。

「外部ルーティングを使用」編集ボックスが表示されます。

2. 「編集」アイコンをクリックします。

図29-49 に示すように、外部ルーティング・ダイアログ・ボックスが表示されます。

図29-49 外部ルーティング・ダイアログ

3. 「クラス名」フィールドで、完全修飾クラス・ファイル名(org.mycompany.tasks.RoutingServiceクラス名など)を入力します。このクラスは、次のインタフェースを実装している必要があります。

oracle.bpel.services.workflow.task.IAssignmentService

4. 表29-14 に示すように、外部サービスに渡す名前またはXPath式別に、名前/値ペアのパラメータを追加します。

表29-14 外部ルーティング

フィールド

説明

名前別

「名前」フィールドに名前を入力し、「値」フィールドに値を入力します。

式別

名前を入力し、フィールドの右側にあるアイコンをクリックして「式ビルダー」ダイアログ・ボックスを表示し、値を動的に入力します。

5. 「追加」アイコンをクリックし、その他の名前/値ペアのパラメータを追加します。

29.5.4 エラー割当て先とレビューアの構成方法

タスクは、間違った割当てなどの理由でエラーになることがあります。このようなエラーが発生すると、タスクは、修正処理を実行するエラー割当て先に割り当てられます。リカバリ可能なエラーは、次のとおりです。

- すべての参加者に対して無効なユーザーおよびグループ。

- 割当て先および有効期間に関連する無効なXPath式。

- 有効期限のエスカレーション・エラー。

- エスカレーション・ポリシーの評価

- 期限更新ポリシーの評価

- 管理チェーンの計算。

- 動的割当てルールの評価。タスクは、現在はエラーではありませんが、現在のユーザーに割り当てられたままです。したがって、リカバリ可能です。

- 動的割当ての循環割当て(「ユーザーA」→「ユーザーB」→「ユーザーA」など)。タスクは、現在はエラーではありませんが、チェーンの最終ユーザーに割り当てられたままです。したがって、リカバリ可能です。

次のエラーは、リカバリ可能ではありません。このような場合、タスクは終了状態ERROREDに移動します。

- 無効なタスク・メタデータ

- 読取り不可のタスク・メタデータ。

- ステート・マシン・ルールからの無効なGOTO参加者。

- 割当てサービスが見つからない場合。

- 割当てサービスによるエラー。

- カスタム・エスカレート関数の評価。

- パラレルのデフォルト結果とパーセント値に対する無効なXPathおよび値。

ワークフローのエラー割当て先は、ワークフロー・タスクのモデリング中に指定できます。エラー割当て先が指定されている場合は、その割当て先が評価されてタスクが割り当てられます。実行時にエラー割当て先が指定されていない場合は、管理ユーザーが検索され、アラート状態のタスクが割り当てられます。エラー割当て先は、次のいずれかのアクションを実行します。

- 非定型ルート
タスクを、そのタスクに実際に割り当てられているユーザーにルーティングします。非定型ルーティングを使用すると、タスクを順番に、またはパラレルなどでユーザーにルーティングできます。注意: FYI参加者の上下に非定型割当て先を追加しないでください。

- 再割当て
タスクを、このタスクに実際に割り当てられているユーザーに再割当てします。

- エラー・タスク
このタスクを修正できないことを示します。

エラー割当て先の評価中にエラーがあると、タスクはエラー発生としてマークされます。

このダイアログ・ボックスでは、割当てエラーが発生した場合にタスク割当て先となるユーザーまたはグループを指定できます。

エラー割当て先を構成する手順は、次のとおりです。

1. 図29-50 に示すように、「追加」アイコンをクリックして、レビューアまたはエラー割当て先を割り当てます。

図29-50 エラー割当て詳細

2. 「追加」アイコンをクリックし、このタスクに参加するユーザー、グループまたはアプリケーション・ロールを選択します。

「開始参加者」表の「識別タイプ」列に、選択したユーザー、グループまたはアプリケーション・ロールが表示されます。

3. ユーザー、グループまたはアプリケーション・ロールを選択する手順の詳細は、「単一タスク参加者リストの作成」のステップ5から7を参照してください。

4. パラレル参加者タイプを使用する場合は、サブタスク・ペイロードの格納場所を次のオプションで指定できます。

- サーバー設定を使用
Oracle Enterprise Manager Fusion Middleware ControlのSharePayloadAcrossAllParallelApproversシステムMBeanブラウザ・ブール型プロパティで、ルート・タスク内のサブタスクのペイロードを共有するかどうかを決定します。デフォルトで、このプロパティは「true」に設定されています。「true」に設定されている場合、「すべてのタスク参加者が同じペイロードを共有(パフォーマンスが向上し、記憶域のスペースが削減されます)」オプションが使用されます。このプロパティを「false」に設定すると、「各パラレル参加者がペイロードのローカル・コピーを所有」オプションが使用されます。設定を変更するには、「サーバー設定の変更方法」を参照してください。

- すべてのタスク参加者が同じペイロードを共有(パフォーマンスが向上し、記憶域のスペースが削減されます)
サブタスクのペイロードは、そのサブタスクのルート・タスクに格納されます。この状況は、ルート・タスクのペイロードが、そのサブタスクすべてで共有されることを意味します。内部的には、このオプションによってパフォーマンスが向上し、記憶域のスペース使用が削減されます。記憶域のスペース使用が削減されるのは、ルート・タスクのペイロードが、そのサブタスクすべてで共有されるためです。

- 各パラレル参加者がペイロードのローカル・コピーを所有
各サブタスクが独自にペイロードのコピーを持ちます。内部的には、このオプションを使用すると、より大きな記憶域のスペースが使用されるため、パフォーマンスが低下し、記憶域のスペース消費が増加します。

5. 「OK」をクリックします。

ユーザー、グループまたはアプリケーション・ロールの詳細は、「タスクの割当ておよびルーティング」を参照してください。

29.5.4.1 サーバー設定の変更方法

SharePayloadAcrossAllParallelApproversプロパティのデフォルト設定を変更するには、次の手順を実行します。

1. 「soa-infra」を右クリックして、「管理」→「システムMBeanブラウザ」の順に選択します。

2. 「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: server_name」→「WorkflowConfig」→「human-workflow」の順に開きます。

3. 「SharePayloadAcrossAllParallelApprovers」をクリックします。

4. リストでこのプロパティを変更し、「適用」をクリックします。

29.6 多言語設定とスタイルシートの指定

図29-51 に示すように、「プレゼンテーション」セクションでは、Oracle BPM Worklistで様々な言語でタスク詳細を表示するためのリソース・バンドルを指定したり、添付ファイルのWordMLおよびカスタム・スタイルシートを指定できます。

図29-51 「プレゼンテーション」セクション

29.6.1 添付ファイルとしてのWordMLスタイルシートとその他のスタイルシートの指定方法

添付ファイルのWordMLスタイルシートを指定する手順は、次のとおりです。

1. 「プレゼンテーション」セクションの「添付ファイルのスタイルシート」リストで、次のオプションのいずれかを選択します。

- Word ML: このオプションを使用すると、WordML XSLTスタイルシートを使用して電子メール添付ファイルとして送信するためのMicrosoft Word文書を動的に作成できます。XSLTスタイルシートは、タスク・ドキュメントに適用されます。

- その他: このオプションを使用すると、XSLTスタイルシートを使用して電子メール添付ファイルを作成できます。XSLTスタイルシートは、タスク・ドキュメントに適用されます。

2. 「検索」アイコンをクリックし、添付ファイルとして使用するスタイルシートを選択します。

29.6.2 多言語設定の指定方法

リソース・バンドルは、Oracle BPM Worklistで様々な言語でタスク詳細を表示するように指定できます。次のタスク詳細でリソース・バンドルがサポートされます。

- プレーン・テキストまたはmessage(key)書式によるタスクの結果値の表示。

- 様々な言語による電子メール通知メッセージの有効化。実行時にXPath拡張関数hwf:getTaskResourceBundleString(taskId, key, locale?)を指定して、指定したリソース・バンドルから国際化された文字列を取得します。通知受信者のロケールは、関数hwf:getNotificationProperty(propertyName)で取得できます。

リソース・バンドルは単純にプロパティ・ファイルでもあります。たとえば、タスクの結果の表示名を構成するリソース・バンドルは、次のようになります。

- APPROVE=Approve

- REJECT=Reject

多言語設定を指定する手順は、次のとおりです。

1. 「プレゼンテーション」セクションで、「リソース・バンドル」の横にある「追加」アイコンをクリックします。

図29-52 に示す「リソースの詳細」ダイアログ・ボックスが表示されます。

図29-52 「リソースの詳細」ダイアログ

2. 「リソース名」フィールドで、リソース・バンドルに使用するリソース名を入力します。このファイルは.propertiesベースのリソース・バンドル・ファイルである必要があります。

3. 「リソースの場所」フィールドで、「検索」アイコンをクリックし、使用するJARまたはZIPリソース・バンドル・ファイルを選択します。リソース・バンドルはシステム・アーカイブ(SAR)ファイルの一部です。

リソース・バンドルがコンポジット・プロジェクト外部にある場合は、SCA-INF/libにローカル・コピーを格納するように求めるプロンプトが表示されます。

リソース・バンドル・ファイルがコンポジット・クラス・ローダー(SCA-INF/classesの直下またはSCA-INF/libのJARファイル内)にない場合は、そのファイルがある場所を指定する必要があります。たとえば、リソース・バンドルがコンポジット・クラス・ローダー外部の場所(たとえば、http://host:port/bundleApp/taskBundles.jarのようなHTTPの場所など)からアクセス可能な場合は、その場所をこのフィールドに指定する必要があります。

4. 「OK」をクリックしてヒューマン・タスク・エディタに戻ります。

詳細は、「異なる言語による通知メッセージの構成方法」を参照してください。

29.7 ワークリストでの「タスクの詳細」に表示するものの指定

「プレゼンテーション」セクションで、worklistappのタスク詳細フォームの「ランタイム履歴」セクションにレコードを指定できます。

繰返しステージのマージ: すべての繰返しステージに対する1つの集計済エントリを表示するには、このオプションを選択します。ワークリストUIは、このオプションを設定または設定解除するオプションも提供します。

将来の参加者の表示: そのタスクのすべての将来の参加者に関する詳細を表示するには、このオプションを選択します。

ユーザーが実行したアクションのみを表示: デフォルトでは、タスク履歴詳細には、ルート・タスクの更新など管理およびシステム・アクションのレコードが含まれます。タスク詳細に、ユーザーが実行したアクションの更新のみを表示しないようにするには、このオプションを選択します。

29.8 タスクのエスカレート、期限更新または終了

図29-53 に、ヒューマン・タスク・エディタの「期限」セクションを示します。

このグローバル・ポリシー・セクション(ルーティング・スリップ・レベル)で、タスクの有効期間を指定できます。有効期間を参加者タイプ・レベルではなくルーティング・スリップ・レベルで指定すると、この期間は全参加者のタスクの有効期間となります。ただし、参加者タイプ・レベルで(「割当て済期間の制限の設定」チェック・ボックスを介して)有効期間を指定すると、その設定は「期限」セクション(ルーティング・スリップ・レベル)で指定した設定よりも優先されます。

指定した期間後にタスクがユーザーのマネージャにエスカレートされるように指定できます。詳細は、「タスクの操作に対する時間制限の指定」を参照してください。

図29-53 ヒューマン・タスク・エディタ - 「期限」セクション

29.8.1 エスカレーションおよび有効期限ポリシーの概要

この項では、このレベルで有効期間を指定し、その設定を参加者全員のタスクの有効期間にする方法の概要を説明します。

たとえば、図29-54 に示すように、参加者LoanAgentGroupおよび参加者Supervisorの両者間でタスクを操作するための日数が3日であるとします。

図29-54 「期限切れまでの時間」ポリシー

参加者レベルまたはこのルーティング・スリップ・レベルで有効期限が指定されていない場合、そのタスクの有効期間設定はありません。

参加者のいずれかのレベルで有効期間が設定されている場合、その参加者には対応する有効期間が使用されます。ただし、参加者レベルの有効期間が設定されていない参加者には、引き続きグローバルな有効期間が使用されます。グローバルな有効期間は、常にタスクでの経過時間だけ減分されます。

参加者について参加者レベルの有効期限を解析するためのポリシーは、次のとおりです。

- シリアル
「管理チェーン」内の各割当ては、「シリアル」で指定されている内容と同じ有効期間を取得します。期間は、この割当てによって生じるすべての割当てに対するものではありません。タスクが管理チェーン内のいずれかの割当てで有効期限に達すると、エスカレーションおよび期限更新ポリシーが適用されます。

- パラレル:

- パラレル・ワークフローでは、パラレル参加者がリソースとして指定されている場合は、リソースごとにルーティング・スリップが作成されます。作成された各ルーティング・スリップの有効期間には、次のルールが適用されます。
パラレル参加者の有効期間が指定されている場合は、その有効期間と等しい有効期間になります。

ルーティング・スリップ・レベルで指定されている場合は、タスクに残っている有効期間。

それ他の場合、有効期間はありません。

- パラレル参加者がルーティング・スリップとして指定されている場合、その有効期間はルーティング・スリップにより決定されます。

注意:

パラレル・タスク内で親タスクが期限切れになった場合、期限切れになっていないサブタスクや未完了のサブタスクは取り消されます。

29.8.2 期限切れがないポリシーの指定方法

タスクが期限切れにならないように指定できます。

図29-53 に示すように、「期限」セクションのドロップダウン・リストで、「期限切れなし」を選択し、期限切れがないポリシーを指定します。

29.8.3 期限切れがあるポリシーの指定方法

タスクに有効期限を指定できます。タスクが期限切れになると、ルーティング・スリップ・レベルのエスカレーション・ポリシーまたは期限更新ポリシーが適用されます。どちらのポリシーも指定されていない場合、タスクは期限切れになります。ルーティング・スリップ・レベルの有効期限ポリシーは、すべての参加者に共通です。

タスクに有効期限を指定する手順は、次のとおりです。

1. 図29-55 に示すように、「期限」セクションのドロップダウン・リストで、「期限切れまでの時間」を選択します。

2. タスクがオープンになっている最大期間を指定します。

パラレル参加者に対する有効期限ポリシーは、次のように解析されます。

- パラレル参加者がパラレル要素でリソースとして指定されている場合、各パラレル参加者に対する有効期限ポリシーはありません。

- パラレル参加者がルーティング・スリップとして指定されている場合、そのパラレル参加者にはルーティング・スリップの有効期限ポリシーが適用されます。

図29-55 は、タスクが3日で期限切れになることを示しています。

図29-55 「期限切れまでの時間」ポリシー

29.8.4 有効期限ポリシー期間の延長方法

ユーザーが割当て時間内に応答しない場合は、有効期限の期間を延長できます。このためには、期限切れの際にタスクの期限を更新できる回数(3回の追加更新など)と各期限更新期間(期限更新ごとに3日間など)を指定します。

有効期限ポリシー期間を延長する手順は、次のとおりです。

1. 図29-56 に示すように、「期限」セクションのドロップダウン・リストで、「期限更新までの時間」を選択します。

2. このタスクの期限更新を継続する最大回数を指定します。

図29-56 では、タスクが期限切れになると、最大3回まで期限が更新されます。タスクが参加者LoanAgentGroupの手元で期限切れになるか、参加者Supervisorの手元で期限切れになるかは関係ありません。

図29-56 「期限更新までの時間」ポリシー

29.8.5 タスク・ポリシーのエスカレート方法

ユーザーが割当て時間内に応答しない場合は、タスクをエスカレートできます。たとえば、ユーザー・ディレクトリに構成されているエスカレーション階層を使用している場合は、ユーザーのマネージャにタスクをエスカレートできます。エスカレーション・コールバックを使用している場合は、定義したユーザーにタスクをエスカレートできます。タスクが最大回数までエスカレートされた場合、エスカレートは停止します。エスカレートされたタスクは、そのタスクの期限切れ以降もユーザーの受信ボックス内に残すことができます。

タスク・ポリシーをエスカレートする手順は、次のとおりです。

1. 図29-57 に示すように、「期限」セクションのドロップダウン・リストで、「エスカレートまでの時間」を選択します。

2. さらに次の値を指定します。両方を設定すると、エスカレーション・ポリシーがより限定的になります。

- エスカレーション・レベルの最大数
タスクをエスカレートする管理レベル数。このフィールドは必須です。

- 承認者の最高役職
最上位承認者の役職(自分、マネージャ、取締役またはCEOなど)。これらの役職は、対応するユーザー・リポジトリのタスク割当て先の役職と比較されます。このフィールドはオプションです。

エスカレーション・ポリシーでは、タスクを期限切れ時にエスカレートできる回数と期限更新期間を指定します。図29-57 では、タスクが期限切れになると、最大3回までエスカレートされます。タスクが参加者LoanAgentGroupの手元で期限切れになるか、参加者Supervisorの手元で期限切れになるかは関係ありません。

図29-57 「エスカレートまでの時間」ポリシー

29.8.6 エスカレーション・ルールの指定方法

このオプションを使用すると、特定のワークフローについてカスタム・エスカレーション・ルールをプラグインできます。たとえば、期限切れ時に、タスクを現在のユーザーの部門マネージャに割り当てるには、カスタム・タスク・エスカレーション関数を記述してワークフロー・サービスに登録し、その関数をタスク定義に使用できます。

デフォルトのエスカレーション・ルールでは、タスクは現在のユーザーのマネージャに割り当てられます。新規エスカレーション・ルールを追加するには、次の手順に従います。

エスカレーション・ルールを指定する手順は、次のとおりです。

1. 次のインタフェースを実装します。

oracle.bpel.services.workflow.assignment.dynamic.IDynamicTaskEscalationFunction

この実装はサーバーのクラス・パスで使用可能である必要があります。

2. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

3. ナビゲータで、「SOA」フォルダを開きます。

4. 「soa-infra」を右クリックして、「SOA管理」→「ワークフロー構成」→「タスク」タブを選択します。

「ワークフロー・タスク・サービス・プロパティ」ページが表示されます。

5. 新しい関数を追加します。次に例を示します。

- 関数名: DepartmentSupervisor

- クラスパス: oracle.bpel.services.workflow.assignment.dynamic.patterns.DepartmentSupervisor

- 関数のパラメータ名

- 関数のパラメータ値

6. 「期限」セクションの「カスタム・エスカレーションJavaクラス」フィールドに、エスカレーション・ルールについて「ワークフロー・タスク・サービス・プロパティ」ページに定義されている関数名を入力します。

詳細は、「カスタム・エスカレーション関数」を参照してください。

29.8.7 期日の指定方法

期日は、タスクを完了する必要がある日付を示すために使用されます。期日は有効期限とは異なります。期限切れタスクの場合は、期限切れとしてマークされるか、エスカレーション・ポリシーに基づいて自動的にエスカレートまたは期限更新されます。通常、期日は有効期限より早い日付で、タスクの期限切れが近いことをユーザーに示します。

図29-53 に示すように、タスクの期日を入力できます。タスクは指定された期日をすぎると、期限切れとなります。この日付は有効期限ポリシーの付加項目です。期日は、有効期限ポリシーが指定されているかどうかに関係なく指定できます。期日を使用すると、Oracle BPM Worklistに期日を表示し、期限切れタスクをリストし、受信ボックス内の期限切れタスクをフィルタ処理できます。期限切れタスクは、TaskQueryService.queryTask(...) APIの述語を使用して、問合せできます。

期日を指定する手順は、次のとおりです。

1. 「期限」セクションで、「要求されたアクションの期日」チェック・ボックスを選択します。

2. 「期間別」を選択して期間を入力するか、「式別」を選択してXPath式として値を動的に入力します。

次の詳細に注意してください。

- 期日は、(Oracle BPM Worklistの「To Doタスクの作成」ダイアログ・ボックスを使用する)タスクと、(ヒューマン・タスク・エディタを使用する).taskファイルの両方で設定できます。これにより、タスクの開始時に、タスク定義のないTo Doタスクで期日を設定できるようになります。タスク(実行時オブジェクト)に設定された期日は、.taskファイルに設定された期日をオーバーライドします。

- タスク定義では、期日は各参加者に対してではなく、グローバルなレベルでのみ指定できます。

- タスクに対して期日が設定されている場合、.taskファイルの期日は無視されます。

- タスクに対して期日が設定されていない場合は、.taskファイルの期日が評価され、タスクに設定されます。

- タスクと.taskファイルのいずれにも期日がない場合、タスクには期日がありません。

注意:

To Doタスクに対してビジネス・ルールを指定することはできません。

詳細は、「To Doタスクの作成方法」を参照してください。

29.9 参加者の通知プリファレンスの指定

図29-58 に、ヒューマン・タスク・エディタの「通知」セクションの「一般」タブ(完全に開いた状態)を示します。

通知は、ユーザーまたはグループにタスクが割り当てられる時期を示すか、タスクのステータスに変更があったことを通知します。通知は、電子メール、ボイス・メッセージ、インスタント・メッセージまたはSMSで送信できます。異なるアクションについて様々なタイプの参加者に通知が送信されます。デフォルトでは、通知はデフォルト・メッセージを使用して構成されます。たとえば、タスクが完了してクローズされたことを示す通知メッセージが送信されます。独自の構成を作成するか、既存の構成を変更できます。

注意:

組込みLDAPでは、グループの電子メール・アドレスがサポートされていません。したがって、タスクがグループIDに割り当てられると、電子メールはグループの電子メール・アドレスではなく、そのグループの全メンバーに送信されます。

図29-58 ヒューマン・タスク・エディタ - 「通知」セクションの「一般」タブ

参加者の通知プリファレンスを指定する手順は、次のとおりです。

1. 図29-58 に示すように、「通知」タブをクリックします。

表29-15 に、「通知」セクションの「一般」タブの各サブセクションの構成方法を示します。

表29-15 ヒューマン・タスク・エディタ - 「通知」セクションの「一般」タブ

サブセクション

参照先

タスク・ステータス

受信者

タスク・ステータスの変更を受信者に通知する方法

通知ヘッダー

通知メッセージの編集方法

通知サービスの詳細は、「ヒューマン・ワークフローからの通知」を参照してください。

2. 「通知」セクションで、「詳細」タブをクリックします。図29-59に詳細を示します。

図29-59 「通知」セクション - 「詳細」タブ

表29-16 に、「通知」セクションの「詳細」タブの各サブセクションの構成方法を示します。

表29-16 ヒューマン・タスク・エディタ - 「通知」セクションの「詳細」タブ

サブセクション

参照先

リマインダ

リマインダの設定方法

エンコーディング

「文字セットのエンコーディングの変更方法」

通知のセキュア化(詳細を除く)

詳細を除外するための通知の保護方法

ワークリストURLを通知に表示

「通知でのURLの表示方法」

通知をアクション可能にする

電子メール・メッセージをアクション可能にする方法

電子メール通知によるタスクの添付ファイルの送信

「電子メール通知によるタスクの添付ファイルの送信方法」

グループ通知構成

「グループおよびアプリケーション・ロールへの電子メール通知の送信方法」

通知ヘッダーの属性

「通知ヘッダーのカスタマイズ方法」

29.9.1 受信者へのタスク・ステータス変更の通知方法

「タスク・ステータス」列には、3つのデフォルト・ステータス・タイプ「割当て」、「完了」および「エラー」が表示されます。通知メッセージの受信用に他のステータス・タイプを選択できます。

受信者にタスク・ステータス変更を通知する手順は、次のとおりです。

1. 「通知」セクションで、「一般」タブをクリックします。

2. 「タスク・ステータス」列で、タイプをクリックしてタスク・タイプの完全なリストを表示します。

- アラート済
タスクがアラート済の状態の場合は、受信者に通知できます。ただし、いずれの通知受信者(割当て先、承認者、所有者、イニシエータまたはレビューア)も、アラート済の状態を知らせるFYI通知の単なる受信者であり、アラート済の状態からエラー状態にタスクを移動することはできません。所有者は、タスクの再割当て、取消し、削除またはパージを実行できます。また、エラーを解決できない場合はタスクをエラー状態に移動するようにエラー割当て先に依頼できます。アラート済からエラー状態にタスクを移動できるのは、エラー割当て先のみです。

エラー割当て先は、「割当ての構成」ダイアログ・ボックスの「割当て」タブで構成します。このタブは「割当て」セクションの「タスクは開始参加者から最終参加者へ移行します」アイコンの下にあります。詳細は、「エラー割当て先とレビューアの構成方法」を参照してください。

- 割当て
ユーザーまたはグループにタスクが割り当てられた場合。この場合は、次のアクションが取得されます。

- ユーザーへのタスクの割当て

- シリアル・ワークフローでの新規ユーザーへのタスクの割当て

- タスクの期限更新

- タスクの委任

- タスクの再割当て

- タスクのエスカレート

- タスク情報の発行

- 完了

- エラー

- 期限切れ

- 情報のリクエスト

- 再開

- 一時停止

- 更新

- タスク・ペイロードの更新

- タスクの更新

- コメントの追加

- 添付ファイルの追加および更新

- 結果の更新

- 取下げ

- その他のすべてのアクション

- 前述のタスク・タイプ以外のアクションこれにはタスクの取得が含まれます。

3. タスク・ステータスのタイプを選択します。

通知は、様々な範囲でタスクに関与するユーザーに送信できます。これには、タスクがグループに割り当てられている場合が含まれます。グループに通知エンドポイントが設定されていない場合は、グループの各ユーザーに通知が送信されます。

4. 「受信者」列でエントリをクリックして、通知メッセージの受信者候補のリストを表示します。

- 割当て先
タスクが現在割り当てられているユーザーまたはグループ。

- イニシエータ
タスクを作成したユーザー。

- 承認者
この時点までにタスクを操作したユーザー。これは、複数のユーザーがタスクを承認するシリアル参加者タイプに適用され、通知はこれらのユーザー全員に送信される必要があります。

- 所有者
タスクの所有者

- レビューア
タスクにコメントおよび添付ファイルを追加できるユーザー。

詳細は、「通知チャネル・プリファレンスの構成方法」を参照してください。

29.9.2 通知メッセージの編集方法

デフォルトの通知メッセージを、選択した受信者に配信できます。必要な場合は、デフォルト・メッセージのテキストを変更できます。

通知メッセージを編集する手順は、次のとおりです。

1. 「通知」セクションで、「一般」タブをクリックします。

2. 「通知ヘッダー」列で、「編集」アイコンをクリックして、デフォルトの通知メッセージを変更します。

図29-60 に示す「通知メッセージの編集」ダイアログ・ボックスが表示されます。

図29-60 「通知メッセージの編集」ダイアログ

このメッセージは、サポート対象のすべての通知チャネル(電子メール、ボイス、インスタント・メッセージおよびSMS)に適用されます。電子メール・メッセージには、このメッセージに定義したワークリスト・タスク詳細も挿入できます。メッセージの配信チャネルは、指定した通知プリファレンスに基づいています。

3. 必要に応じてメッセージの文言を変更します。

4. 「OK」をクリックしてヒューマン・タスク・エディタに戻ります。

通知プリファレンスの詳細は、「ヒューマン・ワークフローからの通知」を参照してください。

29.9.3 リマインダの設定方法

タスクのリマインダを送信できます。リマインダは、タスクがユーザーに割り当てられた時刻またはタスクの有効期限が切れる時刻に基づいています。リマインダの数およびリマインダ間の間隔も構成可能です。

リマインダを設定する手順は、次のとおりです。

1. 「通知」セクションで、「詳細」タブをクリックします。

2. リストから、リマインダの送信数を選択します。

3. 割当て先に1回、2回または3回通知するように選択した場合は、リマインダの間隔を選択し、リマインダを割当て前に送信するか割当て後に送信するかを選択します。

詳細は、「リマインダの送信方法」を参照してください。

29.9.4 文字セットのエンコーディングの変更方法

Unicodeは、任意の言語の情報を単一の文字セットを使用して格納できる全世界共通のエンコード文字セットです。Unicodeでは、プラットフォーム、プログラムまたは言語に関係なく、すべての文字に一意のコード値が指定されます。UTF-8のデフォルト設定を使用するか、Javaクラスで文字セットを指定できます。

文字セットのエンコーディングを変更する手順は、次のとおりです。

1. 「通知」セクションで、「詳細」タブをクリックします。

2. 「エンコーディング」リストから、「Javaクラスで指定」を選択します。

3. 使用するJavaクラスを入力します。

29.9.5 詳細を除く通知をセキュア化する方法

通知のセキュア化、メッセージのアクション可能化および添付ファイルの送信を設定する手順は、次のとおりです。

1. 「通知」セクションで、「詳細」タブをクリックします。

2. 「通知のセキュア化(詳細を除く)」を選択します。

選択すると、デフォルトの通知メッセージが使用されます。電子メールには、HTMLのワークリスト・タスク詳細、添付ファイルまたはアクション可能なリンクはありません。メッセージにはタスク番号のみが含まれます。

詳細は、「セキュアな通知の送信方法」を参照してください。

29.9.6 通知でのOracle BPM Worklist URLの表示方法

電子メール通知メッセージにOracle BPM Worklist URLを表示するかどうかを構成できます。

通知にOracle BPM Worklist URLを表示する手順は、次のとおりです。

1. 「通知」セクションで、「詳細」タブをクリックします。

2. 「ワークリストURLを通知に表示」チェック・ボックスを選択すると、Oracle BPM Worklist URLが電子メール通知メッセージに表示されます。このチェック・ボックスを選択解除した場合、URLは表示されません。

29.9.7 電子メール・メッセージをアクション可能にする方法

電子メール・メッセージをアクション可能にする手順は、次のとおりです。

1. 「通知」セクションで、「詳細」タブをクリックします。

2. 「通知をアクション可能にする」を選択します。このアクションにより、電子メールを介してタスク・アクションを実行できます。

注意:

FYIタスクはアクション可能ではないため、電子メール・メッセージから確認できません。

その他の構成の詳細は、「アクション可能なメッセージの送信方法」を参照してください。

インバウンドとアウトバウンドの電子メールを構成する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

29.9.8 電子メール通知によるタスクの添付ファイルの送信方法

電子メール通知によってタスクの添付ファイルを送信できます。

電子メール通知によってタスクの添付ファイルを送信する手順は、次のとおりです。

1. 「通知」セクションで、「詳細」タブをクリックします。

2. 「電子メール通知によるタスクの添付ファイルの送信」を選択します。

29.9.9 グループおよびアプリケーション・ロールへの電子メール通知の送信方法

タスクが割り当てられたグループおよびアプリケーション・ロールに電子メール通知を送信できます。

グループおよびアプリケーション・ロールに電子メール通知を送信する手順は、次のとおりです。

1. 「通知」セクションで、「詳細」タブをクリックします。

2. 「グループ通知構成」リストから、次のいずれかのオプションを選択します。

- 電子メールを個別に送信
グループまたはアプリケーション・ロール内の各ユーザーが個別の電子メール通知を受け取ります。これはデフォルト選択です。

また、「ロケールに基づいて個別のタスク・フォームを使用」チェック・ボックスが自動的に選択されます。選択すると、言語ロケールに基づいた個別のタスク・フォームを使用して個別の電子メールが送信されます。選択しないと、タスク・フォームを再使用(共有)して個別の電子メールが送信されます。

- すべてのユーザー・アドレスを含む電子メールを送信
グループまたはアプリケーション・ロール内の各ユーザー・ロケールに対して共有の通知電子メールが1回生成され、その結果電子メール・コンテンツの生成時間が短縮されます。電子メールは、グループまたはアプリケーション・ロール内のすべてのユーザーに送信されます。

注意:

- すべてのユーザー(またはユーザーのサブセット)が同じ電子メールを受け取るため、グループまたはアプリケーション・ロール内のユーザーは同じ権限を持つと想定されています。これにより、権限のないユーザーにタスク詳細が表示されないようにします。

- 1通の電子メールをすべてのユーザーに送信する場合、アドレス・フィールドで許容される最大文字数は2000です。制限を超過すると、最大制限内に含まれているユーザー・アドレスにのみ電子メールが送信されます。

29.9.10 通知ヘッダーのカスタマイズ方法

カスタム通知ヘッダーは、名前/値ペアを指定し、通知の中でキー・フィールドを識別するために使用されます。ユーザーは、これらの入力項目を使用して、通知の配布プリファレンスを定義します。たとえば、「名前」を「ApprovalType」、「値」を「経費」に設定したり、「名前」を「優先度」、「値」を「高」に設定することができます。その後、ユーザーはOracle BPM Worklistで配信プリファレンスを指定できます。これらのプリファレンスは通知の内容に基づいています。

ルールベースの通知サービスは、使用する優先通知チャネルを特定する目的のみに使用されます。優先チャネルのアドレスは、引き続きアイデンティティ・サービスから取得されます。

通知ヘッダーをカスタマイズする手順は、次のとおりです。

1. 「通知」セクションで、「詳細」タブをクリックします。

2. 「通知ヘッダーの属性」を開きます。

3. 名前またはXPath式別に、名前/値ペアのパラメータを追加します。

プリファレンスの詳細は、次の各項を参照してください。

- 「インバウンドおよびアウトバウンド添付ファイルの送信方法」

- 「カスタム通知ヘッダーの作成方法」

- Oracle User Messaging Serviceによるアプリケーションの開発

29.10 タスク・コンテンツへのアクセス・ポリシーとタスク・アクションの指定

タスク・コンテンツへのアクセス・ルールと、そのコンテンツに対して実行するアクションを指定できます。

参加者が表示および更新できるタスクの部分を決定するアクセス・ルールを指定できます。アクセス・ルールは、タスクの取得および更新時にタスク・オブジェクトにルールを適用するワークフロー・サービスによって規定されます。

注意:

タスク・コンテンツ・アクセス・ルールおよびタスク・アクション・アクセス・ルールは相互に独立して存在します。

29.10.1 アクセス・ルールの概要

アクセス・ルールは、次の詳細に基づいて算定されます。

- アクセス・ルールに対応して構成されていないロールの権限は、アクセス・ルールで構成された属性によって却下されます。たとえば、割当て先が読み取るペイロードを構成するとします。このアクションでは、割当て先のみの読取り権限が有効になり、他の誰も対象になりません。割当て先も含めて、誰にも書込み権限はありません。

- アクセス・ルールで構成されていない属性には、すべての権限があります。

- ペイロードのメッセージ属性がアクセス・ルールで構成されている場合は、競合の可能性があるためにペイロード自体の構成は無視されます。この場合、APIが返すマップにはペイロードの入力項目は含まれません。読取り権限は、書込み権限によって自動的に提供されます。

- メッセージ属性のサブセットのみがアクセス・ルールで構成されている場合、影響を受けないすべてのメッセージ属性には、すべての権限があります。

- 追加権限があるのは、コメントと添付ファイルのみです。

- 特定の属性への書込み権限は意味がありません。たとえば、履歴の書込み権限によって、履歴に対する権限が付与されたり、却下されることはありません。

- 次の日付属性は、ヒューマン・タスク・エディタでは1つの属性として構成されます。TaskMetadataService.getVisibilityRules()が返すマップには、それぞれ1つのキーがあります。同様に、参加者にDATESの読取り権限がない場合、タスクには次のタスク属性のいずれも含まれません。

- START_DATE

- END_DATE

- ASSIGNED_DATE

- SYSTEM_END_DATE

- CREATED_DATE

- EXPIRATION_DATE

- ALL_UPDATED_DATE

- 次の割当て先属性は、ヒューマン・タスク・エディタでは1つの属性として構成されます。TaskMetadataService.getVisibilityRules()が返すマップには、次の割当て先属性のそれぞれに対して1つのキーがあります。同様に、参加者にASSIGNEESの読取り権限がない場合、タスクには次のタスク属性のいずれも含まれません。

- ASSIGNEES

- ASSIGNEE_USERS

- ASSIGNEE_GROUPS

- ACQUIRED_BY

- マップ済属性には、TaskMetadataService.getVisibilityRules()が返すマップ内に個別の表示はありません。

- TaskMetadataService.getVisibilityRules()が返すマップにあるすべてのメッセージ属性には、ITaskMetadataService.TASK_VISIBILITY_ATTRIBUTE_PAYLOAD_MESSAGE_ATTR_PREFIX (PAYLOAD)の接頭辞が付きます。

アプリケーションでは、アクセス・ルールに基づいてタスク属性を表示するページ(または表示しないページ)も作成できます。これは、次の例に示すように、oracle.bpel.services.workflow.metadata.ITaskMetadataServiceでAPIをコールして参加者のアクセス・ルールを取得することで実行できます。

public Map<String, IPrivilege> getTaskVisibilityRules(IWorkflowContext context,
String taskId)
throws TaskMetadataServiceException;

このメソッドの詳細は、『Oracle SOA Suiteワークフロー・サービスJava APIリファレンス』を参照してください。

29.10.2 タスク・コンテンツの操作に対するユーザー権限の指定

特定のタスク・コンテンツ(ペイロードなど)の操作を特定のユーザー(タスクの作成者または所有者など)に許可する権限を指定できます。

タスク・コンテンツの操作についてユーザー権限を指定する手順は、次のとおりです。

1. 「アクセス」タブをクリックします。

2. 「Content」タブをクリックします。

3. 図29-61 に示すように、アクセス権を指定するタスク・コンテンツを選択します。

図29-61 タスク・コンテンツ・アクセスの設定

4. タスク・コンテンツを操作するユーザーに権限(読取り、書込みまたはアクセスなし)を割り当てます。ユーザーには、最高レベルを超えて権限を割り当てることはできません。たとえば、ADMINユーザーにPAYLOADタスク・コンテンツに対する書込み権限を割り当てることはできません。表29-17 に、タスク・コンテンツに対する各ユーザーの最大権限を示します。

表29-17 タスク・コンテンツに対するユーザーの最高権限レベル

タスク・コンテンツ

読取り権限保持者

書込み権限保持者

割当て先

管理者、承認者、割当て先、作成者、所有者、レビューア

--

添付ファイル

管理者、承認者

割当て先、作成者、所有者、レビューア

コメント

管理者、承認者

割当て先、作成者、所有者、レビューア

日付

管理者、承認者、割当て先、作成者、所有者、レビューア

--

フレックスフィールド

管理者、承認者、レビューア

割当て先、作成者、所有者

履歴

管理者、承認者、割当て先、作成者、所有者、レビューア

--

ペイロード

管理者、承認者、レビューア

割当て先、作成者、所有者

レビューア

管理者、承認者、割当て先、作成者、所有者、レビューア

--

ペイロード要素

ペイロードから継承

ペイロードから継承

たとえば、PAYLOADタスク・コンテンツについて、ASSIGNEES、CREATORおよびOWNERの書込みアクセス権、ADMIN、APPROVERSおよびREVIEWERSの読取りアクセス権、およびアクセス権がないPUBLICというデフォルト設定をそのまま使用すると、ダイアログ・ボックスは図29-61 に示すように表示されます。

5. このダイアログ・ボックスで、タスク・コンテンツの表示方法を選択します。現在選択されていないオプションを選択すると、すべての設定がデフォルトの値にリセットされます。

- 大まかな(デフォルト)
タスク・コンテンツが総括的に表示されます(たとえば、ペイロードやレビューアが1つのみ表示されます)。

- きめ細かな
コンテンツが個別の要素として表示されます (たとえば、すべてのペイロード(p1、p2、p3など)およびこのタスクに割り当てられているすべてのレビューア(jstein、wfaulk、cdickens)が表示されます)。

注意:

システムで許可されている内容とは別に、アクセス・ルールは、常にアクションの実行者とタスクの現在の状態に基づいて適用されます。

29.10.3 タスクの操作に対するアクションの指定

タスク・コンテンツ(ペイロードなど)の操作について、「タスク・コンテンツ・アクセスの設定」ダイアログ・ボックスで指定した特定のユーザー(タスクの作成者または所有者など)に許可するアクション(アクセスまたはアクセスなし)を指定できます。

タスクの操作に対してアクションを指定する手順は、次のとおりです。

1. 「アクセス」タブをクリックします。

2. 「アクション」タブをクリックします。

3. 図29-62 に示すように、ユーザーを指定するタスク・アクションを選択します。

図29-62 「アクション・アクセス・ルールの追加」の選択

4. 選択したアクションを参加者が実行できるかどうかを選択します。

5. このダイアログ・ボックスで、タスク・アクションの表示方法を選択します。現在選択されていないオプションを選択すると、すべての設定がデフォルトの値にリセットされます。

- 大まかな(デフォルト)
タスク・アクションが総括的に表示されます(たとえば、承認や却下が1つのみ表示されます)。

- きめ細かな
コンテンツに対するアクションが個別要素として表示されます (たとえば、すべての承認や却下が表示されます)。

29.10.4 ワークフロー・デジタル署名ポリシーの指定方法

デジタル署名は、デジタル署名されたヒューマン・タスクの否認防止メカニズムを提供します。この機能は、タスクを操作する参加者に対し、タスクの更新前に詳細と各自のアクションに対する署名を義務付けることで、後で否認できないようにします。

注意:

タスクに対してデジタル署名が有効な場合、アクション可能な電子メールは実行時に送信されません。設計時にアクション可能な電子メールが有効化された場合も同様です。

ワークフロー・デジタル署名ポリシーを指定する手順は、次のとおりです。

1. 「アクセス」タブをクリックします。

2. 図29-63 に示すように、「署名ポリシー」リストで「ポリシーの設定」を選択します。

図29-63 デジタル署名

3. タスク参加者が使用する署名ポリシーを指定します。

- 署名は不要
参加者は、署名せずにタスクの送信と操作を実行できます。これはデフォルトのポリシーです。

- パスワードは必須
参加者は、次の参加者にタスクを送信する前に、署名を指定します。参加者はタスクを操作する際に、パスワードを再入力する必要があります。パスワードは、デジタル署名の生成に使用されます。デジタル署名はメッセージ送信者または文書の署名者の本人認証を行います。これにより、送信されたメッセージの元の内容が変更されていないことが保証されます。

- デジタル証明書は必須
参加者は、デジタル署名されたヒューマン・タスクの否認防止のために、デジタル証明書を保持する必要があります。参加者の資格証明は、デジタル証明書によって証明されます。これは認証局(CA)が発行します。名前、シリアル番号、有効期限、証明書所有者の公開鍵のコピー(メッセージとデジタル署名の暗号化に使用)、および証明書発行者のデジタル署名が記載されているため、メッセージの信頼性を確立できます

認証局の名称とCRLおよび発行認証局のURLは、個別に構成する必要があります。

4. 「OK」をクリックします。

詳細は、「エビデンス・ストア・サービスとデジタル署名」を参照してください。

29.10.4.1 認証局の指定

デジタル署名を使用するには、Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで信頼できるCAを指定する必要があります。このCAから発行された証明書のみが、ヒューマン・ワークフローで有効と見なされます。

認証局を指定する手順は、次のとおりです。

1. 「SOAインフラストラクチャ」メニューから、「管理」→「システムMBeanブラウザ」の順に選択します。

2. 「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: server_name」→「WorkflowConfig」→「human.workflow」の順に選択します。

3. 「操作」タブをクリックします。

4. 「AddTrustedCA」をクリックします。

5. 「CaName」および「CaURL」の「値」フィールドに、適切な値を指定します。

6. 「起動」をクリックします。

7. 「戻る」をクリックします。

これらの値は、使用前に検証する必要があります。

29.11 タスク割当てに対する制限の指定

コールバック・クラスを使用してタスクを再割当てまたはルーティングできるユーザーを制限できます。

通常のLDAPディレクトリにシードされているユーザー・コミュニティは会社全体や部署全体を表します。ただし、タスクに関連付けるユーザーの潜在的リストは、スコープに基づいて制限したり、タスクや関連するデータの重要性に基づいて制限することが必要な場合があります。たとえば、数千のユーザーが存在する大企業では、少数のユーザーのみが注文書を承認および作成できるようにする場合があります。特にこのようなタスクでは、非定型ルーティングおよび再割当てに対して選択できるユーザーとして、会社全体規模のユーザーを対象にしないでください。かわりに、適切または権限のある少数のユーザーのみを選択対象とする必要があります。これを実行するには、制限付き割当て機能を使用します。この機能はコールバック・クラスとして実装されます。このコールバック・クラスには、インスタンス・データを含むタスク・オブジェクトが渡されるとそのタスク・オブジェクトに基づいて適切なユーザー・セットを動的に選択するロジックを実装できます。

注意:

制限付きタスクの再割当てなどの特定の関数は、単一のタスクが選択されている場合にのみ使用できます。制限付き再割当てを使用する複数のタスクが選択されている場合、制限付き再割当てアルゴリズムは起動されません。その場合、制限付き再割当てが指定されていなかったかのようにユーザーの完全なリストが返されます。

29.11.1 タスク割当てに対する制限の指定方法

タスク割当てに対して制限を指定する手順は、次のとおりです。

1. 「アクセス」セクションで、「制限付き割当ての設定」をクリックします。

「制限付き割当ての設定」ダイアログ・ボックスが表示されます。

2. クラス名を入力します。入力するクラスは、oracle.bpel.services.workflow.task.IRestrictedAssignmentCallbackインタフェースを実装している必要があります。

3. 「追加」アイコンをクリックし、コールバックを起動する際に渡すプロパティ・マップの名前と値のペアを追加します。

4. 「OK」をクリックします。

29.12 Javaコールバックまたはビジネス・イベント・コールバックの指定

Javaコールバックまたはビジネス・イベント・コールバックを指定できます。

注意:

コールバックを実装している場合、ユーザー・コールバック実装はその他の形式の制限付き割当てをオーバーライドします。検索を実行すると、その結果には、ユーザー・コールバックによって返されるユーザーのみが表示されます。

ワークフロー・サービスのコールバックは、タスクのライフサイクルで特定のステージに到達したときにコールするように登録できます。2つのタイプのコールバックがサポートされています。

- Javaコールバック: コールバック・クラスは、インタフェースoracle.bpel.services.workflow.task.IRoutingSlipCallbackを実装している必要があります。このコールバック・クラスをサーバーのクラスパスで使用可能にします。

- ビジネス・イベント・コールバック: ヒューマン・タスクの状態が変化したときに、ビジネス・イベントが発生するようにできます。Javaクラスを開発して登録する必要はありません。コール元は、承認トランザクションの現在の状態が通知されるように、Oracle Mediatorサービス・コンポーネントを使用してコールバックを実装し、適用可能なビジネス・イベントをサブスクライブします。

タスク・ステータスのコールバック・クラスを指定する手順は、次のとおりです。

1. 「イベント」タブをクリックします。
選択できる状態変更コールバックは、次のとおりです。

- OnAssigned
標準的なルーティング、再割当て、委任、エスカレーションなどを含め、割当ての変更時にコールバック・クラスをコールする必要がある場合に選択します。タスクによって結果が更新される(つまり、チェーンのいずれかの承認者がタスクを承認または却下する)ときにコールバックする必要がある場合は、このオプションを選択する必要があります。

- OnUpdated
更新(ペイロード、コメント、添付ファイル、優先度などを含む)時にコールバック・クラスをコールする必要がある場合に選択します。

- OnCompleted
タスクが完了し、コントロールがイニシエータ(タスクを開始するBPELプロセスなど)に渡されようとしているときに、コールバック・クラスを最終的にコールする必要がある場合に選択します。

- OnStageCompleted
ヒューマン・ワークフロー・タスクでビジネス・イベント・コールバックを有効化するために、コールバック・クラスをコールする必要がある場合に選択します。イベントが発生すると、そのイベントには、完了したステージの名前、完了したステージの結果、およびコールバックが起動された時点でのタスクのスナップショットが格納されます。

- OnSubtaskUpdated
サブタスク(パラレルおよびパラレル・シナリオのいずれかのタスク)の更新(ペイロード、コメント、添付ファイル、優先度などを含む)時にコールバック・クラスをコールする必要がある場合に選択します。

Oracle JDeveloperのインストールが、BPEL拡張とBPM拡張の両方を含むように更新されている場合は、次のコンテンツのコールバックも選択できます。

- コメント・コールバック
WFCOMMENTS列以外のスキーマにコメントを格納するために、コールバック・クラスをコールする必要がある場合に選択します。コールバック・クラスは、oracle.bpel.services.workflow.callback.NotesStoreインタフェースを実装している必要があります。

- 添付コールバック
soa-infraスキーマのWFATTACHMENT表以外のスキーマに添付ファイルを格納するために、コールバック・クラスをコールする必要がある場合に選択します。コールバック・クラスは、oracle.bpel.services.workflow.callback.AttachmentStoreインタフェースを実装している必要があります。

- 検証コールバック
タスクまたはペイロードのいずれかを更新や承認などの前に検証するために、コールバック・クラスをコールする必要がある場合に選択します。コールバック・クラスは、oracle.bpel.services.workflow.task.ITaskValidationCallbackインタフェースを実装している必要があります。

2. 実行するコールバックのタイプに応じて、次の項を参照してください。

- 「Javaコールバックの指定」

- 「ビジネス・イベント・コールバックの指定」

29.12.1 Javaコールバックの指定

Javaコールバックを指定する手順は、次のとおりです。

1. 「イベント」セクションの「状態」列で、タスク状態を選択します。

2. 「Javaクラス」列の空のフィールドをクリックして値を入力します。この値は、oracle.bpel.services.workflow.task.IRoutingSlipCallbackを実装するJavaクラスの完全クラス名です。図29-64に詳細を示します。

図29-64 Javaが選択された状態の「コールバック詳細」ダイアログ

3. 「OK」をクリックします。

29.12.2 ビジネス・イベント・コールバックの指定

ビジネス・イベント・コールバックを指定する手順は、次のとおりです。

1. 「イベント」セクションの「状態」列で、タスク状態を選択します。「Javaクラス」フィールドは空のままにします。

2. 「ワークフロー・イベントのトリガー」チェック・ボックスを選択します。これにより、図29-65 に示すように、「Javaクラス」列が使用不可になります。各コールバック(OnAssignedなど)は、1つのビジネス・イベント・ポイントに対応しています。ビジネス・イベントが起動されると、イベント詳細にはタスク・オブジェクトおよび一連のプロパティが挿入されます。各プロパティの値は、起動されるイベントの内容に基づいて移入されます。

図29-65 ビジネス・イベントが選択された状態の「コールバック詳細」ダイアログ

事前にシードされている静的イベント定義言語(EDL)ファイル(JDev_Home\jdeveloper\integration\seed\soa\shared\workflow\HumanTaskEvent.edl)によって、サブスクライブ対象として使用可能なビジネス・イベントのリストが提供されます。これらのビジネス・イベントは、「コールバック詳細」ダイアログ・ボックスで選択したコールバックに対応しています。EDLファイルを参照し、適切なビジネス・イベントをサブスクライブするOracle Mediatorサービス・コンポーネントを作成する必要があります。

注意:

EDLファイルを配置できるようにするには、ファイルベースのMDS接続が必要です。ファイルベースのMDSの場所は、JDev_Home\jdeveloper\integration\seedです。

3. イベントをサブスクライブできる同じまたは異なるSOAコンポジット・アプリケーションに、Oracle Mediatorサービス・コンポーネントを作成します。

4. Oracle Mediatorの作成時に、「テンプレート」リストで、「イベントのサブスクライブ」を選択します。

5. 「追加」アイコンをクリックして、新しいイベントをサブスクライブします。

6. 「イベント定義」フィールドの右側にある「参照」アイコンをクリックし、EDLファイルを選択します。

「SOAリソース・ブラウザ」ダイアログ。ボックスが表示されます。

7. 前に作成したファイルベースのMDS接続を選択します。

8. 上部のリストから「リソース・パレット」を選択します。

9. 「SOA」→「共有」→「ワークフロー」→「HumanTaskEvent.edl」の順に選択します。

「OK」をクリックします。

これで、選択可能なEDLファイル・ビジネス・イベントが「イベント・チューザ」に移入されます。

10. 「イベント」フィールドで、サブスクライブするイベントを選択します。図29-66に詳細を示します。

図29-66 イベント・コールバック

イベントのサブスクライブに使用可能なヒューマン・タスクは複数あります。たとえば、次を実行したとします。

- イベント(OnAssignedなど)をサブスクライブするTaskAというヒューマン・タスクを構成しました。

- 同じイベントをサブスクライブするTaskBというヒューマン・タスクを構成しました。

TaskAとTaskBのイベントを区別し、意図したOracle Mediatorによってイベントを確実に処理するには、静的なルーティング・フィルタを追加できます。

xpath20:compare(med:getComponentName(), 'TaskA')

これにより、送信コンポーネントがTaskAの場合にのみ、このルーティングが起動されます。

11. EDLファイルがファイルベースのMDS接続から選択されなかった場合、プロンプトに従って依存XSDファイルのインポートを受け入れ、「OK」をクリックします。EDLファイルがファイルベースのMDS接続から選択された場合、プロンプトは表示されません。

これで、Oracle Mediatorサービス・コンポーネントに、サブスクライブするビジネス・イベントが移入されます。同じEDLファイルに定義されている他のビジネス・イベントも、この時点で、または後でサブスクライブできます。

ビジネス・イベントおよびコールバックの詳細は、次の各項を参照してください。

- ビジネス・イベントの詳細は、「ビジネス・イベントおよびイベント配信ネットワークの使用」を参照してください

- サンプルのworkflow-116-WorkflowEventCallback (Oracle SOA Suiteサンプルで使用できます)。

29.12.3 BPELコールバックのタスクとルーティング・カスタマイズの指定方法

通常、BPELプロセスはワークフロー・コンポーネントをコールしてユーザーにタスクを割り当てます。ワークフローが完了すると、ヒューマン・ワークフロー・サービスはBPELプロセスにコールバックされます。ただし、詳細なコールバック(たとえば、onTaskUpdateまたはonTaskEscalated)をBPELプロセスに送信する場合は、「BPELコールバックのタスクとルーティング・カスタマイズを許可」オプションを使用できます。

このコールバック設定については、BPELダイアグラムを必ず手動でリフレッシュしてください。

BPELコールバックのタスクとルーティングのカスタマイズを指定する手順は、次のとおりです。

1. 「イベント」セクションで、「BPELコールバックのタスクとルーティング・カスタマイズを許可」チェック・ボックスを選択します。

2. Oracle BPELデザイナに戻ります。

3. タスクのアクティビティ・ダイアログ・ボックスを開きます。

4. 「OK」をクリックします。

これにより、タスクのscopeアクティビティ内に、BPELコールバックをカスタマイズするためのwhile、pick、およびpickアクティビティのonMessageブランチが作成されます。

タスクとルーティング・カスタマイズの指定の詳細は、「BPELコールバックの起動」を参照してください。

29.12.4 BPELコールバックを無効にする方法

ユーザーtalkアクティビティ(Oracle BPELデザイナ内)にはinvokeアクティビティ、それに続いてreceiveまたはpickアクティビティがあります。「BPELコールバックの無効化」チェック・ボックスの選択を解除すると、リプライを待たずにタスク・サービスを起動できます。

BPELコールバックを無効化する手順は、次のとおりです。

1. 「イベント」セクションで、「BPELコールバックの無効化」チェック・ボックスの選択を解除します。

2. 「OK」をクリックします。

30 ヒューマン・タスク用のタスク・フォームの設計

この章では、開発者がOracle JDeveloperのADFタスク・フローを使用して、ヒューマン・タスクのタスク・フォームを設計してカスタマイズできる方法について説明します。ヒューマン・タスクを使用すると、ユーザーはビジネス・プロセスと相互作用できます。それぞれのタスクには、タスク・メタデータとタスク・フォームという2つの部分があります。タスク・フォームは、タスクのコンテンツをユーザーのワークリストに表示するために使用されます。

Oracle BPM Worklistには、ユーザーまたはグループに割り当てられているすべてのワークリスト・タスクが表示されます。ワークリスト・ユーザーが特定のタスクにドリルダウンすると、タスク・フォームにはそのタスクの詳細が表示されます。

この章の内容は次のとおりです。

- タスク・フォームの概要

- タスク・フローとタスク・サービスの関連付け

- ヒューマン・タスクに基づいたADFタスク・フローの作成

- タスク・フォームの作成

- タスクXSD変更時のデータ・コントロールのリフレッシュ

- タスク・フロー・アプリケーションの保護

- 電子メール通知の作成

- タスク・フローを使用したコンポジット・アプリケーションのデプロイ

- ワークリストでのタスク・フォームの表示

- 電子メール通知でのタスクの表示

- 複数のヒューマン・タスクを含むタスク・フロー・アプリケーションの再利用

ヒューマン・ワークフロー問題のトラブルシューティングの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のヒューマン・ワークフローのトラブルシューティングに関する項を参照してください。

30.1 タスク・フォームの概要

SOAコンポジットにヒューマン・タスクが含まれている場合は、ユーザーがタスクと相互作用する方法が必要です。このため、Oracle SOA Suiteの統合開発環境には、Oracle Application Development Framework (Oracle ADF)が含まれています。Oracle ADFを使用すると、SOAコンポジットのヒューマン・タスクを表すタスク・フォームを設計できます。

タスク・フォームは、Java Server Page XML (.jspx)ファイルです。このファイルは、ヒューマン・タスクが含まれるSOAコンポジットを作成したOracle JDeveloperデザイナで作成します。Java Server Page XMLファイルを作成するには、その前に、Oracle JDeveloperでページのエンコーディングをUTF-8に設定する必要があります。設定するには、Oracle JDeveloperで「ツール」→「プリファレンス」→「環境」の順に選択し、「エンコーディング」ドロップダウン・リストから「UTF-8」を選択します。

図30-1 に、タスク・フォームの作成を開始する、Oracle JDeveloperの「ヒューマン・タスクに基づいたADFタスク・フロー」オプションを示します。

図30-1 Oracle JDeveloperの「ヒューマン・タスクに基づいたADFタスク・フロー」

30.1.1 タスク・フォームに関する必知事項: タイムゾーン変換

タスク・フォームの作成時には、タスク・ペイロードの日時要素に対してタイムゾーン変換が自動的に行われません。日時要素でタイムゾーン変換を有効にするには、<af:convertDateTime>タグを追加する必要があります。標準的なタスク・ヘッダーの時間ラベルを例として参照してください。次の例はヘッダーのサンプルです。

<af:outputText value="#{bindings.createdDate.inputValue}"
id="ot15">
<f:convertDateTime type="#{pageFlowScope.dt}"
timeZone="#{pageFlowScope.tz}"
dateStyle="#{pageFlowScope.df}"
timeStyle="#{pageFlowScope.tf}"/>
</af:outputText>

30.2 タスク・フローとタスク・サービスの関連付け

ヒューマン・タスクに基づいてADFタスク・フローを作成する場合は、タスク・メタデータ・ファイルを選択して、データ・コントロールを生成する必要があります。データ・コントロールは、ページ内のコンテンツのレイアウトを行うために使用され、実行時にはワークフロー・サービス・エンジンに接続して、タスク・コンテンツを取得し、タスクを操作します。詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のADFタスク・フローの開始に関する項を参照してください。

hwtaskflow.xmlファイルは、サービス・エンジンとの接続時に詳細を取得するために使用されます。デフォルトでは、リモートEJBを使用してワークフロー・サーバーに接続します。SOAサーバーのURLとポートは、WebLogic Serverの実行時MBeanを使用して自動的に決定されます。ただし、その内容は、ここでURLとポート情報を明示的に指定することでオーバーライドできます。

タスク詳細アプリケーションがワークフロー・サービスに接続できるように、ORMI権限があるユーザーをシードしてください。このユーザーは、Oracle Enterprise Manager Fusion Middleware Controlを使用してシードできます。

30.3 ヒューマン・タスクに基づいたADFタスク・フローの作成

ADFタスク・フローは、「タスクの詳細」ページのユーザー・インタフェースをモデリングするために使用されます。このタスク・フローは、ヒューマン・タスクが含まれている同じアプリケーション、または別のアプリケーションで作成できます。

タスク・フローを作成するには、その前に、ヒューマン・タスク(.taskファイル)をSOAコンポジットの一部として作成する必要があります。.taskファイルの作成方法は、「ヒューマン・タスクの作成」を参照してください。

タスク・フローがヒューマン・タスクと同じアプリケーションにある場合は、そのタスク・フローに対して別のプロジェクトを作成します。SOAコンポジットに複数のヒューマン・タスクが含まれている場合は、各ヒューマン・タスクに関連付けられているADFタスク・フローごとに個別のプロジェクトを作成します。データ・コントロールは、ADFタスク・フローを使用し、タスクのパラメータと結果に基づいて作成します。

ADFタスク・フォームを自動生成するには、SOAコンポジット・アプリケーション内のヒューマン・タスクにアクセスします(フォームとタスクは同じアプリケーション内にあります)。詳細は、「ヒューマン・タスク・エディタからADFタスク・フローを作成する方法」を参照してください。

別のアプリケーションにADFタスク・フォームを作成するには、新規のアプリケーションとプロジェクトを作成し、ヒューマン・タスクの.taskファイルを参照します。詳細は、「ヒューマン・タスクに基づいたADFタスク・フローの作成方法」を参照してください。

ADFタスク・フォームでは、ユーザー入力は検証されません。実行されるのは、必須入力に値があるかどうかの検証のみです。タスク・フォームを確認して、必要に応じて追加のバリデータを追加する必要があります。

30.3.1 ヒューマン・タスク・エディタからADFタスク・フローを作成する方法

ヒューマン・タスクとタスク・フローが同じアプリケーションにある場合、ヒューマン・タスクを指定する.taskファイルは、簡単にタスク・フローに関連付けられます。

ヒューマン・タスクに対してADFタスク・フローを作成する手順は、次のとおりです。

1. SOAコンポジット・アプリケーション内でBPELプロセスを開きます。

2. ヒューマン・タスク・アクティビティをダブルクリックし、「編集」をクリックします。

図30-2 に、「Human Task」ダイアログを示します。

図30-2 ヒューマン・タスクの編集

3. 「.task」タブ(図30-3 を参照)で、「フォーム」をクリックして「タスク・フォームの自動生成」を選択します。

図30-3 ヒューマン・タスク・エディタでのタスク・フローの作成

4. プロジェクト名とディレクトリ・パスを入力(または、デフォルトをそのまま使用)して、「OK」をクリックします。

図30-4 に示すように、「taskDetails1_jspx」アイコンがデザイナに表示されます。

図30-4 「taskDetails1_jspx」アイコン

これで、タスク・フローおよびタスク・フォームが完成し、デプロイする準備ができました。

30.3.2 ヒューマン・タスクに基づいたADFタスク・フローの作成方法

デプロイメントを容易にするには、図30-1 に示す「ヒューマン・タスクに基づいたADFタスク・フロー」オプションを使用して、ADFタスク・フローおよび追加のアーティファクトを作成します。.taskファイルを選択してADFタスク・フローに関連付けると、タスクのパラメータと結果に基づいてヒューマン・タスク・データ・コントロールが作成されます。これらのデータ・コントロールは、JSPXページで使用可能になります。タスク・フロー・プロジェクトを作成するときは、SOAコンポジット・プロジェクトへのアクセス権が必要です。

ヒューマン・タスクに基づいてADFタスク・フローを作成する手順は、次のとおりです。

1. 「ファイル」メイン・メニューから、「新規」→「アプリケーション」→「カスタム・アプリケーション」の順に選択します。

2. 「OK」をクリックします。

3. アプリケーション名およびディレクトリ情報を入力(または、デフォルトをそのまま使用)して、「終了」をクリックします。

4. プロジェクト名を右クリックし、「新規」を選択します。

5. 「Web層」の下にある「JSF」を選択します。

6. 「ヒューマン・タスクに基づいたADFタスク・フロー」を選択し、「OK」をクリックします。

7. 「SOAリソース・ブラウザ」で、ヒューマン・タスクを定義した.taskファイルを検索して選択し、「OK」をクリックします。

a. ヒューマン・タスクがタスク定義と同じアプリケーションにある場合は、「ファイルシステム」をクリックし、ファイル・ブラウザを使用して.taskファイル(通常はコンポジット・ディレクトリにあります)に移動します。

b. ヒューマン・タスクが別のアプリケーションにある場合は、「SOA-MDS」をクリックし、MDSリソース・カタログを使用してコンポジット・アプリケーションにある.taskファイルを検索します。

c. .taskファイルが現在のアプリケーション内にある場合は、「アプリケーション」をクリックします。

これにより、データ・コントロールを作成する「タスク・フローの作成」ダイアログが表示されます。

8. 「タスク・フローの作成」ダイアログでは、デフォルトをそのまま使用し、「OK」をクリックします。
図30-4 に示すように、「taskDetails1_jspx」アイコンがデザイナに表示されます。このタスク・フローには、ビュー、コントロール・フローおよびタスク・リターンがあります。

タスク・フォームの作成を継続するには、次の項を参照してください。

- 「ペイロードを持つ完了済タスク」ドロップ・ハンドラを使用したタスク・フォームの作成方法。

- 個別のドロップ・ハンドラを使用したタスク・フォーム・リージョンの作成方法。

30.3.3 ヒューマン・タスクに基づいたADFタスク・フロー作成時の処理内容

ヒューマン・タスクに基づいたADFタスク・フローの場合、タスク・フロー・アプリケーションにはタスク・フォームをワークフロー・サービスに接続するタスク・データ・コントロールがあります。データ・コントロールは次を提供します。

- タスク・データにアクセスして操作を行う様々なパラメータおよび操作

- インタフェース・リージョンを作成して、タスクの内容を表示できるドロップ・ハンドラ

図30-5 に示すように、ヒューマン・タスクを意識したデータ・コントロールがOracle JDeveloperの「アプリケーション」ウィンドウの「データ・コントロール」パネルに表示されます。

図30-5 「データ・コントロール」パネルのタスク・コレクション

タスクのデータ・コントロール(図30-5 の「タスク」ノードに表示)には、タスク・フォームを表示するドロップ・ハンドラがあります。詳細は、「タスク・フォームの作成」を参照してください。

30.3.4 異なるメタ属性が指定された同じ要素を含む複数のADFタスク・フローに関する必知事項

同じ要素を含むが異なるメタ属性が指定されている(例: 編集可能と編集不可)ADFタスク・フローを複数作成する場合は、それぞれを個別に作成する必要があります。

たとえば、次のタスクを実行するとします。

1. SOAコンポジット・アプリケーションのタスク・フォーム・アプリケーションを2つ作成します。

- 1つのタスク・フォーム・アプリケーション(たとえば、銀行詳細入力タスクの「EnterBankDetails.task」)には、1つの編集可能ペイロード(たとえば、BankDetails)と1つの編集不可ペイロード(たとえば、Employee)が含まれます。

- もう1つのタスク・フォーム・アプリケーション(たとえば、個人情報検証タスクの「ValidatePersonalInformation.task」)には、1つの編集可能ペイロード(たとえば、Employee)が含まれます。

タスク・フォームを作成するとき、ウィザードでは、ペイロードEmployeeのADF表を定義するオプションが提示されます。

2. ウィザードを完了し、プロセスをデプロイします。

3. プロセスを起動します。

4. Oracle BPM Worklistにログインします。
個人情報検証タスク(ValidatePersonalInformation.task)があります。

5. タスクを選択します。
Employeeの詳細は変更可能です。

6. 新規レコードを追加し、タスクを承認します。

7. 次に、銀行詳細入力タスク(EnterBankDetails.task)を選択します。Employeeは編集不可のペイロードですが、タスク・フォームでは、Employeeデータに対して「新規挿入」ボタンと「削除」ボタンが表示されます。

8. 「削除」をクリックし、「承認」を選択します。ペイロードが削除されます。

これで、2つのADFタスク・フロー・アプリケーションが作成され、両方にEmployee要素が含まれるが、異なるメタ属性が指定されている(編集可能と編集不可)ことを確認してください。

30.4 タスク・フォームの作成

タスク・フォームは、「タスク・フォームの自動生成」オプション、「タスク・フォーム・ウィザードの起動」オプション、またはヒューマン・タスクのドロップ・ハンドラを使用して作成できます。

- 「タスク・フォームの自動生成」オプションの使用方法は、「自動生成タスク・フォームの作成方法」を参照してください。

- 「タスク・フォーム・ウィザードの起動」オプションの使用方法は、「カスタム・タスク・フォーム・ウィザードを使用したタスク・フォームの作成方法」を参照してください。

- ヒューマン・タスクのドロップ・ハンドラの使用方法については、次の各項を参照してください。

- 「ペイロードを持つ完了済タスク」ドロップ・ハンドラを使用したタスク・フォームの作成方法

- 個別のドロップ・ハンドラを使用したタスク・フォーム・リージョンの作成方法

- タスク・フォームへのペイロードの追加方法

注意:

タスク・フォーム名は、大文字か小文字の英字で始まる必要があります。使用できるのは、英字とゼロ(0)から9までの数字のみです。

30.4.1 自動生成タスク・フォームの作成方法

タスク・フォームを自動生成すると、デフォルト・テンプレートが開き、その後、このテンプレートを変更できます。

自動生成タスク・フォームを作成する手順は、次のとおりです。

1. SOAコンポジット・アプリケーション内でBPELプロセスを開きます。

2. ヒューマン・タスク・アクティビティをダブルクリックし、「編集」をクリックします。

3. 図30-6 に示すように、「.task」エディタで、「フォームの作成」をクリックして「タスク・フォームの自動生成」を選択します。

図30-6 タスク・フォームの作成

4. プロジェクト名とディレクトリ・パスを入力(または、デフォルトをそのまま使用)して、「OK」をクリックします。

デフォルトのフォームが「taskDetails1.jspx」タブに開きます。ApprovalHumanTaskのデフォルトのフォームを図30-7 に示します。

図30-7 ApprovalHumanTaskの自動生成タスク・フォーム

30.4.2 カスタム・ページ・テンプレートにライブラリJARファイルを登録する方法

必要に応じて、カスタム・タスク・フォーム・ウィザードで独自のカスタム・ページ・テンプレートを指定できます。「カスタム・タスク・フォーム・ウィザードを使用したタスク・フォームの作成方法」の説明に従って、カスタム・タスク・フォーム・ウィザードの「名前および定義」ページで「カスタム」を選択し、ライブラリおよび.jspxテンプレートを選択します。

前提条件として、まずOracle JDeveloperにライブラリJARファイルを登録する必要があります。

カスタム・ページ・テンプレートにライブラリJARファイルを作成する手順は、次のとおりです。

1. 「ツール」メニューから、「ライブラリの管理」を選択します。

2. 「新規」をクリックします。

「ライブラリの作成」ダイアログが表示されます。

3. 「クラスパス」をハイライトして、「エントリの追加」をクリックします。

「パス・エントリの選択」ダイアログが表示されます。

4. ライブラリのクラス・パスを選択して、「選択」をクリックします。

「クラスパス」の下にクラス・パスが表示され、「ライブラリ名」フィールドにライブラリJARファイル名が表示されます。選択したライブラリ名が接尾辞.jarで終わることを確認してください。図30-8に詳細を示します。

図30-8 カスタム・ライブラリJARファイル

5. 「デフォルトでデプロイ済」チェック・ボックスを選択します。

6. 「OK」をクリックします。

カスタム・タスク・フォーム・ウィザードの実行時に、「名前および定義」ページで「カスタム」ラジオ・ボタンを選択してから、登録するライブラリおよびテンプレートを選択します。

30.4.3 カスタム・タスク・フォーム・ウィザードを使用したタスク・フォームの作成方法

このウィザードでは、ADFページ・テンプレートおよび標準化されたタスク・リージョンを使用してタスク・フォームを作成できます。次のいずれかのページ・テンプレートを使用できます。

- 次の場所で自動的に提供されるデフォルト・ページ・テンプレート:

[JDeveloper_Home}/jdeveloper/soa/modules/oracle.soa.worklist_11.1.1/adflibWorklistComponents.jar

デフォルトのページ・テンプレートは次のとおりです。

- 非タブ付きのデフォルト・テンプレート: taskDetailsTemplate.jspx

- ペイロードとコメント、添付ファイルおよび履歴セクションが別個のタブに表示されるタブ付きテンプレート: taskDetailsTemplate2.jspx

カスタム・タスク・フロー・ウィザードの「名前および定義」ページで、「パッケージ済」を選択し、「デフォルト」または「タブ付き」のいずれかを選択します。

- ユーザーが定義するカスタム・ページ・テンプレート。カスタム・タスク・フロー・ウィザードの「名前および定義」ページで、「カスタム」を選択し、ライブラリ名およびテンプレート名を選択します。
ページ・テンプレートとそのアーティファクトをADFライブラリJARファイルにパッケージします。これらのJARファイルは、他のOracleライブラリ・コンポーネントと同様にパッケージ化、デプロイ、検出および使用できます。ウィザードで、JAR名およびJARでのテンプレートの場所を指定するように求められます。

ページ・テンプレートでは、ページの特定の属性値など、ページ・レイアウト全体を定義できます。テンプレートを使用してページを作成すると、定義したレイアウトがすべて継承されます。テンプレートのレイアウトを変更すると、テンプレートを使用するすべてのページでレイアウト変更が自動的に反映されます。

ウィザードで使用されるテンプレートでは、次の6つのファセットのコンテンツが生成されます。

- アクション

- 添付ファイル

- 本文

- コメント

- ヘッダー

- 履歴

アクション、ヘッダーおよび本文のファセットでは、表示するコンテンツと属性を選択し、レイアウトを微調整できます。

6つのファセットはすべてデフォルト・ページ・テンプレートで定義されます。カスタム・テンプレートの場合は、これらの正確なファセット名をテンプレートで使用します。テンプレートにこれらのファセットが含まれていない場合は、JSPXファイルでファセットのコンテンツが生成されません。

ファセットの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

カスタム・タスク・フォームを作成する手順は、次のとおりです。

1. SOAコンポジット・アプリケーション内でBPELプロセスを開きます。

2. ヒューマン・タスク・アクティビティをダブルクリックし、「編集」アイコンをクリックします。

ヒューマン・タスク・エディタが表示されます。

3. エディタの上にある「フォーム」をクリックし、「タスク・フォーム・ウィザードの起動」を選択します。

4. プロジェクト名とディレクトリ・パスを入力(または、デフォルトをそのまま使用)して、「OK」をクリックします。図30-9 に示すように、カスタム・フォーム・ウィザードに「名前および定義」画面が表示されます。

図30-9 カスタム・タスク・フォーム・ウィザード: フォーム名および定義

5. 「フォーム名」フィールドに、ウィザードの最後に生成されるフォーム(.jspxファイル)の名前を指定します。名前を指定しない場合は、デフォルト名(Humantasknumber_Form)が指定されます。有効な文字が名前に使用されていることを確認してください。空白は許可されていません。

6. 「タスク・フロー名」(つまり、ウィザードの最後に生成されるADFタスク・フローの名前)を指定します。デフォルトの名前であるHumantasknumber_TaskFlowを受け入れるか、別の名前を指定します。

7. 「ページ・テンプレート」セクションで、次のいずれかを選択します。

- パッケージ済: これを選択してデフォルトのページ・テンプレートのいずれかを使用し、その後、リストから特定のテンプレートを選択します。

- カスタム: ライブラリおよびテンプレートを選択します。ライブラリが表示されていない場合、「ライブラリの管理」をクリックして、「カスタム・ページ・テンプレートにライブラリJARファイルを登録する方法」の手順に従います。

「次へ」をクリックします。「ヘッダー・ページ」が表示されます。

8. 図30-10 に示すように、「ヘッダー・ページ」で次の手順を実行し、「次へ」をクリックします。

- 「Actionsファセット」セクションで、タスク・フォームのタイトル・バーに含める次のオプションを選択します。
他のアクション(メニュー): タスクに対して可能なシステム・アクションがリストされます。たとえば、「情報のリクエスト」、「再割当て」、「期限更新」、「一時停止」、「エスカレート」、「保存」などです。

結果(ボタン): ヒューマン・タスクで定義したタスク・アクション(タスクの結果の設定など)のボタンが表示されます。

- 「Headerファセット」セクションで、表示列の数を入力します。各ヘッダー・ラベルを個別の列に表示する場合は、「選択済」リストに移動するヘッダーの数と同じ数を入力します。ここで「1」と入力し、7つのヘッダーを選択すると、7つすべてのヘッダーが1つの列に表示されます。

- ヘッダー・ラベルを「選択済」リストに移動し、必要に応じて順序を変更します。

図30-10 カスタム・タスク・フォーム・ウィザード: ヘッダーの設定

9. 図30-11 に示すように、「本文」ページの「Bodyファセット」セクションで、次の手順を実行してフォームを設定し、「次へ」をクリックします。

- 本文パネルを説明するタイトルを入力します。

- 行1の列数を入力します。単純なフォームの場合は、ヘッダー列の数として入力したのと同じ数を入力できます。

- 「追加」(+)ボタンをクリックして、行を追加します。新しい行ごとに、列の数を指定することもできます。行ごとに独自の列レイアウトを設定できます。たとえば、各行の列ごとに本文ページを作成して、「行1」、「列1」のようにラベルを付けることができます。

図30-11 カスタム・タスク・フォーム・ウィザード: 本文の設定

注意:

ペイロード・データが表示されていない行または列を指定すると、空のパネル・グループが表示されます。この空のセクションでは、後でデータ・コントロールを使用してコンテンツをフォームに追加できます。

10. 図30-12 に示すように、「行1 列1」ページで、ペイロードの全部または一部を「選択済」リストに移動して、「次へ」をクリックします。

図30-12 カスタム・タスク・フォーム・ウィザード: 本文フィールドの選択

11. 「行1 列1」ページの後の「行n 列n」ページでは、手順10を繰り返して「次へ」をクリックします。

表示される「フッター」ページは、ステップ6で「名前および定義」ページで選択したページ・テンプレート(デフォルト・ページ・テンプレートまたはカスタム・ページ・テンプレートのいずれか)に応じて異なります。

「デフォルト・ページ・テンプレート」を選択した場合は、図30-13 に示される「フッター」ページが表示されます。フッターに含めないコメント、添付ファイルまたは履歴のファセットの選択を解除し、「次へ」をクリックします。デフォルトで、コメント、添付ファイルおよび履歴のファセットはすべて選択されています。

図30-13 カスタム・タスク・フォーム・ウィザード: デフォルト・ページ・テンプレートのフッター・フィールドの選択

12. 図30-14 に示すように、「サマリー」ページで選択内容を確認します。「戻る」をクリックして変更を行うか、「終了」をクリックします。

このフォームはADFタスク・フローとして作成され、プロジェクトに追加されます。

図30-14 カスタム・タスク・フォーム・ウィザード: サマリー

図30-15 (タブ上部)および図30-16 (タブ下部)に示すように、デザイナが初期化され、「form_name.jspx」タブが表示されます。

図30-15 カスタム・タスク・フォーム(タブ上部)

図30-16 カスタム・タスク・フォーム(タブ下部)

30.4.4 「ペイロードを持つ完了済タスク」ドロップ・ハンドラを使用したタスク・フォームの作成方法

ヒューマン・タスクのドロップ・ハンドラは、図30-17 に示すように、デザイナのコンテキスト・メニューに表示されます。

図30-17 タスク・フォームを作成するためのヒューマン・タスクのドロップ・ハンドラ

タスク・フォームの作成には、他のADFドロップ・ハンドラ(図30-17 に示すフォーム、表、ツリーなど)を使用することもできます。標準ADFドロップ・ハンドラの詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。

「ペイロードを持つ完了済タスク」ドロップ・ハンドラを使用してタスク・フォームを作成する手順は、次のとおりです。

1. デザイナで、「taskDetails1_jspx」をダブルクリックします。

2. 「JSFページの作成」ダイアログで、ファイル名およびディレクトリ情報を入力(または、デフォルトをそのまま使用)して、「OK」をクリックします。

3. 「アプリケーション」ウィンドウの「データ・コントロール」パネルで、ヒューマン・タスク・ノード、「getTaskDetails」ノード、「戻る」ノードの順に開きます。

4. 「タスク」アイコンを「taskDetails.jspx」ウィンドウにドラッグします。

5. 「ヒューマン・タスク」を選択し、次に「ペイロードを持つ完了済タスク」を選択します。

6. 図30-18 に示すように、「アクション・バインディングの編集」ダイアログで「OK」をクリックします。

図30-18 アクション・バインディングの編集

7. 図30-19 に示すように、次の「アクション・バインディングの編集」ダイアログではデータ・コレクションが選択されています。「OK」をクリックします。

図30-19 データ・コレクションおよびアクションの選択

図30-20 に示すように、タスク・フォームが表示されます。

図30-20 タスク・フォーム

30.4.4.1 ペイロードを持つ完了済タスク

このオプションでは、前述のタスク・フォーム・コンポーネント(タスク・ヘッダー、タスク履歴、タスク・アクション、およびタスクのコメントと添付ファイル)すべての組合せが作成され、さらにペイロードのインタフェースが作成されます。ペイロード・インタフェースは次のように作成されます。

- すべてのテキスト・ノードはテキスト入力フィールドとして作成されます。

- 要素にmaxOccurs="unbounded"がある場合は、表として表示されます。

- ネストされた表は表示されません。つまり、要素がmaxOccurs="unbounded"でmaxOccurs="unbounded"の子がある場合、子要素は表示されません。

- ネストのレベルが複数ある場合は、個々のセクションをドラッグ・アンド・ドロップして、標準ADFドロップ・ハンドラの1つを使用します。

30.4.4.2 ペイロードのない完了済タスク

このオプションでは、前述のタスク・フォーム・コンポーネント(タスク・ヘッダー、タスク履歴、タスク・アクション、およびタスクのコメントと添付ファイル)すべての組合せが作成されます。

30.4.4.3 電子メールのタスク詳細

このオプションでは、電子メールによる送信時に表示されるADFリージョンが作成されます。図30-21 に示すフォームが生成されます。

図30-21 電子メール通知のタスク・フォーム

詳細は、「電子メール通知の作成」を参照してください。

30.4.4.4 タスク・ヘッダー

タスク・フォームには、すべての標準ヘッダー・フィールドが追加されます。これには、タスク番号とタイトル、BPELプロセスの状態、結果および優先度、タスクの作成者、更新者、申告者またはタスクに割り当てられているユーザーに関する情報が含まれます。ここには、タスク作成、最終更新および有効期限に関する日時も表示されます。ヘッダー・フィールドは、タスク表示の必要性に応じて追加または削除できます。

図30-22 に、ヘッダー情報の例を示します。

図30-22 ヘッダー情報

図30-23 に示すように、ヘッダーにはタスク・アクションに関連するボタンも作成されます。

図30-23 タスク・ヘッダー: タスク・アクションのボタン

30.4.4.5 タスク・アクション

次のタスク・アクションは、「アクション」ドロップダウン・リストから表示されたり、ボタンとして表示されます。表示されるタスクは、タスクの状態(「割当て済」、「完了」など)と、そのタスクを表示するユーザーに付与されている権限によって異なります。たとえば、タスクがグループに割り当てられている場合は、「申告」ボタンのみが表示されます。タスクが申告されると、「却下」や「承認」など他のアクションが表示されます。

最初の3つのカスタム・アクション(「申告」、「終了」および「再開」)は、ボタンとしてタスク・フォームに表示されます。表示されるのは、タスクに適用可能なボタンのみです。他のアクションは、「情報のリクエスト」、「再割当て」、「ルート」の順に「アクション」リストに表示されます。カスタム・アクションの後には、システム・アクションの「取消」、「プッシュバック」、「エスカレート」、「リリース」、「一時停止」および「期限更新」が続き、その後に「保存」ボタンが続きます。これらのアクションの場合、入力するダイアログはありません。

- 申告: グループまたは複数のユーザーに割り当てられているタスクが最初に申告されます。「申告」は、グループまたは複数ユーザー割当ての「タスク・アクション」リストで選択可能な唯一のアクションです。タスクが申告されると、すべての適用可能なアクションがリストされます。

注意:

- FYIタスクが複数のユーザーに送信される場合、タスクを終了するには、最初に「申告」ボタンを選択してタスクを申告する必要があります。

- プッシュバックは、グループ投票ではなく単一承認者で機能するように設計されています。グループ投票(またはパラレル)シナリオを含むステージから別ステージへのプッシュバックは、許可されません。同様に、単一の割当て先からグループ投票(またはパラレル)シナリオにプッシュバックすることもできません。

- 終了: このアクションは、ユーザーはタスクで受信を確認する必要があるが、アクションは実行しないタスク(FYIなど)で使用します。

- 再開: 「一時停止」アクションによって停止したタスクを再開できます。「一時停止」を参照してください。

- 情報のリクエスト: タスク作成者や前の割当て先に詳細情報をリクエストできます。再承認が不要な場合、タスクは次の承認者か、ビジネス・プロセスの次のステップに割り当てられます。

- 再割当て: マネージャは報告先にタスクを再割当てできます。「再割当て」オプションでは、「委任」機能も提供されます。この機能を使用すると、タスクを他のユーザーまたはグループに委任できます。委任されたタスクは、元のユーザーと委任されたユーザーの両方のワークリストに表示されます。委任先ユーザーは、元の割当て先のかわりにタスクを操作でき、そのタスクに対しては元の割当て先と同じ権限を持ちます。

- ルート: 承認者の順序が事前に決定されていない場合や、ワークフローが非定型ルーティングを許可するように設計されている場合は、タスクを非定型方式でルーティングできます。このようなタスクの場合は、「タスクの詳細」ページに「ルート」ボタンが表示されます。「ルーティング」ページから、ルーティングに使用する1人以上のユーザーをルックアップできます。複数の割当て先を指定する場合は、割当て先リストの対象として、単純割当て(ユーザー全員へのグループ割当て)、順次割当てまたはパラレル割当てのいずれかを選択できます。パラレル割当ての場合は、承認に必要な得票率を指定します。

- 取消: タスクをキャンセルできるのは、タスク作成者のみです。オプションのコメントがある場合は、「コメント」領域を使用できます。この場合は、ビジネス・プロセスによって、次の処理内容が決定されます。

- プッシュバック: このアクションは、ワークフロー内で1レベル上のタスクを前の割当て先に送信します。注意: プッシュバックは、グループ投票ではなく単一承認者で機能するように設計されています。グループ投票(またはパラレル)シナリオを含むステージから別ステージへのプッシュバックは、許可されません。同様に、単一の割当て先からグループ投票(またはパラレル)シナリオにプッシュバックすることもできません。

- エスカレート: エスカレートされたタスクはユーザーのマネージャに割り当てられます。オプションのコメントがある場合は、「コメント」領域を使用できます。

- リリース: タスクをリリースすると、他の割当て先が利用できるようになります。グループまたは複数のユーザーに割り当てられているタスクは、他の割当て先が申告できるようになります。

- 一時停止: このアクションは、タスクが再開されるまで、有効期限を延期します。タスクの一時停止と再開を実行できるのは、BPMWorkflowSuspendロールを付与されているユーザーのみです。その他のユーザーは、タスク・フィルタで「前へ」を選択するか、「一時停止」ステータスのタスクを検索することで、このタスクにアクセスできます。タスクを更新する各種ボタンは、一時停止後は無効になります。

- 期限更新: タスクを更新すると、タスクの有効期限が7日間延長されます(デフォルトはP7D)。更新期間は、から制御されます。期限更新は、タスク履歴に表示されます。オプションのコメントがある場合は、「コメント」領域を使用できます。

- 保存: タスクへの変更が保存されます。

タスク・フォームを作成している間は、可能なシステム・アクション・ボタンがすべて表示されますが、ワークリストに表示されるのは、タスク状態に適応していて、ユーザーの権限に対応したアクションのみです。

30.4.4.6 タスク履歴

タスク・アクションの履歴は、「タスクの詳細」ページに表示され、ワークリストにも履歴表として表示されます。履歴には、次のフィールドがあります。

- バージョン番号

- 参加者名: タスクを操作したユーザー

- アクション: たとえば、タスクが承認済または割当て済かどうか

- 更新者: 最後にタスクを更新したユーザーの名前

- アクション日

Oracle BPM Worklistでのタスク履歴の表示方法(履歴スナップショットの取得、今後の参加者のリスト表示、およびフル・タスク・アクションのリスト表示を実行するオプションを含む)は、図32-20 および図32-21 を参照してください。

30.4.4.7 タスクのコメントと添付ファイル

コメントの追跡情報(コメントの日付およびコメント作成者のユーザー名を含む)は、タスクのライフ・サイクル全体を通じて保持されます。

タスクに関連付けられているファイルや参照URLは、すべてのヒューマン・タスク参加者が追加できます。

図30-24 に、「コメント」リージョンと「添付ファイル」リージョンの例を示します。

図30-24 「コメント」リージョンと「添付ファイル」リージョン

30.4.5 個別のドロップ・ハンドラを使用したタスク・フォーム・リージョンの作成方法

複数のリージョンを持つ表示フォームは、図30-25 に示すように、「タスク・ヘッダー」、「タスク・アクション」、「タスク履歴」および「タスク・コメントおよび添付ファイル」ドロップ・ハンドラを個別に使用して作成できます。

図30-25 ヒューマン・タスクのドロップ・ハンドラの使用

「タスク・ヘッダー」では、ヘッダーとタスク・アクションの両方が表示されるため、「タスク・ヘッダー」を使用する際は「タスク・アクション」ドロップ・ハンドラは必要ありません。「タスク・アクション」は、「アクション」ドロップダウン・メニューとボタンは必要だが、ヘッダー詳細は不要の場合に使用します。

各リージョンを個別に作成せずにタスク・フォームを作成するには、「「ペイロードを持つ完了済タスク」ドロップ・ハンドラを使用したタスク・フォームの作成方法」を参照してください。

このタスク・フォームを作成するには、その前に、次を作成する必要があります。

- 新しいアプリケーション、SOAプロジェクトおよびヒューマン・タスク・サービス。

- ヒューマン・タスクに基づいたADFタスク・フロー。詳細は、「ヒューマン・ワークフローのチュートリアルの概要」を参照してください。

個別のドロップ・ハンドラを使用してタスク・フォーム・リージョンを作成する手順は、次のとおりです。

1. デザイナで、「taskDetails1.jspx」をダブルクリックします。

2. 「JSFページの作成」ダイアログで、ファイル名およびディレクトリ情報を入力(または、デフォルトをそのまま使用)して、「OK」をクリックします。

3. 「アプリケーション」ウィンドウの「データ・コントロール」パネルで、ヒューマン・タスク・ノード、「getTaskDetails」ノード、「戻る」ノードの順に開きます。

4. 「タスク」アイコンを「taskDetails.jspx」ウィンドウにドラッグします。

5. 「ヒューマン・タスク」を選択し、次に「タスク・ヘッダー」を選択します。

これにより、図30-26 に示すように、タスク・アクションの「アクション」ドロップダウン・リストとボタンが作成され、さらに、図30-27 に示すように、ヘッダー詳細が作成されます。

図30-26 タスク・フォームの設計: タスク・アクションのボタン

図30-27 タスク・フォームの設計: タスク・ヘッダー

6. 「タスク」アイコンをJSPXデザイナに追加ドラッグします。この作業を行うたびに次のオプションを選択します。

- 「ヒューマン・タスク」、次に「タスク履歴」。

- 「ヒューマン・タスク」、次に「タスク・コメントおよび添付ファイル」。

これで、タスク・フォームには、タスク・アクションのドロップダウン・リストとボタン、タスク・ヘッダー詳細、タスク履歴およびコメントと添付ファイル対する複数のリージョンが設定されます。

タスク・フォームの作成を続行するには、「タスク・フォームへのペイロードの追加方法」の手順1を参照してください。

30.4.6 タスク・フォームへのペイロードの追加方法

ペイロードの追加に加えて、タスク・フォーム・リージョンを作成できます。「個別のドロップ・ハンドラを使用したタスク・フォーム・リージョンの作成方法」の手順1を参照してください。

ペイロードをタスク・フォームに追加する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウから、「ADF Faces」を選択します。

2. 「レイアウト」を展開します。

3. 「パネル・グループ・レイアウト」を「ヘッダー」と「コメント」セクションの間にドラッグします。

4. 「データ・コントロール」パネルで「タスク」を展開し、次に「ペイロード」を展開します。

5. ペイロード・データ・コレクションを「パネル・グループ・レイアウト」領域の左にドラッグします。

「ペイロード」ノードをフォームにドロップするかわりに、「ペイロード」ノードを展開して必要な子要素をフォームにドロップすることもできます。たとえば、VacationRequestペイロードの読取り専用フォームを作成するには、「ペイロード」ノードを展開し、「休暇申請プロセス・リクエスト」ノードをフォームにドラッグして、「フォーム」→「ADF読取り専用フォーム」の順に選択します。

6. 図30-28 に示すように、コンテキスト・メニューから「フォーム」を選択し、次に「ADF読取り専用フォーム」を選択します。

図30-28 タスク・フォームのペイロード・リージョンへのADF読取り専用フィールドの追加

7. 「フォーム・フィールドの編集」ダイアログで、デフォルトをそのまま使用し、「OK」をクリックします。

これで、「詳細」と「履歴」の間のペイロード・リージョンに、読取り専用フィールドが作成されます。

図30-29 に示すように、ペイロード・リージョンが表示されます。

図30-29 タスク・フォームのペイロード・リージョン

図30-30 に示すタスク・フォームは完成しており、デプロイする準備ができています。

図30-30 タスク・フォーム(taskDetails.jspx)

30.4.7 タスク・フォーム作成時の処理内容

設計したフォームは.jspxファイルに保存されます。ファイルの場所は次のとおりです。

JDev_Oracle_Home\mywork\task_form_application_name\project_name\public_html

このタスク・フォームはデプロイできます。「タスク・フローを使用したコンポジット・アプリケーションのデプロイ」を参照してください。

30.5 タスクXSD変更時のデータ・コントロールのリフレッシュ

タスク・メタデータが変更された場合、そのタスク・メタデータに基づく「データ・コントロール」ビューをリフレッシュします(XSD変更はリフレッシュされません)。リフレッシュ機能により、データ・コントロールが再作成されます。図30-31 に「リフレッシュ」オプションを示します。

図30-31 データ・コントロールのリフレッシュ

データ・コントロールをリフレッシュする手順は、次のとおりです。

1. データ・コントロールを右クリックします。

2. 図30-32 に示すように、「定義の編集」オプションを選択し、「データ・コントロールのリフレッシュ」ダイアログを表示します。

図30-32 「データ・コントロールのリフレッシュ」ボタン

30.6 タスク・フロー・アプリケーションの保護

タスク・フローは、コンテナベースのセキュリティを使用して保護できます。詳細は、「アイデンティティ伝播のためのクライアント・アプリケーションの要件」を参照してください。Webセキュリティには、フォームベース認証およびSSOベース認証を使用できます。

通知を電子メールで送信している場合は、/notification/secureによりURLを保護してコンテナベースのセキュリティを使用しないでください。これは、SOA外部では作成できない内部コンテキストを使用してSOA APIがアクセスするためです。URLパターンの内部セキュリティに、/(すべてのURL)および//notificationを含めることはできません。

アイデンティティ伝播に必要な追加ステップはありません。アイデンティティはサーバーEJBに自動的に伝播されます。

30.7 電子メール通知の作成

電子メール通知がヒューマン・タスクの一部として定義されている場合は、その電子メール通知を表示するためにタスク・フォームが使用されます。電子メール通知には、次のオプションがあります。

- デフォルト電子メール通知: ヒューマン・タスク用に作成するタスク・フォームの最初のページを使用します。コンテンツはHTMLベースの電子メールとして送信されます。タスク・フローの画像は、接続切断モードでも通知を表示できるように添付ファイルに含まれています。「ペイロードを持つ完了済タスク」および「ペイロードのない完了済タスク」ドロップ・ハンドラを含むすべてのドロップ・ハンドラが電子メールに適しています。

- カスタム電子メール通知: 「電子メールのタスク表示」ドロップ・ハンドラを使用して、カスタム電子メール通知タスク・ページを作成します。

ヒューマン・タスク定義(.taskファイル)の一部として通知設定を確認するには、「ヒューマン・ワークフローからの通知」を参照してください。

30.7.1 電子メール通知の作成方法

コンテンツとレイアウトを指定したカスタム電子メール通知を送信するには、他のJSPXファイルを作成して、電子メール通知ページを設計します。(ただし、通知のデフォルト・ページを変更なしで使用することもできます。)カスタム通知ページの作成には、カスタムおよび標準ドロップ・ハンドラを使用するか、電子メール通知ドロップ・ハンドラを使用します。また、次の操作を行います。

- ルーターをタスク・フローに追加します。このルーターは、タスク・フローに対して、bpmClientTypeページ・フロー・スコープ値に基づいた制御フローに従って、電子メール通知ページまたはデフォルト・ページのいずれかを送信するように指示します。

- 生成されたインラインCSSを編集して、ページをカスタマイズします。実行時には、追加のCSSは含まれておらず、ADF CSSは使用できません。Oracle SOA Suiteサンプルで使用できる、サンプルnotification-101およびnotification-102を参照してください。

- 画像をHTMLまたはJSFページから直接参照します。(間接参照、たとえば、画像を順番に追加するJSFは許可されません。)

30.7.1.1 ルーターを使用したタスク・フローの作成

ルーターを使用した制御フロー・ケースでは、特定のパラメータに基づいて、特定ページにリクエストを渡すことができます。ヒューマン・タスクに基づいたADFタスク・フローでは、電子メール通知用に特別なページが必要です。この項では、電子メール通知用に特別なページを作成する方法を説明します。

ルーターを使用してタスク・フローを作成する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、タスク・フロー・プロジェクトを開き、「project_name _TaskFlow.xml」をダブルクリックします。

デザイナでXMLファイルが開きます。ダイアグラム・ビューに、「taskDetails1.jspx」アイコンが表示されます。

2. 「コンポーネント」ウィンドウで、「ADFタスク・フロー」を選択し、「View」アイコンをデザイナにドラッグします。

3. アイコンの下にある「view1」をクリックし、電子メール通知ページの名前を入力します。

図30-33 に、「EmailPage」という名前の例を示します。

図30-33 電子メール・ページの作成

4. 「コンポーネント」ウィンドウで、「ルーター」をデザイナにドラッグします。

5. アイコンの下の「router1」をクリックし、ルーター名を入力します。

図30-35 に、「PageRouter」という名前の例を示します。

6. ルーターがコールされることを確認するには、図30-34に示すように、ルーター・アイコンを右クリックし、「アクティビティのマーク」→「デフォルト・アクティビティ」 の順にクリックします。

図30-34 ルーターをデフォルト・アクティビティとしてマーク

7. 「ルーター」、「router_name」、「プロパティ・インスペクタ」タブの順にクリックします。

8. 「デフォルト結果」フィールドにdefaultと入力します。

9. 「追加」をクリックして、「結果」フィールドに電子メール通知ページの名前を入力します。

10. 式ビルダーを使用して、#{pageFlowScope.bpmClientType=="notificationClient"}を「式」フィールドに入力します。

11. 「コンポーネント」ウィンドウで、「制御フロー・ケース」をクリックします。

12. デザイナで、ルーター・ページ・アイコンから「taskDetails1.jspx」にドラッグします。

図30-35 に示すように、制御フローには、「デフォルト」というラベルが自動的に付けられます。

図30-35 制御フローの接続

13. 「コンポーネント」ウィンドウで、「制御フロー・ケース」をクリックします。

14. デザイナで、ルーター・ページ・アイコンから電子メール通知ページ・アイコンにドラッグします。

15. 「制御フロー・ケース」、「email_page_name」、「プロパティ・インスペクタ」タブの順にクリックします。

16. 「結果(自)」リストから、電子メール通知ページの名前を選択します。

図30-36 に、完成した制御フローを示します。

図30-36 電子メール通知の完成した制御フロー

電子メール通知ページの作成を続行するには、「電子メール通知ページの作成」の手順1を参照してください。

30.7.1.2 電子メール通知ページの作成

電子メール通知ページの作成は、タスク・フォームの作成と類似していますが、レイアウトとインライン・スタイルの定義が必要です。設計の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

電子メール通知ページを作成する手順は、次のとおりです。

1. デザイナで、「EmailPage」をダブルクリックします。

2. 「JSFページの作成」ダイアログで、ファイル名およびディレクトリ情報を入力(または、デフォルトをそのまま使用)して、「OK」をクリックします。

デザイナで「EmailPage.jspx」タブが開きます。

3. 「コンポーネント」ウィンドウで、「共通コンポーネント」(画像など)または「レイアウト」コンポーネントのいずれかをデザイナにドラッグします。

4. レイアウト・コンポーネントを選択した場合は、位置合せやその他の詳細を「プロパティ・インスペクタ」タブで指定してください。

図30-37 に、「パネル・グループ・レイアウト」が選択されているときに使用できるレイアウト・フィールドを示します。

図30-37 レイアウトの指定

パネル・グループ・レイアウトの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』を参照してください。

5. 「外観」、「スタイルおよびテーマ」、「動作」、「詳細」、「カスタマイズ」および「注釈」を展開し、図30-38 に示すように、その他の詳細を指定します。

図30-38 レイアウトの指定: 詳細

詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のコンポーネント属性を設定する方法に関する項を参照してください。

6. 「データ・コントロール」パネルで、「ヒューマン・タスク」ノード、「getTaskDetails」ノード、「戻る」ノードの順に展開します。

7. パネル・グループ・レイアウト領域に「タスク」をドラッグします。

8. 図30-39 に示すように、「ヒューマン・タスク」を選択し、次に「電子メールのタスク詳細」を選択します。

図30-39 ヒューマン・タスクのドロップ・ハンドラ

このドロップ・ハンドラには、ヘッダーとともに、インライン・スタイル、ADFを使用するペイロード、およびインライン・スタイルを使用するコメントが含まれます。ペイロードは動的に生成されるため、インライン・スタイルは含まれていません。

通常、各コンポーネントの「ヘッダー」セクションにはインライン・スタイルがあるため、それぞれのコンポーネントの「コンテンツ」セクションでは同じスタイルを使用できます。

9. 「アクション・バインディングの編集」ダイアログで、データ・コレクションを選択し、「OK」をクリックします。

これで、電子メール・タスク・フォームが完了し、デプロイする準備ができました。

30.7.2 電子メール通知ページ作成時の処理内容

電子メール通知ページは、電子メールのメッセージ本文にHTMLコンテンツとして送信されます。ページ上の画像は添付ファイルとしてインラインされています。相対URLは絶対URLに変換されます。

フォームのフィールドに使用されているスタイルが電子メールに対して有効でない場合は、電子メールに通知が正しく表示されない場合があります。このため、生成されたインラインCSSを編集して、ページをカスタマイズする必要がある場合があります。詳細は、「電子メール通知の作成方法」を参照してください。

セキュリティの問題によって、フォームが正しく表示されない場合もあります。詳細は、「タスク・フロー・アプリケーションの保護」を参照してください。

30.8 タスク・フローを使用したコンポジット・アプリケーションのデプロイ

ワークリスト・アプリケーションでタスク・フォームを使用するには、その前に、タスク・フローが含まれているコンポジット・アプリケーションをデプロイする必要があります。タスク・フローを使用してアプリケーションをデプロイするプロセスは、「タスク・フローを使用したコンポジット・アプリケーションのデプロイ方法」で説明するように、SOAコンポジット・アプリケーションのデプロイと基本的に同じです。詳細は、「SOAコンポジット・アプリケーションのデプロイ」を参照してください。

30.8.1 タスク・フローを使用したコンポジット・アプリケーションのデプロイ方法

次の手順を実行するには、アプリケーション・サーバー接続が必要です。

タスク・フローを使用してコンポジット・アプリケーションをデプロイする手順は、次のとおりです。

1. コンポジット・アプリケーション名を右クリックし、「デプロイ」→「application_name」→「デプロイ先」→「application_server_connection」の順に選択します。

接続していない場合は、「新規接続」を選択し、「アプリケーション・サーバー接続」ウィザードを使用します。

2. 「デプロイメント・ターゲットの選択」ダイアログで、サーバー・インスタンスを選択します。

3. 「OK」をクリックします。

30.8.2 タスク・フォームの再デプロイ方法

タスク・フォームを変更して再度デプロイするときは、デプロイメント手順を繰り返します。(タスク・フォーム・アプリケーション名を右クリックし、「デプロイ」→「application_name」→「デプロイ先」→「application_server_connection」の順に選択します。)フォームをアンデプロイするかどうかのメッセージが表示されます。「OK」をクリックし、再度タスク・フォームをデプロイします。

30.8.3 タスク・フローを別のアプリケーションとしてデプロイする方法

タスク・フローを別のアプリケーションとしてSOAコンポジット・アプリケーション外にデプロイする場合は、アプリケーションとプロジェクトをそのタスク・フローのコンテナとして作成します。SOAコンポジット・アプリケーションをデプロイした後に、タスク・フロー・アプリケーションをデプロイします。

30.8.4 非SOAのOracle WebLogic Serverにタスク・フォームをデプロイする方法

この項では、非SOAのOracle WebLogic Serverにタスク・フォームをデプロイする方法について説明します。

30.8.4.1 タスク・フォームをデプロイする前に: ポートの変更

RMIまたはHTTPポートのデフォルト値を使用していない場合は、Oracle JDeveloperのwf_client_config.xmlファイルを開いて、値を変更します。

タスク詳細を非SOAサーバーにデプロイする場合は、wf_client_config.xmlファイルを構成する必要があります。このファイルが作成されてタスク詳細プロジェクトに追加されるのは、タスク詳細をSOAサーバーではない別の管理対象サーバーにデプロイする場合のみです。ファイルの<serverURL>と<rootEndpointURL>には、SOAサーバーのホスト名とポート番号を指定します。

次の例は、wf_client_config.xmlファイルのサンプルを示しています。

<?xml version="1.0" encoding="UTF-8" ?>
xmlns="http://xmlns.oracle.com/bpel/services/client">
<server default="true" name="default">
<localClient>

<participateInClientTransaction>false</participateInClientTransaction>
</localClient>
<remoteClient>
<serverURL>t3://my_host.us.example.com:8001</serverURL>

<initialContextFactory>weblogic.jndi.WLInitialContextFactory</initialContextFactory>

<participateInClientTransaction>false</participateInClientTransaction>
</remoteClient>
<soapClient>

<rootEndPointURL>http://my_host.us.example.com:8001</rootEndPointURL>
</soapClient>
</server>
</workflowServicesClientConfiguration>

30.8.4.2 セッション・トラッキングCookieの一意のCookieコンテキスト・パスの構成

非SOAのOracle WebLogic Serverにタスク・フォームをデプロイする前に、タスク・フォームWebアプリケーションのセッション・トラッキングCookieにアプリケーション固有のCookieトリガー・パスが構成されていることを確認してください。これによって、タスク・フォーム・アプリケーションは一意のセッション・トラッキングCookieを持ち、Oracle BPM WorklistやOracle Business Process Management Workspaceなどの他のOracle BPMアプリケーション用に作成されるセッション・トラッキングCookieによって上書きできません。

セッションCookieトリガー・パスを構成するには、JDeveloperで、Webプロジェクトのweblogic.xmlファイルを開きます。.xmlファイル・エディタで概要タブを選択し、セッションを選択します。「Cookieトリガー・パス」フィールドに、Webアプリケーションのアプリケーション・コンテキスト・パスを入力します。たとえば、アプリケーションのURLがhttp://host:port/my-application-context-rootで、my-application-context-rootがアプリケーション・コンテキスト・ルートの名前である場合、Cookieトリガー・パスを次のように設定します。

/my-application-context-root

30.8.4.3 非SOAのOracle WebLogic Serverへのoracle.soa.workflow.jarのデプロイ

非SOAのOracle WebLogic Serverには、oracle.soa.workflow.jar共有ライブラリが必要です。次にあります。

ORACLE_JDEV_HOME\jdeveloper\soa\modules\oracle.soa.workflow_11.1.1

Oracle WebLogic Server管理コンソールを使用して、JARファイルをデプロイします。

oracle.soa.workflow.jarをデプロイする手順は、次のとおりです。

1. Oracle WebLogic Server管理コンソールに移動します

http://remote_hostname:remote_portnumber/console

2. 「ドメイン構造」領域で、「デプロイメント」をクリックします。

3. 図30-40 に示すように、「インストール」をクリックします。

図30-40 Oracle WebLogic Server管理コンソール: 「デプロイメント」リスト

4. 「パス」フィールドに次のパスを入力し、「次」をクリックします。

ORACLE_JDEV_HOME/jdeveloper/soa/modules/oracle.soa.workflow_11.1.1/oracle.soa.workflow.jar

5. 図30-41 に示すように、同じデプロイメントの名前を維持し、「次」をクリックします。

図30-41 Oracle WebLogic Server管理コンソール: 「アプリケーション・インストール・アシスタント」

6. 「ライブラリとしてデプロイ」オプションを選択し、「終了」をクリックします。

7. 図30-42 に示すように、oracle.soa.workflow(11.1.1,11.1.1)ライブラリが「アクティブ」状態であることを確認します。

図30-42 Oracle WebLogic Server管理コンソール: 「アクティブ」状態のoracle.soa.workflow

「非SOAのOracle WebLogic Serverでの外部JNDIプロバイダの定義」を参照して続行してください。

30.8.4.4 非SOAのOracle WebLogic Serverでの外部JNDIプロバイダの定義

Oracle WebLogic Server管理コンソールを使用して、次のタスクを実行します。

外部JNDIプロバイダを定義する手順は、次のとおりです。

1. 「ドメイン構造」領域で、「サービス」を展開し、「外部JNDIプロバイダ」をクリックします。

2. 「新規」をクリックします。

3. 図30-43 に示すように、「名前」フィールドに「ForeignJNDIProvider-SOA」と入力して「次」をクリックします。

図30-43 外部JNDIプロバイダの作成

4. 「ForeignJNDIProvider-SOA」リンクをクリックします。

5. 次のように入力し、「保存」をクリックします。

- 「初期コンテキスト・ファクトリ」に、weblogic.jndi.WLInitialContextFactoryと入力します。

- 「プロバイダURL」に、t3://soa_hostname:soa_portnumber/soa-infraと入力します。
クラスタ化された環境では、「プロバイダURL」にhttp://soa_hostname:soa_portnumber/soa-infraと入力します。

- 「ユーザー」に、weblogicと入力します。

- 「パスワード」に、weblogicと入力します。

図30-44 に、これらの情報を入力するページを示します。

図30-44 外部JNDIプロバイダの定義

「非SOAのOracle WebLogic Serverでの外部JNDIプロバイダ・リンクの定義」を参照して続行してください。

30.8.4.5 非SOAのOracle WebLogic Serverでの外部JNDIプロバイダ・リンクの定義

Oracle WebLogic Server管理コンソールを使用して、次のタスクを実行します。

外部JNDIプロバイダ・リンクを定義する手順は、次のとおりです。

1. 「ドメイン構造」領域で、「サービス」を展開し、「外部JNDIプロバイダ」をクリックします。

2. 「ForeignJNDIProvider-SOA」リンクをクリックします。

3. 「リンク」タブをクリックします。

4. 「新規」をクリックします。

図30-45 に、「リンク」タブを示します。

図30-45 外部JNDIプロバイダ・リンクの定義: 「リンク」タブ

5. 次のように入力し、「OK」をクリックします。

- 「名前」に、RuntimeConfigServiceと入力します。

- 「ローカルJNDI名」に、RuntimeConfigServiceと入力します。

- 「リモートJNDI名」に、RuntimeConfigServiceと入力します。

図30-46 に、これらを入力するページを示します。

図30-46 外部JNDIプロバイダ・リンクの定義: リンクのプロパティ

6. 次のように入力し、「OK」をクリックします。

- 「名前」、「ローカルJNDI名」、「リモートJNDI名」に、ejb/bpel/services/workflow/TaskServiceBeanと入力します。

- 「名前」、「ローカルJNDI名」、「リモートJNDI名」に、ejb/bpel/services/workflow/TaskMetadataServiceBeanと入力します。

- 「名前」、「ローカルJNDI名」、「リモートJNDI名」に、TaskReportServiceBeanと入力します。

- 「名前」、「ローカルJNDI名」、「リモートJNDI名」に、TaskEvidenceServiceBeanと入力します。

- 「名前」、「ローカルJNDI名」、「リモートJNDI名」に、TaskQueryServiceと入力します。

- 「名前」、「ローカルJNDI名」、「リモートJNDI名」に、UserMetadataServiceと入力します。

「bpm-services.jarに対する権限付与を含める方法」を参照して続行してください。

30.8.4.6 bpm-services.jarに対する権限付与を含める方法

bpm-services.jarに対する権限付与を含めるには、system-jazn-data.xmlファイルを編集し、非SOAのOracle WebLogic Serverを再起動します。

bpm-services.jarに対する権限付与を含める手順は、次のとおりです。

1. ドメイン・ディレクトリ「soa-infra」に移動し、次の場所に移動して、system-jazn-data.xmlファイルを検索します。

ORACLE_WEBLOGIC_INSTALL/user_projects/domains/your_domain_name/config/fmwconfig

2. system-jazn-data.xmlに、次の権限付与を追加します。(全部または一部の権限付与が存在する場合は、欠落している部分のみ追加します)。

<grant>
<grantee>
<codesource>
<url>file: ORACLE_JDEV_HOME/jdeveloper/soa/modules/oracle.soa.workflow_
11.1.1/bpm-services.jar</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>VerificationService.createInternalWorkflowContext</name>
</permission>
<permission>
<class>oracle.security.jps.service.credstore.CredentialAccessPermission
</class>
<name>credstoressp.credstore.BPM-CRYPTO.BPM-CRYPTO</name>
<actions>read,write</actions>
</permission>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>IdentityAssertion</name>
<actions>*</actions>
</permission>
</permissions>
</grant>

3. 非SOAのOracle WebLogic Serverを再起動します。

「アプリケーションのデプロイ」を参照して続行してください。

30.8.4.7 アプリケーションのデプロイ

タスク・フォームを含むアプリケーションは、他のアプリケーションをデプロイする方法と同じ方法で非SOAのOracle WebLogic Serverにデプロイします。アプリケーション・サーバー接続を設定するときは、非SOAサーバー上のドメイン(「bpm-services.jarに対する権限付与を含める方法」の手順1で指定したドメイン)を指定します。アプリケーションのデプロイの詳細は、「SOAコンポジット・アプリケーションのデプロイ」を参照してください。

30.8.5 タスク・フォームのデプロイ時の処理内容

タスク・フォームがデプロイされると、タスク・メタデータとタスク・フロー・アプリケーションURL間の関連付けが自動的に作成されます。このマッピングを更新するには、Oracle Enterprise Manager Fusion Middleware Controlを使用します。特定のSOAコンポジット・アプリケーションについては、「コンポーネント・メトリック」表のタスク・フロー・コンポーネントにアクセスします。「管理」タブに、タスク・フォームのURIが表示されます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。タスク・フローがHTTPSアクセス用に構成されている場合は、Enterprise Managerでの追加設定が必要になる場合があります。

注意:

タスク・フォームの関連付けが自動的に実行されるためには、SOAサーバーが実行中である必要があります。関連付けが実行されていない場合に、ワークリスト・アプリケーションまたはOracle Business Process Management Workspaceでそのタスクのタスク・フォームにアクセスしようとすると、「このタスクのタスク詳細は見つかりません」というメッセージが表示されます。この場合は、アプリケーションを再起動するか、Oracle Enterprise Managerに移動してタスク・フォームのURLを手動で登録できます。

タスクの操作方法の詳細は、「Oracle BPM Worklistの使用」を参照してください。

注意:

- タスク・フォームが正しく機能するために、常に、タスク・フローがデプロイされているホストの完全名を使用してURLを指定してください。

- Oracle WebLogic Server管理コンソールで以前設定したホスト名とポート番号とは異なるポート番号を持つ別のURLからタスク・フォームにアクセスする場合、タスクの詳細をワークリストに正しく表示するには、Oracle WebLogic Server管理コンソールでフロントエンドのポート番号を変更し、タスク・フォームを再デプロイする必要があります。

30.8.6 タスク・フローのアンデプロイに関する必知事項

タスク・フローのWebアプリケーションがデプロイされると、タスク・フローのURLがデータベースに登録されます。タスクをクリックしてタスク詳細を表示すると、Oracle BPM WorklistにこのURLが表示されます。後でタスク・フローのWebアプリケーションをアンデプロイまたは停止した場合、データベース内のタスク・フローのURLはアンデプロイ時に削除されません。その結果、ワークリスト内のタスクをクリックしてタスク詳細を表示するときに、メッセージ「このタスクでは詳細を使用できません」ではなく「404 見つかりません」エラーが表示されます。「404 見つかりません」エラーを回避するには、Oracle Enterprise Manager Fusion Middleware Controlを使用して、アプリケーション・ホームページからタスク・フロー・アプリケーションをアンデプロイします。

30.9 ワークリストでのタスク・フォームの表示

タスク・フォームは、Oracle BPM Worklistに表示されており、ユーザーが割り当てられたヒューマン・タスクを操作するWebベースのインタフェースです。ユーザーの権限によって特定のアクションが使用可能または不可能となります。

図30-47 に、ワークリスト・アプリケーションの「タスクの詳細」ページに表示されるヘルプ・デスク・リクエスト例のタスク・フォームを示します。

図30-47 ワークリストの「タスクの詳細」ページ

タスク・フォームは、ログイン後にOracle BPM Worklistで使用可能になります。手順は、「ワークリストへのログイン方法」を参照してください。

30.10 電子メール通知でのタスクの表示

図30-48 に、電子メールに表示される電子メール・タスク通知を示します。

図30-48 電子メール・タスク通知

選択可能なアクションとして「解決済」または「未解決」をクリックするか、「ワークリスト・アプリケーション」リンクをクリックすると、ワークリストにログインできます。アクションをクリックすると電子メール作成ウィンドウが表示され、このウィンドウでは、コメントを追加して、電子メールを送信できます。

デフォルトでは、タスク通知のテキストには「ワークリスト・アプリケーション」と書かれていますが、そのテキストと、関連付けられるURLは変更できます。

30.10.1 タスク通知におけるワークリスト・アプリケーションのテキストの変更

デフォルトでは、タスク通知のテキストには「ワークリスト・アプリケーション」と書かれていますが、そのテキストは変更できます。これを変更するには、カスタム・リソース・バンドルを作成し、適切な文字列を変更します。

タスク通知のテキストを変更する手順は、次のとおりです。

1. サンプルのworkflow-110-workflowCustomizationsでWorkflowLabels.propertiesリソース・バンドルを開きます。

2. WorkflowLabels.propertiesファイルで、次の文字列を変更します。

TASK_NOTIF_MSG.WORKLIST_APPLICATION=Worklist Application
TASK_NOTIF_MSG.WORKSPACE_APPLICATION=Workspace Application

リソース・バンドル文字列の変更方法については、workflow-110-workflowCustomizationsのサンプルを参照してください。

3. インスタンスの「ワークフロー・カスタム・クラスパスURL」構成パラメータを更新します。

アプリケーションが動作するために、WorkflowLabels.propertiesファイルをデプロイする必要はありません。かわりに、次のいずれかを行います。

- file:///で始まるURLを使用して適切な場所を指し、ファイル・システム上でホストします。

- oramds:///...で始まるURLを使用し、MDSでファイルをホストします。

30.10.2 タスク通知におけるワークリスト・アプリケーションのURLの変更

タスク通知のテキストを変更する手順は、次のとおりです。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. ナビゲータで、「SOA」フォルダを開きます。

3. 「soa-infra」を右クリックして、「SOA管理」→「ワークフロー構成」→「タスク」タブを選択します。

「ワークフロー・タスク・サービス・プロパティ」ページが表示されます。

4. 「拡張」を展開します。

5. 「ワークリスト・アプリケーションURL」を変更します。たとえば、次のような既存のエントリを変更できます。

http://[HTTP_HOST]:[HTTP_PORT]/integration/worklistapp/TaskDetails?taskId=PC_HW_TASK_ID_TAG

次のように変更できます。

http://[HTTP_HOST]:[HTTP_PORT]/patch/info/page.jspx?taskId=PC_HW_TASK_ID_TAG

ワークリスト・アプリケーションのURLの表示または非表示の詳細は、「通知でのURLの表示方法」を参照してください。

30.11 複数のヒューマン・タスクを含むタスク・フロー・アプリケーションの再利用

複数のヒューマン・タスクを含む単一のタスク・フロー・アプリケーションを再利用できます。この機能を使用するには、すべてのヒューマン・タスクに両方のペイロード要素が含まれている必要があり、さらに、それらの結果が同一である必要があります。

30.11.1 複数のヒューマン・タスクを含むタスク・フロー・アプリケーションの再利用方法

1. TASKFLOW_PROJ_DIR\adfmsrc\hwtaskflow.xmlファイルを開きます。

2. ヒューマン・タスクを追加するたびに、ファイル内(ファイルの最後で</hwTaskFlows>の直前)に次の要素を追加します。

<hwTaskFlow>
<WorkflowName>$TASK_NAME</WorkflowName>
<TaskDefinitionNamespace>$TASK_NAMESPACE</TaskDefinitionNamespace>
<TaskFlowId>$TASK_FLOW_NAME</TaskFlowId>
<TaskFlowFileName>$TASK_FLOW_FILENAME</TaskFlowFileName>
</hwTaskFlow

説明:

- $TASK_NAMEは、.taskファイル内のヒューマン・タスク名(<name>要素の値)に置き換えます。

- $TASK_NAMESPACEは、.taskファイル内のヒューマン・タスクのネームスペース(要素<taskDefinition>の属性targetNameSpaceの値)に置き換えます。

- $TASK_FLOW_NAMEは、既存の<hwTaskFlow>/<TaskFlowId>要素をコピーします。

- $TASK_FLOW_FILENAMEは、既存の<hwTaskFlow>/<TaskFlowFileName>要素をコピーします。

30.11.2 様々なアクションを含むタスク・フロー・アプリケーションの再利用方法

様々なタスクのための様々なアクションを含む単一のタスク・フローを再利用できます。これを行うには、次の手順を実行します。

1. タスクフローを生成するために使用するタスク内のすべてのアクションを定義します。

2. それらのタスクの中で、除外するアクションを無効化します。

31 ヒューマン・ワークフローのチュートリアル

この章では、最初のワークフローを設計する方法を最初から最後まで説明します。

この章の内容は次のとおりです。

- ヒューマン・ワークフローのチュートリアルの概要

- 前提条件

- BPELプロセスを使用したアプリケーションおよびプロジェクトの作成

- ヒューマン・タスク・サービス・コンポーネントの作成

- ヒューマン・タスクの設計

- ヒューマン・タスクとBPELプロセス・サービス・コンポーネントの関連付け

- タスク・フォームのプロジェクトの作成

- タスク・フォームのデプロイ

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

- SOAコンポジット・アプリケーションのデプロイ

- プロセス・インスタンスの開始

- Oracle BPM Worklistでのタスクの操作

- その他のチュートリアル

31.1 ヒューマン・ワークフローのチュートリアルの概要

このチュートリアルで開発するアプリケーションは、次のユースケースに基づいています。

- 従業員は休暇申請を提出します

- マネージャは休暇申請を承認または却下します

- 従業員は、自分の申請が承認または却下された通知を受け取ります

このチュートリアルでは、新しいアプリケーションとSOAプロジェクトを作成する方法と、承認または却下のために休暇申請をマネージャに送信するヒューマン・タスクを設計する方法について説明します。

結果としてSOAコンポジット・アプリケーションには、次のコンポーネントが含まれます。

- BPELプロセス

- ヒューマン・タスク。従業員が提出した休暇申請を承認します。

また、Oracle ADFベースのタスク・フォームの作成方法についても説明します。Oracle ADFベースのタスク・フォームを使用して、アプリケーションがデプロイされて実行されたときに、エンド・ユーザーが休暇申請の操作を行えるようにします。Oracle ADFベースのタスク・フォームを作成するには、新しいアプリケーションと新しいプロジェクトを作成する必要があります。

このチュートリアルでは、次のタスクをガイドします。

- の使用

- ヒューマン・タスク・エディタの使用

- Oracle BPELデザイナを使用した単一承認ワークフローのモデリング

- Oracle ADFベースのOracle BPM Worklistの作成

- Oracle BPM Worklistを使用したタスクの表示および応答

31.2 前提条件

このチュートリアルでは、次の内容を前提にしています。

- Oracle SOA Suiteは、SOAインフラストラクチャが構成されているホストにインストールされています。

- BPELアクティビティやパートナ・リンクなどの基本的なBPEL構成要素と、基本的なXPath関数について理解しているユーザーを対象にしています。このユーザーは、とOracle BPELデザイナ(BPELプロセスを設計およびデプロイするための環境)についても理解している必要があります。

次の構文を使用して、VacationRequest.xsdというファイルを作成します。このファイルには、休暇申請と後続のレスポンスに対するスキーマが含まれています。

<schema attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http://xmlns.oracle.com/VacationRequest"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="VacationRequestProcessRequest">
<complexType>
<sequence>
<element name="creator" type="string"/>
<element name="fromDate" type="date"/>
<element name="toDate" type="date"/>
<element name="reason" type="string"/>
</sequence>
</complexType>
</element>
<element name="VacationRequestProcessResponse">
<complexType>
<sequence>
<element name="result" type="string"/>
</sequence>
</complexType>
</element>
</schema>

注意:

VacationRequest.xsdファイルは、チュートリアルworkflow-100-VacationRequestの一部としてダウンロードすることもできます。このチュートリアルと他のチュートリアルのダウンロードの詳細は、「その他のチュートリアル」を参照してください。

31.3 BPELプロセスを使用したアプリケーションおよびプロジェクトの作成

BPELプロセスを使用してアプリケーションおよびプロジェクトを作成する手順は、次のとおりです。

1. Oracle JDeveloperを起動します。「ファイル」メイン・メニューから、「新規」→「アプリケーション」→「SOAアプリケーション」を選択します。

「OK」をクリックします。

2. 「アプリケーション名」フィールドにVacationRequestと入力し、「次へ」をクリックします。

3. 「プロジェクト名」フィールドにVacationRequestと入力し、「次へ」をクリックします。

4. 「コンポジット・テンプレート」リストで、BPELプロセスを使用するコンポジットを選択し、「終了」をクリックします。

「BPELプロセスの作成」ダイアログが表示されます。

5. 「名前」フィールドに、VacationRequestProcessと入力します。

「BPELプロセスの作成」ダイアログの下部に移動します。

6. 「入力」フィールドの右側にある「検索」アイコンをクリックします。

「タイプ・チューザ」ダイアログが表示されます。

7. 右上隅にある「スキーマ・ファイルのインポート」アイコンをクリックします。

「スキーマ・ファイルのインポート」ダイアログが表示されます。

8. 「前提条件」で作成したVacationRequest.xsdファイルを参照して選択します。

図31-1 に示すように、「タイプ・チューザ」ダイアログに戻るまで、「OK」をクリックします。

図31-1 リクエスト要素とレスポンス要素が表示された「タイプ・チューザ」ダイアログ・ボックス

9. 入力要素の「VacationRequestProcessRequest」を選択して、「OK」をクリックします。

「BPELプロセスの作成」ダイアログに戻ります。

10. 「出力」フィールドの右側にある「検索」アイコンをクリックします。

11. 出力要素の「VacationRequestProcessResponse」を選択して、「OK」をクリックします。

図31-2 に示すように、「BPELプロセスの作成」ダイアログに戻ります。

図31-2 BPELプロセス・ダイアログ

12. 残りのすべての設定に対するデフォルト値をそのまま使用し、「OK」をクリックします。

図31-3 に示すように、BPELプロセス・サービス・コンポーネントはSOAコンポジット・エディタに作成されます。「BPELプロセスの作成」ダイアログで「SOAPサービスとして公開」を選択したため、BPELプロセスはサービス・バインディング・コンポーネントに自動的に接続されます。このサービスでは、SOAコンポジット・アプリケーションが外部の顧客に公開されます。

図31-3 SOAコンポジット・エディタのBPELプロセス

サービス・コンポーネントおよびSOAコンポジット・エディタの詳細は、「SOAコンポジット・アプリケーションの開発のスタート・ガイド」を参照してください。

31.4 ヒューマン・タスク・サービス・コンポーネントの作成

ヒューマン・タスク・サービス・コンポーネントを作成し、そのコンポーネントでヒューマン・タスクを設計します。

ヒューマン・タスク・サービス・コンポーネントを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウの「サービス・コンポーネント」セクションから、「ヒューマン・タスク」をにドラッグします。

「ヒューマン・タスクの作成」ダイアログが表示されます。

2. 表31-1 に記載されている詳細を入力します。

表31-1 「ヒューマン・タスクの作成」ダイアログのフィールドと値

フィールド

値

名前

VacationRequestTaskと入力します。

ネームスペース

デフォルトの値をそのまま使用します。

SOAPバインディングを持つコンポジット・サービスの作成

チェック・ボックスを選択しないでください。かわりに、後で「BPELプロセスを使用したアプリケーションおよびプロジェクトの作成」で作成したBPELプロセスに関連付けるヒューマン・タスクを作成します。このBPELプロセスは、自動的にバインドされたWebサービスを使用して作成されています。

3. 「OK」をクリックします。

図31-4 に示すように、BPELプロセスの上部にあるに、「ヒューマン・タスク」アイコンが表示されます。

図31-4 の「ヒューマン・タスク」アイコン

4. 「ヒューマン・タスク」アイコンをダブルクリックします。

ヒューマン・タスク・エディタが表示されます。ヒューマン・タスクの設計を開始します。

31.5 ヒューマン・タスクの設計

ヒューマン・タスクを設計する手順は、次のとおりです。

1. 「タスクのタイトル」フィールドに、Request for Vacationと入力します。

2. 結果のデフォルト値(「APPROVE」および「REJECT」)をそのまま使用します。このタスクの場合、これらの結果は、休暇申請に対するマネージャの操作に2つの選択肢があることを示しています。

3. エディタの左側にある「データ」タブをクリックし、「追加」アイコンをクリックしてタスク・ペイロードを指定します

4. 「文字列パラメータの追加」を選択します。

「タスク・パラメータの追加」ダイアログが表示されます。XSDファイル内の要素を表すパラメータを作成します。これにより、ペイロード・データがワークフロー・タスクで使用できるようになります。

5. 「要素」を選択します。「要素」フィールドの右側にある「検索」アイコンをクリックします。

「タイプ・チューザ」ダイアログが表示されます。

6. 「プロジェクトのスキーマ・ファイル」→「VacationRequest.xsd」→「プロセス」の順に開いて選択し、「OK」をクリックします。図31-5に詳細を示します。

図31-5「タイプ・チューザ」ダイアログ

「ワークリストにより編集可能」チェック・ボックスが選択されていることを確認します。この選択によって、実行時にOracle BPM Worklistからこのパラメータを変更するオプションが提供されます。

「タスク・パラメータの追加」ダイアログで、「OK」をクリックします。

7. エディタの左側にある「割当て」タブをクリックします。

8. 「コンポーネント」ウィンドウの「参加者」セクションから、「単一の参加者」タイプをドラッグして「参加者をここにドロップ」ボックスにドロップします(図31-6 を参照)。休暇申請タスクを操作するのは単一の割当て先であるマネージャのため、このタイプを選択します。

Oracle SOA Suiteには、特定のビジネス・ニーズに対応するために、参加者タイプと呼ばれるすぐに使用できるパターンが複数用意されています。詳細は、「タスクの割当ておよびルーティング」を参照してください。

図31-6 割当ておよびルーティング・ポリシー

9. 追加した参加者をダブルクリックします。

「参加者タイプの編集」ダイアログ・ボックスが開きます。

10. 「参加者名」表で、「追加」アイコンをクリックし、「ユーザーの追加」を選択します。

この参加者タイプは、タスクに対して単独で機能します。

11. 「データ型」列をクリックし、表示されたリストから「式別」を選択します。図31-7に詳細を示します。

このアクションを使用すると、タスクのコンテンツによってタスクを動的に割り当てることができます。休暇申請を提出している従業員は、このタスクに渡されたパラメータ(「BPELプロセスを使用したアプリケーションおよびプロジェクトの作成」でインポートしたXSDファイル内のcreator要素)から取得されます。このタスクは、その従業員のマネージャに自動的にルーティングされます。

図31-7 「データ型」列での「式別」の選択

12. 「値」列で、「参照」アイコン(...)をクリックして、「式ビルダー」ダイアログを起動します。

13. 「関数」セクションのドロップダウン・リストで、「アイデンティティ・サービス関数」を選択します。

14. 「getManager」を選択します。この関数によって、休暇申請タスクを作成したユーザーのマネージャが取得されます。

15. 「関数」セクション上部にある「式に挿入」をクリックします。関数のカッコ内にカーソルを置きます。

16. 「スキーマ」セクションで、「task:task」→「task:payload」→「ns1:VacationRequestProcessRequest」→「ns1:creator」の順に展開します。

ここで、ns1はこの例のネームスペースであり、ユーザーのネームスペースとは異なる場合があります。

17. 「式に挿入」をクリックします。

「式ビルダー」ダイアログの「式」セクションに、XPath式が表示されます。図31-8に詳細を示します。

図31-8 XPath式

18. 「OK」をクリックして、「式ビルダー」ダイアログを閉じます。「OK」を再度クリックして、「参加者タイプの追加」ダイアログを閉じます。

19. 「ファイル」メニューから「すべて保存」を選択します。

31.6 ヒューマン・タスクとBPELプロセス・サービス・コンポーネントの関連付け

ヒューマン・タスクを「BPELプロセスを使用したアプリケーションおよびプロジェクトの作成」で作成したBPELプロセスに関連付けます。

ヒューマン・タスクとBPELプロセス・サービス・コンポーネントを関連付ける手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「composite.xml」をダブルクリックします。

2. で、「VacationRequestProcess」BPELプロセス・サービス・コンポーネントをダブルクリックします。

BPELプロセスがOracle BPELデザイナに表示されます。

3. 「コンポーネント」ウィンドウで、「SOAコンポーネント」を開きます。

4. 「receiveInput」receiveアクティビティの下に、「ヒューマン・タスク」をドラッグ・アンド・ドロップします。アクティビティをダブルクリックします。

「Human Task」ダイアログが表示されます。

5. 「タスク定義」リストから、作成した「VacationRequestTask」タスクを選択します(現在表示されていない場合)。

ダイアログが図31-9 に示すようにリフレッシュされ、他のフィールドが表示されます。

図31-9 「Human Task」ダイアログ

6. 図31-10 に示すように、「BPEL変数」列で「参照」アイコン(...)をクリックします。

図31-10 BPEL変数のエントリ

「タスク・パラメータ」ダイアログが表示されます。

7. 「タイプ」リストで「変数」を選択します。

8. 「プロセス」→「変数」→「inputVariable」→「payload」→「ns1:VacationRequestProcessRequest」の順に展開します。図31-11に詳細を示します。

図31-11 変数の選択

「OK」をクリックします。

9. 「OK」をクリックして「ヒューマン・タスク」ダイアログを閉じます。

図31-12 に示すように、ヒューマン・タスク・アクティビティが表示されます。

図31-12 Oracle BPELデザイナのヒューマン・タスクおよびパートナ・リンク

10. SOAコンポジット・エディタに戻ります。BPELプロセス・サービス・コンポーネントとヒューマン・タスク・サービス・コンポーネントが自動的に接続されていることに注意してください。図31-13に詳細を示します。「ファイル」メニューから「すべて保存」を選択します。

図31-13 SOAコンポジット・エディタ

31.7 タスク・フォームのプロジェクトの作成

タスク・フォームのプロジェクトを作成します。これは、ヒューマン・タスクを作成したプロジェクトとは別のプロジェクトです。

タスク・フォームのプロジェクトを作成する手順は、次のとおりです。

1. 「VacationRequestTask」ヒューマン・タスクをダブルクリックします。

ヒューマン・タスク・エディタが表示されます。

2. 上部の「フォーム」メニューから、「タスク・フォームの自動生成」を選択します。図31-14に詳細を示します。

図31-14 タスク・フォームの作成

「プロジェクトの作成」ダイアログが表示されます。

3. 「プロジェクト名」フィールドに、VacationRequestTaskFlowと入力し、「OK」をクリックします。

4. 「ファイル」メイン・メニューから、「すべて保存」を選択します。

31.8 タスク・フォームのデプロイ

タスク・フォームをデプロイする手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「VacationRequestTaskFlow」プロジェクトを右クリックして「デプロイ」→「VacationRequestTaskFlow」の順に選択します。

2. デプロイメント・ウィザードの各ページの指示に従い、タスク・フォームをデプロイします。

タスク・フォームがデプロイされます。

デプロイメントの詳細は、「Oracle JDeveloperでのSOAコンポジット・アプリケーションのデプロイ」を参照してください。

3. Oracle BPM Worklistに戻ります。

4. Oracle BPM Worklistの下部に、タスク・フォームが表示されることに注意してください。

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

Oracle SOA Suiteがインストールされ、SOAインフラストラクチャで構成されたアプリケーション・サーバーへの接続を作成します。ここでは、Oracle WebLogic Serverへの接続を作成する方法について説明します。IBM WebSphere Serverなどの他のアプリケーション・サーバーへの接続を作成する方法は、『Oracle Fusion Middleware Oracle Identity and Access Managemenサードパーティ・アプリケーション・サーバー・ガイド』を参照してください。

アプリケーション・サーバー接続を作成する手順は、次のとおりです。

1. 「ファイル」メイン・メニューから、「新規」→「接続」→「アプリケーション・サーバー接続」を選択します。

「OK」をクリックします。

2. 「接続名」フィールドに、接続名を入力します。

3. 「接続タイプ」リストで「WebLogic 10.3」を選択します。

「次へ」をクリックします。

4. 「ユーザー名」フィールドに、weblogicと入力します。

5. 「パスワード」フィールドに、アプリケーション・サーバーに接続するためのパスワードを入力します。

「次へ」をクリックします。

6. SOAインフラストラクチャで構成されているアプリケーション・サーバーのホスト名を入力します。

7. 「WebLogicドメイン」フィールドに、Oracle WebLogic Serverドメインを入力します。

「次へ」をクリックします。

8. 「接続のテスト」をクリックします。

成功した場合は、図31-15 に示すメッセージが表示されます。

図31-15 接続の成功

9. 「終了」をクリックします。

10. 「ファイル」メニューから「すべて保存」を選択します。

31.10 SOAコンポジット・アプリケーションのデプロイ

接続を作成したアプリケーション・サーバーにデプロイします。

SOAコンポジット・アプリケーションをデプロイする手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「VacationRequest」プロジェクトを右クリックして「デプロイ」→「VacationRequest」の順に選択します。

2. デプロイメント・ウィザードの各ページの指示に従い、プロジェクトをデプロイします。

プロジェクトがデプロイされます。

デプロイメントの詳細は、「Oracle JDeveloperでのSOAコンポジット・アプリケーションのデプロイ」を参照してください。

31.11 プロセス・インスタンスの開始

プロセス・インスタンスを開始するために「Webサービスのテスト」ページにアクセスする方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

31.12 Oracle BPM Worklistでのタスクの操作

Oracle BPM Worklistでタスクを解決する手順は、次のとおりです。

1. Oracle BPM Worklistに移動します。

http://hostname:7001/integration/worklistapp

2. Oracle BPM Worklistにログインします。

3. タスクを解決します。

31.13 その他のチュートリアル

休暇申請のユースケースに加えて、他のチュートリアルもOracle SOA Suiteサンプルから入手できます。

表31-2 に、複数のサンプルの概要を示します。すべてのサンプルは、ワークリスト・アプリケーションとワークフロー通知の使用を説明しています。サンプルの完全なリストについては、このURLを参照してください。

表31-2 エンドツーエンドの例

サンプル

説明

名前

デモ・コミュニティ・シード・アプリケーション

デモ・コミュニティのシードを実行します。他のすべてのワークフロー・サンプルの前提条件となります。

workflow-001-DemoCommunitySeedApp

休暇申請

承認または却下のため、マネージャに割り当てられる休暇申請を提出するサンプルを提供しています。また、このサンプルは、休暇申請のOracle ADFタスク・フォームを作成して、タスクを操作する方法を説明しています。

workflow-100-VacationRequest

売上げ見積り要請

多重タスクに関連する複雑なワークフローのサンプルを提供しています。

workflow-102-SalesQuote

契約承認

契約を承認するサンプルを提供しています。このサンプルは、タスクのデジタル署名を使用します。

workflow-104-ContractApproval

反復設計

設計プロセスの中でワークフロー・タスクが割当て先との間を何度も通過できるサンプルを提供しています。拡張ルーティング・ルールでルーティング動作を実装します。

workflow-106-IterativeDesign

ワークフロー・カスタマイズ

ワークフロー・サービスAPI(タスク属性、ビュー名などのカスタム・リソース文字列など)にカスタマイズを実装する方法を示します。

workflow-110-workflowCustomizations

MLSサンプル

タスク・タイトルに複数の翻訳があるタスクの設定方法を示します。

workflow-114-MLSSample

ワークフロー・イベント・コールバック

ワークフロー・イベント・コールバックの使用方法を示します。タスク・ライフサイクル・イベントで生成されるワークフロー・イベントがOracle Mediatorによって使用されます。

workflow-116-WorkflowEventCallback

ユーザー構成データ・マイグレータ

ユーザー構成(ビュー、マップ済属性など)を、中間エクスポート・ファイルを介して、あるインスタンスから別のインスタンスに移動します。

workflow-117-UserConfigDataMigrator

Javaサンプル

Javaを使用してヒューマン・ワークフローと対話するサンプル各種を提供します。

workflow-118-JavaSamples

32 Oracle BPM Worklistの使用

この章では、ワークリスト・ユーザーや管理者がOracle BPM Worklistを使用する方法、およびワークリスト表示を各国のビジネス・ニーズ、言語、タイムゾーンにあわせてカスタマイズする方法について説明します。

この章の内容は次のとおりです。

- Oracle BPM Worklistの概要

- Oracle BPM Worklistへのログイン

- タスク・リスト・ページのカスタマイズ

- タスクの処理: タスクの詳細ページ

- タスクの承認

- 休暇期間の設定

- ルールの設定

- ワークリスト管理機能の使用

- 通知設定の指定

- マップ済属性 (フレックス・フィールド)の使用

- ワークリスト・レポートの作成

- ローカル言語およびタイムゾーンによるアクセス

- 再利用可能なワークリスト・リージョンの作成

- ワークリスト・アプリケーションでカスタマイズされたアプリケーションを有効化するJavaコード

ワークフロー・サービスによって公開されるAPIの使用方法については、「カスタム・ワークリスト・クライアントの作成」を参照してください。

ヒューマン・ワークフロー問題のトラブルシューティングの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のヒューマン・ワークフローのトラブルシューティングに関する項を参照してください。

32.1 Oracle BPM Worklistの概要

Oracle BPM Worklistを使用すると、ビジネス・ユーザーは自分に割り当てられたタスクにアクセスして操作できます。たとえば、ワークリストから、融資エージェントは融資申請を確認し、マネージャは従業員の休暇申請を承認できます。

Oracle BPM Worklistは、ユーザー・プロファイルに基づいて様々な機能を提供します。標準的なユーザー・プロファイルには、タスク割当て先、監督者、プロセス所有者、レビューアおよび管理者が含まれます。たとえば、ワークリスト・ユーザーは、承認や却下などの結果を提供してタスクを完了することに加えて、ペイロードやビジネス・データの更新、文書やコメントの添付、他のユーザーへのタスクのルーティングも実行できます。監督者やグループ管理者は、ワークリストを使用して、グループに割り当てられたタスクを分析し、そのタスクを適切にルーティングできます。

ユーザーは、ビューや保存済の検索を作成することによって、タスクをフィルタできます。

タスク割当て先は、Oracle BPM Worklistを使用して次の操作を実行できます。

- ワークリスト内のタスクに対して認可されているアクションの実行、共有タスクの獲得およびチェックアウト、個人のTo Doタスクの定義、およびサブタスクの定義を実行できます。

- 様々な基準に基づいてワークリスト・ビューでタスクをフィルタできます。

- 高優先度のタスク、期日の近いタスクなどの標準作業キューを使用できます。作業キューを使用すると、ユーザーは、カスタム・ビューを作成してワークリスト内のタスクのサブセット(高優先度のタスク、24時間以内に期限があるタスク、経費承認タスクなど)をグループ化できます。

- カスタム作業キューを定義できます。

- 別のユーザーのワークリストの一部に対するプロキシ・アクセスを取得できます。

- カスタムの休暇ルールおよび委任ルールを定義できます。

- グループ所有者による、共有タスクのタスク・ディスパッチ・ルールの定義を可能にします。

- 完全なワークフロー履歴と監査証跡を収集できます。

- タスクのためのデジタル署名を使用できます。

図32-1 に、Oracle BPM Worklistを示します。

図32-1 Oracle BPM Worklist: タスク、フォーム、添付およびレポートへのアクセス

ワークリストはタスクのリストです。タスク・フォームでは、タスクの詳細を表示および更新します。Oracle JDeveloperのADFタスク・フローを使用して、タスク・フォームを作成できます。詳細は、「ヒューマン・タスク用のタスク・フォームの設計」を参照してください。

ワークフロー・サービスのクライアントは、ワークフロー・サービスで公開されたAPIを使用して作成できます。このAPIにより、クライアントは、ローカルとリモートのEJB、SOAPおよびHTTPを使用してワークフロー・サービスと通信できるようになります。

32.2 Oracle BPM Worklistへのログイン

表32-1 に、ユーザーに割り当てられた権限に基づいてOracle BPM Worklistで認識される様々なタイプのユーザーを示します。

表32-1 ワークリスト・ユーザー・タイプ

ユーザーのタイプ

アクセス

エンド・ユーザー(ユーザー)

自分または所属グループに割り当てられたタスクを操作し、システム・アクションとカスタム・アクション、ルーティング・ルールおよびカスタム・ビューにアクセスできます。

スーパーバイザ(マネージャ)

自分のエンド・ユーザー・アクセスの他に、報告先のタスク、レポートおよびカスタム・ビューを操作します。

プロセス所有者

自分のエンド・ユーザー・アクセスの他に、プロセスには属しているが他のユーザーに割り当てられているタスクを操作します。

グループ管理者

自分のエンド・ユーザー・アクセスの他に、グループ・ルールと動的割当てを管理します。

ワークフロー管理者

エラー状態のタスク、たとえば再割当てまたは一時停止が必要なタスクを管理します。また、自身のエンド・ユーザーとしてのアクセス以外に、アプリケーションのプリファレンス変更および属性のマッピング、すべてのユーザーまたはグループに対するルール管理が可能です。

割当て先

自分のエンド・ユーザー・アクセスの他に、自分に割り当てられているタスクを操作します。

レビューア

自分のエンド・ユーザー・アクセスの他に、レビューに割り当てられているタスクを操作します。

注意:

複数の認証プロバイダ(たとえば、SSOとフォーム)はサポートされていません。

32.2.1 ワークリストへのログイン方法

ログインするには、Oracle SOA Suiteがインストールされている必要があり、SOAサーバーが実行中である必要があります。詳細は、『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』を参照してください。

サポートされている次のWebブラウザを使用してください。

- Microsoft Internet Explorer 7.x

- Mozilla Firefox 2.x

- Mozilla Firefox 3.x

- Apple Safari

ログインする手順は、次のとおりです。

1. 次に移動します

http://hostname:port_number/integration/worklistapp

- hostnameは、Oracle SOA Suiteがインストールされているホスト・コンピュータの名前です。

- port_numberは、インストール時に使用した番号です。

2. ユーザー名とパスワードを入力します。

管理者としてログインするには、事前にシードされているユーザーを使用できます。アイデンティティ・ストアにデモ・ユーザー・コミュニティをロード済の場合は、jsteinやjcooperなど他のユーザーを使用できます。

ユーザー名とパスワードは、JAZNに指定したユーザー・コミュニティに存在している必要があります。この章内の例で使用されているデモ・ユーザー・コミュニティの組織階層の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

3. 「ログイン」をクリックします。

32.2.1.1 ワークリストにログインするためにweblogicユーザーを有効にする方法

Oracle Internet DirectoryのweblogicユーザーがOracle BPM Worklistにログインするためには、Oracle Internet Directoryオーセンティケータに管理者グループを割り当て、weblogicユーザーをそのグループのメンバーにする必要があります。

weblogicユーザーを有効にするには:

1. LDAPブラウザを使用して、Oracle Internet Directoryにweblogicユーザーを作成します。次のようなusers.ldifファイルがOracle Internet Directoryにインポートされます。

dn: cn=weblogic,cn=Users,dc=us,dc=oracle,dc=com
objectclass: inetorgperson
objectclass: organizationalPerson
objectclass: person
objectclass: orcluser
objectclass: orcluserV2
objectclass: top
sn: weblogic
userpassword: welcome1
uid: weblogic

2. Oracle Internet DirectoryにAdministratorsグループを作成し、このグループにweblogicユーザーを割り当てます。次のようなgroups.ldifファイルがOracle Internet Directoryにインポートされます。

dn: cn=Administrators,cn=Groups,dc=us,dc=oracle,dc=com
objectclass: groupOfUniqueNames
objectclass: orclGroup
objectclass: top
owner: cn=orcladmin,cn=Users,dc=us,dc=oracle,dc=com
uniquemember: cn=weblogic,cn=Users,dc=us,dc=oracle,dc=com

32.2.2 ワークリストへのログイン時の処理内容

アイデンティティ・サービス・ワークフローAPIは、ユーザー名、パスワードおよびレルム・セット(オプション、複数のレルムが組織に定義されている場合)を使用してログインを認証および認可します。管理者がインタフェースに表示されるレルム・ラベルを変更するためにプリファレンスを設定する方法、またはログイン・ページのイメージのソースの場所を変更する方法の詳細は、「ログイン・ページ・レルムのラベルを指定する方法」を参照してください。

図32-2 に、「ホーム」ページの例を示します。

図32-2 Oracle BPM Worklist: 「ホーム」(タスク・リスト)ページ

このページは、ユーザーのロールに応じて、ユーザーに割り当てられたすべてのタスクと作業アイテムの一覧を表示します。たとえば、「ユーザー・タスク」ページと「開始済のタスク」ページはすべてのユーザーがアクセスできます。マイ・スタッフ・ページにはスーパーバイザのみがアクセスでき、「管理タスク」ページにはプロセス・ワークスペース管理者のみがアクセスできます。

図32-3 のように、左端には、「ユーザー・タスク」が選択されているビューのリストがあります。このリストを展開して、次を選択します:

- 特定のビューに、各ビューで開かれているタスクの数が表示されます。特定のビューを選択すると、タスク・カウントが最新の数値にリフレッシュされます。

- プロセス・ワークスペースにデプロイされているアプリケーションのリスト

- 指定したお気に入りのリンクまたはアプリケーション。

タスクでの作業中にこのリストを表示するには、「固定」をクリックします。非表示にするには「固定解除」をクリックします。

図32-3 ビューの選択

表32-2 では、「ホーム」(タスク・リスト)ページのコンポーネントについて説明します。

表32-2 「ホーム」(タスク・リスト)ページのコンポーネント

コンポーネント

説明

「ビュー」リスト

「受信ボックス」、「標準ビュー」、「ユーザー・ビュー」: 詳細は、「ワークリスト・ビューを作成、削除およびカスタマイズする方法」を参照してください。

表示される「受信ボックス」ビューは、ログイン・ユーザーに付与されているロールに応じて異なります。

- すべてのユーザー(ユーザー・ロール)に「ユーザー・タスク」、「開始済のタスク」および「管理タスク」が表示されます。

- マネージャでもあるユーザーには、「ユーザー・タスク」、「開始済のタスク」、「管理タスク」および「スタッフのタスク」の各タブが表示されます。

- 管理者(BPMWorkflowAdmin)でもあるが、マネージャではないユーザーには、「ユーザー・タスク」、「開始済のタスク」、「管理タスク」、「管理」および「エビデンス検索」の各タブが表示されます。

- マネージャであり管理者でもあるユーザーには、すべてのタブ、つまり、「ユーザー・タスク」、「開始済のタスク」、「スタッフのタスク」、「管理タスク」、「管理」および「エビデンス検索」が表示されます。

- workflow.admin.evidenceStore権限があるユーザーには、「エビデンス検索」タブも表示されます。

詳細は、次を参照してください:

- エビデンス検索の詳細は、「デジタル署名が必要なタスクの操作方法」

- 他のユーザーまたはグループのルールの管理方法(管理者として)

ワークリスト・ビュー

-

タスク・ステータス

棒グラフは、現在のビューのタスク・ステータスを示します。詳細は、「タスク・ステータス・グラフのカスタマイズ方法」を参照してください。

表示フィルタ

「割当て先」または「状態」フィールドから検索条件を指定します。使用可能なカテゴリ・フィルタは、選択しているタブに応じて異なります。

- 「ユーザー・タスク」タブの「割当て先」フィルタは、「自分」、「グループ」、「自分および自分のグループ」、「自分(以前)」(以前に作業したタスク)および「自分(確認のみ)」です。「開始済のタスク」タブの割当て先フィルタは、使用できません。「スタッフのタスク」タブの割当て先フィルタは、「報告先」のみです。「管理タスク」タブの割当て先フィルタは、使用できません。

- 「状態」フィルタには、「任意」、「割当て済」、「完了」、「一時停止」、「取消し済」、「期限切れ」、「エラー発生」、「アラート済」および「情報のリクエスト中」が含まれます。

「検索」を使用してキーワードを入力するか、「拡張検索」を使用します。詳細は、「タスクのフィルタ方法」を参照してください。

「アクション」リスト

ヒューマン・タスクに対して定義したグループ・アクション(「申告」)またはカスタム・アクション(「承認」、「却下」など)を選択します。タスクがFYIタスクであっても、「申告」は、グループまたは複数のユーザーに割り当てられているタスクに対して表示されます。タスクを操作する前に、1人のユーザーがタスクを申告する必要があります。タスクに対して可能な他のアクション(システム・アクションなど)は、特定のタスクの「タスクの詳細」ページに表示されます。ここでは、To Doタスクやサブタスクも作成できます。

注意:

- タスクが集約されている場合、集約されたタスクにFYIタスクが含まれていたとしても、「承認」や却下などのアクションのみが表示されます。明示的な確認アクションは提供されません。「承認」または却下が確認アクションとして解釈されます。

- 自動申告を以前に有効にした場合でも「申告」ボタンは有効のままになります。このボタンを使用すると、ユーザーは、タスクをただ承認するのではなく、タスクを申告して作業を継続することができます。

デフォルト列

タイトル: ヒューマン・タスクの作成時に指定したタイトル。パージまたはアーカイブされたプロセス・インスタンスに関連付けられていたタスクは表示されません。

番号: タスクに割り当てられている一意のID番号。

作成者: タスクを作成したユーザー。

割当て済: 対象のタスクが割り当てられた日付。

優先度: ヒューマン・タスクの作成時に指定した優先度。最も高い優先度は1、最低は5です。

タスクの詳細

受信ボックスのタスクを選択すると、タスクの詳細がワークリストの下半分に表示されます。「受信ボックス設定の編集」の「タスクの詳細」ペインを非表示にすることで、同じウィンドウまたは新しいウィンドウで詳細を確認することもできます。タスクを完了すると、次のようになります。

- 完了したタスクの「タスクの詳細」ページが表示されなくなります。

- タスク・リストがリフレッシュされ、残っているタスクのみが表示されます。

- 次のオープンなタスクの詳細が表示されます。

詳細は、「タスクの操作: 「タスクの詳細」ページ」を参照してください。

図32-2 には、「管理」、「レポート」および「プリファレンス」の各リンクも表示されています(右上隅)。表32-3 に、「ホーム」、「管理」、「レポート」および「プリファレンス」の各ページの要約を示します。

表32-3 ワークリストの主要ページのサマリー

ページ

説明

ホーム

表32-2 に示すように、ログイン・ユーザーのタスク・リスト、選択したタスクの詳細、およびタスク操作の開始に必要なすべての機能が表示されます。

管理

使用可能な管理機能は、次のとおりです。

- アプリケーション・プリファレンスの設定

- 属性のマッピング

- エビデンス・ストアの検索

- 承認グループの管理

- タスクの構成

レポート

次のレポートを使用できます。「不参加タスク・レポート」、「タスクの優先度レポート」、「タスクのサイクル・タイム・レポート」、「タスクの生産性レポート」および「タスク時間分布レポート」。詳細は、「レポートの作成方法」を参照してください。

プリファレンス

次のプリファレンス設定が含まれます。

- ユーザーまたはグループに対するルール(休暇ルールを含む)の設定、および休暇期間の設定

- 証明書のアップロード

- ユーザー通知チャネルおよびメッセージ・フィルタの指定

32.2.3 ユーザーがOracle BPM Worklistにログイン中にユーザーの権限を変更した場合の処理内容

Oracle BPM Worklistにログイン中のユーザーの権限をOracle Enterprise Manager Fusion Middleware Controlで変更した場合、その変更はそのユーザーがそれ以降にログインした後でのみ適用されます。2つのアクティブなワークリスト・セッションがあり、同じユーザーがその1つに権限変更前にログインし、もう1つには権限変更後にログインした場合も同様になります。最初のケースでは、ユーザーのログイン中はユーザーの権限変更が有効になりません。2番目のケースでは、ユーザーがワークリスト・アプリケーションの2番目のインスタンスにログインすると、ユーザーの権限変更が有効になります。

32.3 タスク・リスト・ページのカスタマイズ

タスク・リストは、ワークリスト・ビューの追加、表示する列の選択、「タスクの詳細」ペインの表示または非表示の設定、フィルタ基準に基づいたタスクのサブセットの表示など、様々な方法でカスタマイズできます。フェッチするタスクの数を増やすには、タスク・リストの表示領域のサイズを大きくします。

注意:

ヒューマン・タスクを含むSOAコンポジット・アプリケーションをパーティションにデプロイした場合、Oracle BPM Worklist内のパラメータとしてパーティションを使用し、それらのコンポジットに対して作成されたタスクをフィルタ処理することができません。たとえば、特定のパーティションに対応するタスク・タイプを選択することはできますが(同じタスク・タイプでパーティションが異なる)、拡張検索、カスタム・ビュー、カスタム・ルールおよびマップ済属性の各機能ではフィルタ処理が機能しません。たとえば、VacationRequestAppがパーティション1とパーティション2にデプロイされているとします。「拡張検索」を使用して、パーティション1にデプロイされたコンポジットに対応するタスクを選択しようとしても、検索結果にそれらのタスクは表示されません。

32.3.1 タスクのフィルタ方法

図32-4 に、フィルタの各フィールドを示します。

図32-4 フィルタ: 「割当て先」、「ステータス」、「検索」および「拡張検索」

タスクのサブセットを表示するには、次のフィルタ基準に基づいてフィルタを使用します。

- 割当て先
「割当て先」ドロップダウン・リストで、次のものから選択します。

- 自分: ログイン・ユーザーに直接割り当てられているタスクを取得します。

- グループ: 次のものを取得します。

- ログイン・ユーザーが属するグループに割り当てられたタスク

- ログイン・ユーザーに割り当てられたアプリケーション・ロールに割り当てられているタスク

- 複数のユーザー(その中の1人はログイン・ユーザー)に割り当てられているタスク

- 自分および自分のグループ: ユーザーに直接、またはグループ、アプリケーション・ロール、ユーザー・リストのいずれかによって割り当てられた全タスクを取得します。

- 自分(過去): ログイン・ユーザーによって以前に更新または閉じられたタスクを取得します。

- 自分(確認のみ): ログイン・ユーザーがレビューアであるタスクを取得します。

「スタッフのタスク」タブで、「報告先」を選択します。

- 状態: 次の中から選択します。「任意」、「割当て済」、「完了」、「一時停止」(後で再開可能)、「取消し済」、「期限切れ」、「エラー発生」(処理中)、「アラート済」、「情報のリクエスト中」。

- 検索: キーワードを入力して、タスクのタイトル、コメント、識別キー、および指定のフィルタ基準を満たすタスクのフレックス文字列フィールドを検索します。

- 詳細: 詳細な検索フィルタを指定します。

注意:

1つのタスクが複数の報告先に個別に割り当てられている場合は、マネージャが「スタッフのタスク」リストを表示すると、そのタスクが割り当てられている報告先の数と同じ数のタスクのコピーが表示されます。

32.3.1.1 割当て先または状態に基づいてタスクをフィルタ処理する手順

割当て先または状態に基づいてタスクをフィルタ処理するには:

「割当て先」および「状態」リストからオプションを選択します。タスク・リストは、フィルタの選択内容に基づいて自動的に更新されます。

32.3.1.2 キーワード検索に基づいてタスクをフィルタ処理する手順

キーワード検索に基づいてタスクをフィルタ処理する手順は、次のとおりです。

1. キーワードを入力して、タスクのタイトル、コメント、識別キー、および指定のフィルタ基準を満たすタスクのフレックス文字列フィールドを検索します。

2. [Enter]を押すか、「リフレッシュ」をクリックします。

32.3.1.3 拡張検索に基づいてタスクをフィルタ処理する手順

拡張検索に基づいてタスクをフィルタ処理する手順は、次のとおりです。

マップ済属性マッピングが定義済のタスク・タイプを選択すると、マップ済属性のラベルを拡張検索で使用できます。

詳細は、「属性のマップ方法」を参照してください。

1. 「詳細」をクリックします。

2. (オプション)図32-5 および図32-6 に示すように、「検索をビューとして保存」を選択してビュー名を指定し、「表示」タブでその他の情報を指定します。

図32-5 ワークリストの拡張検索: 「定義」タブ

図32-6 ワークリストの拡張検索: 「表示」タブ

表32-4 では、「表示」タブで選択可能な拡張検索のビュー列について説明します。

表32-4 拡張検索: ビュー列

列

説明

開始日

タスクの開始日(To Doタスクで使用)。

タスク定義名

タスク・インスタンスを定義するタスク・コンポーネントの名前。

所有者ロール

タスク・インスタンスを所有しているアプリケーション・ロール(ある場合)。タスク所有者は、アプリケーション・ロール、ユーザーまたはグループのいずれかです。タスクの所有者がアプリケーション・ロールの場合は、このフィールドが設定されます。

更新日

タスク・インスタンスが最後に更新された日付。

コンポジット・バージョン

タスク・インスタンスを定義するタスク・コンポーネントを含むコンポジットのバージョン。

作成者

タスクの作成者の名前。

リクエスト元ユーザー

タスクのリクエスト元ユーザー。

完了したパーセンテージ

タスクが完了したパーセンテージ(To Doタスクで使用)。

所有者グループ

タスク・インスタンスを所有しているグループ(ある場合)。タスク所有者は、アプリケーション・ロール、ユーザーまたはグループのいずれかです。タスクの所有者がグループの場合は、このフィールドが設定されます。

終了日

タスクの終了日(To Doタスクで使用)。

コンポジット

タスク・インスタンスを定義するタスク・コンポーネントを含むコンポジットの名前。

期日

タスクの期日(To Doタスクで使用)。

コンポジット識別名

タスク・インスタンスを定義するタスク・コンポーネントを含むコンポジットの特定のデプロイメントの一意名。

タスク表示URL

タスクの詳細を表示するためのURL。

更新者

タスクを最後に更新したユーザー。

結果

タスクの結果(例: 「承認済」、「却下済」)。このフィールドは、完了したタスク・インスタンスにのみ設定されます。

タスク・ネームスペース

このタスク・インスタンスを定義するタスク・コンポーネントの全バージョンを一意に定義するネームスペース。同じタスク・コンポーネントの異なるバージョンに同じネームスペースを指定することは可能ですが、異なる2つのタスク・コンポーネントに同じネームスペースを指定することはできません。

承認者

タスクの承認者。

アプリケーション・コンテキスト

タスクに関連付けられたアプリケーション・ロール(割当て先、所有者など)が属するアプリケーション。

所有者ユーザー

タスク・インスタンスを所有しているユーザー(ある場合)。タスク所有者は、アプリケーション・ロール、ユーザーまたはグループのいずれかです。タスクの所有者がユーザーの場合は、このフィールドが設定されます。

識別子

(オプション)タスクのカスタムの一意識別子。これは、標準タスク番号に対する追加の一意識別子です。

カテゴリ

タスクのカテゴリ。

取得者

タスクを申告したユーザーの名前(タスクがグループ、アプリケーション・ロールまたは複数のユーザーに割り当てられ、ユーザーによって申告された場合)。

コンポーネント

タスク・インスタンスを定義するタスク・コンポーネントの名前。

元の割当て先ユーザー

タスクを委任するユーザーの名前(ユーザーが別のユーザーにタスクを委任する場合)。

割当て済

このタスクが割り当てられた日付。

パーティション

タスク・インスタンスを定義するタスク・コンポーネントを含むコンポジットが属するドメイン。

タイトル

タスクのタイトル。

数値

タスク・インスタンスを一意に識別する整数。

優先度

タスクの優先度を定義する整数。通常は1から5の数値が使用され、数値が低いほど優先度が高くなります。

割当て先

現在のタスク割当て先(ユーザー、グループまたはアプリケーション・ロール)。

状態

タスク・インスタンスの状態。

作成日

タスク・インスタンスが作成された日付。

有効期限

タスク・インスタンスの有効期限の日付。

カスタム日付1

日付データ型のカスタム・フレックス・フィールド1

カスタム日付2

日付データ型のカスタム・フレックス・フィールド2

カスタム文字列1

文字列データ型のカスタム・フレックス・フィールド1

カスタム文字列2

文字列データ型のカスタム・フレックス・フィールド2

カスタム番号1

数値データ型のカスタム・フレックス・フィールド1

カスタム番号2

数値データ型のカスタム・フレックス・フィールド2

保存済のビューは、図32-7 に示すように、「ユーザー・ビュー」の下の「ビュー」ペインに表示されます。

注意:

ユーザー・ビューを作成する際に、同じコンポジットの複数のバージョンがデプロイされている場合、タスク・タイプで特定のバージョン(たとえばTestCompositeHumanTask2.0)を選択しても、そのバージョンに対応するタスクのみがフィルタ処理されるわけではありません。正しい結果を得るには、タスク・タイプを選択するのではなく、かわりに条件でタスク定義ID列を使用してください。

図32-7 ビューの保存

3. 図32-8 に示すように、割当て先を選択します。

図32-8 ワークリストの拡張検索

4. 図32-9 に示すように、条件(フィルタ)を追加します。

図32-9 タスクの拡張検索に対するフィルタの追加

表32-5 では、使用可能な条件について説明します。

表32-5 拡張検索: 条件

条件

説明

ユーザー条件

-

取得者

タスクを申告したユーザーの名前(タスクがグループ、アプリケーション・ロールまたは複数のユーザーに割り当てられ、ユーザーによって申告された場合)。

承認者

タスクの承認者。

作成者

タスクの作成者の名前。

リクエスト元ユーザー

タスクのリクエスト元ユーザー。

元の割当て先ユーザー

タスクを委任するユーザーの名前(ユーザーが別のユーザーにタスクを委任する場合)。

所有者グループ

タスク・インスタンスを所有しているグループ(ある場合)。タスク所有者は、アプリケーション・ロール、ユーザーまたはグループのいずれかです。タスクの所有者がグループの場合は、このフィールドが設定されます。

所有者ロール

タスク・インスタンスを所有しているアプリケーション・ロール(ある場合)。タスク所有者は、アプリケーション・ロール、ユーザーまたはグループのいずれかです。タスクの所有者がアプリケーション・ロールの場合は、このフィールドが設定されます。

所有者ユーザー

タスク・インスタンスを所有しているユーザー(ある場合)。タスク所有者は、アプリケーション・ロール、ユーザーまたはグループのいずれかです。タスクの所有者がユーザーの場合は、このフィールドが設定されます。

更新者

タスクを最後に更新したユーザー。

拡張条件

-

アプリケーション・コンテキスト

タスクに関連付けられたアプリケーション・ロール(割当て先、所有者など)が属するアプリケーション。

コンポーネント

タスク・インスタンスを定義するタスク・コンポーネントの名前。

コンポジット

タスク・インスタンスを定義するタスク・コンポーネントを含むコンポジットの名前。

コンポジット識別名

タスク・インスタンスを定義するタスク・コンポーネントを含むコンポジットの特定のデプロイメントの一意名。

コンポジット・バージョン

タスク・インスタンスを定義するタスク・コンポーネントを含むコンポジットのバージョン。

パーティション

タスク・インスタンスを定義するタスク・コンポーネントを含むコンポジットが属するドメイン。

タスク表示URL

タスクの詳細を表示するためのURL。

標準条件

-

カテゴリ

タスクのカテゴリ。

識別子

(オプション)タスクのカスタムの一意識別子。これは、標準タスク番号に対する追加の一意識別子です。

数値

タスク・インスタンスを一意に識別する整数。

結果

タスクの結果(例: 「承認済」、「却下済」)。このフィールドは、完了したタスク・インスタンスにのみ設定されます。

完了したパーセンテージ

タスクが完了したパーセンテージ(To Doタスクで使用)。

優先度

タスクの優先度を定義する整数。低い数値ほど優先度が高くなります。通常、1から5の数値が使用されます。

状態

タスク・インスタンスの状態。

タスク定義名

タスク・インスタンスを定義するタスク・コンポーネントの名前。

タスク・ネームスペース

タスクのネームスペース。

タイトル

タスクのタイトル。

時間条件

タスクのカテゴリ。

割当て済

このタスクが割り当てられた日付。

作成日

タスク・インスタンスが作成された日付。

期日

タスクの期日(To Doタスクで使用)。

終了日

タスクの終了日(To Doタスクで使用)。

有効期限

タスク・インスタンスの有効期限の日付。

開始日

タスクの開始日(To Doタスクで使用)。

更新日

タスク・インスタンスが最後に更新された日付。

カスタム条件

-

カスタム日付1

日付データ型のカスタム・フレックス・フィールド1

カスタム日付2

日付データ型のカスタム・フレックス・フィールド2

カスタム文字列1

文字列データ型のカスタム・フレックス・フィールド1

カスタム文字列2

文字列データ型のカスタム・フレックス・フィールド2

カスタム番号1

数値データ型のカスタム・フレックス・フィールド1

カスタム番号2

数値データ型のカスタム・フレックス・フィールド2

5. 複数のフィルタを照合する場合は、「任意」または「すべて」を選択します。

6. 図32-10 に示すように、パラメータ値を追加します。

図32-10 拡張検索

7. このビューの定義またはそのデータを共有するかどうかと、共有するユーザーまたはグループを指定します。

8. 「検索」をクリックします。

基準に従ってタスクがフィルタ処理されたタスク・リストが表示されます。

32.3.2 ワークリスト・ビューを作成、削除およびカスタマイズする方法

図32-11 に示す「ビュー」メニューには、次のものが表示されます。

- 受信ボックス: 使用したフィルタの結果によるすべてのタスクが表示されます。デフォルトでは、すべてのタスクが表示されます。

- 標準ビュー: 標準ビューと自分が定義したビューが表示されます。

- ユーザー・ビュー: 作成したビューが表示されます。

図32-11 ワークリスト・ビュー

ビューを作成、共有およびカスタマイズするには、「ビュー」を使用します。

ワークリスト・ビューを作成する手順は、次のとおりです。

1. 「ビュー」セクションで「ビューの追加」をクリックします。図に示すように、「ユーザー・ビューの作成」ダイアログ・ボックスが表示されます。

2. 次のことを実行するには、図32-12 に示すように、「ユーザー・ビューの作成」ダイアログ・ボックスの「定義」タブを使用します。

- 名前: ビューの名前を指定します。

- 標準ビューに追加: このオプションは管理者のみに適用されます。管理者はこのオプションを選択して、ビューを標準ビューとして作成します。作成された標準ビューは、すべてのワークリスト・ユーザーの「標準ビュー」リストに表示されます。

- 割当て先: 「自分」、「グループ」、「自分および自分のグループ」、「自分(過去)」、「自分(確認のみ)」、「作成者」、「報告先」、「管理者」、「所有者」から選択します。

- 一致: 追加した条件に一致するのが「すべて」か「任意」かを選択します。

- 条件の追加(プラス記号): ビューに適用する条件を選択します。

- ビューの共有: 他のユーザーに、このビューの定義へのアクセス権を付与したり(この場合は、ビュー条件が権限受領者のデータに適用されます)、データ自体へのアクセス権を付与することができます(この場合、権限受領者は、データも含めて権限付与者のワークリスト・ビューを参照できます)。ビューを別のユーザーと共有することは、そのビューに対応する全タスクを他のユーザーに委任することに類似しています。つまり、共有相手のユーザーは自分のかわりにタスクを操作できます。共有ビューは「ユーザー・ビュー」の下に表示されます。

- ユーザー: ビューを共有できるユーザー(権限受領者)を指定します。

- グループ: ビューを共有できるグループを指定します。

図32-12 ワークリスト・ビューの作成

3. 図32-13 に示す「ユーザー・ビューの作成」ダイアログの「表示」タブを使用して、ビューに表示するフィールドをカスタマイズします。

図32-13 ワークリスト・ビューのフィールドの表示

- ビュー列の選択: タスク・リストに表示する列を指定します。特定のタスク・タイプにマップされている標準タスク属性またはマップ済属性を指定できます。デフォルト列は、受信ボックスの列と同じです。

- ソート基準: ソートする列を選択します。

- 次の基準: 2番目にソートする列を選択します。

- 次の基準: 3番目にソートする列を選択します。

- 次の基準: 4番目にソートする列を選択します。

- ソート順: 昇順または降順を選択します。

4. 「OK」をクリックします。
保存済のビューは、「ユーザー・ビュー」の下の「ビュー」パネルに表示されます。

ビューを削除するには、次のステップを実行します。

注意:

管理者が事前にシードされている標準ビューを誤って削除しても、これらのビューは完全に削除された状態のままにはなりません。これらは、サーバーの再起動時に再作成されます。

1. 「ビュー」パネルで、ビューを選択します。

2. 「削除」アイコンをクリックします。

3. 「削除の確認」ダイアログ・ボックスで、ビューを削除することを確認するように求められます。

4. 「はい」をクリックします。ビューが削除されます。

32.3.2.1 ワークリスト・ビューをカスタマイズする手順

ワークリスト・ビューをカスタマイズする手順は、次のとおりです。

1. 「ビュー」ペインで、カスタマイズするビューを選択します。

2. 「ビューの編集」を選択します。「ユーザー・ビューの編集」ダイアログ・ボックスが表示されます。

3. 図32-14 に示すように、「ユーザー・ビューの編集」ダイアログ・ボックスの項目を使用してビューをカスタマイズし、「OK」をクリックします。

図32-14 ワークリスト・ビューのフィールドのカスタマイズ

32.3.3 タスク・ステータス・グラフのカスタマイズ方法

棒グラフには、ステータス別にタスクが表示され、各ステータス・カテゴリのタスク数が示されます。このグラフは、現行ビュー内のフィルタ処理された一連のタスクに適用されます。

タスク・ステータス・グラフをカスタマイズする手順は、次のとおりです。

1. 「編集」アイコンをクリックします。

2. 図32-15 に示すように、表示するステータス状態を追加または削除して、「OK」をクリックします。

図32-15 タスク・ステータス・グラフのカスタマイズ

32.3.4 To Doタスクの作成方法

自分または他のユーザーの最上位レベルのTo Doタスクを作成するには、図32-16 に示す「To Doタスクの作成」ダイアログを使用します。このタスクはビジネス・タスクと関連していません。

図32-16 「To Doタスクの作成」ダイアログ

To Doタスクは、割当て先の「受信ボックス」に表示されます。

他のTo Doタスクまたはビジネス・タスクの子であるTo Doタスクを作成できます。1つのTo Doタスクに作成できるのは、1レベルの子のTo Doタスクのみです。子のTo Doタスクが100%完了すると、その親のTo Doタスクも完了済としてマークされます。親のTo Doタスクが完了すると、ワークフロー・システム内では子のTo Doタスクが100%となります。ただし、親がビジネス・タスクの場合、その子のTo Doは完了済としてマークされません。この場合は、結果を設定して完了する必要があります。To Doタスクを明示的に100%に設定すると、親タスクでの集計はありません。

To Doタスクは、再割当て、エスカレートなどに加えて、削除(論理的な削除)やパージ(物理的な削除)も可能です。親タスクの再割当てやエスカレートなどが、子のTo Doタスクの割当てに影響を与えることはありません。To Doタスクが完了した後は、その完了率を100%未満にリセットできます。

割当てルール(休暇ルールなど)は、To Doタスクに適用されません。また、To Doタスクに対するビジネス・ルールの指定はできません。

To Doタスクを作成する手順は、次のとおりです。

1. 図32-17 に示すように、「アクション」リストから「To-Doタスクの作成」を選択します。

図32-17 To-Doタスクの作成

2. 図32-16 に示す「To Doタスクの作成」ダイアログに詳細を入力して、「OK」をクリックします。

- タスクのタイトル: わかりやすい内容を入力します。

- カテゴリ: わかりやすい内容を入力します。

- 優先度: 1(最高)から5(最低)の間で選択します。

- 完了したパーセンテージ: この属性は、タスクの完了状況を示します。完了すると、この属性に100%が設定されます。

- 開始日: タスクの開始日。開始日は現在の日付である必要はありません。

- 期日: この期日は期限切れではありません。期日を過ぎたタスクも参照できます。

- 割当て先: 自分または他のユーザーを割り当てることができます。

32.3.5 ワークリスト・アプリケーションでのサブタスクの作成方法

サブタスクとは、To Doタスクまたはビジネス・タスクである親タスクの子です。たとえば、注文書に複数の明細項目が含まれ、それぞれに別個の承認プロセスが必要な場合、サブタスクを作成すると便利です。

32.3.5.1 サブタスクの作成に関する必知事項

サブタスクを作成する際、次のような点に注意する必要があります。

- To Doタスクに含められるサブタスクは、1レベルのみです。すべてのTo Doサブタスクが100%完了すると、親To Doタスクも完了としてマークされます。親To Doタスクが完了すると、To Doサブタスクはワークフロー・システム内で100%になります。
親がビジネス・タスクでそのタスクが完了した場合、そのタスクのサブタスクは取り消されます。

- To Doタスクを明示的に100%に設定すると、親タスクでの集計はありません。

- 使用しているOracle Business Process Managementのリリースが11gリリース1 (11.1.1.7.0)より前の場合、サブタスクを作成するタスクのタスク・フォームを再作成する必要があります。ただし、以前のリリースでデプロイされたプロセスは継続して使用できます。
タスク・フォームを再作成しなかった場合、タスク・フォーム自体の「アクション」リストではサブタスクを作成するオプションを選択できません。ただし、「ワークリスト」の上の「アクション」リストから「サブタスクの作成」を選択することによってサブタスクを作成できます。

- BPMNサービス・エンジンの管理者である場合、Oracle Enterprise Manager Fusion Middleware Controlにはサブタスクが表示されないため、注意してください。

サブタスクを作成するには:

1. 「ワークリスト」で、サブタスクを作成するタスクを選択します。

2. 「アクション」リストから「サブタスクの作成」を選択します。

「サブタスクの作成」ダイアログ・ボックスが表示されます。

3. 「サブタスクの作成」ダイアログで、次の点に注意してサブタスクを定義します。

- 「タイトル」は必須フィールドです。

- このサブタスクで使用可能なフォームが複数存在する場合は、「フォーム」フィールドで選択リストが表示されます。そうでない場合は、「フォーム」フィールドにデフォルト・フォームの名前が表示されます。親タスクに関連づけられているものと異なるタスク・フォームを使用できます。

- 使用可能なルーティング・タイプは次のとおりです。

- 単一の承認者

- グループ投票。パラレル・タスクとも呼ばれます。このルーティング・タイプの場合、複数の参加者を入力するよう表示されます。

- 単一承認者のチェーン。順次タスクとも呼ばれます。このルーティング・タイプの場合、複数の参加者を入力するよう表示されます。

- 参加者を指定するには、検索を実行してその結果から選択します。複数のユーザー、グループまたはアプリケーション・ロールを選択できます。

4. サブタスクの指定が完了したら、「サブタスクの作成」ダイアログ・ボックスで「OK」をクリックします。これによってタスク・リストがリフレッシュされます。親タスクを選択すると、「タスクの詳細」ページに「サブタスク」セクションが表示されるようになり、そのタスクについて作成したサブタスクの詳細が示されます。

注意:

- サブタスクについて複数の参加者を指定した場合、「サブタスク」領域には各参加者について別々のアイテムが表示されます。

- 参加者がサブタスクを完了したら、手動でタスクをリフレッシュして、その完了したサブタスクの詳細を表示する必要があります。

32.4 Microsoft Excelへのタスクのエクスポート

選択したビューに基づいて、タスクをExcelにエクスポートできます。

エクスポートによって、選択したビューに表示されているすべての行と列がダウンロードされます。たとえば、「ユーザー・タスク」ビューを選択した場合、16個のタスクがダウンロードされます。「管理タスク」ビューを選択した場合は、図32-18 に示すように、49,694個のタスクがダウンロードされます。

図32-18 タスク・ビュー

32.4.1 Excelへのタスクのエクスポート方法

ログインしているすべてのユーザーがタスクをエクスポートできます。

タスクをエクスポートする手順は、次のとおりです。

1. リストから適切なビューを選択します。

2. 「エクスポート」ボタンをクリックします

3. フォルダの場所を選択し、ダウンロード用のファイル名を入力して「保存」をクリックします。

4. ファイルをExcelで開いてダウンロードされたタスクを表示します。

32.5 タスクの操作: 「タスクの詳細」ページ

タスクの詳細は、インライン(図32-2 の下部セクションを参照)、同じウィンドウまたは新しいウィンドウに表示できます。(「受信ボックス設定の編集」で設定を変更します。)

図32-19 に、「タスクの詳細」ページを示します。

図32-19 「タスクの詳細」ページ

優先度の変更、コメントや添付ファイルの追加など、「タスクの詳細」ページで変更を行った場合は、他の変更を行う前に変更内容を保存する必要があります。

「タスクの詳細」ページには、次のコンポーネントがあります。

- アクション: タスクに対して可能なシステム・アクションがリストされます。たとえば、「情報のリクエスト」、「再割当て」、「期限更新」、「一時停止」、「エスカレート」、「保存」などです。

- アクション・ボタン: ヒューマン・タスクに定義されているカスタム・アクションに関するボタンが表示されます。たとえば、タスクの結果(ヘルプ・デスク・リクエストの場合は「解決済」と「未解決」、融資申請の場合は「承認」と「却下」)を設定するボタンがあります。タスク・イニシエータ、マネージャまたは管理者の場合は、「取消」も表示される場合があります。

- 詳細: 割当て先、タスク作成者、タスク番号、状態、優先度、タスク獲得者および他のマップ済属性など、タスクの属性を表示します。また、タスクの作成、最終更新および有効期限に関する日付も表示します。

- 履歴: タスクの承認順序や更新履歴が表示されます。詳細は、「タスク履歴」を参照してください。
表32-6 に、「タスクの詳細」の「履歴」セクションで使用されるアイコンの意味を示します。

表32-6 タスク・アクションの「履歴」のアイコン

アイコン

説明

非定型ルーティング・シナリオの承認者を表します。

タスクが承認されたことを示します。

FYI参加者を表します。つまり、この参加者は通知タスクを受信するのみで、ビジネス・プロセスはこの参加者のレスポンスを待機しません。参加者がタスクの結果に直接影響を与えることはできませんが、コメントを提供したり添付ファイルを追加できる場合があります。

複数の人が並行して作業することを示します。このパターンは通常、投票で使用されます。

この参加者が管理チェーンに属していることを示します。

参加者が1人のユーザー、1つのグループまたはロールにマッピングされる単純なケースであることを示します。

タスクが未着手であることを示します。

- コメント: ワークフローに参加した様々なユーザーが入力したコメントが表示されます。新規に追加されたコメントやコメンタのユーザー名は、既存のコメントに追加されます。コメントの追跡情報は、タスクのライフ・サイクル全体を通じて保持されます。コメントを追加または削除するには、タスクの更新権限が必要です。

- 添付ファイル: タスクに関連付けられている文書または参照URLが表示されます。これらは通常、ヒューマン・タスクに定義されたワークフロー、またはワークリストを使用して参加者が添付して変更したワークフローに関連付けられています。添付ファイルを追加または削除するには、タスクの更新権限が必要です。添付ファイルを追加する場合は、ファイルの絶対パス名を使用したり、ファイルを参照することができます。

注意:

高可用性のためにサーバーがクラスタ化されている環境では、フェイルオーバーが発生した場合、ファイルのアップロードはサポートされません。アクティブなサーバーが停止した場合、アップロード・プロセスは他のサーバーに引き継がれず、アップロードは失敗します。

コメントおよび添付ファイルは、タスクとサブタスクの間で共有されます。たとえば、To Doタスクを作成してコメントと添付ファイルを追加すると、そのTo Doタスクのサブタスクにも同じコメントと添付ファイルが含まれます。

「タスクの詳細」ページの表示は、設計時にこのページに表示するタスク・フォームの開発に使用したツールによって異なる場合があります。

ユーザーがタスクを参照できるのは、そのタスクが、現在の割当て先(直接的な割当てまたはグループ・メンバーシップによる割当て)、現在の割当て先のマネージャ、作成者、所有者、または以前のアクターとして関連付けられている場合です。

グループ・メンバーシップとロールは、ユーザーのプロファイルによって決定されます。ユーザーの権限は、ロールによって決定されます。ただし、ユーザーが実行できるアクションの正確なセットは、権限とは別に、タスクの状態、カスタム・アクション、および設計時にタスク・フローに対して定義された制限付きアクションによっても変化します。

注意:

制限付きタスクの再割当てなどの特定の関数は、単一のタスクが選択されている場合にのみ使用できます。制限付き再割当てを使用する複数のタスクが選択されている場合、制限付き再割当てアルゴリズムは起動されません。その場合、制限付き再割当てが指定されていなかったかのようにユーザーの完全なリストが返されます。

ユーザーがタスクに対して実行できるアクションは、次のアルゴリズムで決定されます。

1. ユーザーが実行できるアクションのリストは、そのユーザーに付与されている権限に基づいて取得されます。

2. 現在のタスクの状態で実行できるアクションのリストが取得されます。

3. 前述のリストに出現するアクションの結合リストが作成されます。

4. タスクで制限付きアクションとして指定されているアクションが結合リストから除外されます。

結果のアクション・リストは、対象ユーザーのタスク・リスト・ページと「タスクの詳細」ページに表示されます。ユーザーが特定のアクション(申告、一時停止、再割当てなど)をリクエストすると、ワークフロー・サービスでは、リクエストされたアクションが前述のアルゴリズムで決定されたリストに含まれていることを確認します。

前述のアルゴリズムのステップ2では、多くのケースが処理されます。タスクの状態が、最終完了(順序フローですべての承認が終了した状態)、期限切れ、取消し済、エラー発生のいずれかである場合、追加の更新アクションは許可されません。これらの状態の場合は、タスク、タスク履歴およびサブタスク(パラレル・フローの親タスク)を参照できます。タスクが一時停止されている場合、実行可能なアクションは再開または取消のみです。グループに割り当てられているタスクは、なんらかのアクションを実行する前に、申告する必要があります。

注意:

タスクの承認など、「タスクの詳細」ページからタスクを操作した場合は、そのタスクに対する変更内容とともに、変更されていないタスクの詳細データも保存されます。ただし、「アクション」メニューからタスクを操作した場合、変更されていないタスクの詳細は保存されません。

32.5.1 システム・アクション

アクション・バーには、すべてのタスクで使用可能なシステム・アクションがユーザーの権限に基づいて表示されます。表32-7 に、システム・アクションを示します。

表32-7 システム・タスク・アクション

アクション

説明

申告

グループまたは複数のユーザーに割り当てられているタスクは、最初に申告する必要があります。「申告」は、グループまたは複数ユーザー割当ての「タスク・アクション」リストで選択可能な唯一のアクションです。タスクが申告されると、すべての適用可能なアクションがリストされます。

エスカレート

タスクを完了できない場合は、そのタスクをエスカレートし、必要に応じて「コメント」領域にコメントを追加できます。このタスクは、ユーザーのマネージャ(階層内で1レベル上)に再度割り当てられます。

プッシュバック

このアクションは、タスクをワークフロー内で1レベル下の前の割当て先に送信する際に使用します。

プッシュバック・アクションにより、他のすべてのアクションがオーバーライドされます。たとえば、タスクがプッシュバックされた後に再度割り当てられた場合、再割当て先がタスクを承認すると、そのタスクはプッシュバックを実行したユーザーに戻されます。これは予想された動作です。

注意:

- タスクが集約されている場合、プッシュバック・アクションは使用できません。

- プッシュバックは、グループ投票ではなく単一承認者で機能するように設計されています。グループ投票(またはパラレル)シナリオを含むステージから別ステージへのプッシュバックは、許可されません。同様に、単一の割当て先からグループ投票(またはパラレル)シナリオにプッシュバックすることもできません。

再割当て

マネージャは、タスクを報告先に委任できます。

リリース

グループまたは複数のユーザーに割り当てられているタスクを、そのタスクを申告したユーザーが完了できない場合、そのタスクはリリースできます。このタスクは、他の割当て先ユーザーが申告して完了できます。

更新

タスクの期限切れが近づいている場合は、そのタスクを更新し、必要に応じて「コメント」領域にコメントを追加できます。タスクの有効期限は、1週間延長されます。期限更新は、タスク履歴に表示されます。タスクの更新期間は、オプションのパラメータによって管理できます。デフォルト値は、P7D (7日)です。

情報の発行、情報のリクエスト

この2つのアクションは、他のユーザーから詳細情報の提供をリクエストされた場合、またはタスク作成者や前の割当て先に詳細情報をリクエストする場合に使用します。再承認が不要な場合、タスクは次の承認者か、ビジネス・プロセスの次のステップに割り当てられます。

「一時停止」および「再開」

プロセスに関連していないタスクは、一時停止できます。これらのオプションを使用できるのは、BPMWorkflowSuspendロールを付与されているユーザーのみです。他のユーザーは、タスク・フィルタで「前へ」を選択するか、「一時停止」ステータスのタスクを検索することにより、このタスクにアクセスできます。一時停止の期間は無期限です。これは、「再開」を使用してタスクの処理を再開するまで継続されます。

取下げ

タスクの作成者が、そのタスクを継続しない場合(たとえば、休暇申請を取り消す場合)は、タスクを取り消し、必要に応じて「コメント」領域にコメントを追加できます。この場合は、ビジネス・プロセスによって、次の処理内容が決定されます。ホームページで「取消」アクションを使用するには、「作成者」タスク・フィルタを使用します。

開始タスク/停止タスク

ユーザーがタスクの作業を開始または停止することを選択すると、タイム・スタンプが選択したすべてのタスクに割り当てられます。これは、タスクの作業時間の計算に使用されます。たとえば、「startTask」→「stopTask」→「startTask」→「stopTask」→「startTask」→「completeTask」のように、ユーザーは、同じタスクに対して「開始タスク」および「停止タスク」を複数回使用できます。

総作業時間は、これらの時間間隔すべての合計です。

開始タスクおよび停止タスク操作は、「割当て済」または「情報のリクエスト」ステータスのタスクでのみ使用できます。開始タスクおよび停止タスクは、集計済タスクでは使用できません。

32.5.2 タスク履歴

タスク履歴には、ワークフローの参加者が実行したアクションの監査証跡、およびワークフローの様々な時点におけるタスク・ペイロードと添付ファイルのスナップショットが保持されます。タスクの短い履歴には、次のタスクによって作成されたすべてのバージョンが表示されます。

- タスクの開始

- タスクの再開始

- タスクの結果の更新

- タスクの完了

- タスクのエラー

- タスクの期限切れ

- タスクの取消し

- エラー割当て先に対するタスクのアラート

shortHistoryActions要素を変更すると、「短い履歴」リストに次のアクションを追加できます。

- 獲得

- 非定型ルート

- タスクのオート・リリース

- 委任

- エスカレート

- タスク情報のリクエスト

- タスク情報の発行

- ルーティング・スリップのオーバーライド

- 結果の更新およびルート

- プッシュバック

- 再割当て

- リリース

- 更新

- 再開

- 現在の割当てのスキップ

- 一時停止

- 更新

図32-20 に示すように、履歴はタスク・フローのグラフィカル・ビューで表示されます。

図32-20 履歴: グラフィカル・ビュー

図32-21 に示すように、実行したすべてのアクション(コメントの追加など、タスクを変更しないアクションも含む)を表示するには、「フル・タスク・アクション」を選択します。

図32-21 履歴: フル・タスク・アクション

タスク履歴は、次の方法で表示できます。

- タスク・スナップショットの表示

- 将来の承認者の表示

- すべてのタスク・アクションの表示

- タスクの集計

注意:

親タスクの履歴には、そのタスクに含まれるサブタスクの履歴も表示されます。

32.5.3 タスクの操作方法

ヒューマン・タスクが非定型ルーティングを許可するように設計されている場合、または、承認者の順序が事前に決定されていない場合、そのタスクは非定型方式でワーク・リスト内をルーティングできます。このようなタスクに対しては、「タスクの詳細」ページに「ルート」ボタンが表示されます。「ルート」ページから、ルーティングする1人以上のユーザーをルックアップできます。複数の割当て先を指定すると、割当て先のリストを単純割当て(すべてのユーザーにグループ割当て)、順次割当てまたはパラレル割当てのいずれに使用するかを選択できます。

判定などのシナリオに対してパラレル・フロー・パターンが指定されている場合は、パラレル・タスクが作成されます。このパターンでは、パラレル・タスクに共通の親タスクが存在します。この親タスクがユーザーに表示されるのは、そのユーザーがタスクの割当て先、所有者または作成者である場合のみです。パラレル・タスク自体(サブタスク)は、他のすべてのタスクと同じように、タスクが割り当てられているすべてのユーザーが参照できます。親タスクからサブタスクを参照することも可能です。このようなシナリオでは、親タスクの「タスクの詳細」ページに「サブタスクの表示」ボタンが表示されます。「サブタスク」ページには、対応するパラレル・タスクが表示されます。投票シナリオでは、いずれかの割当て先ユーザーがペイロード、コメントまたは添付ファイルを更新した場合、その変更内容を参照できるのはそのタスクの割当て先のみです。

親タスクを参照できるユーザー(パラレル・フロー・パターンの最終レビューアなど)は、サブタスクに移動して、パラレル・フローの参加者によるサブタスクの更新を参照できます。割当て先ユーザーがサブタスクで作業する間、親タスクはサブタスクのコンテナになります。タスク所有者は、親タスクを操作したり承認することはできません。

タスク・リストには、タスクのアクションは表示されません。ユーザーは、タスクの詳細からアクションを実行する必要があります。

ヒューマン・タスクの設定によりパスワードが要求される場合は、タスクを実行する際に、パスワードを指定する必要があります。

注意:

優先度の変更、コメントの追加など、「タスクの詳細」ページで変更を行った場合は、その変更内容を保存する必要があります。タスクに添付ファイルを追加した場合は自動的に保存されます。

タスクを再割当てまたは委任する手順は、次のとおりです。

1. 図32-22 に示すように、「アクション」リストから「再割当て」を選択します。

図32-22 タスクの再割当て

2. 「再割当て」または「委任」を選択します。

「委任」は「再割当て」とは異なり、委任先の権限は委任元の権限に基づいています。この機能は、たとえば、マネージャのアシスタントが使用できます。

3. 図32-23 に示すように、ユーザーまたはグループ名を指定するか、参照します。

図32-23 タスクの再割当て

スーパーバイザは、タスクを任意の報告先にいつでも再割当てできます。

4. チェック・ボックスをクリックして名前を選択し、「OK」をクリックします。

タスクは、複数のユーザーまたはグループに再度割り当てることができます。図32-24 に示すように、割当て先ユーザーの1人がタスクを申告する必要があります。

図32-24 タスクの申告

注意:

タスクの詳細が以前のリリースからアップグレードされている場合、「再割当て」アクションを実行すると、「リクエストに失敗しました」エラーが表示されることがあります。実際には、再割当ては完了しており、もう一度「OK」をクリックすると、ポップアップでタスクが割当て済であることが表示されます。

このエラー・メッセージを表示されないようにするには、タスク・フロー・アプリケーションをOracle JDeveloperで開くことでアップグレードし、その後にタスク・フォームを再デプロイしてください。

32.5.3.1 情報をリクエストする手順

情報をリクエストする手順は、次のとおりです。

1. 図32-25 に示すように、「アクション」リストから「情報のリクエスト」を選択します。

このアクションは、タスク定義で「参加者による他の参加者の招待を許可」設定を有効にしている場合にのみ使用できます。

図32-25 情報のリクエスト

2. 図32-26 に示すように、情報のリクエスト元として過去の承認者を選択するか、ユーザー名を検索します。あるいは、タスクを以前の割当て先にプッシュバックします。

図32-26 過去の承認者または別のユーザーへの情報のリクエスト、またはタスクのプッシュバック

「検索」アイコンを使用してユーザー名を検索すると、図32-27 に示すように、「認証ブラウザ」が表示されます。

図32-27 認証ブラウザ

注意:

マルチテナント環境の場合、ユーザーの検索はユーザー識別子のみで行い、テナント識別子では行わないでください。たとえば、ユーザー識別子がjsteinで、テナント識別子がcompany_name.jsteinの場合、jsteinを使用して検索します。

3. 「OK」をクリックします。

32.5.3.2 タスクをルーティングする手順

注意:

タスクをルーティング可能にする前に、タスク定義を「参加者による他の参加者の招待を許可」に設定する必要があります。

タスクをルーティングする手順は、次のとおりです。

1. 図32-28 に示すように、「タスク・アクション」リストから「非定型ルート」を選択します。

図32-28 非定型ルーティング

2. 図32-29 に示すように、アクションを選択し、ルーティング・オプションを選択します。

図32-29 タスクのルーティング

- 単一の承認者: 単一のユーザーがタスクを操作する場合に使用します。タスクがロールまたは複数ユーザーのグループに割り当てられている場合は、1人のメンバーがタスクを申告して操作する必要があります。

- グループ投票: パラレルで作業する複数のユーザーがアクションを実行する場合(たとえば、雇用に関するフローで複数のユーザーが応募者の採否を票決する)に使用します。図32-30 に示すように、結果が有効になるために必要な得票率(多数決や満場一致など)を指定します。

図32-30 同意情報の指定

- 単一承認者のチェーン: 承認者の順序リストに対して使用します。このリストは、任意のユーザーまたはグループで構成できます。(ユーザーは組織階層に含まれている必要はありません。)

3. 必要に応じて、ルート上の次の参加者のためにコメントを追加します。

4. ユーザー名またはグループ名を指定するか検索し、その名前を「選択済」領域に移動します。

5. 「OK」をクリックします。

32.5.3.3 コメントまたは添付ファイルを追加する手順

コメントまたは添付ファイルを追加する手順は、次のとおりです。

注意:

- ユーザーがタスクのイニシエータの場合、ユーザーのコメントはタスク割当て先のみでなく、すべてのプロセス参加者と共有されます。タスク参加者のみと共有するオプションは使用できません。

- 親タスクに追加されたコメントは、その親のサブタスクでも表示されます。

- 添付ファイルを参照またはアップロードするには、その前に「保存」をクリックして、「タスクの詳細」ページに対してすでに行った変更を必ず保存してください。

- ファイルまたはURL添付を削除した場合、タスクは自動的に更新されません。「アクション」→「保存」の明示的な選択が必要です。そうしないと、添付ファイルは削除されたものとして表示されますが、実際には削除されません。これは予想された動作です。

- 添付ファイルの追加の場合は、「アクション」→「保存」の明示的な選択は不要です。

- URL添付の追加の場合は、「アクション」→「保存」の明示的な選択が必要です。

- 高可用性のためにサーバーがクラスタ化されている環境では、フェイルオーバーが発生した場合、ファイルのアップロードはサポートされません。アクティブなサーバーが停止した場合、アップロード・プロセスは他のサーバーに引き継がれず、アップロードは失敗します。

- ADF接続を使用していて、添付ファイルを追加しようとしたときにプロトコルが見つからないというエラーが表示される場合は、ご使用のconnections.xmlファイルが適切なWSDLファイルと同期していることを確認してください。 connections.xmlファイルは、ADFワークスペースのディレクトリ.adf/META-INF/に配置されています。

1. 「コメント」または「添付ファイル」領域で、「追加」をクリックします。

図32-31 ワークリストのコメントと添付ファイル

2. コメントのテキストを入力し、「OK」をクリックします。コメントは、追加後に削除できません。

コメントには、日付、タイムスタンプおよびユーザー名が追加されます。

3. 添付ファイルの場合は、図32-32 に示すように、ファイル添付かURL添付かを指定して、「OK」をクリックします。

図32-32 ワークリストの添付ファイルの追加

Oracle BPM WorklistでURLファイル(http://www.example.com/technology/products/oem/management_partners/snmpwp6.gifなど)を添付しても、そのファイルは電子メール添付ファイルとして送信されません。かわりに、このファイルは、電子メール通知のタスク詳細にリンクとして表示されます。ただし、デスクトップ・ファイルを添付した場合、そのファイルはタスク通知に個別の添付ファイルとして表示されます。

注意:

マルチバイト文字セット(MBCS)を使用した添付ファイル名はサポートされていません。

最大1998KBの添付ファイルをアップロードできます。この設定は、web.xmlのcontextパラメータを次のように設定することによって変更できます。

<context-param>
<param-name>org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE</param-name>
<param-value>1998</param-value>
</context-param>

ファイルのアップロードの詳細は、Oracle Fusion Middleware Oracle Application Webユーザー・インタフェース開発者ガイドを参照してください。

4. 「タスク・アクション」リストから、「保存」をクリックします。

32.5.4 デジタル署名が必要なタスクの操作方法

ワークリストでは、ヒューマン・タスクで作成された次の署名ポリシーがサポートされています。

- 署名は不要 - 参加者は署名せずにタスクを送信して操作できます。

- パスワードは必須 - 参加者はログイン・パスワードを指定する必要があります。

- デジタル証明書(署名)は必須: 参加者はデジタル証明書を入手した後に、タスクの送信と操作が可能になります。デジタル証明書には、証明書発行者のデジタル署名が記載されているため、誰でも証明書が本物であることを確認できます。参加者の資格証明は、デジタル証明書によって証明されます。これは認証局(CA)が発行します。ユーザー名、シリアル番号、有効期限、証明書所有者の公開鍵のコピー(メッセージとデジタル署名の暗号化に使用)、および証明書発行者のデジタル署名が記載されているため、受信者は証明書が本物であることを確認できます。

署名ポリシーがあるタスクを操作すると、図32-33 に示すように、「署名」ボタンが表示されます。

図32-33 デジタル署名タスク詳細

デジタル署名の保管、およびデジタル署名されたヒューマン・タスクの否認防止には、エビデンス・ストア・サービスを使用します。エビデンス・ストアは、図32-34 に示すように検索できます。

図32-34 エビデンス・ストア

詳細は、「エビデンス・ストア・サービスとデジタル署名」を参照してください。

デジタル署名を指定する手順は、次のとおりです。

1. Oracle BPM Worklistの右上隅にある「プリファレンス」をクリックします。

2. 「証明書」リンクを選択します。

3. 図32-35 に示すように、意思決定の署名に使用する証明書をアップロードします。
証明書を使用してタスクの結果に署名する際は、証明書発行者から発行された1つの証明書のみではなく、証明書チェーン全体をOracle BPM Worklistから.P7B (PKCS7形式)ファイルとしてアップロードする必要があります。チェーン全体はInternet Explorerからエクスポートできます。Mozilla Firefoxでは、チェーンを.P7Bファイルとしてエクスポートできません。この場合は、次の手順を実行できます。

a. Mozilla Firefoxからチェーンを.P12ファイル(秘密鍵も含まれるPKCS12形式)としてエクスポートします。

b. Internet Explorerに.P12ファイルをインポートします。

c. このファイルをInternet Explorerから.P7Bファイルとして再度エクスポートします。

d. Oracle BPM Worklistからこのファイルをアップロードします。

図32-35 証明書のアップロード

証明書をシステムに指定する際は、次の重要な点に注意してください。そうしないと、証明書を使用してタスクに対する決定に署名することができません。

- PKCS7ファイル形式は、バイナリの証明書形式です。スタンドアロンの証明書ファイルをディスクに格納する場合は、このオプションを選択します。

- PKCS12ファイル形式は、キーストア形式です。証明書をキーストア内に格納する場合は、このオプションを選択します。

- 証明書の内容をコピーして貼り付ける場合は、「証明書内容のタイプまたは貼付け」を選択し、BASE64エンコード・テキストをフィールドに貼り付けます。このフィールドには、それ以外の形式の証明書を貼り付けないでください。同様に、証明書をアップロードする場合は、BASE64エンコード証明書をアップロードしないでください。アップロードがサポートされているのは、PKCS12およびPKCS7形式のファイルのみです。

4. Oracle BPM Worklistの右上隅にある「ホーム」リンクをクリックして、タスク・リストに戻ります。

5. 承認または却下するタスクをクリックします。
タスクの詳細が表示されます。

6. 「承認」または「却下」をクリックします。
デジタル署名の詳細が表示されます。

7. 署名ポリシーがあるタスクの場合は、「署名」をクリックします。
テキスト署名レポート・ダイアログが表示されます。

8. 決定の署名に使用する証明書をリストから選択します。

9. 使用するWebブラウザのマスター・パスワードを入力します。

10. 「OK」をクリックします。
Webブラウザでは、選択した証明書を使用して、テキスト署名リクエストの上部に表示される文字列に署名し、選択したアクション(承認または却下)を起動します。ヒューマン・ワークフロー・サービスでは、タスク・ステータスが適切に更新されます。

証明書のアップロード方法と使用方法の詳細は、「エビデンス・ストア・サービスとデジタル署名」を参照してください。

32.6 タスクの承認

表32-8 に、様々なタスク承認者がタスクに対して実行できるアクションのタイプを示します。

表32-8 タスク・アクションと承認者

タスク・アクション

管理者

所有者(+所有者グループ)

割当て先(+割当て先マネージャ+割当て先グループ+プロキシ割当て先)

作成者

レビューア

承認者

獲得(申告)

いいえ

はい

はい

いいえ

いいえ

いいえ

カスタム

いいえ

はい

可[1]

いいえ

いいえ

いいえ

委任

いいえ

いいえ

はい

いいえ

いいえ

いいえ

削除

いいえ

不可[2]

可[2]

可[2]

いいえ

いいえ

エラー

いいえ

いいえ

可[3]

いいえ

いいえ

いいえ

エスカレート

はい

可[4]

はい

いいえ

いいえ

いいえ

情報リクエスト

いいえ

いいえ

はい

いいえ

いいえ

いいえ

情報発行

いいえ

いいえ

はい

いいえ

いいえ

いいえ

ルーティング・スリップのオーバーライド

はい

はい

いいえ

いいえ

いいえ

いいえ

プッシュバック

いいえ

いいえ

はい

いいえ

いいえ

いいえ

パージ

可[2]

可[2]

いいえ

はい

いいえ

いいえ

再割当て

はい

可[5]

可(プロキシ割当て先の場合は不可)

いいえ

いいえ

いいえ

リリース

はい

はい

はい

いいえ

いいえ

いいえ

更新

いいえ

はい

はい

いいえ

いいえ

いいえ

再開

はい

はい

はい

いいえ

いいえ

いいえ

ルート

いいえ

はい

はい

いいえ

いいえ

いいえ

現在の割当てのスキップ

はい

はい

いいえ

いいえ

いいえ

いいえ

一時停止

はい

はい

はい

いいえ

いいえ

いいえ

更新

いいえ

はい

はい

はい

いいえ

いいえ

添付ファイルの更新

はい

はい

はい

はい

はい

いいえ

コメントの更新

はい

はい

はい

はい

はい

いいえ

プロセス履歴の表示

はい

はい

はい

はい

いいえ

いいえ

サブタスクの表示

はい

はい

はい

いいえ

いいえ

いいえ

タスク履歴の表示

はい

はい

はい

はい

はい

はい

取下げ

はい

はい

いいえ

はい

いいえ

いいえ

32.7 休暇期間の設定

休暇期間は、図32-36 に示すように、指定した日付範囲内では自動タスク割当てから削除されるように設定できます。

図32-36 休暇期間の設定

休暇ルールはTo Doタスクに対して実行されません。休暇期間と同期する休暇ルールの設定方法は、「ルールの設定」を参照してください。

休暇期間を作成する手順は、次のとおりです。

1. 「プリファレンス」リンクをクリックします。

「ルール」タブが表示されます。

2. 「休暇期間の有効化」をクリックします。

3. 開始日と終了日を指定します。

4. 「保存」をクリックします。

図32-37 に示すように、休暇期間が有効になります。

図32-37 休暇期間の有効化

32.8 ルールの設定

ルールは、特定のタスク・タイプか、ユーザーまたはグループに割り当てられたすべてのタスクに対して実行されます。図32-38 に、休暇ルールも含めて、ルールを設定する場所を示します(「休暇期間の設定」で説明した休暇期間の設定とは異なります)。

図32-38 ルールの作成

ルールは、そのルールが使用されるすべての環境で常に適用できるわけではありません。たとえば、ルールが複数のタスク・タイプに適用される場合は、タスクによって結果が異なるため、すべてのタスクに結果を設定できない場合があります。

ルールはリストされている順序で実行されます。図32-38 に示すように、ルールはヘッダーの上下ボタンを使用して順序を変更できます。

あるルールがフィルタ条件に一致すると、そのルールが実行され、他のルールは評価されません。ルールを実行するユーザーは、該当するタスクに割り当てられている唯一のユーザーであることが必要です。タスクが(自分を含めて)複数のユーザーに割り当てられている場合、ルールは実行されません。

ビジネス・ルールをTo Doタスクに対して指定することはできません。

32.8.1 ユーザー・ルールの作成方法

ユーザー・ルールを作成する際は、次を指定します。

- ルール名

- ルールが休暇ルールかどうか。休暇ルールと同期する休暇期間の設定方法は、「休暇期間の設定」を参照してください。

- ルールが適用されるタスクまたはタスク・タイプ: 指定されていない場合、ルールは全タスクに適用されます。タスク・タイプを指定すると、そのタスク・タイプにマップされたマップ済属性すべてをルール条件で使用できます。

- ルールを適用するタイミング。

- ルールに対する条件。これらの条件は、ルールを詳細に定義するフィルタです。たとえば、ルールで優先度1のタスクのみを操作したり、特定のユーザーが作成したタスクを操作するように指定します。標準タスク属性や特定のタスクにマップされた任意のマップ済属性に基づいて条件を作成できます。詳細は、「属性のマップ方法」を参照してください。

ユーザー・ルールを使用して、次のアクションを実行します。

- 再割当て先: 直属の部下またはグループにタスクを再割当てできます。

- 委任先: 任意のユーザーまたはグループに委任できます。タスクを完了するためのアクセス権または権限は、タスクの委任元ユーザーに従って決定されます(委任した元のユーザーからの権限が、後続の委任または再割当てによって変更されることはありません)。

- 結果の設定先: ワークフロー・タスクが自動結果(タスクの承認または却下など)用に設計されている場合は、その結果を指定できます。ルールは特定のタスク・タイプを対象とする必要があります。ルールの対象がすべてのタスク・タイプの場合、このオプションは表示されません。

- アクションを実行しない: このアクションを使用すると、より一般的な他のルールの適用を防止できます。たとえば、アクションが不要な融資申請を除いて、休暇中のすべてのタスクを別のユーザーに再度割り当てるには、2つのルールを作成します。第1のルールでは、融資申請に対してアクションを実行しないように指定し、第2のルールでは、すべてのタスクを別のユーザーに再度割り当てるように指定します。第1のルールによって、融資申請に対する再割当てが防止されます。

ユーザー・ルールを作成する手順は、次のとおりです。

1. 「プリファレンス」リンクをクリックします

「ルール」タブが表示されます。

2. 「ルール」ペインで、「ルール」をクリックして、「追加」をクリックします。

3. 「ルール」領域で次の操作を実行し、「保存」をクリックします。

- ルールの名前を指定します。

- 休暇ルールを作成する場合は、「休暇ルールとして使用」を選択します。ルールの開始日と終了日が休暇期間と自動的に同期します。

- 「次の期間のみルールを実行」を選択し、ルールの実行期間を指定します。

- 「タスク」領域で、これらの条件に一致する「すべてのタスク」または「タスク」を選択します。その後、「追加」ボタンを使用して、ルール条件を追加します。

- このルールの適用対象となるタスク・タイプを参照します。

- 図32-38 に示すように、「アクション」領域で、実行するアクションを「再割当て先」、「委任先」、「結果の設定先」、「アクションを実行しない」から選択します。

新しいルールが「ルール」ノードの下に表示されます。

32.8.2 グループ・ルールの作成方法

グループ・ルールの作成はユーザー・ルールの作成に類似していますが、ログイン・ユーザーが管理するグループのリストが追加されています。次に、グループ・ルールの例を示します。

- 特定の顧客からのタスクをグループのメンバーに割り当てます。

- ラウンド・ロビン割当てを使用して、タスク割当てをグループの各メンバーに確実に均等配分します。

- グループ内で最もビジーでないメンバーに、高優先度のタスクを確実にルーティングします。

グループ・ルールを使用して、次のアクションを実行します。

- メンバーへの割当ての経由先: 割当てを取得するグループ・メンバーを決定するための基準を指定できます。この動的割当て基準には、ラウンド・ロビン割当て、最もビジーでないグループ・メンバーへの割当て、または最も生産性の高いグループ・メンバーへの割当てを含めることができます。また、タスクをグループ内のユーザーに割り当てるためのカスタム関数も追加できます。

- 割当て先: ユーザー・ルールと同様に、直属の部下またはグループにタスクを割り当てられます。

- アクションを実行しない: ユーザー・ルールと同様に、より一般的なルールの実行を防止する条件を指定してルールを作成できます。

グループ・ルールを作成する手順は、次のとおりです。

1. 「プリファレンス」リンクをクリックします

2. 「他のルール」タブをクリックします。

3. リストから「グループ」を選択します。

4. グループ名を入力して「検索」アイコンをクリックするか、グループ名を入力します。

「認証ブラウザ」が開き、グループを検索して選択できます。

5. 図32-39 のように、「グループ・ルール」ノードの下のグループ名を選択し、「新規ルールの追加」をクリックします。

図32-39 グループ・ルールの作成

6. グループ・ルールの情報を入力して、「保存」をクリックします。

- ルールの名前を指定します。

- このルールの適用対象となるタスク・タイプを参照します。

- ルールの実行日を指定します。

- 「タスク」領域で、ルール条件を追加します。

- 図32-39 に示すように、「アクション」領域で、実行する(または実行しない)アクションを「メンバーへの割当ての経由先」、「割当て先」、「アクションを実行しない」から選択します。

新しいルールが「グループ・ルール」ノードの下に表示されます。

32.8.3 複数の割当て先があるタスクの割当てルール

タスクに複数の割当て先がある場合、割当てルールはタスクに対して評価されず、タスクは自動的にルーティングされません。これは、タスクの割当て先ごとに割当てルールを定義できるため、タスクに対して実行するアクションに競合が発生する可能性があるためです。割当てルールによってルーティングされるのは、単一のユーザーに排他的に割り当てられたタスクのみです。

たとえば、次の順序を考えてみましょう。

1. ユーザーcdickensに対して、割当て済のすべてのリクエストをユーザーjsteinに再度割り当てるルールを作成します。

2. ユーザーjcooperは、割当て済のタスクをcdickensとcdoyleに再度割り当てます。

3. cdickensがタスクを申告すると、タスクはこの2人の受信ボックスに表示されます。

このタスクは、jsteinに自動的に再度割り当てられません。ユーザーjcooperが、複数のユーザー(cdickensとcdoyle)ではなく、cdickensのみにタスクを明示的に再度割り当てた場合は、cdickensに対して設定された割当てルールに従ってタスクがjsteinにルーティングされます。

32.8.4 再割当てされた休暇ルールでの循環ロジックの回避方法

休暇ルールを作成する場合は、承認タスクが循環的に再割当てされないことを確認してください。

たとえば、jsteinはjcooperのマネージャであり、必要なタスクが承認のためにjsteinに移動します。jsteinが休暇ルールを作成する場合は、それらのタスクがjcooperに再割当てされないようにします。

または、休暇ルールで再割当てではなく委任オプションを使用できます。委任オプションの詳細は、「プロセス・ワークスペースでのタスクの再割当てと委任」を参照してください。

循環依存関係の回避方法

この例では、休暇期間の設定と他のユーザーへのタスクの再割当てを望んでいるUser2に2つのルールを定義します。第1のルールでは、タスクがUser1のタスクではない場合にそのタスクをUser1に再割当てします。第2のルールでは、タスクがUser1のタスクである場合にそのタスクをUser3に再割当てします。

タスク・フローは、jcooper、jstein、wfaulkの順になります。ルールはjsteinに対して設定されます。

1. jsteinとしてワークリストにログインし、「プリファレンス」ページに移動します。

2. 次に示すように、「休暇期間」が無効になっていることを確認します。

3. 「ルール」をクリックし、「新規ルールの追加 +」をクリックします。

4. ルールの名前(VacationRule1など)を入力します。

5. 「休暇ルールとして使用」チェック・ボックスの選択を解除します。

6. 「次の期間のみルールを実行」チェック・ボックスを選択し、適切な日付を入力します。

7. 「タスク」ドロップダウン・リストから「これらの条件に一致するタスク」を選択します。

8. 「条件の追加 +」をクリックし、「ユーザー」→「リクエスト元ユーザー」を選択します。

9. 新しい行で、「次に一致しない」を選択します。

10. その横のテキスト・ボックスに、ユーザー名としてjcooperを入力します。

11. 「アクション」セクションで、「再割当て先」を選択し、ユーザー名としてjcooperを入力します。

12. 「保存」をクリックします。
この手順を繰り返して、次の入力で別のルールを作成します。

13. 第2のルールの名前(VacationRule2など)を入力します。

14. VacationRule1と同じ開始日および終了日を選択します。

15. 「次に一致する」の「リクエスト元ユーザー」条件を追加します。

16. ユーザー名としてjcooperを入力します。

17. 「アクション」セクションで、「再割当て先」を選択し、ユーザー名としてwfaulkを入力します。

18. 「保存」をクリックします。

コンポジットを起動すると、jsteinに定義した2つの新しいルールに基づいて、タスクが期待どおりに割り当てられます。

32.9 ワークリスト管理機能の使用

管理者とは、BPMWorkflowAdminロールが付与されているユーザーです。次の管理機能があります。

- 他のユーザーまたはグループのルールの管理

- ワークリスト表示の設定(アプリケーション・プリファレンス)。アプリケーション・プリファレンスによって、次に示すワークリストの外観をカスタマイズします。

- ログイン・レルムのラベル

- リソース・バンドル

- 言語のロケール情報の取得元

- ブランド・ロゴ

- ブランド・タイトル

- ブランド・スキン

- oracle.com、google.comなどの使用する外部アプリケーション

- マップ済属性の指定

管理者は、すべてのユーザーに割り当てられたすべてのタスクを表示および更新できます。「管理者」タブを選択すると、管理者の「割当て先」フィルタに「管理者」が表示されます。

この項の内容は次のとおりです。

- 他のユーザーまたはグループのルールの管理方法(管理者として)

- ログイン・ページ・レルムのラベルを指定する方法

- リソース・バンドルを指定する方法

- 言語のロケール情報を指定する方法

- ブランド・ロゴを指定する方法

- ブランド・タイトルを指定する方法

- スキンを選択する方法

- カスタマイズされたアプリケーションおよびリンクを有効にする方法

マップ済属性の指定の詳細は、マップ済属性の使用(フレックス・フィールド)を参照してください。

32.9.1 管理者が他のユーザーまたはグループのルールを管理する方法

この機能は、ルールに関する問題を解決する場合に役立ちます。また、管理者は退社したユーザーに対するルールを設定できます。これにより、そのユーザーに割り当てられていた全タスクが別のユーザーまたはグループに自動的に割り当てられます。

別のユーザーまたはグループのルールを作成する手順は、次のとおりです。

1. 「プリファレンス」リンクをクリックします

2. 「他のルール」タブをクリックします。

3. ルールを作成するユーザーまたはグループを検索します(図32-40 を参照)。

図32-40 別のユーザーまたはグループのルールの作成

4. 「ユーザー・ルール」ノードまたはグループ名(グループ・ルールの場合)をクリックします。

5. 「追加」アイコンをクリックして、ルールを作成します。

6. ルールの情報を指定して、「保存」 をクリックします(図32-39を参照)。

32.9.2 ログイン・ページ・レルムのラベルの指定方法

アイデンティティ・サービスが複数のレルムで構成されている場合は、ユーザーがOracle BPM Worklistにログインすると、ログイン・ページにレルム名のリストが表示されます。LABEL_LOGIN_REALM では、これらのレルムを表示するラベルのルックアップに使用されたリソース・バンドル・キーが指定されます。レルムという用語は、ユーザー・コミュニティにあわせて変更でき、国、会社、部署または部門などの用語の方が適切な場合があります。レルムという用語を変更するには、リソース・バンドルをカスタマイズし、この文字列にリソース・バンドル・キーを指定し、そのリソース・バンドル・キーを指すように「ログイン・ページ・レルムのラベル」パラメータを設定します。

図32-41 は、「ログイン・ページ・レルムのラベル」フィールドがハイライト表示された「アプリケーション・プリファレンス」ページを示しています。「アプリケーション・プリファレンス」ページにアクセスするには、「ワークリスト・アプリケーション」インタフェースの最上部にあるグローバル・ツールバーの「管理」をクリックします。

図32-41 ログイン・ページ・レルムのラベルの指定

32.9.3 リソース・バンドルの指定方法

リソース・バンドルは、ワークリスト・アプリケーションに表示される文字列を提供します。デフォルトでは、リソース・バンドルへのクラス・パスは次のとおりです:

oracle.bpel.worklistapp.resource.WorklistResourceBundle

図32-42 は、「リソース・バンドル」フィールドがハイライト表示された「アプリケーション・プリファレンス」ページを示しています。「アプリケーション・プリファレンス」ページにアクセスするには、「ワークリスト・アプリケーション」インタフェースの最上部にあるグローバル・ツールバーの「管理」をクリックします。

図32-42 リソース・バンドルの指定

管理者は、カスタム・リソース・バンドルを作成することで、アプリケーションに表示される文字列を追加または変更できます。その後、「アプリケーション・プリファレンス」ページの「リソース・バンドル」フィールドを使用して、カスタム・リソース・バンドルへのクラス・パスを指定できます。

リソース・バンドルのカスタマイズの詳細は、『Oracle Business Process Managementによるプロセスの管理とモニタリング』を参照してください。

32.9.4 言語のロケール情報の指定方法

「アプリケーション・プリファレンス」ページで、ワークリスト・アプリケーションの表示言語を決定する方法を指定できます。言語ロケールに関する情報は、ユーザーのブラウザ、またはワークリスト・ユーザーに関する情報を格納するアイデンティティ・プロバイダから導出できます。

図32-43 に、「次の言語設定を使用」オプションがハイライト表示された「アプリケーション・プリファレンス」ページを示します。「アプリケーション・プリファレンス」ページにアクセスするには、「ワークリスト・アプリケーション」インタフェースの最上部にあるグローバル・ツールバーの「管理」をクリックします。

図32-43 言語のロケール情報の指定

32.9.5 ユーザー名の形式の指定方法

「アプリケーション・プリファレンス」ページから、ログイン後の画面でのユーザー名の表示方法を指定できます。jsteinなどのユーザーIDやJohn Steinbeckなどのユーザー名を表示することを選択できます。

32.9.6 ブランド・ロゴの指定方法

ブランド・ロゴは、ワークリスト・アプリケーションの各ページの左上隅に表示されるイメージです。Oracleロゴがデフォルトで表示されますが、選択したイメージに変更することもできます。

注意:

適切に表示するためには、イメージ・サイズを120px x 40px (長さx幅)にすることをお薦めします。高解像度の大きいイメージをブランド・ロゴのサイズにあわせて圧縮することもできますが、小さいイメージの方が見やすく表示されます。

図32-44 は、「ブランド・ロゴ」フィールドがハイライト表示された「アプリケーション・プリファレンス」ページを示しています。「アプリケーション・プリファレンス」ページにアクセスするには、「ワークリスト・アプリケーション」インタフェースの最上部にあるグローバル・ツールバーの「管理」をクリックします。

図32-44 ブランド・ロゴの指定

ブランド・ロゴを指定するには:

次のいずれかを行います:

- 外部のイメージ・ホストWebサイトを参照します。このタスクを行うには、「ブランド・ロゴ」フィールドにイメージのURLを入力します。

- サーバー上の特定の場所にイメージをアップロードし、「ブランド・ロゴ」フィールドに相対パス(/afr/my_logo.pngなど)を入力します。

- 共有ライブラリからイメージを参照します。このタスクを行うには、「ブランド・ロゴ」フィールドに、共有ライブラリにあるとおりにロゴ名のパス(/my_logo.pngvなど)を入力します。

注意:

ワークリスト・アプリケーションとプロセス・ワークスペースのいずれかからブランド・ロゴをカスタマイズすると、両方のアプリケーションのロゴが変更されます。たとえば、ワークリストからロゴを変更すると、ワークスペースのロゴが自動的に変更されます。

イメージおよびJARファイルの共有ライブラリの一部としてのデプロイの詳細は、『Oracle Business Process Managementによるプロセスの管理とモニタリング』を参照してください。

32.9.7 ブランド・タイトルの指定方法

サイトのタイトルを指定し、デフォルトのタイトル(BPM Worklist)を好みのタイトルに変更できます。

図32-45 は、「ブランド・タイトル」フィールドがハイライト表示された「アプリケーション・プリファレンス」フィールドを示しています。「アプリケーション・プリファレンス」ページにアクセスするには、「ワークリスト・アプリケーション」インタフェースの最上部にあるグローバル・ツールバーの「管理」をクリックします。

Figure 32-45 ブランド・タイトルの指定

ブランド・タイトルを指定するには:

次のいずれかを行います:

- 「ブランド・タイトル」フィールドに、タイトルの単純な文字列を入力します。

- 「ブランド・タイトル」フィールドに、「リソース・バンドル」のキーと値のペアを参照するラベルを入力します。この方法で、タイトルをLABEL_WORKLIST_TITLE.などのように国際化できます。

32.9.8 スキンの選択方法

スキンは、グラフィック・インタフェースのルック・アンド・フィールを決定します。「アプリケーション・プリファレンス」ページからスキンを指定します。「アプリケーション・プリファレンス」ページにアクセスするには、「ワークリスト・アプリケーション」インタフェースの最上部にあるグローバル・ツールバーの「管理」をクリックします。

図32-46 は、「スキンの選択」フィールドがハイライト表示された「アプリケーション・プリファレンス」ページを示しています。

図32-46 スキンの選択

32.9.8.1 スキンを選択する手順

スキンを選択するには:

次のいずれかを行います:

- 「スキンの選択」リストから、デフォルトのADFスキンの1つを選択します

- .JARファイル内のカスタマイズされたスキン(.cssファイル)をアップロードし、共有ライブラリの一部としてデプロイします。その後、コンソールからアプリケーションを再起動すると、カスタム・スキンが「スキンの選択」リストに表示されます。

32.9.8.2 カスタマイズされたスキンを含むJARファイルを作成する手順

カスタマイズされたスキンを含むJARファイルを作成するには:

1. 次の例のようなディレクトリ構造を作成します:

C:\temp\META-INF\adf\oracle\skin\images
META-INF\skins\custom.css
META-INF\trinidad-skins.xml

この例では、customという単語をカスタマイズしたスキンの名前に変更できます。

2. trinidad-skins.xmlファイルの内容が次のようになっていることを確認します。

<?xml version="1.0" encoding="ISO-8859-1"?>
<skins xmlns="http://myfaces.apache.org/trinidad/skin">
<skin>
<id>custom.desktop</id>
<family>custom</family>
<extends>custom.desktop</extends>
<render-kit-id>org.apache.myfaces.trinidad.desktop</render-kit-id>
<style-sheet-name>skins/custom.css</style-sheet-name>
</skin>
</skins>

3. c:\tempディレクトリから次のコマンドを発行して、.JARファイルを作成します。

jar -cvf customSkin.jar META-INF/

4. このJARファイルをディレクトリ/scratch/username/sharedLibにコピーします。

注意:

次の方法でcssファイル内のイメージを参照します:

../adf/oracle/skin/images/example.gif (末尾に2つドットを付けます)。

これにより、.cssファイルがあるMETA-INF/skinディレクトリの上のディレクトリからMETA-INFルートの検索を開始できます。

JARファイルの共有ライブラリの一部としてのデプロイの詳細は、『Oracle Business Process Managementによるプロセスの管理とモニタリング』を参照してください。

32.9.9 カスタマイズされたアプリケーションおよびリンクを有効にする方法

プロセス・ワークスペースでは、「外部アプリケーション」パネルで使用できるカスタマイズされた外部アプリケーションおよびリンクを作成できます。さらに、プロセス・ワークスペースとワークリスト・アプリケーションの両方で、「タスクの詳細」ペインに表示される列を指定できます。

「アプリケーション・プリファレンス」ページを使用して、カスタム・アプリケーションを指定します。「アプリケーション・プリファレンス」ページにアクセスするには、「ワークリスト・アプリケーション」インタフェースの最上部にあるグローバル・ツールバーの「管理」をクリックします。

カスタム・アプリケーションを指定するJavaコードを確認するには、「ワークリスト・アプリケーションでカスタマイズされたアプリケーションを有効化するJavaコード」を参照してください。

カスタマイズされたアプリケーションを有効にするには:

1. 「アプリケーション・プリファレンス」ページで、図32-47に示すように、「アプリケーション・カスタマイズ・クラス名」 フィールドにカスタム・アプリケーションのクラス名を入力します。

図32-47 カスタム・アプリケーションの指定

2. コンソールからアプリケーションを再起動します。

カスタマイズによっては、その効果をここで確認できます。

プロセス・ワークスペース用のカスタマイズを実行し、外部アプリケーションの作成と「タスクの詳細」ペインでの受信ボックス列の指定のいずれか(あるいはその両方)を実行した場合、次が表示されます。

- プロセス・ワークスペースのホームページにある「外部アプリケーション」パネルにリストされたカスタム・アプリケーション(図32-48 を参照)。

図32-48 プロセス・ワークスペースの「外部アプリケーション」パネル

- ユーザーが指定した内容にあわせて調整された、「タスクの詳細」受信ボックスの列(図32-49 を参照)

図32-49 「タスクの詳細」ペインのカスタマイズされた列

ワークリスト・アプリケーションおよびプロセス・ワークスペースでのアプリケーションのカスタマイズの詳細は、『Oracle Business Process Managementによるプロセスの管理とモニタリング』を参照してください。

32.9.10 タスク・アクションのイメージの指定方法

管理者の場合、アクションを赤の「X」アイコンか、緑のチェック・マーク・アイコンのいずれで表示するかを指定できます。

タスク・アクションのイメージを指定するには:

1. 「管理」、「アプリケーション・プリファレンス」の順に選択します。

2. 「タスク・アクションをイメージにマップ」フィールドで、緑のチェック・マーク・アイコンまたは赤の「X」アイコンにマップするタスクを選択します。

3. 「保存」をクリックします。

32.10 通知設定の指定

複数の通信チャネル(配信タイプ)にアクセスする場合は、通知設定を構成して、メッセージの受信方法、時期および場所を管理できます。具体的には、メッセージを配信するチャネルとその環境を指定するメッセージング・フィルタ(配信プリファレンス)を定義できます。

たとえば、異なるサービス・レベル合意(SLA)を持つ顧客から受信するメッセージに対してフィルタを作成し、プレミアムSLAの顧客の場合は勤務先電話番号とSMSチャネルを介して通知し、それ以外のSLAの顧客の場合は電子メールで通知するように指定できます。

32.10.1 メッセージング・フィルタ・ルール

メッセージング・フィルタ・ルールは、ルール条件とルール・アクションで構成されます。ルール条件は、ルール属性、演算子および関連する値で構成されます。ルール・アクションは、ルール内に指定した条件を満たす場合に実行されるアクションです。

32.10.1.1 データ型

表32-9 に、メッセージング・フィルタでサポートされるデータ型を示します。各属性には関連するデータ型があり、各データ型には一連の比較演算子が事前定義されています。

表32-9 メッセージング・フィルタでサポートされるデータ型

データ型

比較演算子

日付

isEqual、isNotEqual、isGreaterThan、isGreaterThanOrEqual、isLessThan、isLessThanOrEqual、Between、isWeekday、isWeekend

時間

isEqual、isNotEqual、Between

数値

isEqual、isNotEqual、Between、isGreaterThan、isGreaterThanOrEqual、isLessThan、isLessThanOrEqual

文字列

isEqual、isNotEqual、Contains、NotContains

注意:

文字列データ型は正規表現をサポートしていません。

32.10.1.2 属性

表32-10 に、メッセージング・フィルタ用に事前定義されている属性を示します。

表32-10 メッセージング・フィルタ用に事前定義されている属性

属性

データ型

コスト合計

数値

送信元

文字列

支出タイプ

文字列

宛先

文字列

アプリケーション・タイプ

文字列

期間

数値

アプリケーション

文字列

プロセス・タイプ

文字列

ステータス

文字列

件名

文字列

顧客タイプ

文字列

時間

時間

グループ名

文字列

処理時間

数値

日付

日付

期日

日付

ユーザー

文字列

ソース

文字列

金額

数値

ロール

文字列

優先度

文字列

顧客名

文字列

有効期限

日付

順序タイプ

文字列

組織

文字列

分類

文字列

サービス・リクエスト・タイプ

文字列

32.10.2 ルール・アクション

特定のルールには、メッセージング・フィルタによって次のアクションを定義できます。

- メッセージを送信しない: メッセージをチャネルに送信しません。

- 選択したすべてのチャネルにメッセージを送信: アドレス・リストに指定されているすべてのチャネルにメッセージを送信します。

- 最初の使用可能なチャネルに送信: 1つのメッセージの送信に成功するまで、アドレス・リスト内のチャネルに対してメッセージをシリアルに送信します。つまり、現在のチャネルが失敗ステータスを返すと、次のチャネルへの送信が実行されます。このフィルタ・アクションは、ヒューマン・ワークフロー・レイヤーから送信されるメッセージに対してはサポートされていません。

32.10.3 メッセージング・チャネルの管理

Oracle BPM Worklistでのメッセージング・チャネルは、業務用携帯電話などの物理的なチャネル、およびデスクトップで実行する電子メール・クライアント・アプリケーションの両方を意味します。Oracle BPM Worklistで具体的にサポートしているのは、次のメッセージング・チャネルです。

- 電子メール

- IM

- 携帯電話

- SMS

- ボイス

- ワークリスト

メッセージング・チャネルについては次の点に注意してください。

- メッセージング・チャネルのアドレスは、構成済のアイデンティティ・ストアからフェッチされます。

- SMS通知および携帯電話通知は、携帯電話番号に送信されます。

- ボイス通知は、勤務先電話番号に送信されます。

- メッセージング・チャネル・プリファレンスがワークリストの場合、特別な通知は送信されません。かわりに、Oracle BPM Worklistにログインしてタスクを表示してください。

- 優先チャネルが選択されていない場合、デフォルトのメッセージング・チャネル・プリファレンスは電子メールになります。

「使用可能なチャネル」を使用して、メッセージング・チャネルを表示、作成、編集および削除できます。

32.10.3.1 メッセージング・チャネルの表示

既存のメッセージング・チャネルを表示できます。

メッセージング・チャネルを表示する手順は、次のとおりです。

1. 「プリファレンス」リンクをクリックします。

2. 「通知」タブをクリックします。

3. 「使用可能なチャネル」を開きます。

「使用可能なチャネル」リストが表示され(図32-50 )、次の情報が表示されます。

- 名前: メッセージング・チャネルの名前。

- タイプ: メッセージング・チャネルのタイプ(電子メール、SMSなど)。

- アドレス: チャネルのアドレス(電話番号、電子メール・アドレスなど)。

- デフォルト: このチャネルがデフォルトのメッセージング・チャネルかどうかを指定します。

図32-50 メッセージング・チャネル

4. 「表示」→「列」の順にクリックして、表示または非表示の列を選択します。

また、「表示」→「列の並替え」の順にクリックしてダイアログを表示し、表示されている列を並べ替えることもできます。

メッセージング・チャネルの名前とアドレスは、基礎となるアイデンティティ・ストア(Oracle Internet Directoryなど)から取得されます。

32.10.3.2 メッセージング・チャネルの作成、編集および削除

Oracle BPM Worklistでは、基礎となるアイデンティティ・ストア(Oracle Internet Directoryなど)を使用して、メッセージング・チャネルとアドレスを管理します。したがって、Oracle BPM Worklistを使用してメッセージング・チャネルを直接、作成、変更または削除することはできません。

これらのアクションを実行するには、組織のアイデンティティ・ストアの管理責任者であるシステム管理者に連絡してください。

32.10.4 メッセージング・フィルタの管理

「メッセージング・フィルタ」を使用して、受信する通知のタイプ、およびこれらの通知を受信するために使用するチャネルを指定するフィルタを定義できます。そのためには、比較演算子(「は次と等しい」や「は次と等しくない」など)、通知タイプ、内容または送信元を表す属性、および通知アクション(使用可能な最初のメッセージング・チャネルに通知を送信、すべてのメッセージング・チャネルに通知を送信、またはどのチャネルにも通知を送信しない(事実上、通知をブロック))の組合せを使用します。

たとえば、上司であるLiseから受信したすべてのメッセージを取得するLiseからのメッセージというメッセージング・フィルタを作成できます。すべてのフィルタ条件に一致する通知が最初に業務用携帯電話などに送信され、最初のメッセージング・チャネルが使用できない場合は会社の電子メールに送信されます。

32.10.4.1 メッセージング・フィルタの表示

既存のメッセージング・フィルタを表示できます。

メッセージング・フィルタを表示する手順は、次のとおりです。

1. 「通知」タブをクリックします。

2. 「メッセージング・フィルタ」を開きます。

「メッセージング・フィルタ」リストが表示され(図32-51 )、次の情報が表示されます。

- 名前: メッセージング・フィルタの名前

- 説明: (オプション)メッセージング・フィルタの説明

- 有効: このフィルタをメッセージ処理に使用するかどうかを指定します

図32-51 メッセージング・フィルタ

3. 「表示」→「列」の順にクリックして、表示または非表示の列を選択します。

32.10.4.2 メッセージング・フィルタの作成

メッセージング・フィルタを作成する手順は、次のとおりです。

1. 「作成」をクリックします。
図32-52 に示すように、「フィルタの作成」ダイアログ・ボックスが表示されます。

図32-52 メッセージング・フィルタの追加

2. 次の情報を指定します。

- 名前: メッセージング・フィルタの名前。

- 説明: (オプション)メッセージング・フィルタの説明

- 有効: デフォルトでは、このオプションが選択されています。メッセージ処理にこのフィルタを使用しない場合は、選択解除します。

3. 「次のすべての条件に一致」オプションまたは「次の条件のいずれかと一致」オプションを選択して、通知がすべての条件を満たす必要があるのか、いずれかの条件を満たすのかを選択します。

4. 「作成」をクリックします。
次のように、「条件の作成」ダイアログ・ボックスでフィルタ条件を定義します。

a. リストから属性を選択します。

b. リストから「isEqual」などの演算子を選択します。

c. 「オペランド」フィールドに条件の値を入力します。

d. 「OK」をクリックして、条件をリストに追加します。

e. この手順を繰り返してフィルタ条件をさらに追加します。フィルタ条件を削除するには、「削除」をクリックします。

5. 「アクション」セクションで、次のメッセージング・オプションから選択します。

- メッセージを送信しない: すべてのチャネルにメッセージを送信しません。

- 選択したすべてのチャネルに送信: アドレス・リストに指定されているすべてのチャネルにメッセージを送信します。

- 最初の使用可能なチャネルに送信: 1つのメッセージの送信に成功するまで、アドレス・リスト内のチャネルに対してメッセージをシリアルに送信します。つまり、現在のチャネルが失敗ステータスを返すと、次のチャネルへの送信が実行されます。

6. 配信チャネルを設定するには、「通知チャネルの追加」リストからチャネルを選択し、「追加」をクリックします。チャネルを削除するには、「削除」をクリックします。

7. 上/下矢印を使用してチャネルに優先度を付けます。「最初の使用可能なチャネルに送信」を選択すると、最上位のチャネル(使用可能な場合)がフィルタ基準に一致したメッセージを受信します。

8. 「OK」をクリックします。
メッセージング・フィルタが「メッセージング・フィルタ」領域の下に表示されます。この「メッセージング・フィルタ」領域では、チャネルを編集したり、削除することができます。

32.10.4.3 メッセージング・フィルタの編集

メッセージング・フィルタを編集するには:

1. 「メッセージング・フィルタ」領域からフィルタを選択します。

2. 「編集」をクリックします。

3. メッセージング・フィルタを更新するには、「OK」をクリックします。フィルタを変更せずにダイアログを閉じる場合は、「取消」をクリックします。

32.10.4.4 メッセージング・フィルタの削除

メッセージング・フィルタを削除するには:

1. 「メッセージング・フィルタ」領域からフィルタを選択します。

2. 「削除」をクリックします。確認のダイアログが表示されます。

3. メッセージング・フィルタを削除するには、「OK」をクリックします。フィルタを削除せずにダイアログを閉じる場合は、「取消」をクリックします。

32.11 マップ済属性(フレックス・フィールド)の使用

ヒューマン・ワークフローのマップ済属性(以前のフレックス・フィールド)での格納と問合せでは、状況固有のカスタム属性が使用されます。これらのカスタム属性は、通常、タスク・ペイロード値に基づきます。マップ済属性にカスタム属性を格納すると、次の利点が得られます。

- フレックス・フィールドをタスク・リストの列として表示できます。

- フレックス・フィールドでは、カスタム・ビューおよび拡張検索でタスクをフィルタ処理できます。

- フレックス・フィールドは、キーワードベースの検索で使用できます。

たとえば、タスクの注文書リクエスト・ペイロードのRequester、PurchaseOrderIDおよびAmountフィールドをマップ済属性に格納できます。Oracle BPM Worklistにログインした承認者は、これらのフィールドの値をタスク・リスト内の列で確認して、アクセスするタスクを決定できます。ユーザーは、マップ済属性に基づいてタスクをフィルタ処理するビューを定義できます。たとえば、ユーザーは、異なる金額範囲に基づいて発注書の承認用ビューを作成できます。ユーザーがある時点で特定のリクエスタまたは発注書IDに関連するタスクを取得することも必要になった場合、キーワード・フィールドにそのリクエスタまたは発注書IDを指定して検索を実行することによって、関連するタスクを取得できます。

マップ済属性の移入を行う場合は、次の手順で管理者がマップ済属性マッピングを作成する必要があります。

1. 移入するマップ済属性のラベルを指定します。

2. このラベルに、データを含むペイロード属性をマップします。

これらのマッピングは、特定のタスク・タイプに対して有効です。したがって、タスク・タイプごとに異なるマップ済属性マッピングを作成できます。マッピングが完了し、新しいタスクが開始されると、そのペイロードの値はマップ済属性に推進されます。マッピングの前に開始されたタスクについては、マップ済属性に値は格納されません。マップ済属性に推進できるのは、ペイロード内の最上位レベルの単純型の属性のみです。複合型の属性またはその中にネストされた単純型の属性は推進できません。ペイロード内の属性はマップ済属性に推進する必要がある場合があることに留意しながら、ヒューマン・タスク・エディタでタスクのペイロードを定義することが重要です。キーワードベースの検索には、テキストおよび数値のすべてのマップ済属性が自動的に含められます。

基本的に、ヒューマン・タスク・エディタを使用するのは、タスクのペイロードを定義する場合のみです。他のすべての操作は実行時に実行されます。

ディレクトリ・ネーミングは、フレックス・ファイル命名規則と併用できません。

注意:

- マップ済属性は、ビジネス・プロセスのインスタンスが生成される前に定義する必要があります。正しいマップ済属性は、マップ済属性の作成後に生成されたインスタンスにのみ反映されます。ビジネス・プロセスの古いインスタンスには、マップ済属性の以降の変更は反映されません。

- 新規ロケールを追加する場合、マップ済属性のラベルは、キャッシュをフラッシュするまで自動的には変換されません。キャッシュをフラッシュするには、サーバーを再起動するか、またはワークフロー構成の設定の値を変更します。たとえば、ワークフロー構成のworkflowCustomClasspathURLプロパティを新しい値に変更し、再度元の値に変更します。

32.11.1 属性のマップ方法

管理者または特別な権限があるユーザーは、属性マッピングを使用して(図32-53 )、ペイロードのデータをインラインのマップ済属性に推進できます。データをマップ済属性に推進すると、それらのデータが検索可能になり、タスク・リスト・ページで列として表示できるようになります。

管理者はパブリック・マップ済属性をマップできます。workflow.mapping.publicFlexField権限を付与されたユーザーはパブリック・マップ済属性をマップ可能であり、「管理」タブに「パブリック・フレックス・フィールド」ノードが表示されます。

図32-53 マップ済属性マッピング

32.11.1.1 ラベルを作成する手順

ラベルを作成する手順は、次のとおりです。

マップ済属性マッピングを作成するには、まず管理者がマップ済属性を示すわかりやすい表示名となるセマンティック・ラベルを定義します。図32-54 に示すように、「追加」をクリックして「ラベルの作成」ダイアログを使用します。

図32-54 ラベルの作成

図32-54 に示すように、labelNameはタスク属性TextAttribute3にマップされます。ペイロード属性もラベルにマップされます。この例では、「テキスト」属性タイプがlabelNameに関連付けられています。その結果、「テキスト」属性の値が「TextAttribute3」列に格納され、labelNameがユーザーのタスク・リストに表示される列ラベルになります。ラベルは、様々なタスク・タイプに再利用できます。ラベルを削除できるのは、そのラベルがどのマッピングにも使用されていない場合のみです。

マップされたペイロード属性は、カスタム・ビューに列として表示でき、カスタム・ビューとワークフロー・ルールの両方でフィルタ条件として使用できます。ペイロード属性の表示名は、マッピングの実行時に選択した属性ラベルです。

以下の制限に注意してください。

- マップできるのは、単純なタイプのペイロード属性のみです。

- 1つのタスク・タイプに使用できるマップ済属性(およびラベル)は1つのみです。

- numberまたはdateデータ型のデータ型変換はサポートされていません。たとえば、string型のペイロード属性をnumber型のラベルにマップすることはできません。

32.11.1.2 すべてのマッピングを参照する手順

すべてのマッピングを参照する手順は、次のとおりです。

1. 「全マッピングの参照」をクリックします。

2. ラベル表内の行を選択して、特定のラベルにマップされたすべてのペイロード属性を表示します。

図32-55 マッピングの参照

32.11.1.3 マッピングをタスク・タイプ別に編集する手順

マッピングをタスク・タイプ別に編集する手順は、次のとおりです。

1. 「タスク・タイプによるマッピングの編集」をクリックし、必要に応じてタスク・タイプを指定して、「検索」をクリックします。

2. タスク・タイプを選択して、「OK」をクリックします。

図32-56 タスク・タイプの選択

3. 「タスク・タイプによるマッピングの編集」フィールドにタスク・タイプが表示されている状態で、「実行」をクリックします。

図32-57 に示すように、選択したタスク・タイプに対する現行のマッピングがすべて表示されます。

図32-57 ラベルの選択

4. マッピングのラベルを選択して、「選択」をクリックします。

図32-58 に、完成したマッピングを示します。

図32-58 作成されたマップ済属性マッピング

詳細は、「属性ラベルの国際化」を参照してください。

32.11.2 カスタムのマップ済属性

次のマップ済属性がWorkflowTask.xsdファイルに含まれており、制限なしに使用できます。

表32-11 カスタムのマップ済属性

属性

データ型

customerAttributeString1

文字列

customerAttributeString2

文字列

customerAttributeNumber1

倍精度浮動小数点

customerAttributeNumber2

倍精度浮動小数点

customerAttributeDate1

日付

customerAttributeDate2

日付

これらの属性の設定および取得には、次のJava Architecture for XML Binding (JAXB)メソッドを使用します。

task.getCustomerAttributes.getCustomerAttributeString1()

task.getCustomerAttributes.setCustomerAttributeString1("String")

task.getCustomerAttributes.getCustomerAttributeNumber1()

task.getCustomerAttributes.setCustomerAttributeNumber2(9)

task.getCustomerAttributes.setCustomerAttributeDate1()

task.getCustomerAttributes.setCustomerAttributeDate2()

これらのフィールドは、customerAttributeString1、customerAttributeString2、customerAttributeNumber1、customerAttributeNumber2、customerAttributeDate1、customerAttributeDate2としてデータベースに保持されます。

32.12 ワークリスト・レポートの作成

表32-12 に、タスク分析に使用できるワークリスト・レポートを示します。

表32-12 ワークリスト・レポートのタイプ

レポート名

説明

入力パラメータ

不参加タスク

このレポートでは、ユーザーのグループまたは報告先のグループに割り当てられたタスクの中で、まだ獲得されていないタスク(不参加タスク)が分析されます。

- 割当て先: (必須)このオプションでは、ユーザーのグループに割り当てられたタスク(グループ)、報告先のグループに割り当てられたタスク(「報告先」)、ユーザーが作成者であるタスク(「作成者」)、またはユーザーが所有者であるタスク(「所有者」)を選択します。

- 作成日: (オプション)日付範囲。

- 有効期限: (オプション)日付範囲。

- タスクの状態: (オプション)状態は、「任意」、「割当て済」、「期限切れ」または「情報のリクエスト中」のいずれかです。

- 優先度: (オプション)優先度は、「任意」、「最高」、「高」、「標準」、「低」または「最低」のいずれかです。

タスクの優先度

このレポートでは、ユーザー、報告先またはそのグループに割り当てられたタスクの数が優先度別に分析されます。

- 割当て先: (必須)このオプションには、選択した割当て先に応じて、ログイン・ユーザーに割り当てられたタスク(「個人」)、ユーザーとそのユーザーが所属するグループに割り当てられたタスク(「個人とグループ」)、または、ユーザーの報告先が所属するグループに割り当てられたタスク(「報告先」)が含まれます。

- 作成日: (オプション)日付範囲。

- 終了日: (オプション)レポートに含まれるタスクの終了日の日付範囲。

- 優先度: (オプション)優先度は、「任意」、「最高」、「高」、「標準」、「低」または「最低」のいずれかです。

タスクのサイクル・タイム

このレポートでは、ユーザーのグループまたは報告先のグループに基づいて、タスクの割当てから完了までの所要時間が分析されます。

- 割当て先: (必須)このオプションには、選択した割当て先に応じて、自分のタスク(「個人」)、またはユーザーの報告先が所属するグループに割り当てられたタスク(「報告先」)が含まれます。

- 作成日: (オプション)日付範囲。

- 終了日: (オプション)レポートに含まれるタスクの終了日の日付範囲。

- 優先度: (オプション)優先度は、「任意」、「最高」、「高」、「標準」、「低」または「最低」のいずれかです。

タスクの生産性

このレポートでは、ユーザー、報告先またはグループについて、特定期間中に割り当てられたタスク数と完了したタスク数が分析されます。

- 割当て先: (必須)このオプションには、選択した割当て先に応じて、ユーザーのタスク(「個人とグループ」)、またはユーザーの報告先が所属するグループに割り当てられたタスク(「報告先」)が含まれます。

- 作成日(範囲): (オプション)作成日の日付範囲。デフォルト値は1週間です。

- タスク・タイプ: 「検索」(懐中電灯)アイコンを使用して、タスクのタイトルのリストから選択します。「ワークフロー・タスク・タイプの選択」ページに、タスクのすべてのバージョンがリストされます(オプション)。

タスク時間分布

このレポートには、割当て先がタスクを実行するのに要した時間が表示されます。

- 割当て先: (必須)このオプションには、選択した割当て先に応じて、ユーザーのタスク(「個人とグループ」)、またはユーザーの報告先が所属するグループに割り当てられたタスク(「報告先」)が含まれます。

- 開始...終了(日付範囲): (オプション)作成日の日付範囲。デフォルト値は1週間です。

- タスク・タイプ: 「検索」(懐中電灯)アイコンを使用して、タスクのタイトルのリストから選択します。「ワークフロー・タスク・タイプの選択」ページに、タスクのすべてのバージョンがリストされます(オプション)。

32.12.1 レポートの作成方法

レポートは、「レポート」リンクから入手できます。レポートの結果は保存できません。

レポートを作成する手順は、次のとおりです。

1. 「レポート」リンクをクリックします。

2. 作成するレポートのタイプをクリックします。

図32-59 に、使用可能なレポート・タイプを示します。

図32-59 Oracle BPM Worklistのレポート

3. パラメータを入力して、レポートの検索パラメータを定義します。

図32-60 に、不参加タスク・レポートの入力ページの例を示します。他のレポートも同様です。すべてのレポート・タイプの入力パラメータについては、表32-12 を参照してください。

図32-60 不参加タスク・レポート: タスク分析のための入力ページ

4. 「実行」をクリックします。

32.12.2 レポート作成時の処理内容

図32-61 に示すように、(すべてのレポート・タイプについて)レポート結果は表形式と棒グラフ形式の両方で表示されます。レポートの実行に使用した入力パラメータは、左下隅の「レポート入力」に表示されます(表示するためにスクロールが必要な場合があります)。

図32-61 レポート表示: 表形式、棒グラフ形式および「レポート入力」

32.12.2.1 不参加タスク・レポート

図32-62 に、不参加タスク・レポートの例を示します。

図32-62 不参加タスク・レポート

このレポートは、Californiaグループに15件、Supervisorグループに7件、LoanAgentGroupに11件の不参加タスクがあることを示しています。このレポートでは、不参加(未申告)タスクはすべてDocumentReviewタスクです。レポートの実行時に複数のタイプの不参加タスクが存在する場合は、すべてのタスク・タイプがレポートに含まれ、それぞれのタスク・タイプが異なる色で表示されます。

32.12.2.2 タスクの優先度レポート

図32-63 に、タスクの優先度レポートの例を示します。

図32-63 タスクの優先度レポート

このレポートは、Californiaグループ、SupervisorグループおよびLoanAgentGroupに標準優先度のタスクがそれぞれ16件あることを示しています。ユーザーrstevenとjcooperのタスクはそれぞれ5件と22件で、いずれも標準優先度です。棒グラフでは、優先度(最高、高、標準、低、最低)が異なる色で区別されます。

32.12.2.3 タスクのサイクル・タイム・レポート

図32-64 に、タスクのサイクル・タイム・レポートの例を示します。

図32-64 タスクのサイクル・タイム・レポート

このレポートは、DocumentReviewタスクが完了するまでの平均所要時間が1時間6分、VacationApprovalタスクが完了するまでの平均所要時間が1時間28分であることを示しています。棒グラフには、平均サイクル・タイムがミリ秒単位で表示されます。

32.12.2.4 タスクの生産性レポート

図32-65 に、タスクの生産性レポートの例を示します。

図32-65 タスクの生産性レポート

このレポートは、California、LoanAgentGroupおよびSupervisorの各グループに割当て済のタスク数を示しています。ユーザー別では、jcooperに22件のタスクが割り当てられています。jcooperには、割当て済タスクに加えて、完了したタスクも2件あります。また、mtwainとrstevenには完了したタスクがそれぞれ6件と11件あることを示しています。棒グラフでは、2つのタスクの状態(「割当て済」と「完了」)が異なる色で区別されます。

注意:

「自分とグループ」および「報告先」オプションは、生産性レポートから削除されました。

32.13 Oracle BPM Worklistへのローカル言語およびタイムゾーンによるアクセス

ユーザーの優先ワークリスト言語は、アイデンティティ・ストアまたはブラウザから構成されます。

ユーザーの優先タイムゾーンは、アイデンティティ・プロバイダから構成します。

プリファレンス情報が使用できない場合、ユーザーの優先言語とタイムゾーンはシステム・デフォルトによって決定されます。システム・デフォルトは、言語とタイムゾーンのサーバー設定に基づいています。

ブラウザ・ロケールのカスタム・リソース・バンドル・クラスが使用できず、デフォルト・サーバー・ロケールのカスタム・リソース・バンドル・クラスが使用できる場合、言語は、デフォルト・サーバー・ロケールのカスタム・リソース・バンドル・クラスから導出されます。デフォルト・サーバー・ロケールのカスタム・リソース・バンドル・クラスも使用できない場合、言語はカスタム・ベース・クラスから導出されます。

ユーザー言語設定が設定されていない場合、またはOracle BPM Worklistでサポートされていない言語に設定されている場合、ワークリスト・アプリケーションの言語はデフォルトで英語に設定されます。

ワークリスト・インタフェースで「ブラウザ」または「アイデンティティ・プロバイダ」を選択する手順については、次の各項を参照してください。

- ログイン・ページ・レルムのラベルを指定する方法(アプリケーション・プリファレンス・ページで「ブラウザ」または「アイデンティティ・プロバイダ」を選択する方法)

- 「タスク・リスト・ページのカスタマイズ」および図32-14

32.13.1 Oracle BPM Worklist内の文字列

ワークリストのほとんどの文字列は、ワークリスト・アプリケーション・バンドルから取得されます。デフォルトでは、これは次のクラスです。

oracle.bpel.services.workflow.resource.WorkflowResourceBundle

ただし、適切なアプリケーション・プリファレンスの設定(リソース・バンドルを指定する方法を参照)か、またはデフォルトのバンドル・クラスの更新済バージョンを指定すると、カスタム・リソース・バンドルに変更できます。詳細は、ワークフローのカスタマイズのサンプルを参照してください。

タスク属性名、マップ済属性のラベルおよびDynamic Assignment Function名に関しては、文字列はリソース・プロパティ・ファイルWorkflowLabels.propertiesの構成により取得されます。このファイルは、サービス構成ディレクトリのwfresourceサブディレクトリに存在します。このファイルに対してDynamic Assignment Functionおよび属性ラベル用にエントリを追加する方法は、「ヒューマン・ワークフロー・サービスの概要」を参照してください。

カスタム・アクションおよびタスクのタイトルの表示名は、タスク構成ファイルに指定されているメッセージ・バンドルから取得されます。メッセージ・バンドルが指定されていない場合は、設計時に指定された値が使用されます。カスタム・アクションおよびタスクのタイトルを優先言語で表示するためにメッセージ・バンドルを指定する方法については、「ヒューマン・ワークフロー・サービスの概要」を参照してください。

注意:

ヒューマン・タスク名にハングル文字は使用できません。ヒューマン・タスク名にはハングル文字のかわりにA-Z、a-z、0-9および"_"の文字のみを使用することをお薦めします。

32.13.2 アイデンティティ・ストアがLDAPベースである場合の優先言語、ユーザーの表示名およびタイムゾーン設定の変更方法

Oracle Internet DirectoryなどのLDAPベース・プロバイダが使用されている場合、Oracle Internet Directoryコミュニティの言語設定が変更されます。組込みLDAPサーバーに接続し、Oracle Internet Directoryコミュニティの言語設定を変更します。

1. LDAPブラウザを起動します(例: openLdapブラウザ、ldapbrowser、jXplorerなど)。起動方法は、ブラウザのドキュメントを参照してください。

2. サーバーが実行されているホスト名とポート番号、およびログインする管理ユーザーの資格証明を指定して、LDAPサーバーに接続します。

- 組込みLDAPの場合:

a. 管理対象サーバーのデフォルトのポート番号は7001です。

b. 管理資格証明のユーザー名はcn=adminです。

c. 管理パスワード資格証明にアクセスするには、Oracle WebLogic Server管理コンソールから、ドメインに対して「セキュリティ」→「組込みLDAP」の順に選択します。
デフォルトのパスワード資格証明の変更手順については、『Oracle WebLogic Serverセキュリティの管理』の第9章「組込みLDAPサーバーの管理」を参照してください。

- Oracle Internet Directoryの場合:

a. デフォルトのポート番号は3060です。

b. 管理ユーザー名はcn=orcladminです。

c. 管理パスワードはLDAPサーバーのパスワードです。

3. ユーザーの優先言語を変更するには、ユーザー・エントリに移動して、preferredLanguage属性を追加または設定します。サポートされている言語のリストは、表32-13 を参照してください。
ユーザー名を表示する言語を決定することもできます。このタスクを実行するには、LDAPディレクトリのユーザー・エントリに移動して、displayname属性を追加または指定します。ただし、ワークリストの「割当て先」列に表示されるユーザー名については、displayname属性の設定は優先されません。

タイムゾーン設定を変更するには、orclTimeZone属性を追加または設定します。タイムゾーン文字列の書式は「大陸/地域」です。$JAVA_HOME/jre/lib/ziディレクトリでタイムゾーン値を確認できます。ディレクトリで大陸名(Africa、Asia、Americaなど)を指定し、ディレクトリ内のファイルで地域を指定します。地域によっては、America/Indiana/Indianapolisのようにサブ地域が含まれる場合があります。

ユーザーがログインすると、ワークリストのページは、ユーザーの優先言語とタイムゾーンで表示されます。

32.13.3 タスク表示に使用する言語の変更方法

より高いパフォーマンスを得るため、Oracle Enterprise Manager Fusion Middleware Controlの「システムMBeanブラウザ」のLocaleListプロパティには、英語のみがリストされています。タスクのタイトル、カテゴリまたはサブカテゴリの他言語表示や言語の追加が必要な場合は、「システムMBeanブラウザ」で、言語のロケールを変更する必要があります。

注意:

すべての言語を最初に追加する必要があります。後で他の言語を追加しても、以前に他の言語で記述されたタスクはワークリストには表示されなくなります。たとえば、以前に指定されていた言語が英語で、その後フランス語を追加した場合、フランス語の追加前に記述されたタスクはワークリストには表示されなくなります。

言語を追加または変更する手順は、次のとおりです。

1. Oracle Enterprise Manager Fusion Middleware Controlのナビゲータで、soa-infraを右クリックし、「管理」→「システムMBeanブラウザ」を選択します。

2. 「アプリケーション定義のMBeans」、oracle.as.soainfra.config、「サーバー: server_name」、「WorkflowConfig」の順に展開します。

3. 「human-workflow」をクリックします。
言語を変更する手順は、次のとおりです。

a. 「名前」列で、「LocaleList」をクリックします。

b. 「値」フィールドで、値をクリックします。

c. 「名前」列で、「言語」をクリックします。

d. 「値」フィールドのenを、使用する言語の値に変更します。

e. 「適用」をクリックします。

言語を追加する手順は、次のとおりです。

a. 「操作」タブをクリックします。

b. 「名前」列で、「createLocale」をクリックします。

c. 「値」フィールドに値を入力します。より高いパフォーマンスを得るため、タスクのタイトル、カテゴリ、サブカテゴリで使用する言語のみを含めてください。

d. 「起動」をクリックします。

32.13.4 JAZN XMLファイルからの言語設定の変更方法

JAZN XMLファイルで、太字で示された部分を変更しユーザーの優先言語を設定します。

<preferredLanguage>en</preferredLanguage>

Oracle BPM Worklistでは、表32-13 に示す言語がサポートされています。

表32-13 Oracle BPM Worklistでサポートされている言語

言語

書式

英語

(en)

フランス語

(fr)

ドイツ語

(de)

スペイン語(インターナショナル)

(es)

イタリア語

(it)

ポルトガル語(ブラジル)

(pt-BR)

日本語

(ja)

韓国語

(ko)

中国語(繁体字)

(zh-TW)

中国語(簡体字)

(zh-CN)

アラビア語

(ar)

チェコ語

(cs)

デンマーク語

(da)

オランダ語

(nl)

フィンランド語

(fi)

ギリシャ語

(el)

ヘブライ語

(he)

ハンガリー語

(hu)

ノルウェー語

(no)

ポーランド語

(po)

ポルトガル語

(pt)

ルーマニア語

(ro)

ロシア語

(ru)

スロバキア語

(sk)

スウェーデン語

(sv)

タイ語

(th)

トルコ語

(tr)

フランス語(カナダ)

(fr-CA)

32.13.5 ワークリストでの表示言語の設定に関する必知事項

Oracle BPM Worklistは、ブラウザまたはアイデンティティ・ストア(LDAP)から言語を設定するよう構成できます。この設定には、アプリケーション・レベルとユーザー・レベルの2つのレベルがあります。ユーザー・プリファレンスが、ユーザー設定のLDAPとして設定されている場合は、ワークリストの表示言語が決定される際にこの設定が優先されます。LDAPで言語を設定しない場合、ワークリストは、サーバー・ロケールとしてデフォルトの言語に従います。ただし、電子メール通知は、常にLDAPで設定された言語に従います。LDAPで言語が設定されていない場合、電子メール通知は、サーバー・ロケールに従います。

32.13.6 ワークリストで使用するタイムゾーンの変更方法

次の説明は、JAZN XMLファイルからユーザーのタイムゾーンを抽出する方法に基づいています。

タイムゾーンを変更する手順は、次のとおりです。

ユーザーの優先タイムゾーンを設定するには、太字部分を変更します。

<timeZone>America/Los_Angeles</timeZone>

タイムゾーン文字列の形式は、大陸/地域です。$JAVA_HOME/jre/lib/ziディレクトリでタイムゾーン値を確認できます。ディレクトリが大陸名(たとえば、Africa、Asia、Americaなど)を示し、ディレクトリ内のファイルが地域を示します。地域によっては、America/Indiana/Indianapolisのようにサブ地域が含まれる場合があります。

32.14 再利用可能なワークリスト・リージョンの作成

ワークリストで使用可能な一部の機能は、アプリケーションに埋め込むことができるスタンドアロン再利用可能コンポーネントとして公開されています。さらに、これらのスタンドアロン・タスク・フローにより、パラメータを使用した多くのカスタマイズ機能が提供されるため、ユーザーは要件にあわせてワークリスト・アプリケーションを作成してカスタマイズできます。すべてのタスク・フローは、埋込みアプリケーションに含めることができるADFライブラリにバンドルされます。

32.14.1 埋込みの再利用可能なワークリスト・リージョンを使用したアプリケーションの作成方法

再利用可能な各ワークリスト・リージョンの使用方法は通常のワークリスト・リージョンと同じですが、いくつかの例外があります。次の手順では、アプリケーションを作成してタスク・リスト・タスク・フローをアプリケーションに埋め込むステップについて詳細に説明します。可能な場合は、他のタイプの再利用可能なワークリスト・リージョンの使用方法についても説明しています。

埋込みの再利用可能なワークリスト・リージョンを使用してアプリケーションを作成する手順は、次のとおりです。

1. Oracle JDeveloperで新規のFusion Webアプリケーションを作成します。この例では、アプリケーションの名前はTaskListTaskFlowSampleです。図32-66に詳細を示します。

図32-66 埋込みの再利用可能なワークリスト・リージョンを使用したアプリケーションの作成

2. ビュー・コントローラの「プロジェクト・プロパティ」を開き、「ライブラリとクラスパス」セクションで「ライブラリの追加」をクリックして、次のライブラリをクラスパスに追加します。

- BPMワークリスト・コンポーネント: このライブラリを追加して、タスク・フローJAR adflibTaskListTaskFlow.jarおよびadflibWorklistComponents.jarを追加します。これらはプロジェクトのクラスパスで必要です。

- BPMサービス

- WSRPコンテナ

図32-67に詳細を示します。

図32-67 「ライブラリとクラスパス」セクション

3. アプリケーションが非SOAサーバーで実行されている場合は、次の2つのステップを実行する必要があります。

a. oracle.soa.workflow共有ライブラリをインストールします。
サーバーにoracle.soa.workflow.wcがすでにインストールされている場合、oracle.soa.workflowのインストールは不要です。

b. サーバーで外部JNDIを構成します。
タスク・リスト・タスク・フローをフェデレーテッド・モードで実行する場合、このステップは不要です。タスク・フローをフェデレーテッド・モードで使用する方法の詳細は、「タスク・リスト・タスク・フローに関する必知事項」の「federatedMode」を参照してください。

4. ビュー・コントローラ・プロジェクトを選択し、「ファイル」→「新規」→「現在のプロジェクト・テクノロジ」→「Web層」→「JSFページ」の順に選択して、jspxファイル(例: testSample.jspx)を作成します。
「JSFページの作成」ダイアログでは、必ず「XMLドキュメントの作成(*.jspx)」を選択してください。

5. 「コンポーネント」ウィンドウから「adflibTaskListTaskFlow.jar」を選択します。すべてのタスク・フローとリージョンのリストが含まれます。図32-68に詳細を示します。

図32-68 「コンポーネント」ウィンドウ

6. タスク・フロー・リージョンの1つをjspxページにドラッグ・アンド・ドロップし、「作成」メニューから「リージョン」を選択します(例: タスク・リスト・タスク・フローの場合はtaskList-task-flow-definition)。
タスク・フロー定義の詳細は、次の各項を参照してください。

- タスク・リスト・タスク・フローに関する注意事項

- 証明書タスク・フローに関する注意事項

- レポート・タスク・フローに関する注意事項

- アプリケーション・プリファレンス・タスク・フローに関する注意事項

- マップ済属性タスク・フローに関する注意事項

- ルール・タスク・フローに関する注意事項

- 承認グループ・タスク・フローに関する必知事項

- タスク構成タスク・フローに関する必知事項

7. flex-fields-task-flow-definition、rules-task-flow-definition、tasklist-reports-task-flow-definitionまたはtaskList-task-flow-definitionを選択した場合は、表示される「タスク・フロー・バインディングの編集」ダイアログでタスク・フロー・パラメータを渡します。

8. 新しいエントリがpagenamePagedef.xmlファイルに追加されます。
たとえば、taskList-task-flow-definitionを追加すると、新しいエントリは次のようになります。

<taskFlow id="taskListtaskflowdefinition1"
taskFlowId="/WEB-INF/taskList-task-flow-definition.xml#taskList-task- flow-definition"
xmlns="http://xmlns.oracle.com/adf/controller/binding">
<parameters>
<parameter id="taskFlowMode" value="MODE_WORKLIST"/>
<parameter id="showTaskDetailsPanel" value="true"/>
<parameter id="showActionDropdown" value="true"/>
<parameter id="showViewFilter" value="true"/>
<parameter id="showStatusFilter" value="true"/>
<parameter id="showSearchControl" value="true"/>
</parameters>
</taskFlow>

9. weblogic-application.xmlファイルの共有ライブラリを追加します。oracle.soa.workflow.wcをサーバーにインストールしている場合は、そのライブラリを追加します。

<library-ref>
<library-name>oracle.soa.workflow</library-name>
</library-ref>

生成されたカスタム・アプリケーションがモジュールの場合、weblogic.xmlを使用します。

<library-ref>
<library-name>oracle.soa.worklist.webapp</library-name>
</library-ref>

アプリケーションをデプロイする前に、「デプロイメント・プロファイルの設定方法」を参照してください。

32.14.2 デプロイメント・プロファイルの設定方法

アプリケーションをデプロイする前に、デプロイメント・プロファイルを編集する必要があります。

デプロイメント・プロファイルを編集する手順は、次のとおりです。

1. View Controllerプロジェクトを選択し、「ファイル」→「新規作成」→「一般」→「デプロイメント・プロファイル」を選択します。「WARファイル」を選択し、「OK」をクリックします。

2. 「WEB-INF/lib」→「フィルタ」の順に選択し、adflibTaskListTaskFlow.jar、adflibWorklistComponents.jarおよびwsrp-container.jarを選択します。

32.14.3 フェデレーテッド・モードのタスク・フローのデプロイメント準備

タスク・フローをフェデレーテッド・モードで使用する場合は、フェデレーテッド・サーバーのリストをタスク・フローに渡す必要があります。詳細は、「タスク・リスト・タスク・フローに関する必知事項」の「federatedMode」を参照してください。

タスク・フローをフェデレーテッド・モードで使用する場合は、フェデレーテッド・サーバー間でグローバル・トラストを有効にします。これにより、すでに認証されたユーザー・トークンが、タスク・フローに渡されたすべてのフェデレーテッド・サーバーに渡されます。

すべてのフェデレーテッド・サーバーで次の手順を実行して、すべてのサーバーを再起動します。すべてのサーバーを再起動することが非常に重要です。

サーバーを再起動する手順は、次のとおりです。

1. Oracle WebLogic Serverコンソールにログインします。

2. 「ドメイン構造」からドメイン名soainfraを選択します。SOAサーバーを使用していない場合は、ドメイン名が異なる場合があります。

3. 「セキュリティ」タブを選択します。

4. 「詳細」リンク(下部の「保存」ボタンの近くにあります)を選択します。

5. 「資格証明」フィールドにパスワードを入力します。(すべてのフェデレーテッド・サーバーで同じパスワードを使用する必要があります)。

6. 「保存」をクリックします。

7. サーバーを再起動します。

32.14.4 タスク・リスト・タスク・フローに関する必知事項

タスク・リスト・タスク・フローでは、埋込みリージョンの表示動作を制御するためのパラメータを指定します。図32-69に詳細を示します。

図32-69 タスク・リスト

次に、パラメータの一部を示します。

- federatedMode

- federatedServers

- showServerColumn

- wfCtxID

federatedMode

trueとして渡された場合、タスク・リストはフェデレーテッド・モードで表示されます。タスク・フローをフェデレーテッド・モードで実行するには、フェデレーテッド・サーバーのリストをタスク・フローに渡す必要があります。次のいずれかの方法で、フェデレーテッド・サーバーのリストをタスク・フローに渡すことができます。

- クライアント構成ファイルwf_client_config.xmlをクラス・パス(EARレベルのAPP-INF\classes\wf_client_config.xmlまたはWebアプリケーションのWEB-INF\classes)に含めます。クライアント構成ファイルには、すべてのフェデレーテッド・サーバーの詳細が含まれています。

- フェデレーテッド・サーバー・リストを格納したJAXBオブジェクトを作成します。このJAXBオブジェクトは、federatedServersパラメータを使用してタスク・フローに渡すことができます。JAXBオブジェクトの作成方法については、次の「federatedServers」を参照してください。

クライアント構成ファイル(wf_client_config.xml)とJAXBオブジェクトの両方がタスク・フローに渡された場合は、JAXBオブジェクトが優先されます。

federatedServers

タスク・フローがフェデレーテッド・モードで実行される場合、このパラメータは、サーバーのリストが含まれるJAXBオブジェクトです。クライアント構成ファイル(wf_client_config.xml)も渡された場合は、このパラメータが優先されます。JAXBオブジェクト(WorkflowServicesClientConfigurationType)の作成方法の詳細は、次のコード・サンプルを参照してください。

次のコード・サンプルに示すように、サーバーの1つをdefaultとして設定する必要があります。デフォルトとして指定する必要があるのは1つのサーバーのみです。また、デフォルトとして指定したサーバーが、フェデレーテッド・サーバーのリストから除外されていることを確認してください。次の例では、これに関連するコードが太字で表示されています。

デフォルト・サーバーが使用されるのは、wf_client_config.xmlまたはJAXBオブジェクトに複数のサーバーが定義されているが、ワークフロー・クライアントで1つのサーバーのみ必要な場合です。サーバー名をパラメータとして使用しないレガシーのAPIがいくつかあります。このようなレガシーのAPIをサポートするには、1つのサーバーをデフォルト・サーバーとして定義する必要があります。そうしないと、サーバー名を使用しないレガシーのAPIは機能しません。

import oracle.bpel.services.workflow.client.config.IdentityPropagationType;
import oracle.bpel.services.workflow.client.config.PolicyReferenceType;
import oracle.bpel.services.workflow.client.config.PolicyReferencesType;
import oracle.bpel.services.workflow.client.config.RemoteClientType;
import oracle.bpel.services.workflow.client.config.ServerType;
import oracle.bpel.services.workflow.client.config.SoapClientType;
import oracle.bpel.services.workflow.client.config.WorkflowServicesClientConfigurationType;

WorkflowServicesClientConfigurationType wscct =
new WorkflowServicesClientConfigurationType();

List<ServerType> servers = wscct.getServer();

/**** Setting default server in the list ****/

ServerType defalutServer = new ServerType();
servers.add(defalutServer);

defalutServer.setDefault(true);
defalutServer.setExcludeFromFederatedList(true);
defalutServer.setName("default");

RemoteClientType rct = new RemoteClientType();
rct.setServerURL("t3://myhost.us.example.com:7001");
rct.setInitialContextFactory("weblogic.jndi.WLInitialContextFactory");
rct.setParticipateInClientTransaction(false);
defalutServer.setRemoteClient(rct);

SoapClientType sct = new SoapClientType();
PolicyReferencesType prts = new PolicyReferencesType();

PolicyReferenceType prt = new PolicyReferenceType();
prt.setEnabled(true);
prt.setCategory("security");
prt.setUri("oracle/wss10_saml_token_client_policy");
prts.getPolicyReference().add(prt);

IdentityPropagationType ipt = new IdentityPropagationType();
ipt.setMode("dynamic");
ipt.setType("saml");
ipt.setPolicyReferences(prts);

sct.setRootEndPointURL("http://myhost.us.example.com:7001");
sct.setIdentityPropagation(ipt);

defalutServer.setSoapClient(sct);

/****** Setting Federated Server 1 to the list ****/

ServerType server1 = new ServerType();
servers.add(server1);
server1.setName("Human Resource");

RemoteClientType rct1 = new RemoteClientType();
rct1.setServerURL("t3://myhost.us.example.com:7001");
rct1.setInitialContextFactory("weblogic.jndi.WLInitialContextFactory");
rct1.setParticipateInClientTransaction(false);
server1.setRemoteClient(rct1);

SoapClientType sct1 = new SoapClientType();
PolicyReferencesType prts1 = new PolicyReferencesType();

PolicyReferenceType prt1 = new PolicyReferenceType();
prt1.setEnabled(true);
prt1.setCategory("security");
prt1.setUri("oracle/wss10_saml_token_client_policy");
prts1.getPolicyReference().add(prt1);
IdentityPropagationType ipt1 = new IdentityPropagationType();
ipt1.setMode("dynamic");
ipt1.setType("saml");
ipt1.setPolicyReferences(prts1);

sct1.setRootEndPointURL("http://myhost.us.example.com:7001");
sct1.setIdentityPropagation(ipt1);

server1.setSoapClient(sct1);

/****** Setting Federated Server 2 to the list ****/

ServerType server2 = new ServerType();
servers.add(server2);
server2.setName("Financials");

RemoteClientType rct2 = new RemoteClientType();
rct2.setServerURL("t3://myhost.us.example.com:7001");
rct2.setInitialContextFactory("weblogic.jndi.WLInitialContextFactory");
rct2.setParticipateInClientTransaction(false);
server2.setRemoteClient(rct2);

SoapClientType sct2 = new SoapClientType();
PolicyReferencesType prts2 = new PolicyReferencesType();

PolicyReferenceType prt2 = new PolicyReferenceType();
prt2.setEnabled(true);
prt2.setCategory("security");
prt2.setUri("oracle/wss10_saml_token_client_policy");
prts2.getPolicyReference().add(prt2);

IdentityPropagationType ipt2 = new IdentityPropagationType();
ipt2.setMode("dynamic");
ipt2.setType("saml");
ipt2.setPolicyReferences(prts2);

sct2.setRootEndPointURL("http://myhost.us.example.com:7001");
sct2.setIdentityPropagation(ipt2);

server2.setSoapClient(sct2);

showServerColumn

タスク・フローがフェデレーテッド・モードで実行される場合、デフォルトではタスク・リストのサーバー列は表示されません。サーバー列を表示する場合は、このパラメータをtrueで渡します。それ以外の場合、サーバー列は表示されません。

wfCtxID

これはワークフロー・コンテキストのトークン文字列です。ワークフロー・コンテキストをタスク・フロー内部に作成する場合に使用します。アプリケーションがSSO対応の場合、またはアプリケーションがADFセキュリティを使用して保護されている場合、このパラメータは必要ありません。それ以外の場合、これは必須パラメータです。次のコード・サンプルに、ワークフロー・コンテキストIDを取得する方法を示します。

IWorkflowContext wfCtx =  wfSvcClient.getTaskQueryService().authenticate(username,password,realm,null);
wfCtxID = wfCtx.getToken();

32.14.5 証明書タスク・フローに関する必知事項

次の図に示すように、ユーザーは意思決定の署名に使用する証明書をアップロードできます。証明書を使用してタスクの結果に署名する際は、証明書発行者から発行された1つの証明書のみではなく、証明書チェーン全体をOracle BPM Worklistから.P7B (PKCS7形式)ファイルとしてアップロードする必要があります。

デジタル証明書には、証明書発行者のデジタル署名が記載されているため、誰でも証明書が本物であることを確認できます。参加者の資格証明は、デジタル証明書によって証明されます。これは認証局(CA)が発行します。ユーザー名、シリアル番号、有効期限、証明書所有者の公開鍵のコピー(メッセージとデジタル署名の暗号化に使用)、および証明書発行者のデジタル署名が記載されているため、受信者は証明書が本物であることを確認できます。

証明書タスク・フローにパラメータはありません。図32-70に詳細を示します。

図32-70 デジタル証明書

32.14.6 レポート・タスク・フローに関する必知事項

図32-71 に、不参加タスク・レポートを示します。

図32-71 不参加タスク・レポート

次に、タスク分析に使用できるワークリスト・レポートを示します。

不参加タスク

不参加タスク・レポートでは、ユーザーのグループまたは報告先のグループに割り当てられたタスクの中で、まだ獲得されていないタスク(不参加タスク)が分析されます。

- 割当て先 - (必須)このオプションでは、ユーザーのグループに割り当てられたタスク(グループ)、報告先のグループに割り当てられたタスク(「報告先」)、ユーザーが作成者であるタスク(「作成者」)、またはユーザーが所有者であるタスク(「所有者」)を選択します。

- 作成日 - (オプション)日付範囲。

- 有効期限 - (オプション)日付範囲。

- タスクの状態 - (オプション)状態は、「任意」、「割当て済」、「期限切れ」または「情報のリクエスト中」のいずれかです。

- 優先度 - (オプション)優先度は、「任意」、「最高」、「高」、「標準」、「低」または「最低」のいずれかです。

タスクの優先度

タスクの優先度レポートでは、ユーザー、報告先またはそのグループに割り当てられたタスクの数が優先度別に分析されます。

- 割当て先 - (必須)このオプションには、選択した割当て先に応じて、ログイン・ユーザーに割り当てられたタスク(「個人」)、ユーザーとそのユーザーが所属するグループに割り当てられたタスク(「個人とグループ」)、または、ユーザーの報告先が所属するグループに割り当てられたタスク(「報告先」)が含まれます。

- 作成日 - (オプション)日付範囲。

- 終了日 - (オプション)レポートに含まれるタスクの終了日の日付範囲。

- 優先度 - (オプション)優先度は、「任意」、「最高」、「高」、「標準」、「低」または「最低」のいずれかです。

タスクのサイクル・タイム

タスクのサイクル・タイム・レポートでは、ユーザーのグループまたは報告先のグループに基づいて、タスクの割当てから完了までの所要時間が分析されます。

- 割当て先 - (必須)このオプションには、選択した割当て先に応じて、自分のタスク(「個人」)、またはユーザーの報告先が所属するグループに割り当てられたタスク(「報告先」)が含まれます。

- 作成日 - (オプション)日付範囲。

- 終了日 - (オプション)レポートに含まれるタスクの終了日の日付範囲。

- 優先度 - (オプション)優先度は、「任意」、「最高」、「高」、「標準」、「低」または「最低」のいずれかです。

タスクの生産性

タスクの生産性レポートでは、ユーザー、報告先またはグループについて、特定期間中に割り当てられたタスク数と完了したタスク数が分析されます。

- 割当て先 - (必須)このオプションには、選択した割当て先に応じて、ユーザーのタスク(「個人とグループ」)、またはユーザーの報告先が所属するグループに割り当てられたタスク(「報告先」)が含まれます。

- 作成日(範囲) - (オプション)作成日の日付範囲。デフォルト値は1週間です。

- タスク・タイプ - 「検索」(懐中電灯)アイコンを使用して、タスクのタイトルのリストから選択します。「ワークフロー・タスク・タイプの選択」ページに、タスクのすべてのバージョンがリストされます(オプション)。

タスク時間分布

タスク時間分布レポートには、割当て先がタスクを実行するのに要した時間が表示されます。

- 割当て先 - (必須)このオプションには、選択した割当て先に応じて、ユーザーのタスク(「個人とグループ」)、またはユーザーの報告先が所属するグループに割り当てられたタスク(「報告先」)が含まれます。

- 開始...終了(日付範囲) - (オプション)作成日の日付範囲。デフォルト値は1週間です。

- タスク・タイプ - 「検索」(懐中電灯)アイコンを使用して、タスクのタイトルのリストから選択します。「ワークフロー・タスク・タイプの選択」ページに、タスクのすべてのバージョンがリストされます(オプション)。

32.14.7 アプリケーション・プリファレンス・タスク・フローに関する必知事項

ワークリストの外観は、アプリケーション・プリファレンスを使用してカスタマイズします。管理者は次の値を指定できます。

- ログイン・ページ・レルムのラベル: アイデンティティ・サービスが複数のレルムで構成されている場合は、Oracle BPM Worklistのログイン・ページにレルム名のリストが表示されます。LABEL_LOGIN_REALMは、これらのレルムを表示するラベルのルックアップに使用するリソース・バンドル・キーを指定します。realm(レルム)という語は、ユーザー・コミュニティにあわせて変更できます。たとえば、country(国)、company(会社)、division(部)、department(部門)などの方が適切な場合があります。管理者は、リソース・バンドルをカスタマイズし、この文字列にリソース・キーを指定して、このパラメータがリソース・キーを指し示すように設定できます。

- グローバル・ブランド・アイコン: これは、ワークリストの各ページの左上隅に表示されるイメージです。(Oracleロゴがデフォルトです。)管理者は、ロゴに使用する.gif、.pngまたは.jpgファイルを提供できます。このファイルはpublic_htmlディレクトリに置く必要があります。

- リソース・バンドル: アプリケーション・リソース・バンドルは、ワークリストに表示される文字列を指定します。デフォルトでは、これはoracle.bpel.worklistapp.resource.WorklistResourceBundleのクラスです。図32-72に詳細を示します。

図32-72 アプリケーション・プリファレンス

32.14.8 マップ済属性タスク・フローに関する必知事項

ヒューマン・ワークフローのマップ済属性での格納と問合せでは、状況固有のカスタム属性が使用されます。これらのカスタム属性は、通常、タスク・ペイロード値に基づきます。マップ済属性にカスタム属性を格納すると、次の利点が得られます。

- フレックス・フィールドをタスク・リストの列として表示できます。

- フレックス・フィールドでは、カスタム・ビューおよび拡張検索でタスクをフィルタ処理できます。

- フレックス・フィールドは、キーワードベースの検索で使用できます。

たとえば、タスクの注文書リクエスト・ペイロードのRequester、PurchaseOrderIDおよびAmountフィールドをマップ済属性に格納できます。Oracle BPM Worklistにログインした承認者は、これらのフィールドの値をタスク・リスト内の列で確認して、アクセスするタスクを決定できます。ユーザーは、マップ済属性に基づいてタスクをフィルタ処理するビューを定義できます。

たとえば、ユーザーは、異なる金額範囲に基づいて発注書の承認用ビューを作成できます。ユーザーがある時点で特定のリクエスタまたは発注書IDに関連するタスクを取得することも必要になった場合、キーワード・フィールドにそのリクエスタまたは発注書IDを指定して検索を実行することによって、関連するタスクを取得できます。図32-73に詳細を示します。

図32-73 マップ済属性マッピング

32.14.9 ルール・タスク・フローに関する必知事項

ルールを使用してタスクを操作します。タスクは、特定のタスク・タイプ、またはユーザーやグループに割り当てられた全タスクのいずれかです。次の図に、休暇ルールも含めて、ルールを設定する場所を示します。

ルールは、そのルールが使用されるすべての環境で常に適用できるわけではありません。たとえば、ルールが複数のタスク・タイプに適用される場合は、タスクによって結果が異なるため、すべてのタスクに結果を設定できない場合があります。

ルールはリストされている順序で実行されます。ルールはヘッダーの上下ボタンを使用して順序を変更できます。あるルールがフィルタ条件に一致すると、そのルールが実行され、他のルールは評価されません。ルールを実行するユーザーは、該当するタスクに割り当てられている唯一のユーザーであることが必要です。タスクが(自分を含めて)複数のユーザーに割り当てられている場合、ルールは実行されません。

showOtherUsersRulesパラメータはブール値を取ります。このパラメータがTrueとして渡されると他のユーザーのルールが表示され、Falseとして渡されると他のユーザーのルールは表示されません。さらに、ユーザーが他のユーザーのルールを表示するには、必要な権限が付与されている必要があります。図32-74 および図32-75 に詳細を示します。

図32-74 休暇期間

図32-75 ルール

32.14.10 承認グループ・タスク・フローに関する必知事項

承認グループは、静的に定義されたか、または動的に生成された承認者のリストです。承認グループは、通常、ワークリスト・アプリケーションを使用して、プロセス所有者によって構成されます。一般に、これらは、管理承認の前後にタスクを処理する必要がある、人事や弁護士などのトランザクションの権限の管理チェーンの外側の主題専門家をモデリングするのに使用されます。

静的な承認グループは事前定義済の承認者リストで、動的な承認グループはランタイムに承認者リストを生成します。動的な承認グループでは、次を実行する必要があります。

- 開発者による動的承認者リストのインタフェースに応じた実装の提供

- IT部門によるOracle BPM WorklistのUIを使用した動的な承認グループとしての実装の登録

- SOAクラス・パスの一部であり世界的に有名なディレクトリでの、クラス・ファイルの公開

32.14.11 タスク構成タスク・フローに関する必知事項

タスク構成は、ワークリスト・アプリケーション内のWebベース・アプリケーションで、ワークフロー設計者が事前に定義したルールをビジネス・ユーザーおよび管理者が確認および変更することが可能です。この事前定義済ルールは、特定の顧客向けに、適用可能な顧客企業ポリシーに基づいて変更できます。

たとえば、会社のポリシーで、1000を超える経費には2レベルの承認が必要であるとします。さらに、このポリシーが変更され、3レベルを必要とするようになったとします。IT部門が基礎となるプロセスでルールを変更し、再度デプロイするかわりに、タスク構成を使用してルールを変更できます。ルールの変更は次のインスタンスから適用され、すでに進行中のインスタンスでは現在のルール定義が使用されます。

タスク構成を使用すると、承認フローに関連付けられているイベント駆動ルールとデータ駆動ルールを、ワークフローのデプロイ後である実行時に編集できます。

32.15 ワークリスト・アプリケーションでカスタマイズされたアプリケーションを有効化するJavaコード

「カスタマイズされたアプリケーションおよびリンクを有効にする方法」では、ワークリスト・アプリケーションの「アプリケーション・プリファレンス」ページを使用してカスタム・アプリケーションを指定する方法について説明しています。この指定を実行するJavaコードは、次のとおりです。

package view.customisationimpl;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import oracle.bpel.services.workflow.client.IWorkflowServiceClient;
import oracle.bpel.services.workflow.runtimeconfig.IRuntimeConfigService;
import oracle.bpel.services.workflow.runtimeconfig.model.AttributeLabelType;
import oracle.bpel.services.workflow.runtimeconfig.model.AttributeLabelUsageList;
import oracle.bpel.services.workflow.runtimeconfig.model.AttributeLabelUsages;
import oracle.bpel.services.workflow.verification.IWorkflowContext;
import oracle.bpm.ui.customization.CustomLink;
import oracle.bpm.ui.customization.IBPMUICustomizations;

public class WorkspaceCustomisationImpl implements IBPMUICustomizations {
private static Map displayNameMap = new HashMap();
public WorkspaceCustomisationImpl() {
displayNameMap.put("instanceId", "Instance Id");
displayNameMap.put("protectedTextAttribute1", "Business Status");
}
public List<CustomLink> getCustomGlobalLinks() {
CustomLink globalLink1 =
new CustomLink("Oracle Home Page", "www.oracle.com", null);
CustomLink globalLink2 =
new CustomLink("Self Services Application", "http://global-ebusiness.example.com/",
null);
CustomLink globalLink3 =
new CustomLink("BUG DB", "https://bug.example.com/", null);
List<CustomLink> globalLinks = new ArrayList<CustomLink>();
globalLinks.add(globalLink1);
globalLinks.add(globalLink2);
globalLinks.add(globalLink3);
return globalLinks;
}
public String getColumnNames() {
return "title,taskNumber,instanceId,creator,protectedTextAttribute1";
}

private static void initDisplayMap(IWorkflowServiceClient client,
IWorkflowContext context) {
// you can use service to load all label namess for text attributes
if (displayNameMap == null) {
synchronized (String.class) {
if (displayNameMap == null) {
displayNameMap = new HashMap();
try {
IRuntimeConfigService service =
client.getRuntimeConfigService();
AttributeLabelUsageList list =
service.getAttributeLabelUsages(context, "Text");
List<AttributeLabelUsages> list1 =
list.getAttributeLabelUsages();
for (AttributeLabelUsages usage : list1) {
AttributeLabelType type = usage.getLabel();
displayNameMap.put(type.getTaskAttribute(),
type.getLabelName());
}
} catch (Exception exc) {
}
}
}
}
}

public String getColumnDisplayName(IWorkflowServiceClient client,
IWorkflowContext context,
java.lang.String colName) {
initDisplayMap(client, context);
return (String)displayNameMap.get(colName);
}
}

1
To Doタスクには無効です

2
To Doタスクにのみ有効です

[3]
アラート済状態のタスクにのみ適用可能です

4
現在の割当て先のマネージャへの申告およびエスカレートはありません

5
申告はありません

33 カスタム・ワークリスト・クライアントの作成

この章では、サンプルのワークリスト・アプリケーションをはじめとして、開発者がワークフロー・サービスにより公開されたAPIを使用してワークフロー・サービスのクライアントを作成する方法について説明します。このAPIにより、クライアントは、リモートのEJB、SOAPおよびHTTPを使用してワークフロー・サービスと通信できるようになります。

この章の内容は次のとおりです。

- ワークフロー・サービスのクライアント作成に関する概要

- クライアント作成に使用するパッケージとクラス

- ワークフロー・サービス・クライアント

- SOAPを使用するクライアント用のクラスパス

- リモートEJBを使用するクライアント用のクラスパス

- タスクの開始

- ワークフロー標準ビュー定義の変更

- HelpDeskUIサンプルを使用した記述

33.1 ワークフロー・サービスのクライアント作成に関する概要

次に、簡単なワークリスト・アプリケーションを作成する際の典型的なコール順序を示します。

簡単なワークリスト・アプリケーションを作成する手順は、次のとおりです。

1. IWorklistServiceClientへのハンドルをWorkflowServiceClientFactoryから取得します。

2. ITaskQueryServiceへのハンドルをIWorklistServiceClientから取得します。

3. ユーザー名とパスワードをITaskQueryServiceの認証メソッドに渡して、ユーザーを認証します。IWorkflowContextへのハンドルを取得します。

4. ITaskQueryServiceを使用してタスク・リストを問い合せます。

5. ITaskServiceへのハンドルをIWorklistServiceClientから取得します。

6. 返されたタスク・リストを反復し、ITaskServiceを使用してタスクに対するアクションを実行します。

次のコード・サンプルは、ワークフロー・サービスのクライアントの作成方法を示しています。jsteinに割り当てられている全タスクのリストに対して問合せが実行されます。結果が設定されていないタスクが承認されます。

try
{
//Create JAVA WorflowServiceClient
IWorkflowServiceClient  wfSvcClient = WorkflowServiceClientFactory.getWorkflowServiceClient(
WorkflowServiceClientFactory.REMOTE_CLIENT);
//Get the task query service
ITaskQueryService querySvc = wfSvcClient.getTaskQueryService();

//Login as jstein
IWorkflowContext ctx = querySvc.authenticate("jstein","welcome1".toCharArry(),null);
//Set up list of columns to query
List queryColumns = new ArrayList();
queryColumns.add("TASKID");
queryColumns.add("TASKNUMBER");
queryColumns.add("TITLE");
queryColumns.add("OUTCOME");

//Query a list of tasks assigned to jstein
List tasks = querySvc.queryTasks(ctx,
queryColumns,
null, //Do not query additional info
ITaskQueryService.AssignmentFilter.MY,
null, //No keywords
null, //No custom predicate
null, //No special ordering
0,    //Do not page the query result
0);
//Get the task service
ITaskService taskSvc = wfSvcClient.getTaskService();
//Loop over the tasks, outputting task information, and approving any
//tasks whose outcome has not been set...
for(int i = 0 ; i < tasks.size() ; i ++)
{
Task task = (Task)tasks.get(i);
int taskNumber = task.getSystemAttributes().getTaskNumber();
String title = task.getTitle();
String taskId = task.getSystemAttributes().getTaskId();
String outcome = task.getSystemAttributes().getOutcome();
if(outcome == null)
{
outcome = "APPROVE";
taskSvc.updateTaskOutcome(ctx,taskId,outcome);
}
System.out.println("Task #"+taskNumber+" ("+title+") is "+outcome);
}

}
catch (Exception e)
{
//Handle any exceptions raised here...
System.out.println("Caught workflow exception: "+e.getMessage());
}

33.2 クライアント作成に使用するパッケージとクラス

クライアントの作成には、次のパッケージとクラスを使用します。

- oracle.bpel.services.workflow.metadata.config.model
このパッケージ内の各クラスには、タスク定義ファイル内のワークフロー構成用のオブジェクト・モデルが含まれています。オブジェクトの作成には、ObjectFactoryクラスを使用できます。

- oracle.bpel.services.workflow.metadata.routingslip.model
このパッケージ内の各クラスには、ルーティング・スリップ用のオブジェクト・モデルが含まれています。オブジェクトの作成には、ObjectFactoryクラスを使用できます。

- oracle.bpel.services.workflow.metadata.taskdisplay.model
このパッケージ内の各クラスには、タスク表示用のオブジェクト・モデルが含まれています。オブジェクトの作成には、ObjectFactoryクラスを使用できます。

- oracle.bpel.services.workflow.metadata.taskdefinition.model
このパッケージ内の各クラスには、タスク定義ファイル用のオブジェクト・モデルが含まれています。オブジェクトの作成には、ObjectFactoryクラスを使用できます。

- oracle.bpel.services.workflow.client.IWorkflowServiceClient
ワークフロー・サービス・クライアントのインタフェースです。

- oracle.bpel.services.workflow.client.WorkflowServiceClientFactory
ワークフロー・サービス・クライアントを作成するためのファクトリです。

- oracle.bpel.services.workflow.metadata.ITaskMetadataService
タスク・メタデータ・サービスのインタフェースです。

- oracle.bpel.services.workflow.task.ITaskService
タスク・サービスのインタフェースです。

- oracle.bpel.services.workflow.task.IRoutingSlipCallback
タスク処理中にコールバックを受信するコールバック・クラスのインタフェースです。

- oracle.bpel.services.workflow.task.IAssignmentService
割当てサービスのインタフェースです。

33.3 ワークフロー・サービス・クライアント

ワークリスト・アプリケーションは、ワークフロー・サービス・クライアントを介して様々なワークフロー・サービスにアクセスします。ワークフロー・サービス・クライアントのコードは、様々なローカル・プロトコルとリモート・プロトコルを使用したワークフロー・サービスとの通信に必要なロジックをすべてカプセル化します。ワークリスト・アプリケーションにワークフロー・サービス・クライアントのインスタンスがある場合は、クライアントとワークフロー・サービスとの通信方法を考慮する必要はありません。

クライアントを使用するメリットは、次のとおりです。

- SOAP/HTTPやEnterprise JavaBeansなどの基礎となる接続メカニズムの複雑さが軽減されます。

- 使用する起動メカニズムの変更(SOAP/HTTPからリモートEnterprise JavaBeansへの変更など)が容易になります。

IWorkflowServiceClientインタフェースのインスタンス作成には、次のクラスが使用されます。

oracle.bpel.services.workflow.client.WorkflowServiceClientFactory

WorkflowServiceClientFactoryには、ワークフロー・クライアントを作成する複数のメソッドがあります。getWorkflowServiceClientは最も単純なメソッドで、パラメータとしてクライアント・タイプのみをとります。クライアント・タイプは次のいずれかです。

- WorkflowServiceClientFactory.REMOTE_CLIENT: クライアントはリモートEnterprise JavaBeansインタフェースを使用してリモートのワークフロー・サービスを起動します。

- WorkflowServiceClientFactory.SOAP_CLIENT: クライアントはSOAPを使用して、リモートのワークフロー・サービスへのWebサービス・インタフェースを起動します。

他のファクトリ・メソッドを使用すると、接続プロパティを直接指定し(ファクトリで接続プロパティをwf_client_config.xml fileからロードする必要はありません)、クライアント・アクティビティを記録するロガーを指定できます。

このリリースには、ワークフロー・サービス・クライアントの次の拡張機能が含まれています。

- 次の例1および2に示すように、ワークフロー・クライアント構成は、JAXBオブジェクトまたはマップのいずれかを使用して指定できます。
例1

WorkflowServicesClientConfigurationType wscct = new  WorkflowServicesClientConfigurationType();
List<ServerType> servers = wscct.getServer();
ServerType server = new ServerType();
server.setDefault(true);
server.setName(serverName);
servers.add(server);

RemoteClientType rct = new RemoteClientType();
rct.setServerURL("t3://stapj73:7001");
rct.setUserName("weblogic");
rct.setPassword("weblogic"));
rct.setInitialContextFactory("weblogic.jndi.WLInitialContextFactory");
rct.setParticipateInClientTransaction(false);
server.setRemoteClient(rct);
IWorkflowServiceClient wfSvcClient = WorkflowServiceClientFactory.getWorkflowServiceClient(
WorkflowServiceClientFactory.REMOTE_CLIENT, wscct, logger);

例2

Map<IWorkflowServiceClientConstants.CONNECTION_PROPERTY,java.lang.String> properties = new
HashMap<IWorkflowServiceClientConstants.CONNECTION_PROPERTY,java.lang.String>();

properties.put(IWorkflowServiceClientConstants.CONNECTION_PROPERTY.MODE,
IWorkflowServiceClientConstants.MODE_DYNAMIC);

properties.put(IWorkflowServiceClientConstants.CONNECTION_PROPERTY.SOAP_END_POINT_ROOT,
"http://localhost:8888");

IWorkflowServiceClient client =
WorkflowServiceClientFactory.getWorkflowServiceClient(WorkflowServiceClientFactory.SOAP_CLIENT,
properties, null);

- クライアントでは、クライアントがメッセージを記録するjava.util.logging.Loggerを必要に応じて渡すことができます。ロガーが指定されていない場合、ワークフロー・サービスのクライアント・コードは何も記録しません。次のコード・サンプルは、ロガーをワークフロー・サービス・クライアントに渡す方法を示しています。

java.util.logging.Logger logger = ....;

IWorkflowServiceClient client =
WorkflowServiceClientFactory.getWorkflowServiceClient(WorkflowServiceClientFactory.REMOTE_CLIENT,
properties, logger);

すべてのワークフロー・サービスのクライアント・ライブラリは、ファクトリを介して取得できます。表34-1 で、各サービスに使用可能なクライアントを確認してください。

BPMIdentityServiceおよびBPMIdentityConfigServiceのインスタンスは、WorkflowServiceClientFactoryでgetSOAPIdentityServiceClientメソッドおよびgetSOAPIdentityConfigServiceClientメソッドをコールして取得できます。その他のすべてのサービスは、IWorkflowServiceClientのインスタンスを介して取得できます。

クライアント・クラスは、サービスのエンドポイントにwf_client_config.xml構成ファイルを使用します。クライアントのクラスパスでは、このファイルはクラスパス直下にあります。つまり、このファイルが格納されているディレクトリはクラスパス内にあります。wf_client_config.xmlファイルには、次の内容が含まれています。

- 次のコード・サンプルに示すリモート・クライアント用のセクション:

<remoteClient>
<serverURL>t3://hostname.domain_name:7001</serverURL>
<userName>weblogic</userName>
<password>weblogic</password>
<initialContextFactory>weblogic.jndi.WLInitialContextFactory
</initialContextFactory>
<participateInClientTransaction>false</participateInClientTransaction>
</remoteClient>

- 次のコード・サンプルに示す各サービスのSOAPエンドポイント用のセクション:

<soapClient>
<rootEndPointURL>http://hostname.domain_name:7001</rootEndPointURL>
<identityPropagation mode="dynamic" type="saml">
<policy-references>
<policy-reference enabled="true" category="security"
uri="oracle/wss10_saml_token_client_policy"/>
</policy-references>
</identityPropagation>
</soapClient>

ワークフロー・クライアント構成のXMLスキーマ定義は、wf_client_config.xsdファイルに格納されています。

33.3.1 IWorkflowServiceClientインタフェース

IWorkflowServiceClientインタフェースは、各種ワークフロー・サービス・インタフェースへのハンドルを取得できるように、表33-1 に示すメソッドを提供します。

表33-1 IWorkflowServiceClientのメソッド

メソッド

インタフェース

getTaskService

oracle.bpel.services.workflow.task.ITaskService

getTaskQueryService

oracle.bpel.services.workflow.query.ITaskQueryService

getTaskReportService

oracle.bpel.services.workflow.report.ITaskReportService

getTaskMetadataService

oracle.bpel.services.workflow.metadata.ITaskMetadataService

getUserMetadataService

oracle.bpel.services.workflow.user.IUserMetadataService

getRuntimeConfigService

oracle.bpel.services.workflow.runtimeconfig.IRuntimeConfigService

getTaskEvidenceService

oracle.bpel.services.workflow.metadata.ITaskMetadataService

33.4 SOAPを使用するクライアント用のクラスパス

SOAPクライアントのクラスパスには、次のJARファイルが必要です。

- ${bea.home}/wlserver/server/lib/wlfullclient.jar

- $ORACLE_HOME/soa/plugins/jdeveloper/external/oracle.external.soa.jrf-wsclient-extended.jar

- ${bea.home}/soa/soa/modules/oracle.soa.fabric_11.1.1/bpm-infra.jar

- ${bea.home}/soa/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar

- ${bea.home}/soa/soa/modules/oracle.soa.fabric_11.1.1/fabric-runtime.jar

- ${bea.home}/oracle_common/module/clients/com.oracle.webservices.wls.jaxws-owsm-client_12.1.3.jar

wlfullclient.jarファイルは、次のコード・サンプルに示すコマンドを使用して生成できます。

cd ${bea.home}/wlserver/server/lib
java -jar ../../../modules/com.bea.core.jarbuilder_2.2.0.0.jar

注意:

クライアント・アプリケーションは、クラスパス内のsystem\services\configまたはsystem\services\schemaディレクトリを使用しません。

33.5 リモートEJBを使用するクライアント用のクラスパス

リモートEJBを使用するクライアントのクラスパスには、次のJARファイルが必要です。

- wlfullclient.jar

- oracle.external.soa.jrf-wsclient-extended.jar

- wlclient.jar

- xmlparserv2.jar

- xml.jar

- bpm-infra.jar

- bpm-services.jar

- fabric-runtime.jar

注意:

クライアント・アプリケーションは、クラスパス内のsystem\services\configまたはsystem\services\schemaディレクトリを使用しません。

33.6 タスクの開始

タスクはプログラムによって開始できます。その場合は、次のタスク属性を設定する必要があります。

- taskDefinitionId

- title

- payload

- priority

次のタスク属性はオプションですが、通常はクライアントによって設定されます。

- creator

- ownerUser: 空の場合はbpeladminにデフォルト設定されます。

- processInfo

- identificationKey: タスクは、TaskQueryServiceからの識別キーに基づいて問い合せることができます。

33.6.1 タスクの作成

タスクのオブジェクト・モデルは、次のパッケージで使用できます。

oracle.bpel.services.workflow.task.model

このモデル内でオブジェクトを作成するには、ObjectFactoryクラスを使用します。

33.6.2 タスクのペイロード要素の作成

タスク・ペイロードには、複数のペイロード・メッセージ属性を含めることができます。ペイロードはタスクが定義されるまで詳細に定義されないため、タスクのJavaオブジェクト・モデルには、クライアント・ペイロード用の強い型指定のオブジェクトが含まれません。タスク・ペイロードはAnyType Javaオブジェクトで表されます。AnyType Javaオブジェクトは、ネームスペース内のpayloadをルートとして持つXML要素を使用して作成されます。

http://xmlns.oracle.com/bpel/workflow/task

ペイロードのXML要素には、他のすべてのXML要素が含まれます。各XML要素では、メッセージ属性を定義します。

次のコード・サンプルは、タスク・ペイロードの設定方法を示しています。

import oracle.bpel.services.workflow.task.model.AnyType;
import oracle.bpel.services.workflow.task.model.ObjectFactory;
import oracle.bpel.services.workflow.task.model.Task;
..........

Document document = //createXMLDocument
Element payloadElem = document.createElementNS("http://xmlns.oracle.com/bpel/workflow/
task", "payload");
Element orderElem = document.createElementNS("http://xmlns.oracle.com/pcbpel/test/order", "order");
Element child = document.createElementNS("http://xmlns.oracle.com/pcbpel/test/order", "id");
child.appendChild(document.createTextNode("1234567"));
orderElem.appendChild(child);
payloadElem.appendChild(orderElem);
document.appendChild(payloadElem);

task.setPayloadAsElement(payloadElem);

注意:

AnyType.getContent()要素は、変更不可のXML要素リストを返します。このリストには他のメッセージ属性を追加できません。

33.6.3 プログラムによるタスクの開始

次のコード・サンプルは、休暇申請タスクをプログラムによって開始する方法を示しています。

// create task object
ObjectFactory objectFactory = new ObjectFactory();
Task task = objectFactory.createTask();

// set title
task.setTitle("Vacation request for jcooper");

// set creator
task.setCreator("jcooper");

// set taskDefinitionId. taskDefinitionId is the target
// namespace of the task
// If namespace is used, the active version of the composite corresponding
// to that of the namespace will be used.
task.setTaskDefinitionId("http://xmlns.oracle.com/VacationRequest/
Project1/Humantask1");  (Your task definition ID will be different.)

// create and set payload
Document document = XMLUtil.createDocument();
Element payloadElem = document.createElementNS(TASK_NS, "payload");
Element vacationRequestElem = document.createElementNS(VACATION_REQUEST_NS,
"VacationRequestProcessRequest");

Element creatorChild = document.createElementNS(VACATION_REQUEST_NS, "creator");
creatorChild.appendChild(document.createTextNode("jcooper"));
vacationRequestElem.appendChild(creatorChild);

Element fromDateChild = document.createElementNS(VACATION_REQUEST_NS, "fromDate");
fromDateChild.appendChild(document.createTextNode("2006-08-05T12:00:00"));
vacationRequestElem.appendChild(fromDateChild);

Element toDateChild = document.createElementNS(VACATION_REQUEST_NS, "toDate");
toDateChild.appendChild(document.createTextNode("2006-08-08T12:00:00"));
vacationRequestElem.appendChild(toDateChild);

Element reasonChild = document.createElementNS(VACATION_REQUEST_NS, "reason");
reasonChild.appendChild(document.createTextNode("Hunting"));
vacationRequestElem.appendChild(reasonChild);

payloadElem.appendChild(vacationRequestElem);
document.appendChild(payloadElem);

task.setPayloadAsElement(payloadElem);

IWorkflowServiceClient workflowServiceClient =
WorkflowServiceClientFactory.getWorkflowServiceClient
(WorkflowServiceClientFactory.SOAP_CLIENT);
ITaskService taskService = workflowServiceClient.getTaskService();
IInitiateTaskResponse iInitiateTaskResponse = taskService.initiateTask(task);
Task retTask = iInitiateTaskResponse.getTask();
System.out.println("Initiated: " + retTask.getSystemAttributes().getTaskNumber() + " - " +
retTask.getSystemAttributes().getTaskId());
return retTask;

33.7 ワークフロー標準ビュー定義の変更

ワークリスト・アプリケーションおよびUserMetadataService APIは、標準ビューの作成、更新および削除に使用できるメソッドを提供します。詳細は、「ユーザー・メタデータ・サービス」を参照してください。

33.8 HelpDeskUIサンプルを使用したワークリスト・アプリケーションの記述

この項の例では、HelpDeskRequestデモの一部であるヘルプ・デスク・インタフェースの変更方法を示します。

ワークリスト・アプリケーションを記述する手順は、次のとおりです。

1. ワークフロー・コンテキストは、ユーザーを認証することで作成します。

// get workflow service client
IWorkflowServiceClient wfSvcClient =
WorkflowServiceClientFactory.getWorkflowServiceClient
(WorkflowServiceClientFactory.REMOTE_CLIENT);

//get the workflow context
IWorkflowContext wfCtx =
wfSvcClient.getTaskQueryService().authenticate(userId, pwd, null);

これは、「ワークフロー・サービスのクライアント作成に関する概要」のステップ3です。

HelpDeskRequestのlogin.jspファイルでは、前述のAPIを使用してユーザーが認証され、ワークフロー・コンテキストが作成されます。ユーザーが認証されると、statusPage.jspファイルによって、ログイン・ユーザーに割当て済のタスクが表示されます。GUID-734EB3A5-2BA1-4511-BA88-8458DF488F9F.htm#GUID-60276421-C344-4D30-BC52-C75DC32782A2__CIHDECBAは、login.jspファイルからのサンプル・コードを示しています。

<%@ page import="javax.servlet.http.HttpSession"
import="oracle.bpel.services.workflow.client.IWorkflowServiceClient"
import="oracle.bpel.services.workflow.client.WorkflowServiceClientFactory"
import="java.util.Set"
import="java.util.Iterator"
import="oracle.bpel.services.workflow.verification.IWorkflowContext"
import="oracle.tip.pc.services.identity.config.ISConfiguration"%>
<%@ page contentType="text/html;charset=windows-1252"%>

<html>
<head>
<title>Help desk request login page</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body bgcolor="#F0F0F0" text="#000000" style="font: 12px verdana; line-height:18px">
<center>
<div style="width:640px;padding:15px;border-width: 10px; border-color: #87b4d9; border-style:
solid;
background-color:white; text-align:left">

<!-- Page Header, Application banner, logo + user status -->
<jsp:include page="banner.jsp"/>

<!-- Initiate Meta Information -->

<div style="background-color:#F0F0F0; border-top:10px solid white;border-bottom:
10px solid white;padding:10px;text-align:center" >
<b>Welcome to the HelpDesk application</b>
</div>

<%
String redirectPrefix =  "/HelpDeskUI/";
// Ask the browser not to cache the page
response.setHeader("Pragma", "no-cache");
response.setHeader("Cache-Control", "no-cache");

HttpSession httpSession = request.getSession(false);
if (httpSession != null) {

IWorkflowContext ctx = (IWorkflowContext) httpSession.getAttribute("workflowContext");
if (ctx != null) {
response.sendRedirect(redirectPrefix + "statusPage.jsp");
}
else
{
String authFailedStr = request.getParameter("authFailed");
boolean authFailed = false;
if ("true".equals(authFailedStr))
{
authFailed = true;
}
else
{
authFailed = false;
}

if (!authFailed)
{
//Get page parameters:
String userId="";
if(request.getParameter("userId") != null)
{
userId = request.getParameter("userId");
}
String pwd="";
if(request.getParameter("pwd") != null)
{
pwd = request.getParameter("pwd");
}

if(userId != null && (!("".equals(userId.trim())))
&& pwd != null && (!("".equals(pwd.trim()))))
{
try {
HttpSession userSession = request.getSession(true);

IWorkflowServiceClient wfSvcClient =
WorkflowServiceClientFactory.getWorkflowServiceClient
(WorkflowServiceClientFactory.REMOTE_CLIENT);
IWorkflowContext wfCtx =
wfSvcClient.getTaskQueryService().authenticate(userId, pwd, null);
httpSession.setAttribute("workflowContext", wfCtx);
response.sendRedirect(redirectPrefix + "statusPage.jsp");
}
catch (Exception e)
{
String worklistServiceError = e.getMessage();
response.sendRedirect(redirectPrefix + "login.jsp?authFailed=true");
out.println("error is " + worklistServiceError);
}
}
} else
{
out.println("Authentication failed");
}
}
}
%>

<form action='<%= request.getRequestURI() %>' method="post">
<div style="width:100%">
<table cellspacing="2" cellpadding="3" border="0" width="30%" align="center">
<tr>
<td>Username
</td>
<td>
<input type="text" name="userId"/>
</td>
</tr>
<tr>
<td>Password
</td>
<td>
<input type="password" name="pwd"/>
</td>
</tr>
<tr>
<td>
<input type="submit" value="Submit"/>
</td>
</tr>
</table>
</form>
</div>
</div>
</center>
</body>
</html>

2. TaskQueryServiceからのqueryTask APIを使用してタスクを問い合せます。

//add list of attributes to be queried from the task
List displayColumns = new ArrayList();
displayColumns.add("TASKNUMBER");
displayColumns.add("TITLE");
displayColumns.add("PRIORITY");
displayColumns.add("STATE");
displayColumns.add("UPDATEDDATE");
displayColumns.add("UPDATEDBY");
displayColumns.add("CREATOR");
displayColumns.add("OUTCOME");
displayColumns.add("CREATEDDATE");
displayColumns.add("ASSIGNEEUSERS");
displayColumns.add("ASSIGNEEGROUPS");
// get the list of tasks
List tasks =  wfSvcClient.getTaskQueryService().queryTasks
(wfCtx,
displayColumns,
null,
ITaskQueryService.AssignmentFilter.MY_AND_GROUP,
null,
null,
null,
0,
0);
// create listing page by using above tasks
//add href links to title to display details of the task by passing taskId
as input parameter
Use getTaskDetailsById(IWorkflowContext wftx, String taskId);

これは、「ワークフロー・サービスのクライアント作成に関する概要」のステップ4です。

HelpDeskRequestのstatusPage.jspファイルを使用して、ヘルプ・デスク・リクエストのステータスが表示されます。次のコード・サンプルは、statusPage.jspを示しています。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%@ page import="oracle.tip.pc.services.identity.BPMAuthorizationService,
oracle.bpel.services.workflow.verification.IWorkflowContext,
oracle.tip.pc.services.common.ServiceFactory,
oracle.bpel.services.workflow.client.IWorkflowServiceClient,
oracle.bpel.services.workflow.client.WorkflowServiceClientFactory,
oracle.bpel.services.workflow.query.ITaskQueryService,
oracle.bpel.services.workflow.task.model.Task,
oracle.bpel.services.workflow.task.model.IdentityType,
oracle.tip.pc.services.identity.BPMUser,
java.util.List,
java.util.Calendar,
java.text.SimpleDateFormat,
java.util.ArrayList"%>
<%@ page contentType="text/html;charset=UTF-8"%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>RequestPage</title>
<style TYPE="text/css">
Body, Form, Table, Textarea, Select, Input, Option
{
font-family : tahoma, verdana, arial, helvetica, sans-serif;
font-size : 9pt;
}
table.banner
{
background-color: #eaeff5;
}
tr.userInfo
{
background-color: #eaeff5;
}
tr.problemInfo
{
background-color: #87b4d9;
}
</style>
</head>
<body bgcolor="White">
<%
HttpSession httpSession = request.getSession(false);
httpSession.setAttribute("pageType","STATUSPAGE");
%>
<table bordercolor="#eaeff5" border="4" width="100%">
<tr><td> <jsp:include page="banner.jsp"/> </td></tr>
</table>
<%
BPMUser bpmUser = null;
String redirectPrefix =  request.getContextPath() + "/";
IWorkflowContext ctx = null;
if (httpSession != null) {

ctx = (IWorkflowContext) httpSession.getAttribute("workflowContext");
if (ctx != null) {
bpmUser = getAuthorizationService(ctx.getIdentityContext()).
lookupUser(ctx.getUser());
}
else
{
response.sendRedirect(redirectPrefix + "login.jsp");
return;
}
}
else
{
response.sendRedirect(redirectPrefix + "login.jsp");
return;
}
if(bpmUser == null)
{
response.sendRedirect(redirectPrefix + "login.jsp");
return;
}
String status = (String)httpSession.getAttribute("requeststatus");
if(status != null && !status.equals(""))
{
%>
<p></p>
<div style="text-align:left;color:red" >
<%= status %>
</div>
<%
}
httpSession.setAttribute("requeststatus",null);
IWorkflowServiceClient  wfSvcClient =
WorkflowServiceClientFactory.getWorkflowServiceClient(
WorkflowServiceClientFactory.REMOTE_CLIENT);
List displayColumns = new ArrayList();
displayColumns.add("TASKNUMBER");
displayColumns.add("TITLE");
displayColumns.add("PRIORITY");
displayColumns.add("STATE");
displayColumns.add("UPDATEDDATE");
displayColumns.add("UPDATEDBY");
displayColumns.add("CREATOR");
displayColumns.add("OUTCOME");
displayColumns.add("CREATEDDATE");
displayColumns.add("ASSIGNEEUSERS");
displayColumns.add("ASSIGNEEGROUPS");
List tasks =  wfSvcClient.getTaskQueryService().queryTasks
(ctx,
displayColumns,
null,
ITaskQueryService.ASSIGNMENT_FILTER_CREATOR,
null,
null,
null,
0,
0);
%>
<p></p>
<div style="text-align:left;color:green" >
<b>
Previous help desk request
</b>
</div>
<p></p>
<div style="text-align:center" >
<table cellspacing="2" cellpadding="2" border="3" width="100%">
<TR class="problemInfo">
<TH>TaskNumber</TH>
<TH>Title</TH>
<TH>Priority</TH>
<TH>CreatedDate</TH>
<TH>Assignee(s)</TH>
<TH>UpdatedDate</TH>
<TH>UpdatedBy</TH>
<TH>State</TH>
<TH>Status</TH>
</TR>
<%
SimpleDateFormat dflong = new SimpleDateFormat( "MM/dd/yy hh:mm a" );
for(int i = 0 ; i < tasks.size() ; i ++)
{
Task task = (Task)tasks.get(i);
int taskNumber = task.getSystemAttributes().getTaskNumber();
String title = task.getTitle();
int priority = task.getPriority();
String assignee = getAssigneeString(task);
Calendar createdDate = task.getSystemAttributes().getCreatedDate();
Calendar updateDate =  task.getSystemAttributes().getUpdatedDate();
String updatedBy = task.getSystemAttributes().getUpdatedBy().getId();
String state = task.getSystemAttributes().getState();
String outcome = task.getSystemAttributes().getOutcome();
if(outcome == null) outcome = "";
String titleLink = "http://" + request.getServerName() +
":" + request.getServerPort() +
"/integration/worklistapp/TaskDetails?taskId=" +
task.getSystemAttributes().getTaskId();
%>
<tr class="userInfo">
<td><%=taskNumber%></td>
<td><a href="<%=titleLink%>" target="_blank"><%=title%></a></td>
<td><%=priority%></td>
<td><%=dflong.format(createdDate.getTime())%></td>
<td><%=assignee%></td>
<td><%=dflong.format(updateDate.getTime())%></td>
<td><%=updatedBy%></td>
<td><%=state%></td>
<td><%=outcome%></td>
<tr>
<%
}
%>
</table>
</div>
<%!
private BPMAuthorizationService getAuthorizationService(String identityContext)
{
BPMAuthorizationService authorizationService =
ServiceFactory.getAuthorizationServiceInstance();
if (identityContext != null)
authorizationService = ServiceFactory.getAuthorizationServiceInstance(identityContext);

return authorizationService;
}
private String getAssigneeString(Task task) throws Exception
{
List assignees = task.getSystemAttributes().getAssigneeUsers();
StringBuffer buffer = null;
for(int i = 0 ; i < assignees.size() ; i++)
{
IdentityType type = (IdentityType)assignees.get(i);
String name = type.getId();
if(buffer == null)
{
buffer = new StringBuffer();
}
else
{
buffer.append(",");
}
buffer.append(name).append("(U)");
}
assignees = task.getSystemAttributes().getAssigneeGroups();
for(int i = 0 ; i < assignees.size() ; i++)
{
IdentityType type = (IdentityType)assignees.get(i);
String name = type.getId();
if(buffer == null)
{
buffer = new StringBuffer();
}
else
{
buffer.append(",");
}
buffer.append(name).append("(G)");
}
if(buffer == null)
{
return "";
}
else
{
return buffer.toString();
}
}
%>
</body>
</html>

34 ヒューマン・ワークフロー・サービスの概要

この章では、開発者を対象として、Oracle SOA Suiteでのヒューマン・ワークフロー・サービスの使用方法について説明します。ヒューマン・ワークフロー・サービスは、タスクのライフ・サイクル内で様々な操作を実行します。

この章の内容は次のとおりです。

- ヒューマン・ワークフロー・サービスの概要

- ヒューマン・ワークフローからの通知

- 割当てサービスの構成

- コールバックとリソース・バンドルに対するクラスのロード

- ワークフロー・サービスのリソース・バンドル

- ヒューマン・ワークフロー・クライアントとサービスとの統合の概要

- ヒューマン・タスクのタスクの状態

- Oracle Workflowのデータベース・ビュー

注意:

以前のリリースのOracle BPM Worklistには、フレックス・フィールドと呼ばれる機能が含まれていました。リリース11g R1 (11.1.1.4)から、フレックス・フィールドはマップ済属性と呼ばれるようになりました。

34.1 ヒューマン・ワークフロー・サービスの概要

この項では、次のヒューマン・ワークフロー・サービスの役割について説明します。

- タスク・サービス

- タスク問合せサービス

- アイデンティティ・サービス

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

- ユーザー・メタデータ・サービス

- タスク・レポート・サービス

- ランタイム構成サービス

- エビデンス・ストア・サービス

34.1.1 ヒューマン・ワークフロー・サービスに対するSOAP、Enterprise JavaBeansおよびJavaサポート

表34-1 に、タスク・サービスに提供されるSimple Object Access Protocol (SOAP)、Enterprise JavaBeansおよびJavaサポートのタイプを示します。ほとんどのヒューマン・ワークフロー・サービスは、SOAPおよびリモートのEnterprise JavaBeans APIからアクセスできます。これらのサービスは、適切なクライアント・プロキシを使用して直接利用できます。また、プロトコル詳細を要約し、すべての通信の共通のインタフェースを提供するクライアント・ライブラリが提供されます。

表34-1 Enterprise JavaBeans、SOAPおよびJavaサポート

サービス名

SOAP Webサービスのサポート

リモートEnterprise JavaBeansのサポート

タスク・サービス: タスク状態の管理およびタスクの永続性を提供します。これらのサービスに加え、タスク・サービスでは、タスクの更新、完了、エスカレート、再割当てなどの操作が公開されます。

はい

はい

タスク問合せサービス: 様々な検索基準(キーワード、カテゴリ、ステータス、ビジネス・プロセス、属性値、タスクの履歴情報など)に基づいて、ユーザーのタスクを問い合せます。

はい

はい

アイデンティティ・サービス: ユーザーの認証、ユーザーのプロパティ、ロール、グループ・メンバーシップおよび権限のルックアップが可能になります。

はい

いいえ

タスク・メタデータ・サービス: タスク関連のメタデータ情報を取得するための操作を公開します。

はい

はい

ユーザー・メタデータ・サービス: ワークフロー・ユーザー関連のメタデータ(ユーザー作業キュー、プリファレンス、休暇および委任ルールなど)を管理します。

はい

はい

タスク・レポート・サービス: ワークフロー・レポートの詳細を提供します。

はい

はい

ランタイム構成サービス: タスク・サービスのランタイム環境で使用されるメタデータの管理メソッドを提供します。

はい

はい

エビデンス・ストア・サービス: デジタル署名されたワークフロー・タスクの保管と否認防止をサポートします。

はい

はい

表34-2 に、各タスク・サービスに対するSOAP Web Services Description Language (WSDL)ファイルの場所を示します。

表34-2 タスク・サービスのSOAP WSDLの場所

サービス名

SOAP WSDLの場所

タスク・サービス

http://host:port/integration/services/TaskService/TaskServicePort?WSDL

タスク問合せサービス

http://host:port/integration/services/TaskQueryService/TaskQueryService?WSDL

アイデンティティ・サービス

http://host:port/integration/services/IdentityService/configuration?WSDL

http://host:port/integration/services/IdentityService/identity?WSDL

タスク・メタデータ・サービス

http://host:port/integration/services/TaskMetadataService/TaskMetadataServicePort?WSDL

ユーザー・メタデータ・サービス

http://host:port/integration/services/UserMetadataService/UserMetadataService?WSDL

タスク・レポート・サービス

http://host:port/integration/services/TaskReportService/TaskReportServicePort?WSDL

ランタイム構成サービス

http://host:port/integration/services/RuntimeConfigService/RuntimeConfigService?WSDL

エビデンス・ストア・サービス

http://host:port/integration/services/EvidenceService/EvidenceService?WSDL

表34-3 に、様々なEnterprise JavaBeansのJNDI名を示します。

表34-3 様々なEnterprise JavaBeansのJNDI名

サービス名

様々なEnterprise JavaBeansのJNDI名

タスク・サービス

ejb/bpel/services/workflow/TaskServiceBean

クライアント・トランザクションに参加するタスク・サービスのEnterprise JavaBeans

ejb/bpel/services/workflow/TaskServiceGlobalTransactionBean

タスク・メタデータ・サービス

ejb/bpel/services/workflow/TaskMetadataServiceBean

タスク問合せサービス

TaskQueryService

ユーザー・メタデータ・サービス

UserMetadataService

ランタイム構成サービス

RuntimeConfigService

タスク・レポート・サービス

TaskReportServiceBean

タスク・エビデンス・サービス

TaskEvidenceServiceBean

ワークリスト・サービスのクライアント・ライブラリの詳細は、「カスタム・ワークリスト・クライアントの作成」を参照してください。

34.1.1.1 外部JNDI名のサポート

ヒューマン・ワークフロー・サービスは、WebサービスとRemote Method Invocation (RMI)を介してJ2EEアプリケーションと統合できます。他の管理対象サーバーやクラスタ、または他のOracle WebLogic ServerドメインにあるEnterprise JavaBeansのリモート・ルックアップを容易にするために、Oracle WebLogic Serverには外部JNDIプロバイダが組み込まれています。外部JNDIプロバイダは、リモート・サーバーのホストとポートを使用して、リモート・サーバーのEnterprise JavaBeansをローカル・サーバーのJNDIツリーにリンク付けするように構成されています。

ワークフロー・サービスでは、表34-3 にリストされているEnterprise JavaBeansが公開されます。これらのEnterprise JavaBeansは、タスク問合せサービス、ヒューマン・タスクに対するADFタスク・フローの登録、埋込みワークリスト・リージョンのユースケースを完全にサポートするために、外部JNDIプロバイダを介してすべてリンクされている必要があります。

外部JNDI名のサポートを提供する手順は、次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

http://host:port/console

2. 「ドメイン構造」で、「サービス」→「JDBC」→「外部JNDIプロバイダ」の順に選択します。

ローカルJNDIネームスペースに対するリモートEnterprise JavaBeans名を、外部JNDIプロバイダを介して同じOracle WebLogic Serverドメイン内のSOAサーバーから特定の管理対象サーバーまたはクラスタにリンク付けする場合は、注意事項が1つあります。ローカルJNDI名は、そのドメイン内のすべての管理対象サーバーに公開されます。このようにリンク付けすると、そのドメイン内のSOAサーバー上でネームスペースの競合が発生します。これは、Oracle BPM Worklistから登録されたEnterprise JavaBeansがすでに存在しているためです。競合を回避して構成を最小限に維持する別の方法として、JNDI接尾辞を使用する方法があります。これを実行するには、リモート・ワークフローEnterprise JavaBeansのすべてのローカルJNDIリンクの末尾に一貫性のある接尾辞を追加し、接尾辞キーが含まれた単純なwf_client_config.xmlファイルを作成します。

クライアント・プロパティの定義には様々な方法があります。詳細は、「構成オプション」を参照してください。

3. 表34-3 に示した各Enterprise JavaBeans名にJNDI接尾辞を追加し、外部JNDI名を登録します。

- ejb/bpel/services/workflow/TaskServiceGlobalTransactionean_server1

- ejb/bpel/services/workflow/TaskServiceBean_server1

- ejb/bpel/services/workflow/TaskMetadataServiceBean_server1

- TaskQueryService_server1

- UserMetadataService_server1

- RuntimeConfigService_server1

- TaskReportServiceBean_server1

- TaskEvidenceServiceBean_server1

4. 次のコード・サンプルに示すように、wf_client_config.xmlファイルにejbJndiSuffix要素の値のみを指定して、リモート名を定義します。JAXBオブジェクトのWorkflowServicesClientConfigurationTypeを使用することも、Map<CONNECTION_PROPERTY, String>プロパティでCONNECTION_PROPERTY.EJB_JNDI_SUFFIXを使用することもできます。

<remoteClient>
<ejbJndiSuffix>_server1</ejbJndiSuffix>
</remoteClient>

34.1.2 サービスのセキュリティ・モデル

アイデンティティ・サービスを除いて、前述のAPI (SOAPおよびリモートEnterprise JavaBeans)を使用するすべてのサービスでは、認証を起動する必要があります。前述のすべてのチャネルでは、ヒューマン・ワークフロー・コンテキストを使用したユーザーIDの受渡しがサポートされています。ヒューマン・ワークフロー・コンテキストには、次のいずれかが含まれています。

- ログインとパスワード

- トークン

タスク問合せサービスでは、ログインとパスワードを取得し、すべてのサービスに使用するヒューマン・ワークフロー・コンテキストを返すauthenticate操作が公開されます。管理者は、必要に応じて、各リクエストごとにログインとパスワード付きでヒューマン・ワークフロー・コンテキストを渡すことができます。

authenticate操作では、管理IDおよび管理パスワードを使用して、ユーザーにかわってコンテキストを作成するという概念もサポートされます。この操作により、Oracle BPM Worklistにログインしたユーザーのパスワードを利用できない場合は、そのユーザー用のコンテキストを作成できます。

ワークフロー・コンテキストは、1回取得してすべてのリクエストで使用することをお薦めします。リクエストごとにワークフロー・コンテキストを取得すると、パフォーマンスが低下する場合があります。

レルムは、アイデンティティ構成からのアイデンティティ・サービス・コンテキストです。デフォルトの構成を使用する場合、レルム名はNULLにできます。

34.1.2.1 SOAP Webサービス使用時のワークフロー・サービスへのアイデンティティ伝播の制限

アイデンティティ伝播は複数のSOAP Webサービス間で認証されたアイデンティティのレプリケーションで、トランザクションを1回で完了するために使用されます。SOAP Webサービスでは、Webサービス・セキュリティもサポートされます。Webサービス・セキュリティが使用されている場合は、SOAP入力にヒューマン・ワークフロー・コンテキストが存在している必要はありません。Webサービス・セキュリティは、Oracle Enterprise Manager Fusion Middleware Controlから構成できます。

注意:

ヒューマン・ワークフローのSOAPクライアントは、Webサービスが保護されている場合に、Security Assertion Markup Language (SAML)トークンベースのアイデンティティ伝播を使用できるように拡張されています。

34.1.2.2 ユーザーにかわるヒューマン・ワークフロー・コンテキストの作成

タスク問合せサービスに対するauthenticateOnBehalfOf APIメソッドでは、管理ユーザーのユーザーIDとパスワードをリクエストで渡すことで、ユーザーのかわりにヒューマン・ワークフロー・コンテキストを作成できます。管理ユーザーにはworkflow.admin権限があります。この場合は、ユーザーのかわりにパスワードを使用して作成した場合と同様のコンテキストが作成されます。

これは、バックエンド・システムがワークフロー・タスクを操作し、一方でユーザーが自分のシステムで操作する環境で役立ちます。ワークフロー・サービスとの直接の相互作用はありません。システムは、ユーザーにかわってログインし、ユーザーのコンテキストを取得できます。

注意:

この機能は、システム操作に対してのみ使用することをお薦めします。これは、管理ユーザー・コンテキストを作成して、ユーザーのかわりに作成したヒューマン・ワークフロー・コンテキストを問い合せる必要があるためです。かわりにアイデンティティ伝播を使用すると、ユーザーはすでに認証されているため、クライアントはすでに認証されているそのユーザーのIWorkflowContextを取得できます。詳細は、「JAASアプリケーションによって以前に認証されたユーザーのワークフロー・コンテキストの取得」を参照してください。

次のコード・サンプルでは、ユーザーjcooperのヒューマン・ワークフロー・コンテキストを作成します。

String adminUser = "...."
String adminPassword = "...."
String realm = "...."

IWorkflowContext adminCtx =
taskQueryService.authenticate(user,password.toCharArray(),realm);

IWorkflowContext behalfOfCtx =
taskQueryService.authenticateOnBehalfOf(adminCtx,"jcooper");

34.1.2.3 JAASアプリケーションによって以前に認証されたユーザーのワークフロー・コンテキストの取得

クライアントでJAASアプリケーションによって以前に認証されたユーザーのワークフロー・コンテキストを取得する場合は、次のコード・サンプルに示すアイデンティティ伝播を使用できます。

public IWorkflowContext getWorkflowContextForAuthenticatedUser() throws WorkflowException;

クライアントで適切なクライアント・タイプ用にアイデンティティ伝播が構成されている場合は、このAPIによって認証済のユーザーのワークフロー・コンテキストが返されます。クライアント・タイプがリモートの場合は、このメソッドでEnterprise JavaBeansアイデンティティ伝播が使用されます。クライアント・タイプがSOAPの場合は、このメソッドでSAMLトークン伝播が使用されます。

34.1.3 タスク・サービス

タスク・サービスにより、タスクに対するアクションを実行するための操作が公開されます。表34-4 に、タスク・サービスの一般的な操作の一部を示します。パッケージoracle.bpel.services.workflow.taskは、タスク・サービスに対応しています。

タスク・サービスの詳細は、『Oracle SOA Suiteワークフロー・サービスJava APIリファレンス』を参照してください。

表34-4 タスク・サービスのメソッド

メソッド

説明

acquireTask

タスクを獲得します。

acquireTasks

一連のタスクを獲得します。

addAttachment

タスクに添付ファイルを追加します。

注意: このAPIで、クライアントは、タスクの作成前に添付ファイルを追加するためのAPIをコールできるようになります。タスクがまだ作成されていない場合は、クライアントはtaskId equals NULLを指定してAPIをコールできます。ただし、添付ファイルは、タスクが作成される前にアップロードされているため、Oracle Workflowサービスでは、同じ名前を持つ複数の添付ファイルをタスクの開始前に追加することはできません。

タスクがすでに作成されている場合は、複数の添付ファイルに同じ名前が付いていると、Oracle Workflowサービスではその添付ファイルの最新バージョンのみが保持されます。

addComment

タスクにコメントを追加します。

createToDoTask

To Doタスクを作成します。

delegateTask

タスクを別のユーザーに委任します。現在の割当て先とタスク委任先ユーザーの両方が、タスクを表示して操作できます。

delegateTasks

タスクのリストを別のユーザーに委任します。現在の割当て先とタスクのリスト委任先ユーザーの両方が、タスクを表示して操作できます。

deleteTask

タスクの論理削除を実行します。データベース上にはタスクはまだ存在します。

deleteTasks

タスクのリストの論理削除を実行します。データベース上にはタスクはまだ存在します。

errorTask

タスクをエラーにします。通常、この操作はエラー割当て先が使用します。

escalateTask

タスクをエスカレートします。デフォルトでは、現行のユーザーのマネージャにエスカレートします。これはエスカレーション関数を使用してオーバーライドできます。

escalateTasks

複数のタスクをまとめてエスカレートします。デフォルトでは、現行のユーザーのマネージャにエスカレートします。これはエスカレーション関数を使用してオーバーライドできます。

getApprovers

タスクの前の承認者を取得します。

getFutureParticipants

タスクの今後の参加者を取得します。今後の参加者は、単純参加者を含むルーティング・スリップ形式で返されます(ルーティング・スリップを含む参加者ノードとパラレル・ノード)。

getUsersToRequestInfoForTask

情報リクエストのリクエストが可能なユーザーを取得します。

initiateTask

タスクを開始します。

mergeAndUpdateTask

タスクをマージおよび更新します。この操作を使用するのは、部分タスクに更新が必要な場合です。部分タスクとは、一部のタスク属性が存在しないタスクです。この部分タスクでは、次のタスク属性のみが解析されます。

- タスク・ペイロード

- コメント

- タスクの状態

- タスクの結果

overrideRoutingSlip

タスク・インスタンスのルーティング・スリップを新規ルーティング・スリップでオーバーライドします。現行のタスク割当てはNULLになり、タスクの開始時には新規ルーティング・スリップが解析されます。

purgeTask

永続ストアからタスクを削除します。

purgeTasks

永続ストアからタスクのリストを削除します。

pushBackTask

タスクを前の承認者または当初の割当て先にプッシュバックします。当初の割当て先は、タスクの再割当てやエスカレートを実行している可能性があるため、承認者でなくてもかまいません。タスクが当初の割当て先にプッシュバックされるか、承認者にプッシュバックされるかは、Oracle Enterprise Manager Fusion Middleware Controlの「システムMBeanブラウザ」のプロパティ「PushbackAssignee」によって制御されます。

1. 「SOAインフラストラクチャ」メニューから、「管理」→「システムMBeanブラウザ」の順に選択します。

2. 「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: soa_server1」→「WorkflowConfig」→「human-workflow」の順に選択します。

3. 「PushbackAssignee」をクリックして値を表示または変更します。

注意: プッシュバックは、グループ投票ではなく単一承認者で機能するように設計されています。グループ投票(またはパラレル)シナリオを含むステージから別ステージへのプッシュバックは、許可されません。同様に、単一の割当て先からグループ投票(またはパラレル)シナリオにプッシュバックすることもできません。

reassignTask

タスクを再割当てします。

reassignTasks

複数のタスクをまとめて再割当てします。

reinitiateTask

タスクを再開します。タスクを再開すると、前に完了したタスクが持ち越されるため、履歴、コメントおよび添付ファイルも新規タスクに持ち越されます。

releaseTask

前に獲得したタスクをリリースします。

releaseTasks

前に獲得した一連のタスクをリリースします。

removeAttachment

タスクの添付ファイルを削除します。

renewTask

タスクの期限を更新して有効期間を延長します。

requestInfoForTask

タスク情報をリクエストします。

requestInfoForTaskWithReapproval

再承認を伴うタスク情報をリクエストします。たとえば、jcooperがタスクを作成し、jsteinとwfaulkが同じ順序でタスクを承認したとします。次の承認者であるcdickensがjcooperに対して再承認を伴う情報のリクエストを送信すると、jcooperはリクエストされた情報を発行し、jsteinとwfaulkはcdickensより先にそのタスクを承認します。cdickensがjsteinに対して再承認を伴う情報のリクエストを送信すると、jsteinはリクエストされた情報を発行し、wfaulkはcdickensより先にそのタスクを承認します。

resumeTask

タスクを再開します。ワークフローの保留を解除するために、タスク所有者(またはBPMWorkflowSuspend権限を持つユーザー)のみが実行できる操作です。ヒューマン・ワークフローの再開後は、タスクに対するアクションを実行できます。

resumeTasks

一連のタスクを再開します。

routeTask

タスクを、レビューする必要のある次のユーザーに非定型の形式でルーティングできるようにします。ユーザーは、タスクをシリアル、パラレルまたは単一割当てでルーティングするように指定できます。タスクをルーティングできるのは、ヒューマン・ワークフローでタスクの非定型ルーティングが許可されている場合のみです。

skipCurrentAssignment

現在の割当てをスキップして次の割当てに移動するか、他に割当て先が存在しない場合は、直前の承認者が設定した結果を使用します。

submitInfoForTask

タスク情報を発行します。通常、このアクションは、必要なタスク更新を実行した後、または追加情報を含むコメントや添付ファイルを追加した後に実行します。

suspendTask

タスク所有者(またはBPMWorkflowSuspend権限を持つユーザー)に、ヒューマン・ワークフローの一時的な保留を許可します。この場合、タスクの有効期限とエスカレーションは、ワークフローが再開されるまで適用されません。一時停止されているタスクには、アクションを実行できません(再開または取消しを除く)。

suspendTasks

一連のタスクを一時停止します。

updateOutcomeOfTasks

一連のタスクの結果を更新します。

updatePriority

指定したタスクIDのタスクおよびそのサブタスクの優先度を更新します。UpdatePriorityTypeがINCREMENTの場合、指定した優先度を1ずつ増分することにより、タスクが更新されます(つまり、タスクの優先度は高くなります)。UpdatePriorityTypeがDECREMENTの場合、優先度を1ずつ減分することによりタスクが更新され(つまり、タスクの優先度は低くなります)、それ以外の場合には、指定した優先度で更新されます。

updatePriorityOfTasks

タスクの一括更新に使用します。優先度の更新が必要なタスクのリストを、このAPIに対してパラメータとして渡すことができます。タスクのリストの優先度が更新されます。これにより、タスクおよびそのサブタスクの優先度が更新されます。

updateTask

タスクを更新します。

updateTaskOutcome

タスクの結果を更新します。

updateTaskOutcomeAndRoute

タスクの結果を更新してタスクをルーティングします。タスクをルーティングすると、ユーザーはそのタスクを、レビューする必要のある次のユーザーに非定型の形式でルーティングできます。ユーザーは、タスクをシリアル、パラレルまたは単一割当てでルーティングするように指定できます。タスクをルーティングできるのは、ヒューマン・ワークフローでタスクの非定型ルーティングが許可されている場合のみです。

withdrawTask

タスク作成者は、ヒューマン・ワークフローを介してタスクを送る必要がなくなった場合、保留中のタスクを取り消すことができます。タスク所有者も、作成者のかわりにタスクを取り消すことができます。タスクが取り消されると、ビジネス・プロセスは、タスクの状態属性が「取消し済」に設定された状態でコールバックされます。

withdrawTasks

一連のタスクを取り消します。

詳細は、次を参照してください。

- タスク・インスタンス属性

- Oracle SOA Suite ワークフロー・サービスJava APIリファレンス

- いくつかのAPIの例を示すサンプルのworkflow-118-JavaSamples

34.1.4 タスク問合せサービス

タスク問合せサービスでは、様々な検索基準(キーワード、カテゴリ、ステータス、ビジネス・プロセス、属性値、タスクの履歴情報など)に基づいてタスクを問い合せます。表34-5 に、タスク問合せサービスの一般的な操作の一部を示します。パッケージoracle.bpel.services.workflow.queryは、タスク問合せサービスに対応しています。

タスク問合せサービスの詳細は、『Oracle SOA Suiteワークフロー・サービスJava APIリファレンス』を参照してください。

表34-5 タスク問合せサービスのメソッド

メソッド

説明

authenticate

アイデンティティ認証サービスでユーザーを認証し、有効なIWorkflowContextオブジェクトを渡して戻します。

authenticateOnBehalfOf

必要に応じ、他のユーザーにかわって認証を行います。

countTasks

指定した問合せ基準に一致するタスクの数をカウントします。

countViewTasks

指定したビューの問合せ基準に一致するタスクの数をカウントします。

createContext

事前認証済のHTTPリクエストから有効なIWorkflowContextオブジェクトを作成します。

doesTaskExist

指定した問合せ基準に一致する既存タスクがあるかどうかを確認します。

doesViewTaskExist

指定したビューの問合せ基準に一致するタスクが存在するかどうかを確認します。

getWorkflowContext

指定のコンテキスト・トークンを使用してヒューマン・ワークフロー・コンテキストを取得します。

destroyWorkflowContext

不要になったヒューマン・ワークフロー・コンテキストをクリーン・アップします。通常、このメソッドはユーザーのログアウト時に使用されます。

getTaskDetailsById

タスクのtaskIdプロパティから特定のタスクの詳細を取得します。

getTaskDetailsByNumber

タスクのtask numberプロパティから特定のタスクの詳細を取得します。

getTaskHistory

指定タスクIDのタスク・バージョンのリストを取得します。

getTaskSequence

タイプが順序のタスクについて、IDがタスクIDのタスクのタスク順序ツリーを取得します。

getTaskVersionDetails

指定のタスクIDとバージョン番号について、特定のタスク・バージョン詳細を取得します。

getWorkflowContextForAuthenticatedUser

JAASアプリケーションによって認証されたユーザーのIWorkflowContextオブジェクトを取得します。これは、Enterprise JavaBeansアイデンティティ伝播またはSAMLトークン・アイデンティティ伝播とともに使用します。

queryAggregatedTasks

指定した問合せを実行し、問合せで返されたタスクの数を、指定した列ごとにグループ化して集計します。

queryTaskErrors

指定の述語に一致するタスク・エラー・オブジェクトのリストを返します。

queryTasks

指定のフィルタ条件に一致するタスクのリストを返します。タスクは、指定の順序付け条件(存在する場合)に従ってリストされます。基準に一致するタスクのリスト全体を返すか、クライアントがページング問合せを実行できます。その場合は、リストのうち指定した数のタスクのみが取得されます。フィルタ条件は次のとおりです。

- assignmentFilter: タスクを割当て先または作成者に従ってフィルタします。割当てフィルタに可能な値は、次のとおりです。
ADMIN: フィルタリングなし。割当てや作成者に関係なく全タスクが返されます。

ALL: フィルタリングなし。割当てや作成者に関係なく全タスクが返されます。

CREATOR: コンテキスト・ユーザーが作成者であるタスクが返されます。

GROUP: コンテキスト・ユーザーがメンバーであるグループ、アプリケーション・ロールまたはユーザーのリストに割り当てられているタスクが返されます。

MY: コンテキスト・ユーザーに排他的に割り当てられているタスクが返されます。

MY_AND_GROUP: コンテキスト・ユーザー、またはコンテキスト・ユーザーがメンバーであるグループ、アプリケーション・ロールまたはユーザーのリストに、排他的に割り当てられているタスクが返されます(他のユーザーによって申告されたタスクは除きます)。

MY_AND_GROUP_ALL: コンテキスト・ユーザー、またはコンテキスト・ユーザーがメンバーであるグループ、アプリケーション・ロールまたはユーザーのリストに、排他的に割り当てられているタスクが返されます(他のユーザーによって申告されたタスクを含みます)。

OWNER: コンテキスト・ユーザーがタスク所有者であるタスクが返されます。

PREVIOUS: コンテキスト・ユーザーが以前に更新したタスクが返されます。

REPORTEES: コンテキスト・ユーザーの報告先に割り当てられているタスクが返されます。

REVIEWER: コンテキスト・ユーザーがレビューアであるタスクが返されます。

- keywords: オプションの検索文字列です。この場合は、この文字列がタスクのタイトル、タスク識別キーまたはタスク・テキスト・マップ済属性(以前のフレックス・フィールド)に含まれているタスクのみが返されます。

- predicate: オプションのoracle.bpel.services.workflow.repos.Predicateオブジェクトです。これによって、クライアントはSQLのような複雑な問合せ述語を指定できます。

queryViewAggregatedTasks

指定したビューに定義されているように問合せを実行し、そのビューに定義されているチャート・プロパティに従って選択したタスクを集計します。

queryViewTasks

指定のビューの基準に従ってタスクのリストが返されます。タスク・リストの全体またはページを返すことができます。クライアントは、ビューのコンテンツに対してフィルタと順序付け基準を追加指定できます。

詳細は、次を参照してください。

- タスク・インスタンス属性

- ドキュメント・ライブラリの『Oracle SOA Suiteワークフロー・サービスJava APIリファレンス』

- いくつかのAPIの例を示すサンプルのworkflow-118-JavaSamples

34.1.5 アイデンティティ・サービス

アイデンティティ・サービスは、Oracle WebLogic Serverのセキュリティ・インフラストラクチャ(Oracle Identity ManagementおよびOracle Platform Security Services (OPSS))または任意のカスタム・ユーザー・リポジトリの上部に位置するWebサービスのシン・レイヤーです。アイデンティティ・サービスにより、ユーザーの認証、ユーザー・プロパティ、ロール、グループ・メンバーシップおよび権限のルックアップが可能になります。Oracle WebLogic Serverでは、Oracle Identity Managementが唯一のアイデンティティ・サービス・プロバイダです。Oracle Identity Managementは、XML、LDAPなど様々なリポジトリに対するユーザーとロールの保管と取得をすべて処理します。Oracle Identity Managementには、具体的に次の機能が用意されています。

- すべてのプロバイダは、Oracle Identity Managementを通してサポートされます。OracleAS JAAS Provider (JAZN)とLDAPのプロバイダはサポートされていません。カスタム・プロバイダは非推奨で、後方互換性のためにのみサポートされます。Oracle Identity Managementでは、カスタム・プロバイダを経由するか、LDAPプロバイダとしてOracle Virtual Directory (OVD)を構成して(あるいはその両方)、プロバイダのすべてのカスタマイズが実行されます。OVDはデータを様々なリポジトリ全体にわたって集約します。

- 次の内容を含むOPSSレイヤーが使用されます。

- アイデンティティ・ストア

- ポリシー・ストア

- 資格証明ストア

- フレームワーク

詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。すべてのセキュリティ構成は、jps-config.xmlファイルを使用して行われます。

- 以前のリリースの動作と異なり、すべての権限がパーミッションと照合して検証されます。

- 次の一連のアプリケーション・ロールが定義されています。これらのロールはOPSSポリシー・ストアのSOAインフラストラクチャ・アプリケーションに自動的に定義されます。

- SOAAdmin: どのSOAモジュールにも管理操作を実行する必要があるユーザーにこのロールを付与します。このロールには、BPMWorkflowAdminおよびB2BAdminロールも付与されます。

- BPMWorkflowAdmin: どのワークフローにも管理操作を実行する必要があるユーザーにこのロールを付与します。この管理操作には、システム内の任意のタスクに対する検索および操作、ユーザーまたはグループのルール作成および変更、アプリケーションのカスタマイズ実行などの操作が含まれます。このロールには、BPMWorkflowCustomizeロールと次の権限が付与されます。

- workflow.mapping.protectedFlexField

- workflow.admin.evidenceStore

- workflow.admin

- BPMWorkflowCustomize: このロールは、パブリック・マップ済属性へのマップ済属性(以前のフレックス・フィールド)マッピングを実行する必要があるビジネス・ユーザーに付与します。このロールには、workflow.mapping.publicFlexField権限も付与されます。

- 次のワークフロー権限が定義されます。

- workflow.admin: タスク、ユーザーとグループのルールおよびカスタマイズに関連する管理操作を実行できるユーザーを制御します。

- workflow.admin.evidenceStore: デジタル署名されたタスク(デジタル証明書を使用した署名が必要なタスク)に関連するエビデンス記録を表示および検索できるユーザーを制御します。

- workflow.mapping.publicFlexField: パブリック・マップ済属性にタスク・ペイロード属性のマッピングを実行できるユーザーを制御します。

- workflow.mapping.protectedFlexField: 保護されたマップ済属性にタスク・ペイロード属性のマッピングを実行できるユーザーを制御します。

注意:

Oracle SOA Suiteに対して、複数の認証プロバイダを指定することはできません。これは、OPSSが複数のプロバイダをサポートしていないためです。ヒューマン・ワークフロー認証に使用するプロバイダは、Oracle SOA Suiteの認証プロバイダの順序を示したリスト内で最初のプロバイダである必要があります。

詳細は、次を参照してください。

- OPSSの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』

- Oracle Identity Managementの詳細は

- OVDの詳細は

34.1.5.1 アイデンティティ・サービス・プロバイダ

図34-1 に示すように、Oracle Identity Managementはリリース11g でサポートされている唯一のプロバイダです。

図34-1 アイデンティティ・サービス・プロバイダ

34.1.5.1.1 カスタム・ユーザー・リポジトリ・プラグイン

リリース11g以降、アイデンティティ・サービスでカスタム・プロバイダ・プラグインはサポートされていません。アイデンティティのカスタマイズは、すべてアイデンティティ・ストアで実行されるようになりました。Oracle Fusion Middlewareでは、カスタム・アイデンティティ・ストアと対話するユーザーおよびロールAPIを有効にするプロバイダがサポートされます。詳細は、次のURLを参照してください。

http://www.oracle.com/technetwork/middleware/id-mgmt/overview/index.html

34.1.6 タスク・メタデータ・サービス

タスク・メタデータ・サービスにより、タスク関連のメタデータ情報を取得するための操作が公開されます。表34-6 に、タスク・メタデータ・サービスの一般的な操作の一部を示します。パッケージoracle.bpel.services.workflow.metadataは、タスク・メタデータ・サービスに対応しています。

タスク・メタデータ・サービスの詳細は、『Oracle SOA Suiteワークフロー・サービスJava APIリファレンス』を参照してください。

表34-6 タスク・メタデータ・サービスのメソッド

メソッド

説明

getTaskMetadataByNamespace

指定のタスク定義ネームスペースとコンポジット・バージョンを使用して、ヒューマン・タスク・サービス・コンポーネントが記述されたTaskMetadataオブジェクトを取得します。

getOutcomes

タスクについて許可されている結果を取得します。結果とその表示値が返されます。

getResourceBundleInfo

タスクのリソース・バンドル情報を取得します。リソース・バンドル情報には、バンドルの位置と名前が含まれます。

getRestrictedActions

特定のタスクに対する制限付きアクションを取得します。

getTaskAttributesForTaskDefinitions

標準タスク属性と、指定したタスク定義に共通のマップ済属性列が記述されたTaskAttributeオブジェクトのリストを取得します。

getTaskAttributesForTaskNamespaces

標準タスク属性と、指定したネームスペースで識別されたタスク定義に共通のマップ済属性列が記述されたTaskAttributeオブジェクトのリストを取得します。

getTaskAttributes

タスク・メッセージ属性を取得します。

getTaskAttributesForTaskDefinition

特定のタスク定義のメッセージ属性を取得します。

getTaskDefinition

タスクに関連するタスク定義を取得します。

getTaskDefinitionById

タスク定義IDによるタスク定義を取得します。

getTaskDefinitionOutcome

特定のタスク定義IDの結果を取得します。

getTaskVisibilityRules

タスク表示ルールを取得します。

getTaskDisplayRegion

タスクのタスク表示リージョンを取得します。

getVersionTrackedAttrs

変更された場合にタスク・バージョンが作成されるタスク属性を取得します。

listTaskMetadata

システム内のタスク定義をリストします。

詳細は、『Oracle SOA Suiteワークフロー・サービスJava APIリファレンス』を参照してください。

34.1.7 ユーザー・メタデータ・サービス

ユーザー・メタデータ・サービスは、個々のユーザーおよびグループに固有のメタデータを管理するためのメソッドを提供します。これは、ユーザー・ワークリストのプリファレンスの取得と設定、ユーザーのカスタム・ビューの管理、およびユーザーとグループに対するヒューマン・ワークフロー・ルールの管理に使用されます。

ユーザー・メタデータ・サービスのほとんどのメソッドの場合、認証済ユーザーは独自のユーザー・メタデータを問い合せて更新できます。ただし、他のユーザーに属するメタデータは更新できません。

グループ・メタデータ(グループに対するヒューマン・ワークフロー・ルールなど)の場合、グループのメタデータを問い合せて更新できるのは、そのグループの所有者として指定されているユーザー(またはworkflow.admin権限ユーザー)のみです。ただし、workflow.admin権限があるユーザーは、任意のユーザーまたはグループのメタデータに対して問合せおよび更新を実行できます。

表34-7 に、ユーザー・メタデータ・サービスの一般的な操作の一部を示します。パッケージoracle.bpel.services.workflow.userは、ユーザー・メタデータ・サービスに対応しています。

ユーザー・メタデータ・サービスの詳細は、『Oracle SOA Suiteワークフロー・サービスJava APIリファレンス』を参照してください。

表34-7 ユーザー・メタデータ・サービスのメソッド

メソッド

説明

createRule

新規ルールを作成します。

decreaseRulePriority

ルールの優先度を1つ低くします。このルールが最低優先度の場合、このメソッドでは何も実行されません。

deleteRule

ルールを削除します。

getVacationInfo

ユーザーに対してタスクを割り当てることができない日付の範囲(設定されている場合)を取得します。

getRuleDetail

特定のヒューマン・ワークフロー・ルールの詳細を取得します。

getRuleList

特定のユーザーまたはグループに対するルールのリストを取得します。

updateRule

既存のルールを更新します。

increaseRulePriority

ルールの優先度を1つ高くします。ユーザーまたはグループに対するルールは、優先度の順序付きリストで保守されます。高優先度のルール(リストの先頭に近いルール)は、低優先度のルールよりも先に実行されます。このルールが最高優先度の場合、このメソッドでは何も実行されません。

getUserTaskViewList

ユーザーが所有するユーザー・タスク・ビューのリストを取得します。

getGrantedTaskViewList

ユーザーに他のユーザーから権限付与されたユーザー・タスク・ビューのリストを取得します。ユーザーは付与されたビューを使用してタスクのリストを問合せできますが、ビュー定義は更新できません。

getStandardTaskViewList

ヒューマン・ワークフロー・サービスに付属している標準タスク・ビューのリストを取得します。このビューはすべてのユーザーが使用できます。

getUserTaskViewDetails

単一ビューの詳細を取得します。

createUserTaskView

新規のユーザー・タスク・ビューを作成します。

updateUserTaskView

既存のユーザー・タスク・ビューを更新します。

deleteUserTaskView

ユーザー・タスク・ビューを削除します。

updateGrantedTaskView

このユーザーに対する他のユーザーからのビュー権限付与の詳細を更新します。更新は、ビュー権限付与の非表示または非表示解除(非表示にしたビューは、Oracle BPM Worklistのメイン受信ボックス・ページに表示されません)、および権限を付与されたユーザーに表示されるビュー名および説明の変更に制限されています。

getUserPreferences

ユーザーのユーザー・プリファレンスのリストを取得します。ユーザー・プリファレンスは、単純な名前/値ペアの文字列です。ユーザー・プリファレンスはユーザーごとにプライベートです(ただし、workflow.admin権限があるユーザーも問い合せて更新できます)。

setUserPreferences

ユーザーのユーザー・プリファレンス値を設定します。前に格納されていて新規のユーザー・プリファレンス・リストに含まれていないプリファレンスは削除されます。

getPublicPreferences

ユーザーのパブリック・プリファレンスのリストを取得します。パブリック・プリファレンスは、ユーザー・プリファレンスに類似していますが、すべてのユーザーが問合せできます。ただし、パブリック・プリファレンスを更新できるのは、そのプリファレンスを所有しているユーザー、またはworkflow.admin権限のあるユーザーのみです。パブリック・プリファレンスは、アプリケーション単位のプリファレンスを格納する場合に役立ちます(プリファレンスはMyAppPrefsなどのダミー・ユーザー名で格納できます)。

setPublicPreferences

ユーザーのパブリック・プリファレンスを設定します。

setVacationInfo

ユーザーに対してタスクを割り当てることができない日付の範囲を設定します。(Dynamic Assignment Functionでは、休暇中のユーザーにタスクが割り当てられることはありません。)

getStandardTaskViewDetails

viewIdで識別される特定の標準ビューに関する全詳細を取得します。

詳細は、次を参照してください。

- ルール構成ページとユーザー・プリファレンス・ページの詳細は「Oracle BPM Worklistの使用」

- いくつかのAPIの例を示すサンプルのworkflow-118-JavaSamples

- Oracle SOA Suite ワークフロー・サービスJava APIリファレンス

34.1.8 タスク・レポート・サービス

タスク・レポート・サービスは、レポートを実行してその結果を受け取ります。表34-8 に、レポートのリストを示します。パッケージoracle.bpel.services.workflow.reportは、タスク・レポート・サービスに対応しています。表34-8 に示す標準レポートは、インストールに含まれています。

表34-8 タスク・レポート・サービス

レポート

説明

不参加タスク・レポート

このレポートでは、ユーザーのグループまたは報告先のグループに割り当てられたタスクの中で、まだ獲得されていないために注意が必要なタスクが分析されます。

タスクの優先度レポート

このレポートでは、ユーザー、報告先またはそのグループに割り当てられたタスクの数が優先度別に分析されます。

タスクのサイクル・タイム・レポート

このレポートでは、ユーザーのグループまたは報告先のグループに基づいて、タスクの割当てから完了までの所要時間が分析されます。

タスクの生産性レポート

このレポートでは、ユーザー、報告先またはそのグループについて、特定期間中に割り当てられたタスク数と完了したタスク数が分析されます。

タスク時間分布レポート

このレポートでは、特定期間中に、特定のユーザー、ユーザーのグループまたは報告先がタスクを完了するのに要した時間が分析されます。

34.1.9 ランタイム構成サービス

ランタイム構成サービスは、タスク・サービスのランタイム環境で使用されるメタデータの管理メソッドを提供します。これは、主にタスク・ペイロード・マップ済属性マッピングとタスク詳細の表示に使用するURIの管理をサポートします。

タスク・サービスで使用されるタスク・オブジェクトには、多数のマップ済属性が含まれており、タスク・ペイロードからの情報を移入できます。これにより、タスク・ペイロード情報を問い合せ、タスク・リストに表示し、ヒューマン・ワークフロー・ルールに使用できます。

ランタイム構成サービスは、クライアント・アプリケーションにある特定タスク定義のインスタンスのタスク詳細を表示するURIの問合せおよび更新メソッドを提供します。どのようなタスク定義でも、複数URI表示がサポートされ、異なるURIは異なるアプリケーションに対して使用されます。メソッドgetTaskDisplayInfoにより、特定のタスク定義のURIを問い合せることができます。メソッドsetTaskDisplayInfoにより、新規のURIを定義したり、既存のURIを更新することができます。setTaskDisplayInfoをコールできるのは、workflow.admin権限があるユーザーのみですが、getTaskDisplayInfoは認証されたユーザーがコールできます。

ランタイム構成サービスを使用すると、管理者は単純なタスク・ペイロード属性とこれらのマップ済属性間のマッピングを作成できます。

パブリック・マップ済属性のペイロード・マッピングを更新できるのは、workflow.mapping.publicFlexFieldまたはworkflow.mapping.protectedFlexField権限があるユーザーのみです。保護されたマップ済属性のペイロード・マッピングを更新できるのは、workflow.mapping.protectedFlexField権限があるユーザーのみです。いずれの認証済ユーザーも、このサービスの問合せメソッドを使用できます。

管理者は、各種マップ済属性を表す属性ラベルを作成できます。これらの属性ラベルは、属性にわかりやすいラベルを提供します(たとえば、マップ済属性TextAttribute1を表すラベルLocationを作成できます)。特定のマップ済属性に複数のラベルを関連付けることができます。ユーザーがOracle BPM Worklistで特定のタスクの属性リストを表示すると、この属性ラベルが表示されます。特定のタスク・タイプの属性ラベルは、タスク・メタデータ・サービスのgetTaskAttributesForTaskDefinitionメソッドをコールして決定できます。

属性ラベルを定義する際は、サービスによって次のフィールドに値が自動的に移入されます。これらの属性の値を属性ラベルの作成時または更新時に指定する必要はありません。

- Id

- CreatedDate

- WorkflowType

- Active

パブリック・マップ済属性のタスク属性フィールドの有効値は、次のとおりです。

- TextAttribute1 through TextAttribute20

- FormAttribute1 through FormAttribute10

- UrlAttribute1 through UrlAttribute10

- DateAttribute1 through DateAttribute10

- NumberAttribute1 through NumberAttribute10

その後、タスク・ペイロード・フィールドと属性ラベルとのマッピングを作成できます。たとえば、ペイロード・フィールドcustomerLocationを属性ラベルLocationにマップできます。様々なタスク・タイプで同じ属性ラベルを共有できます。これにより、同じ意味を持つ異なるタスク・タイプのペイロード属性を同じ属性ラベルにマップできます。

注意:

単純なXMLタイプのペイロード・フィールドは直接マップでき、また、XPath式は複雑なペイロード・フィールドから単純なXMLタイプ値を選択するために指定できます。

ランタイム構成サービスでは、次のメソッドも提供されます。

- サーバーでサポートされているDynamic Assignment Functionを問い合せるためのメソッド

- Oracle BPM Worklistおよび他のアプリケーションでのタスク詳細の表示に使用するタスク表示URLを管理するためのメソッド

- サーバーのHTTPおよびJNDI URLを取得するためのメソッド

表34-9 に、ランタイム構成サービスの一般的な操作の一部を示します。パッケージoracle.bpel.services.workflow.runtimeconfigは、ランタイム構成サービスに対応しています。

ランタイム構成サービスの詳細は、『Oracle SOA Suiteワークフロー・サービスJava APIリファレンス』を参照してください。

表34-9 ランタイム構成サービス

メソッド

説明

CreateAttributeLabel

特定のタスク・マップ済属性を表す新規の属性ラベルを作成します。

createPayloadMapping

属性ラベルとタスク・ペイロード・フィールド間の新規マッピングを作成します。

DeleteAttributeLabel

既存の属性ラベルを削除します。

deletePayloadMapping

既存のペイロード・マッピングを削除します。

getAttributeLabelUsages

ラベルが現在使用されているマッピング(存在する場合)の属性ラベル(すべての属性ラベル、または特定のタイプの属性ラベル)のリストを取得します。

getDynamicAssignmentFunctions

このサーバーに実装されているDynamic Assignment Functionのリストを返します。

getTaskDisplayInfo

具体的なタスク定義のタスク・インスタンス表示に使用されるURIに関連する情報を取得します。

getTaskStatus

特定のタスク定義やコンポジット・インスタンスに対応するタスク・インスタンスのステータスを取得します。

GetWorkflowPayloadMappings

特定のヒューマン・ワークフロー定義に関するすべてのマップ済属性マッピングのリストを取得します。

setTaskDisplayInfo

具体的なタスク定義のタスク・インスタンス表示に使用されるURIに関連する情報を設定します。

updateAttributeLabel

既存の属性ラベルを更新します。

詳細は、次を参照してください。

- 詳細は、「動的割当てパターンおよびタスク・エスカレーション・パターン」

- マップ済属性マッピングの詳細は「Oracle BPM Worklistの使用」

- いくつかのAPIの例を示すサンプルのworkflow-118-JavaSamples

- Oracle SOA Suite ワークフロー・サービスJava APIリファレンス

34.1.9.1 属性ラベルの国際化

属性ラベルは、タスク・マップ済属性にわかりやすいラベルを添付するメソッドを提供します。ユーザーのロケールに適した言語に翻訳された属性ラベルを表示することが望ましい場合があります。

カスタム・リソース・バンドルを使用するには、ワークフロー構成パラメータworkflowCustomClasspathURLで識別される場所(ファイルまたはHTTPパス)にリソース・バンドルを配置します。

これは、Oracle Enterprise Manager Fusion Middleware Controlの次のいずれかの場所で設定できます。

- 「システムMBeanブラウザ」ページ

- 「ワークフロー・タスク・サービス・プロパティ」ページ

このパラメータを使用する方法の詳細は、サンプルのworkflow-110-workflowCustomizationsを参照してください。詳細は、Oracle SOA Suiteサンプルを参照してください。

マップ済属性ラベルのエントリには、次の書式を使用する必要があります。

FLEX_LABEL.[label name]=Label Display Name

たとえば、Locationというラベルのエントリは次のようになります。

FLEX_LABEL.Location=Location

これらのファイルに属性ラベルのエントリを追加するかどうかはオプションです。ファイルにエントリが存在しない場合は、APIを使用して指定した属性ラベルの名前がかわりに使用されます。

34.1.10 エビデンス・ストア・サービスとデジタル署名

エビデンス・ストア・サービスは、デジタル署名の保管とデジタル署名されたヒューマン・ワークフローの否認防止に使用します。デジタル署名は、メッセージ送信者や文書署名者のアイデンティティを認証する電子署名です。これにより、送られたメッセージや文書の元の内容が変更されていないことが保証されます。デジタル署名は転送可能で、他人に模倣されることがなく、自動的にタイムスタンプが付けられます。署名されたオリジナルのメッセージが届いたことを証明できるため、送信者が後で否認することはできません。デジタル署名は、ヒューマン・ワークフロー・ドキュメントが次の状態であることを保証します。

- 真正であること

- 他のエンティティで捏造されていないこと

- 変更されていないこと

- 送信者が否認できないこと

暗号ベースのデジタル署名は、公開鍵のアルゴリズムによって送信者の秘密鍵付のメッセージが署名されたときに作成されます。

設計時、タスクに対して署名は有効です。Oracle BPM Worklistの実行時には、ユーザーがタスクを承認または却下すると、Webブラウザでは次の動作が発生します。

- 署名に使用する秘密鍵の選択をユーザーに要求します。

- 秘密鍵とOracle BPM Worklistから提供されたタスク・コンテンツを使用してデジタル署名を生成します。

図34-2 に例を示します。

図34-2 デジタル署名と証明書

注意:

- この証明書は、Personal Information Exchange Syntax Standard (PFX)ファイルを指しています。このファイルには証明書と秘密鍵が含まれており、シンプルなテキスト・パスワードで保護されています。PFXでは、ユーザーの秘密鍵、証明書、その他のシークレットなどを格納またはトランスポートするための移植形式が指定されます。

- 署名は証明書の公開鍵を介して検証できるため、データの署名には、その証明書の公開鍵に対応した秘密鍵の所有で十分です。ただし、証明書のユーザー名と証明書を更新するユーザーを関連付けることはありません。たとえば、ユーザーjsteinがユーザーcdickensの秘密鍵を所有する場合、jsteinはその秘密鍵を使用して署名できます。

次のデジタル署名の機能をサポートします。

- X.509証明書によるPKCS7署名

- ブラウザベースの、添付ファイルなしデジタル署名付コンテンツ

34.1.10.1 前提条件

デジタル署名と証明書を使用するための前提条件は、次のとおりです。

- Oracle BPM Worklistのユーザーは、証明書を持っている必要があります。

- 管理者は、証明書を信頼する必要があるCA、および対応するCRL URLを指定する必要があります。ユーザーは、これらのCAが発行した証明書のみをアップロードする必要があります。そのためには、Oracle Enterprise Manager Fusion Middleware Controlの「システムMBeanブラウザ」を編集します。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. ナビゲータで、「SOA」フォルダを開きます。

3. 「soa-infra」を右クリックし、「管理」→「システムMBeanブラウザ」の順に選択します。
ページの右側に「システムMBeanブラウザ」が表示されます。

4. 「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: server_name」→「WorkflowConfig」→「human-workflow」の順に開きます。

5. ページの右側にある「操作」タブをクリックします。

6. 「addTrustedCA」をクリックします。

7. 「caName」と「caURL」に値を指定します。これは、信頼するチェーンの各証明書に対して実行する必要があります。たとえば、表34-10 に示すように、各起動に対して値を指定します。

表34-10 caNameとcaURLの値

caName

caURL

CN = Intg, OU =AppServ, O =Oracle, C = US

http://www.oracle.com/Integration%20CRL%20Data.crl

CN = Intg1, OU =AppServ, O =Oracle, C = US

http://www.oracleindia.in.com/Integration%20In.crl

CN = Intg2, OU =AppServ, O =Oracle, C = US

http://www.oracle.us.com/integration.crl

8. 「起動」をクリックします。

34.1.10.2 インタフェースとメソッド

表34-11 から表34-14 では、エビデンス・ストア・サービスのメソッドについて説明します。パッケージoracle.bpel.services.security.evidenceは、エビデンス・サービスに対応しています。

表34-11 ITaskEvidenceServiceインタフェース

メソッド

説明

createEvidence

エビデンスを作成し、否認防止のためにリポジトリに保管します。

getEvidence

特定の条件に一致するエビデンスのリストを取得します。結果は、サービスを問い合せるユーザーに関連付けられている権限によって異なります。ユーザーにworkflow.admin.evidenceStore権限(権限の付与方法を詳説した場所を指します)が付与されている場合は、一致するエビデンスはすべて参照可能です。それ以外の場合は、ユーザーが作成したエビデンスのみ参照可能です。

uploadCertificate

後で署名検証に使用する証明書をアップロードします。これが、特定の証明書を使用してエビデンスを作成するための前提条件です。ユーザーがアップロードできるのは、自分の証明書のみです。

updateEvidence

ステータスのCRL検証部分を更新します。これには、検証時間、ステータス、エラー・メッセージ(ある場合)が含まれます。

validateEvidenceSignature

エビデンス署名を検証します。基本的にエビデンスの否認防止チェックを実行します。署名が検証されると、trueの値が返されます。それ以外の場合はfalseが返されます。

表34-12 Evidenceインタフェース

メソッド

説明

getCertificate

このエビデンスの署名に使用する証明書を取得します。

getCreateDate

エビデンスの作成日付を取得します。

getErrorMessage

CRL検証に関連するエラー・メッセージを取得します。

getEvidenceId

エビデンスに関連する一意の識別子を取得します。

getPlainText

このエビデンスの一部として署名されたコンテンツを取得します。

getPolicy

エビデンスの署名ポリシーを取得します。PASSWORDまたはCERTIFICATEのいずれかです。

getSignature

エビデンスの署名を取得します。

getSignedDate

署名が作成された日付を取得します。

getStatus

CRL検証ステータスを取得します。これは、次のいずれかです。

- AVAILABLE: エビデンスはCRL検証に使用できます。

- FAILURE: CRL検証に失敗しました。

- SUCCESS: CRL検証に成功しました。

- UNAVAILABLE: CRLデータをフェッチできませんでした。

- WAIT: CRL検証の処理中です。

getTaskId

このエビデンスが関連付けられているタスクの一意の識別子を取得します。

getTaskNumber

このエビデンスが関連付けられているタスクのタスク番号を取得します。

getTaskPriority

このエビデンスが関連付けられているタスクのタスク優先度を取得します。

getTaskStatus

このエビデンスが関連付けられているタスクのタスク・ステータスを取得します。

getTaskSubStatus

このエビデンスが関連付けられているタスクのタスク・サブステータスを取得します。

getTaskTitle

このエビデンスが関連付けられているタスクのタイトルを取得します。

getTaskVersion

このエビデンスが関連付けられているタスクのバージョンを取得します。

getVerifiedDate

使用した証明書のCRL検証が実行された日付を取得します。

getWorkflowType

このエビデンスが関連付けられているタスクのワークフロー・タイプを取得します。通常はBPELWFです。

表34-13 Certificateインタフェース

メソッド

説明

getCA

証明書発行者の識別名(DN)を取得します。

getCertificate

インタフェースによって抽象化された証明書オブジェクトを取得します。

getID

証明書のシリアル・ナンバーを取得します。

getIdentityContext

この証明書をアップロードするユーザーに関連付けられているアイデンティティ・コンテキストを取得します。

getUserName

この証明書に関連付けられているユーザーの名前を取得します。

isValid

証明書がまだ有効であれば、trueを返します。

表34-14 Policy TypeとWorkflow Typeインタフェース

メソッド

説明

fromValue

文字列表現からオブジェクトを構成します。

value

このオブジェクトの文字列表現を返します。

詳細は、次を参照してください。

- ヒューマン・タスク・エディタでデジタル署名およびデジタル証明書を指定する方法の詳細は「ワークフロー・デジタル署名ポリシーの指定方法」

- Oracle BPM Worklistのタスク・アクションへのデジタル署名の詳細は「ヒューマン・タスク用のタスク・フォームの設計」

34.1.11 タスク・インスタンス属性

タスクは、ユーザーによる実行が必要な作業です。タスクを作成する場合は、そのタスクに参加して操作するユーザーを割り当てます。表34-15 に、アプリケーションでよく使用され、解析されるタスク属性を示します。

表34-15 タスク属性

タスク属性名

説明

task/applicationContext

タスクに関連付けられたアプリケーション・ロール(割当て先、所有者など)が属するアプリケーション。

task/category

(オプション)タスクのカテゴリ。

task/creator

タスクの作成者の名前。

task/dueDate

タスクの期日。これはTo Doタスクで使用されます。

task/identificationKey

(オプション)タスクに対するカスタムの一意識別子。これは、標準のタスクIDとタスク番号に対する追加の一意識別子として設定できます。このキーを使用すると、タスクが作成されたビジネス・オブジェクトの識別子に基づいて、タスクを取得できます。

task/identityContext

ユーザーおよびグループがシードされているアイデンティティ・レルム。単一レルム環境では、デフォルトのレルムがデフォルト値になります。

task/ownerGroup

タスク・インスタンスを所有するグループ(ある場合)。タスク所有者は、アプリケーション・ロール、ユーザーまたはグループのいずれかです。タスクの所有者がグループの場合は、このフィールドが設定されます。

task/ownerRole

タスク・インスタンスを所有しているアプリケーション・ロール(ある場合)。タスク所有者は、アプリケーション・ロール、ユーザーまたはグループのいずれかです。タスクの所有者がアプリケーション・ロールの場合は、このフィールドが設定されます。

task/ownerUser

タスク・インスタンスを所有するユーザー(ある場合)。タスク所有者は、アプリケーション・ロール、ユーザーまたはグループのいずれかです。タスクの所有者がユーザーの場合は、このフィールドが設定されます。

task/payload

XMLとして取得されるタスク・ペイロード。

task/percentageComplete

タスクの完了パーセンテージ。これはTo Doタスクで使用されます。

task/priority

タスクの優先度を定義する整数。数値が低いほど優先度が高くなります。通常は、1から5の数値が使用されます。

task/startDate

タスクの開始日。これはTo Doタスクで使用されます。

task/subCategory

(オプション)タスクのサブカテゴリ。

task/taskDefinitionId

タスクをタスク・メタデータにバインドするタスク定義ID。タスクの開始時は、compositeDN/componentName文字列、または.taskファイルのtargetNamespaceのいずれかです。後者を使用する場合は、targetNamespaceに一致するアクティブなバージョンが使用されます。

task/taskDisplayUrl

タスク詳細の表示に使用するURL。

task/title

タスクのタイトル。

表34-16 に、プロセス・メタデータ情報を取得する属性を示します。

表34-16 プロセス・メタデータ情報を取得する属性

属性

説明

task/sca/applicationName

このタスク・インスタンスを定義するタスク・コンポーネントがデプロイされるパーティション。

task/sca/componentName

タスク・インスタンスを定義するタスク・コンポーネントの名前。

task/sca/compositeDN

タスク・インスタンスを定義するタスク・コンポーネントを含むコンポジットの特定のデプロイメントの一意名。

task/sca/compositeInstanceId

コンポジット・インスタンスID。

task/sca/compositeName

タスク・インスタンスを定義するタスク・コンポーネントを含むコンポジットの名前。

task/sca/compositeVersion

タスク・インスタンスを定義するタスク・コンポーネントを含むコンポジットのバージョン。

task/sca/compositeCreatedTime

このタスク・インタスタンスが属すコンポジット・フローが開始された日付および時間。

task/sca/flowId

このタスク・インタスタンスが属すコンポジット・フローの一意の識別子。

表34-17 に、添付ファイル関連の属性を示します。

表34-17 添付ファイル関連の属性

属性

説明

task/attachment/content

添付ファイルのコンテンツ。

task/attachment/mimeType

添付ファイルのMultipurpose Internet Mail Extension (MIME)タイプ。

task/attachment/name

添付ファイルの名前。

task/attachment/updatedBy

添付ファイルを更新したユーザー。

task/attachment/updatedDate

添付ファイルの更新日付。

task/attachment/URI

URI(添付ファイルがURIベースの場合)。

表34-18 に、コメント関連の属性を示します。

表34-18 コメント関連の属性

属性

説明

task/userComment/comment

ユーザーのコメント。

task/userComment/updatedBy

コメントを追加したユーザー。

task/userComment/updatedDate

コメントが追加された日付。これは、コメントの保存時にサービスによって設定されます。コメントの保存時にクライアントによって設定された場合は、無視されます。

task/userComment/displayNameLanguage

コメントの読取り時にサービスによって設定されます。これは、updatedBy displayNameに移入する言語を示します。

task/userComment/acl

使用されません。

task/userComment/doesBelongToParent

コメントを親から継承した場合(サンプル・プロセス・コメント)。

task/userComment/isSystemComment

コメントがワークフロー・システムによって設定された場合、サービスによって設定されます(たとえば、タスクがアラート状態になった場合、コメントが作成されます)。

task/userComment/taskId

コメントが作成されたtaskId。たとえば、スコープがBPMの場合、コメントが作成されたタスクと異なるタスクにコメントが表示されることがあります。また、パラレル・タスクの場合も、現在のtaskIdとコメントtaskIdが異なることがあります。これはサービスによって設定されます。

task/userComment/commentScope

値がnull、空またはTASKの場合、コメントがそのタスク専用であることを意味します。値がBPMの場合、プロセス全体に対するものであることを意味します。コメントをプロセス全体に適用可能にする場合は、コメントの追加時に値をBPMに設定する必要があります。

task/userComment/updatedBy/id

コメントを更新したユーザーのID。

task/userComment/updatedBy/displayName

コメントを更新したユーザーの表示名。

task/userComment/updatedBy/type

コメントを更新したユーザーのユーザーのタイプ、グループまたはロール。

表34-19 に、ワークフロー・サービス・システムで操作される属性を示します。

表34-19 ワークフロー・サービス・システムで操作される属性

属性

説明

task/systemAttributes/acquiredBy

グループ、アプリケーション・ロールまたは複数のユーザーに割り当てられたタスクが、ユーザーによって申告された場合、このフィールドはタスクを申告したユーザーの名前に設定されます。

task/systemAttributes/approvers

タスクに対してカスタム・アクションを実行したユーザーのID。

task/systemAttributes/assignedDate

このタスクが割り当てられた日付。

task/systemAttributes/assignees

現在のタスク割当て先(ユーザー、グループまたはアプリケーション・ロール)。

task/systemAttributes/createdDate

タスク・インスタンスが作成された日付。

task/systemAttributes/customActions

タスクに対して実行できるカスタム・アクション。

task/systemAttributes/endDate

タスクの終了日。これはTo Doタスクで使用されます。

task/systemAttributes/expirationDate

タスク・インスタンスの有効期限の日付。

task/systemAttributes/fromUser

タスクを前に操作したユーザー。

task/systemAttributes/hasSubTasks

trueの場合は、サブタスクがあります。

task/systemAttributes/isGroup

trueの場合は、タスクがグループに割り当てられています。

task/systemAttributes/originalAssigneeUser

ユーザーが別のユーザーにタスクを委任している場合、このフィールドには、タスクを委任したユーザーの名前が移入されます。

task/systemAttributes/outcome

タスクの結果(承認済、却下済など)。このフィールドは、完了したタスク・インスタンスにのみ設定されます。

task/systemAttributes/parentTaskId

これは、再開されたタスクにのみ設定されます(再開される前のタスクのタスクID)。

task/systemAttributes/parentTaskVersion

これは、サブタスクにのみ設定されます。親タスクのバージョンを参照します。

task/systemAttributes/participantName

Oracle JDeveloperからモデリングされた参加者の論理名。

task/systemAttributes/reviewers

タスクのレビューア。これは、ユーザー、グループまたはアプリケーション・ロールです。

task/systemAttributes/rootTaskId

ルート・タスクのID。これは、ルート・タスクのタスクIDと同じです。

task/systemAttributes/stage

実行中のステージ名。

task/systemAttributes/state

タスク・インスタンスの現在の状態。

task/systemAttributes/substate

タスクの現在のサブ状態。

task/systemAttributes/subTaskGroupInstanceId

サブタスクに設定されている一意のID。これと同じIDが親タスクのtaskGroupInstanceIdに設定されます。これは、どの時点でどのサブタスクが作成されたかを識別するために必要です。

task/systemAttributes/systemActions

タスクに対して実行できるシステム・アクション(再割当て、エスカレートなど)。

task/systemAttributes/taskDefinitionName

タスク・インスタンスを定義するタスク・コンポーネントの名前。

task/systemAttributes/taskGroupId

直接の親タスクのID。サブタスクのみが設定されます。

task/systemAttributes/taskGroupInstanceId

親タスクに設定される一意のID。これと同じIDがサブタスクのsubTaskGroupInstanceIdに設定されます。これは、どの時点でどのサブタスクが作成されたかを識別するために必要です。

task/systemAttributes/taskId

タスクの一意のID。

task/systemAttributes/taskNamespace

このタスク・インスタンスを定義するタスク・コンポーネントの全バージョンを一意に定義するネームスペース。同じタスク・コンポーネントの異なるバージョンに同じネームスペースを指定することは可能ですが、異なる2つのタスク・コンポーネントに同じネームスペースを指定することはできません。

task/systemAttributes/taskNumber

タスク・インスタンスを一意に識別する整数。

task/systemAttributes/updatedBy

タスクを最後に更新したユーザー。

task/systemAttributes/updatedDate

このインスタンスが最後に更新された日付。

task/systemAttributes/version

タスクのバージョン。

task/systemAttributes/versionReason

バージョンが作成された理由。

task/systemAttributes/workflowPattern

実行されるパターン(パラレル、シリアル、FYI、単一など)。

表34-20 にマップ済属性を示します。

表34-20 マップ済属性

属性

説明

task/systemMessageAttributes/*

マップ済属性です。

34.2 ヒューマン・ワークフローからの通知

通知は、タスクの状態が変化したことをユーザーに警告するために送信されます。通知は、電子メール、電話ボイス・メッセージ、インスタント・メッセージ(IM)、ショート・メッセージ・サービス(SMS)のいずれかのチャネルを通じて送信できます。通知はBPELプロセスのヒューマン・タスクから、または直接BPELプロセスから送信できます。

11g 以前のリリースでは、電子メール通知はヒューマン・ワークフロー電子メール通知レイヤーを通じて送信されていました。ボイスまたはSMSの通知は、オラクル社のホスティング通知サービスを通じて送信されていました。IM通知はサポートされていませんでした。

リリース11g 以降、ヒューマン・ワークフロー電子メール通知レイヤーはOracle User Messaging Serviceと連携し、タスクの状態が変化したことをユーザーに警告します。Oracle User Messaging Serviceでは、BPELプロセスまたはヒューマン・タスクから起動できる、電子メール、ボイス、IMまたはSMSのいずれかのチャネルを通じて通知を送信するための操作が公開されています。

Oracle User Messaging Serviceは次の機能をサポートしています。

- メッセージおよびステータスの送受信

- 特定のチャネルの指定したアドレスへの通知送信

- 一連のフェイルオーバー・アドレスへの通知送信

Oracle Fusion Middleware以外のアプリケーション・サーバーでは、電子メール通知に対してヒューマン・ワークフロー電子メール通知レイヤーを使用できます。

Oracle User Messaging Serviceの構成に関する詳細は、次を参照してください。

- 通知サービスの使用

- Oracle User Messaging Serviceによるアプリケーションの開発

- Oracle Enterprise Manager Fusion Middleware Controlで通知サービス配信チャネルを構成する手順は、『Oracle User Messaging Serviceの管理』を参照してください。

34.2.1 通知のコンテンツ

各電子メール通知には、次のパートを含めることができます。

- 通知メッセージ

- Oracle BPM WorklistからのHTMLコンテンツ
これは、タスクに関するOracle BPM Worklistの読取り専用ビューです。Oracle BPM Worklistからのコンテンツを含むように電子メール通知を構成する方法は、「電子メール通知の作成」を参照してください。

- タスクの添付ファイル:
通知にタスクの添付ファイルが含まれている場合です。

- アクション可能リンク

SMS、IMおよびボイスによる通知には、通知メッセージのみが含まれます。

通知メッセージは、静的なテキストと動的な値を含めることができるXPath式です。メッセージの作成時に動的な値に使用できるのは、タスクBPEL変数のみです。メッセージはBPELプロセスのコンテキスト外で評価されるため、この制限があります。また、タスク変数のペイロードでは、XPathツリー参照用のペイロードの型を含むために、強い型指定が使用されます。XPath拡張関数hwf:getNotificationProperty(propertyName)を使用すると、特定の通知のプロパティを取得できます。この関数は、対応する値に対して通知ごとに評価されます。propertyNameの値は、次のいずれかです。

- recipient
通知の受信者

- recipientDisplay
受信者の表示名

- taskAssignees
タスクの割当て先

- taskAssigneesDisplay
タスク割当て先の表示名

- locale
受信者のロケール

- taskId
通知対象となるタスクのID

- taskNumber
通知対象となるタスクの番号

- appLink
Oracle BPM Worklistのタスク詳細ページへのHTMLリンク

次の例に、hwf:getNotificationPropertyとhwf:getTaskResourceBundleを使用する方法を示します。

concat('Dear ', hwf:getNotificationProperty('recipientDisplay'), ' Task ',
/task:task/task:systemAttributes/task:taskNumber, ' is assigned to you. ',
hwf:getTaskResourceBundleString(/task:task/task:systemAttributes/task:taskId,
'CONGRATULATIONS', hwf:getNotificationProperty('locale')))

この場合、メッセージは次のようになります。

Dear Cooper, James Task 1111 is assigned to you. Congratulations

34.2.2 エラー・メッセージのサポート

ヒューマン・ワークフロー電子メール通知レイヤーは、介入が必要なエラーが発生した場合に管理者に警告するように、自動的に構成されます。エラー通知とエラー・レスポンス・メッセージは維持されます。

メッセージは、Oracle Enterprise Manager Fusion Middleware Controlで表示できます。

メッセージの表示の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

34.2.3 信頼性のサポート

Oracle User Messaging Serviceと連携するヒューマン・ワークフロー電子メール通知レイヤーでは、次の信頼性をサポートしています。

- 次の場合、メッセージは紛失しません。

- ヒューマン・ワークフローからのメッセージ受信を確認した後で、ヒューマン・ワークフロー電子メール通知レイヤーで障害が発生した場合。

- Oracle User Messaging Serviceがヒューマン・ワークフローからのメッセージ受信を確認する前に、ヒューマン・ワークフロー電子メール通知レイヤーとOracle User Messaging Serviceの両方で障害が発生した場合。

- Oracle User Messaging Serviceが停止した場合。メッセージ配信は成功するまで再試行されます。

- 通知チャネルが停止した場合。

- 通知が配信できない場合は3回再試行され、そのアドレスが無効としてマークされます。また、そのアドレスは不正アドレス・リストに追加されます。必要な場合は、Oracle Enterprise Manager Fusion Middleware Controlで不正アドレス・リストからアドレスを手動で削除できます。発信通知は、アドレスが訂正されるまで再送信されません。不適切に識別されるのを防ぐために、アドレスが無効とマークされるのは約1時間のみです。この時間内に、新規の通知が送信されることはありません。

- スパム・メール発信者として識別されているアドレスからの受信通知レスポンスは無視されます。

- 受信通知メッセージは維持されます。

- 通知配信失敗を示す受信通知レスポンス(ホスト不明メールなど)は無視されません。かわりに修正処理(不正アドレス・リストの更新など)が自動的に実行されます。

- 受信通知レスポンスは、通知ステータスを示す確認が送信者に送られるように構成できます。

- 受信通知レスポンスの検証は、受信通知メッセージと送信通知メッセージを関連付けて実行されます。

通知の詳細は、次を参照してください。

- 通知サービスの使用

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

34.2.4 Oracle Human Workflow通知サービスの管理

管理者は、次の管理タスクをOracle Enterprise Manager Fusion Middleware Controlから実行できます。

- 失敗した通知や誤りのある受信通知レスポンスを表示し、修正処理を実行します。

- 送信通知とアドレスの削除、再送信、編集などの修正処理を実行します。

- 受信通知レスポンスについて、不正な電子メールを表示して電子メール・アドレスをブロックします。

- 不正な電子メール・アドレスのリストを管理します。

- 失敗した通知のランタイム・データにアクセスします。このデータは、不要になった場合消去できます。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

34.2.5 通知チャネル・プリファレンスの構成方法

通知チャネル・プリファレンスを構成する手順は、次のとおりです。

1. Oracle JDeveloperで、電子メールおよび他のチャネル用の通知サービスを構成します。詳細は、「通知サービスの使用」を参照してください。

2. Oracle JDeveloperで、ヒューマン・タスク・エディタを開きます。

タスク通知は、ヒューマン・タスク・エディタでタスクを作成するときに構成できます。異なるアクションについて、様々なタイプの参加者に通知を送信できます。

タスク通知が送信可能なアクションについては、「受信者へのタスク・ステータス変更の通知方法」を参照してください。

通知は、様々な範囲でタスクに関与するユーザーに送信できます。これらのユーザーについては、「受信者へのタスク・ステータス変更の通知方法」を参照してください。

タスクがグループに割り当てられていて、そのグループに通知エンドポイントが設定されていない場合は、グループの各ユーザーに通知が送信されます。

詳細は、次を参照してください。

- 通知サービスの使用

- ヒューマン・タスク・エディタでタスク通知を構成するには、「参加者の通知プリファレンスの指定」を参照してください

- 通知チャネルの構成の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照

3. Oracle Enterprise Manager Fusion Middleware Controlのメッセージング・サーバー・ページから、適切なチャネル(電子メールなど)を構成します。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

4. Oracle Enterprise Manager Fusion Middleware Controlの「ワークフロー通知プロパティ」ページから、すべてのチャネルまたは電子メールに、通知サービスの通知モード・パラメータを構成します。

この値は、デフォルトで「なし」に設定されています。これは、通知が送信されないことを意味します。有効な値は、次のとおりです。

- すべて
電子メール、IM、SMSおよびボイスのチャネルを構成し、任意のチャネルを通じて通知を送信します。

- 電子メール
通知メッセージ送信に、電子メール・チャネルのみが構成されます。

- なし
通知メッセージの送信用にどのチャネルも構成されません。これがデフォルトの設定です。

34.2.6 異なる言語による通知メッセージの構成方法

通知は、複数のソースから生成され多様に国際化された4つのタイプのデータで構成されます。

様々な言語で通知メッセージを構成する手順は、次のとおりです。

1. 次の方法のいずれかを使用して、通知コンテンツのメッセージを国際化します。

a. タスク定義の際に指定したリソース・バンドル中の値を使用するには、次のXPath拡張関数を使用します。

hwf:getTaskResourceBundleString(taskId, key, locale?)

この関数は、タスク定義で指定されたリソース・バンドルから、国際化された文字列を返します。

通知受信者ロケールは、次の関数によって取得できます。

hwf:getNotificationProperty('locale')

通知に対応するタスクIDは、次の関数によって取得できます。

hwf:getNotificationProperty('taskId')

b. 異なるリソース・バンドルが使用されている場合は、次のXPath拡張関数を使用してローカライズされたメッセージを取得します。

orcl:get-localized-string()

ただし、国際化されたすべての通知のロケールは、アイデンティティ・サービスのBPMUserオブジェクトから取得されます。

- パッケージ済の文字列(アクション・リンク、コメント、Oracle BPM Worklistなど)
これらの文字列は、次のパッケージの一部として製品に国際化されています。

oracle.bpel.services.workflow.resource

ユーザーのロケールは適切なメッセージの取得に使用します。

- タスク詳細添付
ユーザーのロケールはタスク詳細HTMLコンテンツの取得に使用します。

- タスクの結果文字列(承認、却下など)
ヒューマン・タスク・エディタの「詳細設定」セクションでタスク定義がモデリングされると、結果のリソース・バンドルが指定されます。リソース・バンドルの各結果のキーは結果の名前そのものです。

- 通知メッセージ

詳細は、「多言語設定の指定方法」を参照してください。

34.2.7 アクション可能なメッセージの送信方法

アクション可能なメッセージの送信方法は数種類あります。この項では、手順の概要について説明します。

注意:

タスクに対してデジタル署名が有効な場合、アクション可能な電子メールは実行時に送信されません。設計時にアクション可能な電子メールが有効化された場合も同様です。

34.2.7.1 ヒューマン・タスクのアクション可能な電子メールの送信方法

アクション可能な電子メールを使用できるようにタスクを設定している場合は、電子メールを介してタスク・アクションを実行できます(同じアクションをOracle BPM Worklistからも実行できます)。アクション可能な電子メール・アカウントは、タスク・アクション関連の電子メールを受信して処理します。

ヒューマン・タスクのアクション可能な電子メールを送信する手順は、次のとおりです。

1. ヒューマン・タスク・エディタの「通知」セクションの「詳細」タブで、「通知をアクション可能にする」を選択して、電子メール通知をアクション可能にします。このアクションにより、電子メールを介してタスク・アクションを実行できます。

通知がアクション可能な場合、電子メールにはカスタムの結果ごとにリンクが含まれます。

2. 通知メッセージでタスクの添付ファイルを送信するには、「電子メール通知によるタスクの添付ファイルの送信」を選択します。

アクション可能な電子メールが到着した後に、次のタスクを実行します。

3. Oracle Enterprise Manager Fusion Middleware Controlの「Oracle User Messaging Service」セクションから、受信サーバー、送信メール・サーバー、送信ユーザー名とパスワードなどのプロパティを設定します。

4. Oracle Enterprise Manager Fusion Middleware Controlの「ワークフロー通知プロパティ」ページで、通知モードを「すべて」または「電子メール」に設定します。

5. 「承認」リンクをクリックし、新規の電子メール・ウィンドウを起動します。このウィンドウには、承認データが表示されます。図34-3に詳細を示します。

図34-3 アクション可能な通知

6. 承認メールの「コメント」セクションにコメントを追加します。次に例を示します。

This contract has been approved based on the attached information.

7. 図34-4 に示すように、必要に応じて添付ファイルを追加します。

図34-4 アクション可能な電子メールへの添付ファイル

8. この電子メールの件名や本文など、何も変更しないでください。NID部分文字列を含むコンテンツを変更すると、電子メールは処理されません。

9. 「送信」をクリックします。

10. Oracle Enterprise Manager Fusion Middleware Controlの「ワークフロー・タスク・サービス・プロパティ」ページで、アクション可能な電子メールのアカウント名を設定します。

Oracle Enterprise Manager Fusion Middleware Controlの「Oracle User Messaging Service」セクション、「ワークフロー通知プロパティ」ページおよび「ワークフロー・タスク・サービス・プロパティ」ページの詳細は、『Oracle User Messaging Serviceの管理』と『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

34.2.8 インバウンドおよびアウトバウンド添付ファイルの送信方法

「添付ファイルを含む」フラグが選択されている場合は、電子メールのみが送信されます。電子メールには、タスクのすべての添付ファイルが電子メール添付ファイルとして含まれます。

インバウンドおよびアウトバウンド添付ファイルを送信する手順は、次のとおりです。

1. ヒューマン・タスク・エディタの「通知」セクションの「詳細」タブで、「電子メール通知によるタスクの添付ファイルの送信」を選択します。

アクション可能な電子メール・リプライでは、電子メールに添付ファイルを追加できます。これらの添付ファイルはタスクの添付ファイルとして追加されます。

詳細は、「電子メール・メッセージをアクション可能にする方法」を参照してください。

34.2.9 インバウンド・コメントの送信方法

インバウンド・コメントを送信する手順は、次のとおりです。

1. アクション可能な電子メール・リプライでは、図34-3に示すとおり、Comments[[‘と‘]] の間にコメントを追加します。これらのコンテンツはタスクのコメントとして追加されます。たとえばComments[[looks good]]とします。

34.2.10 セキュアな通知の送信方法

セキュアな通知を送信する手順は、次のとおりです。

1. ヒューマン・タスク・エディタの「通知」セクションの「詳細」タブで、「通知のセキュア化(詳細を除く)」を選択します。これにより、デフォルトの通知メッセージを使用できます。この場合、通知メッセージにはタスクのコンテンツは含まれません。また、この通知はアクション可能ではありません。デフォルトの通知メッセージには、Oracle BPM Worklist内のタスクへのリンクが含まれています。タスク詳細を参照するにはログインする必要があります。

詳細は、「詳細を除く通知をセキュア化する方法」を参照してください。

34.2.11 通知に使用されるチャネルの設定方法

通知に使用されるチャネルを設定する手順は、次のとおりです。

1. Oracle BPM Worklistのプリファレンス・ユーザー・インタフェースを使用して優先通知チャネルを設定します。チャネルは、通知を送信する前にユーザー・プリファレンス・ストアに問い合せることで、動的に決定されます。ユーザー・プリファレンスが指定されていない場合は、電子メールのチャネルが使用されます。

Oracle Delegated Administration Serviceの詳細は、を参照してください。

34.2.12 リマインダの送信方法

タスクは、リマインダを送信するように構成できます。リマインダは、タスクがユーザーに割り当てられた時刻またはタスクの有効期限が切れる時刻に基づいています。リマインダの数およびリマインダ間の間隔も構成可能です。タスクがASSIGNEDとしてマークされている場合、リマインダに使用されるメッセージはASSIGNEESに対するメッセージです。

リマインダを送信する手順は、次のとおりです。

1. ヒューマン・タスク・エディタの「通知」セクションの「詳細」タブで、リマインダを設定します。リマインダ構成に関連するパラメータは、次のとおりです。

- Recurrence:
リマインダの送信回数を指定します。recurrenceに使用可能な値は、EVERY、NEVER、0、1、2 …、10です。

- RelativeDate:
タスクの割当て日または有効期限日のどちらからリマインダ期間を相対的に計算するかを指定します。relativeDateに使用可能な値は、ASSIGNED、EXPIRATIONおよびBEFORE DUE DATEです。「要求されたアクションの期日」オプション(以前のリリースでは「期間を使用」と呼ばれていたオプション)を使用するために、タスクのエスカレーションおよび有効期限ポリシーを変更した場合、Oracle JDeveloperには最終的な値が表示されます。

- Duration:
relativeDateからの、最初のリマインダとそれ以降の各リマインダの期間を指定します。期間のデータ型は、xsd:durationであり、その書式はISO 8601によりPnYnMnDTnHnMnSという形式で定義されています。大文字はデリミタであり、対応するメンバーを使用しない場合は省略できます。この例には、PT1004199059S、PT130S、PT2M10S、P1DT2S、-P1Y、P1Y2M3DT5H20M30.123Sなどがあります。

次の例で、リマインダが送信されるタイミングを具体的に説明します。

- relativeDateがASSIGNED、recurrenceがEVERY、およびリマインダの期間がPT1Dであるとします。タスクが2005年3月24日午前10:00に割り当てられた場合、リマインダは2005年3月25日午前10:00、2005年3月26日午前10:00、2005年3月27日午前10:00に送信され、さらにユーザーがタスクに対するアクションを実行するまで続きます。

- relativeDateがEXPIRATION、recurrenceが2、およびリマインダ期間がPT1Dであるとします。タスクの有効期限切れが2005年3月26日午前10:00で、タスクが2005年3月24日午前10:00より前に割り当てられた場合、リマインダは2005年3月24日午前10:00と2005年3月25日午前10:00に送信されます。

- relativeDateがEXPIRATION、recurrenceが2、およびリマインダ期間がPT1Dであるとします。タスクの有効期限切れが2005年3月26日午前10:00で、タスクが2005年3月24日午後3:00に割り当てられた場合、リマインダは2005年3月25日午前10:00の1回のみ送信されます。

詳細は、「リマインダの設定方法」を参照してください。

34.2.13 未処理メッセージに対する自動返信の設定方法

システム・エラー、例外エラー、ユーザー・エラーなどのために、受信メッセージを処理できない場合、ヒューマン・ワークフロー通知サービスは自動返信メッセージを送信します。グローバル・リソース・バンドル内のこれらのメッセージに対するテキストは変更できます。次のコード・サンプルは、WorkflowLabels.propertiesファイルを示しています。詳細は、「グローバル・リソース・バンドル - WorkflowLabels.properties」を参照してください。

# String to be prefixed to all auto reply messages
AUTO_REPLY_PREFIX_MESSAGE=Oracle Human Workflow Service
# String to be sufixed to all auto reply mesages
AUTO_REPLY_SUFFIX_MESSAGE=This message was automatically generated by Human \
Workflow Mailer. Do not reply to this mail.

# Message indicating closed status of a notified task
TaskClosed=You earlier received the notification shown below. That notification \
is now closed, and no longer requires your response. You may \
simply delete it along with this message.

# Message indicating that notification was "replied" to instead of "responded" by
# using the response link.
EMailRepliedNotification=The message you sent appeared to be a reply to a \
notification. To respond to a notification, use the \
response link that was included with your notification.

#
EMailUnSolicited= The message you sent did not appear to be in response to a \
notification. If you are responding to a notification        \
Use the response link that was included with your notification.

EMailUnknownContent= The message you sent did not appear to be in response to a \
notification. If you are responding to a notification,      \
Use the response link that was included with your notification.

ResponseNotProcessed=Your response to notification could not be processed. \
Log in to worklist application for more details.

ResponseProcessed=Your response to notification was successfully processed.

34.2.14 カスタム通知ヘッダーの作成方法

タスク参加者が複数の通知チャネルにアクセスする可能性もあります。カスタム通知ヘッダーを使用すると、このような参加者のタイプが通知を受信する優先チャネルとして単一のチャネルを指定できます。

カスタム通知ヘッダーを作成する手順は、次のとおりです。

1. ヒューマン・タスク・エディタの「通知」セクションの「詳細」タブの「通知ヘッダーの属性」セクションで、使用する優先通知チャネル(ボイス、SMSなど)を指定するカスタム通知ヘッダーを作成します。ヒューマン・ワークフロー電子メール通知レイヤーは、これらのヘッダー値をOracle User Messaging Serviceのルールベース通知サービスに提供します。

たとえば、「名前」フィールドをdeliveryTypeに設定し、「値」フィールドをSMSに設定します。

ルールベースの通知サービスは、使用する優先通知チャネルを特定する目的のみに使用されます。優先チャネルのアドレスは、Oracle Identity Managementから取得されます。通知メッセージは、両方のサービスによって提供される情報から作成されます。

詳細は、次を参照してください。

- 「電子メール通知によるタスクの添付ファイルの送信方法」

- Oracle User Messaging Serviceによるアプリケーションの開発

34.3 割当てサービスの構成

この項では、Dynamic Assignment Functionを使用した割当てサービスの構成方法について説明します。この項の内容は、次のとおりです。

- 動的割当てパターンおよびタスク・エスカレーション・パターン

- 割当てサービスによるタスク参加者の動的割当て

- カスタム・エスカレーション関数

34.3.1 動的割当てパターンおよびタスク・エスカレーション・パターン

タスクがグループ、アプリケーション・ロールまたはユーザー・リストに割り当てられると、単一のユーザーは、操作対象のタスクを申告する必要があります。ただし、様々なディスパッチ・メカニズムを使用すると、ユーザーに作業を自動的に送信できます。

自動タスク・ディスパッチは、動的割当てパターンを介して実行されます。動的割当てパターンでは、グループまたはユーザーやグループのリストから、特定のユーザーまたはグループが選択されます。同様に、タスクがエスカレートされる場合、タスク・エスカレーション・パターンを使用して、タスクのエスカレート先となるユーザーを決定できます。組込みパターンがいくつか用意されています。ただし、動的割当ておよびタスク・エスカレーション用の独自のパターンを作成して、ワークフロー・サービスに登録することもできます。表34-21 に、組込みの3つの動的割当てパターンと1つのタスク・エスカレーション・パターンを示します。

表34-21 動的割当てパターン

割当てパターン

タイプ

説明

LEAST_BUSY

動的割当て

現在割り当てられているタスク数が最も少ないユーザーまたはグループを選択します。

MOST_PRODUCTIVE

動的割当て

特定の期間(デフォルトでは過去7日間)に最も多くのタスクを完了したユーザーまたはグループを選択します。

ROUND_ROBIN

動的割当て

各ユーザーまたはグループを順番に選択します。

MANAGERS_MANAGER

タスク・エスカレーション

マネージャのマネージャを選択します。

これらのパターンではいずれもユーザーの休暇ステータスがチェックされます。現在割当てできないユーザーにタスクが自動的に割り当てられることはありません。

「単一参加者タイプの構成方法」に示すように、タスク参加者を定義する場合には動的割当てパターンを使用できます。「グループ・ルールの作成方法」に示すように、これらをタスク割当てルールとともに使用すると、エンド・ユーザーは、管理するグループのメンバーに対してタスクの動的割当てを指定できるようになります。

動的割当てパターンは、タスク定義の任意のXpath式でXpath関数を使用してコールすることもできます。

関数のシグネチャは次のとおりです。

hwf:dynamicTaskAssign(patternName, participants, inputParticipantType,
targetAssigneeType, isGlobal, invocationContext, parameter1, parameter2, ...,
parameterN)

パラメータは次のとおりです。

- patternName: 必須。使用するパターンの名前。

- participants: 必須。割当て先として選択される参加者(複数可)。参加者名や参加者名のカンマ区切りリストを含む文字列または要素にするか、あるいは参加者名や参加者名のカンマ区切りリストを含む一連の要素にすることができます。参加者のタイプはすべて同じである必要があります。

- inputParticipantType: 必須。入力する参加者のタイプ(user、groupまたはapplication_role)。

- targetAssigneeType: 必須。選択する割当て先のタイプ(user、groupまたはapplication_role)。値は、関数が使用されているコンテキストと一致する必要があります(たとえば、所有者ユーザーを動的に選択する場合にはuserである必要があります)。inputParticipantTypeがuserである場合、ここで有効な値はuserのみです。

- isGlobal: パターンの評価にすべてのタイプのタスクを使用するか、または同じタイプのタスクのみを現在のタスクとして使用するかを示すブール値。オプション(デフォルトはfalseです)。

- invocationContext: この関数が使用されている場所を一意に識別する文字列。指定しない場合は、デフォルトのコンテキストが割り当てられます。

- parameterN: 一部の動的割当てパターンではパラメータを指定できます。パラメータ値は、=文字をデリミタとして使用し、名前/値ペアとして指定できます(TIME_PERIOD=7など)

使用例:

hwf:dynamicTaskAssign(“LEAST_BUSY","jcooper,jstein,mtwain","user","user","true","ErrorAssignee")

hwf:dynamicTaskAssign(“MOST_PRODUCTIVE",task:task/task:payload/task:users,"user","user","false","OwnerUser","TIME_PERIOD=7")

hwf:dynamicTaskAssign(“LEAST_BUSY","DeveloperRole","application_role","group"):

12c リリース1 (12.1.3)より前は、XPath関数のwfDynamicUserAssignおよびwfDynamicGroupAssignを使用して動的割当てを実行できました。これらのXPath関数は、12cリリース1 (12.1.3)では非推奨です。引き続き使用は可能ですが、これらのXPath関数の既存の使用をすべて新しいdynamicTaskAssign関数に移行することをお薦めします。

34.3.1.1 動的割当てパターンの実装方法

次の手順に従って、独自の動的割当てパターンを実装します。

動的割当てパターンを実装する手順は、次のとおりです。

次のインタフェースを実装するJavaクラスを記述します。

oracle.bpel.services.workflow.assignment.dynamic.IDynamicAssignmentPattern

メソッドgetAssigneeFromParticipantListを実装することにより、(すべて同じタイプの)参加者リストから単一の割当て先を選択するためのサポートを、実装で提供する必要があります。

実装により、すべての割当て先タイプがサポートされる必要はありません。インタフェースでメソッドgetSupportedAssigneeTypeを使用することにより、実装時に、サポートする割当て先のタイプを指定できます。

実装で選択基準を指定する入力パラメータを受け入れると、Dynamic Assignment Frameworkがこれらの入力パラメータを検証し、実装はそのパラメータ(ある場合)をメソッドgetPatternParameters()で定義できます。

実装では、実装の初期化時にフレームワークによって設定される初期化パラメータを受け入れることができます。パラメータ値は(configMBeanを使用するか、Oracle Enterprise Manager Fusion Middleware Controlでのヒューマン・ワークフロー・サービス・エンジン構成によって)ヒューマン・ワークフロー構成で定義されており、ここに動的割当てパターンが登録されます。

便宜上、フレームワークでは、一部の共通機能を実装するクラスAbstractDynamicAssignmentPatternが提供されています。割当てパターンの実装により、この抽象クラスを拡張して、一部のパラメータおよびローカライズ・サポートの実装を保存できます。

11g (11.1.1.6.0)より前は、カスタムの動的割当てパターンは、次のインタフェースのいずれかまたは両方を使用して実装されていました。

oracle.bpel.services.workflow.assignment.dynamic.IDynamicGroupAssignmentFunction
oracle.bpel.services.workflow.assignment.dynamic.IDynamicUserAssignmentFunction

これらのインタフェースはIDynamicAssingmentPatternインタフェースで使用可能なすべての機能を備えているわけではなく、非推奨になりました。Dynamic Assignment Frameworkは、古いインタフェースを使用する実装との下位互換性を維持していますが、新しいインタフェースの使用が必要なすべての実装を移行することをお薦めします。

動的割当てのインタフェースとユーティリティに関するJavadocの詳細は、『Oracle Fusion Middleware Workflow Services Java API Reference for Oracle BPEL Process Manager』を参照してください。

34.3.1.2 動的割当てパターンの構成方法

動的割当てパターンは、Oracle Enterprise Manager Fusion Middleware Controlで他のヒューマン・ワークフロー構成パラメータとともに構成します。

動的割当てには、それぞれ次の2つの必須パラメータがあります。

- name:
パターンの名前

- classpath:
パターンを実装するクラスの完全修飾クラス名

また、各パターンには、任意の数のプロパティをオプションで指定できます。これらのプロパティは単純な名前/値ペアで、初期化パラメータとしてパターンに渡されます。

これらのタグで指定したプロパティ値は、動的割当てパターンのsetInitParametersメソッドに(name属性の値で索引付けされた)マップとして渡されます。

組込みパターンのうち2つには、初期化パラメータが含まれています。それらは次のとおりです。

- ROUND_ROBIN
MAX_MAP_SIZEパラメータは、パターンがROUND_ROBINカウントを維持できる一連のユーザーまたはグループの最大数を指定します。動的割当てパターンでは、ROUND_ROBINパターンを実行するように要求される各グループ(またはユーザーとグループのリスト)について、ユーザーとグループのリストがメモリーに保持されます。

- MOST_PRODUCTIVE
DEAFULT_TIME_PERIODパラメータは、ユーザーの生産性を計算する期間(日数)を指定します。この値は、MOST_PRODUCTIVE動的割当てパターンをコールするときにオーバーライドできます。

Oracle Enterprise Manager Fusion Middleware ControlでDynamic Assignment Functionを構成する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

34.3.1.3 動的割当てパターンの表示名の構成方法

ランタイム構成サービスには、使用可能なユーザーとグループの動的割当てパターンのリストを返すメソッドが用意されています。これらのパターンは、パターンの名前、およびパターンとそのパラメータに対するユーザーが表示可能なラベルと説明の両方を返します。このパターンでは表示名のローカライズがサポートされるため、コンテキスト・ユーザーには適切な言語で表示されます。Oracle BPM WorklistおよびJDeveloperのヒューマン・タスク・エディタでは、これらのパターンを使用して、使用可能な動的割当てパターンのリストを表示します。

Dynamic Assignment Frameworkでは、パターン実装で、パターンとそのパラメータに対する判読可能な表示名と説明が表示されるようにするメソッドが提供されています。

組込みパターン実装、およびAbstractDynamicPatternクラスを拡張するカスタム実装では、WorkflowLabels.propertiesリソース・バンドル・ファイルを使用して、これらの表示文字列を構成します。

動的割当てパターンの表示名を構成する手順は、次のとおりです。

エントリをリソース・プロパティ・ファイルWorkflowLabels.propertiesに追加し、関連リソース・プロパティ・ファイルを他の言語で追加して、動的割当てパターンとそのパラメータの表示名と説明(および適切なトランスレーション)を指定します。このファイルは、次のパスにある、ワークフロー構成パラメータworkflowCustomizationsClasspathURL識別されるクラスパス内に配置されている必要があります。

oracle/bpel/services/workflow/resource/WorkflowLabels.properties

動的割当てパターンのエントリは、次の形式である必要があります。

DYN_ASSIGN_FN.[pattern name]=Pattern Display Name

DYN_ASSIGN_DESCR.[pattern name]=Function Description

DYN_ASSIGN_PARAM_LABEL.[pattern name].[parameter name]=Parameter Display Name

DYN_ASSIGN_PARAM_LABEL.[pattern name].[parameter name]=Parameter Description

たとえば、MOST_PRODUCTIVEパターンのエントリは、次のとおりです。

DYN_ASSIGN_FN.MOST_PRODUCTIVE = Most Productive

DYN_ASSIGN_DESCR.MOST_PRODUCTIVE = Picks the user, group or application role that
has completed the highest number of tasks within a certain time period. For group
and application roles the total number of tasks completed by all the users who
are direct members of that group or role are counted. The time period to use can
be specified using the Time Period parameter. If no time period is specified,
then the default value specified in the dynamic assignment configuration for the
instance is used.

DYN_ASSIGN_PARAM_LABEL.MOST_PRODUCTIVE.TIME_PERIOD = Time Period

DYN_ASSIGN_PARAM_DESCR.MOST_PRODUCTIVE.TIME_PERIOD = The previous number of days
over which to count the number of completed tasks. If not specified, the default
value defined in the human workflow dynamic assignment configuration is used.

これらのファイルに動的割当てパターンのエントリを追加するかどうかはオプションです。ファイルにエントリが存在しない場合は、かわりに関数名(ROUND_ROBINなど)が使用されます。

WorkflowLabels.propertiesファイルの詳細は、Oracle SOA Suiteサンプルで使用可能なworkflow-110-workflowCustomizationsのサンプルを参照してください。

34.3.1.4 タスク・エスカレーション・パターンの実装方法

タスク・エスカレーション関数は動的割当てパターンに非常に類似していますが、異なる関数を実行します(エスカレート時のタスクの割当て先を決定します)。カスタム実装は、異なるインタフェース(IDynamicTaskEscalationPattern)を実装している必要があります。

34.3.2 割当てサービスによるタスク参加者の動的割当て

ヒューマン・ワークフロー参加者は、ルーティング・スリップで宣言的に指定されます。ルーティング・スリップでは、参加者およびヒューマン・ワークフローへの参加方法(管理チェーン階層、承認者のシリアル・リストなど)を指定することでヒューマン・ワークフローの進行方法を決定します。

ヒューマン・タスク・エディタでは様々な組込みパターンを使用して、ルーティング・スリップを宣言的に作成できます。さらに、ビジネス・ルールに基づいた拡張ルーティングを使用して、より複雑にルーティングできます。ただし、カスタム・ロジックを使用してより高度なルーティングを作成するには、カスタム割当てサービスを実装してルーティングします。

このような動的割当てをサポートするために、割当てサービスが使用されます。割当てサービスは、タスク割当て先の決定を担当します。独自の割当てサービスを実装し、その実装をプラグイン接続して特定のヒューマン・ワークフローで使用することもできます。

割当てサービスにより、ヒューマン・ワークフローの次のタスク割当て詳細が決定されます。

- タスク開始時の割当て。

- タスク再開始時の割当て。

- ユーザーがタスクの結果を更新するときの割当て。タスクの結果が更新された場合、そのタスクは他のユーザーにルーティングするか完了にできます。

- タスク情報のリクエスト元の割当て先。

- タスクでOracle BPM Worklistからの再承認をサポートしている場合、ユーザーは再承認のための情報をリクエストできます。

- 再承認がサポートされている場合にタスクを再承認するユーザー。

ヒューマン・ワークフロー・サービスでは、特定のタスクについて割当てサービスが識別されて起動され、タスク割当てが決定されます。

たとえば、単純割当てサービスの繰返しは次のとおりです。

1. クライアントが、割当てサービスによりルーティングが決定される経費承認タスクを開始します。

2. 割当てサービスが、タスク割当て先をjcooperであると決定します。

3. jcooperがタスクを承認すると、割当てサービスがタスクをjsteinに割り当てます。また、割当てサービスはタスク作成者であるjlondonに必ず通知を送信するように指定します。

4. jsteinがタスクを承認し、割当てサービスは他にタスクの割当て先ユーザーがいないことを示します。

34.3.2.1 割当てサービスの実装方法

割当てサービスを実装する手順は、次のとおりです。

1. 割当てサービスは、IAssignmentServiceインタフェースを使用して実装します。ヒューマン・ワークフロー・サービスは、次の情報を割当てサービスに渡してタスク割当てを決定します。

- タスク・ドキュメント
ヒューマン・ワークフローで実行されるタスク・ドキュメント。タスク・ドキュメントには、ペイロードと他のタスク情報(現在の状態など)が含まれています。

- プロパティのマップ
割当てサービスを指定するときは、プロパティのリストを指定して、タスク割当て先を決定するバックエンド・サービスにコールバックを相関付けることもできます。

- タスク履歴
タスク履歴は、タスクの履歴をトレースするための時系列順のタスク・ドキュメントのリストです。このリスト内のタスク・ドキュメントには、実際のタスクの属性のサブセット(state、updatedBy、outcome、updatedDateなど)が含まれています。

34.3.2.2 割当てサービスの実装例

注意:

- ステートフルな割当てサービス・クラスは使用できません。これは、ヒューマン・ワークフロー・サービスでは、割当てサービスのコールが必要になるたびに新規インスタンスが作成されるためです。

- getAssigneesToRequestForInformationメソッドは複数回コールできます。これは、情報のリクエスト・アクションを表示するための基準の1つが、情報をリクエストしているユーザーが複数存在していることであるためです。したがって、ヒューマン・ワークフロー・サービスがタスクについて許可されているアクションを判別しようとするたびに、このメソッドがコールされます。

独自の割当てサービス・プラグインを実装できます。このプラグインは、ヒューマン・ワークフロー実行時にヒューマン・ワークフロー・サービスによって起動されます。

次のコード・サンプルでは、TestAssignmentService.javaと呼ばれるIAssignmentService実装の例を示します。

/* $Header: TestAssignmentService.java 24-may-2006.18:26:16 Exp $ */
/* Copyright (c) 2004, 2006, Oracle. All rights reserved.  */
/*
DESCRIPTION
Interface IAssignmentService defines the callbacks an assignment
service implements. The implementation of the IAssignmentService
is called by the workflow service
PRIVATE CLASSES
<list of private classes defined - with one-line descriptions>
NOTES
<other useful comments, qualifications, etc.>
MODIFIED    (MM/DD/YY)

*/
/**
*  @version $Header: IAssignmentService.java 29-jun-2004.21:10:35 Exp
$
*
*
*/
package oracle.bpel.services.workflow.test.workflow;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import oracle.bpel.services.workflow.metadata.routingslip.model.*;
import oracle.bpel.services.workflow.metadata.routingslip.model.Participants;
import oracle.bpel.services.workflow.metadata.routingslip.model.ParticipantsType.*;
import oracle.bpel.services.workflow.task.IAssignmentService;
import oracle.bpel.services.workflow.task.ITaskAssignee;
import oracle.bpel.services.workflow.task.model.Task;
public class TestAssignmentService implements
oracle.bpel.services.workflow.task.IAssignmentService {
static int numberOfApprovals = 0;
static String[] users = new String[]{"jstein", "wfaulk", "cdickens"};
public Participants onInitiation(Task task,
Map propertyBag) {
return createParticipant();
}
public Participants onReinitiation(Task task,
Map propertyBag) {
return null;
}
public Participants onOutcomeUpdated(Task task,
Map propertyBag,
String updatedBy,
String outcome) {
return createParticipant();
}
public Participants onAssignmentSkipped(Task task,
Map propertyBag) {
return null;
}
public List getAssigneesToRequestForInformation(Task task,
Map propertyBag) {
List rfiUsers = new ArrayList();
rfiUsers.add("jcooper");
rfiUsers.add("jstein");
rfiUsers.add("wfaulk");
rfiUsers.add("cdickens");
return rfiUsers;
}
public List getReapprovalAssignees(Task task,
Map propertyBag,
ITaskAssignee infoRequestedAssignee) {
List reapprovalUsers = new ArrayList();
reapprovalUsers.add("jstein");
reapprovalUsers.add("wfaulk");
reapprovalUsers.add("cdickens");
return reapprovalUsers;
}
private Participants createParticipant() {
if (numberOfApprovals > 2) {
numberOfApprovals = 0;
return null;
}
String user = users[numberOfApprovals++];

ObjectFactory objFactory = new ObjectFactory();
Participants participants = objFactory.createParticipants();
Participant participant = objFactory.createParticipantsTypeParticipant();
participant.setName("Loan Agent");
ResourceType resource2 = objFactory.createResourceType(user);
resource2.setIsGroup(false);
resource2.setType("STATIC");
participant.getResource().add(resource2);

participants.getParticipantOrSequentialParticipantOrAdhoc().
add(participant);
return participants;
}

}

34.3.2.3 カスタム割当てサービスのデプロイ方法

カスタム割当てサービスをデプロイする手順は、次のとおりです。

1. 次のメソッドを1つ使用して、割当てサービスの実装クラスおよび関連クラスをOracle BPEL Process Managerのクラスパスで使用可能にします。

- クラスをSCA-INF/classesに直接ロードするか、SCA-INF/libにJARとしてロードします。

- ディレクトリ・ツリーまたはJARファイルにカスタム関数のクラス・ファイルを配置します。次に、クラスが置かれているJARまたはルート・ディレクトリを指すようにworklfowCustomClasspathURL構成パラメータを更新します。これはURLであるため、Webサーバー上でクラス・ファイルをホスティングし、そのクラス・ファイルからHTTPを介して複数のOracle WebLogic Serverにアクセスできるようになります。さらに、そのファイルをメタデータ・リポジトリ(MDS)にデプロイし、ORAMDS URLを使用して適切な場所を指すようにすることもできます。この方法の詳細は、サンプルのworkflow-110-workflowCustomizationsを参照してください。このサンプルをダウンロードするには、Oracle SOA Suiteサンプルを参照してください。

注意:

- 様々なBPELプロセスで使用するために割当てサービスの別バージョンを作成するには、パッケージ名またはクラス名を変更する必要があります。

- スーツケース内のJavaクラスとJARファイルはクラスパスで使用できないため、割当てサービスのデプロイメント・モデルとしては使用できません。

- 前述の手順はクラスタ内のノードごとに繰り返す必要があります。

34.3.3 カスタム・エスカレーション関数

カスタム・エスカレーション関数を使用すると、ヒューマン・ワークフロー内でカスタム・ルールを統合できます。

カスタム・エスカレーション関数を実装する手順は、次のとおりです。

1. カスタムのタスク・エスカレーション関数を作成し、この関数をタスク定義に使用するヒューマン・ワークフロー・サービスに登録します。

2. ヒューマン・タスク・エディタを使用して、ヒューマン・ワークフローでルールを統合します。

詳細は、「エスカレーション・ルールの指定方法」を参照してください。

34.4 コールバックとリソース・バンドルに対するクラスのロード

次のコールバックおよびリソース・バンドルのクラスは、SOAプロジェクトから直接ロードできます。oracle.soainfra.common共有ライブラリのクラスをロードしてOracle WebLogic Serverを再起動する必要はありません。

- IAssignmentService

- IRestrictedAssignmentService

- IRoutingSlipCallback

- IPercentageCompletionCallback

- INotificationCallback

- プロジェクト・レベルのリソース・バンドル

コールバック・クラスは、次の場所に配置できます。

- プロジェクトのSCA-INF/libディレクトリにあるJAR

- プロジェクトのSCA-INF/classesディレクトリにあるクラス

さらに、下位互換性をサポートするために、プロジェクト・レベルのリソース・バンドルは、.taskファイルと同じディレクトリ内に配置することもできます。

34.5 ワークフロー・サービスのリソース・バンドル

この項では、ヒューマン・ワークフロー・サービスで使用するリソース・バンドルと、リソース・バンドルをカスタマイズして代替のリソース文字列を提供する方法について説明します。

ヒューマン・ワークフロー・サービスAPIおよびOracle BPM Worklistでは、IWorkflowContextオブジェクトのロケール設定を使用してAPIにアクセスします。これは、アイデンティティ・サービスで構成されているユーザー・ディレクトリ内のユーザーのロケールです。ユーザーに対してロケールが指定されていない場合は、かわりにJava EEサーバーのデフォルト・ロケールが使用されます。

APIクライアントでは、IWorkflowContextオブジェクトに新しい値を設定することで、このロケールをオーバーライドできます。Oracle BPM Worklistには、ユーザー・プリファレンス・オプションが用意されており、このオプションによって、ユーザーは、各自のユーザー・ディレクトリに設定されているロケールのかわりに、ブラウザのロケールを使用できます。

34.5.1 タスク・リソース・バンドル

各ヒューマン・ワークフロー・コンポーネントは、リソース・バンドルに関連付けることができます。このバンドルによって、タスクの結果の表示名として使用するリソース文字列が定義されます。リソース文字列は、TaskMetadataServiceメソッドのgetTaskDefinitionOutcomesによって返され、Oracle BPM Worklistおよびタスク・フローのタスク詳細アプリケーションに表示されます。

また、ヒューマン・ワークフローのXPath関数のgetTaskResourceBundle文字列を使用すると、タスクのリソース・バンドルのリソース文字列をルックアップできます。たとえば、このXPath関数は、タスクの通知メッセージの作成に使用するXPath式の一部として使用できます。

ヒューマン・ワークフロー・コンポーネントをリソース・バンドルに関連付けます。これを実行するには、ヒューマン・タスク・エディタの「プレゼンテーション」セクションにある「リソースの詳細」ダイアログの「リソース名」フィールドと「リソースの場所」フィールドを設定します。「リソースの場所」フィールドの値はURLです。リソース・バンドルは、このURLが指し示すJARファイル内に含めることができます。リソース・バンドルに対して共有場所を使用すると、複数のヒューマン・ワークフロー・コンポーネント間で同じリソース・バンドルを共有できます。

ヒューマン・ワークフロー・コンポーネントに対してリソース・バンドルが指定されていない場合は、グローバル・リソース・バンドル内でソース文字列がルックアップされます(「グローバル・リソース・バンドル - WorkflowLabels.properties」を参照。)よく使用されるタスクの結果をグローバル・リソース・バンドルで定義すると、個別のヒューマン・ワークフロー・コンポーネントに対してリソース・バンドルを定義する必要性が減少します。

特定の結果に対してリソース文字列を配置できない場合は、その結果の名前がすべてのロケールで表示値として使用されます。

34.5.2 グローバル・リソース・バンドル - WorkflowLabels.properties

次のグローバル・リソース・バンドルは、ヒューマン・ワークフロー・サービスAPIによるリソース文字列のルックアップに使用されます。

oracle.bpel.services.workflow.resource.WorkflowLabels.properties

このバンドルをカスタマイズすると、既存の表示文字列の代替を提供したり、他の文字列(マップ済属性のラベル、標準ビュー、カスタムのDynamic Assignment Function用など)を追加できます。

グローバル・リソース・バンドルでは、次の内容に対するリソース文字列が提供されます。

- タスク属性
Oracle BPM Worklist(または他のクライアント)に表示される様々なタスク属性のラベル。リソース文字列値は、次のTaskMetadataServiceメソッドから返されます。

- getTaskAttributes

- getTaskAttributesForTaskDefinition

- getTaskAttributesForTaskDefinitions

- マップ済属性のラベル
ランタイム構成サービスを介して作成されたマップ済属性のラベル。これらの文字列は、Oracle BPM Worklistで、マップ済属性を表示する際に使用されます。リソース文字列値は、次のTaskMetadataServiceメソッドから返されます。

- getTaskAttributesForTaskDefinition

- getTaskAttributesForTaskDefinitions

マップ済属性マッピングに翻訳されたリソース文字列が必要な場合は、WorkflowLabels.propertiesバンドルをカスタマイズして適切な文字列を挿入します。

- タスクの結果
共有のタスクの結果に対するデフォルトのリソース文字列。前述のように、タスクの結果はタスク・リソース・バンドルでオーバーライドできます。タスク固有のリソース・バンドルが指定されていない場合、リソース文字列は、TaskMetadataServiceメソッドのgetTaskDefinitionOutcomesから返されます。出荷時のグローバル・リソース・バンドルには、次の結果に対するリソース文字列が含まれています。

- 承認

- 却下

- はい

- いいえ

- OK

- 遅延

- 承認

- 確認

- Dynamic Assignment Function名
Dynamic Assignment Functionのラベル。これらの文字列は、ランタイム構成サービス・メソッドのgetUserDynamicAssignmentFunctionsおよびgetGroupDynamicAssignmentFunctionsから返されます。同梱されているリソース・バンドルには、標準のDynamic Assignment Function (ROUND_ROBIN、LEAST_BUSYおよびMOST_PRODUCTIVE)のラベルが含まれています。追加のカスタムDynamic Assignment Functionが作成されている場合は、WorkflowLabels.propertiesリソース・バンドルを変更して、新しい関数用のリソース文字を指定します。

- 標準ビュー名
標準ビューのラベル。作成した標準ビューに対して翻訳したリソース文字列が必要な場合は、それらの文字列をここで追加します。標準ビューのリソース文字列値は、リソース・バンドルからルックアップされ、UserMetadataServiceメソッドのgetStandardTaskViewListおよびgetStandardTaskViewDetailsから、標準ビュー名として返されます。リソース文字列のキーは、標準ビューの作成時に指定した名前である必要があります。特定の標準ビューに対してリソース文字列を追加しない場合は、かわりに入力した名前が使用されます。

- 通知メッセージ
タスク・サービスによる自動通知の送信時に使用されるリソース文字列。通知メッセージは、ユーザーの要件にあわせてカスタマイズできます。

- タスク・ルーティング・エラー・コメント
タスクのルーティングでエラーが発生すると、タスク・サービスは、エラーを記述したコメントをタスクに自動的に追加します。このコメントで使用される様々な文字列は、このリソース・バンドルで定義されます。

WorkflowLabels.propertiesリソース・バンドルのコピーは、サンプルのworkflow-110-workflowCustomizationsから入手できます。

WorkflowLabels.propertiesリソース・バンドルはカスタマイズできます。

ファイルをカスタマイズする手順は、次のとおりです。

1. プロパティ・ファイルを編集します。

2. カスタマイズ済のクラスをワークフロー・サービスで使用されるクラスパスに追加します。カスタマイズ済ファイルが、クラスパスでデフォルト・クラスより前にあることを確認します。

3. カスタマイズ済ファイルを次のディレクトリに保存します。

directory_path/oracle/bpel/services/workflow/resource/WorkflowLabels.properties

4. directory_pathを指し示すように、worklfowCustomClasspathURL構成パラメータを更新します。これはURLであるため、Webサーバー上でリソース・バンドルをホスティングしたり、SOAサーバーのMDSリポジトリへの格納が可能で、oramds URLプロトコルを使用して、そのリソース・バンドルに複数のOracle WebLogic Serverからアクセスできるようになります。この方法の詳細は、サンプルのworkflow-110-workflowCustomizationsを参照してください。このサンプルをダウンロードするには、Oracle SOA Suiteサンプルを参照してください。

34.5.3 ワークリスト・クライアントのリソース・バンドル

ADFワークリスト・クライアント・アプリケーションでは、次の2つのリソース・バンドルが使用されます。これらのハンドルには、ワークリスト・クライアントWebアプリケーションに表示されるすべての文字列が含まれています。

- oracle.bpel.worklistapp.resource.WorkflowResourceBundle:
このバンドルには、ADF Oracle BPM Worklistと、Oracle SOA Suiteのバージョン10.1.3に同梱されているJSPベースのサンプルのOracle BPM Worklistの両方で使用される文字列が含まれています。

- oracle.bpel.worklistapp.resource.WorklistResourceBundle:
このバンドルには、ADF Oracle BPM Worklistでのみ使用される文字列が含まれています。

ワークリストのリソース・バンドルのコピーは、サンプルのworkflow-110-workflowCustomizationsから入手できます。

このサンプルには、Oracle BPM Worklistのカスタマイズ方法が示されています。この方法によって、リソース・バンドルを再コンパイルし、更新したクラスをOracle BPM Worklistに追加します。

34.5.4 タスク詳細のADFタスク・フロー・リソース・バンドル

特定のタスク・タイプの詳細を表示するために作成されたADFタスク・フロー・アプリケーションと関連のデータ制御では、リソース・バンドルのoracle.bpel.services.workflow.worklist.resource.worklistを使用してリソース文字列が格納されます。

タスク・フロー・アプリケーションにカスタマイズしたリソース・バンドルを追加すると、タスク詳細のADFタスク・フローに独自のカスタム・リソース文字列を提供できます。

このリソース・バンドルを使用すると、タスク・フロー・フォームに表示されるXML要素名をローカライズできます。各キーを追加すると、タスク・フロー・フォームのコンテンツ・セクションでそれらのキーを使用できます。入力テキスト・ラベルは、次のようになります。

#{resources.mykeyword}

WorkflowLabels.propertiesリソース・バンドルのコピーは、サンプルのworkflow-110-workflowCustomizationsから入手できます。このサンプルには、タスク詳細のADFタスク・フロー・アプリケーションに、カスタマイズした独自のリソース文字列を提供する方法の詳細が示されています。

34.5.5 リソース・バンドルでのステージ名と参加者名の指定

コンポジット・リソース・バンドルで、ステージ名と参加者名の翻訳済の値を指定できます。リソース・バンドルには次のようなエントリが含まれている必要があります。

- stage_name=translated_value

- participant_name=translated_value

34.5.6 グループ名とアプリケーション・ロール名での大/小文字の区別

デフォルトでは、ヒューマン・ワークフロー・システムでユーザー名の大/小文字は区別されません。すべてのユーザー名は小文字で格納されます。ただし、グループ名とアプリケーション・ロール名は常に大/小文字が区別されます。ユーザー名は、大/小文字を区別するようにOracle Enterprise Manager Fusion Middleware Controlで変更できます。

注意:

この設定は、新規のインストールを実行した後にのみ変更してください。インスタンスをアクティブに処理しているインストール、または多数のインストールがデータベースにあるインストールでこの値を変更すると、重大な問題が発生します。

大/小文字を区別するように変更する手順は、次のとおりです。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. ナビゲータで、「SOA」フォルダを開きます。

3. 「soa-infra」を右クリックし、「管理」→「システムMBeanブラウザ」の順に選択します。

ページの右側に「システムMBeanブラウザ」が表示されます。

4. 「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: server_name」→「WorkflowIdentityConfig」→「human-workflow」→「WorkflowIdentityConfig.PropertyType」の順に開きます。

5. 「caseSensitive」をクリックします。

6. 「操作」タブをクリックします。

7. 「setValue」をクリックします。

8. 「値」フィールドにtrueと入力し、「起動」をクリックします。

10.1.3(デフォルトで、大/小文字を区別します)からアップグレードする場合、システムの動作を10.1.3と同じにするには、「caseSensitive」をtrueに設定します。

34.6 ヒューマン・ワークフロー・クライアントとOracle WebLogic Serverサービスとの統合の概要

この項では、ヒューマン・ワークフロー・クライアントとOracle WebLogic Serverサービスとの統合方法について説明します。

34.6.1 ヒューマン・ワークフロー・サービス・クライアント

ヒューマン・ワークフロー・サービスは、次のワークフロー・サービスを公開します。

- タスク・サービス

- タスク問合せサービス

- ユーザー・メタデータ・サービス

- タスク・エビデンス・サービス

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

- ランタイム構成サービス

- タスク・レポート・サービス

これらのサービスを使用するには、ワークフロー・サービスに対してAbstract Factoryパターンを使用する必要があります。Abstract Factoryパターンを使用すると、共通のテーマを持つ各ファクトリのグループをカプセル化できます。

次のタスクを実行します。

- 特定のサービス・タイプに対してIWorkflowServiceClientインスタンスを取得します。WorkflowServiceClientFactoryは、サービス・タイプに従ってIWorkflowServiceClientを取得する静的ファクトリ・メソッドを提供します。

- IWorkflowServiceClientインスタンスを使用して、使用するサービス・インスタンスを取得します。

サポートされているサービス・タイプは「リモート」と「soap」です。

リモート・クライアントは、Enterprise JavaBeansクライアント(したがってリモートEnterprise JavaBeans)を使用します。SOAPはSOAPクライアントを使用します。各タイプのサービスには、ワークフロー・クライアントを構成する必要があります。「ワークフロー・クライアント構成ファイル - wf_client_config.xml」の最初のコード・サンプルに詳細を示します。

クライアント構成ファイルには、複数の構成についての定義が含まれています。各サーバーには一意の名前が指定されている必要があります。構成ファイルに複数のサーバーを定義した場合は、1つのサーバーのデフォルト属性にtrueを設定する必要があります。workflowServicesClientConfigurationにはserverTypeというオプション属性があり、LOCAL、REMOTEまたはSOAPのいずれかに設定できます。各サーバーのクライアント・タイプをオーバーライドするには、オプション属性のclientTypeを使用します。

「ワークフロー・クライアント構成ファイル - wf_client_config.xml」の2番目のコード・サンプルに詳細を示します。

2番目のコード・サンプルでは、server2にREMOTEのデフォルトのclientTypeが使用されていますが、server1にはデフォルトのclientTypeの値をオーバーライドしてSOAPのclientTypeが使用されています。wf_client_config.xmlファイルのかわりに、JAXBオブジェクトのWorkflowServicesClientConfigurationTypeが使用されている場合も、同じルールが適用されます。

構成でクライアント・タイプを定義すると、WorkflowServiceClientFactoryクラスのファクトリ・メソッドを使用できます。次のコード・サンプルを参照してください。

public static IWorkflowServiceClient
getWorkflowServiceClient(WorkflowServicesClientConfigurationType wscc, Logger
logger) throws WorkflowException

マップでプロパティのCONNECTION_PROPERTY.CLIENT_TYPEを使用してクライアント・タイプを定義すると、次のコード・サンプルに示すファクトリ・メソッドを使用できます。

public static IWorkflowServiceClient getWorkflowServiceClient(Map<CONNECTION_
PROPERTY, String> properties, String serverName,    Logger logger) throws
WorkflowException

34.6.1.1 タスク問合せサービス・クライアントのコード

次のコード・サンプルに、タスク問合せサービス・クライアントのコード例を示します。

/**
* WFClientSample
*/
package oracle.bpel.services.workflow.samples;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import oracle.bpel.services.workflow.IWorkflowConstants;
import oracle.bpel.services.workflow.WorkflowException;
import oracle.bpel.services.workflow.client.IWorkflowServiceClient;
import oracle.bpel.services.workflow.client.WorkflowServiceClientFactory;
import oracle.bpel.services.workflow.client.IWorkflowServiceClientConstants
.CONNECTION_PROPERTY;
import oracle.bpel.services.workflow.query.ITaskQueryService;
import oracle.bpel.services.workflow.query.ITaskQueryService.AssignmentFilter;
import oracle.bpel.services.workflow.query.ITaskQueryService.OptionalInfo;
import oracle.bpel.services.workflow.repos.Ordering;
import oracle.bpel.services.workflow.repos.Predicate;
import oracle.bpel.services.workflow.repos.TableConstants;
import oracle.bpel.services.workflow.verification.IWorkflowContext;

public class WFClientSample {

public static List  runClient(String clientType) throws WorkflowException {
try {

IWorkflowServiceClient wfSvcClient = null;
ITaskQueryService taskQuerySvc = null;
IWorkflowContext wfCtx = null;

// 1. this step is optional since configuration can be set in  wf_client_
config.xml file
Map<CONNECTION_PROPERTY, String> properties = new HashMap<CONNECTION_
PROPERTY, String>();
if (WorkflowServiceClientFactory.REMOTE_CLIENT.equals(clientType)) {
properties.put(CONNECTION_PROPERTY.EJB_INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
properties.put(CONNECTION_PROPERTY.EJB_PROVIDER_URL,
"t3://myhost.us.example.com:7001");
properties.put(CONNECTION_PROPERTY.EJB_SECURITY_CREDENTIALS,
"weblogic");
properties.put(CONNECTION_PROPERTY.EJB_SECURITY_PRINCIPAL, "weblogic");
} else if (WorkflowServiceClientFactory.SOAP_CLIENT.equals(clientType)) {
properties.put(CONNECTION_PROPERTY.SOAP_END_POINT_ROOT,
"http://myhost:7001");
properties.put(CONNECTION_PROPERTY.SOAP_IDENTITY_
PROPAGATION,"non-saml"); // optional
}
// 2. gets IWorkflowServiceClient for specified client type
wfSvcClient =
WorkflowServiceClientFactory.getWorkflowServiceClient(clientType, properties,
null);

// 3. gets ITaskQueryService instance
taskQuerySvc = wfSvcClient.getTaskQueryService();

// 4. gets IWorkflowContext instance
wfCtx = taskQuerySvc.authenticate("jcooper", "welcome1".toCharArray(),
"jazn.com");

// 5. creates displayColumns
List<String> displayColumns = new ArrayList<String>(8);
displayColumns.add("TASKID");
displayColumns.add("TASKNUMBER");
displayColumns.add("TITLE");
displayColumns.add("CATEGORY");

// 6. creates optionalInfo
List<ITaskQueryService.OptionalInfo> optionalInfo = new
ArrayList<ITaskQueryService.OptionalInfo>();
optionalInfo.add(ITaskQueryService.OptionalInfo.DISPLAY_INFO);

// 7. creates assignmentFilter
AssignmentFilter assignmentFilter = AssignmentFilter.MY_AND_GROUP;

// 8. creates predicate
List<String> stateList = new ArrayList<String>();
stateList.add(IWorkflowConstants.TASK_STATE_ASSIGNED);
stateList.add(IWorkflowConstants.TASK_STATE_INFO_REQUESTED);
Predicate predicate = new Predicate(TableConstants.WFTASK_STATE_COLUMN,
Predicate.OP_IN, stateList);

// 9. creates ordering
Ordering ordering = new Ordering(TableConstants.WFTASK_DUEDATE_COLUMN,
true, false);
ordering.addClause(TableConstants.WFTASK_CREATEDDATE_COLUMN, true,
false);

// 10. calls service - query tasks
List taskList = taskQuerySvc.queryTasks(wfCtx,
(List<String>) displayColumns,
(List<OptionalInfo>) optionalInfo,
(AssignmentFilter)
assignmentFilter,
(String) null, // keywords is
optional (see javadoc)
// optional
predicate,
ordering,
0,    // starting row
100); // ending row for paging, 0
if no paging

// Enjoy result
System.out.println("Successfuly get list of tasks for client type: " +
clientType +
". The list size is " + taskList.size());
return taskList;
} catch (WorkflowException e) {
System.out.println("Error occurred");
e.printStackTrace();
throw e;
}
}

public static void main(String args[]) throws Exception {
runClient(WorkflowServiceClientFactory.REMOTE_CLIENT);
runClient(WorkflowServiceClientFactory.SOAP_CLIENT);
}

}

34.6.1.2 構成オプション

各タイプのクライアントには、ワークフロー・クライアント構成を設定する必要があります。次の場所に構成を設定できます。

- JAXBオブジェクト

- wf_client_config.xmlファイル

- プロパティ・マップ

プロパティ・マップは常に、wf_client_config.xmlファイルの補足です。構成属性は、JAXBオブジェクトまたはプロパティ・マップによって上書きされる場合があります。構成ファイルはオプションです。構成ファイルがアプリケーションのクラスパスに見つからない場合は、プロパティ・マップが構成の主要ソースになります。

34.6.1.2.1 JAXBオブジェクト

JAXBオブジェクトは、クライアント構成を定義するために使用できます。次のコード・サンプルに、WorkflowServiceClientFactoryメソッドの使用方法を示します。

public static IWorkflowServiceClient getWorkflowServiceClient(String clientType,WorkflowServicesClientConfigurationType wscc,Logger logger) throws WorkflowException

34.6.1.2.2 ワークフロー・クライアント構成ファイル - wf_client_config.xml

クライアント構成のXSDスキーマは、wf_client_config.xsdファイルにあります。

サーバー構成には、次の3タイプのクライアントが含まれている必要があります。

- localClient

- remoteClient

- soapClient

すべてのクライアントを指定することをお薦めします。これは、リモート・クライアントを持たないサービス(アイデンティティ・サービスなど)があるためです。このため、他のサービスでリモート・クライアントを使用する場合、アイデンティティ・サービスではSOAPサービスを使用します。

次のコード・サンプルに、クライアント構成のXMLファイルの例を示します。この構成によって、defaultという名前のサーバーが定義されます。このXMLファイルは、クライアント・アプリケーションのEARファイルに移動する必要があります。

<workflowServicesClientConfiguration>
server name="default" default="true">

<remoteClient>
<serverURL>t3://myhost.us.example.com:7001</serverURL>
<userName>weblogic</userName>
<password>weblogic</password>
<initialContextFactory>weblogic.jndi.WLInitialContextFactory
</initialContextFactory>
<participateInClientTransaction>false</participateInClientTransaction>
</remoteClient>

<soapClient>
<rootEndPointURL>http://myhost.us.example.com:7001</rootEndPointURL>
<identityPropagation mode="dynamic" type="saml">
<policy-references>
<policy-reference enabled="true" category="security"
uri="oracle/wss10_saml_token_client_policy"/>
</policy-references>
</identityPropagation>
</soapClient>

</server>
</workflowServicesClientConfiguration>

次のコード・サンプルに、複数の構成が定義されたクライアント構成ファイルの例を示します。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowServicesClientConfiguration
xmlns="http://xmlns.oracle.com/bpel/services/client" clientType="REMOTE"
<server name="server1" default="true"  clientType="SOAP">
<remoteClient>
<serverURL>t3://myhost1.us.example.com:7001</serverURL>
<initialContextFactory>weblogic.jndi.WLInitialContextFactory</initialContextFactory>
<participateInClientTransaction>false</participateInClientTransaction>
</remoteClient> -->
<soapClient>
<rootEndPointURL>http://myhost1.us.example.com:7001</rootEndPointURL>
<identityPropagation mode="dynamic" type="saml">
<policy-references>
<policy-reference enabled="true" category="security"
uri="oracle/wss10_saml_token_client_policy"/>
</policy-references>
</identityPropagation>
</soapClient>
</server>
<server name="server2">
<remoteClient>
<serverURL>t3://myhost2.us.example.com:7001</serverURL>
<initialContextFactory>weblogic.jndi.WLInitialContextFactory</initialContextFactory>
<participateInClientTransaction>false</participateInClientTransaction>
</remoteClient> -->
<soapClient>
<rootEndPointURL>http://myhost2us.example.com:7001</rootEndPointURL>
<identityPropagation mode="dynamic" type="saml">
<policy-references>
<policy-reference enabled="true" category="security"
uri="oracle/wss10_saml_token_client_policy"/>
</policy-references>
</identityPropagation>
</soapClient>
</server>
</workflowServicesClientConfiguration>

WorkflowServicesClientConfigurationType wsccがnullの場合は、wf_client_config.xmlにクライアント・プロパティを定義できます。

WorkflowServiceClientFactory getWorkflowServiceClient()メソッドは常に、クラスパス内でwf_client_config.xmlを検索します。このファイルが検出されると、クライアント・プロパティがロードされます。

wf_client_config.xmlファイルに定義した値は、プロパティ・マップまたはJAXBオブジェクトで定義したすべてのプロパティによってオーバーライドされます。

34.6.1.2.3 プロパティ・マップでのワークフロー・クライアント構成

接続プロパティを動的に指定する場合は、java.util.Mapを使用してプロパティを指定できます。これらのプロパティは、構成ファイル内の定義よりも優先されます。したがって、wf_client_config.xmlに定義した値は、これらのプロパティの値によって上書きされます。サーバーへの接続詳細を動的に指定しない場合は、マップでのプロパティ設定を省略し、ファクトリ・メソッドにNULL値を渡すことができます。この場合、構成ファイルwf_client_config.xmlはクライアント・アプリケーションのクラスパス内で検索されます。

構成ファイルがクラスパス内にある必要があるのは、構成ファイルから構成を取得する場合のみです。特定のクライアント・タイプの全設定をプロパティ・マップを使用して行う場合、このファイルの設定はオプションです。また、JAXBオブジェクトにも構成ファイルは必要ありません。これは、すべての設定がJAXBオブジェクトから取得されるためです。次のコード・サンプルに詳細を示します。

IWorkflowServiceClient   wfSvcClient =
WorkflowServiceClientFactory.getWorkflowServiceClient(WorkflowServiceClientFactory
.REMOTE_CLIENT,
(Map<IWorkflowServiceClientConstants.CONNECTION_PROPERTY, String> ) null, null);

この場合、クライアントは、クラスパス内で検出されたwf_client_config.xmlの値を使用してサービスにアクセスします。構成ファイルがクラスパス内に見つからない場合に、サービス・タイプに応じた設定を指定しないと、ワークフロー例外がスローされます。プロパティ・マップがNULLで、構成ファイルが見つからない場合も、例外がスローされます。構成ファイルが見つからない場合に、クライアントでマップ内の一部のプロパティが省略されていると、実行時にサービス・コールが失敗します(プロパティは構成ファイルの補足です)。

クライアント・プロパティは、WorkflowServiceClientFactoryメソッドを使用して定義できます。次のコード・サンプルに詳細を示します。

public static IWorkflowServiceClient getWorkflowServiceClient(String clientType,Map<CONNECTION_PROPERTY, String> properties,
Logger logger) hrows WorkflowException

マップでプロパティのCONNECTION_PROPERTYタイプを使用してクライアント・タイプを定義すると、次のコード・サンプル示すファクトリ・メソッドを使用できます。

public static IWorkflowServiceClient getWorkflowServiceClient(Map<CONNECTION_
PROPERTY, String> properties,   Logger logger) throws WorkflowException

次に、クライアント・プロパティを設定するためにプロパティ・マップで使用できるIWorkflowServiceClientConstants.CONNECTION_PROPERTYを示します。

public enum CONNECTION_PROPERTY {
MODE,  // not supported , deprecated
EJB_INITIAL_CONTEXT_FACTORY,
EJB_PROVIDER_URL,
EJB_SECURITY_PRINCIPAL,
EJB_SECURITY_CREDENTIALS,
// SOAP configuration
SOAP_END_POINT_ROOT,
SOAP_IDENTITY_PROPAGATION, // if value is 'saml' then SAML-token
identity propagation is used
SOAP_IDENTITY_PROPAGATION_MODE,  // "dynamic'
MANAGEMENT_POLICY_URI, // dafault value is "oracle/log_policy"
SECURITY_POLICY_URI,   // default value is  "oracle/wss10_
saml_token_client_policy"
// REMOTE EJB
TASK_SERVICE_PARTICIPATE_IN_CLIENT_TRANSACTION  // default value is
false
//(task service EJB starts a new transaction)
CLIENT_TYPE,            DISCOVERY_OF_END_POINT,
WSS_RECIPIENT_KEY_ALIAS,
EJB_JNDI_SUFFIX // append to jndi name to used  foreign jndi name
};

注意:

プロパティ・マップを使用する場合、IWorkflowServiceClientConstants.CONNECTION_PROPERTY.MODEを指定する必要はありません。このプロパティは、11g リリース1では非推奨です。

次のコード・サンプルに、リモートEnterprise JavaBeansクライアントの例を示します。

Map<CONNECTION_PROPERTY,String> properties = new HashMap<CONNECTION_
PROPERTY,String>();
properties.put(CONNECTION_PROPERTY.EJB_INITIAL_CONTEXT_
FACTORY,"weblogic.jndi.WLInitialContextFactory");

properties.put(CONNECTION_PROPERTY.EJB_PROVIDER_URL,
"t3://myhost.us.example.com:7001");
properties.put(CONNECTION_PROPERTY.EJB_SECURITY_PRINCIPAL, "weblogic");
properties.put(CONNECTION_PROPERTY.EJB_SECURITY_CREDENTIALS, "weblogic");
IWorkflowServiceClient client =
WorkflowServiceClientFactory.getWorkflowServiceClient(
WorkflowServiceClientFactory.REMOTE_CLIENT,
properties, null);

次のコード・サンプルに、SOAPクライアントの例を示します。

Map<CONNECTION_PROPERTY,String> properties = new HashMap<CONNECTION_
PROPERTY,String>();
properties.put(CONNECTION_PROPERTY.SOAP_END_POINT_ROOT, "http://myhost:7001");
IWorkflowServiceClient client =
WorkflowServiceClientFactory.getWorkflowServiceClient(
WorkflowServiceClientFactory.SOAP_CLIENT,
properties, null);

34.6.1.3 クライアントのロギング

クライアントでは、クライアントがメッセージを記録するjava.util.logging.Loggerを必要に応じて渡すことができます。ロガーが指定されていない場合、ワークフロー・サービス・クライアントのコードは何も記録しません。次のコード・サンプルは、ロガーをワークフロー・サービス・クライアントに渡す方法を示しています。

java.util.logging.Logger logger = ....;

IWorkflowServiceClient client =
WorkflowServiceClientFactory.getWorkflowServiceClient(WorkflowServiceClientFactory
.REMOTE_CLIENT, properties, logger);

34.6.1.4 構成移行ユーティリティ

クライアント構成スキーマは、リリース10.1.3.x と11g リリース1の間で変更されています。リリース10.1.3.xから11g リリース1に移行するには、次のコード・サンプルに示すユーティリティを使用します。

java -classpath wsclient_extended.jar:bpm-services.jar
oracle.bpel.services.workflow.client.config.MigrateClientConfiguration
original_file [new_file];

original_fileは10.1.3.x のwf_client_config.xmlファイルで、new_fileは新規の構成ファイル名(オプション)です。新規の構成ファイル名を指定しないと、元の構成ファイルがバックアップされ、wf_client_config.xmlファイルが上書きされます。

34.6.2 アイデンティティ伝播

この項では、Enterprise JavaBeansおよびSAMLトークン(SOAPクライアント用)を使用してアイデンティティを伝播する方法について説明します。

リクエストごとにワークフロー・コンテキストを取得すると、パフォーマンスが低下する場合があります。これは、アイデンティティ伝播の場合も同様です。SAMLトークンまたはEnterprise JavaBeansによるアイデンティティ伝播を使用する場合は、ユーザー名とパスワードにNULLを渡してクライアントを認証し、ワークフロー・コンテキスト・インスタンスを取得して、アイデンティティ伝播を使用せずにワークフロー・コンテキストを使用する別のサービス・コールを使用します。

34.6.2.1 Enterprise JavaBeansアイデンティティ伝播

クライアント・アプリケーションは、Enterprise JavaBeansアイデンティティ伝播を使用して、ユーザー・アイデンティティをサービスに伝播できます。クライアントのコードでは、ユーザー・アイデンティティを保護する必要があります。

34.6.2.1.1 クライアント構成

アイデンティティ伝播を使用する場合、クライアントのコードでは、wf_client_config.xml構成ファイルの<remoteClient>要素の下にある<userName>要素と<password>要素を省略する必要があります。さらに、「プロパティ・マップでのワークフロー・クライアント構成」で移入したMap<IWorkflowServiceClientConstants.CONNECTION_PROPERTY,String>プロパティには、次のプロパティを移入しないでください。

- IWorkflowServiceClientConstants.CONNECTION_PROPERTY.EJB_SECURITY_PRINCIPAL

- IWorkflowServiceClientConstants.CONNECTION_PROPERTY.EJB_SECURITY_CREDENTIALS

34.6.2.1.2 アイデンティティ伝播のためのクライアント・アプリケーションの要件

アイデンティティ伝播が機能するのは、アプリケーションがOracle WebLogic Serverコンテナにデプロイされ、コンテナ・セキュリティによって保護されている場合、またはクライアントがカスタムJAASログイン・モジュールによって保護されている場合のみです。

エンド・ユーザーは、正しいユーザー名とパスワードを使用してクライアント・アプリケーションにログインします。クライアント・アプリケーションを使用するユーザーは、SOAアプリケーションで使用されるアイデンティティ・ストアで使用可能である必要があります。このため、クライアントの構成には、ワークフロー・サービスやOracle SOA Suiteで使用するアイデンティティ・ストアと同じアイデンティティ・ストアを使用することをお薦めします。これにより、ユーザーがクライアント側に存在している場合、そのユーザーはサーバー側にも存在していることが保証されます。

アイデンティティ・ストアの構成方法の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

カスタム・アイデンティティ・ストアとの相互作用の詳細は、次のURLを参照してください。

http://www.oracle.com/technetwork/middleware/id-mgmt/overview/index.html

34.6.2.2 SOAPクライアント用のSAMLトークン・アイデンティティ伝播

SOAPクライアントを使用する場合は、Oracle WebサービスでサポートされているSAMLトークン・アイデンティティ伝播を使用できます。

この項では、アプリケーションがOracle WebLogic Serverコンテナ内に存在し、このコンテナによって保護されていることを前提にしています。

34.6.2.2.1 クライアント構成

アイデンティティ伝播を有効にするには、クライアント構成で特別な伝播モードを指定する必要があります。

34.6.2.2.1.1 プロパティを使用したアイデンティティ伝播モード設定

プロパティを使用する場合は、CONNECTION_PROPERTY.SOAP_IDENTITY_PROPAGATIONプロパティに値samlを移入します。

- 動的SAMLトークン伝播モード
SAMLトークン・ポリシーは動的に提供されます(デフォルト)。次のコード・サンプルに示すプロパティはオプションです。アイデンティティ伝播モードが設定されている場合、デフォルトでは動的モードで実行します。

properties.put(IWorkflowServiceClientConstants.CONNECTION_PROPERTY.SOAP_
IDENTITY_PROPAGATION_MODE , "dynamic");

SAMLトークンでは、デフォルトで、セキュリティ・ポリシーURIのoracle/wss10_saml_token_client_policyに基づいて動的ポリシーが構成されます。ロギングは使用されません。デフォルトのポリシーURIを上書きするには、クライアントで次に示すコードを追加します。

properties.put(CONNECTION_PROPERTY.SECURITY_POLICY_URI     "oracle/wss10_saml_
token_client_policy");
properties.put(CONNECTION_PROPERTY.MANAGEMENT_POLICY_URI , "oracle/log_policy");

次のコード・サンプルに、SAMLトークン動的クライアントを示します。

Map<CONNECTION_PROPERTY,String> properties = new HashMap<ONNECTION_
PROPERTY,String>();
properties.put(CONNECTION_PROPERTY.SOAP_IDENTITY_PROPAGATION , "saml");
properties.put(CONNECTION_PROPERTY.SOAP_END_POINT_ROOT,
"http://myhost.us.example.com:7001");
properties.put(ONNECTION_PROPERTY.SECURITY_POLICY_URI, "oracle/wss10_saml_token_
client_policy"); //optional
properties.put(CONNECTION_PROPERTY.MANAGEMENT_POLICY_URI , "oracle/log_policy");
//optional
IWorkflowServiceClient client =
WorkflowServiceClientFactory.getWorkflowServiceClient(
WorkflowServiceClientFactory.SOAP_CLIENT,
properties, null);

ポリシーURIへのクライアント参照は、サーバー・ポリシーURIと一致する必要があります。そうでない場合、SAMLトークン伝播は失敗します。

34.6.2.2.1.2 構成ファイルでのアイデンティティ伝播モード設定

構成ファイルでは、次に示すように、<soapClient>の<identityPropagation>要素を使用して伝播モードを定義できます。

<soapClient>
<rootEndPointURL>http://myhost.us.example.com:7001</rootEndPointURL>
<identityPropagation mode="dynamic" type="saml">
<policy-references>
<policy-reference enabled="true" category="security"
uri="oracle/wss10_saml_token_client_policy"/>
</policy-references>
</identityPropagation> </soapClient>

詳細は、『Webサービスの管理』を参照してください。

34.6.2.2.1.3 JAXBオブジェクトを使用したアイデンティティ伝播モード設定

アイデンティティ伝播モードは、JAXBオブジェクトを使用し、プログラムによって設定できます。

34.6.2.3 公開鍵の別名

ワークフロー・クライアントとともにoracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_RECIPIENT_KEY_ALIASプロパティを使用できます。このプロパティは、アウトバウンド・メッセージ・タイプの暗号化に使用する受信者の公開鍵に別名を設定します。このプロパティを使用して、公開鍵の別名でワークフロー・サービスを保護します。このプロパティが関連するのは、SOAPクライアント・タイプでアイデンティティ伝播が使用される場合のみです。

公開鍵の別名を定義する場合は、クライアント・コードでWSS_RECIPIENT_KEY_ALIAS値をマップに追加する必要があります。次のコード・サンプルに詳細を示します。

Map<CONNECTION_PROPERTY,String> properties = new HashMap<ONNECTION_
PROPERTY,String>();
properties.put(CONNECTION_PROPERTY.SOAP_IDENTITY_PROPAGATION , "saml");
properties.put(CONNECTION_PROPERTY.SOAP_END_POINT_ROOT,
"http://myhost.us.example.com:7001");
properties.put(CONNECTION_PROPERTY.WSS_RECIPIENT_KEY_ALIAS,keyAlias);
// where keyAlias  is a key alias value
properties.put(ONNECTION_PROPERTY.SECURITY_POLICY_URI, "oracle/wss10_saml_token_
client_policy"); //optional
properties.put(CONNECTION_PROPERTY.MANAGEMENT_POLICY_URI , "oracle/log_policy");
//optional
IWorkflowServiceClient client =
WorkflowServiceClientFactory.getWorkflowServiceClient(
WorkflowServiceClientFactory.SOAP_CLIENT,
properties, null);

クライアントでJAXBオブジェクトのWorkflowServicesClientConfigurationTypeまたはwf_client_config.xmlファイルを使用する場合は、wssRecipientKeyAliasと呼ばれるオプション要素をSOAPクライアントのidentityPropagation要素の下に追加します。次のコード・サンプルに詳細を示します。

<xsd:complexType name="identityPropagationType">
<xsd:sequence>
<xsd:element name="policy-references"  type="PolicyReferencesType"
minOccurs="0" maxOccurs="1"/>
<xsd:element name="wssRecipientKeyAlias"  type="xsd:string"  minOccurs="0"
maxOccurs="1"/> </xsd:sequence>
<xsd:attribute name="type" type="xsd:string"  default="saml"/>
<xsd:attribute name="mode" type="xsd:string"  default="dynamic"/>
</xsd:complexType>

資格証明ストアでの公開鍵の別名の作成方法および使用方法の詳細は、『Webサービスの管理』を参照してください。

34.6.3 クライアントJARファイル

アイデンティティ伝播を使用しないクライアント・アプリケーションには、そのクラスパスにbpm-services.jarファイルを指定する必要があります。12cリリース1 (12.1.3)の場合、クライアントのクラスパスには次に示すファイルが必要です。

$fmwhome/wlserver/server/lib/wlfullclient.jar
$fmwhome/wlserver/lib/weblogic.jar
$fmwhome/wlserver/server/lib/wlclient.jar
$fmwhome/oracle_common/modules/clients/com.oracle.webservices.fmw.client_
12.1.3.jar
$fmwhome/soa/soa/modules/com.oracle.webservices.fmw.client_12.1.3.jar
$fmwhome/oracle_common/modules/oracle.xdk_12.1.3/xml.jar
$fmwhome/oracle_common/modules/oracle.nlsrtl_11.2.0/orai18n-mapping.jar
$fmwhome/soa/soa/modules/oracle.soa.fabric_11.1.1/bpm-infra.jar
$fmwhome/soa/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar
$fmwhome/soa/soa/modules/soa-startup.jar

wlfullclient.jarファイルは生成する必要があります。

- wlfullclient.jarは、次のように生成します。

cd $fmwhome/wlserver/server/lib
java -jar ../../modules/com.bea.core.jarbuilder_2.2.0.0.jar

34.7 ヒューマン・タスクのタスクの状態

次のリストに、ヒューマン・タスクで利用可能なすべてのタスクの状態を示します。すべての状態の定数は、IWorkflowConstants.javaで定義されています。

- String TASK_STATE_ALERTED = "ALERTED";

- String TASK_STATE_ASSIGNED = "ASSIGNED";

- String TASK_STATE_COMPLETED = "COMPLETED";

- String TASK_STATE_DELETED = "DELETED";

- String TASK_STATE_ERRORED = "ERRORED";

- String TASK_STATE_EXPIRED = "EXPIRED";

- String TASK_STATE_INFO_REQUESTED = "INFO_REQUESTED";

- String TASK_STATE_OUTCOME_UPDATED = "OUTCOME_UPDATED";

- String TASK_STATE_STALE = "STALE";

- String TASK_STATE_SUSPENDED = "SUSPENDED";

- String TASK_STATE_WITHDRAWN = "WITHDRAWN";

IWorkflowConstants.javaの詳細は、『Oracle SOA Suiteワークフロー・サービスJava APIリファレンス』を参照してください。

34.8 Oracle Workflowのデータベース・ビュー

この項では、データベース・ビューについて説明します。データベース・ビューを使用すると、レポート受信の問合せをOracle Workflowサービス・スキーマに対して実行できます。表34-22 に、Oracle BPM Worklistで公開されるレポート、およびこれらのレポートに対応するデータベース・ビューを示します。

表34-22 レポートのビュー

既存のワークリスト・レポート

対応するデータベース・ビュー

不参加タスク・レポート

WFUNATTENDEDTASKS_VIEW

タスクのサイクル・タイム・レポート

WFTASKCYCLETIME_VIEW

タスクの生産性レポート

WFPRODUCTIVITY_VIEW

タスクの優先度レポート

WFTASKPRIORITY_VIEW

34.8.1 「不参加タスク・レポート」ビュー

表34-23 に、WFUNATTENDEDTASKS_VIEWレポート・ビューを示します。

表34-23 「不参加タスク・レポート」ビュー

名前

タイプ

TASKID[1]

VARCHAR2(64)

TASKNAME

VARCHAR2(200)

TASKNUMBER

NUMBER

CREATEDDATE

DATE

EXPIRATIONDATE

DATE

STATE

VARCHAR2(100)

PRIORITY

NUMBER

ASSIGNEEGROUPS

VARCHAR2(2000)

次に例を示します。

- 次に、有効期限が翌週の不参加タスクの問合せを示します。

SELECT tasknumber, taskname, assigneegroups FROM WFUNATTENDEDTASKS_VIEW
WHERE expirationdate > current_date AND expirationdate < current_date +
7;

- 次に、mygroupの不参加タスクの問合せを示します。

SELECT tasknumber, taskname, assigneegroups FROM WFUNATTENDEDTASKS_VIEW
WHERE 'mygroup' IN assigneegroups;

- 次に、過去30日以内に作成された不参加タスクの問合せを示します。

SELECT tasknumber, taskname, assigneegroups FROM WFUNATTENDEDTASKS_VIEW
WHERE createddate > current_date -30;

34.8.2 「タスクのサイクル・タイム・レポート」ビュー

表34-24 に、WFTASKCYCLETIME_VIEWレポート・ビューを示します。

表34-24 「タスクのサイクル・タイム・レポート」ビュー

名前

タイプ

TASKID[2]

VARCHAR2(64)

TASKNAME

VARCHAR2(200)

TASKNUMBER

NUMBER

CREATEDDATE

DATE

ENDDATE

DATE

CYCLETIME

NUMBER(38)

次に例を示します。

- 次に、過去30日以内に作成された完了済タスクの平均サイクル・タイム(タスク完了時間)の計算を示します。

SELECT avg(cycletime) FROM  WFTASKCYCLETIME_VIEW  WHERE createddate >
(current_date - 30);

- 次に、過去30日以内に作成されたすべての完了済タスクの平均サイクル・タイムの問合せおよびタスク名によるグループ化を示します。

SELECT taskname, avg(cycletime) FROM WFTASKCYCLETIME_VIEW WHERE
createddate > (current_date - 30) GROUP BY taskname;

- 次に、各タスクで要した最短および最長時間の問合せを示します。

SELECT taskname, min(cycletime), max(cycletime) FROM WFTASKCYCLETIME_VIEW
GROUP BY taskname;

- 次に、過去7日以内に完了したタスクの平均サイクル・タイムの計算を示します。

SELECT avg(cycletime) FROM  WFTASKCYCLETIME_VIEW  WHERE enddate >
(current_date - 7);

- 次に、完了に8日以上要したタスクの問合せを示します。

SELECT taskname, avg(cycletime) FROM WFTASKCYCLETIME_VIEW WHERE cycletime
> ((current_date +7) - current_date) GROUP BY taskname;

34.8.3 「タスクの生産性レポート」ビュー

表34-25 に、WFPRODUCTIVITY_VIEWレポート・ビューを示します。

表34-25 「タスクの生産性レポート」ビュー

名前

タイプ

TASKNAME

VARCHAR2(200)

TASKID

VARCHAR2(200)

TASKNUMBER

NUMBER

USERNAME

VARCHAR2(200)

STATE[3]

VARCHAR2(100)

LASTUPDATEDDATE

DATE

次に例を示します。

- 次に、過去30日以内にユーザーが更新した一意のタスク数のカウントを示します。

SELECT username, count(distinct(taskid))  FROM WFPRODUCTIVITY_VIEW WHERE
lastupdateddate > (current_date -30) GROUP BY username;

- 次に、過去7日以内にユーザーが更新したタスク数(タスクによっては複数回更新された可能性があります)のカウントを示します。

SELECT username, count(taskid)  FROM WFPRODUCTIVITY_VIEW  WHERE
lastupdateddate > (current_date -7) GROUP BY username;

- 次に、ユーザーが作業した各タスク・タイプのタスク数のカウントを示します。

SELECT username, taskname, count(taskid) FROM WFPRODUCTIVITY_VIEW GROUP
BY username, taskname;

- 次に、過去100日以内にユーザーが作業した各タスク・タイプのタスク数のカウントを示します。

SELECT username, taskname, count(taskid) FROM WFPRODUCTIVITY_VIEW WHERE
lastupdateddate > (current_date -100) GROUP BY username, taskname;

34.8.4 「タスクの優先度レポート」ビュー

表34-26 に、WFTASKPRIORITY_VIEWレポート・ビューを示します。

表34-26 「タスクの優先度レポート」ビュー

名前

タイプ

TASKID[4]

VARCHAR2(64)

TASKNAME

VARCHAR2(200)

TASKNUMBER

NUMBER

PRIORITY

NUMBER

OUTCOME

VARCHAR2(100)

ASSIGNEDDATE

DATE

UPDATEDDATE

DATE

UPDATEDBY

VARCHAR2(64)

次に例を示します。

- 次に、各タスク優先度で各ユーザーが更新したタスク数の問合せを示します。

SELECT updatedby, priority, count(taskid) FROM  WFTASKPRIORITY_VIEW GROUP
BY  updatedby, priority;

- 次に、タスクから結果までの分布の問合せを示します。

SELECT taskname, decode(outcome, '', 'COMPLETED', outcome),  count
(taskid) FROM WFTASKPRIORITY_VIEW GROUP BY taskname, outcome;

- 次に、各優先度で特定のユーザーが更新したタスク数の問合せを示します。

SELECT priority, count(taskid) FROM WFTASKPRIORITY_VIEW WHERE
updatedby='jstein' GROUP BY priority;

[1]
NOT NULL列

[2]
NOT NULL列

[3]
完了済タスクの場合、状態はnullです。問合せでは、decode(outcome, '', 'COMPLETED', outcome)を使用します。

[4]
NOT NULL列

第VI部 バインディング・コンポーネントの使用

このセクションでは、バインディング・コンポーネントの使用方法について説明します。

この部は、次の章で構成されています。

- バインディング・コンポーネントのスタート・ガイド

- REST操作とSOAコンポジット・アプリケーションとの統合

- Enterprise JavaBeansとコンポジット・アプリケーションの統合

- コンポジット・サービスの起動に直接バインディングを使用

35 バインディング・コンポーネントのスタート・ガイド

この章では、SOAコンポジット・アプリケーションに統合できる、サポートされているサービスおよび参照バインディング・コンポーネントのタイプとテクノロジについて説明します。サポートされているバインディング・コンポーネントには、Webサービス、HTTPバインディング、JCAアダプタ、クラウド・アダプタ、Oracle Business Activity Monitoring (BAM)、Oracle B2B、Oracle Healthcare、ADF-BCサービス、Enterprise JavaBeans (EJB)サービス、Managed File Transfer (MFT)、Representational State Transfer (REST)サービスおよび直接バインディング・サービスが含まれます。外部参照のバインディングURLで使用するトークンの作成についても説明します。

この章の内容は次のとおりです。

- バインディング・コンポーネントの概要

- バインディング・コンポーネントとSOAコンポジット・アプリケーションの統合の概要

- 外部参照のバインディングURLで使用するためのトークンの作成

詳細は、「サービス・バインディング・コンポーネントの追加」および「参照バインディング・コンポーネントの追加」を参照してください。

35.1 バインディング・コンポーネントの概要

バインディング・コンポーネントは、SOAコンポジット・アプリケーションと外部との接続を確立します。バインディング・コンポーネントには、次の2種類があります。

- サービス
外部に対してSOAコンポジット・アプリケーションへのエントリ・ポイントを提供します。サービスのWSDLファイルによって、そのサービスの機能が外部のアプリケーションに通知されます。これらの機能は、SOAコンポジット・アプリケーション・コンポーネントとの接続に使用されます。サービスのバインディング接続性には、サービス(SOAP/HTTPやRESTバインディングなど)と通信できるプロトコルが記述されています。

- 参照
SOAコンポジット・アプリケーションから外部にある外部サービスに送信するメッセージを有効にします。RESTバインディングでは、Web Application Description Language (WADL)ファイルによって機能を外部アプリケーションに通知します。

図35-1 は、OrderBookingCompositeプロジェクトを示しており、ここでは「公開されたサービス」スイムレーンのサービス(UpdateOrderStatus)がコンポジットへのエントリ・ポイントを提供し、「外部参照」スイムレーンの参照(BAM_OrderDO)によって、外部のOracle BAMサーバーへ情報を送信できます。

図35-1 サービス・バインディング・コンポーネントおよび参照バインディング・コンポーネント

バインディング・コンポーネントを使用すると、次のタイプのテクノロジをSOAコンポジット・アプリケーションに統合できます。

- SOAP Webサービス

- HTTPバインディング

- JCAアダプタ

- Oracle E-Business Suite

- Oracle BAM 11g (このアダプタはOracle BAM 11gサーバーにのみ接続できます。)

- Oracle B2B

- Oracle Healthcare

- Oracle Managed File Transfer (MFT)

- ADF-BCサービス

- EJBサービス

- 直接バインディング・サービス

- RESTバインディング

- クラウド・アダプタ

次の各項では、これらのテクノロジについて説明します。

35.1.1 SOAP Webサービス

このサービスを使用すると、Simple Object Access Protocol (SOAP) over HTTPを使用した標準ベースWebサービスにアプリケーションを統合できます。WSDLファイルには、複数のWebサービスが記述されています。

WebサービスをSOAコンポジット・エディタのスイムレーンにドラッグすると、構成プロパティを指定するための「Webサービスの作成」ダイアログが表示されます。

Webサービスの詳細は、「Webサービスのインタフェース(WSDL)の定義方法」を参照してください。

メッセージ転送最適化メカニズム(MTOM)添付をWebサービスに追加する方法の詳細は、「SOAコンポジット・アプリケーションとのMTOM最適化メッセージの送受信」を参照してください。

35.1.1.1 WS-AtomicTransactionのサポート

「Webサービスの作成」ダイアログでは、WS-CoordinationおよびWS-AtomicTransaction (WS-AT)トランザクションのサポートも構成できます。WS-ATにより、Oracle WebLogic Serverと他のベンダーのトランザクション・サービス間でトランザクションの相互運用を行うことができます。相互運用は次の2レベルで行われます。

- ローカルJava Transaction API (JTA)環境からWebサービス・リクエストへのトランザクションのエクスポート。

- Webサービス・リクエストからローカルJTA環境へのトランザクションのインポート。これによって、Webサービス環境での複数ノード間の分散トランザクション処理が可能になります。

図35-2 に、「Webサービスの作成」ダイアログの下部にあるWS-ATのサポートを示します。

図35-2 「Webサービスの作成」ダイアログでのWS-ATのサポート

表35-1 では、WS-ATフィールドについて説明しています。「Webサービスの作成」ダイアログの残りのフィールドの詳細は、「Webサービスのインタフェース(WSDL)の定義方法」を参照してください。

表35-1 「Webサービスの作成」ダイアログのWS-ATのフィールド

プロパティ

説明

トランザクション参加

値を選択します。Webサービスを「公開されたサービス」スイムレーンに追加すると、外部トランザクション・マネージャでは、Oracle WebLogic ServerでホストされているリソースをWS-ATを使用して調整できます。また、Webサービスを「外部参照」スイムレーンに追加すると、Oracle WebLogic Serverのトランザクションでは、外部環境でホストされているリソースをWS-ATを使用して調整できます。

- なし
トランザクション・コンテキストは、インポート(サービスの場合)またはエクスポート(参照の場合)されません。Webサービスをサービス・バインディング・コンポーネントとして「公開されたサービス」スイムレーンに追加した場合は、これがデフォルトです。

- サポート
トランザクションが存在する場合は、トランザクション・コンテキストがインポート(サービスの場合)またはエクスポート(参照の場合)されます。この情報はcomposite.xmlファイルに追加されます。

- 必須
トランザクション・コンテキストはインポート(サービスの場合)またはエクスポート(参照の場合)されます。この情報はcomposite.xmlファイルに追加されます。エクスポートの場合、アクティブなトランザクションが存在しない場合はWebサービス例外メッセージがスローされます。インポートの場合、リクエストにトランザクション・コンテキストが存在しない場合はフォルトがクライアントに戻されます。

- WSDLDriven
このプロパティが表示されるのは、Webサービスを参照バインディング・コンポーネントとして「外部参照」スイムレーンに追加した場合のみです。これはデフォルト値です。

バージョン

WS-ATでサポートされるバージョン(1.0、1,1、1,2またはデフォルト)が表示されます。デフォルトでは、このリストが有効になるのは、「トランザクション参加」リストから「サポート」または「必須」を選択した場合のみです。

完了すると、次の例に示すように、WS-ATの選択内容がcomposite.xmlファイルに表示されます。

<service name="Service1" ui:wsdlLocation="BPELProcess1.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/Application5_
jws/Project1/BPELProcess1#wsdl.interface(BPELProcess1)"
callbackInterface="http://xmlns.oracle.com/Application5_
jws/Project1/BPELProcess1#wsdl.interface(BPELProcess1Callback)"/>
<binding.ws port="http://xmlns.oracle.com/Application5_
jws/Project1/BPELProcess1#wsdl.endpoint(Service1/BPELProcess1_pt)">
<property name="weblogic.wsee.wsat.transaction.flowOption"
type="xs:string" many="false">SUPPORTS</property>
<property name="weblogic.wsee.wsat.transaction.version" type="xs:string"
many="false">WSAT11</property>
</binding.ws>

変更内容を編集するには、サービスを右クリックして「編集」を選択するか、SOAコンポジット・エディタでサービスをダブルクリックします。

デプロイメント後は、システムMBeanブラウザを使用して、トランザクション参加およびバージョンの値を変更できます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

WS-ATおよびWS-Coordinationの詳細は『Oracle Infrastructure Webサービスの開発』、WS-ATおよびWS-Coordinationの仕様は次のURLを参照してください。

http://www.oasis-open.org

35.1.1.1.1 WS-ATでのBPELプロセスの参加確認

WS-AT参加プロパティの設定に加え、クライアントが、BPELプロセスであるWebサービスを呼出し、そのWebサービスが呼出し側のトランザクションに登録される場合、呼出し対象のBPELプロセスは、対応するcomposite.xmlファイルでtransactionプロパティが設定されている必要があります。

<property name="bpel.config.transaction">required</property>

この設定によって、エラーが発生(整合性制限違反によるデータベース・アダプタ呼出しの失敗など)しても、トランザクション・ロールバックは正常に完了することが保証されます。

transactionプロパティの設定方法の詳細は、「BPELプロセス・サービス・コンポーネントの追加方法」、「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」および「トランザクション・セマンティクス」を参照してください。

35.1.1.1.2 最適化が有効な場合にWS-ATトランザクションがサポートされない

「Webサービスの作成」ダイアログの「トランザクション参加」ドロップダウン・リストから、WS-ATトランザクションをサポートするためにサービスまたは参照のいずれかとしてWebサービス・バインディング・コンポーネントを構成できます。WS-ATトランザクションは、oracle.webservices.local.optimizationプロパティがfalseに設定されている場合に、コンポジットからWebサービスを(またはWebサービスからコンポジットを)コールする環境でサポートされます。

WS-ATトランザクションは、oracle.webservices.local.optimizationプロパティがfalseに設定されていても、コンポジットからコンポジットへの呼出しではサポートされません。

oracle.webservices.local.optimizationプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

35.1.2 HTTPバインディング・サービス

HTTPバインディング・サービスを使用すると、SOAコンポジット・アプリケーションとHTTPバインディングを統合できます。

「HTTP」サービスを「コンポーネント」ウィンドウからSOAコンポジット・エディタのスイムレーンにドラッグして、HTTPバインディング・ウィザードを起動します。この追加によって、HTTPバインディングを次のように構成できます。

- HTTPのPOSTおよびGET操作からSOAコンポジット・アプリケーションを起動するサービス・バインディング・コンポーネントとして「公開されたサービス」スイムレーンに構成します。

- HTTPのPOSTおよびGET操作からHTTPエンドポイントを起動する参照バインディング・コンポーネントとして「外部参照」スイムレーンに構成します。

注意:

SOAコンポジット・アプリケーションでHTTPバインディングを使用する際は、次の点に注意してください。

- アウトバウンドHTTPバインディング参照でサポートされているのは、外部HTTPエンドポイントからのレスポンスとしてのXMLのみです。レスポンスには、アウトバウンド予測に従った正しいXMLパート名が含まれている必要があります。

- HTTPバインディング・コンポーネントのhttpBindingプロパティは、実行時にOracle Enterprise Manager Fusion Middleware Controlで変更できません。

35.1.2.1 サポートされている相互作用

表35-2 に、インバウンド方向およびアウトバウンド方向でサポートされている動詞、ペイロードおよび操作を示します。

表35-2 サポートされている動詞、ペイロードおよび操作

方向

動詞

ペイロード・タイプ

操作

サポート対象か

インバウンド

GET

URLエンコード

一方向

はい

インバウンド

GET

URLエンコード

リクエスト/レスポンス

はい

インバウンド

GET

XML

一方向

いいえ

インバウンド

GET

XML

リクエスト/レスポンス

いいえ

インバウンド

POST

URLエンコード

一方向

はい

インバウンド

POST

URLエンコード

リクエスト/レスポンス

はい

インバウンド

POST

XML

一方向

はい

インバウンド

POST

XML

リクエスト/レスポンス

はい

アウトバウンド

GET

URLエンコード

一方向

いいえ

アウトバウンド

GET

URLエンコード

リクエスト/レスポンス

はい

アウトバウンド

GET

XML

一方向

いいえ

アウトバウンド

GET

XML

リクエスト/レスポンス

はい

アウトバウンド

POST

URLエンコード

一方向

いいえ

アウトバウンド

POST

URLエンコード

リクエスト/レスポンス

はい

アウトバウンド

POST

XML

一方向

いいえ

アウトバウンド

POST

XML

リクエスト/レスポンス

はい

表35-3 に、インバウンド方向およびアウトバウンド方向でサポートされているXSDタイプを示します。

表35-3 サポートされているXSD

方向

XSDタイプ

サポート対象か

インバウンド

単純

はい

インバウンド

複合

いいえ

インバウンド

ネイティブ

いいえ

アウトバウンド

単純

はい

アウトバウンド

複合

いいえ

アウトバウンド

ネイティブ

いいえ

次のHTTPヘッダーは、インバウンド方向またはアウトバウンド方向のいずれかでサポートされていません(つまり、コンポジットでHTTPヘッダーにアクセスした場合、そのヘッダーはコンポジットで設定できません)。

- User-agent

- Content-type

- Content-length

- Server

- Server-port

- Referrer

- Authorization

- MIME-Version

- Location

35.1.2.2 HTTPバインディング・サービスの構成方法

HTTPバインディング・サービスを構成する手順は、次のとおりです。

1. 「HTTP」アイコンを「コンポーネント」ウィンドウからドラッグすることで、HTTPバインディング・ウィザードを起動してHTTPバインディングを構成します。

2. 「ようこそ」、「サービス名」および「アダプタ・インタフェース」ページに対する適切なレスポンスを提供します。

ウィザードのHTTPバインディング・コンポーネント・ページを使用すると、操作タイプ、動詞およびペイロード・タイプを指定できます。図35-3に詳細を示します。

図35-3 HTTPバインディングの作成ウィザード - 「HTTPバインディング構成」ページ

3. インバウンドHTTPバインディングに対して次の操作タイプを選択します。

- 一方向操作: HTTPエンドポイントとの間でメッセージを送信または受信します。

- 同期リクエスト/レスポンス操作: HTTPエンドポイントとの間で入力メッセージと出力メッセージを送受信します。

HTTP POSTリクエスト・メソッドの場合は、URLエンコード(アンパサンドで区切られた名前/値ペア)またはXMLのいずれかのペイロード・タイプを選択できます。

HTTP GETリクエスト・メソッドの場合、ペイロード・タイプはURLエンコードです。

参照バインディング・コンポーネントのHTTP GETまたはPOSTリクエスト・メソッドの場合は、エンドポイントURLも指定するように求められます。HTTP認証およびSecure Socket Layer (SSL)もサポートされています。

注意:

セキュアなHTTP (HTTPS)は、インバウンド方向およびアウトバウンド方向の両方でサポートされています。

4. 「OK」をクリックします。

5. 既存のリクエスト・メッセージ・スキーマを参照するか、「メッセージ」ページの「URL」フィールドの右にあるリンクを使用して独自のスキーマを定義します。図35-4に詳細を示します。

図35-4 HTTPバインディングの作成ウィザード - 「メッセージ」ページ

6. 「OK」をクリックします。

7. 独自のスキーマを定義する場合は、要素名、データ型、最小発生数値および最大発生数値を「スキーマの作成」ダイアログで指定するように求められます。図35-5に詳細を示します。

図35-5 HTTPバインディングの作成ウィザード - 「スキーマの作成」ページ

8. 「OK」をクリックします。

実行時に、具体WSDLが、HTTPバインディングおよびSOAPバインディングとともに生成されます。これは、HTTPサポートの提供にSOAPエンドポイントが使用されているためです。

35.1.2.3 HTTPバインディングに対して基本認証を有効にする方法

インバウンドおよびアウトバウンドのHTTPバインディングでは、基本認証がサポートされています。インバウンドのHTTPバインディングに対して基本認証を有効にするには、セキュリティ・ポリシーを添付する必要があります。インバウンドHTTPバインディングは、基本認証が有効でなくても使用できます。

基本認証を有効化する手順は、次のとおりです。

1. 「公開されたサービス」スイムレーンで作成済のHTTPバインディング・サービスを右クリックし、「WSポリシーの構成」を選択します。

2. 「SOA WSポリシーの構成」ダイアログで、「セキュリティ」セクションにある「追加」アイコンをクリックします。

3. 「oracle/wss_http_token_service_policy」ポリシーを選択し、「OK」をクリックします。

4. 「SOA WSポリシーの構成」ダイアログで「OK」をクリックします。

35.1.3 JCAアダプタ

JCAアダプタを使用すると、サービスおよび参照を次のテクノロジと統合できます。

- データベース

- ファイル・システム

- FTPサーバー

- メッセージ・システム(Advanced Queueing (AQ)、Java Messaging Systems (JMS)など)

- IBM WebSphere MQ

- TCP/IPソケット

- サード・パーティ・アダプタ(SAP、JDE Worldなど)

- Oracle User Messaging Service

- Lightweight Directory Access Protocol (LDAP)サーバー

- Coherenceキャッシュ

JCAアダプタをSOAコンポジット・エディタのスイムレーンにドラッグすると、構成プロパティを指定するためのアダプタ構成ウィザードが起動します。

35.1.3.1 データベース・アダプタ

データベース・アダプタを使用すると、BPELプロセス、Oracle MediatorまたはOracle Service BusでJDBCを介してOracle Databaseやサード・パーティ・データベースと通信できます。

詳細は、『テクノロジ・アダプタの理解』のデータベースのOracle JCAアダプタに関する項を参照してください。

35.1.3.2 ファイル・アダプタ

ファイル・アダプタを使用すると、BPELプロセスまたはOracle Mediatorでローカル・ファイル・システムのファイルを交換(読取りおよび書込み)できます。ファイル・コンテンツは、XMLデータ・フォーマットと非XMLデータ・フォーマットのどちらでも構いません。

注意:

ファイル・アダプタをコールすると、Oracle Real Application Clustersの計画的停止に対して実行する際にOracle BPEL Process Managerが同じファイルを2回処理する可能性があります。これは、ファイル・アダプタがXAに準拠していないアダプタであるためです。したがって、グローバル・トランザクションに組み入れると、各ファイルを1回のみ処理するXAインタフェース仕様に逸脱する可能性があります。

詳細は、『テクノロジ・アダプタの理解』のOracle JCA Adapters for Files/FTPに関する項を参照してください。

35.1.3.3 FTPアダプタ

FTPアダプタを使用すると、BPELプロセスまたはOracle Mediatorでファイル転送プロトコル(FTP)を使用してリモート・ファイル・システムのファイルを交換(読取りおよび書込み)できます。ファイル・コンテンツは、XMLデータ・フォーマットと非XMLデータ・フォーマットのどちらでも構いません。

詳細は、『テクノロジ・アダプタの理解』のOracle JCA Adapters for Files/FTPに関する項を参照してください。

35.1.3.4 AQアダプタ

AQアダプタを使用すると、シングル・コンシューマ・キューまたはマルチ・コンシューマ・キューと相互作用できます。

Oracle Streams AQは、関連アプリケーション間での双方向の非同期通信を実現する柔軟なメカニズムを提供します。アドバンスト・キューはOracleデータベースの機能であるため、高いスケーラビリティと信頼性を備えています。また、単一のアプリケーションを複数のキューで処理できるため、メッセージを様々な方法で分割したり、ロード・バランシングを介して別のレベルのスケーラビリティを提供したりできます。

詳細は、『テクノロジ・アダプタの理解』のOracle JCA Adapter for AQに関する項を参照してください。

35.1.3.5 JMSアダプタ

JMSアダプタを使用すると、Oracle BPELプロセスまたはOracle MediatorでJava Messaging System (JMS)と相互作用できます。

JMSアーキテクチャでは、多数のメッセージング・サーバーに対して1つのクライアント・インタフェースを使用します。JMSモデルには、2つのメッセージング・ドメインがあります。

- ポイント・ツー・ポイント: メッセージはキュー経由で交換され、各メッセージは1人の受信者にのみ配信されます。

- パブリッシュ・サブスクライブ: メッセージはトピックに送信され、多数のサブスクライブ・クライアントで読み取ることができます。

詳細は、『テクノロジ・アダプタの理解』のOracle JCA Adapter for JMSに関する項を参照してください。

35.1.3.6 MQアダプタ

MQアダプタは、BPELプロセス、Oracle MediatorおよびWebSphere MQキューイングの各システム間のメッセージ交換機能を提供します。

Messaging and Queuing Series (MQ Series)は、IBMによって開発された製品および標準のセットです。MQ Seriesは、保証されたメッセージ配信、セキュリティおよび優先度ベースのメッセージングを提供するキューイング・インフラストラクチャを備えています。

詳細は、『テクノロジ・アダプタの理解』のOracle JCA Adapter for MQ Seriesに関する項を参照してください。

35.1.3.7 ソケット・アダプタ

ソケット・アダプタを使用すると、クライアントまたはサーバーのソケットを作成し、接続を確立できます。このアダプタを使用すると、TCP/IPソケットを介した通信用の標準または非標準プロトコルをモデル化できます。転送されるデータのフォーマットはテキストまたはバイナリです。

詳細は、『テクノロジ・アダプタの理解』のOracle JCA Adapter for Socketsに関する項を参照してください。

35.1.3.8 サード・パーティ・アダプタ

サード・パーティ・アダプタを使用すると、PeopleSoft、SAPなどのサード・パーティ・アダプタをSOAコンポジット・アプリケーションに統合できます。これらのサード・パーティ・アダプタによって、JCAアダプタを構成できるアーティファクト(WSDLおよびJCAファイル)が生成されます。

詳細は、『テクノロジ・アダプタの理解』を参照してください。

35.1.3.9 Oracle User Messaging Serviceアダプタ

Oracle User Messaging Serviceは、電子メール、セキュア・メッセージング・サービス(SMS)、インスタント・メッセージングおよびボイスなどのメッセージング・チャネルをサポートしています。Oracle User Messaging Serviceは、BPELプロセスまたはOracle Mediatorサービス・コンポーネントと外部との間のメッセージング・プロキシを提供します。Oracle User Messaging Serviceには、2つのメッセージング方法(インバウンドおよびアウトバウンド)があります。

詳細は、『テクノロジ・アダプタの理解』のOracle JCA Adapter for UMSに関する項を参照してください。

35.1.3.10 LDAPアダプタ

LDAPアダプタは、非同期および同期の両方のインタフェースを定義して、LDAPディレクトリ・サーバーとの間でリクエストとレスポンスを送受信します。LDAPアダプタを使用すると、プロセスは、LDAPプロトコルを使用してLDAPディレクトリを検索、比較および変更できます。

詳細は、『テクノロジ・アダプタの理解』のOracle JCA Adapter for LDAPに関する項を参照してください。

35.1.3.11 コヒーレンス・アダプタ

Coherenceキャッシュは、データベースとクライアント・アプリケーションの間の仲介として機能するデータ・オブジェクトの集合です。データベース・データをキャッシュにロードして、異なるアプリケーションで使用できます。Coherenceキャッシュは、データベースの負荷を削減し、データベース・データへのより高速なアクセスを提供します。キャッシュ内のオブジェクトは、XMLまたはPlain Old Java Object (POJO)のいずれかになります。Coherenceアダプタを使用すると、Coherenceキャッシュに対して次の操作を実行できます。

- 項目の追加

- 項目の取得

- 項目の削除

- 項目の問合せ

詳細は、『テクノロジ・アダプタの理解』のコヒーレンスのためのOracle JCAアダプタに関する項および『Oracle SOA Suiteの理解』のコヒーレンス・アダプタを使用したキャッシュからのプロバイダの読取りに関する項を参照してください。

35.1.4 Oracle E-Business Suiteアダプタ

Oracle Applicationsアダプタは、Oracle Applicationsへの接続性を提供します。このアダプタはOracle Applicationsリリース12およびリリース11iのモジュールをすべてサポートしています。このサポートには、Oracle E-Business Suiteのバージョンに基づいたカスタム統合インタフェース・タイプの選択も含まれます。

詳細は、『Oracle E-Business Suite Adapterユーザーズ・ガイド』を参照してください。

35.1.5 Oracle BAM 11gアダプタ

Oracle BAM 11gアダプタを使用すると、Java EEアプリケーションをOracle BAM 11gサーバーと統合してデータを送信できます。このアダプタはOracle BAM 11gサーバーにのみ接続できます。

BAM 11gアイコンをSOAコンポジット・エディタのスイムレーンにドラッグすると、構成プロパティを指定するためのアダプタ構成ウィザードが起動します。

詳細は、『Oracle BAMでのビジネス・アクティビティのモニタリング』を参照してください。

35.1.6 Oracle B2B

Oracle B2Bサービスを使用すると、MDSリポジトリのB2Bメタデータを参照したり、ドキュメント定義を選択することができます。

Oracle B2Bは、組織と外部取引パートナ間における安全で信頼できるトランザクション交換を提供するE-Commerceゲートウェイです。Oracle B2BおよびOracle SOA Suiteは、セキュリティ、準拠、可視性および管理の問題に対処するインフラストラクチャ内でプロセス・オーケストレーション、エラー低減、データ・トランスレーションとデータ・トランスフォーメーションを必要とするE-Commerceビジネス・プロセス用に設計されています。

「B2B」アイコンをSOAコンポジット・エディタのスイムレーンにドラッグすると、構成プロパティを指定するためのB2B構成ウィザードが起動します。

詳細は、『Oracle B2Bユーザーズ・ガイド』を参照してください。

35.1.7 Oracle Healthcare Adapter

Oracle Healthcare Adapterを使用すると、SOAコンポジット・アプリケーションにエンドツーエンドHealthcare統合プロセスを作成できます。Healthcareアダプタにより、SOAコンポジット・アプリケーションと、データを共有する外部ヘルスケア・アプリケーションとの間の接続、あるいは内部トピックまたはキューとの接続が確立され、データを内部または他のシステムで使用できるようになります。自身のコンポジット・アプリケーションで、BPELプロセス、Oracle Mediatorコンポーネント、様々なアダプタなど他のOracle SOA Suiteコンポーネントを使用できます。

次のように、Oracle JDeveloperの「Healthcare構成」ウィザードで、ヘルスケア統合バインディング・コンポーネントをSOAコンポジット・アプリケーションに追加できます。

- このコンポーネントは、外部システムからメッセージを受信してそれらをSOAコンポジット・アプリケーションに配信するためのサービス(インバウンド)として使用されます。Oracle SOA Suite for health care integrationは、SOAコンポジット・アプリケーションへのエントリ・ポイントです。

- このコンポーネントは、SOAコンポジット・アプリケーションから外部アプリケーションにメッセージを送信するための参照(アウトバウンド)として使用されます。

「Healthcare構成」ウィザードの手順に従うと、Oracle SOA Suite for health care integrationで作成されたドキュメント定義を選択するプロンプトが表示されます。

適切なものが存在しない場合は、そのウィザードからOracle SOA Suite for health care integrationを起動してドキュメント定義を作成できます。これは、外部システムとの間でユーザーが送受信するペイロード、つまりメッセージです。

詳細は、『Oracle SOA Suiteヘルスケア統合ユーザーズ・ガイド』を参照してください。

35.1.8 Oracle MFT

Oracle MFTにより、次などの多くのエンドポイント・タイプにおけるファイルの転送ができます。

- 組み込まれたFTPサーバーやsFTPサーバー

- リモートのFTPサーバーやsFTPサーバー

- ディレクトリ

- SOAP Webサービス・エンドポイント

- Oracle SOA Suite SOAP Webサービス・エンドポイント

- Oracle Service Bus Webサービス・エンドポイント

- Oracle B2BパートナとOracle Healthcareエンドポイント

- Oracle Data Integrator Webサービス・エンドポイント

詳細は、『Oracle Managed File Transferの使用』を参照してください。

35.1.9 ADF-BCサービス

ADF-BCサービスを使用すると、サービス・データ・オブジェクト(SDO)を使用してOracle Application Development Framework (ADF)アプリケーションをSOAコンポジット・アプリケーションに統合できます。

「ADF-BC」アイコンをSOAコンポジット・エディタのスイムレーンにドラッグすると、構成プロパティを指定するための「ADF-BCサービスの作成」ダイアログが表示されます。

Oracle ADFの詳細は、次のものを参照してください。

- データ・プロバイダ・サービスへのXMLデータ操作の委任

- スタンドアロンSDOベースの変数の使用

- Oracle Application Development FrameworkによるFusion Webアプリケーションの開発

- ADF FacesによるWebユーザー・インタフェースの開発

35.1.10 EJBアダプタ

EJBアダプタを使用すると、Javaインタフェース(インタフェースの定義にWSDLファイルを使用しない)またはSDOパラメータ(インタフェースの定義にWSDLファイルを使用)を渡すことによって、Enterprise JavaBeansとSOAコンポジット・アプリケーションの相互作用が可能になります。

SDOを使用すると、物理的にどのようにアクセスされているかに関係なくビジネス・データを修正できます。SOAコンポジット・アプリケーションでSDOを使用する場合、特定のバックエンド・データ・ソースへのアクセス方法についての知識は不要です。つまり、静的または動的なプログラミング・スタイルを使用して、接続および切断されたアクセスを取得できます。

Enterprise JavaBeansは、Javaでエンタープライズ・アプリケーションを作成するためのコンポーネントベースの標準アーキテクチャに適合する、サーバー側ドメイン・オブジェクトです。これらのオブジェクトは、分散化されたセキュアなトランザクション・コンポーネントになります。

Javaインタフェースの場合、WSDLファイルの定義は不要です。このタイプの統合は、次のオブジェクトをサポートします。

- ネイティブJavaオブジェクト

- Java Architecture for XML Binding

「EJB」アイコンをSOAコンポジット・エディタのスイムレーンにドラッグすると、構成プロパティを指定するための「EJBサービスの作成」ダイアログが表示されます。

詳細は、「Enterprise JavaBeansとコンポジット・アプリケーションの統合」を参照してください。

35.1.11 直接バインディング・アダプタ

直接バインディング・アダプタは、インバウンド方向では、直接バインディング起動APIを使用してSOAコンポジット・アプリケーションを起動し、Remote Method Invocation (RMI)を介してメッセージを交換します。このオプションでは、複数のJVM間のアイデンティティおよびトランザクションの両方の伝播がサポートされ、T3の最適化されたパスが使用されます。同期および非同期の両方の起動パターンがサポートされます。

アウトバウンド方向では、Oracle Service Bus (OSB)フローまたは別のSOAコンポジット・アプリケーションも起動できます。

「直接」アイコンをSOAコンポジット・エディタのスイムレーンにドラッグすると、構成プロパティを指定するための「直接バインディングの作成」ダイアログが表示されます。

直接バインディングの詳細は、「コンポジット・サービスの起動に直接バインディングを使用」を参照してください。

直接バインディング起動APIの詳細は、インフラストラクチャ管理のためのJava APIリファレンスを参照してください。

OSBの詳細は、『Oracle Service Busでのサービスの開発』を参照してください。

35.1.12 RESTバインディング

RESTは、ネットワーク・アプリケーションの設計用のアーキテクチャです。RESTfulアプリケーションでは、HTTPリクエストを使用してデータのポスト(作成および更新)、データの取得(問合せの作成など)およびデータの削除を行います。RESTは、Webサービスを使用するかわりの方法となります。SOAコンポジットは、REST対応可能、またはRESTアダプタを介して既存のRESTサービスを起動できます。

詳細は、「REST操作とSOAコンポジット・アプリケーションとの統合」を参照してください。

35.1.13 クラウド・アダプタ

SalesForceアダプタなどのクラウド・アダプタにより、クラウド・サーバーとメッセージの送受信ができます。

詳細は、『テクノロジ・アダプタの理解』を参照してください。

35.2 バインディング・コンポーネントとSOAコンポジット・アプリケーションの統合の概要

バインディング・コンポーネントをSOAコンポジット・アプリケーションに統合するには、対象のバインディング・コンポーネントを「コンポーネント」ウィンドウからドラッグします。

35.2.1 バインディング・コンポーネントとSOAコンポジット・アプリケーションの統合方法

SOAコンポジット・アプリケーションにバインディング・コンポーネントを統合する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウの「テクノロジ」セクションから、バインディング・コンポーネントを適切なスイムレーンにドラッグします。コンポーネントをドラッグするスイムレーンは、実行するアクションによって決まります。すべてのアダプタを両方のスイムレーンにドロップできるわけではありません。参照でのみ使用可能なアダプタの場合、サービス・スイムレーンにはドロップできません。

- SOAコンポジット・アプリケーションへのエントリ・ポイントを外部に提供する場合は、バインディング・コンポーネントを「公開されたサービス」スイムレーンにドラッグします。

- SOAコンポジット・アプリケーションから外部にある外部サービスにメッセージを送信できるようにする場合は、バインディング・コンポーネントを「外部参照」スイムレーンにドラッグします。

図35-6 に、コンポジットにドラッグされるSOAP Webサービスを示します。これによって、様々な構成プロパティを指定するためのダイアログが表示されます。

図35-6 Webサービス・バインディング・コンポーネントとコンポジットの統合

バインディング・コンポーネントの追加方法の詳細は、「サービス・バインディング・コンポーネントの追加」および「参照バインディング・コンポーネントの追加」を参照してください。

35.2.2 ADFバインディングを使用してJSP/Javaクラスからコンポジット・アプリケーションを起動する方法

SOAコンポジット・アプリケーションでWebサービス・バインディングを使用してエンドポイント参照を定義すると、JSP/Javaクラスからコンポジットを起動できません。Webサービス・バインディングは、binding.ws port="" location=""タグを使用してcomposite.xmlファイルに定義されます。次の例に詳細を示します。

<service name="client_ep" ui:wsdlLocation="BPEL.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/Application/Project/
BPEL#wsdl.interface(BPEL)"/>
<binding.ws port="http://xmlns.oracle.com/App/BPELProj/
BPELProcess#wsdl.endpoint(bpel_client_ep/BPELProcess_pt)"/>
</service>

かわりに、SOAコンポジットとADF-BC Webアプリケーションの相互作用にADFバインディングを使用します。ADFバインディングを使用してコンポジットをデプロイすると、JSP/Javaクラスからコンポジットを正常に起動できます。次の例に詳細を示します。

<reference name="ADFWebService"
ui:wsdlLocation="ADFWebService.wsdl">
<interface.wsdl interface="http://example.com/hr/#wsdl.interface(HRAppService)"/>
<binding.adf serviceName="{http://example.com/hr/}HRAppService"
registryName="hrapp_JBOServiceRegistry"/>
</reference>

この例では、hrappはADF-BC Webアプリケーション名です。

35.3 外部参照のバインディングURLで使用するためのトークンの作成

Oracle JDeveloperで、外部参照のバインディングURL内のHTTPプロトコル、ホスト、およびポート値に対してトークンを作成できます。その後、トークンに割り当てられた値によって、composite.xmlファイルのbinding.ws要素のlocation属性内のハードコードされたHTTPホストおよびポート値が置き換えられます。

たとえば、次の例は、プロトコル(http)、ホスト(host.us.example)およびポート(80)のハードコードされた値を持つlocation属性を示しています。

<binding.ws
port="http://www.globalcompany.example.com/ns/CreditAuthorizationService#wsdl.
endpoint(CreditAuthorizationService/CreditAuthorizationPort)"
location="http://host.us.example:80/apps/FusionOrderDemoShared/services/
creditAuthorization/CreditAuthorizationService.wsdl">

次の例は、トークン作成後のlocation属性を示しています。

<binding.ws
port="http://www.globalcompany.example.com/ns/CreditAuthorizationService#wsdl.
endpoint(CreditAuthorizationService/CreditAuthorizationPort)"
location="${protocol}://${host1}:${port1}/apps/FusionOrderDemoShared/services/
creditAuthorization/CreditAuthorizationService.wsdl">

注意:

- トークンは、composite.xmlファイルのbinding.ws要素のlocation属性でのみ使用できます。

- WSDLファイル、スキーマ・ファイルなど他のファイルでプロトコル、ホストおよびポート値に対してトークンを使用することはできません。

- Oracle JDeveloperでは、ローカル・ファイル・システム上の、トークン値を含むトークン・ファイルのみが更新されます。設計時にローカル・トークン・ファイルを使用する場合、実行時にそれらのトークンをSOAサーバーに移動する必要があります。トークンを実行時に作成する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

35.3.1 外部参照のバインディングURLで使用するためのトークンの作成方法

この項の手順に従って、外部参照のバインディングURLで使用するためのトークンを作成します。

外部参照のバインディングURLで使用するためのトークンを作成する手順は、次のとおりです。

1. Oracle JDeveloperで、トークンを作成するSOAコンポジット・アプリケーションにアクセスします。

2. 「SOAコンポジット・エディタ」の上で、「バインディングURLのトークン化機能」アイコンをクリックします。図35-7に詳細を示します。

図35-7 「バインディングURLのトークン化機能」アイコン

図35-8 のように、「バインディングURL」ダイアログが表示されます。

- 次のエントリで始まるcomposite.xmlファイルでlocation属性を持つbinding.ws要素が設定されている各外部参照のバインディングURLが、自動的に表示されます。

- http

- https

- ${ (ハードコードされたHTTPプロトコル、ホスト、またはポート値のかわりにトークンを使用するURLの場合)

- callbackServerURL

- binding.rest要素のlocation属性が設定されているREST参照のバインディングURLが、自動的に表示されます。

図35-8 「バインディングURL」ダイアログ

図35-8 のService2参照には、callbackServerURLなど参照プロパティを使用したコールバック場所のオーバーライドも含まれています。

<property name="callbackServerURL" type="xs:string" many="false">
${protocol}://${myhost1}:${myport1}/soa-infra/services/default/service/
bpelprocess1_client_ep</property>

図35-8 のようにcallbackServerURLプロパティもトークン化できます。

3. 行をダブルクリックするか、行を選択して「編集」アイコンをクリックし、外部参照のバインディングURLのHTTPプロトコル、ホスト、ポート値のトークンを作成します。

図35-9 のように、「バインディングURLのトークン化」ダイアログが表示されます。

図35-9 「バインディングURLのトークン化」ダイアログ

4. 表35-4 の説明に従って、環境に適した値を指定し、「OK」をクリックします。

表35-4 「バインディングURLのトークン化」ダイアログ

フィールド

説明

トークン・ファイル

次のオプションのいずれかを実行します。

- 「参照」ボタンをクリックし、トークン名および値が含まれているトークン・ファイルを選択するためのダイアログにアクセスします。ファイルは、ローカル・ファイル・システム上に配置されていてもかまいません。このファイルに指定した名前および値によって、binding.ws要素内のプロトコル、ホストおよびポートに対してハードコードされた名前および値が置き換えられます。このフィールドは、後続のこのダイアログの起動時に、ファイルの選択によって自動的に移入されます。ファイル・システムのトークン・ファイルを指定する場合、それは、次の形式のXMLファイルである必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM
"http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>
URL Resolver file used by the Metadata
manager to resolve $<variable> in URLs
</comment>
<entry key="protocol">oramds</entry>
<entry key="host">MyHost</entry>
<entry key="port">80</entry>
</properties>

- 新しいトークン名と値をそれぞれ「トークン」と「現在の値」のフィールドに手動で入力する場合、このフィールド全体をスキップします。
ファイルに保存されていないトークンは、コンポジットのbinding.ws要素のlocation属性にのみ配置されます。設計時に手動で入力されたものと一致するトークンを持つトークン・ファイルを実行時に指定することが予期されています。

参照

手順3で選択した外部参照を表示します。

プロトコル

プロトコル・トークン名を指定するフィールドを表示します。

- 「参照」アイコンをクリックし、「トークン・ピッカー」ダイアログから使用するトークン名を選択します。「トークン・ピッカー」ダイアログに、「トークン・ファイル」フィールドでインポートしたトークン・ファイルに含まれているトークン名が移入されます。選択したトークン名(たとえば、port1)およびそのデフォルト値(たとえば、80)が、それぞれ「トークン」と「現在の値」のフィールドに追加されます。トークン・ファイルが書込み可能(つまり、ファイル・システム内の保護されていないファイル)である場合、トークン名の現在の値を変更できます。「トークン・ピッカー」ダイアログへのアクセスの詳細は、手順5を参照してください。そのファイルが読取り専用である場合、メッセージによって警告され、その操作を取り消して続行できます。

- 使用するトークン名および値を手動で入力します。「トークン・ファイル」フィールドでファイルをインポートしたかどうかに関係なく、これらのフィールドに手動で情報を入力できます。「トークン・ファイル」フィールドで、書込み可能なファイルをインポートしてあり、トークン名を手動で入力すると、それがすでに存在していない場合は、それがそのファイルに追加されます。新しいトークン名の現在の値は、デフォルトで、トークン化中のURL内の値になります。

ホスト

ホスト・トークン名を指定するフィールドを表示します。情報の指定方法の詳細は、「プロトコル」フィールドの説明を参照してください。

ポート

ポート・トークン名を指定するフィールドを表示します。情報の指定方法の詳細は、「プロトコル」フィールドの説明を参照してください。

他の参照の同じ現在値にこれらのトークンを適用

同じプロトコル、ホストおよびポート値を持つ他の外部参照を、同じトークンで置き換えないようにするには、このチェック・ボックスの選択を解除します。

このチェック・ボックスが選択されており、URLオブジェクトの1つか2つのみをトークン化する場合は、それらのオブジェクトに対してのみ参照が変更されます。たとえば、ホスト(host1.us.oracleの現在値を持つ)のみをトークン化する場合、同じホスト値を持つすべての参照が更新されます。

5. 「プロトコル」、「ホスト」または「ポート」のフィールドで「参照」ボタンを選択した場合、図35-10 のように「トークン・ピッカー」が表示されます。このダイアログには、「バインディングURLのトークン化」ダイアログの「トークン・ファイル」フィールドでインポートしたファイルで定義されているすべてのトークンがリストされます。

図35-10 「トークン・ピッカー」ダイアログ

6. 次のオプションの1つを介して、使用するトークン名を選択します。

- リストをスクロールして、トークンを選択します。

- 「トークン」フィールドに名前を入力を開始して、名前が自動的に完成され、リスト内のトークンが選択されるまで続けます。

7. 「OK」をクリックします。

選択したトークン名と値がそれぞれ、「トークン」と「現在の値」のフィールドに表示された「バインディングURLのトークン化」ダイアログに戻ります。

36 REST操作とSOAコンポジット・アプリケーションとの統合

この章では、REST (Representational State Transfer)操作をサービス・バインディング・コンポーネントおよび参照バインディング・コンポーネントとしてSOAコンポジット・アプリケーションに統合する方法について説明します。また、バインディング・コンポーネント構成中のWebアプリケーション記述言語(WADL)ファイルの使用方法についても説明します。

この章の内容は次のとおりです。

- RESTサポートの概要

- サービスおよび参照バインディング・コンポーネントにおけるRESTサポートの作成

- BPELコンポーネントでのJavaScriptおよびJSONの使用

- HTTPアナライザによるRESTアダプタのテスト

- Oracle Enterprise Manager Fusion Middleware ControlでのREST参照のバインディング・コンポーネントのテストおよび構成

RESTアダプタの使用方法の詳細は、『Oracle SOA Suiteの理解』のRESTサービスによる出荷リソースの定義に関する説明を参照してください。

36.1 RESTサポートの概要

RESTは、ネットワーク・アプリケーションの設計用のアーキテクチャです。RESTfulアプリケーションは、HTTPリクエストを使用してデータのポスト(作成と更新)、データの取得(たとえば問合せの作成)、データの更新およびデータの削除を実行します。RESTは、Webサービスを使用するかわりの方法となります。

12.2.1から、SOAコンポジットでエンドツーエンドのJSONを使用できるようになりました。すなわち、RESTサービスはRESTリクエストを受信し、XMLに変換することなくBPELエンジンにルーティングすることができます。BPELコンポーネントはJavaScriptアクションを使用して、さらに条件付きおよび反復コンストラクトでJavaScriptを使用して、JSONオブジェクトで直接動作できます。REST参照はBPELエンジンからRESTメッセージを受信し、変換することなく外部RESTエンドポイントにルーティングできます。

注意:
RESTインタフェースとBPELコンポーネントはエンドツーエンドのJSONをサポートしています。ただし、メディエータのような他のサービス・コンポーネントを使用している場合は、RESTリソースと動詞をWSDL操作とXMLスキーマに内部的にマッピングして着信ペイロードをXMLに変換する、12.1.3スタイルのコンポジットを使用する必要があります。

Oracle SOA Suiteでは次のRESTサポートを提供します。

- SOAコンポジット・アプリケーションでのサポート:

- エンドツーエンドのJSONの有効化

- 新規または既存のサービスでのRESTサポートの有効化。

- 外部REST APIとの統合。

- RESTful状態遷移セットの編成 (RPC/HATEOAS (Hypermedia as the Engine of Application State)アプローチ)。

- XML、JavaScript Object Notation (JSON) (XMLへおよびXMLからの自動翻訳を含む)、テキスト、不透明(Opaque)(バイナリ)およびURLエンコード・ペイロード・データのサポート。

- RESTサービス操作用のサンプルURIの生成。

- WADLサービスのサポート。WADLは、デプロイ済のOracle SOA SuiteまたはOracle Service Busサービス、あるいはJersey RESTサービスなど、Oracle SOA SuiteまたはOracle Service Bus以外のサービスでも提供できます。

- 開発の容易さ:

- Oracle JDeveloperウィザードには、RESTインタフェースおよびWSDL操作バインディングをモデル化するためのいくつかのオプションが用意されています。

- REST定義からWSDLへのマッピングが含まれる基礎となるWSDLを生成するための、リソース・パスおよびREST操作の手動による定義。

- WSDL操作をリソース・パスおよびHTTP動詞にマッピングするサービス・コンポーネントまたは外部参照のWSDLの選択。

- RESTアダプタに操作マッピングを自動的に移入する多数のソース(たとえば、アプリケーション・サーバーやSOA-MDS)からのWSDLの選択。

- 開発時に使用する各メソッドを公開する読取り可能API。

- Oracle JDeveloperからOracle RESTエンドポイント(Oracle Service Busなど)をブラウズおよび消費可能。

- Oracle Web Service Manager (OWSM)ポリシーのRESTセキュリティのサポート。

- 次のユースケースをサポートします。

- 顧客リストの取得

- 新規顧客の作成

- 顧客の詳細情報の取得

- 顧客の詳細情報の更新

- 顧客の削除

- 顧客の新住所の作成

- 顧客の住所の取得

- 顧客の住所の更新

36.2 サービスおよび参照バインディング・コンポーネントにおけるRESTサポートの作成

Oracle SOA Suiteコンポーネント、サービスおよび参照は、RESTサービスとして選択および公開できます。この項では、次のタスクの実行方法について説明します。

- 既存のSOAコンポジット・アプリケーションのサービス・バインディング・コンポーネントとしてRESTサポートを追加します。

- SOAコンポジット・アプリケーションから起動できる参照バインディング・コンポーネントとしてRESTサポートを追加します。

- ショートカットを使用してRESTサポートを構成します。

- RESTスキーマを生成します

- ホスト、ポートおよびプロトコル値のグローバル・トークン変数を使用します。

注意:

- RESTバンディングは、非同期コンポーネント(例: 非同期BPELプロセス)に添付できません。この添付を試みると、この操作はサポート対象ではないため、RESTサービスと一方向インタフェースを持つサービスの間にOracle Mediatorを配置し、サービス・コールバックを別の(アウトバウンド) RESTアダプタにルーティングするための回避策の提案を示すメッセージが表示されます。

- RESTサービス・バインディング・コンポーネントはREST参照バインディング・コンポーネントに接続できません。

36.2.1 SOAコンポジット・アプリケーションのRESTバインディング・コンポーネントを構成する方法

この項では、RESTバインディング・コンポーネントをSOAコンポジット・アプリケーションに追加する方法について説明します。RESTバインディング・コンポーネントをサービスまたは参照バインディング・コンポーネントとして追加できます。

RESTアダプタをSOAコンポジット・アプリケーションのサービスまたは参照バインディング・コンポーネントとして構成する手順:

1. JDeveloperで、RESTサービスまたは参照コンポーネントをコンポジット・ビューの適切なスイムレーンに追加します。「コンポーネント」ウィンドウからRESTコンポーネントをドラッグすることもできます。

- RESTサービス・コンポーネントを追加するには、SOAコンポジット・エディタの「公開されたサービス」スイムレーンを右クリックし、「挿入」→「REST」を選択します。この操作で、適切なサービス・コンポーネントと相互作用するサービス・バインディング・コンポーネントとしてRESTサポートを追加できます。

- REST参照コンポーネントを追加するには、SOAコンポジット・エディタの「外部参照」スイムレーンを右クリックし、「挿入」→「REST」を選択します。この操作で、外部RESTエンドポイントと相互作用する参照バインディング・コンポーネントとしてRESTサポートを追加できます。

RESTバインディング構成ウィザードが表示されます。

2. RESTサービスまたは参照の名前を入力します。
タイプフィールドにRESTバインディングのタイプが表示されます。これは、RESTサービスの場合は「サービス」、REST参照の場合は「参照」です。

3. オプションで「サービスはWSDLインタフェースを使用してコンポーネントを起動します」または「参照はWSDLインタフェースを使用してコンポーネントによって起動されます」オプションを選択します。

- RESTサービスの場合、コンポジットで内部的にXMLスキーマとWSDL操作が使用される場合は、「サービスはWSDLインタフェースを使用してコンポーネントを起動します」を選択します。

- REST参照の場合、コンポジットで内部的にXMLスキーマとWSDL操作が使用される場合は、「参照はWSDLインタフェースを使用してコンポーネントによって起動されます」を選択します。

12.2.1から、SOAコンポジットでエンドツーエンドのJSONを使用できるようになりました。すなわち、RESTサービスはRESTリクエストを受信し、XMLに変換することなくBPELエンジンにルーティングすることができます。BPELコンポーネントはJavaScriptアクションを使用して、さらに条件付きおよび反復コンストラクトでJavaScriptを使用して、JSONオブジェクトで直接動作できます。REST参照はBPELエンジンからRESTメッセージを受信し、変換することなく外部RESTエンドポイントにルーティングできます。

デフォルトでは、新しいRESTサービス/参照バインディングはWADLを使用します。ただし、RESTリソースと動詞をWSDL操作とXMLスキーマに内部的にマッピングして、着信ペイロードをXMLに変換する12.1.3スタイルのコンポジットを使用する必要がある場合は、このオプションを選択します。コンポジットでWSDLベースの操作のみをサポートするメディエータのようなコンポーネントが使用される場合も、このチェック・ボックスを選択できます。

- このオプションを選択すると、XMLスキーマの順序付けを強制オプションが表示されます。
「XMLSchemaの順序付けを強制」を選択すると、XMLスキーマの順序付けが強制されます。

選択すると、XMLスキーマの要素の順序付けと一致するようにJSONペイロードを並べ替えます。これには、インバウンド・リクエスト・ペイロードおよびアウトバウンド・リクエストからのレスポンスが含まれます。このオプションによって、パフォーマンスのオーバーヘッドが追加される可能性があります。

このチェック・ボックスを選択すると、RESTサービス・バインディングのプロパティreorderJsonAsPerXmlSchemaがcomposite.xmlファイルでtrueに設定されます。

4. 「次へ」 をクリックします。
「リソース」ページが表示されます。

5. 表36-1 では、このページのフィールドについて説明します。

表36-1 「リソース」ページ

フィールド

説明

構成ショートカット

コンテキストに基づいて構成ショートカットを提供します。

- RESTサービス・インタフェースの場合:

- WADLベースのRESTサービスを作成する場合は、「WADLサービスからリソースとメソッドを追加」を選択できます。これにより、既存のWADLサービスを使用して、リソースとメソッドをRESTサービスに追加できます。

- サービスがSDLインタフェースを使用してコンポーネントを起動する場合、「RESTコンポーネントや参照の有効化」および「REST外部Webサービスの有効化」オプションを選択できます。すなわち、選択したコンポーネントまたはサービスのフォルト・バインディングが、WSDLファイルで定義されたフォルトに基づいて自動的に生成されます。
選択したWSDLが読み取られ、WSDL操作が、「リソース」ページの「操作バインディング」セクションのリソース・パスおよびHTTP動詞にマッピングされます。操作バインディングで追加の構成マッピングが必要な場合は、「完了」列の「いいえ」の値でそのことが示されます。

- REST参照インタフェースの場合:
「WADLサービスに基づいてリソースと操作のマッピングを追加」を使用して、WADLリソースからリソースと操作のマッピングを追加できます。WADLリソースは、ローカル・ファイル・システムまたはプロジェクト、デザインタイムOracle Metadata Servicesリポジトリ(MDSリポジトリ)あるいはアプリケーション・サーバーにあります。

説明

このフィールドは、RESTサービスに対して表示されます。

RESTサービスの説明を入力します。この説明は、開発時に使用される読取り可能なAPIの一部として公開されます。

ベースURI

このフィールドは、REST参照に対して表示されます。

インタフェースでサポートされているすべてのリソースのベースURI接続情報。例: http://search.mydomain.com/search.format

リソース・パス

デフォルト・リソース・パス(/)をダブルクリックしてリソース・パスを更新するか、「追加」をクリックして新しいリソース・パスを追加します。

「相対パス」フィールドで、リソース・パス(この例では/orders)を入力し、「OK」をクリックします。

操作バインディング

このセクションは、RESTリソースと動詞をWSDL操作とXMLスキーマに内部的にマッピングして、着信ペイロードをXMLに変換する12.1.3スタイルのコンポジットを作成している場合に表示されます。

「追加」をクリックして、新しい操作バインディングを追加します。

既存の操作バインディングを選択して「編集」をクリックすることもできます。

「追加」または「編集」をクリックすると、「REST操作バインディング」ダイアログが表示されます。「REST操作バインディング」ダイアログに表示されるフィールドの構成の詳細情報は、「「REST操作バインディング」ダイアログ」を参照してください。

メソッド

このセクションは、タイプ付きでないペイロードをスキーマなしで使用するWADLベースのサービスまたは参照を作成している場合に表示されます。
「追加」をクリックして新しいメソッドを追加します。

既存のメソッドを選択して「編集」をクリックすることもできます。

「追加」または「編集」をクリックすると、「RESTメソッド定義」ダイアログが表示されます。「RESTメソッド定義」ダイアログに表示されるフィールドの詳細情報は、「「RESTメソッド定義」ダイアログ」を参照してください。

6. 「終了」をクリックして、RESTバインディング構成を完了します。

36.2.1.1 「RESTメソッド定義」ダイアログ

「RESTメソッド定義」ダイアログを使用して、WADLおよびタイプ付きでないペイロードをスキーマなしで使用するSOA RESTサービスまたは参照のRESTメソッドを定義します。

表36-2 「RESTメソッド定義」ダイアログ

フィールド

説明

メソッド

定義するRESTメソッドの名前を入力します。

リソース

既存のURLリソース・パスをリストから選択するか、「追加」アイコンをクリックして新しいリソース・パスを追加します。

HTTP動詞

WSDL操作にバインドされる動詞(GET、PUT、POST、DELETEなど)を選択します。

説明

説明を入力します(オプション)。これは、メソッドについて公開される説明テキストです。

リクエスト

「ペイロード」セクションでは、リクエスト・ペイロードの形式をJSON (デフォルト選択項目)、XML、URLエンコード、テキスト、不透明(Opaque)またはペイロードなしのいずれかに指定できます。「メソッドのサンプルURLを生成します」をクリックして、メソッド操作のサンプルURLを表示します。

「URIパラメータ」セクションでは、REST問合せまたはテンプレート・パラメータから対応するランタイム・プロパティへのマッピングを指定できます。

1. 「メソッドのサンプルURLを生成します」アイコン(最初のアイコン)をクリックして、以前入力したすべてのバインディング情報に基づいてサンプルURLを生成します。このオプションは通常、すべてのパラメータを構成した後に選択します。

2. 「パラメータの追加」アイコン(2番目のアイコン)をクリックして、マッピング・パラメータを手動で追加します。

3. 「スタイル」で、「問合せ」または「テンプレート」を選択します。テンプレート変数は、通常、POST操作およびPUT操作に使用されます。問合せパラメータは、通常、GET操作およびDelete操作に使用されます。

4. 「タイプ」で、パラメータのデータ型を選択します。すべてのXSDプリミティブ型がサポートされています。

5. 「デフォルト値」で、パラメータの設計時のデフォルト値を設定できます。RESTリクエストにURIパラメータがない場合は、RESTサービスによって対応するデフォルト値が使用されます。

6. 「ランタイム・プロパティ」に、メソッド・パラメータのマッピング先のランタイム・プロパティの名前が表示されます。

レスポンス

成功および失敗セクションでは、レスポンス・ペイロードとメソッドのステータスを選択できます。

デフォルトのレスポンス・ペイロードは「ペイロードなし」です。成功した操作のデフォルトのHTTPステータス・コードは204で、失敗した操作の場合は500です。

36.2.1.2 「REST操作バインディング」ダイアログ

「REST操作バインディング」ダイアログを使用し、WSDLインタフェースを使用してコンポーネントを起動するRESTサービスのREST操作を定義します。リソース・パスおよびREST操作を定義できます。REST定義からWSDLへのマッピングが含まれた基礎となるWSDLが生成されます。

表36-3 「REST操作バインディング」ダイアログ

フィールド

説明

操作

マッピングするWSDL操作名を表示します。生成されたWSDLで使用されている名前を指定できます。

リソース

既存のURLリソース・パスをリストから選択するか、「追加」アイコンをクリックして新しいリソース・パスを追加します。

選択したリソース・パスが、このダイアログの下部にある「リクエスト」セクションの「URIパラメータ」表に追加されます。選択したリソースに{var}などのテンプレート変数が含まれている場合、その変数がURIパラメータに追加されます。

HTTP動詞

WSDL操作にバインドされる動詞(GET、PUT、POST、DELETEなど)を選択します。

この選択内容によって、受信REST問合せパラメータからWSDLスキーマへのマッピングが「URIパラメータ」表に移入されます。

操作のHTTP動詞は、「OK」をクリックした後に、「RESTバインディングの作成」ダイアログの「操作バインディング」セクションにも追加されます。

説明

説明を入力します(オプション)。参照バインディング・コンポーネントには、「ベースURI」フィールドがあります。

リクエスト

「スキーマ」セクションには、使用されているリクエスト・スキーマが表示されます。

- スキーマURL: 使用するリクエスト・スキーマが表示されます。「RESTバインディングの作成」ダイアログで「RESTコンポーネントや参照の有効化」を選択した場合、スキーマはサービスの操作WSDLから取得されるため、このフィールドは読取り専用になります。「RESTバインディングの作成」ダイアログで「操作バインディングの追加」を選択した場合、スキーマを参照するか、ネイティブ・フォーマット・ビルダー・ウィザードを使用してサンプルから新しいスキーマを作成する必要があります。

- 要素: 使用する要素が表示されます。

「ペイロード」セクションでは、リクエスト・ペイロードの形式をXML (デフォルト選択項目)、JSON、URLエンコードまたはペイロードなしのいずれかに指定できます。「サンプル・ペイロードの生成」をクリックして、選択したリクエスト・ペイロードのサンプルを表示します。

「URIパラメータ」セクションでは、REST問合せパラメータからWSDLスキーマへのマッピングを指定できます。このセクションは、「HTTP動詞」リストでスキーマを指定する際に(動詞に応じて)自動的に移入されます。GET動詞およびDELETE動詞では、パラメータはWSDLスキーマにバインドされます。POST動詞およびPUT動詞では、インバウンド・ペイロードがWSDLスキーマにマッピングされます。

1. 「操作用のサンプルURLを生成」アイコン(最初のアイコン)をクリックして、以前入力したすべてのバインディング情報に基づいてサンプルURLを生成します。このオプションは通常、すべてのパラメータを構成した後に選択します。

2. 「パラメータの追加」アイコン(2番目のアイコン)をクリックして、マッピング・パラメータを手動で追加します。

3. 「スタイル」列で特定の行をクリックするとリストが呼び出され、このリストで問合せまたはテンプレートを選択できます。テンプレート変数は、通常、POST操作およびPUT操作に使用されます。問合せパラメータは、通常、GET操作およびDelete操作に使用されます。

4. 「タイプ」列で、パラメータのデータ型を選択します。すべてのXSDプリミティブ型がサポートされています。多くの場合、パラメータがスキーマから自動的に生成されるときにタイプが設定されます。新しいパラメータを作成した場合は、「タイプ」列でリストからタイプを選択できます。

5. 「デフォルト値」列で、パラメータの設計時のデフォルト値を設定できます。RESTリクエストにURIパラメータがない場合は、RESTサービスによって対応するデフォルト値が使用されます。

6. 「式」列で特定の行をクリックすると、xpath-expression関数を追加するための「式ビルダー」ダイアログが表示されます。スキーマが操作に対して定義されていない場合、「式ビルダー」パラメータにはプロパティ変数のみが表示され、メッセージ変数は表示されません。式によってパラメータがWSDLスキーマのフィールドにバインドされます。パラメータが自動的に生成される(既存または生成されたスキーマに基づいて)すべての場合に、この式はすでに自動的に生成されています。新しいパラメータを追加する場合や実行時プロパティなどの別のものにバインドする場合にのみ、式を追加します。XPath式は、特定のURIパラメータを正規化されたメッセージに挿入する場所を指定します。

レスポンス

「HTTPステータス」セクションでHTTPステータス・コードを指定できます。空白で区切られた複数のステータスを入力できます。参照では、成功と解釈される可能性のあるステータスがあります。サービスでは、返すことができる可能性のある成功ステータス(BPELなどのサービス・コンポーネントによって設定)があります。

「ペイロード」セクションでは、可能なレスポンス・ペイロードであるXML (デフォルト)、JSONまたはペイロードなしを指定できます。実行時に返される出力は、受信リクエストに応じて異なります。「サンプル・ペイロードの生成」をクリックして、選択したレスポンス・ペイロードのサンプルを表示します。

「スキーマ」セクションには、可能なペイロードのタイプが選択されている場合に使用されるレスポンス・スキーマが表示されます。ペイロードなしが選択されている場合、このフィールドは表示されません。

- スキーマURL: 使用するレスポンス・スキーマが表示されます。スキーマを指定していない場合は、既存のスキーマを参照するか、ネイティブ・フォーマット・ビルダー・ウィザードを使用してサンプルから新しいスキーマを作成するかを選択できます。このウィザードでは、JSON Interchangeフォーマット、XMLサンプル、URIエンコード形式またはURIサンプルのいずれかでスキーマを作成できます。詳細は、「サンプルからのスキーマの生成方法」を参照してください。

- 要素: 使用する要素が表示されます。

「フォルト・バインディング」セクションには、レスポンス・フォルト名、タイプ、ステータスおよびスキーマが表示されます。フォルトの詳細がWSDLファイルで定義されている場合は、フォルト・バインディングがこのセクションに自動的に作成されます。フォルト・バインディングは、「追加」アイコンをクリックして、手動でも定義できます。フォルトの詳細は、「RESTフォルト・バインディングに関する必知事項」を参照してください。

36.2.2 例: 既存のRESTサービス・コンポーネントの有効化

RESTバインディング構成ウィザードの「構成ショートカット」からRESTコンポーネントやサービスの有効化 オプションを使用して、既存のRESTサービス・コンポーネントを有効化できます。

1. SOAコンポジット・エディタの「公開されたサービス」スイムレーンを右クリックし、「挿入」→「REST」を選択します。
RESTバインディング構成ウィザードが表示されます。

2. 「サービスはWSDLインタフェースを使用してコンポーネントを起動します」を選択します。

3. 「次へ」 をクリックします。

4. 「構成ショートカット」でRESTコンポーネントやサービスの有効化を選択します。
「サービス・エクスプローラ」ダイアログが表示されます。

5. ナビゲータを開いて、サービス・コンポーネントのWSDL (この例ではBPELプロセス)を選択し、「OK」をクリックします。この操作で、WSDL操作をリソース・パスおよびHTTP動詞にマッピングできます。図36-1に詳細を示します。

図36-1 REST操作をリソース・パスおよびHTTP動詞にマッピングするために選択されたWSDL

RESTバインディング構成ウィザードの「リソース」ページが更新され、図36-2に示すように表示されます。

選択したWSDLが読み取られ、WSDL操作が、「操作バインディング」セクションのリソース・パスおよびHTTP動詞にマッピングされます。「リソース・パス」および「HTTP動詞」セクションには、構成マッピングを追加する必要があることに注意してください。これは、「完了」列の「いいえ」の値でも示されます。

図36-2 RESTバインディング構成ウィザードの「リソース」ページ

今度は、各操作のリソース・パスおよびHTTP動詞を構成する必要があります。この例では、操作は1回のみです。WSDLによっては、「操作」列に複数の操作が表示される可能性があります。

6. 「リソース」セクションの「リソース・パス」表で、「/」のデフォルト・パス・エントリをダブルクリックします。操作バインディングを開始する前にリソース・パスを定義することもできます。この場合、選択されているリソースが新しいバインディングに使用されます。

「RESTリソースの更新」が起動します。

7. 「相対パス」フィールドで、リソース・パス(この例では/orders)を入力し、「OK」をクリックします。図36-3に詳細を示します。

図36-3 「RESTリソースの更新」ダイアログ

古いリソース・パスを持つ操作マッピングが、「リソース」セクションおよび「操作バインディング」セクション(この例では、/orders)の新しいリソース・パスで更新されます。既存のコンポーネントを更新する場合は、通常はすべての操作が更新されます。

必要に応じて、「リソース」セクションの「追加」アイコンをクリックし、「RESTリソースの作成」ダイアログを表示して、リソース・パスを追加で作成できます。

今度は、「操作バインディング」セクションの「HTTP動詞」列を構成する必要があります。

8. 「操作バインディング」セクションで操作を選択して、「編集」をクリックします。
「REST操作バインディング」ダイアログが表示されます。

このダイアログを使用して、操作のHTTP動詞を選択し、HTTP動詞およびリソースをWSDL操作にバインドしてRESTパラメータをコンポーネント・サービスのWSDLスキーマにマッピングするために「URIパラメータ」セクションに移入できます。「「REST操作バインディング」ダイアログ」で、このダイアログのフィールドについて説明しています。

9. 必要に応じて、「リソース」リストで新しいリソースを選択します。

「URIパラメータ」セクションが更新され、選択内容が反映されます。

10. 「HTTP動詞」リストで操作(この例ではGET)を選択します。

「URIパラメータ」セクションが更新され、選択内容が反映されます。

スタイル(queryまたはtemplate)は、「URIパラメータ」セクションの「スタイル」列で自動的に選択されます。

テンプレート変数を含む新規RESTリソースを選択または作成する場合、Oracle JDeveloperでは、同じ名前のテンプレート・パラメータの作成を試みます。その名前のパラメータがすでに存在する場合、その名前が再使用されます(また、問合せパラメータだった場合はテンプレート・パラメータになります)。重複したパラメータ名は決して作成されません。重複したパラメータが手動で作成されると、エラーが返されます。

11. 「レスポンス」タブをクリックして、HTTPステータス・コード、ペイロード出力タイプ、スキーマおよびフォルト・バインディングの詳細を表示します。スキーマはこの例ですでに定義したので、選択項目の編集が無効になっています。

12. フォルト名をダブルクリックして、「RESTフォルト・バインディング」ダイアログを表示します。このダイアログの詳細は、「ヘルプ」アイコンをクリックするか、「RESTフォルト・バインディングに関する必知事項」を参照してください。

13. 必要に応じて編集し、「OK」をクリックします。

14. 「OK」をクリックして「リソース」ページに戻ります。追加したHTTP動詞が表示されます。

15. 「操作バインディング」セクションで、操作を選択し、「編集」をクリックして、残りの操作についてもリソースおよびHTTP動詞を定義します。

16. 「OK」をクリックしてSOAコンポジット・エディタに戻ります。
RESTサービスはBPELプロセス・サービス・コンポーネントに接続されます。

36.2.3 例: WADLサービスからREST参照へのリソースおよび操作の追加

RESTバインディング構成ウィザードの「構成ショートカット」を使用して、WADLサービスからREST参照にリソースおよび操作を追加できます。

1. SOAコンポジット・エディタの「外部参照」スイムレーンを右クリックし、「挿入」→「REST」を選択します。
RESTバインディング構成ウィザードが表示されます。

2. RESTサービスまたは参照の名前を入力します。
タイプフィールドに参照が表示されます。

3. 「サービスはWSDLインタフェースを使用してコンポーネントにより起動されます」を選択します。

4. 「次へ」 をクリックします。

5. 「構成ショートカット」で「WADLサービスに基づいてリソースと操作のマッピングを追加」を選択します。
「WADLの場所」ダイアログが表示されます。

6. 次のいずれかの方法で、WADLファイルを指定します。

a. 「WADL URL」フィールドでWADLファイルのURLを指定し、手順7に進みます。
または

b. 「検索」アイコンをクリックして、WADLファイルを検索する「WADLチューザ」ダイアログを表示します。WADLの検索オプションが表示され、ローカル・ファイル・システムまたはプロジェクト内、あるいはデザインタイムOracle Metadata Servicesリポジトリ(MDSリポジトリ)内を検索するか、アプリケーション・サーバーに接続して、デプロイ済のOracle SOA SuiteまたはOracle Service Busサービスに関連するWADLを検索するかを選択できます。図36-4に詳細を示します。

図36-4 「WADLチューザ」ダイアログ

c. WADLファイルを選択し、「OK」をクリックします。

d. 手順7に進みます。

7. 「OK」をクリックします。

8. WADLファイル内で参照されているスキーマは新しいRESTアダプタ参照で使用されるため、「スキーマ・アーティファクトをプロジェクトにコピー。」を選択してこれらのスキーマをローカル・プロジェクトにコピーします。これが推奨される方法です。

9. 選択したWADLファイルのタイプに応じて、手順を参照してください。表36-4に詳細を示します。

表36-4 WADLファイルのステータス

選択したWADLファイルの提供元

結果

手順

Oracle SOA SuiteまたはOracle Service BusのRESTサービス

「リソース」ページが、WADLファイルの情報で完全に構成されます。すべての操作、リソース・パスおよび動詞が「操作バインディング」セクションに表示されます。すべての構成が、「操作バインディング」セクションの「完了」列に「はい」の値で表示されます。

9.a

Oracle SOA SuiteまたはOracle Service Bus以外のRESTサービス(Jerseyサービスなど)。

「WADL解析問題」ダイアログに、追加の構成が必要と表示されます。

9.b

a. 「リソース」ページを表示して内容を確認し、「OK」をクリックします。

b. 「WADL解析問題」ダイアログ(図36-5 を参照)で、推奨修正処理のリストを確認し、「OK」をクリックします。後の参照用に、同じ情報がOracle JDeveloperの「ログ」ウィンドウに書き込まれます。

Oracle SOA SuiteまたはOracle Service Bus以外のサービスのWADLファイルには、通常、必要な情報がすべて含まれていません。構成を手動で完了する必要があります。図36-5 などの多くの場合に、使用するWADLファイルではREST参照をWSDL操作にバインドするために必要なスキーマが提供されません。通常、このスキーマは、RESTサービス・プロバイダによって提供されるサンプル・ペイロードを使用してネイティブ・フォーマット・ビルダー・ウィザードで生成できます。

図36-5 WADL解析問題

「リソース」ページが表示されます。

さらに構成が必要なRESTバインディングについては、「操作バインディング」セクションの「完了」列に「いいえ」の値が表示されます。値が「いいえ」の各「完了」列のツールチップには、欠落している内容が示されているので、修正処理を実行できます。少なくとも1つの操作の「完了」列に「いいえ」の値があるかぎり、「OK」ボタンは無効になります。

注意:

Oracle JDeveloperの「ログ」ウィンドウにも、すべてのエラーおよび警告がより詳しく表示されます。たとえば、「ログ」ウィンドウには次のようなエントリが含まれています。

ERROR at [resource path: containers/{container}, method name: PUT,
request/response: response, representation mediaType:
application/xml ] - No schema information is available for
containers/{container}.PUT response.  Please specify a schema.

c. ツールチップに表示される修正処理を実行します。構成が正常に完了すると、「操作バインディング」セクションの「完了」列のすべての操作に「はい」の値が表示されます。
SOAデザインタイムMDSリポジトリの詳細は、「デザインタイムMDSリポジトリとの共有データの管理」を参照してください。

36.2.4 ショートカットからRESTアダプタを構成する方法

RESTアダプタは、WSDLまたはWADLファイルに基づくいくつかのショートカットを使用して構成できます。

36.2.4.1 アプリケーション・サーバーにデプロイされたWebサービスに基づいてRESTサービスを生成する手順:

1. Oracle JDeveloperメイン・メニューから、「ウィンドウ」→「アプリケーション・サーバー」を選択します。

2. WSDLサービスを右クリックして、「SOA」→「RESTとして公開」を選択します。図36-6に詳細を示します。

図36-6 自動RESTアダプタ・サービス・バインディング・コンポーネントの構成

「RESTバインディングの作成」ダイアログが起動し、選択されたWSDLファイルから操作マッピングが移入されます。

3. 「RESTアダプタをSOAコンポジット・アプリケーションのサービス・バインディング・コンポーネントとして構成する方法」の手順を実行して、必要な構成をすべて完了します。

注意:

選択したWSDLとその依存アーティファクトのローカル・コピーを作成するよう求められます。ローカル・コピーの作成を選択すると、SOAP参照バインディング・コンポーネントのbinding.wsセクションに、選択元の具体WSDL/エンドポイントの場所と、抽象WSDLとして(コンポジットのインポートなどで)使用されるコピー先のWSDLが含まれます。

構成が完了すると、RESTサービス・バインディング・コンポーネントがSOAP参照バインディング・コンポーネントに接続されます。図36-7に詳細を示します。

図36-7 RESTサービス・バインディング・コンポーネントおよびSOAP参照バインディング・コンポーネントの構成

36.2.4.2 アプリケーション・サーバーにデプロイされたRESTサービスに基づいてREST参照を生成する手順:

1. Oracle JDeveloperメイン・メニューから、「ウィンドウ」→「アプリケーション・サーバー」を選択します。

2. REST/WADLサービスを右クリックして、「SOA」→「REST参照の生成」を選択します。図36-8に詳細を示します。

図36-8 自動RESTアダプタ参照バインディング・コンポーネントの構成

「RESTバインディングの作成」ダイアログが起動し、選択したWADLファイルからの情報が移入されます。

3. 「RESTアダプタをSOAコンポジット・アプリケーションの参照バインディング・コンポーネントとして構成する方法」の手順を実行して、必要な構成をすべて完了します。
構成が完了すると、図36-9 のようにREST参照バインディング・コンポーネントが表示されます。

図36-9 RESTアダプタ参照コンポーネント

36.2.4.3 SOAコンポーネントのWSDLサービスに基づいてRESTサービスを生成する手順:

1. SOAコンポジット・エディタで、SOAコンポーネント・サービスまたは外部参照を右クリックして、「RESTとして公開」オプションを選択します。図36-10に詳細を示します。

図36-10 「RESTとして公開」オプション

「RESTバインディングの作成」ダイアログが起動し、選択したWADLファイルからの情報が移入されます。

2. 必要なRESTアダプタ構成をすべて完了します。
構成が完了すると、RESTサポート(この例ではサービス・バインディング・コンポーネント)が作成され、クリックしたインタフェースに自動的に接続されます。図36-11に詳細を示します。

図36-11 RESTアダプタ・サービス・バインディング・コンポーネント

36.2.5 スキーマを手動で生成する方法

スキーマ生成のためのスキーマまたはサンプル・データがない場合は、スキーマ生成のためのパラメータを手動で入力できます。スキーマを手動で定義するには、「追加」アイコンをクリックし、「RESTバインディングの作成」ダイアログの「操作バインディング」セクションで「操作バインディングの追加」を選択します。

次のガイドラインに留意してください。

- 「REST操作バインディング」ページの「URIパラメータ」セクションで、必要な問合せまたはテンプレート・パラメータを入力します。各パラメータにデータ・タイプを選択できますが、式を入力する必要はありません。スキーマやペイロードが指定されていない場合、「OK」をクリックすると、パラメータ・スキーマが自動的に生成されます(WSDLに埋め込まれます)。ランタイム・プロパティにマッピングされた式を持つパラメータは、生成されたスキーマには含まれません。

- スキーマが操作に対して定義されていない場合、「式」列からアクセス可能な「式ビルダー」ダイアログにのみ、プロパティ変数が表示され、メッセージ変数は表示されません。

RESTサポート作成の詳細は、「RESTアダプタをSOAコンポジット・アプリケーションのサービス・バインディング・コンポーネントとして構成する方法」および「RESTアダプタをSOAコンポジット・アプリケーションの参照バインディング・コンポーネントとして構成する方法」を参照してください。

36.2.6 サンプルからのスキーマの生成方法

スキーマは、JSON interchangeフォーマットを含むサンプル・ファイルから生成できます。

1. 「REST操作バインディング」ダイアログの「リクエスト」セクションで、「スキーマURL」フィールドの右にある「ネイティブ・フォーマットのスキーマの定義」アイコンをクリックします。図36-12に詳細を示します。

図36-12 「ネイティブ・フォーマットのスキーマの定義」アイコン

ネイティブ・フォーマット・ビルダー・ウィザードが表示されます。

2. 「タイプの選択」ページが表示されるまで、ウィザードの最初のページを進みます。

このページでは、各種のフォーマット・タイプからスキーマを生成することを選択できます。図36-13に詳細を示します。

図36-13 スキーマを生成するタイプ

3. 適切なタイプを選択します。

タイプにはそれぞれ、JSON、XMLまたはURLサンプルを貼り付けるか、インポートするサンプル・ファイルを選択する領域があります。

JSON interchangeフォーマットの詳細は、「JSON InterchangeフォーマットからRESTスキーマへの変換に関する必知事項」を参照してください。

RESTサポート作成の詳細は、「RESTアダプタをSOAコンポジット・アプリケーションのサービス・バインディング・コンポーネントとして構成する方法」および「RESTアダプタをSOAコンポジット・アプリケーションの参照バインディング・コンポーネントとして構成する方法」を参照してください。

36.2.7 グローバル・トークン変数の使用方法

「RESTバインディングの作成」ダイアログの「ベースURI」フィールドで、ホスト名、ポート番号およびプロトコルのグローバル・トークン変数の割当てができます。

グローバル・トークン変数を使用する手順は次のとおりです。

1. 「SOAコンポジット・エディタ」の上で、「バインディングURLのトークン化機能」アイコンをクリックします。

2. REST外部参照を選択し、「編集」アイコンをクリックします。

3. mdm-url-resolver.xmlファイルを指定するか、ホスト、ポートおよびプロトコル(httpまたはhttps)の値を手動で入力し、「OK」をクリックします。

その後、トークンに割り当てられた値によって、composite.xmlファイルのbinding.ws要素のlocation属性内のハードコードされたHTTPホストおよびポート値が置き換えられます。詳細は、「外部参照のバインディングURLで使用するためのトークンの作成」を参照してください。

36.2.8 RESTヘッダーのプロパティの設定方法

正規化されたメッセージ・プロパティは、特定の標準HTTPヘッダーで使用できます。これらのプロパティは、図36-14 に示すOracle JDeveloperのBPELのreceiveアクティビティおよびreplyアクティビティの「プロパティ」タブの選択項目に表示されます。これらのヘッダー・プロパティは、デフォルトではサービス・エンジン全体に伝播されません。これらは、適切な割当てロジックを適用することよって手動で伝播する必要があります。

図36-14 receiveおよびreplyアクティビティでの正規化されたメッセージのプロパティ

36.2.8.1 インバウンドおよびアウトバウンド・ヘッダー

外部クライアントがSOA RESTサービスと対話するインバウンドの場合、次にクライアントが対話するリソースへのハイパーリンクを送信するためのサービス構成できます。このハイパーリンクは、リソースまたはHTTPリンクのレスポンス・ヘッダーのペイロードで送信できます。次の正規化メッセージ・プロパティが作成され、次のリンクが返されます。

- rest.binding.requestBaseURI
このプロパティは、リクエスト・メッセージ上で使用できます。RESTサービスのベースURIを保持します。SOAコンポジット・アプリケーションで、これを同じRESTサービスの別のリソースのパスに結合して、そのリソースに戻る絶対URLを作成できます。

- rest.binding.http.Link
このプロパティがレスポンス・メッセージで設定されると、リンク・ヘッダーがHTTPレスポンスに追加されます。このヘッダーの値は、正規化されたメッセージ・プロパティの値です。

SOAコンポジット・アプリケーションが外部RESTサービスを起動するアウトバウンドの場合、サービスによってリンク・ヘッダーまたはペイロードのいずれかにある次のリンクが含まれたレスポンスが返されることがあります。次の正規化されたメッセージ・プロパティは、次のリンクを取得し、そのリンクにあるリソースを起動するために使用できます。

- rest.binding.http.Link
外部RESTサービスからのHTTPレスポンスにリンク・ヘッダーが含まれている場合、rest.binding.http.Linkプロパティがそのレスポンス・メッセージに追加されます。このプロパティの値は、リンク・ヘッダーの値です。

- rest.binding.requestURI
次のリンクにあるリソースは、リクエスト・メッセージでrest.binding.requestURIプロパティを設定することで起動できます。設定した場合、このプロパティのURLが、設計時に指定されたURLをオーバーライドします。これは、外部RESTサービスを起動します。

SOAコンポジット・アプリケーションが、外部RESTサービスから受信した次のリンクに基づいてRESTリソースを起動するときに、満たす必要のある事前条件がいくつかあります。

- 起動される可能性のあるリソースは、設計時にREST参照バインディング・コンポーネントで設計されている必要があります。

- リクエストおよびレスポンスの構造は、既知のものであり、設計時にモデル化されている必要があります。

「プロパティ」タブの正規化されたメッセージ・プロパティの設定の詳細は、「メッセージ・ヘッダーを介した正規化メッセージ・プロパティの伝播」を参照してください。

36.2.8.2 カスタム・ヘッダー・サポート

RESTサービスおよび参照は、カスタムHTTPヘッダーを処理できます。表36-5に詳細を示します。

表36-5 カスタム・ヘッダー・サポート

方向

サービス側

参照側

リクエスト

リクエストに含まれるHTTPヘッダーは、正規化されたメッセージ・プロパティとして伝播されます。ヘッダーにはrest.binding.http.header-nameが付加されます。これらのヘッダーは、正規化されたメッセージ・プロパティの一部として、サービス・エンジンで使用できます。たとえば、個々のヘッダーは、receiveアクティビティおよびreplyアクティビティのプロパティにあるBPELプロセスで取得できます。

rest.binding.http.*が先頭に付いたすべての正規化されたメッセージ・プロパティは、HTTPヘッダーとしてHTTPリクエストに追加されます。ヘッダーをHTTPリクエストに添付する前に、RESTサービスによって、ヘッダー名から接頭辞rest.binding.http.が削除されます。

レスポンス

rest.binding.http.*が先頭に付いたすべての正規化されたメッセージ・プロパティは、HTTPヘッダーとしてHTTPレスポンスに追加されます。ヘッダーをHTTPレスポンスに添付する前に、RESTサービスによって、ヘッダー名から接頭辞rest.binding.http.が削除されます。

レスポンスで受信するHTTPヘッダーは、正規化されたメッセージ・プロパティとして伝播されます。ヘッダーにはrest.binding.http.header-nameが付加されます。これらのヘッダーは、正規化されたメッセージ・プロパティの一部として、サービス・エンジンで使用できます。たとえば、個々のヘッダーは、receiveアクティビティおよびreplyアクティビティのプロパティにあるBPELプロセスで取得できます。

36.2.9 RESTフォルト・バインディングに関する必知事項

図36-15 に示すとおり、「RESTフォルト・バインディング」ダイアログでRESTフォルト・バインディング・レスポンスの詳細を定義します。フォルトの詳細がWSDLファイルで定義される場合は、「RESTフォルト・バインディング」ダイアログの「フォルト・バインディング」セクションにフォルト・バインディングが自動的に作成されます。フォルト・バインディングは、「フォルト・バインディング」セクションの「フォルト・バインディングの追加」アイコンをクリックすることで、手動でも定義できます。

図36-15 「RESTフォルト・バインディング」ダイアログ

デフォルトでフォルト・ステータスは、フォルト・ペイロードがある場合は400で、フォルト・ペイロードがない場合は404です。

フォルト・バインディングの詳細は、「RESTバインディングの作成」ダイアログでの選択内容によって異なります。

- 「RESTコンポーネントや参照の有効化」を選択した場合、フォルト・バインディングは、WSDLファイルで定義されているフォルトに基づいて自動的に生成されます。

- 「操作バインディングの追加」を選択した場合は、サポートされるフォルト・バインディングを構成する必要があり、これは生成されるWSDLに追加されます。

「REST操作バインディング」ダイアログの「フォルト・バインディング」セクションには、レスポンス・フォルト名、タイプ、ステータスおよびスキーマが表示されます。図36-16に詳細を示します。

図36-16 フォルト・バインディングの定義

36.2.10 JSON InterchangeフォーマットからRESTスキーマへの変換に関する必知事項

RESTスキーマは、ネイティブ・フォーマット・ビルダー・ウィザードの「タイプの選択」ダイアログで、JSON Interchangeフォーマット・サンプルから作成することを選択できます(図36-13 を参照)。スキーマの生成中、このウィザードは次のことを試行します。

- ネームスペース情報のないRESTスキーマを生成します。

- ネームスペース情報のないJSON Interchangeフォーマット・サンプルを消費し、適切なネームスペースを持つXMLを生成します。

ただし、変換を処理できない場合もあります。

- ネームスペース情報が保持され、次の例に示すJSON Interchangeフォーマット・サンプルの変換が可能になります。これは、基礎となるスキーマに複数のネームスペースからの要素および属性があるためです。

<schema xmlns:us="http://xmlns.oracle.com/addresses/us"
xmlns:india="http://xmlns.oracle.com/addresses/india"
targetNamespace="http://xmlns.oracle.com"
xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<import ...>
<element name="Person">
<complexType>
<choice>
<element ref="us:Address"/>
<element ref="india:Address"/>
</choice>
</complexType>
</element>
</schema>
<schema targetNamespace="http://xmlns.oracle.com/addresses/us"
xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<element name="Address">
<complexType>
<sequence>
<element name="Street" type="xsd:string"/>
<element name="City" type="xsd:string"/>
<element name="State" type="xsd:string"/>
<element name="ZipCode" type="xsd:integer" minOccurs="0"/>
</sequence>
</complexType>
</element>
</schema>
<schema targetNamespace="http://xmlns.oracle.com/addresses/india"
xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<element name="Address">
<complexType>
<sequence>
<element name="Street" type="xsd:string"/>
<element name="City" type="xsd:string"/>
<element name="District" type="xsd:string" minOccurs="0"/>
<element name="State" type="xsd:string"/>
<element name="PinCode" type="xsd:integer" minOccurs="0"/>
</sequence>
</complexType>
</element>
</schema>

- 連続したグループ要素の下にある、名前が重複した兄弟要素は変換できません。これはJSONではキーが重複したオブジェクトに変換されてしまい、こうしたオブジェクトは無効であるためです。

36.2.11 同一ノード内でRESTサービスをコールするREST参照に関する必知事項

SOAIncomingRequests_maxThreadsプロパティは、デフォルトでは、Oracle WebLogic Server管理コンソールのSOADataSourceデータ・ソースに基づいて構成されています。この設定は、負荷が高いRESTサービス(たとえば、同じノード内でREST参照がRESTサービスをコールするシナリオで200の同時ユーザーがいる場合など)では十分でない場合があります。SOAIncomingRequests_maxThreads値を400に増やして、次の例に示す例外エラーを防ぐ必要があります。

<May 2, 2014 10:16:11 AM PDT> <Error> <oracle.soa.bpel.system> <BEA-000000>
<cube engineJTA transaction is not in active state.
The transaction became inactive when executing activity "" for instance
"30,023", bpel engine can not proceed further without an active transaction.
please debug the invoked subsystem on why the transaction is not in active
status. the transaction status is "MARKED_ROLLBACK".
The reason was The execution of this instance "30023" for process
"BuyCoffeeBPELProcess" is supposed to be in an active jta transaction, the
current transaction status is "MARKED_ROLLBACK", the underlying exception is
"Service Unavailable" .
Consult the system administrator regarding this error.
, Cikey=30023, FlowId=20014, Current Activity Key=30023-BpInv0-BpSeq0.3-3,
Current Activity Label=InvokeCreateOrder,
ComponentDN=default/CoffeeShopClient!1.0*soa_19d4a881-115b-42c5-824d-1af3fa766
62d/BuyCoffeeBPELProcess
oracle.fabric.common.FabricInvocationException: Service Unavailable
at
. . .
. . .

36.3 BPELコンポーネントでのJavaScriptおよびJSONの使用

BPELコンポーネントは、XML変数およびJSON変数の両方とともに使用できます。JavaScriptは、XPath式を使用できるすべての箇所で使用できます。JavaScriptは述部、式およびJavaScript BPELアクティビティ内で使用できます。

JSON変数の使用

既存のRESTサービスに基づいてBPELプロセスを作成し、RESTサービスからメソッドを追加することを選択できます。これは、次の図に示されています。

入力ペイロード・データを受信するためにJSONオブジェクト変数を使用するように、BPELプロセスのReceiveアクティビティが自動的に構成されます。

必要に応じて、BPELプロセスに追加のスキーマレスJSON変数を作成できます。

BPELプロセスの式言語の設定

BPELデザイナで、BPELプロセス領域の空白の領域を右クリックします。「プロセスの編集」ダイアログが表示されます。必要に応じて、問合せ言語と式言語を設定します。JavaScriptを使用するためにjsを使用できます。

JavaScript式の使用

JavaScriptは、XPath式を使用できるすべての箇所で使用できます。これらの式は、BPELアクティビティおよび条件付きおよび反復コンストラクトで使用できます。この項では、いくつかの例を示します。

次の例は、Assertアクティビティで使用されるJavaScript式を示しています。式では、プロセス入力のタイプがオブジェクトかどうかが確認されます。

process変数は、実行中にJavaScriptコンテキストがアクセス可能なグローバル変数です。

次のコードは、Whileアクティビティで使用される可能性のあるJavaScript条件を示しています。

process.counter < 10

次のコードは、Waitアクティビティに表示される可能性のあるJavaScript式を示しています。

bpel.until(process.counter + 3)

次のコードは、Switchアクティビティの分岐に表示され、奇数のテストに役立つJavaScript式を示しています。

process.counter % 2 == 1

JavaScriptアクティビティの使用

BPELプロセスでJavaScriptアクティビティを使用して、JavaScriptコード・スニペットまたはコード・ブロックを追加できます。JavaScriptアクティビティを追加するには、「コンポーネント」ウィンドウからBPELプロセスの適切な場所にJavaScriptアイコンをドラッグします。追加したJavaScriptアクティビティをダブルクリックして編集できます。次の図は、xpathおよびbpelオブジェクト関数を呼び出すJavaScriptコードを示しています。

xpathは、すべてのXPath関数にバインドするグローバル・オブジェクトです。このため、たとえば、var o = process.output.xpathでは新しいxpathオブジェクトが作成され、o.refid = xpath.ora.getECID()ではoraネームスペース・プリフィクスのgetECID関数が呼び出されます。

次のJavaScriptコードはJavaScriptアクティビティに表示され、サーバー・コンソールおよびBPEL監査ログに出力を書き込みます。

console.log("input: ", process.input)
console.log("output: ", process.output)
audit.log("output: ", process.output)

BPELプロセスへのJavaScriptファイルのインポート

JavaScript関数を含む外部JavaScriptファイルを、BPELプロセスにインポートできます。これらのファイルに含まれるJavaScript関数が、BPELプロセス内で使用可能になります。次の行では、importおよびinclude文を使用してmain.jsおよびone.jsファイルをBPELプロセスにフェッチしています。

<bpelx:js include="jslib/main.js"/>
<bpelx:js import="jslib/one.js"/>

includeとimportの違いは、import文では、インポート回数に関係なくファイルが含められるのは1回のみである点です。

次の図は、 include/import文を含むBPELプロセスのソース・ウィンドウを示しています。JavaScriptファイルがプロジェクト・フォルダの下に表示される場所に注意してください。

36.4 HTTPアナライザによるRESTアダプタのテスト

HTTPアナライザを使用してRESTアダプタをテストできます。

HTTPアナライザを使用してRESTアダプタをテストする手順は、次のとおりです。

1. 図36-17 に示すように、Oracle Enterprise Manager Fusion Middleware ControlのSOAコンポジット・アプリケーションのホームページからWADLファイルのURLをコピーします。

図36-17 Oracle Enterprise Manager Fusion Middleware ControlのWADLファイルのURL

2. HTTPアナライザで、「URLを開く」アイコンをクリックし、Oracle Enterprise Manager Fusion Middleware ControlからコピーしたWADLのURLを入力して[Return]を押します。

WADLファイルはPOSTメソッドに含まれています。図36-18に詳細を示します。

図36-18 WADLファイルおよびPOSTメソッド

3. 「テスト」をクリックします。

4. サンプル・リクエストのXMLペイロードを「リクエストHTTPヘッダー」セクションにコピー・アンド・ペーストして、「リクエストの送信」をクリックします。JSONフォーマットも指定できます。図36-19に詳細を示します。

図36-19 リクエスト・メッセージ

処理が完了すると、レスポンス・メッセージが表示されます。この例では、注文ステータスがShippedであるメッセージが表示されます。図36-20に詳細を示します。

図36-20 レスポンス・メッセージ

36.5 Oracle Enterprise Manager Fusion Middleware ControlでのREST参照のバインディング・コンポーネントのテストおよび構成

RESTバインディング・コンポーネントを含むSOAコンポジット・アプリケーションのインスタンスは、Oracle Enterprise Manager Fusion Middleware Controlの「テスト・インスタンス」ページから開始できます。このページでは、任意のWSDLまたはWADLをテストできます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAコンポジット・アプリケーションのテスト・インスタンスの起動に関する説明を参照してください。

Oracle Enterprise Manager Fusion Middleware ControlでREST参照のバインディング・コンポーネントのプロパティを構成できます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のRESTアダプタのプロパティの構成に関する説明を参照してください。

37 Enterprise JavaBeansとコンポジット・アプリケーションの統合

この章では、Javaインタフェースまたはサービス・データ・オブジェクト(SDO)のパラメータを使用してEnterprise JavaBeansをSOAコンポジット・アプリケーションに統合する方法について説明します。ここでは、SDOベースのEnterprise JavaBeansアプリケーションの設計、Oracle JDeveloperでのEnterprise JavaBeansサービスの作成、Oracle SOA Suiteを起動するためのEnterprise JavaBeansクライアントの設計、Enterprise JavaBeansロールの指定およびJNDIアクセスを行う方法について説明します。

この章の内容は次のとおりです。

- Enterprise JavaBeansバインディングとSOAコンポジット・アプリケーションの統合の概要

- SDOベースのEnterprise JavaBeansアプリケーションの設計

- Oracle JDeveloperでのEnterprise JavaBeansサービスの作成

- Oracle SOA Suiteを起動するEnterprise JavaBeansクライアントの設計

- Enterprise JavaBeansロールの指定

- 資格証明ストア・フレームワークでのEnterprise JavaBeansバインディングのサポートの構成

注意:

Enterprise JavaBeans 3.0およびEnterprise JavaBeans 2.0の参照(つまり、Enterprise JavaBeans 2.0 Beanをコールする場合)はサポートされています。ただし、Enterprise JavaBeans 2.0のサービス(つまり、Enterprise JavaBeans 2.0 Beanを使用してコールされる場合)はサポートされていません。

37.1 Enterprise JavaBeansバインディングとSOAコンポジット・アプリケーションの統合の概要

Enterprise JavaBeansとSOAコンポジット・アプリケーションの統合方法には、次の2つのオプションがあります。

- Javaインタフェースを使用する方法(インタフェースの定義にWSDLファイルを使用しない)

- SDOベースのEJBを使用する方法(インタフェースの定義にWSDLファイルを使用する)

この章では、両方のオプションについて説明します。

JavaインタフェースとSOAコンポジット・アプリケーションの統合には、Springサービス・コンポーネントも使用できます。Springサービス・コンポーネントの使用方法の詳細は、「Spring Frameworkを使用したSOAコンポジット・アプリケーションへの統合」を参照してください。

37.1.1 Javaインタフェースを使用した統合

Enterprise JavaBeansとOracle SOA Suiteの統合にはJavaインタフェースを使用できるため、WSDLファイルの定義は不要です。このタイプの統合は、次のオブジェクトをサポートします。

- ネイティブJavaオブジェクト

- Java Architecture for XML Binding

JavaインタフェースはSDOインタフェースとは異なります。SDOインタフェースは、XMLが中心のサービス・コンポーネント(Oracle BPEL Process Manager、Oracle Mediatorなど)を対象としているため、WSDLファイルに定義されます。Javaインタフェースを使用する場合、SDOパラメータは不要です。

この統合を定義するには、「Javaインタフェース・ベースのEnterprise JavaBeansとSOAコンポジット・アプリケーションの統合方法」で説明するように、Oracle JDeveloperの「EJBサービスの作成」ダイアログを使用します。このオプションでは、WSDLファイルを使用する必要はありません。完了すると、次の例に示すように、相互作用がinterface.javaエントリを介してcomposite.xmlファイルに定義されます。Javaインタフェース・クラスは、接続コンポーネントが使用するWSDLファイルと互換性がある必要があります(つまり、メッセージがBPELコンポーネントに送信される場合)。BPELサービスはWSDLによって定義されるため、Javaインタフェース・クラスにはそのWSDLとの互換性が必要です。

<service name="PortfolioService">
<interface.java interface="com.bigbank.services.MyService" />
binding.ejb uri="MyJNDI" ejb-version="EJB3"/>

Javaクラスは、ユーザー・インタフェースに使用できるプロジェクトのローダー内にある必要があります。このクラスは、デプロイされるSCA-INF内にある必要があります(プロジェクト・クラスパス内のすべてのJARファイルがデプロイされるわけではありません)。これは通常、クラスがSCA-INF/classesディレクトリ内、またはSCA-INF/libディレクトリのJAR内にある必要があることを意味します。ただし、システム・クラスパスのインタフェースも使用できます。

JAXBの詳細は、『Oracle TopLinkソリューション・ガイド』および「Spring Frameworkを使用したSOAコンポジット・アプリケーションへの統合」を参照してください。

37.1.2 SDOベースのEJBを使用した統合

SDOを使用すると、物理的にどのようにアクセスされているかに関係なくビジネス・データを修正できます。SOAコンポジット・アプリケーションでSDOを使用する場合、特定のバックエンド・データ・ソースへのアクセス方法についての知識は不要です。つまり、静的または動的なプログラミング・スタイルを使用して、接続および切断されたアクセスを取得できます。

Enterprise JavaBeansは、Javaでエンタープライズ・アプリケーションを作成するためのコンポーネントベースの標準アーキテクチャに適合する、サーバー側ドメイン・オブジェクトです。これらのオブジェクトは、分散化されたセキュアなトランザクション・コンポーネントになります。

多くのOracle SOA Suiteインタフェースは、WSDLファイルで記述されます。Enterprise JavaBeansインタフェースは、Javaインタフェースで記述されます。両者の間の起動は、Oracle SOA SuiteのWSDLインタフェースに対応するEnterprise JavaBeansのJavaインタフェースによって、Oracle SOA Suiteで可能になります。

このインタフェースを介して、Oracle SOA Suiteは次の機能をサポートします。

- Enterprise JavaBeans参照バインディング・コンポーネントを介した、SDOパラメータによるEnterprise JavaBeansの起動。このシナリオでは、SOAコンポジット・アプリケーションが外部のEnterprise JavaBeansアプリケーションにSDOパラメータを渡します。

- Enterprise JavaBeansを介した、SDOパラメータによるEnterprise JavaBeansサービス・バインディング・コンポーネントの起動。このシナリオでは、Enterprise JavaBeansアプリケーションがSOAコンポジット・アプリケーションにSDOパラメータを渡します。

図37-1 に概要を示します。

図37-1 SDOおよびEnterprise JavaBeansバインディングの統合

この統合を定義するには、「SDOベースのEnterprise JavaBeansとSOAコンポジット・アプリケーションの統合方法」で説明するように、Oracle JDeveloperの「EJBサービスの作成」ダイアログを使用します。このオプションでは、WSDLファイルを使用する必要があります。完了すると、次の例に示すように、WSDL相互作用がinterface.wsdlエントリを介してcomposite.xmlファイルに定義されます。

<service name="PortfolioService">
<interface.wsdl
interface="http://bigbank.com/#wsdl.interface(PortfolioService)" />
<binding.ejb javaInterface="java.class.ejb.com" serviceId="PortfolioService"
jarLocation="soaejb.jar"/>

37.2 SDOベースのEnterprise JavaBeansアプリケーションの設計

この項では、Enterprise JavaBeansアプリケーション設計手順の高レベルな概要を示します。詳細は、次のドキュメントを参照してください。

- Oracle WebLogic Server Enterprise JavaBeansの開発

- Oracle Application Development FrameworkによるFusion Webアプリケーションの開発

- Oracle JDeveloperオンライン・ヘルプ目次にある次のトピック

- Enterprise JavaBeans

- Enterprise JavaBeansおよびJava永続性API (JPA)のSDO

ヘルプにアクセスするには、Oracle JDeveloperで「ヘルプ」→「目次」の順に選択します。

37.2.1 SDOコンパイラを使用したSDOオブジェクトの作成方法

SDOオブジェクトを作成するには、次のいずれかのオプションを選択します。

- EclipseLinkは、Java開発者用のオープン・ソースのオブジェクト・リレーショナル・マッピング・パッケージです。EclipseLinkには、Javaオブジェクトをリレーショナル・データベースに格納したり、JavaオブジェクトをXML文書に変換するためのフレームワークが備わっています。
EclipseLinkを使用してSDOオブジェクトを作成します。EclipseLinkをインストール、構成および使用してSDOオブジェクトを作成する方法の手順は、次のURLを参照してください。

http://wiki.eclipse.org/EclipseLink/Installing_and_Configuring_EclipseLink

- Oracle JDeveloperでは、JPAエンティティに対するSDOサービス・インタフェースを作成できます。この機能は、SOAコンポジット・アプリケーションのOracle Application Development Framework (ADF)サービス・バインディングで使用する場合により適していますが、SOAコンポジット・アプリケーションのEnterprise JavaBeansサービス・バインディングでもこの機能を使用できます。SDOサービス・インタフェース機能では、必要なWSDLおよびXSDファイルが生成されます。この機能を使用する場合、Enterprise JavaBeansサービス・バインディングを処理するには、次のタスクを実行する必要があります。

- 「WSDLチューザ」ダイアログでこのWSDLファイルを参照して選択しますが、このダイアログには、「EJBサービスの作成」ダイアログの「WSDL URL」フィールドからアクセスできます(「Oracle JDeveloperでのEnterprise JavaBeansサービスの作成」を参照)。

- 「BC4Jサービス・ランタイム」ライブラリをSOAプロジェクトに追加します。このライブラリを追加するには、プロジェクトをダブルクリックし、「プロジェクト・プロパティ」ダイアログで「ライブラリとクラスパス」を選択してライブラリを追加します。これで、ビジネス・ロジックを設計できる状態になります。

詳細は、Oracle JDeveloperオンライン・ヘルプのEnterprise JavaBeans/JPA用のSDOに関するトピックを参照してください(SDOサービス・インタフェースの作成方法の手順も含まれています)。

37.2.2 セッションBeanを作成してSDOオブジェクトをインポートする方法

セッションBeanを作成してSDOオブジェクトをインポートする手順は、次のとおりです。

1. 「セッションBean作成」ウィザードを使用して、単純なセッションBeanを作成します。このウィザードの使用方法の詳細は、Oracle JDeveloperオンライン・ヘルプのセッションBeanの作成に関するトピックを参照してください。

2. 「プロジェクト・プロパティ」ダイアログで、SDOオブジェクトをプロジェクトにインポートします。

3. ロジックおよび必要なインポート・ファイルとライブラリ・ファイルを追加します。特に、Commonj.sdo.jarファイルをインポートする必要があります。JARファイルは、「ライブラリとクラスパス」ダイアログで追加できます。このダイアログにアクセスするには、プロジェクトをダブルクリックし、「プロジェクト・プロパティ」ダイアログで「ライブラリとクラスパス」を選択します。これで、ロジックを設計できる状態になります。

4. メソッドをリモート・インタフェースに公開します。

37.2.3 プロファイルおよびEARファイルの作成方法

プロファイルおよびEARファイルを作成する手順は、次のとおりです。

1. 「プロジェクト・プロパティ」ダイアログで、Enterprise JavaBeansのJARプロファイルを作成します。

2. 「アプリケーション・プロパティ」ダイアログで、アプリケーション・レベルのEARファイルを作成します。

37.2.4 Enterprise JavaBeans Beanを使用したSDOタイプの定義方法

Enterprise JavaBeans BeanでSDOタイプを定義する必要があります。次の例で詳細を示します。

注意:

defineをコールする場所が重要な場合があります。Remote Method Invocation (RMI)マーシャリングが必要になる前に、適切なヘルパー・コンテキストにタイプを定義する必要があります。EclipseLink SDO実装によって、アプリケーション名またはクラス・ローダーでヘルパー・インスタンスに索引付けされます。

Enterprise JavaBeansメソッドを起動したときに、EclipseLink SDOランタイムでアプリケーション名を使用できるようになります。EclipseLink SDOは、キーとしてアプリケーション名を使用してコンテキストを検索します。アプリケーション名が参照可能な場合は、タイプを必ず定義してください。Enterprise JavaBeansの静的ブロックの初期化時に、アプリケーション名は作成されません。したがって、静的ブロックにdefineを配置すると、デフォルトのアプリケーション名ベースのコンテキストを使用している場合は機能しません。アプリケーション名を初期化する方法の1つは、weblogic-ejb-jar.xmlファイルを使用して、3つ以上のインスタンスBeanを割り当てることです。

InputStreamReader reader = new InputStreamReader(url.openStream());
StreamSource source = new StreamSource(reader);
List<SDOType> list = ((SDOXSDHelper) XSDHelper.INSTANCE).define(source, null);

weblogic-ejb-jar.xmlファイルは、デプロイメントjarに追加する必要があるディスクリプタ・ファイルです。weblogic-ejb-jar.xmlファイルは、セッションBeanを作成すると自動的に作成されます。このファイルは、次の例に示すエントリを追加して変更する必要があります。

<?xml version = '1.0' encoding = 'windows-1252'?>
<weblogic-ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-ejb-jar
http://www.bea.com/ns/weblogic/weblogic-ejb-jar/1.0/weblogic-ejb-jar.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-ejb-jar">

<weblogic-enterprise-bean>
<ejb-name>HelloEJB</ejb-name>
<stateless-session-descriptor>
<pool>
<initial-beans-in-free-pool>2</initial-beans-in-free-pool>
</pool>
</stateless-session-descriptor>
</weblogic-enterprise-bean>

</weblogic-ejb-jar>

図37-2 に、SDOロジックが定義されているセッションBeanのコード例を示します。

図37-2 SDOロジックが定義されているセッションBean

37.2.5 Webサービス注釈の使用方法

WSDLファイルを生成するには、Enterprise JavaBeansインタフェースで次のWebサービス注釈を使用する必要があります。これらの注釈の使用については、『JSR 224: Java API for XML-Based Web Services (JAX-WS) 2.0』で説明されています。詳細は、次のURLを参照してください。

http://www.jcp.org/en/jsr/detail?id=224

また、Enterprise JavaBeansバインディング・レイヤーで現在サポートされているのは、ドキュメント/リテラルWSDLのみです。

表37-1 に、使用する注釈を説明します。

表37-1 注釈

名前

説明

@javax.jws.WebResult;

@javax.jws.WebParam;

Webサービス・メッセージ・パートおよびXML要素に対する個々のパラメータのマッピングをカスタマイズします。正規化されたメッセージ・ペイロードからの適切なXML要素にSDOパラメータをマップするために、両方の注釈が使用されます。

@javax.jws.Oneway;

メソッドを、入力メッセージのみで出力メッセージのない一方向のWebサービス操作として指定します。この場合、Enterprise JavaBeansバインディング・コンポーネントは、リプライを想定しません。

@javax.xml.ws.RequestWrapper;

@javax.xml.ws.ResponseWrapper;

Enterprise JavaBeansバインディング・コンポーネントに対して、デシリアライズ・オブジェクトをアンラップするかどうか、またはシリアル化の前にラッパーを作成する必要があるかどうかを指示します。

Enterprise JavaBeansインタフェースは、既存のWSDLから生成するか、または他の手段で取得できます。WSDLが存在しない場合は生成できます。

@javax.xml.ws.WebFault;

WSDLフォルトをJava例外にマップします。この注釈は、WSDLフォルト・メッセージで参照するグローバル要素から生成される、JAXBタイプのマーシャリング時に使用されるフォルト要素名を取得します。

@oracle.webservices.PortableWebService

WSDLに使用するtargetNamespaceおよびserviceNameを指定します。次に例を示します。

@PortableWebService(
targetNamespace = "http://hello.demo.oracle/",
serviceName = "HelloService")

serviceNameは、WSDLファイル名として使用されます。それが注釈内に指定されていない場合、かわりにサービス・エンドポイント・インタフェース(SEI)クラス名が使用されます。

適切なメソッド・パラメータ注釈の追加

メッセージ要素およびタイプのWSDLへのマップ方法を制御します。たとえば、インタフェースがdoc/lit/bareスタイルにある場合は、メソッドに次の注釈を追加します。

@WebMethod
@SOAPBinding(parameterStyle =
SOAPBinding.ParameterStyle.BARE)

@SDODatabinding

スキーマを生成するかわりに既存のスキーマを使用するために、インタフェース・クラスに追加します。次に例を示します。

@SDODatabinding(schemaLocation = "etc/HelloService.xsd")

次の例は、注釈を使用したEnterprise JavaBeansインタフェースの例を示しています。

@Remote
@PortableWebService(targetNamespace = "http://www.example.org/customer-example",
serviceName = "CustomerSessionEJBService")
@SDODatabinding(schemaLocation = "customer.xsd")
public interface CustomerSessionEJB {
@WebMethod(operationName="createCustomer")
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@WebResult(targetNamespace = "http://www.example.org/customer-example",
partName = "parameters", name = "customer")
CustomerType createCustomer();
@WebMethod(operationName="addPhoneNumber")
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@WebResult(targetNamespace = "http://www.example.org/customer-example",
partName = "parameters", name = "customer")
CustomerType addPhoneNumber(@WebParam(targetNamespace =
"http://www.example.org/customer-example", partName = "parameters", name =
"phone-number")PhoneNumber phNumber);
}

37.2.6 Enterprise JavaBeans EARファイルのデプロイ方法

Oracle JDeveloperからEARファイルをデプロイする手順は、次のとおりです。

1. アプリケーション名の右側にあるアプリケーション・コンテキスト・メニューを選択します。

2. 「デプロイ」を選択し、EARファイルを以前に作成したアプリケーション・サーバー接続にデプロイします。

37.3 Oracle JDeveloperでのEnterprise JavaBeansサービスの作成

この項では、Oracle JDeveloperでEnterprise JavaBeans参照バインディング・コンポーネントまたはEnterprise JavaBeansサービス・バインディング・コンポーネントを作成する方法について説明します。Enterprise JavaBeansサービスを使用すると、Enterprise JavaBeansアプリケーションでOracle SOA Suiteと通信できるようになり、Oracle SOA SuiteでリモートのEnterprise JavaBeansと通信できるようになります。

この項では、次のタイプの統合を作成する方法について説明します。

- Javaインタフェースを使用した統合

- SDOインタフェースを使用した統合

37.3.1 Javaインタフェース・ベースのEnterprise JavaBeansとSOAコンポジット・アプリケーションの統合方法

Javaインタフェース・ベースのEnterprise JavaBeansとSOAコンポジット・アプリケーションの間では、次のタイプの統合を作成できます。

- SOAコンポジット・アプリケーションからのJavaインタフェース・ベースのEnterprise JavaBeansの起動

- Javaインタフェースを使用したEnterprise JavaBeansからのSOAコンポジット・アプリケーションの起動

Javaインタフェース・ベースのEnterprise JavaBeansをSOAコンポジット・アプリケーションに統合する手順は、次のとおりです。

1. SOAコンポジット・エディタでSOAコンポジット・アプリケーションに移動します。

2. 「コンポーネント」ウィンドウの「テクノロジ」セクションで、「EJB」アイコンを適切なスイムレーンにドラッグします。

- SOAコンポジット・アプリケーションからEnterprise JavaBeans参照バインディング・コンポーネントを起動するには、アイコンを「外部参照」スイムレーンにドラッグします。

- Enterprise JavaBeansサービス・バインディング・コンポーネントからSOAコンポジット・アプリケーションを起動するには、アイコンを「公開されたサービス」スイムレーンにドラッグします。

3. 「インタフェース」セクションで、「Java」をクリックします(まだ選択していない場合)。

4. 「EJBサービスの作成」ダイアログに、図37-3 で示すフィールドが表示されます。

図37-3 Javaインタフェース用の「EJBサービスの作成」

5. 表37-2 に記載されている詳細を入力します。「EJB」アイコンをドラッグしたスイムレーンに関係なく、表示されるフィールドは同じです。

表37-2 「EJBサービスの作成」ダイアログ

フィールド

値

名前

デフォルトの値をそのまま使用するか、別の名前を入力します。

タイプ

次の値が表示されます。

- このアイコンを「外部参照」スイムレーンにドラッグした場合は、「参照」と表示されます。

- このアイコンを「公開されたサービス」スイムレーンにドラッグした場合は、「サービス」と表示されます。

バージョン

サポートするEJBのバージョンをEJB2またはEJB3 (デフォルト選択)から選択します。

注意: このフィールドは、「EJBサービス」アイコンを「外部参照」スイムレーンにドラッグした場合のみ表示されます。

インタフェース

「Java」を選択します。

JNDI名

Enterprise JavaBeansのJNDI名を入力します。

Jarファイル

「検索」アイコンをクリックし、「SDOベースのEnterprise JavaBeansアプリケーションの設計」で作成したEJB JARファイルを選択します。JARチューザ・ダイアログでは、現在のプロジェクト・ディレクトリのSCA-INF/libサブディレクトリで起動されるJARファイルを検索して表示します。JARファイルには、インタフェース・クラスおよび任意のサポート対象クラスが含まれます。

注意: 現在のプロジェクトの外部にあるJARファイルを選択する場合、Oracle JDeveloperは、現在のプロジェクトのSCA-INF/libディレクトリにあるJARファイルのコピーを作成します。プロンプトが表示されたら、「OK」をクリックして承認します。

JAVAインタフェース

次のいずれかのオプションを選択します。

- 手動でJavaインタフェースを入力します。

- 「クラス・ファイルの参照」アイコンをクリックし、Javaインタフェースを選択するための「クラス・ブラウザ」ダイアログを呼び出します。
クラスは、ランタイム・クラスパスで使用できる必要があります。ランタイム・クラスパスでクラスを使用できるようにする方法がいくつかあります。その1つとして、確実にデプロイされるように設計時にクラスをSCA-INF/classesディレクトリまたはSCA-INF/libディレクトリのJARファイルに配置する方法があります。ただし、システム・クラスパスのインタフェースも使用できます。

ランタイム時にクラスを使用できるようにする方法がいくつかありますが、その1つとして、設計時にデプロイされるようにクラスまたはJARをSCA-INFに配置する方法があります。

注意: 「Jarファイル」フィールドを使用する場合、「アプリケーション」メイン・メニューから「プロジェクト・プロパティ」→「ライブラリとクラスパス」→「JAR/ディレクトリの追加」を選択して、新規JARファイルをプロジェクトに追加する必要はありません。

- 「WSDLからのJavaインタフェースの生成」アイコンをクリックして、Javaインタフェースを生成するWSDLファイルを選択します。これは、「SDOベースのEnterprise JavaBeansとSOAコンポジット・アプリケーションの統合方法」で説明したオプションと同じです。

6. 「OK」をクリックします。

37.3.2 SDOベースのEnterprise JavaBeansとSOAコンポジット・アプリケーションの統合方法

SDOベースのEnterprise JavaBeansとSOAコンポジット・アプリケーションの間では、次のタイプの統合を作成できます。

- SOAコンポジット・アプリケーションからのSDOベースのEnterprise JavaBeansの起動

- SDOパラメータを使用したEnterprise JavaBeansからのSOAコンポジット・アプリケーションの起動

SDOベースのEnterprise JavaBeansをSOAコンポジット・アプリケーションに統合する手順は、次のとおりです。

1. SOAコンポジット・エディタでSOAコンポジット・アプリケーションに移動します。

2. 「コンポーネント」ウィンドウの「テクノロジ」セクションで、「EJB」アイコンを表37-3 に示す適切なスイムレーンにドラッグします。

表37-3 EJBサービスに対するスイムレーン

起動対象

EJBサービスをドラッグするスイムレーン

SOAコンポジット・アプリケーションからのSDOベースのEnterprise JavaBeansの起動

外部参照

SDOパラメータを使用したEnterprise JavaBeansからのSOAコンポジット・アプリケーションの起動

公開されたサービス

「EJBサービスの作成」ダイアログが表示されます。

3. 「インタフェース」セクションで、「WSDL」をクリックします。

4. EJBサービスをドラッグしたスイムレーンに応じて、表37-4 に示す手順を参照してください。

表37-4 スイムレーンの場所

EJBサービスをドラッグしたスイムレーン

移動先

外部参照

44.a

公開されたサービス

44.b

a. 図37-4 に示すように、「外部参照」スイムレーンに表示される「EJBサービスの作成」ダイアログを確認します。

図37-4 「外部参照」スイムレーンの「EJBサービスの作成」

b. 図37-5 に示すように、「公開されたサービス」スイムレーンに表示される「EJBサービスの作成」ダイアログを確認します。

図37-5 「公開されたサービス」スイムレーンの「EJBサービスの作成」

5. 環境に適した値を入力します。「EJBサービス」アイコンをドラッグしたスイムレーンに応じて、表示されるフィールドが異なります。表37-5に詳細を示します。

表37-5 「EJBサービスの作成」ダイアログ

フィールド

値

名前

デフォルトの値をそのまま使用するか、別の名前を入力します。

タイプ

次の値が表示されます。

- このアイコンを「外部参照」スイムレーンにドラッグした場合は、「参照」と表示されます。

- このアイコンを「公開されたサービス」スイムレーンにドラッグした場合は、「サービス」と表示されます。

バージョン

注意: このフィールドは、「EJBサービス」アイコンを「外部参照」スイムレーンにドラッグした場合のみ表示されます。

サポートするEJBのバージョンをEJB2またはEJB3 (デフォルト選択)から選択します。「インタフェース」リストで「WSDL」を選択した場合は、「EJB3」のみを選択できます。

インタフェース

「WSDL」を選択します。

JNDI名

注意: このフィールドは、「EJBサービス」アイコンを「外部参照」スイムレーンにドラッグした場合のみ表示されます。

Enterprise JavaBeansのJNDI名を入力します。

Jarファイル

「検索」アイコンをクリックし、「SDOベースのEnterprise JavaBeansアプリケーションの設計」で作成したEJB JARファイルを選択します。JARチューザ・ダイアログでは、現在のプロジェクト・ディレクトリのSCA-INF/libサブディレクトリで起動されるJARファイルを検索して表示します。JARファイルには、インタフェース・クラスおよび任意のサポート対象クラスが含まれます。

注意: 現在のプロジェクトの外部にあるJARファイルを選択する場合、Oracle JDeveloperは、現在のプロジェクトのSCA-INF/libディレクトリにあるJARファイルのコピーを作成します。プロンプトが表示されたら、「OK」をクリックして承認します。

JAVAインタフェース

「参照」アイコンをクリックして「クラス・ブラウザ」ダイアログを起動し、以前に作成したEnterprise JavaBeansインタフェースの完全修飾Javaクラス名を選択します。このクラスは、選択したJARファイルに存在している必要があります。JARファイルを指定しない場合、クラスは現在のプロジェクト・ディレクトリの/SCA-INF/classesサブディレクトリ内にあるとみなされます。

注意: 「Jarファイル」フィールドを使用する場合、「アプリケーション」メイン・メニューから「プロジェクト・プロパティ」→「ライブラリとクラスパス」→「JAR/ディレクトリの追加」を選択して、新規JARファイルをプロジェクトに追加する必要はありません。

WSDL URL

注意: WSDLファイルの生成前に、必ず、「Webサービス注釈の使用方法」の説明に従ってEnterprise JavaBeansインタフェースの注釈を作成しておいてください。

右側にある2番目のアイコンをクリックして、Enterprise JavaBeansインタフェースを表すWSDLファイルを生成します。

「SDOコンパイラを使用したSDOオブジェクトの作成方法」の説明に従ってOracle JDeveloperでSDOオブジェクトを作成した場合は、このオプションで自動的に生成されたWSDLファイルを必ず選択してください。

ポート・タイプ

ポート・タイプを選択します。

コールバック・ポート・タイプ

コールバック・ポート・タイプを選択します(非同期サービスの場合)。

6. 「OK」をクリックします。

37.4 Oracle SOA Suiteを起動するEnterprise JavaBeansクライアントの設計

この項では、Oracle SOA Suiteを起動するEnterprise JavaBeansクライアントの設計方法について説明します。

37.4.1 Oracle SOA Suiteを起動するJavaインタフェース・ベースのクライアントの作成方法

標準のEnterprise JavaBeansクライアントを使用します。次の例に詳細を示します。

InitialContext ic = new InitialContext(jndiProps);
SimpleEjb svc = (SimpleEjb) ic.lookup("PassthroughRef");
String result = svc.addBreadCrumb("RemoteTest");

37.4.2 SDO-Enterprise JavaBeansサービスの起動方法

Enterprise JavaBeansからSDO - Enterprise JavaBeansサービスを起動するには、クライアント・ライブラリを使用する必要があります。Enterprise JavaBeansクライアントを設計するには、次のガイドラインに従ってください。

- JNDIツリーからSOAServiceInvokerBeanを検索します。

- SOAServiceFactoryのインスタンスを取得し、ファクトリにEnterprise JavaBeansサービス・インタフェースのプロキシを返すように要求します。

- クライアント側のEnterprise JavaBeansの起動ライブラリ($FMW_HOME/soa/soa/modules/oracle.soa.fabric_11.1.1/fabric-client.jarまたはOracle JDeveloperホーム・ディレクトリまたはOracle WebLogic Serverにあるfabric-runtime.jarファイル)をEnterprise JavaBeansクライアント・アプリケーションに含めることができます。たとえば、fabric-runtime.jarファイルをJDev_Home\jdeveloper\soa\modules\oracle.soa.fabric_11.1.1ディレクトリに格納できます。
Enterprise JavaBeansアプリケーションがOracle SOA Suiteと異なるJVMで実行されている場合、Enterprise JavaBeansアプリケーションは、ejbClientライブラリを参照する必要があります。次のコードは、その一例を示しています。

serviceFactory.createServiceのMyTestEJBServiceパラメータを指定してサービスIDの完全なパスを指定する必要があります(たとえば、"default/MyTestProject!1.0/MyTestEJBService")。完全なパスが指定されていない場合、EJBException- Could not locate the serviceエラーが表示されます。

Properties props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
props.put(Context.PROVIDER_URL, "t3://" + HOSTNAME + ":" + PORT);
InitialContext ctx = new InitialContext(props);
SOAServiceInvokerBean invoker =
(SOAServiceInvokerBean)
ctx.lookup("SOAServiceInvokerBean#oracle.integration.platform.blocks.sdox.ejb.api.
SOAServiceInvokerBean");

//--  Create a SOAServiceFactory instance
SOAServiceFactory serviceFactory = SOAServiceFactory.newInstance(invoker);

//--  Get a dynamice proxy that is essentially a remote reference
HelloInterface ejbRemote =
serviceFactory.createService("complete_path/MyTestEJBService", HelloInterface.class);

//--  Invoke methods
Item item = (Item) DataFactory.INSTANCE.create(Item.class);
item.setNumber(new BigInteger("32"));
SayHello sayHello = (SayHello)
DataFactory.INSTANCE.create(SayHello.class);
sayHello.setItem(item);

SayHelloResponse response = ejbRemote.sayHello(sayHello);
Item reply = response.getResult();

37.5 Enterprise JavaBeansロールの指定

Java EEアプリケーションからSOAコンポジット・アプリケーションを起動するために必要なロール名を指定するには、ロール名をEnterprise JavaBeansサービス構成に追加します。Enterprise JavaBeansサービスは、コール元のプリンシパルにセキュリティ・ロールがあるかどうかをチェックします。次の例に詳細を示します。

<service name="EJBService" ui:wsdlLocation="BPELEJBProcess.wsdl">
<interface.wsdl
interface="http://xmlns.oracle.com/EJBApplication/EJBProject/BPELEJBProcess#wsdl.int
erface(BPELProcess1)"callbackInterface="http://xmlns.oracle.com/EJBApplication/
EJBProject/BPELEJBProcess#
wsdl.interface(BPELEJBProcessCallback)"/>
<property name="rolesAllowed">Superuser, Admin</property>
<binding.ejb javaInterface="java.class.ejb.com" serviceId="EJBService"
jarLocation="soaejb.jar"/>
</service>

37.6 資格証明ストア・フレームワークでのEnterprise JavaBeansバインディングのサポートの構成

この項では、資格証明ストア・フレームワークでEnterprise JavaBeansバインディングのサポートを構成する方法について説明します。

37.6.1 資格証明ストア・フレームワークでのEnterprise JavaBeansバインディングのサポートの構成方法

すべてのEnterprise JavaBeansバインディングでは、サービス・データ・オブジェクト(SDO)のEnterprise JavaBeansバインディングのみではなく、JNDIユーザー・アクセス資格証明を格納するための資格証明ストア・フレームワーク(CSF)の使用がサポートされています。

Oracle Enterprise Manager Fusion Middleware Controlでは、Enterprise JavaBeansバインディングの次のJNDIプロパティを編集できます。

- java.naming.factory.initial

- java.naming.provider.url

- java.naming.dns.url

- java.naming.factory.url.pkgs

- java.naming.factory.url.pkgs

- java.naming.security.authentication

- java.naming.security.protocol

- java.naming.security.principal

- java.naming.security.crendentials

- oracle.jps.credstore.map

- oracle.jps.credstore.key

37.6.1.1 資格証明ストア・フレームワークでEnterprise JavaBeansバインディングのサポートを構成する手順:

これらのプロパティを編集するには、Oracle Enterprise Manager Fusion Middleware Controlで次の手順を実行します。

1. Enterprise JavaBeansバインディング・コンポーネントを含むSOAコンポジット・アプリケーションを右クリックします。

2. 「サービス/参照プロパティ」を選択します。

3. Enterprise JavaBeansバインディング・コンポーネントを選択します。

4. 「プロパティ」タブをクリックします。

5. 適切なプロパティを設定します。

37.6.1.2 oracle.jps.credstore.mapおよびoracle.jps.credstore.keyプロパティを指定する手順:

プロパティoracle.jps.credstore.mapおよびoracle.jps.credstore.keyを指定して、CSFマップにJNDIルックアップのプリンシパル/資格証明を格納することをお薦めします。プロパティとしてユーザー名/パスワードを直接格納するのはセキュアではありません。

1. Oracle Enterprise Manager Fusion Middleware Controlで、次のいずれかに移動して、「資格証明」ページを表示します。

a. (アプリケーションがOracle WebLogic Serverにデプロイされている場合)「Domain」→「セキュリティ」→「資格証明」の順に選択します。
または

b. (アプリケーションがWebSphere Application Serverにデプロイされている場合)「セル」→「セキュリティ」→「Application」→「ポリシー」の順に選択します。

2. 新規マップを追加するには、「マップの作成」を選択します。

3. マップをクリックして、oracle.jps.credstore.mapのキー・エントリを追加します。

4. 手順2および3を繰り返してoracle.jps.credstore.keyを追加します。

37.6.1.3 CSFマップ・ストアにSOAインフラストラクチャの実行時アクセスを付与する手順:

前述の手順を完了したら、CSFマップ・ストアにSOAインフラストラクチャの実行時アクセスを付与する必要があります。

1. 「WebLogic Domain」を展開します。

2. 「soa-infra」を右クリックして、「セキュリティ」→「システム・ポリシー」の順に選択します。

3. 名前fabric-runtimeを含むタイプ「コードベース」を検索します。

4. エントリを選択し、資格証明ストアのアクセス権限を追加します。

5. マップに、少なくとも読取りアクションを付与します。

38 コンポジット・サービスの起動に直接バインディングを使用

この章では、直接バインディング起動APIおよびSOAコンポジット・アプリケーションの起動方法について説明します。ここでは、インバウンド直接バインディング・サービスの作成方法、アウトバウンド直接バインディング参照の作成方法および直接バインディングを起動するJava 2 Platform Standard Edition (J2SE)クライアントのアイデンティティの設定方法について説明します。直接バインディング起動APIの使用のサンプルについても示します。

この章の内容は次のとおりです。

- 直接バインディングの概要

- 直接バインディング起動APIの概要

- 起動APIを使用したSOAコンポジット・アプリケーションの起動

- 直接バインディング起動APIの使用例

38.1 直接バインディングの概要

通常、コンポジットの起動にはSOAP over HTTPを使用します。このためには、Webサービス・バインディングを使用してコンポジットのSOAPサービスを作成する必要があります。これに対して、直接バインディングを使用すると、より緊密な統合を作成できます。Javaクライアントは、直接バインディングを使用してコンポジット・サービスを直接起動できるため、Webサービス・バインディングで必要なXMLへの中間変換が不要になります。

直接バインディングでは、次の2種類の起動スタイルがあります。

- インバウンド直接バインディング
直接サービス・バインディング・コンポーネントを使用すると、外部クライアントは直接バインディング起動APIを使用してメッセージを送信できます。この場合、直接バインディング起動APIでは、JNDI接続パラメータを使用し、クライアントにかわって接続オブジェクトが作成されます。

- アウトバウンド直接バインディング(直接参照バインディング)
直接参照バインディング・コンポーネントでは、Remote Method Invocation (RMI)を介した外部サービスへのSOAメッセージの直接送信がサポートされています。直接インバウンド起動APIと同様に、外部サービスではSOA起動APIを実装する必要があります。

直接アウトバウンド・バインディングの場合、接続オブジェクトは、バインディングに対して構成された外部サービスBeanのJNDI名を使用して作成されます。

直接バインディングは、interface句、およびcallbackInterface句(オプション)を提供するinterface.wsdlに関連付けられている必要があります。また、コンポジットには、関連するWSDLがインポートされている必要があります。

サービス・バインディング・コンポーネントは、直接バインディングを通知するWSDLの変更済バージョンも公開します。

38.1.1 直接サービス・バインディング・コンポーネント

次の例は、直接サービス・バインディング・コンポーネントを使用するサンプル構成を示しています。

<service name="direct2">
<interface.wsdl
interface="http://xmlns.oracle.com/asyncNonConvDocLit#wsdl.interface(asyncNonConvD
ocLit)"
callbackInterface="http://xmlns.oracle.com/asyncNonConvDocLit#wsdl.interface(async
NonConvDocLitCallback)" xmlns:ns="http://xmlns.oracle.com/sca/1.0"/>
<binding.direct/>
</service>

38.1.2 直接参照バインディング・コンポーネント

直接参照バインディング・コンポーネントでは、ユーザー指定のSOAインボーカに接続するために次の情報が必要です。

- プロパティ:
エンド・サービスのDirectConnectionを定義する一連のプロパティ(oracle.soa.management.facade.Locatorを参照)。

- ConnectionFactoryクラス名(oracle.soa.management.facade.Locatorを参照)。
ConnectionFactoryクラスはoracle.soa.api.invocation.DirectConnectFactoryインタフェースを実装する必要があります。

ConnectionFactoryクラス名を指定しない場合は、デフォルトのoracle.soa.api.JNDIDirectConnectionFactoryが使用されます。デフォルトのコネクション・ファクトリを使用するには、EJBのルックアップ名を指定する必要があります。

- 外部サービスで使用されるアドレス
このアドレス値は、バインディング・コンポーネントでは処理されませんが、起動時にサービスBeanに渡されます。

- addressingVersion (オプション):
デフォルトで使用されるアドレッシング・バージョンは2005/08.です。

- useSSLForCallback:
コールバックJNDI接続にSecure Socket Layer (SSL)を使用します。このフラグをtrueに設定すると、WS-AddressingのreplyToヘッダーは、サービスにSSL JNDIポートでのコールバックを指示します。

次の例にサンプルの構成を示します。

<reference name="HelloReference" ui:wsdlLocation="HelloService.wsdl">
<interface.wsdl
interface="http://hello.demo.oracle/#wsdl.interface(HelloInterface)"/>
<binding.direct connection-factory="oracle.soa.api.JNDIDirectConnectionFactory"
addressingVersion="http://www.w3.org/2005/08/addressing"
address="soadirect://syncOut"
useSSLForCallback="false">
<property
name="oracle.soa.api.invocation.direct.bean">MyDirectTestServiceBean#directEjb.Tes
tInvoker</property>
<property
name="java.naming.factory.initial">weblogic.jndi.WLInitialContextFactory</property
>
<property name="java.naming.provider.url">t3://@host:@port</property>
</binding.direct>
</reference>

直接バインディング・コンポーネントでは、同期および非同期の両方の起動パターンがサポートされています。図38-1 で同期起動パターンのサンプルを、図38-2 で非同期起動パターンのサンプルを説明します。

図38-1 同期起動パターンのサンプル

図38-2 非同期起動パターンのサンプル

38.2 直接バインディング起動APIの概要

次に、直接バインディング起動APIで使用する各種パッケージを示します。

- oracle.soa.management.facade.Locator
oracle.soa.management.facade.Locatorインタフェースは、直接接続を返すcreateConnectionメソッドを公開します。次の例に示すように、LocatorはDirectConnectionを返すためのメソッドを公開します。

import java.util.Map;
public interface DirectConnectionFactory {
DirectConnection createDirectConnection(CompositeDN compositeDN,
String serviceName) throws Exception;

次の例に示すように、LocatorFactory実装を使用してDirectConnectionを取得できます。

Hashtable jndiProps = new Hashtable();
jndiProps.put(Context.PROVIDER_URL, "t3://" + hostname + ':' + portname + "/soa-infra");
jndiProps.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
jndiProps.put(Context.SECURITY_PRINCIPAL,"weblogic");
jndiProps.put(Context.SECURITY_CREDENTIALS,"welcome1");
jndiProps.put("dedicated.connection","true");
Locator locator = LocatorFactory.createLocator(jndiProps);
CompositeDN compositedn = new CompositeDN(domainName, compositename, version);
String serviceName = "HelloEntry";
return locator.createDirectConnection(compositedn, serviceName);

- oracle.soa.api.invocation.DirectConnection
DirectConnectionインタフェースは、直接バインディングを使用してコンポジット・サービスを起動します。詳細は、インフラストラクチャ管理のためのJava APIリファレンスを参照してください。

- oracle.soa.api.message.Message
Messageインタフェースは、交換されたデータをカプセル化します。詳細は、インフラストラクチャ管理のためのJava APIリファレンスを参照してください。

38.2.1 同期直接バインディング起動

直接バインディングでは、次の例に示すメソッドを使用した同期直接起動もサポートされています。

<T> Message<T> request(String operationName, Message<T> message)
throws InvocationException, FaultException

38.2.2 非同期直接バインディング起動

非同期起動は、メッセージ・インスタンスに設定されているWS-Addressingヘッダーに依存します。すべてのヘッダーはWS-Addressing仕様に準拠している必要があります。

直接バインディング起動APIを使用すると、クライアントはWS-AddressingのReplyTo SOAPヘッダーを指定し、宛先と通信してレスポンスを受信できます。

注意:

サポートされているアドレッシング・バージョンは次のとおりです。

- http://www.w3.org/2005/08/addressing

- http://schemas.xmlsoap.org/ws/2004/08/addressing

- http://schemas.xmlsoap.org/ws/2003/03/addressing

下に、非同期起動に使用されるWS-Addressingヘッダーの例を示します。

<wsa:MessageID>D6202742-D9D9-4023-8167-EF0AB81042EC</wsa:MessageID>
<wsa:ReplyTo xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>sb://testserver:9001/callback</wsa:Address>
<wsa:ReferenceParameters>
<soa:callback xmlns:soa="http://xmlns.oracle.com/soa/direct"
connection-factory="mytest.MyDirectionConnectionFactory">
<soa:property name="oracle.soa.api.invocation.direct.bean"
value="myTest.MyDirectConnectionBean"/>
<soa:property name="java.naming.provider.url" value="t3://test:8001"/>
<soa:property name="java.naming.factory.initial"
value="weblogic.jndi.WLInitialContextFactory"/>
</soa:callback>
</wsa:ReferenceParameters>
</wsa:ReplyTo>

注意:

コールバックとそのプロパティ要素は、SOA直接ネームスペースを使用して正しく修飾する必要があります。

直接バインディング・コンポーネントは、メッセージ・インスタンスに設定されたAddressingヘッダーの解析を担当します。この例には、wsa:MessageIDおよびwsa:ReplyToの2つのヘッダーがあります。サービス・バインディング・コンポーネントでは、内部SOAコンポーネントに対して次のプロパティが使用可能になります。

- replyToAddress = sb://testserver:9001/callback

- replyToReferenceParameter: WSAの要素: ReferenceParameters

38.2.3 直接バインディングJavaクライアント・コードをコンパイルおよび実行するために必要なJARファイル

直接バインディングJavaクライアント・コードのコンパイルには、次のJARファイルが必要です。

- $FMWHOME/soa/soa/modules/oracle.soa.mgmt_11.1.1/soa-infra-mgmt.jar

直接バインディングJavaクライアント・コードの実行には、次のJARファイルが必要です。

- $FMWHOME/wlserver/server/lib/wlthint3client.jar

- $FMWHOME/soa/soa/modules/oracle.soa.fabric_11.1.1/oracle-soa-client-api.jar

38.2.4 SOA直接アドレス構文

直接バインディング起動APIで使用するサービス・パスは、SOA直接アドレス・パターンに従います。

- soadirect:/CompositeDN/serviceName (CompositeDNはコンポジット識別名)

SOA直接アドレスでは、CompositeDNの形式は次のとおりです(labelはオプションです)。

domainName/compositeName[!compositeVersion[*label]]

38.2.5 SOAトランザクション伝播

直接バインディングでは、SOAトランザクション伝播機能がサポートされています。この機能は、次の2つの方法でクライアントから起動できます。

- クライアントからJavaトランザクションを開始し、すべてのデータベース操作を実行した後にコミットします。データベース操作は、クライアント側からの正常なコミットの後にコミットする必要があります。

- クライアント側からJavaトランザクションを開始します。SOAコンポジットで操作中にフォルトがスローされた場合は、クライアント側からトランザクションをロールバックします。これで、すべてのデータベース操作がロールバックされます。

38.3 起動APIを使用したOracle JDeveloperでのSOAコンポジット・アプリケーションの起動

Oracle JDeveloperの「コンポーネント」ウィンドウの「直接」アイコン(図38-3 を参照)では、RMIでのSOAとのSOAメッセージ交換がサポートされています。

図38-3 「直接バインディング」オプション

Oracle JDeveloperでは、Oracle Service Busまたは別のSOAコンポジットのいずれかを起動する直接サービス・バインディングと直接参照バインディングの作成がサポートされています。

注意:

クライアントが直接バインディングを使用してコンポジット・サービスを起動するには、そのクラスパスにsoa-infra-mgmt.jar、wlthint3client.jarおよびoracle-soa-client-api.jarが含まれている必要があります。

直接バインディング起動APIの詳細は、「直接バインディング起動APIの概要」を参照してください。

38.3.1 インバウンド直接バインディング・サービスの作成方法

Oracle JDeveloperの「コンポーネント」ウィンドウの「直接」アイコンを使用して、SOAコンポジット・アプリケーションを起動できます。

インバウンド直接バインディング・サービスを作成する手順は、次のとおりです。

1. Oracle JDeveloperを開きます。

2. 「コンポーネント」ウィンドウで、「SOA」を選択します。

3. 「テクノロジ」リストから、「直接」アイコンを「公開されたサービス」スイムレーンにドラッグします。「直接バインディングの作成」ダイアログが表示されます。

4. 表38-1 に記載されている詳細を入力します。

表38-1 「直接バインディングの作成」ダイアログのフィールドと値

フィールド

値

名前

名前を入力します。

タイプ

リストから「サービス」を選択します。

参照ターゲット

このサービスを「公開されたサービス」スイムレーンで定義する場合、このフィールドは無効になります。

WSDL URL

WSDLファイルのURLの場所。既存のWSDLがある場合は、「既存のWSDLを検索します。」オプションをクリックします。それ以外の場合は、「スキーマからWSDLを生成します。」をクリックします。

ポート・タイプ

WSDLファイルのポート・タイプ。リストからポート・タイプを選択する必要があります。

コールバック・ポート・タイプ

非同期プロセスのコールバック・ポート・タイプ。

コールバックに対するSSLの使用

コールバックに対してSSLを使用する場合に選択します。

アドレス

WSDLが具体的で少なくとも1つの直接バインディングがある場合、このフィールドは自動的に移入されます。

プロバイダURL

WSDLが具体的で少なくとも1つの直接バインディングがある場合、このフィールドは自動的に移入されます。

ローカルJNDIプロバイダの使用

ローカルJNDIプロバイダを使用する場合に選択します。

WSDLとその依存アーティファクトをプロジェクトにコピー。

このチェック・ボックスを選択解除します。このチェック・ボックスを選択した場合、リモートWSDLが更新されると、WSDLファイルのローカル・コピーに同期の問題が発生する可能性があります。

完了すると、図38-4 に示すように、「直接バインディングの作成」ダイアログが表示されます。

図38-4 「直接バインディングの作成」ダイアログ

5. 「OK」をクリックします。

図38-5 に示すように、直接バインディング・サービスがSOAコンポジット・エディタに表示されます。丸囲みの1本の矢印は、同期する一方向の直接バインディング・コンポーネントであることを示します。

図38-5 直接バインディング・サービス

38.3.2 アウトバウンド直接バインディング参照の作成方法

SOAコンポジット・アプリケーションまたはOracle Service Busのいずれかを起動するために、Oracle JDeveloperの「コンポーネント」ウィンドウの「直接」アイコンを使用して、アウトバウンド直接バインディング参照を作成できます。

注意:

Oracle SOA SuiteとOracle Service Busが異なるドメインにある場合、それらのドメイン間の信頼を有効化する必要があります。

アウトバウンド直接バインディング参照を作成する手順は、次のとおりです。

1. Oracle JDeveloperを開きます。

2. 「コンポーネント」ウィンドウで、「SOA」を選択します。

3. 「テクノロジ」リストから、「直接」アイコンを「外部参照」スイムレーンにドラッグします。「直接バインディングの作成」ダイアログが表示されます。

4. 表38-2 に記載されている詳細を入力します。

表38-2 「直接バインディングの作成」ダイアログのフィールドと値

フィールド

値

名前

名前を入力します。

タイプ

リストから「参照」を選択します。

参照ターゲット

直接バインディング・サービスの実行先となる参照ターゲットを選択します。

- Oracle SOAコンポジット: SOAコンポジット・アプリケーションを参照ターゲットとして直接バインディングを作成します。

- Oracle Service Bus: Oracle Service Busを参照ターゲットとして直接バインディングを作成します。

WSDL URL

WSDLファイルのURLの場所。既存のWSDLがある場合は、「既存のWSDLを検索します。」オプションをクリックします。

ポート・タイプ

WSDLファイルのポート・タイプ。リストからポート・タイプを選択する必要があります。

コールバック・ポート・タイプ

非同期プロセスのコールバック・ポート・タイプ。

コールバックに対するSSLの使用

コールバックに対してSSLを使用する場合に選択します。

アドレス

具体的なWSDL URLとポート・タイプを選択した場合、このフィールドは自動的に移入されます。ただし、具体的でないWSDLが指定されている場合、このフィールドは手動で入力する必要があります。

プロバイダURL

具体的なWSDL URLとポート・タイプを選択した場合、このフィールドは自動的に移入されます。ただし、具体的でないWSDLが指定されている場合、このフィールドは手動で入力する必要があります。

ローカルJNDIプロバイダの使用

ローカルJNDIプロバイダを使用する場合に選択します。

WSDLとその依存アーティファクトをプロジェクトにコピー。

このチェック・ボックスを選択解除します。このチェック・ボックスを選択した場合、リモートWSDLが更新されると、WSDLファイルのローカル・コピーに同期の問題が発生する可能性があります。

完了すると、図38-6 に示すように、「直接バインディングの作成」ダイアログが表示されます。Oracle SOA SuiteのサービスをOracle Service Busで使用する方法の詳細は、『Oracle Service Busでのサービスの開発』の「Oracle SOA Suiteのトランスポート(SOA-DIRECT)」を参照してください。

図38-6 「直接バインディングの作成」ダイアログ

5. 「OK」をクリックします。

図38-7 に示すように、直接バインディング参照がデザイナに表示されます。丸囲みの1本の矢印は、同期する一方向の直接バインディング参照コンポーネントであることを示します。

図38-7 直接バインディング参照

38.3.3 直接バインディングを起動するJ2SEクライアントのアイデンティティの設定方法

次の例に示すように、JNDIルックアップのプロセス中にサーバーに対してJNDIセキュリティ資格証明を渡すことによる認証時に、ユーザー・アイデンティティを確立できます。

public static void main(String[] args) throws Exception {
String operation = "process";

// This is the request message XML
String ns = "http://xmlns.oracle.com/DirectBinding_jws/EchoBPEL/BPELProcess1";
String payloadXML = "<ns1:process xmlns:ns1=\"" + ns + "\">\n" +
"  <ns1:input>wew</ns1:input>\n" +
"</ns1:process>";

String serviceAddress = "soadirect:/default/EchoBPEL!1.0/DService1";

// Specify the direct binding connection properties
Map<String, Object> props = new HashMap<String, Object>();
props.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
props.put(Context.PROVIDER_URL, "t3://" + hostname + ':' + portname);
props.put(Context.SECURITY_PRINCIPAL,username);
props.put(Context.SECURITY_CREDENTIALS, password);

// Create the direct binding connection, using those context properties
DirectConnectionFactory factory = JNDIDirectConnectionFactory.newInstance();

try {
DirectConnection dc = factory.createConnection(serviceAddress, props);

// Parse the XML request message
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
Document doc =
dbf.newDocumentBuilder().parse(new InputSource(new StringReader(payloadXML)));

// Prepare the payload for inclusion in the Message object
Map<String, Element> payload = new HashMap<String, Element>();
payload.put("payload", doc.getDocumentElement());

Message<Element> request = XMLMessageFactory.getInstance().createMessage(payload);

Message<Element> response = dc.request(operation, request);
} finally {
dc.close();
}
}

38.3.4 同一のサーバー名/ドメイン名を持つホスト上でのSOAコンポジットの呼出しに関する必知事項

あるSOAコンポジット・アプリケーションが、異なるホスト上の別のSOAコンポジット・アプリケーションを直接バインディングを介して呼び出し、両コンポジットが同一のサーバー名/ドメイン名を持つホスト上にある場合、呼出しが失敗します。

これは、Oracle WebLogic Serverトランザクション・サブシステムでは、トランザクション管理が正常に機能するためにドメイン名およびサーバー名が異なっている必要があるためです。トランザクション・サブシステムは、これらの名前を使用してトランザクションに関連するサーバーの場所をトラッキングします。呼出し時に2つのサーバーが同一の名前を持つ場合、トランザクション・サブシステムは間違って2つのサーバーを混同してしまいます。

別個のサーバー名およびドメイン名を持つホストを使用するようにしてください。

38.4 直接バインディング起動APIの使用例

この項では、APIの使用方法について説明します。接続パラメータを設定し、直接バインディングによってSOAコンポジット・アプリケーションを起動する方法、および直接バインディング起動を起動するようにメッセージ・オブジェクトを変更する方法を示します。

// The JNDIDirectConnectionFactory can be used to establish SOA instance
// connections for exchanging messages over the direct binding.
DirectConnectionFactory dcFactory = JNDIDirectConnectionFactory.newInstance();

// Connections are created based on the configuration, which is a map of standard
// naming properties, which will be used for the underlying connection lookup.
Map<String, Object> properties = new HashMap<String, Object>();
properties.put(Context.INITIAL_CONTEXT_FACTORY, jndi.WLInitialContextFactory");
properties.put(Context.PROVIDER_URL, "t3://HOST:PORT");
properties.put(Context.SECURITY_PRINCIPAL, USERNAME);
properties.put(Context.SECURITY_CREDENTIALS, PASSWORD);
DirectConnection conn =
dcFactory.createConnection("soadirect:/default/MyComposite!1.0/MyService",
properties);

// Messages are created using the MessageFactory
// Message objects are subsequently modified to be used for an invocation.
Message<Element> request = XMLMessageFactory.getInstance().createMessage();

// Define a Map of WSDL part names to matching XML Element objects
Map<String, Element> partData;

Payload<Element> payload = PayloadFactory.createXMLPayload(partData);
request.setPayload(payload);

// One-way invocation
conn.post("onewayoperation", request);

// Request-reply invocation
Message<Element> response = conn.request("requestreplyoperation", request);

Hashtable jndiProps = new Hashtable();
jndiProps.put(Context.PROVIDER_URL, "t3://" + HOST + ':' + PORT);
jndiProps.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
jndiProps.put(Context.SECURITY_PRINCIPAL,USERNAME);
jndiProps.put(Context.SECURITY_CREDENTIALS, PASSWORD);
Locator locator = LocatorFactory.createLocator(jndiProps);
CompositeDN compositedn = new CompositeDN(domainName, compositename, version);
String serviceName = "HelloEntry";
DirectConnection conn = locator.createDirectConnection(compositedn, serviceName);

第VII部 サービス・コンポーネント間の共有機能

この部では、複数のサービス・コンポーネントで使用可能な機能について説明します。

この部は、次の章で構成されています。

- Oracle SOA Suiteテンプレートおよび再利用可能なサブプロセス

- XSLTマップ・エディタを使用したトランスフォーメーションの作成

- XQueryマッパーを使用したトランスフォーメーションの作成

- ビジネス・イベントおよびイベント配信ネットワークの使用

- 相互参照の使用

- ドメイン値マップの使用

- ドメイン値マップでのOracle SOAコンポーザの使用

39 Oracle SOA Suiteテンプレートおよび再利用可能なサブプロセス

この章では、SOAプロジェクト、サービス・コンポーネントおよびBPELスコープ・アクティビティでのOracle SOA Suiteテンプレートの作成および使用方法、およびその他のプロセス内のスタンドアロンおよびインラインBPELサブプロセスの作成および再使用方法について説明します。

この章の内容は次のとおりです。

- テンプレートの概要

- スタンドアロンおよびインラインBPELサブプロセスの起動の概要

- Oracle SOA Suiteテンプレートと再利用可能なサブプロセスの違い

- テンプレートの作成

- BPELプロセスでのスタンドアロンおよびインラインBPELサブプロセスの作成

39.1 Oracle SOA Suiteテンプレートの概要

テンプレートとは、Oracle SOA Suiteプロジェクトの再利用可能な部分で、新規プロジェクトの作成に使用できます。表39-1 に示すように、テンプレートには3種類あります。

表39-1 テンプレート・タイプ

テンプレート・タイプ

説明

SOAプロジェクト

SOAプロジェクトがすべてパッケージされ、新規プロジェクトの開始に使用されます。このテンプレートを使用して、新規SOAコンポジット・アプリケーションを作成できます。

サービス・コンポーネント

BPEL 2.0プロセス(センサーを含む)など、他のプロジェクトへのインポート用にパッケージされたサービス・コンポーネントです。すべての依存コンポーネントおよび接続もパッケージされます。SOAコンポジット・アプリケーションの「コンポーネント」ウィンドウに、カスタム・サービス・コンポーネントとして表示されます。

カスタムBPELスコープ・アクティビティ

「コンポーネント」ウィンドウでカスタム・アクティビティとしてパッケージされ、他のBPELプロジェクトにインポートできる、BPELプロセスのスコープ・アクティビティです。このカスタム・アクティビティは、「コンポーネント」ウィンドウのBPELアクティビティ・パレットに表示できる可能性があります。

Oracle SOA Suiteテンプレートには、次の利点があります。

- アプリケーション、コンポジットおよびプロセス間で共通のコード(プロセスまたはスコープのサブパート)を共有します。一度作成すれば、他と共有できます。テンプレートは、何度も再使用できます。

- Oracle Metadata Servicesリポジトリ(MDSリポジトリ)からテンプレートを保存および再使用します。

- 消費時にすべて編集できます。

- Oracle JDeveloperでテンプレートを自動的に検出します。テンプレートは保存されると、「コンポーネント」ウィンドウに表示されます。

- 継承はありません。つまり、将来的にソース・テンプレートを変更しても、アプリケーションには表示されません。ソース・テンプレートを変更しても、テンプレートの現在のユーザーには変更されたことがわかりません。

- コンポーネント・スコープ・テンプレートにカスタム・アイコンが用意されます。

- テンプレートのバージョニングはありません。バージョン間の区別をするには、テンプレート名でバージョン番号を指定します。

- BPELバージョン1.1および2.0の両方のテンプレートをサポートします。

特定のテンプレートに対する変更は、以前にそのテンプレートを使用して作成されたプロジェクトには伝播されません。この機能は、レイヤー・カスタマイズで実現できます。

新しい注釈がコンポジット/BPELプロセスに追加され、テンプレートのリレーションシップが識別されます。

テンプレート使用の詳細は、「SOAプロジェクト・テンプレートの作成および使用」、「サービス・コンポーネント・テンプレートの作成および使用」および「BPELスコープ・アクティビティ・テンプレートの作成および使用」を参照してください。

39.2 スタンドアロンおよびインラインBPELサブプロセスの起動の概要

BPELでは、ビジネス・プロセス・ロジックを再利用可能にするモジュール化を制限付きでサポートします。ただ1つの方法は、再利用可能なプロセス・ロジックを完全に独立したプロセスとしてパッケージ化することで、このプロセスを、(起動アクティビティを介して)Webサービスで使用するのと同一のメソッドの親プロセス(再利用可能なプロセス・ロジックを使用するプロセス)で使用します。

この問題に対応するため、Oracle SOA Suiteでは、BPELにサブプロセスの拡張機能を提供しています。サブプロセスは、別個のプロセスが特定のプロセッサ内で再利用できるBPELコードのフラグメントです。このサブプロセス拡張機能には、次の利点があります。

- BPELプロセス・コードを再使用できることで、同じタスクを実行するために、同じアクティビティを何度も作成する必要がなくなります。

- コードのモジュール性。

- コードのメンテナンス(変更内容の伝播により、変更が必要になるたびに複数の場所に更新を実装する必要がなくなります)。

- 起動アクティビティよりオーバーヘッドが減少します。

- メモリー・フットプリントが減少します。メモリー・フットプリントは、複雑なプロセスでは大量となる場合があります。

注意:

- サブプロセスは、BPELバージョン2.0でのみサポートされます。BPELバージョン1.1ではサポートされません。

- 相関セットは、サブプロセスではサポートされません。インラインまたはスタンドアロン・サブプロセスで相関セットを作成すると、実行時に失敗します。

- サブプロセスを複数のコンポジットで共有することはできません。

- 「監視」ビューは、サブプロセス内ではサポートされていません。「監視」ビューは、Oracle BPELデザイナ上部の「監視ビューに変更」アイコンを選択することで、BPELプロセスからアクセスできます。

表39-2 に示すように、Oracle SOA Suiteでは2種類のサブプロセスをサポートします。

表39-2 サブプロセス・タイプ

スタンドアロン・サブプロセス

インライン・サブプロセス

- BPELコール・アクティビティがサブプロセスを起動します。

- BPELコール・アクティビティがサブプロセスを起動します。

- 同じコンポジット内のサブプロセスのみサポートします。

- 親BPELプロセス・コードの一部で、コンポジット・ビューには表示されません。

- 「コンポーネント」ウィンドウに表示されます。

- 「コンポーネント」ウィンドウに表示されます。

- インタフェースがなく、別のBPELプロセスからのみ呼び出すことができます。パートナ・リンクを含めることができます。

- サブプロセス・コードは実行時に再入可能かつ再利用可能です。何度も呼び出される場合でも、メモリーに保存できるコピーは1つのみです。

- 他のBPELプロセス間で再使用されるアクティビティが多数含まれるBPELプロセスの断片です。

- 1つのBPELプロセス内で再使用されるアクティビティのグループ用です。

- コンポジット・ビューでは、サブプロセスへの接続が点線で表示され、実際のコンポーネント間の接続でないことを示します。

- 設定するパラメータを定義するか、またはプロセス・パラメータを使用できます。

- アクティビティは、サブプロセスに変換されるスコープ・アクティビティ内に存在する必要があります。

スタンドアロン・サブプロセスの作成の詳細は、「スタンドアロンBPELサブプロセスの作成方法」を参照してください。

インライン・サブプロセスの作成の詳細は、「インライン・サブプロセスの作成方法」を参照してください。

39.2.1 スタンドアロン・サブプロセスの概要

スタンドアロン・サブプロセスは、次の例に示すように、拡張子が.sbpel (サブプロセスBPEL拡張子)のファイルで定義されます。

<!-- A subprocess is defined in a SBPEL file, containing a bpelx:subProcess
! document
! The bpelx:subProcess is similar to a standard bpel:process, with
! differences asnoted below.
-->

<bpelx:subProcess name="NCName" targetNamespace="anyURI"
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
xmlns:bpelx="http://schemas.oracle.com/bpel/extension" ...>

<!-- Partner links and variables serve as sub-process arguments -->
<partnerLinks>?
<partnerLink name="NCName" partnerLinkType="QName" myRole="NCName"?
partnerRole="NCName"?
bpelx:argumentRequired=["yes"|"no"]? />
<partnerLinks>
<variables>?
<variable name="BPELVariableName"  messageType="QName"? type="QName"?
element="QName"?
bpelx:argumentRequired=["yes"|"no"]?>
from-spec?
</variable>
</variables>

<!-- Standard process definition here, except no <receive> or <pick> with -->
<!--  createInstance="yes" -->
/activity/
</bpelx:subProcess>

<subProcess>要素は、WS-BPEL 2.0言語の拡張機能です。<subProcess>要素は、サブプロセス定義のルート要素です。この要素のネームスペースは次のとおりです。

http://schemas.oracle.com/bpel/extension

の第10.9項に指定されているとおり、<subProcess>アクティビティは<extensionActivity>に埋め込まれている必要があります。

次のWS-BPELターゲット・ネームスペースで定義されているように、サブプロセスのタイプはtProcessです。

http://docs.oasis-open.org/wsbpel/2.0/process/executable

これは、次の点でtProcessとは異なります。

- <subProcess>要素直下の変数およびパートナ・リンクは、サブプロセスの引数として機能します。属性argumentRequiredをyes (デフォルト値はno)に設定することにより、必要な引数にマークが付きます。サブプロセスに必要な引数は、コール元が渡す必要がある引数の最小セットです。

- インラインfrom-specイニシャライザで定義される変数は、デフォルト値を持つオプションの引数として機能します。コール元がこの引数を渡すと、コール元が引数に指定した値がデフォルト値をオーバーライドします。

- 値を設定する前に変数が参照された場合、必要な引数でないと、検証でエラーがレポートされます。

- サブプロセスの最初のアクティビティは、createInstanceをyesに設定したreceiveアクティビティまたはpickアクティビティにできません。これは、指定されたサブプロセス・タイプにはインスタンスが作成されず、論理的にはこのサブプロセスが既存のプロセス・インスタンスの一部となるためです。

サブプロセスの/@name属性は、デプロイされたコンポジット内で一意のサブプロセス名を定義します。

このサブプロセスは自己完結型です。つまり、すべての変数およびパートナ・リンクが、ローカル定義または引数に解決されるプロセス・スニペットで参照します。これは、コール・アクティビティで適用範囲内の変数およびパートナ・リンクへの未解決の参照が可能な<inlineSubProcess>要素とは異なります。

通常は、親とサブプロセスの間で複数の変数が交換されます。大容量のドキュメントの場合、コピーすると負荷が高くなります。このため、参照渡しはオプションになります。

サブプロセスはパートナと同期式(InOut)または非同期式(InOnly)で対話できます。これらの相互作用のパートナ・リンクは、親プロセスの引数として渡すか、サブプロセス内で構成できます。非同期リクエストの場合、WSアドレス/正規化されたメッセージの対話IDを親プロセス・インスタンスIDで設定します。これにより、正しいプロセス・インスタンスにコールバック・メッセージをルーティングできます。

SOAコンポジット・アプリケーションのサブプロセスはcomposite.xmlファイルに列挙されます。コンポーネント要素定義は、定義されたsbpelファイルにそのサブプロセス名を関連付けます。デプロイ中にサブプロセス・コンポーネントはBPELプロセス・サービス・エンジンに委任されます。このBPELプロセス・サービス・エンジンはプロセス定義を検証し、サブプロセス・ターゲット名をキーとし、サブプロセス定義を値とするマップを構築します。コンシューマ・カウントから独立したサービス・エンジンに存在するサブプロセスのインスタンスは、多くて1つのみです。メモリーの最適化のため、プロセスはアクティブに使用されていない場合、遅延ロードまたはアンロードされる場合があります。

スタンドアロン・サブプロセスの作成の詳細は、「スタンドアロンBPELサブプロセスの作成方法」を参照してください。

39.2.2 インライン・サブプロセスの概要

インライン・サブプロセスは<process>レベルのBPEL 2.0プロセスの一部として定義できます。構文を次の例に示します。

<process name="NCName" targetNamespace="anyURI"
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" ...>
<!--
! All sub-process definitions must appear prior to the WS-BPEL artifacts of
! the process definition.
-->

<!-- Inline sub-process definition at process scope -->
<bpelx:inlineSubProcess xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="NCName">*
...
<!-- Partner links and variables serve as sub-process arguments -->
<partnerLinks>?
<partnerLink name="NCName" partnerLinkType="QName" myRole="NCName"?
partnerRole="NCName"?
bpelx:argumentRequired=["yes"|"no"]? />+
<partnerLinks>
...
<variables>?
<variable name="BPELVariableName"  messageType="QName"? type="QName"?
element="QName"?
bpelx:argumentRequired=["yes"|"no"]?>+
from-spec?
</variable>
</variables>
...
<!--
! Standard process activity graph here, except that no <receive> or <pick>
! activities with createInstance = "yes" are allowed.
-->
activity
</bpelx:inlineSubprocess>

<!--
! BPEL code stripped for brevity
-->
</process>

BPELプロセス・インスタンスの最初の作成時には、すべてのサブプロセス参照が解決されます。このプロセスが特定のコール・アクティビティを実行する際は、インスタンスの作成時に解決済のサブプロセスが使用されます。したがって、たとえばサブプロセスのデフォルトのコンポジット・リビジョンが変更された場合など、同じプロセス内の2つの別のインスタンスが、別のバージョンの参照済サブプロセスを使用する可能性があります。

BPELプロセス・インスタンスがコール・アクティビティを実行する際は、プロセスの実行スペース内で実行され、状態を共有します。コール・アクティビティではコントロールをサブプロセスに送信し、その際、サブプロセス・スコープが次の引数の値で初期化されます。

- 各パラメータは、コール・アクティビティからサブプロセスのスコープに(指定に応じて参照または値により)コピーされます。

- コール・アクティビティのパラメータ・リストで参照されないオプションのパラメータ(デフォルト値で設定)は、デフォルト値で初期化されます。

- 必要なすべてのパラメータが、コール・アクティビティによって指定される必要があります。

- コール・アクティビティのパラメータによって指定されたすべての値は、サブプロセスで定義された対応する変数(またはパートナ・リンク)と互換性のあるタイプである必要があります。

- サブプロセスの各変数(またはパートナ・リンク)は、コール・アクティビティのパラメータ・リストで1回のみ設定できます。

サブプロセスの完了時に、コントロールが親プロセスに返されます。通常は、コール・アクティビティの後、引き続き次のアクティビティが実行されます。サブプロセスが正常に完了しなかった場合は、WS-BPELの標準ライフ・サイクル・ルールに従って、親プロセスがこのプロセスを進めます。

サブプロセスの新規プロセス・インスタンスは、監視および管理ビューからは作成できません。親プロセス・インスタンスのコール・アクティビティで表されます。アクティビティを開く(移動する)と、サブプロセスの実行の詳細が表示されます。

実行時のリンク・エラーを最小限にするため、プロセスおよびサブプロセスのデプロイの際は、参照が解決されます。パラメータ・リストはデプロイ後のアクティビティとして検証されます。新規プロセス・インスタンスの作成の前処理では、プロセスのすべてのサブプロセス参照を検証します。解決されない参照がある場合、そのインスタンスは作成されません。かわりに、基本的に次のような意味のエラー・メッセージが返されます。

HTTP Status Code 503, "service not available

リンク・エラーがあると、サービス・コンシューマが待機中の場合、終了アクティビティ処理が行内に含まれたエラー・メッセージがコンシューマに送信されます。それ以外の場合、インスタンスは一時停止され、理由がlinkage errorに設定されます。適切なサブプロセスがデプロイされて参照が解決可能な場合は、一時停止されたインスタンスをリカバリして、自動リカバリにより通常実行を再開できます。

インライン・サブプロセスの作成の詳細は、「インライン・サブプロセスの作成方法」を参照してください。

39.3 Oracle SOA Suiteテンプレートと再利用可能なサブプロセスの違い

自社のビジネスで使用するには、テンプレートと再利用可能なサブプロセスではどちらが最適なソリューションかを判断する際は、相違点を理解することが重要です。

- テンプレート
テンプレートは、カスタマイズ可能な、骨組みの状態のプロジェクト、サービス・コンポーネントまたはスコープ・アクティビティです。テンプレートは、SOAコンポジット・アプリケーションまたはBPELプロセスにドラッグ・アンド・ドロップして、変更を加えることができます。基本的には、テンプレートをコピーして貼付けます。たとえば、テンプレートに50行のコードがあり、2回コピーして使用する場合、コードは100行になります。

- 再利用可能なサブプロセス
サブプロセスは、特定の目的を想定したBPELコード・スニペットです。以前に定義されたサブプロセスを呼び出してそのまま使用できます。50行のインライン・サブプロセスを2回呼び出しても、親プロセスのコードは100行ではなく、50行のままとなります。サブプロセスは、テンプレートよりもパフォーマンスが高く、メモリー・フットプリントも小さくなります。

39.4 Oracle SOA Suiteテンプレートの作成

次のタイプのテンプレートを作成できます。

- SOAプロジェクト

- サービス・コンポーネント

- カスタムBPELスコープ・アクティビティ

テンプレートの概念の詳細は、「テンプレートの概要」および「Oracle SOA Suiteテンプレートと再利用可能なサブプロセスの違い」を参照してください。

39.4.1 SOAプロジェクト・テンプレートの作成および使用

この項では、SOAプロジェクトをテンプレートとして作成および使用する方法について説明します。

注意:

テンプレートの使用は、Oracle JDeveloperカスタマイズ・ロールではサポートされません。

39.4.1.1 SOAプロジェクト・テンプレートの作成方法

SOAプロジェクト・テンプレートを作成する手順は、次のとおりです。

1. SOAコンポジット・アプリケーションを開きます。

2. 「アプリケーション」ウィンドウで、次のいずれかを右クリックします。

- composite_name

- プロジェクト名

3. 「SOAテンプレートの作成」を選択します。

SOAテンプレートの作成ウィザードが表示されます。コンポジット名に基づくテンプレートのデフォルトの名前および保存場所が自動的に含められます。図39-1に詳細を示します。

図39-1 「SOAテンプレートの作成」ウィザード - 「テンプレート情報の指定」ページ

4. 必要に応じてデフォルト値を変更し、説明を入力して、「次へ」をクリックします。「保存先」フィールドの「参照」アイコンを使用して、ファイル・システムまたはMDSリポジトリのOracle SOA Suiteデザインタイム・セクションにテンプレートを保存できます。

SOAテンプレートの作成ウィザード - 「バンドルするファイル」ページが表示されます。図39-2に詳細を示します。このページには、パッケージされたすべてのファイルが、このテンプレートの一部として表示されます。

測定(ビジネス・インジケータ)およびテスト・スイートを手動で選択して含めることもできます。コンポジットにドメイン値マップ(DVM)が含まれている場合(たとえば、DVM関数がBPELスコープ・アクティビティで参照されるなど)、それらもテンプレートに含まれます。

ビジネス・インジケータの詳細は、「BPELプロセス分析の構成」を参照してください。テスト・スイートの詳細は、「コンポジット・テスト・フレームワークの概要」を参照してください。

図39-2 SOAテンプレートの作成ウィザード -「バンドルするファイル」ページ

5. パッケージするファイルを表示して追加ファイルを選択し、「終了」をクリックします。

6. テンプレートが正常に作成されたことを確認するよう求められたら、「OK」をクリックします。

39.4.1.2 別のSOAコンポジットでコンポジット・テンプレートを使用する方法

この項では、「SOAプロジェクト・テンプレートの作成方法」で作成したコンポジット・テンプレートを別のSOAコンポジット・アプリケーションで使用する方法について説明します。

別のSOAコンポジットでコンポジット・テンプレートを使用する方法は次のとおりです。

1. Oracle JDeveloperで新規SOAコンポジット・アプリケーションを作成します。

2. SOAアプリケーションの作成ウィザード - SOA設定の構成ページで、「SOAテンプレート」を選択します。図39-3に詳細を示します。

図39-3 カスタム・テンプレートの選択

使用可能なテンプレートのリストが表示されます。図39-4に詳細を示します。

図39-4 選択可能なSOAテンプレート

3. リストからテンプレートを選択し、「追加」をクリックして追加するテンプレートを選択します。

4. 「終了」をクリックします。

SOAコンポジット・エディタにカスタム・テンプレートが表示されます。テンプレートのファイルが「アプリケーション」ウィンドウに表示されます。

バインディング・コンポーネントおよびプロセス名の変更など、必要に応じてコンポーネント名を変更できます。

5. 右クリックし、「名前の変更」を選択します。

39.4.2 サービス・コンポーネント・テンプレートの作成および使用

この項では、サービス・コンポーネント・テンプレートを作成および使用する方法について説明します。

39.4.2.1 サービス・コンポーネント・テンプレートの作成方法

サービス・コンポーネント・テンプレートを作成する方法は次のとおりです。

1. Oracle JDeveloperメイン・メニューから、「ファイル」→「新規」を選択します。

2. 「SOAプロジェクト」を選択し、「OK」をクリックします。

3. プロジェクト名を入力し、「次へ」をクリックします。

4. BPELプロジェクトを選択し、「終了」をクリックします。

5. SOAコンポジット・アプリケーションを設計します。

6. SOAコンポジット・エディタで、テンプレートを作成するサービス・コンポーネントを右クリックします。

7. 「コンポーネント・テンプレートの作成」を選択します。

コンポーネント・テンプレートの作成ウィザードが表示されます。

8. オプションでパートナ・リンクのアイコンを選択するなど、適切なレスポンスを指定して、「次へ」をクリックします。図39-5に詳細を示します。

図39-5 コンポーネント・テンプレートの作成ウィザード - 「テンプレート情報の指定」ページ

コンポーネント・テンプレートの作成ウィザード - 「バンドルするファイル」ページが表示されます。

9. パッケージされたファイルを表示して、必要に応じて追加ファイル(アダプタや測定など)を選択し、「終了」をクリックします。

10. テンプレートが正常に作成されたことを確認するよう求められたら、「OK」をクリックします。

サービス・コンポーネント・テンプレートが「コンポーネント」ウィンドウの「コンポーネント・テンプレート」セクションに追加されます。図39-6に詳細を示します。

図39-6 「コンポーネント」ウィンドウの「コンポーネント・テンプレート」セクションのサービス・コンポーネント・テンプレート

39.4.2.2 別のSOAコンポジットでサービス・コンポーネント・テンプレートを使用する方法

この項では、「サービス・コンポーネント・テンプレートの作成方法」で作成したパッケージ済サービス・コンポーネント・テンプレートを別のSOAコンポジット・アプリケーションで使用する方法について説明します。

別のSOAコンポジットでサービス・コンポーネント・テンプレートを使用する方法は次のとおりです。

1. Oracle JDeveloperで空のSOAコンポジット・アプリケーションを作成します。

2. SOAコンポジット・エディタで、「SOA」リストから「SOAテンプレート」を選択します。図39-7に詳細を示します。

図39-7 「SOA」メニューの「SOAテンプレート」オプション

3. サービス・コンポーネント・テンプレートをSOAコンポジット・エディタにドラッグします。

これにより、図39-8 に示すように、「コンポーネント・テンプレートからSOAコンポーネントを作成」ダイアログが表示されます。このダイアログには、テンプレート名、説明、およびこのテンプレートに含まれるファイルが表示されます。

図39-8 「コンポーネント・テンプレートからSOAコンポーネントを作成」ダイアログ

4. 「OK」をクリックします。

サービス・コンポーネント・テンプレートがSOAコンポジット・アプリケーションに表示されます。

5. 「アプリケーション」ウィンドウを表示して、スキーマやWSDLなどのファイルがSOAコンポジット・アプリケーションに表示されることを確認します。

6. サービス・コンポーネント・テンプレートを同じSOAコンポジット・アプリケーションに2回目に適用しようとすると、「コンポーネント・テンプレートからSOAコンポーネントを作成」ダイアログが表示され、スキーマおよびBPELファイルがそのコンポジットにすでに存在するため、競合することを示します。図39-9に詳細を示します。

図39-9 「コンポーネント・テンプレートからSOAコンポーネントを作成」ダイアログ

7. 「次へ」をクリックします。

8. 「競合の解決」ページで、スキップするか、すべてのファイルまたは競合する特定のファイルを上書きするかを選択します。図39-10に詳細を示します。

図39-10 競合しているファイル名

9. 完成したら、「終了」をクリックします。

39.4.3 BPELスコープ・アクティビティ・テンプレートの作成および使用

この項では、BPELスコープ・アクティビティ・テンプレートを作成および使用する方法について説明します。

39.4.3.1 BPELスコープ・アクティビティ・テンプレートの作成方法

BPELスコープ・アクティビティ・テンプレートを作成する手順は次のとおりです。

1. Oracle BPELデザイナで、スコープ・アクティビティをBPELプロセスにドラッグします。

2. スコープ・アクティビティのコンテンツを設計してアクティビティ、イベント・ハンドラおよび捕捉を含め、必要に応じて、フォルト変数を含むすべてのブランチを捕捉します。

3. スコープからテンプレートを作成します。

a. スコープを右クリックして、「カスタム・アクティビティ・テンプレートの作成」を選択します。

または

a. 図39-11 に示すように、スコープを展開して、「カスタム・アクティビティ・テンプレートの作成」を選択します。

図39-11 スコープ・テンプレートの作成

図39-12 に示すように、カスタム・アクティビティ・テンプレートの作成ウィザード - 「テンプレート情報の指定」ページが表示されます。

図39-12 カスタム・アクティビティ・テンプレートの作成ウィザード - 「テンプレート情報の指定」ページ

4. 詳細を指定し、「次へ」をクリックします。
カスタム・アクティビティ・テンプレートの作成ウィザード - 「変数」ページが表示されます。図39-13に詳細を示します。このページは、変数がスコープで使用されている場合に表示されます。このページは、スコープが空の場合、またはスコープで変数を使用しない場合は表示されません。

図39-13 カスタム・アクティビティ・テンプレートの作成ウィザード -「変数」ページ

5. 変数をローカル変数に変換することを選択します。この変数が、receiveアクティビティおよびreplyアクティビティのスコープ・アクティビティ外で使用される場合、この変換は推奨されません。変数がこのスコープ内でのみ使用される場合は、このチェック・ボックスはデフォルトで選択されています。

6. 変数の説明(オプション)を入力し、「次へ」をクリックします。
図39-2 に示したように、カスタム・アクティビティ・テンプレートの作成ウィザード - 「バンドルするファイル」ページが表示されます。このページには、パッケージされたすべてのファイルが、このテンプレートの一部として表示されます。テスト・スイートを手動で選択して含めることもできます。

7. ファイルを選択し、「終了」をクリックします。

39.4.3.2 BPELスコープ・アクティビティ・テンプレートを別のBPELプロセスで使用する方法

この項では、BPELスコープ・アクティビティ・テンプレートを別のBPELプロセスで使用する方法について説明します。

BPELスコープ・アクティビティ・テンプレートを別のBPELプロセスで使用する方法は次のとおりです。

1. 新規BPELプロセスを作成するか、既存のBPELプロセスを開きます。

2. 「コンポーネント」ウィンドウの「カスタム・アクティビティ・テンプレート」セクションから、「BPELスコープ・アクティビティ・テンプレートの作成方法」で作成したスコープ・アクティビティ・テンプレートをBPELプロセスにドラッグします。図39-14に詳細を示します。

注意:

BPELサービス・コンポーネントのバージョンと互換性のあるスコープ・アクティビティ・テンプレートのみを使用できます。たとえば、BPEL 2.0のサービス・コンポーネントの場合、BPEL 2.0のスコープ・アクティビティ・テンプレートのみを選択できます。BPELバージョン1.1のスコープ・アクティビティ・テンプレートは表示されません。

図39-14 スコープ・アクティビティ・テンプレート

自分で設計したエラー処理(catchおよびcatchallアクティビティなど)や、自分で作成したスコープ変数も、BPELプロセスにコピーされます。

図39-15 に示すように、「テンプレートからのカスタム・アクティビティの作成」ページが表示されます。

図39-15 テンプレートからのカスタム・アクティビティの作成ウィザード

3. 「次へ」をクリックします。
競合がある場合は、図39-16 に示すように、テンプレートからのカスタム・アクティビティの作成ウィザード - 「競合の解決」ページが表示されます。

図39-16 テンプレートからのカスタム・アクティビティの作成ウィザード - 「競合の解決」ページ

4. すべてのファイル競合または個別のファイル競合をスキップする選択をして、「次へ」をクリックします。
図39-17 に示すように、テンプレートからのカスタム・アクティビティの作成ウィザード - 「変数」ページが表示されます。

「BPELスコープ・アクティビティ・テンプレートの作成方法」の手順5で、カスタム・アクティビティ・テンプレートの作成ウィザード - 「変数」ページで変数をローカル変数に変換することを選択した場合は、特別な処理は必要なく、このページに表示されません。ローカル変数に変換されなかった変数のみが、「テンプレートからのカスタム・アクティビティの作成」ウィザード - 「変数バインド」ページに表示されます。

図39-17 「テンプレートからのカスタム・アクティビティの作成」ウィザード -「変数バインド」ページ

5. テンプレートおよびプロジェクトの両方にこの変数が含まれる場合、変数を再使用するか、または「BPEL変数」列のリストから新しい変数をバインドすることを選択できます。

a. 新規変数へのバインドを選択した場合は、名前を入力し、変数をテンプレート・スコープ用にローカルに作成するか、BPELプロセス用にグローバルに作成するかを選択して、「OK」をクリックします。図39-18に詳細を示します。

図39-18 「新規変数へのバインド」ダイアログ

スコープB内のスコープA内にあるアクティビティ・テンプレートを削除した場合、スコープAとスコープBもリストに含まれます。これによって、変数を宣言可能なすべての場所から選択できます。

6. 「次へ」をクリックします。

7. スコープでパートナ・リンクを使用する場合は、「カスタム・アクティビティ・テンプレートの作成」ウィザード - 「パートナ・リンク」ページが表示されます。

8. 「終了」をクリックします。

39.4.4 テンプレートの管理

使用可能なすべてのテンプレート・タイプを「プリファレンス」ダイアログで管理できます。

テンプレートを管理する手順は、次のとおりです。

1. Oracle JDeveloperメイン・メニューから、「ツール」→「プリファレンス」→「SOA」→「テンプレート」を選択します。

図39-19 に示すように、「プリファレンス」ダイアログが表示されます。

図39-19 SOAテンプレートのプリファレンス

テンプレートは次の2つの場所に保存できます。

- フォルダ: テンプレートをファイル・システムに保存できます。

- SOA-MDS: テンプレートをMDSリポジトリに保存して共有できます。

2. 図39-20 に示すように、フォルダを右クリックして、管理タスクのリストを表示します。

図39-20 管理タスク

表39-3 では、実行可能な管理タスクについて説明します。

表39-3 テンプレートの管理タスク

要素

説明

参照

特定のテンプレート名を参照します。

「参照」オプションは、Windowsの場合はWindows Explorerを、Linuxの場合はファイル・ブラウザを使用して記憶域フォルダを参照します。テンプレートはファイルとして格納されるため、ファイルと同様に操作できます(つまり、FTPでのアップロード、電子メールによる送信、別のフォルダにコピーしてバックアップなど)。

リフレッシュ

テンプレートのリストをリフレッシュします。

記憶域の追加

既存のテンプレートを「プリファレンス」 - 「SOAテンプレート」ダイアログに追加します。

削除

フォルダおよびそのテンプレートを「プリファレンス」 - 「SOAテンプレート」ダイアログからのみ削除します。テンプレートは、ファイル・システムやMDSリポジトリから物理的には削除されません。「記憶域の追加」を選択するか「追加」アイコンをクリックして、このダイアログに再度追加できます。テンプレートのコンテキスト・メニューには、テンプレートを物理的に削除する「削除」オプションがあります。

すべてのテンプレート

すべてのテンプレートを表示します。

プロジェクト・テンプレート

SOAプロジェクト・テンプレートのみを表示します。

コンポーネント・テンプレート

サービス・コンポーネント・テンプレートのみを表示します。

アクティビティ・テンプレート

BPELスコープ・アクティビティ・テンプレートのみを表示します。

3. jdeveloper/integration/templatesディレクトリにテンプレートをインポートする場合は、「ファイル」→「インポート」→「SOAテンプレート」を選択します。ファイルは、「追加」アイコンをクリックするか、フォルダを右クリックして「記憶域の追加」を選択することで、「プリファレンス」ダイアログに追加できます。

39.5 BPELプロセスでのスタンドアロンおよびインラインBPELサブプロセスの作成

BPELプロセスで、SOAコンポジットではスタンドアロン・サブプロセスを、BPELプロセスではインラインBPELサブプロセスを作成できます。サブプロセスは、別個のプロセスが特定のプロセッサ内で再利用できるBPELコードのフラグメントです。

サブプロセスの概念の詳細は、「スタンドアロンおよびインラインBPELサブプロセスの起動の概要」および「Oracle SOA Suiteテンプレートと再利用可能なサブプロセスの違い」を参照してください。

注意:

- 1つのBPELサブプロセスが再帰的にそのサブプロセス自体を呼び出すことに、制限はありません。同じBPELサブプロセスを再帰的に呼び出すかどうかと、サブプロセスを呼び出す回数を指定する必要があります。

- スタンドアロン・サブプロセスのみを含むSOAコンポジット・アプリケーションは、作成して正常にデプロイできます。たとえば、SOAコンポジット・アプリケーションを作成して、サブプロセスのパラメータを2つ定義したスタンドアロン・サブプロセスを追加し、このサブプロセスでassignアクティビティを定義して、両方のパラメータの値を入れ替えます。ただし、スタンドアロン・サブプロセスのみを含み、他のコンポーネントは含まないSOAコンポジット・アプリケーションはデプロイできますが、実用的ではありません。

- スタンドアロン・サブプロセスはMDSリポジトリで共有できません。ただし、サブプロセスを呼び出すコール・アクティビティを含むBPELプロセスは、MDSリポジトリで共有できます

39.5.1 スタンドアロンBPELサブプロセスの作成方法

この項では、スタンドアロン・サブプロセスを使用する簡単なアプリケーションの作成方法の例を示します。

注意:

スタンドアロン・サブプロセスには、インライン・サブプロセスを含めることができます。

スタンドアロンBPELサブプロセスを作成する手順は次のとおりです。

1. BPEL 2.0プロセスを含むSOAコンポジット・アプリケーションを作成します。この例では、同期BPEL 2.0プロセスを作成します。

2. BPEL 2.0プロセスを設計します。この例では、次のプロセスが設計されます。

- タイプ文字列の変数が作成され(この例ではvariable1という名前)、パラメータとして渡されます。

- assignアクティビティが作成され、そこでクライアント入力文字列がvariable1にマップされます。

図39-21 はBPELプロセスの設計を示しています。

図39-21 BPEL 2.0プロセスの設計

3. Oracle BPELデザイナ上部の「composite_name」リンクをクリックして、SOAコンポジット・エディタにアクセスします。

4. SOAコンポジット・エディタ内を右クリックし、「挿入」→「サブプロセス」の順に選択するか、「コンポーネント」ウィンドウから「サブプロセス」アイコンをコンポジットにドラッグします。

「サブプロセスの作成」ダイアログが表示されます。

5. 適切な値を入力するか、デフォルト値をそのまま使用して、「OK」をクリックしてスタンドアロン・サブプロセスを作成します。図39-22に詳細を示します。この例では、指定されたサブプロセス名がSubprocess1となります。

図39-22 「サブプロセスの作成」ダイアログ

6. SOAコンポジット・エディタのサブプロセスを右クリックし、「編集」を選択します。

7. サブプロセスのタイプ文字列の変数を作成し(この例の変数名はp1)、「OK」をクリックします。

これで、スタンドアロン・サブプロセスで簡単なプロセス・ロジックを設計しました。

8. 「コンポーネント」ウィンドウからプロセスに、assignアクティビティをドラッグします。

9. assignアクティビティの「コピー・ルール」タブの「ターゲット」セクションで、「式ビルダー」アイコンをp1変数にドラッグします。

10. concat式を作成して、サブプロセス内のパラメータから値を読み取り、その値で変数p1を更新します。

concat($p1,",from subprocess")

11. コンポジットを保存するか、「すべて保存」を選択して、BPEL 2.0プロセスを終了します。

12. SOAコンポジット・エディタでBPELプロセスを右クリックして、「編集」を選択します。

13. 「Oracle Extensions」サブセクションから、Oracle BPELデザイナのassignアクティビティの下にcallアクティビティをドラッグします。

14. callアクティビティを右クリックし、「編集」を選択します。

コールの編集ダイアログが表示されます。変数p1は、「名前」列の選択したSubprocess1の後に表示されることに注意してください。

15. 「値」列内をクリックして、「変数チューザ」ダイアログを起動します。

16. 「variable1」を選択し、「OK」をクリックします。これにより、変数p1がスタンドアロン・サブプロセスから、最初に作成したBPEL 2.0プロセスの変数variable1にマッピングされます。

17. 「値によるコピー」チェック・ボックスを選択解除したままにします。

このチェック・ボックスを選択解除のままにすると、変数が参照によってコピーされます。変数には、変数またはパートナ・リンクのみを使用でき、XPath関数問合せは使用できません。参照によるコピーは、入力および出力変数の両方をサポートします。値によるコピーは、値の入力のみをサポートします。

18. 「コンポーネント」ウィンドウから、2番目のassignアクティビティをコール・アクティビティの下にドラッグします。

19. assignアクティビティの「コピー・ルール」タブで、出力メッセージをvariable1で更新し、「OK」をクリックします。図39-23に詳細を示します。

図39-23 assignの編集ダイアログ

図39-24 は、サブプロセスを含むBPEL 2.0プロセスを示しています。このBPEL 2.0プロセスでは、次のロジックが設計されます。

- Assign1の入力メッセージの文字列値が取得されて、callアクティビティのvariable1に割り当てられ、参照により渡されます。

- assign2がvariable1を取得し、レスポンスを作成します。variable1の値は、サブプロセスによって更新されます。

図39-24 BPEL 2.0プロセス

20. SOAコンポジット・エディタに移動し、BPELサブプロセスは現在、callアクティビティによってBPEL 2.0プロセスに接続されていることに注意してください。

これで、SOAコンポジット・アプリケーションをデプロイし、Oracle Enterprise Manager Fusion Middleware Controlでビジネス・フロー・インスタンスを作成する準備ができました。

Oracle Enterprise Manager Fusion Middleware Controlで作成されたビジネス・フロー・インスタンスの監査証跡にアクセスする際は、callアクティビティとそのコンポーネントが表示されることに注意してください。

スタンドアロンBPELサブプロセスの詳細は、『Oracle SOA Suiteの理解』のデータベースで注文のステータスを更新するためのテンプレートおよびスタンドアロン・サブプロセスの使用方法に関する項を参照してください。

39.5.2 インライン・サブプロセスの作成方法

インライン・サブプロセスは、スタンドアロン・サブプロセスに類似していますが、インライン・サブプロセスが親プロセスに埋め込まれているという点が異なります。たとえば、顧客注文のステータスを更新するスコープ・アクティビティ内にassignアクティビティとinvokeアクティビティが含まれているBPEL 2.0プロセスがあるとします。これらの同じアクティビティを、後で同じプロセスで繰り返すというビジネス・ニーズがあるとします。スコープの同じassignアクティビティとinvokeアクティビティを、後でプロセス内で物理的に繰り返す方法がありますが、これはエラーが発生しやすい可能性があります。さらに、毎回変更する必要があり、それを両方のスコープに実装する必要があります。アクティビティを繰り返すかわりに、インライン・サブプロセスを使用できます。

注意:

既存のインライン・サブプロセス内にインライン・サブプロセスを作成することはサポートされません。

インライン・サブプロセスを作成する手順は次のとおりです。

1. たとえば、顧客注文のステータスを更新するassignアクティビティとinvokeアクティビティが含まれている、BPEL 2.0プロセスのスコープ・アクティビティに移動します。

注意:

インライン・サブプロセスは、Oracle BPELデザイナの上部にある「プロパティ構造」メニューから「インライン・サブプロセス」を選択し、「インライン・サブプロセス」フォルダを選択して、「追加」クリックすることでもBPELプロセスに作成できます。

2. スコープ・アクティビティを閉じます。図39-25に詳細を示します。

図39-25 scopeアクティビティ

3. スコープ・アクティビティを右クリックして、「サブプロセスに変換」を選択します。

図39-26 に示すように、「インライン・サブプロセスの作成」ダイアログが表示されます。

図39-26 「インライン・サブプロセスの作成」ダイアログ

4. 環境に適した値を入力し、「OK」をクリックします。

表39-4 「インライン・サブプロセスの作成」ダイアログ

要素

説明

名前

名前を入力するか、デフォルト値をそのまま使用します。デフォルトはスコープ名になっています。

サブプロセス・コールのあるスコープを置換

選択すると、スコープをBPELコール・アクティビティで自動的に置き換えます(デフォルト選択)。インライン・サブプロセスを作成し、選択したスコープをプロセスで保持する場合は、このチェック・ボックスを選択解除します。

ラベル

オプションで説明を入力します。

コメント

コメントを最適に入力します。

イメージ

選択すると、標準のコール・アクティビティ・アイコンが独自のイメージに置き換えられます。

図39-27 に示すように、スコープ・アクティビティがBPEL 2.0プロセスのcallアクティビティに変換されます。

図39-27 callアクティビティ

新規インライン・サブプロセスは、「コンポーネント」ウィンドウの「サブプロセス」セクションにも表示されます。図39-28に詳細を示します。

図39-28 「コンポーネント」ウィンドウのインライン・サブプロセス

5. Oracle BPELデザイナの上で、「サブプロセス - updateOrderStatusSP」を選択して、サブプロセスのコンテンツ(最初のスコープ・アクティビティと同じコンテンツ)を表示します。図39-29に詳細を示します。

図39-29 Oracle BPELデザイナの上の「サブプロセス」セクション

インライン・サブプロセスのコンテンツが表示されます。図39-30に詳細を示します。

図39-30 インライン・サブプロセスのコンテンツ

6. 必要に応じて、invokeアクティビティの追加など、サブプロセスに変更を加えます。

必要に応じて、同じBPEL 2.0プロセスにサブプロセスを追加できます。

7. 「コンポーネント」ウィンドウの「サブプロセス」セクションから、インライン・サブプロセスをBPEL 2.0プロセスの適切なセクションにドラッグします。図39-31に詳細を示します。

図39-31 同じBPEL 2.0プロセスに追加されたサブプロセス

図39-32 に示すように、サブプロセス名はCall番号に自動的に変更されます。

図39-32 変更されたサブプロセス名

インラインBPELサブプロセスの使用方法の詳細は、『Oracle SOA Suiteの理解』のインラインBPELサブプロセスによる注文のステータスの更新に関する項を参照してください。

39.5.3 パートナ・リンクをパラメータとして取得するスタンドアロン・サブプロセスの作成方法

この項では、サブプロセスがパートナ・リンクをパラメータとして取得し、それを使用してパートナを呼び出し、結果を返す方法を示します。基本的には、サブプロセスからサブプロセスへパートナ・リンクを使用しています。

パートナ・リンクをパラメータとして取得するスタンドアロン・サブプロセスを作成する手順は次のとおりです。

1. BPEL 2.0プロセスを含むSOAコンポジット・アプリケーションを作成します。この例では、同期BPEL 2.0プロセスを作成します。

2. SOAコンポジット・エディタでSOAコンポジット・アプリケーションに移動します。

3. 右クリックして、「挿入」→「サブプロセス」を選択します。

「サブプロセスの作成」ダイアログが表示されます。

4. デフォルト値をそのまま使用し(たとえば、デフォルト名はSubprocess1)、「OK」をクリックします。

これで、パートナ・リンクとして使用する2番目のプロセスを作成しました。

5. SOAコンポジット・アプリケーションで2番目の同期BPEL 2.0プロセス(この例では、BPELProcess2)を作成します。これは、呼び出すプロセスです。

6. 「コンポーネント」ウィンドウから、2番目のBPEL 2.0プロセスにassignアクティビティをドラッグします。

7. 「コピー・ルール」タブの「ターゲット」セクションで、「式ビルダー」アイコンをresult変数にドラッグします。図39-33に詳細を示します。

図39-33 assignの編集ダイアログ

8. XPath式を構築し、「OK」をクリックします。

string("hello from process2")

9. 2番目のBPEL 2.0プロセスを保存して、サブプロセスに戻ります。

10. 図39-34 に示すように、「パートナ・リンク」アイコンをクリックします。

図39-34 パートナ・リンクの作成

「パートナ・リンク」ダイアログが表示されます。

11. 「追加」アイコンをクリックします。

「パートナ・リンクの作成」ダイアログが表示されます。これで、このパートナ・リンクをパラメータとして定義しました。

12. パラメータ・リンク(この例ではPartnerLink1という名前)を設計し、「OK」をクリックします。図39-35に詳細を示します。パートナ・リンクのロールはプロバイダとなります。

図39-35 パートナ・リンクの作成

「パートナ・リンク」ダイアログが図39-36 のように表示されます。

図39-36 「パートナ・リンク」ダイアログ

図39-37 に、サブプロセスのコンテンツを示します。

図39-37 サブプロセスのコンテンツ

13. scopeアクティビティをサブプロセスにドラッグします。

14. スコープ・アクティビティの「変数」アイコンをクリックして、リクエストおよびレスポンス・メッセージ・タイプ変数を作成します。図39-38に詳細を示します。

図39-38 リクエストおよびレスポンス・メッセージ・タイプ変数の作成

15. sequenceアクティビティをサブプロセスにドラッグします。

16. パートナ・リンクを起動するサブプロセスに「起動」アクティビティをドラッグします。

17. 図39-39 に示すように、パートナ・リンクを起動するサブプロセスのinvokeアクティビティを設計します。この設計には、出力変数(Variable2)が含まれます。

図39-39 「起動の編集」ダイアログ

図39-40 に、サブプロセスを示します。

図39-40 BPELサブプロセス

18. サブプロセスの「変数」アイコンをクリックして、結果を返す文字列変数を作成します。

「変数」ダイアログが表示されます。

19. 「追加」アイコンをクリックして、「変数の作成」ダイアログを起動します。

20. 文字列変数(この例ではresultという名前)を作成します。

21. assignアクティビティをサブプロセスにドラッグします。

22. 図39-41 に示すように、パートナ・リンク起動の結果をresult変数にマッピングして、「OK」をクリックします。

図39-41 assignアクティビティの編集

これで、サブプロセスの設計は完了です。

23. Oracle BPELデザイナのメインBPEL 2.0プロセス(BPELProcess1)に戻ります。

24. プロセスの「変数」アイコンをクリックします。

25. 「追加」アイコンをクリックして、手順22で構成して返した結果を含む文字列変数(この例ではVariable1という名前)を作成します。図39-42に詳細を示します。

図39-42 「変数」ダイアログ

26. assignアクティビティを追加して、文字列値をVariable1に割り当てます。

27. Oracle BPELデザイナのassignアクティビティの下にcallアクティビティをドラッグします。図39-43に詳細を示します。

図39-43 メインBPEL 2.0プロセスに追加されたサブプロセス

28. 「パートナ・リンク」スイムレーンを右クリックして、「パートナ・リンクの作成」を選択します。

29. 図39-44 に示すように、BPELProcess2を起動するパートナ・リンクを設計します。

図39-44 「パートナ・リンクの作成」ダイアログ

30. callアクティビティを右クリックして、「編集」をクリックします。

コールの編集ダイアログに、サブプロセスでこれまでに作成されたパートナ・リンクが表示されます。

31. 「result」行の「値」列をクリックして、「変数チューザ」ダイアログを起動します。

32. 「Variable1」を選択し、「OK」をクリックします。

33. 「PartnerLink1」行の「値」列をクリックして、「パートナ・リンク・チューザ」ダイアログを起動します。

34. 「PartnerLink1」を選択して「OK」をクリックします。図39-45 に、設計が完了したコールの編集ダイアログを示します。変数は参照によって送信されるので、なんらかの理由でサブプロセスがパートナ・リンクを変更すると(別のパートナ・リンクへのコピーなど)、コール・プロセスのパートナ・リンクが影響を受けます。これは、変数を含む場合と同じプロセスです。

図39-45 コールの編集ダイアログ

35. callアクティビティの下のassignアクティビティをドラッグして、結果を返します。

36. 「コピー・ルール」タブで、Variable1をresultにマッピングして、コール元に結果を返します。図39-46に詳細を示します。

図39-46 assignの編集ダイアログ

37. SOAコンポジット・アプリケーションをデプロイします。

39.5.4 サブプロセスの名前変更に関する必知事項

サブプロセスの名前を変更する際、起動中のコール・アクティビティでは更新されません。コール・アクティビティのサブプロセス名は手動で更新する必要があります。

次の手順を実行すると仮定します。

1. 非同期BPEL 2.0プロセスを作成します。

2. SOAコンポジット・エディタを右クリックし、「挿入」→「サブプロセス」を選択します。

3. SubProcessNewという名前のサブプロセスを作成します。

4. 「SubProcessNew」を右クリックして、「編集」をクリックします。

5. 「コンポーネント」ウィンドウからサブプロセスに、「空」のアクティビティをドラッグします。

6. 非同期BPEL 2.0プロセスを開きます。

7. 「コンポーネント」ウィンドウからプロセスに、「コール」アクティビティをドラッグします。

8. SubProcessNewサブプロセスをcallアクティビティから起動します。

9. SOAコンポジット・エディタに戻り、SubProcessNewサブプロセスの名前をSubProcessRenamedに変更します。

10. 非同期BPEL 2.0プロセスのcallアクティビティを開き、「サブプロセス」フィールドが空であることに注意してください。

11. 「サブプロセス」フィールドに、更新された名前のSubProcessRenamedを手動で入力します。

40 XSLTマップ・エディタを使用したトランスフォーメーションの作成

この章では、XSLTマップ・エディタを使用して、ソース・スキーマ要素とターゲット・スキーマ要素の間のデータ・トランスフォーメーションを作成、設計およびテストする方法について説明します。

この章の内容は次のとおりです。

- XSLTマップ・エディタの概要

- XSLTマップの作成

- マップ・ビューでのXSLTマップの編集

- XSLTビューでのXSLTマップの編集

- XPath式の使用

- 自動マップを使用した複合ノードのマッピング

- マップの完了ステータスの確認

- マップのテスト

- 外部XSLTマップのインポート

- 変数およびパラメータの使用

- 要素およびタイプの置換

- 名前付きテンプレートの使用

- テンプレート・ルールの使用

- 実行ビューの使用

- XSLTマップのデバッグ

- メモリーの問題のトラブルシューティング

- XSLマップ・プリファレンスの設定

40.1 XSLTマップ・エディタの概要

XSLTマップ・エディタでは、グラフィック表示のエディタを使用して、XSLTスタイルシートを編集できます。また、XSLTソースを直接編集する機能もあります。

図40-1 に、XSLTマップ・エディタを示します。エディタ下部のタブを使用して、グラフィック表示のエディタとソース・ビューを切り替えることができます。グラフィック表示のエディタを使用して編集するには、「設計」をクリックします。ソース・エディタを使用して編集するには、「ソース」をクリックします。

図40-1 XSLTマップ・エディタ

「ソース」タブと「設計」タブを行き来できます。一方のタブで変更を加えると、もう一方のタブでも反映されます。「履歴」タブを使用して、リビジョンの履歴を表示し、編集履歴の任意の時点に戻ることも可能です。

XSLTマップ・エディタはXSLT 1.0およびXPath 1.0を完全にサポートしています。

XSLT 2.0を使用する場合、ソース・ビューでXSLTバージョンを変更できます。

XSLT 2.0固有のすべてのコンストラクトをソース・ビューで追加する必要があります。その後、設計ビューへの切替えを選択して、引き続きマップを編集できます。XSLT 2.0固有のコンストラクトは設計ビューに表示されますが、ソース・ビューでのみ変更できます。XPath 2.0のコンストラクトも設計ビューで追加できます。ただし、XPath 2.0のコンストラクトは解析して、設計ビューの個別のグラフィカル要素にはできません。完全なXPath文をテキスト形式で編集する必要があります。

XSLTマップ・エディタでは、設計ビューで次の編集ビューを使用できます。

- マップ・ビュー

- XSLTビュー

XSLTエディタの右上隅にあるボタンを使用して、2つのビューを切り替えられます。XSLTエディタの従来のマップ・ビューを使用するには、「マップ」をクリックします。より複雑なXSLTマップ向けのXSLTビューを使用するには、「XSLT」をクリックします。

40.1.1 マップ・ビューの使用

図40-1 に、XSLTマップ・エディタのマップ・ビューを示します。左側のペインには、受信ソースXMLドキュメントを表すソース・ツリーが含まれています。このソース・ツリーはXSDスキーマ・ファイルまたはサンプルXMLファイルから作成できます。

中央のペイン、またはキャンバスは、XSLT要素にマッピング可能なXPath式および関数をドロップする場所です。

右側のペインは、作成するXSLTのマージ済ビューを表すターゲット・ペインと、ターゲット・スキーマを表すターゲット・ツリーです。このターゲット・ツリーはXSDスキーマ・ファイルまたはサンプルXMLファイルから作成できます。

ターゲット・ツリーにイタリック体でグレー表示されたノードは、まだマッピングされていないノードを表します。これらのノードはXSLTの一部ではなく、便宜上表示されています。グレー表示のノードはマッピングされると、通常のフォントになり、XSLTマップに表示されます。

マップ・ビューでは、ソース・ツリーからターゲット・ツリーへのドラッグ・アンド・ドロップ・マッピングがサポートされます。さらにマップ・ビューでは、XPath関数のコールおよび、xsl:ifやxsl:for-eachなどのXSLT文もサポートされます。

マップ・ビューではXSLT文がターゲット・ツリーから分離されないため、次の制限事項があります。

- match='/'属性を含むXSLTテンプレート・ルールが1つのみサポートされます。

- サポートされるXSLT文は、xsl:for-each、xsl:value-of、xsl:text、xsl:if、xsl:choose/when、xsl:variableおよびxsl:paramです。

XSLT文をターゲット・ツリーから分離する必要がある複雑なXSLT文には、XSLTビューを使用します。

40.1.2 XSLTビューの使用

XSLTビューはより高度なモードで、XSLT文をターゲット・ツリー・ドキュメントから分離できます。これにより、設計ビューのまま、複雑なXSLT文を作成できます。ソース・スキーマおよびターゲット・スキーマは、XSLTビューではオプションです。

XSLTビューにはマップ・ビューと同じペインが含まれますが、右側のターゲット・ペインは2つに分かれています。上のペインはXSLTペイン、下のペインはターゲット・ペインと呼びます。ターゲット・スキーマが定義されていない場合、下のペインは表示されません。ソース・スキーマが定義されていない場合でも、ソース・ペインはそのまま表示され、そこでXSLTから参照可能なパラメータおよび変数を追加できます。

XSLTビューでは、連続したXSLT文をいくつでも作成でき、これらの文をターゲット・ツリー・ノードに挿入する必要はありません。たとえば11gのマッパーでは、すべてのxsl:if文にターゲット出力ノードを1つ含める必要がありました。XSLTビューでは、xsl:if文を任意の場所で使用でき、他のXSLT文を含めることができます。

XSLTビューでは、すべてのXSLT 1.0文がサポートされます。また、XSLTビューは、ソース・スキーマおよびターゲット・スキーマを含む、または含まない複数のテンプレート・ルールもサポートしています。XSLTビューでは、複雑さに関係なく、任意のXSLTスタイルシートをグラフィック表示して編集できます。

40.1.3 「コンポーネント」ウィンドウの使用

「コンポーネント」ウィンドウには、XSLTマップで使用できるすべてのXPath関数と、XSLT要素およびテンプレートが含まれています。

「コンポーネント」ウィンドウは、デフォルトではOracle JDeveloperの右上隅にあります。「コンポーネント」ウィンドウが表示されない場合は、「ウィンドウ」メニューの「コンポーネント」をクリックすると、「コンポーネント」ウィンドウが表示されます。オプションで、「JDeveloper」ウィンドウの使いやすい場所に「コンポーネント」ウィンドウをドラッグする選択ができます。また、「コンポーネント」ウィンドウは必要に応じてサイズを変更できます。

「コンポーネント」ウィンドウではこれらの関数、要素およびテンプレートを次のカテゴリにまとめます。

- 拡張XPath:

- 一般XPath:

- XML:

- XSLT要素:

- XSLTテンプレート:

- すべてのページ:

- ユーザー定義:

- コンポーネント:

40.1.4 「プロパティ」ウィンドウの使用

「プロパティ」ウィンドウは、XSLTマップ・エディタで選択されたアイテムの内容およびプロパティを示します。これらのプロパティの一部は、編集も可能です。

「プロパティ」ウィンドウは、デフォルトではXSLTマップ・エディタの下にあります。「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メニューの「プロパティ」をクリックすると、「プロパティ」ウィンドウが表示されます。オプションで、「JDeveloper」ウィンドウ内の使いやすい場所に「プロパティ」ウィンドウをドラッグする選択ができます。また、「プロパティ」ウィンドウは必要に応じてサイズを変更できます。

「プロパティ」ウィンドウは、通常、次のアイテムのプロパティの表示および編集に使用できます。

エディタで選択された要素

「プロパティ」ウィンドウの表示内容

編集の可否(はい/いいえ)

ソース・ツリー・ノード

選択された要素または属性のスキーマ情報

いいえ

ターゲット・ツリー・ノード

選択された要素または属性のスキーマ情報

いいえ

XSLTツリー・ノード: XSLT要素

XSLT要素の属性およびその値

はい

XSLTツリー・ノード: リテラル要素または属性

リテラル要素または属性の名前およびネームスペース

はい

「キャンバス」ペインのXPath式フォルダ

全文XPath式

はい

「キャンバス」ペインの式フォルダ内の「関数」アイコン

関数の各パラメータのXPathフィールド

はい

ソースおよびターゲット・ノードをつなぐ線

全文XPath式

はい

40.2 XSLTマップの作成

XSLT1マップは一から作成するか、BPEL、BPM、メディエータなど、他のエディタから作成できます。

40.2.1 XSLTマップの作成方法

XSLTマップを作成する手順は次のとおりです。

1. 「ファイル」メイン・メニューから、「新規」→「XSLマップ」を選択します。または、プロジェクト・フォルダを右クリックして、「新規」→「XSLマップ」の順に選択します。

「XSLマップ・ファイルの作成」ダイアログが開きます。

2. 「ファイル名」で、.xslマップ・ファイルの名前を指定します。

3. 「ディレクトリ名」で、.xslファイルの宛先ディレクトリを選択します。

4. 「ソース」で、「ソース・スキーマの使用」を選択してマップのソース・スキーマを指定します。

5. 「プライマリ・ソース」で、「参照」をクリックしてソース・スキーマを選択します。「スキーマの選択」ダイアログ・ボックスが表示されます。

6. XSDスキーマ・ファイルまたはWSDLファイルをソース・スキーマに使用する場合は、「スキーマの選択」を選択します。

注意:

または、サンプルXMLファイルをスキーマ・ソースとして使用できます。

XMLファイルからスキーマを生成するには、「XMLから生成」を選択します。サンプル・ファイルを選択して、「開く」をクリックします。手順9に進みます。

7. 「参照」をクリックして、ソース・スキーマのスキーマ・ファイルおよび要素を選択します。「タイプ・チューザ」ダイアログが表示されます。

8. スキーマ・ファイルと対応する要素を、プロジェクト・スキーマ・ファイルまたはプロジェクトWSDLファイル・ツリーから選択します。「OK」をクリックします。

必要なスキーマ・ファイルまたはWSDLファイルがツリーで使用できない場合は、ダイアログの右上隅にある「スキーマ・ファイルのインポート」ボタンまたは「WSDLファイルのインポート」ボタンをクリックして、スキーマ・ファイルまたはWSDLファイルをインポートできます。

9. 「スキーマの選択」ダイアログで「OK」をクリックします。

注意:

「その他のソース」で緑色のプラス記号アイコン(+)で表示される「スキーマの追加」ボタンをクリックして、追加のソースをパラメータ形式で追加できます。

10. 「ターゲット・スキーマの使用」を選択して、XSLマップのターゲット・スキーマを指定します。

11. 「参照」をクリックしてターゲット・スキーマを選択します。「スキーマの選択」ダイアログが表示されます。

12. ターゲット・スキーマの選択後、「スキーマの選択」ダイアログで「OK」をクリックします。

注意:

「ターゲット・スキーマ」を使用すると、現在の「プリファレンス」設定によっては、最初の要素および属性のノードがXSLTペインに生成される場合があります。

デフォルト設定では、ターゲット・スキーマで必要なすべての要素および属性の後に、match=''/''属性を含むルート・テンプレートが生成されます。

13. 「OK」をクリックして、XSLマップ・ファイルを作成します。

注意:

- XSLTマップの作成後、キャンバス・ペインのコンテキスト・メニューで適切なオプションを選択して、ソースおよびターゲット・スキーマを追加または置換できます。
たとえば、ソース・ペインのコンテキスト・メニューで「パラメータの追加」を選択して、追加のソースをパラメータとして追加できます。

- JDeveloperを使用して、XSLTマップで使用されているソースまたはターゲット・スキーマ・ファイルを編集できます。スキーマ・ファイルを保存すると、XSLTエディタのソースまたはターゲット・ツリーが自動的に更新されます。

40.2.2 Oracle BPEL Process ManagerでXSLマップ・ファイルを作成する方法

XSLT transformアクティビティを使用すると、Oracle BPEL Process ManagerのXSLTマップ・エディタを使用してトランスフォーメーションを作成できます。このツールを使用すると、1つ以上のソース要素をターゲット要素にマップできます。たとえば、受信したソース注文書スキーマ・データを、送信する請求書スキーマ・データにマップできます。

Oracle BPEL Process ManagerでXSLマップ・ファイルを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウから、XSLT transformアクティビティをBPELプロセス・ダイアグラムにドラッグします。図40-2 に例を示します。

図40-2 transformアクティビティ

2. XSLT transformアクティビティをダブルクリックします。
図40-3 に示す「Transform」ダイアログが表示されます。

図40-3 「変換」ダイアログ

3. 次の情報を指定します。

a. 要素のマップ元となるソース変数を追加します。追加するには、「追加」アイコンをクリックして、変数と、必要に応じて変数のパート(たとえば、注文書リクエストで構成されるペイロード・スキーマ)を選択します。

注意:

複数の入力変数を選択できます。定義されている最初の変数が、XSLマップへのメインXML入力を表します。ここで追加される他の変数は、XSLマップでは入力パラメータとして定義されます。

b. 要素のマップ先となるターゲット変数を追加します。

注意:

図40-3 は、BPEL 2.0での「変換の編集」ダイアログを示しています。BPEL 1.1の「変換の編集」ダイアログは少し異なります。BPEL 1.1の「変換の編集」ダイアログでは、変数のリストから「ターゲット変数」を選択できます。

c. マップ先となる変数のターゲット・パート(たとえば、請求書で構成されるペイロード・スキーマ)を追加します。

4. 「マッパー・ファイル」フィールドで、マップ・ファイル名を指定するか、デフォルト名をそのまま使用します。XSLTマップ・エディタを使用して、マップ・ファイルにマッピングを作成します。

5. 「追加」アイコン(「マッパー・ファイル」フィールドの右側にある2番目のアイコン)をクリックして、マッピングを作成します。ファイルが存在する場合は、「編集」アイコン(3番目のアイコン)をクリックしてマッピングを編集します。
XSLTマップ・エディタが表示されます。

注意:

拡張子が.xsltの既存のファイル(たとえば、xform.xslt)を選択すると、xform.xsltファイルを使用するつもりでもXSLTマップ・エディタが開き、xform.xslt.xslという名前のXSLファイルが作成されます。拡張子が.xslではないすべてのファイルに.xsl拡張子が追加され、新規ファイルでマッピングを作成する必要が発生します。回避策として、ファイル名には必ず拡張子.xslを付けるようにします。XSLファイルの拡張子が.xsltである場合は、.xslに変更します。

6. XSLTマップ・エディタの使用方法の概要は、「XSLTマップ・エディタの概要」を参照してください。

40.2.3 Oracle BPEL Process Managerでインポートされたソースとターゲット・スキーマ・ファイルからXSLマップ・ファイルを作成する方法

次の手順では、po.xsdファイルとinvoice.xsdファイルを使用して、Oracle BPEL Process ManagerでXSLマップを作成する方法の概要を説明します。

Oracle BPEL Process Managerで、インポートされたソースとターゲット・スキーマ・ファイルからXSLマップ・ファイルを作成する手順は、次のとおりです。

1. Oracle JDeveloperで、新規XSLマップを作成するアプリケーション・プロジェクトを選択します。

2. プロジェクトにpo.xsdおよびinvoice.xsdファイルをインポートします。次に例を示します。

a. Oracle JDeveloperの「構造」ウィンドウで、「スキーマ」を右クリックします。

b. 「スキーマのインポート」を選択します。

3. 選択したプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」ダイアログが表示されます。

4. 「カテゴリ」ツリーで、「SOA層」を開いて「トランスフォーメーション」を選択します。

5. 「項目」リストで、「XSLマップ」をダブルクリックします。
「XSLマップ・ファイルの作成」ダイアログが開きます。このダイアログでは、ターゲットのスキーマ・ファイルまたはWeb Services Description Language (WSDL)ファイルのルート要素にソースのスキーマ・ファイルまたはWSDLファイルのルート要素をマップする、XSLマップ・ファイルを作成できます。次の詳細に注意してください。

- プロジェクトに追加されたWSDLファイルは、「プロジェクトのWSDLファイル」の下に表示されます。

- プロジェクトに追加されたスキーマ・ファイルは、「プロジェクトのスキーマ・ファイル」の下に表示されます。

- プロジェクトの一部ではないスキーマ・ファイルは、スキーマ・ファイルのインポート機能を使用してインポートできます。「スキーマ・ファイルのインポート」アイコン(スキーマ・ファイル・リストの右上にある1番目のアイコン)をクリックしてください。

- プロジェクトの一部ではないWSDLファイルは、WSDLファイルのインポート機能を使用してインポートできます。「WSDLファイルのインポート」アイコン(スキーマ・ファイル・リストの右上にある2番目のアイコン)をクリックしてください。

6. 「「ファイル名」」フィールドに、XSLマップ・ファイルの名前を入力します。

7. ソース・ツリーとターゲット・ツリーでルート要素を選択します。図40-4 の例では、ソース・ルート要素にPurchaseOrder要素が選択され、ターゲット・ルート要素にInvoice要素が選択されています。

図40-4 展開された「ターゲット」セクション

8. 「OK」をクリックします。
図40-5 に示すように、新しいXSLマップが作成されます。

図40-5 新規XSLマップ

9. この時点でファイルを保存して閉じるか、トランスフォーメーションの設計を開始します。XSLTマップ・エディタの使用方法の詳細は、「XSLTマップ・エディタの概要」を参照してください。

10. 「コンポーネント」ウィンドウから、transformアクティビティをBPELプロセスにドラッグします。

11. transformアクティビティをダブルクリックします。

12. 次の情報を指定します。

a. 要素のマップ元となるソース変数を追加します。追加するには、「追加」アイコンをクリックして、変数と、必要に応じて変数のパート(たとえば、注文書リクエストで構成されるペイロード・スキーマ)を選択します。

注意:

複数の入力変数を選択できます。定義されている最初の変数が、XSLマップへのメインXML入力を表します。ここで追加される他の変数は、XSLマップでは入力パラメータとして定義されます。

b. 要素のマップ先となるターゲット変数を追加します。

c. マップ先となる変数のターゲット・パート(たとえば、請求書で構成されるペイロード・スキーマ)を追加します。

13. 「マッパー・ファイル」フィールドの右側にある「検索」アイコン(1番目のアイコン)をクリックし、ステップ6で指定したファイル名を参照します。

14. 「開く」をクリックします。

15. 「OK」をクリックします。
XSLTマップ・エディタにXSLマップ・ファイルが表示されます。

16. XSLTマップ・エディタの使用方法の概要は、「XSLTマップ・エディタの概要」を参照してください。

40.2.4 Oracle MediatorでXSLマップ・ファイルを作成する方法

XSLTマップ・エディタを使用すると、Oracle Mediatorで、XMLスキーマ間でデータを変換するためのXSLファイルを作成できます。XSLファイルを定義した後は、そのファイルを複数のルーティング・ルール仕様で再利用できます。この項では、XSLTマップ・エディタを使用してトランスフォーメーション・マップXSLファイルを作成する方法の概要を示します。

XSLTマップ・エディタは、Oracle JDeveloperの「アプリケーション」ウィンドウでXSLファイルをクリックするか、メディエータ・エディタで「トランスフォーメーション」アイコンをクリックすると使用できます(次の手順で説明します)。新規のトランスフォーメーション・マップを作成するか、既存のトランスフォーメーション・マップを更新できます。

メディエータ・エディタでXSLTマップ・エディタを起動してデータ・トランスフォーメーションXSLファイルを作成または更新するには、次の手順に従います。

メディエータ・エディタでXSLマップ・ファイルを作成する手順は、次のとおりです。

1. メディエータ・エディタを開きます。

2. 「ルーティング・ルール」の左側の「+」アイコンをクリックして「ルーティング・ルール」パネルを開きます。

「ルーティング・ルール」パネルにトランスフォーメーション・マップ・アイコンが表示されます。

3. 図40-6 に示すように、「次を使用して変換」フィールドの右側にある適切なトランスフォーメーション・マップ・アイコンをクリックして、トランスフォーメーション・マップ・ダイアログを表示します。

図40-6 ルーティング・ルール

このトランスフォーメーション・マップ・ダイアログには、既存のトランスフォーメーション・マップ(XSL)ファイルを選択するか、新規のマップ・ファイルを作成するオプションが表示されます。たとえば、「同期リプライ」セクションのトランスフォーメーション・マップ・アイコンを選択すると、図40-7 に示すダイアログが表示されます。

図40-7 「リプライ・トランスフォーメーション・マップ」ダイアログ

ルーティング・ルールに同期リプライまたはフォルトが含まれている場合、「リプライ・トランスフォーメーション・マップ」ダイアログまたは「フォルト・トランスフォーメーション・マップ」ダイアログには、「リクエストをリプライ・ペイロードに含める」オプションが表示されます。 このオプションを有効化すると、リクエスト・メッセージから情報を取得できます。リクエスト・メッセージ、リプライおよびフォルト・メッセージは、複数のパートで構成できるため、複数のソース・スキーマを指定できます。コールバックとコールバック・タイムアウト・トランスフォーメーションも、複数のパートで構成できます。

各メッセージ・パートには変数が入ります。リプライ・トランスフォーメーションでは、リプライ・メッセージにはメイン・パート(検出される最初のパート)のスキーマ、およびそれに続く各パートのin.partname変数が含まれます。インクルード・リクエスト・メッセージには、各パートのinitial.partname変数が含まれます。

たとえば、リプライのメイン・パートがout1.HoustonStoreProductスキーマで、変数として処理される他の2つのパートがin.HoustonStoreProductとin.HoustonStoreProduct2であるとします。リクエスト・メッセージには、変数として処理されるinitial.expense、initial.expense2およびinitial.expense3の3つのパートが含まれます。図40-8 に例を示します。

図40-8 リプライ・パート

4. 次のいずれかのオプションを選択します。

- 「検索」アイコンを選択し、既存のXSLTマップ・ファイルを参照(またはデフォルト値をそのまま使用)します。

- 「追加」アイコンをクリックして、新しいXSLTマップ・ファイルを作成し、そのファイルの名前を入力(またはデフォルト値をそのまま使用)します。
ステップ3で説明したように、WSDLファイルのソース・メッセージに複数のパートがある場合は、各パートに変数が使用されます。トランスフォーメーションのターゲットに複数のパートがある場合は、複数のトランスフォーメーション・ファイルがこれらのターゲットにマップされます。この場合、Oracle Mediatorの「トランスフォーメーション」ダイアログには、ターゲット・パートごとに別々のパネルが表示されます。たとえば、図40-9 はターゲットに3つのパートがあるリクエストを示しています。

図40-9 「リクエスト・トランスフォーメーション・マップ」ダイアログ

5. 「OK」をクリックします。

新しいXSLTマップ・ファイルを作成することを選択した場合は、XSLTマップ・エディタが開き、ソース・スキーマ要素をターゲット・スキーマ要素に関連付けることができます。

6. XSLTマップ・エディタの使用方法の概要は、「XSLTマップ・エディタの概要」を参照してください。

40.2.5 XSLマップ・ファイルの作成に関する必知事項

基本的なフォーマット・データ以外の既存のマッピング・エントリをすべてXSLファイルから手動で削除した場合、XSLファイルのエラーは、実行時のトランスフォーメーション中には表示されません。マッピング・エントリは必ず指定してください。たとえば、次の処理を実行するとします。

1. XSLTマップ・エディタで、入力データから出力データへのトランスフォーメーション・マッピングを作成します。

2. 出力データをファイル・アダプタを使用してファイルに書き込むように、アプリケーションを設計します。

3. XSLファイルを手動で変更し、基本的なフォーマット・データ以外のマッピング・エントリをすべて削除します。次に例を示します。

<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.0"
xmlns:xp20="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.fu
nctions.Xpath20"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:ns0="http://xmlns.oracle.com/pcbpel/adapter/file/MediaterDemo/Validation
UsingSchematron/WriteAccounInfoToFile/"
xmlns:orcl="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.fu
nctions.ExtFunc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dvm="http://www.oracle.com/XSL/Transform/java/oracle.tip.dvm.LookupValue
"
xmlns:hwf="http://xmlns.oracle.com/bpel/workflow/xpath"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:mhdr="http://www.oracle.com/XSL/Transform/java/oracle.tip.mediator.servi
ce.common.functions.GetRequestHeaderExtnFunction"
xmlns:ids="http://xmlns.oracle.com/bpel/services/IdentityService/xpath"
xmlns:imp1="http://www.mycompany.com/MyExample/NewAccount"
xmlns:tns="http://oracle.com/sca/soapservice/MediaterDemo/ValidationUsingSchem
atron/CreateNewCustomerService"
xmlns:xref="http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRe
fXPathFunctions"
xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ora="http://schemas.oracle.com/xpath/extension"
xmlns:inp1="http://www.mycompany.com/MyExample/NewCustomer"
exclude-result-prefixes="xsi xsl tns xsd inp1 ns0 imp1 plt xp20 bpws orcl dvm
hwf mhdr ids xref ora">
</xsl:stylesheet>

この場合でも、ファイルのコンパイルは可能ですが、XSLマッピングは無効になっています。

4. SOAコンポジット・アプリケーションのインスタンスをデプロイおよび作成します。

インスタンスの作成中に、書込み操作が入力を受信しなかったために失敗し、例外エラーが発生します。ただし、XSLトランスフォーメーション中にエラーは表示されません。

40.2.6 XSLマップ・ファイルを作成せずにOracle Mediatorを介してペイロードを渡した場合の実行時の処理内容

トランスフォーメーション・マッピングの定義または値の割当てを行わずに、Oracle Mediatorを介してペイロードを渡すようにSOAコンポジット・アプリケーションを設計した場合、ペイロードはOracle Mediatorを介して渡されます。

ただし、ペイロードが正しく渡されるには、ソース・メッセージとターゲット・メッセージのパート名およびタイプが同じである必要があります。それ以外の場合、SOAプロジェクトのコンパイルが失敗します。11gからアップグレードされたプロジェクトでは、プロジェクトはコンパイルされますが、入力ソースがNullのようですまたはパートが見つかりませんというエラー・メッセージが表示されて、ターゲット参照の実行に失敗する可能性があります。

40.2.7 空のネームスペース・タグがある出力メッセージを受信した場合の処理内容

XSLファイルのXML表現と、シナリオで使用するXML表現(このシナリオでは、トランスフォーメーションを実行するか、assignアクティビティを使用してメッセージを渡します)は、XMLが構文的およびセマンティク的に同じであっても異なる場合があります。たとえば、Oracle Mediatorサービス・コンポーネントを使用して、ネームスペースのない要素を含むインバウンド・ペイロードをアウトバウンド・ペイロードにマップすると、出力メッセージに空のネームスペース・タグが出力されることがあります。

<Country xmlns="">US</Country>

これは正常な動作です。空のネームスペースxmlns=""は自動的に追加されます。

40.3 マップ・ビューでのXSLTマップの編集

この項では、マップ・ビューで使用できる基本的な機能について説明します。残りの各項では、XSLTビューでの編集について、注意や制限事項も含めて説明しますが、これは説明する特定のアクティビティにマップ・ビューで適用される可能性があります。

40.3.1 ノードのリンクによる値のコピーの実行方法

ソースの属性の値またはリーフ要素をターゲットの属性またはリーフ要素にコピーするには、ソース・ノードからターゲット・ノードに線をドラッグします。ドラッグ・アンド・ドロップすると、緑色にハイライト表示された線が表示されます。ドロップし終わると、ソース・ノードとターゲット・ノードをつなぐ線が描画されます。

図40-10 は、ソース要素PurchaseOrder/IDがターゲット要素Invoice/IDにマッピングされたマップ・ビューを示しています。ソース・ノードとターゲット・ノードが線でつながれていることを確認してください。また、ターゲット・ツリーのID要素がグレー表示でなくなり、通常のフォントで表示されます。これは、ID要素がXSLTマップに追加されたことを示しています。

図40-10 マップ・ビューでのリーフ・ノードのコピー

40.3.2 出力ドキュメントでの空ノードの作成方法

出力ドキュメントで空ノードを作成する手順は次のとおりです。

1. ターゲット・ペインでグレー表示のノードを選択します。

2. ノードを右クリックし、コンテキスト・メニューで「XSLT内のノードの作成」を選択します。

40.3.3 ターゲット・ノードのリテラル・テキスト値の設定方法

出力ノードまたはターゲット・ノードにリテラル・テキスト値を設定する手順は、次のとおりです。

1. ターゲット・ペインでノードを右クリックします。表示されるコンテキスト・メニューから「テキスト値の編集」を選択します。

「テキストの設定」ダイアログが表示されます。

2. ノードに割り当てられるテキスト値を入力します。テキストを一重引用符で囲まないでください。

3. 「OK」をクリックします。

テキスト値が項目に設定されたことを示す黄色の「T」アイコンがノードの隣に表示されます。マウス・カーソルをノードに合せると、対応するテキストが表示されます。ノードが以前はグレー表示されていた場合、ノードがXSLTマップに追加されたため、今後はグレー表示されることはありません。

40.3.4 XSLT文の追加方法

条件文(if-then-else)や反復(for-each)などのコンストラクトを処理するために、XSLT文を追加できます。

40.3.4.1 XSLT文を追加する手順:

1. ターゲット・ノードを右クリックして、表示されるコンテキスト・メニューから「XSL命令の追加」を選択します。追加可能な様々なXSL文が含まれたサブメニューが表示されます。

2. サブメニューから、目的のXSL文(if、choose、for-eachなど)を選択します。

XSLT文xsl:textおよびxsl:variableは、既存のノードにのみ追加できます。

40.3.4.2 xsl:textまたはxsl:variable文を追加する手順:

1. ターゲット・ノードがXSLTに存在することを確認します。
ターゲット・ノードがグレー表示されている場合は、そのターゲット・ノードを右クリックして、表示されるコンテキスト・メニューから「XSLT内のノードの作成」を選択します。今後このノードはグレー表示されることはなく、XSLTマップに追加されています。

2. ターゲット・ノードを右クリックして、表示されるコンテキスト・メニューから「XSL命令の追加」を選択します。追加可能な様々なXSL文が含まれたサブメニューが表示されます。

3. サブメニューから「テキスト」または「変数」を選択します。

注意:

xsl:copy-of文は、マップ・ビューではサポートされていません。これはXSLTビューでサポートされています。

「コンポーネント」ウィンドウからXSLT文をドラッグ・アンド・ドロップすることも選択できます。

40.3.4.3 XSLT文をターゲット・ノードにドラッグ・アンド・ドロップする手順:

1. 「コンポーネント」ウィンドウから「XSLT要素」ページを選択します。文カテゴリのリストが表示されます。

2. サポートされている文を特定しますが、マップ・ビューの場合、カテゴリにあります。たとえば、for-each文は、「フロー制御」カテゴリに表示されます。
マップ・ビューでは、XSLT文のサブセットのみがサポートされます。これらの文については、後続の項で個別に説明します。

3. 文を、緑色のハイライト表示がノードに表示される(文をドロップできることを示します)まで目的のターゲット・ノードにドラッグします。

4. 文をドロップして、XSLTマップに挿入します。

この後の各項には、マップ・ビューを使用して追加できる様々なXSLT文が列挙されています。

- 「xsl:ifを使用した条件付き処理の追加方法」

- 「xsl:chooseを使用した条件付き処理の追加方法」

- 「xsl:for-eachを使用したループの追加方法」

- 「xsl:for-each文へのxsl:sortの追加方法」

- 「XSLT命令の複製方法」

40.3.4.4 xsl:ifを使用した条件付き処理の追加方法

それぞれのスキーマで、ソース・ノードおよびターゲット・ノードがオプションの場合、通常、xsl:if文は、対応するターゲット・ノードを作成する前にソース・ノードの存在をテストするために使用されます。

図40-11 では、「コメント」ノードは、ソースとターゲットの両方でオプションです。「コメント」ノードを囲んでいる大カッコは、これがオプションのノードであることを示しています。

図40-11 ソース・ツリーおよびターゲット・ツリーでのオプション・ノード

実行時にソースの「コメント」ノードがソース・ドキュメントに存在しない場合、この値は空になります。これによって、ターゲット・ドキュメントに「コメント」ノードが作成され、空の値が設定されます。

ソース・ノードが存在しない場合に空のノードが作成されないようにするには、ターゲットの「コメント」ノードの上にxsl:if文を追加します。xsl:if文は、ターゲット・ノードを作成する前に、ソース・ノードの存在をテストします。

40.3.4.4.1 コンテキスト・メニューを使用してxsl:if文を追加する手順:

1. ターゲット・ノードを右クリックして、表示されるコンテキスト・メニューから「XSL命令の追加」→「if」の順に選択します。xsl:ifノードが、ターゲット・ノードの親ノードとして追加されます。

2. xsl:ifノードの条件を設定するには、ソース・ノードをxsl:ifノードにドラッグ・アンド・ドロップします。

図40-12 xsl:ifノードへのソース・ノードのドラッグ

40.3.4.4.2 ドラッグ・アンド・ドロップを使用してxsl:if文を追加する手順:

1. 「コンポーネント」ウィンドウで、「XSLT要素」ページを選択します。

2. 「フロー制御」セクションを開きます。セクションを開くには、「フロー制御」の隣にあるプラス記号(+)をクリックします。

3. 緑色のハイライト表示が表示されるまで「if」アイコンをターゲット・ノードの右側にドラッグします(図40-13 を参照)。

図40-13 xsl:if文の追加

4. 緑色のハイライト表示が表示されている間に「if」アイコンをドロップします。xsl:ifノードが、ターゲット・ノードの親ノードとして追加されます。

5. xsl:ifノードの条件を設定するには、ソース・ノードをxsl:ifノードにドラッグ・アンド・ドロップします。

ソース・ビューで表示すると、xsl:if文は次のようになります。

<xsl:if test="/ns0:PurchaseOrder/ns0:Comment">
<tns1:Comment>
<xsl:value-of select="/ns0:PurchaseOrder/ns0:Comment"/>
</tns1:Comment>
</xsl:if>

前述のxsl:if文では、ソース・ノードが存在する場合にのみターゲット・ノードが作成されることを確認しています。

40.3.4.5 xsl:chooseを使用した条件付き処理の追加方法

xsl:choose文はxsl:ifコンストラクトと似ています。評価する条件が複数ある場合に、xsl:choose XSLT文を使用できます。

図40-14 に、ソース・スキーマとターゲット・スキーマのサンプルが含まれたXSLTマップ・エディタを示します。ソース・スキーマには、xsd:choiceコンストラクトが定義されています。ソース・スキーマには、HQAccountノードまたはBranchAccountノードのいずれかを含めることができますが、両方は含めません。ターゲット・スキーマには、定義する必要のあるBilledToAccountノードおよびAccountNumberノードがあります。

HQAccountノードが存在する場合は、このAccountNumberをターゲットのBilledToAccountおよびAccountNumberにコピーする必要があります。HQAccountノードが存在しない場合は、BranchAccountノードからAccountNumberをコピーする必要があります。xsl:choose文を使用してこのタスクを実行できます。

図40-14 ソース・スキーマおよびターゲット・スキーマのサンプルが含まれたXSLTマップ・エディタ

40.3.4.5.1 コンテキスト・メニューを使用してxsl:choose文を追加する手順:

1. ターゲット・ノードを右クリックして、表示されるコンテキスト・メニューから「XSL命令の追加」→「choose」の順に選択します。
choose文が、xsl:when文とともにターゲット・ノードの親ノードとして追加されます。図40-15 に、AccountNumberノードにxsl:choose文を追加した結果を示します。

図40-15 xsl:choose文の追加

xsl:choose文には、複数のxsl:when文の後にオプションのxsl:otherwise文を含めることができます。

2. xsl:otherwiseノードをxsl:chooseノードに追加するには、ターゲット・ツリーで「xsl:choose」を右クリックして、表示されるコンテキスト・メニューから「XSL命令の追加」→「otherwise」の順に選択します。
図40-16 に、xsl:choose文にxsl:otherwise文を追加した結果を示します。AccountNumberノードがxsl:choose文の各セクションにコピーされることに注意してください。

図40-16 xsl:choose文へのxsl:otherwise文の追加

3. 存在がテストされるソース・ノードにxsl:whenノードをマッピングします。現在の例では、ソースのHQAccountノードからターゲットのxsl:whenノードへ線をドラッグします。

4. xsl:whenケースとxsl:otherwiseケースをマッピングします。現在の例では、HQAccount/AccountNumberノードからxsl:choose/xsl:when/AccountNumberノードへ線をドラッグします。同様に、BranchAccount/AccountNumberノードからxsl:choose/xsl:otherwise/AccountNumberノードへ線をドラッグします。
図40-17 に、完成したxsl:chooseコンストラクトを示します。

図40-17 xsl:chooseコンストラクトのサンプル

40.3.4.5.2 ドラッグ・アンド・ドロップを使用してxsl:choose文を追加する手順:

1. 「コンポーネント」ウィンドウで、「XSLT要素」ページを選択します。

2. 「フロー制御」セクションを開きます。セクションを開くには、「フロー制御」の隣にあるプラス記号(+)をクリックします。

3. 緑色のハイライト表示が表示されるまで「choose」アイコンをターゲット・ノードの右側にドラッグします(図40-18 を参照)。

図40-18 ターゲット・ノードへの「choose」アイコンのドラッグ

4. 緑色のハイライト表示が表示されている間に「choose」アイコンをドロップします。xsl:chooseノードが、ターゲット・ノードの親ノードとして追加されます。xsl:chooseノードには、子xsl:whenノードが含まれています。

5. otherwise句を作成するには、「コンポーネント」ウィンドウから、「otherwise」アイコンを緑色のハイライト表示が表示されるまでxsl:chooseノードの左側にドラッグします(図40-19 を参照)。

図40-19 xsl:chooseノードへの「otherwise」アイコンのドラッグ

6. 緑色のハイライト表示が表示されている間に「otherwise」アイコンをドロップします。xsl:otherwiseノードが、xsl:chooseノードの子ノードとして追加されます。

7. 存在がテストされるソース・ノードにxsl:whenノードをマッピングします。現在の例では、ソースのHQAccountノードからターゲットのxsl:whenノードへ線をドラッグします。

8. xsl:whenケースとxsl:otherwiseケースをマッピングします。現在の例では、HQAccount/AccountNumberノードからxsl:choose/xsl:when/AccountNumberノードへ線をドラッグします。同様に、BranchAccount/AccountNumberノードからxsl:choose/xsl:otherwise/AccountNumberノードへ線をドラッグします。
図40-17 に、完成したxsl:chooseコンストラクトを示します。

ソース・ビューで表示すると、xsl:choose文は次のようになります。

<BilledToAccount>
<xsl:choose>
<xsl:when test="/ns0:PurchaseOrder/HQAccount">
<AccountNumber>
<xsl:value-of select="/ns0:PurchaseOrder/HQAccount/AccountNumber"/>
</AccountNumber>
</xsl:when>
<xsl:otherwise>
<AccountNumber>
<xsl:value-of select="/ns0:PurchaseOrder/BranchAccount/AccountNumber"/>
</AccountNumber>
</xsl:otherwise>
</xsl:choose>
</BilledToAccount>

40.3.4.6 xsl:for-eachを使用したループの追加方法

xsl:for-each文は、ソース・ノードセット、またはノードのセットをループ処理し、ソース・ノードセットの各ノードに出力ノードを作成するために使用できます。

40.3.4.6.1 コンテキスト・メニューを使用してxsl:for-each文を追加する手順:

1. ターゲット・ノードを右クリックして、表示されるコンテキスト・メニューから「XSL命令の追加」→「for-each」の順に選択します。xsl:for-each文が、ターゲット・ノードの親ノードとして追加されます。

2. ソース・ノードセットがループ処理するように設定するには、ソース・ノードをxsl:for-each文にドラッグ・アンド・ドロップします。
図40-20 に、xsl:for-each文の作成例を示します。ソースのPurchaseOrderドキュメントにはItemノードが含まれています。Itemノードはそのアイコンが表すとおり、繰返しノードです。ソース・ドキュメントの各Itemノードでxsl:for-each文を使用することで、Itemノードがターゲット・ドキュメントに作成されます。

図40-20 xsl:for-each文の作成

40.3.4.6.2 ドラッグ・アンド・ドロップを使用してxsl:for-each文を追加する手順:

1. 「コンポーネント」ウィンドウで、「XSLT要素」ページを選択します。

2. 「フロー制御」セクションを開きます。セクションを開くには、「フロー制御」の隣にあるプラス記号(+)をクリックします。

3. 緑色のハイライト表示が表示されるまで「for-each」アイコンをターゲット・ノードの右側にドラッグします(図40-21 を参照)。

図40-21 ターゲット・ノードへの「for-each」アイコンのドラッグ

4. 緑色のハイライト表示が表示されている間に「for-each」アイコンをドロップします。xsl:for-eachノードが、ターゲット・ノードの親ノードとして追加されます。

5. ソース・ノードセットがループ処理するように設定するには、ソース・ノードをxsl:for-each文にドラッグ・アンド・ドロップします(図40-20 を参照)。

ソース・ビューで表示すると、xsl:for-each文は次のようになります。

<ShippedItems>
<xsl:for-each select="/ns0:PurchaseOrder/Items/HighPriorityItems/Item">
<Item/>
</xsl:for-each>
</ShippedItems>

xsl:for-each文内で作成されたItemノードが、空のノードであることに注意してください。ターゲットのItemノードの下に要素をマッピングして、値を設定できます。

たとえば、図40-22 に示すように、QtyをQuantityにドラッグ・アンド・ドロップすると、Qty要素の値が出力のQuantity要素にコピーされます。

図40-22 QuantityへのQtyのマッピング

次の例は、作成されたコードをソース・ビューで示しています。さらに、ソース・ドキュメントおよび出力ドキュメントのスニペットのサンプルも示しています。

<ShippedItems>
<xsl:for-each select="/ns0:PurchaseOrder/Items/HighPriorityItems/Item">
<Item>
<Quantity>
<xsl:value-of select="Qty"/>
</Quantity>
</Item>
</xsl:for-each>
</ShippedItems>

ソース・ドキュメントのサンプル値の一部を次のスニペットに示します。

<HighPriorityItems>
<Item PartNum="000-AA">
<Qty>20</Qty>
</Item>
<Item PartNum="000-AB">
<Qty>24</Qty>
</Item>
</HighPriorityItems>

前述のソース・ドキュメントに対応する出力値を次のスニペットに示します。

<ShippedItems>
<Item>
<Quantity>20</Quantity>
</Item>
<Item>
<Quantity>24</Quantity>
</Item>
</ShippedItems>

xsl:for-each文で、XPath式は通常、xsl:for-each文で選択したノードに対して相対的なものです。たとえば、前の例で、Qtyは現在のItemノード/ns0:PurchaseOrder/Items/HighPriorityItems/Item:に対して相対的なものです。

<xsl:for-each select="/ns0:PurchaseOrder/Items/HighPriorityItems/Item">
<Item>
<Quantity>
<xsl:value-of select="Qty"/>
</Quantity>
</Item>
</xsl:for-each>

xsl:for-each文で絶対パスを使用すると意図しない結果が発生する可能性があります。たとえば、前の例で、相対パスのかわりに絶対パスを使用した場合、コードは次のようになります。

<ShippedItems>
<xsl:for-each select="/ns0:PurchaseOrder/Items/HighPriorityItems/Item">
<Item>
<Quantity>
<xsl:value-of
select="/ns0:PurchaseOrder/Items/HighPriorityItems/Item/Qty"/>
</Quantity>
</Item>
</xsl:for-each>
</ShippedItems>

この結果として生成される出力ドキュメントは次のようになります。

<ShippedItems>
<Item>
<Quantity>20</Quantity>
</Item>
<Item>
<Quantity>20</Quantity>       <!-- repeating incorrect value! -->
</Item>
</ShippedItems>

絶対パスは、Itemノードセット内で最初のQty要素を常に選択するため、出力の各Item要素に繰返し値が配置されることがわかります。

XSLTマップ・エディタは、可能な場合は、for-each文の下にノードをマッピングする際に相対パスを作成します。xsl:for-each文は、for-eachの下に表示されるノードをマッピングする前に作成することをお薦めします。for-eachを追加する前にQuantityなどのノードをマッピングすると、エディタによって警告が表示され、そのfor-eachに対してノードセットをマッピングするときに、絶対XPath式から相対パス式へのリファクタが試みられます。

注意:

- 自動マップを実行すると、必要に応じてxsl:for-each文が自動的に挿入されます。

- 設計には無限ループが含まれていないことが必要です。無限ループがあると、アプリケーションのデプロイメントおよび起動時に、次のようなエラーが表示されます。

ORAMED-04001:
. . .
oracle.tip.mediator.service.BaseActionHandler requestProcess
SEVERE:
failed reference BPELProcess1.bpelprocess1_client operation =  process

40.3.4.7 xsl:for-each文へのxsl:sortの追加方法

xsl:sort文をxsl:for-each文に追加して、ソート実行時の基準となるフィールドを指定できます。xsl:sort命令は、xsl:for-eachに対して、定義されたノードセットの特定の順序によるループ処理を実行させます。

40.3.4.7.1 コンテキスト・メニューを使用してxsl:sort文を追加する手順:

1. xsl:for-eachノードを右クリックして、表示されるコンテキスト・メニューから「XSL命令の追加」→「sort」の順に選択します。
「属性の設定」ダイアログが表示されます。

2. 必要に応じて、xsl:sort文に属性を指定します。「OK」をクリックします。
「属性の設定」ダイアログでは、xsl:sort文に対する属性を設定できます。属性は、ソートが実行される方法を制御します。たとえば、「order」属性を選択した場合、次にソート順として「昇順」または「降順」を選択できます。ソートに必要な属性を選択します。

注意:

属性のデフォルト値が、「属性の設定」ダイアログで事前に選択されています。これらの値は、選択された属性が存在しない場合に使用されます。

たとえば、ソート順序のデフォルトは昇順です。明示的に「order」属性を選択して、昇順を有効にする必要はありません。

xsl:sort文はxsl:for-each文のすぐ下に、for-eachの下にある他のノードの前に追加されます。

3. ソート対象の要素を設定するには、ノードをソースのノードセットの下からxsl:sortノードにドラッグ・アンド・ドロップします。たとえば、USPriceでソートするには、USPriceノードをノードセット要素Itemの下からxsl:sortノードにドラッグします(図40-23 を参照)。

図40-23 xsl:sortノードへのソースのノードセットの接続

40.3.4.7.2 ドラッグ・アンド・ドロップを使用してxsl:sort文を追加する手順:

1. 「コンポーネント」ウィンドウで、「XSLT要素」ページを選択します。

2. 「フロー制御」セクションを開きます。セクションを開くには、「フロー制御」の隣にあるプラス記号(+)をクリックします。

3. 緑色のハイライト表示が表示されるまで「sort」アイコンをfor-eachノードの下の要素の一番上にドラッグします(図40-24 を参照)。

図40-24 for-eachへのソートの追加

4. 緑色のハイライト表示が表示されている間に「sort」アイコンをドロップします。xsl:sortノードが、ハイライトされているノードの兄弟関係ノードとして追加されます。図40-24 に示す例では、xsl:sortノードはItem要素の兄弟関係として追加されます。

5. ソート対象の要素を設定するには、ノードをソースのノードセットの下からxsl:sortノードにドラッグ・アンド・ドロップします。たとえば、USPriceでソートするには、USPriceノードをノードセット要素Itemの下からxsl:sortノードにドラッグします(図40-23 を参照)。

ソース・ビューで表示すると、xsl:sort文は次のようになります。

<xsl:for-each select="/ns0:PurchaseOrder/Items/HighPriorityItems/Item">
<xsl:sort select="USPrice"/>
<Item>
<Quantity>
<xsl:value-of select="Qty"/>
</Quantity>
</Item>
</xsl:for-each>

40.3.4.8 XSLT命令の複製方法

XSLT命令をターゲット・ツリーで複製する必要がある場合があります。たとえば、2つのfor-each文を隣り合って作成し、ソース・ドキュメント内で2つのノードセットをループ処理するか、同じノードセットで2回ループ処理する場合があります。

xsl:ifやxsl:sortなどのその他のXSLT命令も複製できます。この項では、xsl:for-each文を使用した複製命令の作成について説明します。同じ手順が他のXSLT命令に適用されます。

xsl:for-each文を複製する手順は、次のとおりです。

1. ターゲット・ツリーでxsl:for-eachノードを右クリックして、表示されるコンテキスト・メニューから「重複」を選択します。

ノードがその子およびマッピングとともに複製されます。図40-25 は、重複ノードを示しています。

図40-25 xsl:for-each文の複製

2. 必要に応じて、xsl:for-eachノードのマッピングを変更するか、xsl:for-eachノードの下にあるノードのマッピングを変更します。

40.3.4.8.1 例: XPath式を変更することによるマッピングの変更

この例では、重複xsl:for-each文を変更して、ソース・ドキュメントにあるLowPriorityItemsノードの下でItemノードをループ処理させます。マッピングを変更する方法は複数あります。次の例は、マッピングを変更する1つの方法を示しています。

for-each文に関連付けられているXPath式を編集する場合は、for-eachの下にあるすべての相対マッピングが自動的に更新されます。次の手順を使用して、重複for-each文に関連付けられているXPath式を変更します。

1. XPath式を編集するには、2番目のfor-eachに接続されている線をダブルクリックします。これは、図40-25 では青い線です。
「XPathの編集」ダイアログが表示されます。「XPath式」フィールドに、このマップに対応するXPath式が表示されます。

2. XPath式で、HighPriorityItemsをLowPriorityItemsに変更します。「OK」をクリックします。

xsl:for-each文およびそのすべての子が、LowPriorityItems/Itemノードセットを参照するようになりました。

40.3.4.8.2 例: 削除および再作成によるマッピングの変更

for-each文のマッピングを変更するために、そのマッピングを削除して再作成することも選択できます。重複for-each文のマッピングを変更する手順を次に示します。

1. 重複xsl:for-eachノードを右クリックして、表示されるコンテキスト・メニューから「マッピングの削除」を選択します。
「XPathのリファクタ」ダイアログが表示され、for-each文の下でXPath式をリファクタするかどうかが確認されます。

2. リファクタするには、「いいえ」をクリックします。これによって相対パスが保持され、この相対パスを別のループに適用します。「いいえ」をクリックした後は、for-each文の下にある線が一時的にソース・ツリーから切断されます。

前述の図では、Quantityフィールドに関連付けられている相対XPath式はQtyです。for-each文にXPath式がないと、相対的に関連付けられるItemノードがないため、ソース・ツリーには参照がなくなります。

注意:

通常、ソース・ツリーのノードに解決できないXPath式は、中央のパネルに示されます。これは、前述のケースのように、問題を示す場合があります。上にfor-each式がないため、解決できない相対パスがあります。

設計時にソース参照ノードを特定するには式が複雑すぎる場合にも、XPath式が中央のペインに示されることがあります。

3. ソース・ツリーのLowPriorityItems/Itemノードから重複xsl:for-each文に、線をドラッグ・アンド・ドロップします。
次の図に示すように、Quantityフィールドへのマッピングは、LowPriorityItems/Itemノードの下にあるQtyフィールドに自動的に再接続されます。

40.3.5 要素の複製方法

マップ・ビューでターゲット・ノードを複製するためには、そのノードがターゲット・スキーマで繰返しノードとして定義されている必要があります。特定のケースでは、前述の項で説明したとおり、for-eachループを使用して繰返しノードを作成できます。その他の場合では、ノードの複数の独立インスタンスを作成し、ソース・ドキュメントの異なる領域を介して、データをそれらのインスタンスにマップする必要がある場合があります。

繰返しターゲット・ノードを複製する手順は、次のとおりです。

1. ターゲット・ノードのテキストがイタリック体でグレー表示されている場合は、そのノードを右クリックして、表示されるコンテキスト・メニューから「XSLT内のノードの作成」を選択します。

図40-26 XSLTでのノードの作成

2. ノードを再度右クリックして、表示されるコンテキスト・メニューから「重複」を選択します。ノードが複製されます。

図40-27 コンタクト・ノードの複製

3. ソース・ドキュメントから2つの重複要素に適切なフィールドをマッピングします。

次の図では、ターゲット・ツリーの重複Contactノードが、ソース・ドキュメントの異なる領域にマップされています。最初のContactノードはShipToデータにマッピングされています。2番目のContactノードは、BillToデータにマッピングされています。

40.3.6 要素または属性の削除方法

現在のXSLTマップから要素または属性を削除するには、その要素または属性が最初にXSLTに存在している必要があります。イタリック体でグレー表示でないターゲット・ツリーにあるノードは、XSLTに存在しているノードです。イタリック体でグレー表示されているノードは、XSLTの一部ではありません。そのようなグレー表示のノードは、ターゲット・スキーマの候補の要素および属性を表し、表示から削除することはできません。

XSLTに存在するターゲット・ノードを削除するには、次のいずれかを実行します。

- ターゲット・ノードをクリックして選択します。[Delete]キーを押します。

- ターゲット・ノードを右クリックして、表示されるコンテキスト・メニューから「削除」を選択します。

ノードがXSLTから削除され、そのノードへのマッピングも削除されます。削除されたノードは、表示からは削除されません。削除されたノードはイタリック体でグレー表示され、現在はターゲット・スキーマからの可能なターゲット・ノードであり、XSLTの一部ではないことを示します。ただし、削除されたノードが重複ノードであったか、ターゲット・スキーマに準拠しない位置にあった場合は、このノードは表示から削除されます。

次の図は、XSLTマップの一部である2つのCommentノードを示します。

2番目のCommentノードを右クリックして、コンテキスト・メニューから「削除」を選択した場合、次の図に示すとおり、重複ノードがXSLTおよび表示から削除されます。

次に、残りのCommentノードを右クリックして削除します。このノードは表示から削除されませんが、XSLTからは削除され、次の図に示すとおり、外観がグレーのイタリック体に変わります。

40.3.7 要素または属性からマッピングを削除する方法

ターゲット・ノードへのマッピングを削除するには、ターゲット・ツリーでノードを右クリックして、表示されるコンテキスト・メニューから「マッピングの削除」を選択します。または、マッピングを表す線を選択して[Delete]キーを押すこともできます

マップ・ビューでマッピングを削除する場合、マッピングされていたノードはXSLTから削除されません。ノードを削除するには、右クリックして、表示されるコンテキスト・メニューから「削除」を選択します。マッピングのみが削除されノードは削除されない場合、XSLTは実行時に空のノードを生成します。

40.4 XSLTビューでのXSLTマップの編集

この項では、XSLTビューのXSLTペインを使用した基本的な編集機能について説明します。次のリストに、XSLTビューでの編集とマップ・ビューでの編集の主な違いを示します。

- XSLTビューでは、XSLTノードとターゲット・スキーマのマージされたビューは提供されません。右側のターゲット・ペインは2つのペインに分割されています。上のペインはXSLTペイン、下のペインはターゲット・ペインと呼びます。ターゲット・スキーマが定義されていない場合、下のペインは表示されません。

- ターゲット・ノードをマッピングするには、マッピングの前にこれらのノードをXSLTペインに明示的に追加する必要があります。エディタには、これを行うための複数の方法が用意されています。これらについては後続の項で説明します。

- XSLT 1.0命令のすべての種類をXSLTビューで使用できます。これらの命令は、その位置がXSLT仕様と矛盾しない場合は、XSLTパネルの任意の場所に追加できます。

- テンプレート・ルール(一致するテンプレート)、名前付きテンプレート、インポート/インクルードなどの多数の拡張機能をXSLTビューで使用できます。これらの拡張機能については、この章で後述します。

40.4.1 マップ前にターゲットの要素または属性を追加する方法

ターゲット要素および属性にマッピングする前に、その要素または属性をXSLTペインに明示的に追加する必要があります。この項では、次の項目について説明します。

- ターゲット・スキーマからの要素および属性の追加方法

- ターゲット・スキーマがない場合のリテラル要素および属性の追加方法

- 出力ドキュメントでの空ノードの作成方法

40.4.1.1 ターゲット・スキーマからの要素および属性の追加方法

ターゲット・スキーマがある場合は、要素および属性をターゲット・ツリーからXSLTペインに追加できます。

XSLT要素または属性のコンテキスト・メニューを使用して関連要素/属性を追加するか、または目的の要素/属性をターゲット・ツリーからXSLTツリーにドラッグ・アンド・ドロップします。

要素がターゲット・スキーマと矛盾した位置にある場合、またはXSLTマップが不完全なため、その要素がその場所で有効かどうかをエディタで判別できていない場合、要素のアイコンの上に疑問符が表示されます。次の図は、アイテム要素が疑問符付きで表示されているXSLTツリーを示しています。

40.4.1.1.1 ターゲット・スキーマがある場合に要素および属性を追加する手順:

1. XSLTペインで、子要素または属性を含めようとする要素を右クリックします。コンテキスト・メニューが表示されます。

注意:

選択したノードがXSLTに存在する場合は、このアクションはマップ・ビューからも実行できます。

マップ・ビューでは、「XSLT内のノードの作成」を選択することで、空のXSLTノードを追加することもできます。詳細は、「出力ドキュメントでの空ノードの作成方法」を参照してください。

2. 「スキーマからの子の追加」を選択します。サブメニューが表示され、ターゲット・スキーマと一貫性のある選択肢が示されます。図40-28 は、「スキーマからの子の追加」サブメニューを示しています。

図40-28 追加する子要素/属性の選択

3. 追加する要素名または属性名を選択します。すべての子要素または属性を追加するには、「すべての要素」または「すべての属性」を選択します。必要な子要素または属性をすべて追加するには、「すべての必須」を選択します。

40.4.1.1.2 ターゲット・スキーマ・ツリーから要素および属性をドラッグ・アンド・ドロップする手順:

- 要素を既存の要素の子として挿入する手順は次のとおりです。
ターゲット要素または選択範囲の要素を、ターゲット・ペインからXSLTツリーの目的の要素の左側にドラッグします。緑色のハイライト表示が、その要素が子として挿入されることを示します。ドロップすると、その子が子のリストに追加されます。

緑色のハイライト表示が特定の位置に表示されない場合は、その要素をその位置に挿入するのは無効であることを示します。

- 要素を既存の要素の後に兄弟として挿入する手順は次のとおりです。
ターゲット要素または選択範囲の要素を、ターゲット・ペインからXSLTツリーの既存の要素の下部にドラッグします。緑色のハイライト表示が、その要素が兄弟として挿入されることを示します。ドロップすると、その兄弟が既存の要素の後に追加されます。

- 要素を既存の要素の前に兄弟として挿入する手順は次のとおりです。
ターゲット要素または選択範囲の要素を、ターゲット・ペインからXSLTツリーの既存の要素の上部にドラッグします。緑色のハイライト表示が、その要素が兄弟として挿入されることを示します。ドロップすると、その兄弟が既存の要素の前に追加されます。

- 要素を既存の要素の親として挿入する手順は次のとおりです。
ターゲット要素または選択範囲の要素を、ターゲット・ペインからXSLTツリーの既存の要素の右側にドラッグします。緑色のハイライト表示が、その要素が親として挿入されることを示します。ドロップすると、その要素が既存の要素の親として挿入されます。

40.4.1.2 ターゲット・スキーマがない場合のリテラル要素および属性の追加方法

この項は、XSLTビューとマップ・ビューの両方に適用されます。

40.4.1.2.1 ターゲット・スキーマがない場合にリテラル要素を追加する手順:

1. XSLTペインで要素を右クリックします。要素のコンテキスト・メニューが表示されます。

2. 既存の要素に関連付けられる新規リテラル要素の相対位置を選択します。リテラル要素は、既存の要素の子、兄弟または親として作成できます。図40-29 は、使用可能なオプション(「子の追加」、「親の挿入」、「兄弟を前に挿入」、「兄弟を後に挿入」)を示しています。

図40-29 XSLTペインへのリテラル要素の追加

3. サブメニューから「リテラル要素」を選択します。「要素の定義」ダイアログが表示されます。

4. 「ローカル名」に、リテラル要素の名前を入力します。オプションで、要素のネームスペースを指定できます。

5. 「OK」をクリックして、「要素の定義」ダイアログを閉じます。

40.4.1.2.2 ターゲット・スキーマがない場合にリテラル属性を追加する手順:

1. XSLTペインで既存のリテラル要素を右クリックします。リテラル要素のコンテキスト・メニューが表示されます。

2. 「子の追加」→「リテラル属性」を選択します。「要素の定義」ダイアログが表示されます。

3. 「ローカル名」に、リテラル属性の名前を入力します。オプションで、属性のネームスペースを指定できます。

4. 「OK」をクリックして、「属性の定義」ダイアログを閉じます。

40.4.1.3 出力ドキュメントでの空ノードの作成方法

前述の項(「ターゲット・スキーマからの要素および属性の追加方法」および「ターゲット・スキーマがない場合のリテラル要素および属性の追加方法」)で説明した方法を使用してノードをXSLTペインに追加する場合、これらのノードをソース・ノードにマッピングしないかぎり、空のノードとして作成されます。また、複合ノードをXSLTペインに追加する場合は、複合ノードの下の必要なすべてのノードが自動的に作成されます。

「XSLマップ: XSLエディタ・プリファレンス」ページでXSLマップの初期化オプションを設定して、マップの作成時に空のノードを生成することもできます。詳細は、「XSLエディタのプリファレンスの設定方法」を参照してください。

40.4.2 ノードのリンクによる値のコピーの実行方法

ソースの属性の値またはリーフ要素をXSLTペインの属性またはリーフ要素にコピーするには、ソース・ノードからXSLTノードに線をドラッグします。ドラッグ・アンド・ドロップすると、緑色にハイライト表示された線が表示されます。ドロップし終わると、ソース・ノードとターゲット・ノードをつなぐ線が描画されます。

図40-30 は、PurchaseOrder/IDソース要素がInvoice/ID XSLT要素にマッピングされているXSLTビューを示しています。ソースとXSLTノードが線でつながれます。

図40-30 値のコピーの実行

40.4.3 xsl:valueof文の挿入方法

前述の項の説明に従ってソース要素をXSLT要素にマッピングすると、暗黙的なxsl:valueof文がXSLTに作成されます。

XSLTビューでは、1つのXSLT要素に複数のxsl:valueof要素を明示的に作成できます。XSLT要素の結果の値は、個々のxsl:valueofの値を連結したものです。

XSLT要素のxsl:valueof要素を作成する手順は、次のとおりです。

1. XSLTペインでリテラル要素を右クリックします。コンテキスト・メニューが表示されます。

2. コンテキスト・メニューから「子の追加」→「XSL」→「value-of」の順に選択します。「属性の設定」ダイアログ・ボックスが表示されます。

3. オプションで、'disable output escaping'属性を選択します。「OK」をクリックします。

xsl:value-of要素が挿入されます。

4. xsl:value-of要素を、リテラル要素のマッピングと同様に、ソース要素にマッピングします。これは前述の項で説明しています。

xsl:value-of要素がマッピングされていないリテラル要素に追加された場合、マッピングされるまでxsl:value-of文がリテラル要素の下に表示されます。xsl:value-of要素をマッピングした後、エディタによってリテラル要素の下のxsl:value-of文が非表示にされ、マッピングを示す線のみが表示されます。

複数のxsl:value-of文をそのリテラル要素に追加した場合は、すべてのxsl:value-of文がリテラル要素の下に明示的に表示され、マッピングの線が各xsl:value-of要素に対して個別に表示されます。

40.4.4 XSLTノードのリテラル・テキスト値の設定方法

XSLTノードにリテラル・テキスト値を設定する手順は、次のとおりです。

1. XSLTペインでノードを右クリックします。表示されるコンテキスト・メニューから「テキスト値の編集」を選択します。

「テキストの設定」ダイアログが表示されます。

2. ノードに割り当てられるテキスト値を入力します。テキストを一重引用符で囲まないでください。

3. 「OK」をクリックします。

テキスト値が項目に設定されたことを示す黄色の「T」アイコンがノードの隣に表示されます。マウス・カーソルをノードに合せると、対応するテキストが表示されます。

40.4.5 xsl:text命令を使用したリテラル・テキスト値の設定方法

xsl:text命令を使用してリテラル要素の値を設定する手順は次のとおりです。

1. XSLTペインでリテラル要素を右クリックします。コンテキスト・メニューが表示されます。

2. コンテキスト・メニューから「子の追加」→「XSL」→「text」の順に選択します。「属性の設定」ダイアログ・ボックスが表示されます。

3. オプションで、'disable output escaping'属性を選択します。「OK」をクリックします。

xsl:text要素が挿入されます。

4. 新しく挿入されたxsl:text要素を右クリックし、表示されるコンテキスト・メニューから「テキスト値の編集」を選択します。

「テキストの設定」ダイアログ・ボックスが表示されます。

5. ノードに割り当てられるテキスト値を入力しますが、テキストを一重引用符で囲まないでください。

6. 「OK」をクリックします。

テキスト値が要素に設定されたことを示す黄色の「T」アイコンがxsl:textノードの隣に表示されます。マウス・カーソルをノードに合せると、対応するテキストが表示されます。

7. 任意の時点でテキスト値を変更するには、xsl:text要素を再度右クリックして、表示されるコンテキスト・メニューから「テキスト値の編集」を選択します。

40.4.6 XSLT文の追加方法

この手順はXSLTビューにのみ適用されます。XSLTは、「コンポーネント」ウィンドウまたはコンテキスト・メニューを使用して追加できます。

40.4.6.1 コンテキスト・メニューを使用してXSLT要素を追加する手順:

1. XSLTペインで要素を右クリックします。要素のコンテキスト・メニューが表示されます。

2. 既存の要素に関連付けられる新規要素の相対位置を選択します。リテラル要素は、既存の要素の子、兄弟または親として作成できます。使用可能なオプションは、「子の追加」、「親の挿入」、「兄弟を前に挿入」および「兄弟を後に挿入」です。

3. サブメニューから「XSL」を選択します。その位置で有効なXSLT要素のリストが表示されます。図40-31 は、XSLの選択例を示しています。

図40-31 XSLT要素の挿入

4. 目的のXSLT要素を選択します。
選択した要素によっては、ダイアログで属性値の入力を求められる場合があります。その場合は、属性値を入力して「OK」をクリックします。

5. XSLT要素がツリーに追加されます。
追加された要素の属性は、XSLTツリーに明示的に表示されません。マウス・カーソルを要素の上に置き、ツールチップ・テキストに属性を表示します。または、XSLT要素を選択して、「プロパティ」ウィンドウで要素のプロパティを表示して編集します。

40.4.6.2 「コンポーネント」ウィンドウからXSLT要素を追加する手順:

1. 「コンポーネント」ウィンドウが表示されていることを確認します。デフォルト位置はOracle JDeveloperの右上隅です。

2. 「コンポーネント」ウィンドウが表示されていない場合は、「ウィンドウ」メニューから「コンポーネント」を選択します。

3. 「XSLT要素」ページを選択します。

4. 「XSLT要素」の目的のセクションを選択します。目的のXSLT要素をXSLTペインにドラッグします。

- XSLT要素を既存の要素の子として挿入する手順は次のとおりです。
XSLT要素を、「コンポーネント」ウィンドウからXSLTツリーの既存の要素の左側にドラッグします。緑色のハイライト表示が、XSLT要素が子として挿入されることを示します。ドロップすると、XSLT要素が既存の子の末尾に追加されます。

緑色のハイライト表示が特定の位置に表示されない場合は、その要素をその位置に挿入するのは無効であることを示します。

- XSLT要素を既存の要素の後に兄弟として挿入する手順は次のとおりです。
XSLT要素を、「コンポーネント」ウィンドウからXSLTツリーの既存の要素の下部にドラッグします。緑色のハイライト表示が、XSLT要素が兄弟として挿入されることを示します。ドロップすると、XSLT要素が既存の要素の後に追加されます。

- XSLT要素を既存の要素の前に兄弟として挿入する手順は次のとおりです。
XSLT要素を、「コンポーネント」ウィンドウからXSLTツリーの既存の要素の上部にドラッグします。緑色のハイライト表示が、XSLT要素が兄弟として挿入されることを示します。ドロップすると、XSLT要素が既存の要素の前に追加されます。

- XSLT要素を既存の要素の親として挿入する手順は次のとおりです。
XSLT要素を、「コンポーネント」ウィンドウからXSLTツリーの既存の要素の右側にドラッグします。緑色のハイライト表示が、XSLT要素が親として挿入されることを示します。ドロップすると、XSLT要素が既存の要素の親として追加されます。

選択したXSLT要素によっては、ダイアログで属性値の入力を求められる場合があります。その場合は、属性値を入力して「OK」をクリックします。

5. XSLT要素がツリーに追加されます。
追加された要素の属性は、XSLTツリーに明示的に表示されません。マウス・カーソルを要素の上に置き、ツールチップ・テキストに属性を表示します。または、XSLT要素を選択して、「プロパティ」ウィンドウで要素のプロパティを表示して編集します。

40.4.7 XSLT式属性の値の設定方法

多くのXSLT命令には、XPath式として解析される特殊な属性が含まれています。これらの式属性は、通常、selectまたはtestという名前です。たとえば、xsl:for-each要素にはselect属性が、xsl:if要素にはtest属性が含まれます。

こうした属性はXPath式で定義できます。これらの属性の値は、XSLTペイン(XSLTビューの場合)またはターゲット・ペイン(マップ・ビューの場合)のXSLT要素に、ドラッグ・アンド・ドロップを使用して設定できます。

ソース・ツリーからのドラッグ・アンド・ドロップを使用してXSLT式属性の値を設定するには、ソース・ツリーの目的のノードからXSLTペインの目的のXSLT要素に、線をドラッグします。ソース・ツリーのノードとXSLT要素をつなぐ線が表示されます。

ソース・ビューではXSLT命令に適切な式属性が挿入されます。次に例を示します。

<xsl:if test="/ns0:PurchaseOrder/BillTo/Address/@country">

前述の例のコードは、ソース・スキーマのcountry属性をXSLTツリーのxsl:if文にドラッグすることにより作成されます。このコードは、if条件でソース・スキーマ内にcountry属性があるかどうかをテストします。

40.4.8 要素の複製方法

ターゲット・スキーマで繰返しノードとして定義されているXSLTペインにリテラル要素を複製するには、「要素の複製方法」の手順を使用します。この手順はマップ・ビューでの手順と同じです。

ターゲット・スキーマが定義されていない場合は、ルート・ノードを除くすべてのノードをXSLTビューで複製できます。

ノードは複製する必要があるが、ターゲット・スキーマで繰返しノードとして定義されていない場合は、次のように、リテラル要素を明示的に作成することで重複ノードを作成できます。

ターゲット・スキーマで繰返しノードとして定義されていないリテラル要素を複製する手順は、次のとおりです。

1. XSLTペインで、複製する要素を右クリックします。コンテキスト・メニューが表示されます。

2. コンテキスト・メニューから「兄弟を後に挿入」→「リテラル要素」の順に選択します。「要素の定義」ダイアログが表示されます。

3. 複製するノードの要素名およびネームスペースを入力します。「OK」をクリックします。

40.4.9 要素または属性の削除方法

この機能はXSLTビューとマップ・ビューの両方で使用できます。マップ・ビューを使用する場合、処理はターゲット・ペインで実行されます。

XSLTに存在するターゲット・ノードを削除するには、次のいずれかを実行します。

- XSLTペインでノードを右クリックします。表示されたコンテキスト・メニューから「削除」を選択します。

- XSLTペインでノードをクリックして選択します。[Delete]キーを押します。

そのノードに対するマッピングとともにノードがXSLTペインから削除されます。

40.4.10 要素の移動方法

XSLTペインで、ある位置からドラッグして別の位置へドロップすることで要素を移動できます。要素を移動して、別の要素の兄弟、親または子にすることもできます。マップ・ビューでは要素を移動できません。

図40-32 では、XSLTペインで正しくない位置にあるAccountNumber要素を示しています。ターゲット・スキーマで一貫性のあるようにするには、AccountNumber要素をBilledToAccount要素の下に移動する必要があります。

図40-32 AccountNumber要素

XSLTペインで、AccountNumber要素をBilledToAccount要素の左側に緑色のハイライト表示が表示されるまでドラッグします(図40-33 を参照)。緑色のハイライト表示は、AccountNumber要素がBilledToAccountの子としてドロップされることを示しています。

図40-33 AccountNumberノードのドラッグ

緑色のハイライトが表示されている間に要素をドロップします。AccountNumberノードの位置がBilledToAccountノードの下に変わります(図40-34 を参照)。

図40-34 位置が変更されたAccountNumberノード

40.4.11 要素または属性からマッピングを削除する方法

XSLTノードからマッピングを削除するには、ノードを右クリックし、コンテキスト・メニューで「マッピングの削除」を選択します。または、マッピングを表す線を選択して[Delete]キーを押すこともできます前述の方法は、マップ・ビューとXSLTビューの両方で使用できます。

40.5 XPath式の使用

「ノードのリンクによる値のコピーの実行方法」および「ノードのリンクによる値のコピーの実行方法」では、ドラッグ・アンド・ドロップ操作を使用して、ソースの要素または属性とターゲットの要素または属性との間のマッピングを作成する方法について説明しました。ドラッグ・アンド・ドロップではXSLTにXPath式が作成され、この式はソース・ドキュメントの特定のノードを参照します。

たとえば、次のXSLTコードは、ソース要素をターゲット要素にマッピングすることで生成されます。

<ID>
<xsl:value-of select="/ns0:PurchaseOrder/ID"/>
</ID>

前述のコードにはxsl:value-of文が含まれています。この文のselect属性にはXPath式(/ns0:PurchaseOrder/ID)が含まれており、これはマッピングされるソース・ノードを参照します。

このXPath式は、ロケーション・パス式を表します。XPath式は複雑にでき、XPath関数および演算子を含むこともできます。

たとえば、次のコードは、ソース要素/PurchaseOrder/IDの値を属性/PurchaseOrder/@PONumberの値に連結します。その後、その結果がターゲット要素<ID>に割り当てられます。

<ID>
<xsl:value-of select="concat(/ns0:PurchaseOrder/ID,/ns0:PurchaseOrder/@PONumber )"/>
</ID>

前述のコードで、select属性の値はXPath式です。XPath式では、concat関数を使用して、2つのソース・ノードの値を連結します。

XSLTマップ・エディタには、簡単なドラッグ・アンド・ドロップ・アクションによって作成されるよりも複雑なXPath式を入力するための多数の方法が用意されています。XPath式を作成するための次の方法は、マップ・ビューとXSLTビューの両方で使用できます。

40.5.1 既存のソースとターゲットのマッピングの変更方法

ソースとターゲットのノード間にドラッグ・アンド・ドロップ・アクションで作成されたマッピングのXPath式を変更できます。

40.5.1.1 「XPathの編集」ダイアログを使用してXPath式を編集する手順

1. ソースからターゲットへのマッピングを表す線をダブルクリックします。「XPathの編集」ダイアログが表示されます。

2. 「XPathの編集」を必要に応じて編集します。
たとえば、「説明」フィールドにソースで最初に発生するコメントを含める場合は、最初のコメントのインデックスを持つ式に条件を追加します。

XPath式の編集に関するその他の情報が必要な場合は、「ヘルプ」をクリックします。

3. 「XPathの編集」ダイアログで「OK」をクリックします。

40.5.1.2 「プロパティ」ウィンドウを使用してXPath式を編集する手順

1. 「プロパティ」ウィンドウが表示されていない場合は、Oracle JDeveloperのメニュー・バーから「ウィンドウ」→「プロパティ」の順に選択します。
「プロパティ」ウィンドウのデフォルトの場所は、XSLTマップ・エディタの下です。

2. ソースからターゲットへのマッピングを表す線をクリックして選択します。「プロパティ」ウィンドウには、選択したマップ線に対応するXPath式が表示されます。

3. 「XPathの編集」を必要に応じて編集します。
たとえば、「説明」フィールドにソースで最初に発生するコメントを含める場合は、最初のコメントのインデックスを持つ式に条件を追加します。

XPath式の編集に関するその他の情報が必要な場合は、「プロパティ」ウィンドウで「ヘルプ」アイコンをクリックします。

4. 変更内容でXSLTを更新するには、「プロパティ」ウィンドウの左上隅にある「変更の適用」アイコンをクリックします。または、XSLTマップ・エディタの任意の場所をクリックします。

40.5.1.3 XPath関数の既存のXPath式への追加方法

既存のソースからターゲットへのマッピングの上に関数をドラッグ・アンド・ドロップできます。マップ上に関数をドロップすると、ドロップされた関数の最初のパラメータを移入するために既存のロケーション・パス式が使用されます。

次の手順では、前述の項(「既存のソースとターゲットのマッピングの変更方法」)で編集した式を変更します。concat関数を使用して、ソースの最初のコメントをソースの説明を連結します。

XPath関数を既存のXPath式に追加する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウが表示されていない場合は、Oracle JDeveloperのメニュー・バーから「ウィンドウ」→「コンポーネント」の順に選択します。

2. 「コンポーネント」ウィンドウで、「一般XPath」を選択します。隣にあるプラス記号(+)をクリックして「文字列関数」セクションを開きます。

3. 「concat」関数アイコンを、「文字列関数」セクションから編集する既存のマップを表す線にドラッグします。線が、関数をドロップできることを示す緑色に変わります。

4. 「concat」関数を線の上にドロップします。関数がマップに挿入され、concat関数の最初のパラメータが既存のXPath式の値に設定されます。

注意:

関数をマップに追加しない場合、その関数はパラメータを持たない可能性があります。たとえば、「xp20:current-date」関数を既存の線にドロップした場合に、「xp20:current-date」関数はパラメータをとらないため、効果がありません。

40.5.2 キャンバス・ペインでの既存の関数XPath式の変更方法

XPath関数はキャンバス・ペインに表示され、いくつかの方法で編集できます。前述の項(「XPath関数の既存のXPath式への追加方法」)の例から引き続き、concat関数の2番目のパラメータの値をいくつかの方法で設定します。

40.5.2.1 ドラッグ・アンド・ドロップを使用して関数パラメータを設定する手順:

1. ソース・ツリーのDescription要素からキャンバス・ペインの「concat」関数アイコンの左側まで線をドラッグします。関数のそれぞれの可能なパラメータに対するコネクタが含まれているポップアップ・パネルが表示されます。

2. 目的のコネクタに線をドロップします。前述の図では、2番目に必要なパラメータを示す2番目のコネクタ上に線をドロップしています。3番目のオプションのパラメータ上に線をドロップして、2番目のパラメータ値を後で入力することも選択できます。
パラメータが関数に追加されます。必要なすべてのパラメータを追加すると、警告アイコンが表示されなくなります。

40.5.2.2 関数パラメータを削除する手順:

関数パラメータを削除するには、関数パラメータへの入力を示す線を選択して、[Delete]キーを押します。または、線を右クリックして、コンテキスト・メニューから「削除」を選択します。

40.5.2.3 完全XPath式としての関数の編集方法

「XPathパスの編集」ダイアログまたは「プロパティ」ウィンドウの「XPathパスの編集」パネルを使用して、XPath関数をテキストのXPath式として編集できます。

40.5.2.3.1 XPathの編集ダイアログを使用して関数をテキストのXPath式として編集する手順:

1. キャンバス・ペインの関数のアイコンの境界領域で式フォルダをダブルクリックします。「XPathの編集」ダイアログが表示されます。

かわりに中央のアイコンをダブルクリックすると、「関数の編集」ダイアログが表示されます。

2. 「XPath式」を必要に応じて編集します。DescriptionノードにXPathのロケーション・パスを追加するには、たとえば、最初のパラメータの後ろにカーソルを置きます。[Ctrl]を押しながら[Space]を押して、「/ns0:PurchaseOrder」をダブルクリックして選択します。

/ns0:PurchaseOrderが式の挿入され、/ns0:PurchaseOrderノードの可能な子がドロップダウン・メニューに移入されます。

3. 「Description」エントリをダブルクリックして選択します。マウス・カーソルをエントリ上に置き、[Enter]キーを押して選択することもできます。

4. 「XPathの編集」ダイアログで「OK」をクリックします。

40.5.2.3.2 「プロパティ」ウィンドウを使用して関数をテキストのXPath式として編集する手順:

1. 「プロパティ」ウィンドウが表示されていない場合は、Oracle JDeveloperのメニュー・バーから「ウィンドウ」→「プロパティ」の順に選択します。
「プロパティ」ウィンドウのデフォルトの場所は、XSLTマップ・エディタの下です。

2. キャンバス・ペインの関数のアイコンの境界領域で式フォルダをクリックします。「プロパティ」ウィンドウの右側のペインに、関数の完全な「XPath式」が表示されます。

3. 「XPath式」を必要に応じて編集します。前述の手順の手順2から3も参照してください。

4. 変更内容でXSLTを更新するには、「プロパティ」ウィンドウの左上隅にある「変更の適用」アイコンをクリックします。または、XSLTマップ・エディタの任意の場所をクリックします。

40.5.2.4 関数の個々のパラメータの編集方法

各パラメータのXSLTを別の「XPath式」フィールドで編集できるように、XPathマップ・エディタでは関数を対応するパラメータに解析できます。

40.5.2.4.1 「関数の編集」ダイアログを使用して関数のパラメータを編集する手順:

1. キャンバス・ペインで関数のアイコンをダブルクリックします。「関数の編集」ダイアログが表示されます。

中央の関数のアイコンをダブルクリックしてください。関数のアイコンの境界領域をダブルクリックすると、「XPathの編集」ダイアログが表示されます。

2. 必要に応じて、関数パラメータをそれぞれ編集します。「ヘルプ」をクリックして、パラメータの編集に関する情報を確認することもできます。

3. 必要に応じて、新しいパラメータを追加するには、緑色のプラス記号(+)で表される「追加」アイコンをクリックします。

4. パラメータの編集が終了したら「OK」をクリックします。

40.5.2.4.2 「プロパティ」ウィンドウを使用して関数のパラメータを編集する手順:

1. 「プロパティ」ウィンドウが表示されていない場合は、Oracle JDeveloperのメニュー・バーから「ウィンドウ」→「プロパティ」の順に選択します。
「プロパティ」ウィンドウのデフォルトの場所は、XSLTマップ・エディタの下です。

2. キャンバス・ペインで関数のアイコンの中央領域をクリックします。「プロパティ」ウィンドウの右側のペインに、関数パラメータが表示されます。

3. 必要に応じて、関数パラメータを編集します。「ヘルプ」アイコンをクリックして、パラメータの編集に関する情報を確認することもできます。

4. 必要に応じて、新しいパラメータを追加するには、緑色のプラス記号(+)で表される「追加」アイコンをクリックします。

5. 変更内容でXSLTを更新するには、「プロパティ」ウィンドウの左上隅にある「変更の適用」アイコンをクリックします。または、XSLTマップ・エディタの任意の場所をクリックします。

40.5.3 キャンバス・ペインでの新しい関数の作成方法

XSLTキャンバス・ペインで新しい関数を作成するには、いくつかの方法があります。これらについては、後続の各項で説明します。

40.5.3.1 キャンバスのコンテキスト・メニューを使用してXPath関数を作成する手順

1. キャンバス・ペインの中央の空白領域を右クリックします。表示されるコンテキスト・メニューで「XPathの作成」を選択します。

2. 「XPathの作成」のサブメニューから、必要な関数を選択します。たとえば、「日付関数」カテゴリから「current-date」関数を選択します。

関数をターゲット・ノードに接続するように求める「情報」ダイアログが表示される場合があります。「OK」をクリックします。

キャンバス・ペインに関数のアイコンが表示されます。

3. 関数からターゲット・ノードに線をドラッグすることで、関数をターゲット・ノードにマッピングします。

4. 関数でパラメータが必要な場合は、「キャンバス・ペインでの既存の関数XPath式の変更方法」で説明する方法の1つを使用してパラメータを編集します。

40.5.3.2 「コンポーネント」ウィンドウを使用してXPath関数を作成する手順

1. 「コンポーネント」ウィンドウが表示されていない場合は、Oracle JDeveloperのメニュー・バーから「ウィンドウ」→「コンポーネント」の順に選択します。

2. 「コンポーネント」ウィンドウで、「一般XPath」または「拡張XPath」を選択します。関数のカテゴリ(たとえば「文字列関数」)を選択します。

3. 「コンポーネント」ウィンドウからXSLTマップ・エディタのキャンバス・ペインの中央に目的の関数をドラッグします。

4. 関数からターゲット・ノードに線をドラッグすることで、関数をターゲット・ノードにマッピングします。

5. 関数でパラメータが必要な場合は、「キャンバス・ペインでの既存の関数XPath式の変更方法」で説明する方法の1つを使用してパラメータを編集します。

40.5.3.3 ターゲット・ツリーのコンテキスト・メニューを使用してXPath関数を作成する手順

1. XPath関数を割り当てる必要のあるターゲット・ツリー・ノード(マップ・ビュー)またはXSLTツリー・ノード(XSLTビュー)を右クリックします。コンテキスト・メニューが表示されます。

2. 「XPathの作成」を選択します。表示されるサブメニューから、必要なXPath関数を選択します。

関数がキャンバス・ペインで作成され、作成されたターゲット・ノードまたはXSLTノードにリンクされます。

3. 関数でパラメータが必要な場合は、「キャンバス・ペインでの既存の関数XPath式の変更方法」で説明する方法の1つを使用してパラメータを編集します。

40.5.3.4 ターゲット・ツリーにドラッグすることでXPath関数を作成する手順

1. 「コンポーネント」ウィンドウが表示されていない場合は、Oracle JDeveloperのメニュー・バーから「ウィンドウ」→「コンポーネント」の順に選択します。

2. 「コンポーネント」ウィンドウで、「一般XPath」または「拡張XPath」を選択します。関数のカテゴリ(たとえば「文字列関数」)を選択します。

3. 目的の関数を「コンポーネント」ウィンドウから、関数を割り当られるターゲット・ツリー・ノード(マップ・ビュー)またはXSLTツリー・ノード(XSLTビュー)にドラッグします。ターゲットまたはXSLTのツリー・ノードの左側に緑色のハイライト表示が表示されます。

4. 緑色のハイライト表示が表示されている間に関数をドロップします。
関数がキャンバス・ペインで作成され、関数がドロップされたターゲット・ノードまたはXSLTノードにリンクされます。

5. 関数でパラメータが必要な場合は、「キャンバス・ペインでの既存の関数XPath式の変更方法」で説明する方法の1つを使用してパラメータを編集します。

40.5.4 関数をまとめて連鎖させる方法

関数を別の関数と連鎖させる手順は次のとおりです。

関数の連鎖(ある関数の出力を別の関数の入力にマップすること)によって、複雑な式を作成できます。たとえば、concat関数の出力から先頭と末尾の空白をすべて削除するには、次の手順を実行します。

1. left-trim関数とright-trim関数をconcat関数の枠線の領域にドラッグします。

2. 図40-35 に示すように、一方の関数の出力側から次の関数の入力側に線をドラッグして、2つの関数を連鎖します。

連鎖は、関数を接続リンクにドラッグ・アンド・ドロップして実行することもできます。

図40-35 関数の連鎖

40.5.5 XPath式の削除方法

XPath式を削除する手順は次のとおりです。

1. キャンバス・ペインでXPath式/関数のアイコンを選択します。

2. アイコンを右クリックして、コンテキスト・メニューから「削除」を選択します。

40.5.6 ユーザー定義関数のインポート方法

XSLTまたはXPath式で実行できない複雑な機能がある場合は、ユーザー定義のJava関数を作成し、インポートできます。

次の手順に従って、ユーザー独自の関数を作成して使用します。ロジックが複雑すぎるためにXSLマップ内で実行できない場合は、外部のユーザー定義関数が必要になる場合があります。

ユーザー定義関数をインポートする手順は、次のとおりです。

1. 関数をコーディングし、作成します。

XSLTマップ・エディタの拡張関数のコード方法は、Oracle BPELプロセス・マネージャの拡張関数とは異なります。mapper-107-extension-functionsサンプル・シナリオのSampleExtensionFunctions.javaファイルには、2つの例があります。これらのサンプルやその他のサンプルをダウンロードするには、Oracle SOA Suiteサンプルを参照してください。

各関数は、静的関数として宣言する必要があります。入力パラメータと戻り値は、次のいずれかのタイプで宣言する必要があります。

- java.lang.String

- int

- float

- double

- boolean

- oracle.xml.parser.v2.XMLNodeList

- oracle.xml.parser.v2.XMLDocumentFragment

これらの関数のテキストは、次のとおりです。

// SampleExtensionFunctions.java
package oracle.sample;
/*
This is a sample XSLT Map Editor User Defined Extension Functions implementation
class.
*/
public class SampleExtensionFunctions
{
public static Double toKilograms(Double lb)
{
return new Double(lb.doubleValue()*0.45359237);
}
public static String replaceChar(String inputString, String oldChar, String
newChar )
{
return inputString.replace(oldChar.charAt(0), newChar.charAt(0));
}
}

2. XML拡張関数構成ファイルを作成します。このファイルは関数とそのパラメータを定義します。

このファイルの名前は、ext-mapper-xpath-functions-config.xmlに設定する必要があります。このファイルのフォーマットの詳細は、「ユーザー定義XPath拡張関数の作成」を参照してください。次の構文は、手順1でコードされている関数toKilogramsおよびreplaceCharを表します。

<?xml version="1.0" encoding="UTF-8"?>
<soa-xpath-functions version="11.1.1"
xmlns="http://xmlns.oracle.com/soa/config/xpath" xmlns:sample=
"http://www.oracle.com/XSL/Transform/java/oracle.sample.SampleExtensionFunctions"
>
<function name="sample:toKilograms">
<className>oracle.sample.SampleExtensionFunctions</className>
<return type="number"/>
<params>
<param name="pounds" type="number"/>
</params>
<desc>Converts a value in pounds to kilograms</desc>
</function>
<function name="sample:replaceChar">
<className>oracle.sample.SampleExtensionFunctions</className>
<return type="string"/>
<params>
<param name="inputString" type="string"/>
<param name="oldChar" type="string"/>
<param name="newChar" type="string"/>
</params>
<desc>Returns a new string resulting from replacing all occurrences
of oldChar in this string with newChar</desc>
</function>
</soa-xpath-functions>

XSLT拡張関数の定義には、他にいくつかのルールが適用されます。

- 関数にはネームスペースの接頭辞とネームスペースが必要です。この例では、sampleとhttp://www.oracle.com/XSL/Transform/java/oracle.sample.SampleExtensionFunctionsとなります。

- Oracle XSLTプロセッサと連携する拡張関数の場合、関数ネームスペースはhttp://www.oracle.com/XSL/Transform/java/で始まる必要があります。

- ネームスペースの後半部は、この例ではoracle.sample.SampleExtensionFunctionsですが、拡張関数を実装したJavaクラスの完全な修飾名である必要があります。

- 表40-1 に示したタイプおよび等価のJavaタイプは、パラメータと戻り値に対して使用できます。

表40-1 タイプおよび等価のJavaタイプ

XML構成ファイルのタイプ名

Javaタイプ

string

java.lang.String

boolean

boolean

number

int、float、double

node-set

oracle.xml.parser.v2.XMLNodeList

tree

oracle.xml.parser.v2.XMLDocumentFragment

3. XML構成ファイルとコンパイル済クラスの両方が含まれたJARファイルを作成します。構成ファイルは、JARファイル用のMETA-INFディレクトリに格納される必要があります。この項の例の場合、ディレクトリ構造は、JARファイルにoracleディレクトリとMETA-INFディレクトリが追加され、次のようになります。

- oracle

- sample(クラス・ファイルが格納されます。)

- META-INF

- ext-mapper-xpath-functions-config.xml

次に、JARファイルをOracle JDeveloperに登録する必要があります。

4. 「ツール」→「プリファレンス」→「SOA」の順に選択します。

5. 「追加」ボタンをクリックし、JARファイルに移動して選択します。

6. Oracle JDeveloperを再起動します。

新しい関数は、「コンポーネント」ウィンドウで、「ユーザー定義」ページの「ユーザー定義拡張関数」グループに表示されます。

7. 関数をランタイム環境で使用できるようにする方法の詳細は、「ユーザー定義関数のランタイムへのデプロイ方法」を参照してください。

40.6 自動マップを使用した複合ノードのマッピング

非リーフ・ソース要素を非リーフ・ターゲット要素にマッピングする際は、自動マップ機能により、子ソース要素がそれに対応するターゲット要素に自動的に一致します。自動マップでは要素の名前、タイプおよびパスを確認して、正しいマッピングを提示します。また、自動マップでは、プリファレンスに応じてオプションのノードのxsl:if文を挿入できます。

自動マップ機能は、ターゲット・スキーマが使用される場合にのみ使用できます。マップ・ビューとXSLTビューの両方で、自動マップを使用できます。

40.6.1 自動マップのプリファレンスの設定方法

「プリファレンス」ダイアログを使用して、自動マップ機能の動作を指定できます。「ツール」メニューで「プリファレンス」を選択します。左側のナビゲーション・ツリーで、「XSLマップ」の下の「自動マップ」を選択します。図40-36 は、自動マップのプリファレンスのデフォルト設定を示しています。

図40-36 「自動マップ・プリファレンス」

次のリストは、構成可能な「自動マップ・プリファレンス」の様々な設定について説明しています。

- 自動マップの結果を確認: このオプションを選択すると、一致するソースおよびターゲット要素を自動的にマッピングする前に、「自動マップ」にそれらの要素のリストが表示されます。一致した組合せの中から、適用するものを選択できます。

- 自動マップの前にプリファレンスをプロンプト: このオプションを選択すると、2つの複合ノードをマッピングしようとするたびに「自動マップ・プリファレンス」ダイアログが表示されます。

- モード: 自動マップを基本モードまたは拡張モードのどちらで実行するかを指定します。モード選択により、このダイアログで表示される残りのオプションが決まります。

「基本モード」を選択した場合に使用できる残りのオプションは、次のとおりです。

- 類似した名前による要素の一致: 類似した名前の要素が一致します。

- 完全な名前による要素の一致: 完全に同じ名前の要素が一致します。

- 完全なタイプによる要素の一致: 完全に同じデータ・タイプの要素のみが一致します。

- 祖先名を考慮した要素の一致: 一致の際、要素名とともに要素のパスも考慮されます。

- xsl:ifの挿入: xsl:if文を自動的に挿入するかどうかを指定します。次の設定が使用されます。

- なし: xsl:if文は自動的には挿入されません。

- ソース・ノードが存在していることを確認: xsl:if文は、出力でノードが作成される前に、ソース・ノードの存在を確認して挿入されます。

- ソース・ノードが空でないことを確認: xsl:if文は、出力でノードが作成される前に、ソース・ノードが空でないことを確認して挿入されます。

「拡張モード」を選択した場合に使用できる残りのオプションは、次のとおりです。

- 祖先の重み: 祖先の一致の重要度を示す0から5の数字です。0の数字は、基本モードでの「祖先名を考慮した要素の一致」オプションの選択解除に対応します。5の数字は、基本モードでの「祖先名を考慮した要素の一致」オプションの選択に対応します。

- 言語の重み: 要素名の一致の重要度を示す0から5の数字です。0の数字は、要素名が一致している必要がないことを示します。5の数字は、要素名が完全に一致している必要があることを示します。

- タイプの重み: 要素名の一致の重要度を示す0から5の数字です。0の数字は、要素タイプが一致している必要がないことを示します。5の数字は、要素タイプが完全に一致している必要があることを示します。

- 一致のしきい値(%): 自動マップで、各マップ(祖先、言語、タイプ)の一致率を計算して、その中で最も高い割合を選択します。最も高い一致率がしきい値の割合を超える場合に、一致が作成されます。

- ディクショナリ: 既存のディクショナリを自動マップに追加できます。ディクショナリは、既存のマップから定義し、後続のマップで使用できます。

40.6.2 自動マップの実行方法

自動マップを実行する手順は次のとおりです。

1. 複合ソース・ノードをXSLTペインのターゲット要素にドラッグ・アンド・ドロップします。マップ・ビューを使用している場合は、ソース・ノードをターゲット・ペインのノードにドロップします。

2. 「自動マップ・プリファレンス」によっては、「プリファレンス」ダイアログが表示されることがあります。自動マップのプリファレンスを選択し、「OK」をクリックします。

3. 「自動マップ・プリファレンス」によっては、「自動マップ」ダイアログが表示されることがあります。自動マップで作成された一致を検証し、「OK」をクリックします。

40.7 マップの完了ステータスの確認

マップでターゲット・スキーマを使用している場合は、マップの完了ステータスをいつでも確認できます。これは、マップ・ビューとXSLTビューの両方で実行できます。完了ステータスを確認すると、次のものにフラグが付きます。

- マップされていないすべてのターゲット要素および属性。フラグは、ターゲット要素がターゲット・スキーマで必要な要素であるかどうかを示します。

- 不完全なXPath式でマッピングされたターゲット要素。たとえば、ターゲット・ノードにマッピングされたXPath関数のパラメータが失われている場合があります。

- 失われたすべてのターゲット要素および属性。フラグは、失われたターゲット要素がターゲット・スキーマで必要な要素であるかどうかを示します。

マップの完了ステータスを確認するには、キャンバス・ペイン(中央)を右クリックし、コンテキスト・メニューで「完了ステータス」を選択します。「完了ステータス」ダイアログが表示され、不完全なターゲット・ノードがすべて示されます。完了ダイアログ・ステータスの行をクリックして、XSLT/ターゲット・ツリーで対応するノード位置を選択します。図40-37 は、失われたノードがハイライト表示されている「完了ステータス」ダイアログを示しています。

図40-37 「完了ステータス」ダイアログ

40.8 マップのテスト

XSLTマップ・エディタには、マップをテストするためのツールが用意されています。テスト・ツールを起動するには、キャンバス・ペインを右クリックし、コンテキスト・メニューから「テスト」を選択します。このテスト・ツールは、マップ・ビューとXSLTビューの両方で使用できます。

図40-38 は、「XSLマップのテスト」ダイアログを起動する様子を示しています。

図40-38 テスト・ダイアログの起動

40.8.1 トランスフォーメーション・マッピングのロジックをテストする方法

図40-39 に示す「XSLマップのテスト」ダイアログでは、XSLTマップ・エディタで設計したトランスフォーメーション・マッピングのロジックをテストできます。指定したテスト設定は保存されるため、次回のテスト時に再度入力する必要はありません。Oracle JDeveloperを閉じて再度開いた場合は、テスト設定をもう一度入力する必要があります。

図40-39 「XSLマップのテスト」ダイアログ

トランスフォーメーション・マッピングのロジックをテストする手順は、次のとおりです。

1. 「ソースXMLファイル」フィールドで、テスト用にサンプルのソースXMLファイルを生成するか、「参照」をクリックして別のソースXMLファイルを指定します。
「OK」をクリックすると、ソースXMLファイルが検証されます。検証に合格するとトランスフォーメーションが実行され、ターゲットXMLファイルが作成されます。

検証に失敗した場合、トランスフォーメーションは実行されず、画面にメッセージが表示されます。

2. マップ・ソースXSDスキーマに基づいてサンプルのXMLファイルを作成するには、「ソースXMLファイルの生成」チェック・ボックスを選択します。

3. 「ソースXMLファイルの表示」チェック・ボックスを選択し、テスト用のソースXMLファイルを表示します。ソースXMLファイルがOracle JDeveloperのXMLエディタに表示されます。
マップに定義済のパラメータがある場合は、「スキーマのあるパラメータ」または「スキーマのないパラメータ」表が表示されます。

a. 「スキーマのあるパラメータ」表が表示された場合は、「参照」ボタンを使用してそのパラメータの入力XMLファイルを指定できます。「ファイルの生成」チェック・ボックスを選択して、ファイルを生成します。

b. 「スキーマのないパラメータ」表が表示された場合は、「値の指定」チェック・ボックスを選択し、「タイプ」列および「値」列を適切に編集して値を指定できます。

4. 「ターゲットXMLファイル」フィールドにファイル名を入力するか、トランスフォーメーションからの結果XML文書が格納されるファイルの名前を参照します。

5. テスト用のターゲットXMLファイルを表示するには、「ターゲットXMLファイルの表示」チェック・ボックスを選択します。ターゲットXMLファイルがOracle JDeveloperのXMLエディタに表示されます。

6. ソースとターゲット両方のXMLを表示する場合は、XMLエディタのレイアウトをカスタマイズできます。右上隅にある「自動レイアウトの有効化」を選択してパターンの1つをクリックします。

7. 「OK」をクリックします。
図40-40 に示すように、テスト結果が表示されます。

この例では、ソースXMLとターゲットXMLが並んで表示され、その下にXSLマップが表示されています(デフォルト設定)。「スキーマのあるパラメータ」表に対応する追加のソースXMLファイルが、メイン・ソース・ファイルと同じ場所にタブとして表示されます。エディタを右クリックして「XMLの検証」を選択すると、ソースまたはターゲットのXMLを、マップのソースまたはターゲットのXSDスキーマと照合して検証できます。

図40-40 テスト結果

40.8.1.1 DVM参照関数を使用するXSLTマップをテストする方法

DVM参照関数が含まれているXSLTマップをテストできます。ローカル・ファイルまたはMDSのファイルを参照するDVM参照関数をマップで使用する場合で、これらのファイルにJDeveloper環境からアクセスできる場合は、追加の手順を実行する必要はありません。

JDeveloper環境からアクセスできないファイルを参照するDVM参照関数をマップで使用している場合は、テスト用にローカルのDVMファイルを作成でき、XSLTのDVM参照を変更する必要はありません。次の手順に従います。

1. XSLTテストをまだ実行していない場合は、このテスト・ツールを一度実行します。このテスト・ツールによって、XSLNonDeployedFilesフォルダにUnitTestURLs.dvmが生成され、XSLTファイルと同じフォルダに配置されます。

UnitTestURLs.dvmファイルには、XSLTファイルのDVM参照とローカルのテスト・ファイルへのDVM参照間のマッピングが含まれています。テストするXSLTファイルにファイル(oramds:/apps/AIAMetaData/dvm/CUSTOMERPARTY_STATUSCODE.dvm)への参照があるが、JDeveloperのこのファイルへのアクセス権がない場合は、テストを実行するファイルに対してローカルのDVM参照ファイルを作成できます。

2. JDeveloperで、XSLNonDeployedFilesフォルダにあるUnitTestURLs.dvmファイルを開きます。

3. 「serverURL」列の下に、XSLTで参照するDVMファイルへの参照を追加します。

4. 「testURL」列の下に、テストで使用するローカル・ファイルへの参照を追加します。

5. UnitTestURLs.dvmファイルを保存します。

6. テストDVMファイルにテスト・データを移入します。

7. テスト・ツールを実行します。参照はローカル・ファイルに対して実行されます。このローカル・ファイルを指すようにXSLTを変更する必要はありません。テストでは、UnitTestURLs.dvmファイルを使用して、「serverURL」列に定義されている参照用の正しいテスト・ファイルを参照します。

40.8.1.2 XREF関数を使用するXSLTマップをテストする方法

ローカルのdvm参照ファイル(UnitTestXrefFunctionReturn.dvmという名前)を使用して、テストをエミュレートできます。このファイルは、XSLTテストを最初に実行したときに自動的に生成されます。

UnitTestXrefFunctionReturn.dvmファイルには、すべてのXREF関数に対するデフォルトのレスポンスが含まれています。これによって、関数が正しく実行されたときに予想されるレスポンスをシミュレートします。デフォルトのレスポンスは変更できます。さらに、パラメータ値が異なる場合に、同じ関数の別の呼出しに対して異なる戻り値を作成することもできます。

次の図はDVMファイルの最初の状態を表しています。

図40-41 UnitTestXrefFunctionReturn.dvmファイル

「FunctionName」列には関数の名前を指定します。最初は、各関数にデフォルトの動作が定義された1つのエントリのみがあります。すべてのXREF関数は、このデフォルト情報を使用して実行されます。必要に応じて、指定された関数にさらにエントリを作成したり、入力パラメータに基づいて関数に別の戻り値を入力できます。

「returnValue」列には関数の戻り値を指定します。これには、関数から返される値を定義します。

その他の列には、指定されたパラメータの値に基づいて、1つの関数コールを別の関数コールと区別するために使用できる修飾子を定義します。これらの各列には、指定された関数コールで使用可能なパラメータを定義します。すべてのパラメータがすべての関数で使用できるわけではありません。パラメータが使用できない場合は、元の表にNA (使用不可)とマークされます。

40.8.1.2.1 returnValueの使用:

「returnValue」列は、SBL_001などのテキスト値として定義されるか、パラメータ名によって定義されるかのいずれかです。たとえば、最初の関数であるlookupXRefを見ると、この関数にはRefColumnValueという戻り値があります。これはパラメータの名前(RefColumnValue)であるため、このパラメータの値は、XSLTに対する関数の戻り値です。

たとえば、lookupXRef関数に対して次のようなコールを実行するとします。

lookupXRef( oramds:/apps/AIAMetaData/xref/CUSTOMERPARTY_PARTYLOCATIONID.xref",
"COMMON_ID", "COMMON_001", "SBL_ID", false())

これは渡されたRefColumnValueパラメータの値のため、値COMMON_001が返されます。

markForDelete関数では、値trueが返され、ブールに変換されます。

lookupXRef1M関数およびlookupPopulatedColumns関数では、関数によってノードセットが返されます。このノードセットには、次の書式の要素が含まれています。

<column name="columnNameHere">columnValueHere</column>

図40-41 に示すとおり、lookupXRef1M関数のデフォルト値は次のとおりです。

:RefColumnName:RefColumnValue:ColumnName:RefColumnValue

これによって、関数からノードセットで返される2つの列ノードの列名と値がエンコードされます。最初の文字は、情報の解析で使用されるデリミタを定義します。データにコロン(:)が含まれている場合は、デリミタとしてテスト・データにない任意の文字を使用できますが、その文字を最初の文字として配置し、データを区切るために使用する(#abc:def#abc:ghiなど)ことで使用できます。

たとえば、lookupXRef1Mに対して次の関数コールを実行するとします。

lookupXRef1M ("oramds:/mydata", "COMMON_ID", "COMMON_001", "SAP_ID", false())

:RefColumnName:RefColumnValue:ColumnName:RefColumnValueの戻り値にデフォルト定義を使用すると、次の2つの列要素が返されます。

<column name="COMMON_ID">COMMON_001</column>
<column name="SAP_ID">COMMON_001</column>

:SAP_ID:SAP_001:SBL_ID:SBL_001:ORCL_ID:ORCL_001のreturnValueを持つようにDVMで行を変更した場合、関数によって次の3つの列ノードが返されます。

<column name="SAP_ID">SAP_001</column>
<column name="SBL_ID">SBL_001</column>
<column name="ORCL_ID">ORCL_001</column>

40.8.1.2.2 追加行の追加:

DVMファイルに行を追加することもできます。パラメータに別の入力値を指定することで、関数に追加の行を追加して、別の戻り値が返されるようにできます。

たとえば、同じXREFファイルに対して複数の参照が設定されているときに、参照ごとに異なる値を返したい場合に、DVMファイルのlookupXRefに次の行を追加できます。

正しい戻り値の決定では、デザインタイム・エミュレータは、DVM表の一番下から開始して、パラメータ値の最初に一致する値を検索します。最初の一致行に対応する戻り値が返されます。

前述の図に示すとおり、たとえば、lookupXRef("oramds:/apps/AIAMetaData/xref/CUSTOMERPARTY_PARTYLOCATIONID.xref", "COMMON_ID", "COMMON_001", "SBL_ID", false()),に対するコールでは、値SBL_001が返されます。

一方、lookupXRef("oramds:/apps/AIAMetaData/xref/CUSTOMERPARTY_PARTYLOCATIONID.xref", "COMMON_ID", "COMMON_002", "SBL_ID", false())に対するコールでは、最後の3行に一致するものがないため、デフォルト値COMMON_002 (パラメータRefColumnValueの値)が返されます。

40.8.2 レポートの生成方法

次の情報を備えたHTMLレポートを生成できます。

- XSLマップのファイル名、ソース・スキーマとターゲット・スキーマのファイル名、そのルート要素名、およびそのルート要素のネームスペース

- ターゲット・ドキュメントのマッピング

- マップされていないターゲット・フィールド(必須フィールドを含む)

- サンプル・トランスフォーメーション・マップの実行

次の手順に従って、レポートを生成します。

1. キャンバス・ペイン(中央)で右クリックして、「XSLTマップのレポートの生成」を選択します。

図40-42 に示すように、「レポートの生成」ダイアログが表示されます。マップのパラメータが定義されている場合は、適切なパラメータ表が表示されます。

図40-42 「レポートの生成」ダイアログ

フィールドの詳細は、「レポートの生成」ダイアログのオンライン・ヘルプを参照してください。

40.8.3 サンプルXML生成のカスタマイズ方法

サンプルXMLの生成は、次のパラメータを指定してカスタマイズできます。Oracle JDeveloperの「ツール」メイン・メニューで、「プリファレンス」→「XSLマップ」の順に選択し、「プリファレンス」ダイアログを表示します。「サンプルXMLの生成」で次の設定を変更できます。

- 繰返し要素の数
この数は、要素の属性maxOccursが1より大きい値に設定されている場合に、要素の繰返し作成数を指定します。指定した値が特定の要素に対するmaxOccurs属性の値より大きい場合、その特定の要素に対する繰返し作成数は、指定した数ではなく、このmaxOccursの値となります。

- オプション要素の生成
選択されている場合は、オプション要素(その属性minOccursが値0に設定されている)が必須要素(その属性minOccursが0より大きい値に設定されている)と同様に生成されます。

- 最大の深さ
サンプルXMLの生成において、オプション要素による再帰の発生を回避するために、オプション要素の生成限度であるXML文書階層ツリーの最大の深さを指定します。

40.9 外部XSLTマップのインポート

JDeveloper以外のエディタで開発されたXSLTマップがある場合、そのマップをJDeveloperにインポートできます。

外部マップをインポートする手順は次のとおりです。

1. 「ファイル」メイン・メニューから、「新規」→「ギャラリから」を選択します。

2. 「カテゴリ」で「一般」→「XML」を選択します。「アイテム」で「XSLスタイルシートからのXSLマップ」を選択します。「OK」をクリックします。「XSLTチューザ」ダイアログが表示されます。

3. インポートするXSLTファイルを選択します。「OK」をクリックします。ファイルが開き、ソースまたはターゲット・スキーマ定義のないデフォルト・ヘッダーが挿入されます。

4. ソースおよびターゲットのスキーマ定義を作成するには、キャンバス・ペイン(中央)を右クリックし、「ソース・スキーマの置換/追加」を選択してソース・スキーマを設定します。「ターゲット・スキーマの置換/追加」を選択して、ターゲット・スキーマを設定します。

注意:

インポートしたマップは、ソースおよびターゲット・スキーマが両方とも定義され、マップ・ビューでサポートされないXSLT機能がない場合にのみ、マップ・ビューを使用できます。

すべてのマップはXSLTビューを使用できます。

40.10 変数およびパラメータの使用

変数およびパラメータをXSLTマップに追加できます。これらは、マップ・ビューとXSLTビューの両方で使用できます。

40.10.1 グローバル変数の追加方法

グローバル変数は、マップ・ビューとXSLTビューの両方で使用できます。

グローバル変数を作成するには:

1. ソース・ペインの任意のノードを右クリックし、コンテキスト・メニューから「グローバル変数の追加」を選択します。または、XSLTツールバーに緑色のプラス記号で表示される「追加」アイコンをクリックして、「グローバル変数の追加」を選択します。このオプションは、「作成」オプションの下にあるキャンバスのコンテキスト・メニューでも使用できます。

「変数」ダイアログが表示されます。

2. 変数の名前、および必要な場合はオプションのネームスペースおよび接頭辞を入力します。

3. 「OK」をクリックします。

XSLTビューとマップ・ビューのどちらを使用しているかに応じて、XSLTペインまたはターゲット・ペインの最上部に変数ノードが表示されます。

この変数は、「変数」フォルダのソース・ツリーにも表示されます。これにより、変数からXPath式またはターゲット・ツリーのノードにマッピングできます。

注意:

現在のリリースの変数に対して構造を定義することはできません。参照している変数が複雑な構造を示す場合は、適切なXPath式を手動で入力することで、構造内のノードを参照できます。

40.10.2 マップ・ビューでのローカル変数の追加方法

マップ・ビューでローカル変数を追加する手順は、次のとおりです。

1. ターゲット・ツリーで既存のノード(イタリック体のグレー表示でない)を右クリックして、表示されるコンテキスト・メニューから「XSL命令の追加」→「variable」の順に選択します。

「変数」ダイアログが表示されます。

2. 変数の名前、および必要な場合はオプションのネームスペースおよび接頭辞を入力します。

3. 「OK」をクリックします。

変数が、ターゲット・ツリーの選択したノードのすぐ上に追加されます。

この変数は、「変数」フォルダのソース・ツリーにも表示されます。これにより、変数からXPath式またはターゲット・ツリーのノードにマッピングできます。

変数が特定のXSLTノードまたはXPath式のスコープ内にあるかどうかを判別するには、ターゲット・ツリー・ノードまたはXPath式を選択します。変数がターゲット・ツリー・ノードまたはXPath式のスコープ内にある場合、その変数はソース・ツリーに太字で表示されます。変数が選択したターゲット・ツリー・ノードまたはXPath式のスコープ内にない場合、その変数は無効化された状態でソース・ツリーに表示されます。

スカラー変数のみを定義できます。変数の構造は定義できません。参照している変数が複雑な構造を示す場合は、適切なXPath式を手動で入力することで、構造内のノードを参照できます。

40.10.3 XSLTビューでのローカル変数の追加方法

XSLTビューでは、ローカル変数は、その他のXSLT要素と同じ方法で追加されます。コンテキスト・メニューまたは「コンポーネント」ウィンドウを使用したXSLT要素の追加の詳細は、「XSLT文の追加方法」を参照してください。

そこでたとえば、XSLTノードのコンテキスト・メニューで「兄弟を前に挿入」→「XSL」→「変数」を選択すると、「変数」ダイアログ・ボックスが表示されます。変数名を入力し、オプションでネームスペースを指定して、「OK」をクリックします。

XSLT/ターゲット・ペインの適切な場所に変数が表示されます。XPath式をその変数にマッピングして、変数の値を設定することを選択できます。

この変数は、「変数」フォルダのソース・ツリーにも表示されます。これにより、変数から他のXPath式またはXSLTノードにマッピングできます。

変数が特定のXSLTノードまたはXPath式のスコープ内にあるかどうかを判別するには、XSLTノードまたはXPath式を選択します。変数がXSLTノードまたはXPath式のスコープ内にある場合、その変数はソース・ツリーに太字で表示されます。変数が選択されたXSLTノードまたはXPath式のスコープ内にない場合、その変数はソース・ツリーに無効化して表示されます。

スカラー変数のみを定義できます。変数の構造は定義できません。参照している変数が複雑な構造を示す場合は、適切なXPath式を手動で入力することで、構造内のノードを参照できます。

注意:

XSLT 1.0を使用して、複雑な変数を使用する場合、XPath式を使用して変数内のノードにアクセスする前に、ora:node-set関数内で変数を折り返す必要がある場合があります。

たとえば、myVar変数が次のような構造になっているとします。

<xsl:variable name="myVar">
<A>
<B>sometext</B>
</A>
</xsl:variable>

Bのテキストはora:node-set($myVar)/A/Bとして参照できます。このnode-set関数はXSLT 2.0では不要です。

40.10.4 グローバル・パラメータの追加方法

パラメータは、グローバル・パラメータおよび名前付きテンプレート・パラメータの両方として、XSLTマップ・エディタに追加できます。

グローバル・パラメータは、XSLTマップの作成時に追加できます。詳細は、「XSLTマップの作成方法」を参照してください。グローバル・パラメータを既存のマップに追加することもできます。

グローバル・パラメータを既存のマップに追加する手順は次のとおりです。

1. ソース・ペインの任意のノードを右クリックし、コンテキスト・メニューから「グローバル・パラメータの追加」を選択します。

または、XSLTツールバーに緑色のプラス記号で表示される「追加」アイコンをクリックして、「グローバル・パラメータの追加」を選択します。図40-43 に、XSLTマップ・エディタの最上部にあるXSLTツールバーを示します。

図40-43 XSLTツールバーからのグローバル・パラメータの追加

キャンバス(中央)・ペインの任意の場所を右クリックし、コンテキスト・メニューから「作成」→「グローバル・パラメータの追加」の順に選択することもできます。

「パラメータの追加」ダイアログが表示されます。図40-44 に、「パラメータの追加」ダイアログを示します。

図40-44 「パラメータの追加」ダイアログ

2. パラメータの「ローカル名」を入力し、オプションでネームスペースを指定します。

パラメータが複合パラメータの場合は、パラメータにスキーマおよび要素定義を指定できます。ダイアログの「ヘルプ」ボタンをクリックすると、個々のフィールドの詳細情報が表示されます。

3. 「パラメータの追加」ダイアログで「OK」をクリックして、パラメータを作成します。

ターゲット・ペイン(マップ・ビューの場合)またはXSLTペイン(XSLTビューの場合)の適切な場所にパラメータ・ノードが表示されます。これにより、XPath式をパラメータにマッピングして、パラメータのデフォルト値を設定できます。

このパラメータはソース・ツリーにも表示されます。これにより、パラメータをXPath式またはXSLTツリー内のノードにマッピングできます。

注意:

他のXSLT要素のように、パラメータを追加することもできます。コンテキスト・メニューまたは「コンポーネント」ウィンドウを使用したXSLT要素の追加の詳細は、「XSLT文の追加方法」を参照してください。

40.11 要素およびタイプの置換

ソース・ツリーとターゲット・ツリーの要素とタイプは置換できます。

要素置換は、次の場合に使用します。

- 要素が、基礎となるスキーマ内の置換グループの先頭として定義されている場合。要素は抽象でも抽象でなくてもかまいません。置換グループの任意の要素を元の要素と置換できます。

- 要素がany要素として定義されている場合。スキーマに定義されているすべてのグローバル要素を置換できます。

タイプ置換は、次の場合に使用します。

- 基礎となるスキーマでグローバル・タイプを使用でき、そのタイプがソース・ツリーまたはターゲット・ツリーの要素のタイプから導出されている場合。この場合は、グローバル・タイプを要素の元のタイプと置換できます。抽象タイプから導出された任意のタイプをその抽象タイプと置換できます。

- ソース・ツリーまたはターゲット・ツリーの要素がanyTypeタイプとして定義されている場合。この場合は、スキーマに定義されている任意のグローバル・タイプを置換できます。

タイプ置換は、XMLのxsi:type属性の使用によってサポートされます。

ソース・ツリーとターゲット・ツリーの要素またはタイプを置換する手順は、次のとおりです。

1. ソース・ツリーまたはターゲット・ツリーで、置換を適用する要素を右クリックします。XSLTペインを使用している場合は、選択した要素が、置換の前にXSLTに存在する必要があります。

2. コンテキスト・メニューから「要素またはタイプの置換」を選択します。このオプションが無効な場合、基礎となるスキーマの要素またはそのタイプに対して可能な置換はありません。

図40-45 に示す「要素またはタイプの置換」ダイアログが表示されます。

図40-45 「要素またはタイプの置換」ダイアログ

3. 要素の置換またはタイプの置換のいずれかを選択します(基礎となるスキーマによっては1つしか使用できない場合があります)。

置換可能なグローバル・タイプまたは要素のリストがダイアログに表示されます。

4. 置換するタイプまたは要素を選択します。

5. 「OK」をクリックします。

要素またはタイプが、最初に選択した要素と置換されます。この選択によって表示される結果は、次の項で説明する、置換の種類および置換の実行場所によって異なります。

- タイプ置換の場合

- ソース・ツリーでのタイプ置換

前述の図に示すように、元の要素の下にxsi:type属性が追加されます。ノードが置換されたことを示す「S」アイコンが要素に表示されます。置換タイプ内のxsi:type属性を含む任意の構造要素からマッピングできます。

注意:

要素置換とは異なり、ソース・ツリーに表示できるタイプ置換は一度に1つのみです。ただし、ソースで元のタイプと置換タイプの切換えが可能なマップが作成できなくなるわけではありません。

ソース・ツリーでノードが表示されず、そのノードがXPath式にマッピングされている場合、ノードにマッピングされているXPath式は、中央のキャンバス・ペインには表示されます。

- マップ・ビューのターゲット・ツリーでのタイプ置換

前述の図に示すように、元の要素の下にxsi:type属性が追加されます。この属性はマップ・ビューでは無効化されているため、選択されたタイプ値に設定されます。ノードが置換されたことを示す「S」アイコンが要素に表示されます。置換タイプ内のxsi:type属性を除く任意の構造要素にマッピングできます。

- XSLTビューのXSLTペインでのタイプ置換
元の要素の下にxsi:type属性が追加されます。その値は選択されたタイプ値に設定されますが、マッピングされる可能性があります。ノードが置換されたことを示す「S」アイコンが要素に表示されます。「スキーマからの子の追加」コンテキスト・メニュー・オプションを使用して、任意の構造要素を追加できます。

XPath文を使用して「xsi:type」フィールドの値を動的に設定する必要がある場合があります。xsi:typeの値を動的に設定する必要がある場合は、タイプ置換を使用して、実行時に予想される値が必要な構造要素に対して一時的なアクセス権を提供できます。

必要な要素を追加し、目的のXPath文をxsi:type属性にマッピングして、値を動的に設定します。xsi:typeのランタイム値はデザインタイムには使用できないため、その値が動的に設定されている場合に、タイプ値に依存する要素上に疑問符アイコン(?)が表示されます。

- XSLTビューのターゲット・ペインでのタイプ置換
XSLTビューのターゲット・ペインでも置換を実行できます。このペインは、ターゲット・スキーマ・ドキュメントを表します。ターゲット・ペインでタイプ置換を実行後、次の図に示すとおり、元の要素の下にxsi:type属性がそのタイプに関連付けられている構造要素とともに追加されます。

必要に応じて、これらの要素を選択して、XSLTペインにドロップできます。これらの要素は、XSLTペインの使用可能な「スキーマからの子の追加」コンテキスト・メニュー・オプションにも表示されます。

たとえば、次の図では、置換要素(Item)のすべての子を選択します。

次に、次の図に示すとおり、新しいItemノードをItemsノードの子としてXSLTペインにドロップします。

Itemノードおよびその子が、Itemsノードの子として追加されます。ターゲット・ペインで、別の置換から別の構造を同様に作成できます。

- 要素置換の場合

- ソース・ツリーでの要素置換
元の要素と置換された要素の両方がソース・ツリーに表示され、青い大カッコで接続されています。置換されたノードに「S」アイコンが表示されます。置換要素内の任意の構造要素からマッピングできます。

前述の図では、ns1:ShipFutureDateがAny要素に置換されています。

次の図に示すとおり、複数の要素を同時に置換することもできます。

- マップ・ビューのターゲット・ツリーでの要素置換

前述の図に示すとおり、元の要素と置換された要素の両方が青い大カッコで接続されています。置換されたノードに「S」アイコンが表示されます。置換要素内の任意の構造要素にマップできます。

- XSLTビューのXSLTペインでの要素置換
XSLTペインで要素を置換するには、元の要素はXSLTに表示可能な要素である必要があります。Any要素はXSLTペインに表示できないため、次の項で説明するように、XSLTビューのターゲット・ペインで置換する必要があります。抽象要素はXSLTペインに一時的に追加できますが、最終出力としては使用しないでください。置換グループの先頭であり抽象ではない要素は、通常の要素として使用でき、変換もできます。

次の図のns0:attachment要素は、置換グループの先頭でもある抽象要素です。これに対する置換がXSLTペインで実行されると、この要素はその置換で置き換えられます。

置換後に、抽象要素が選択した要素で置換されます。「S」アイコンは置換を示します。「スキーマからの子の追加」コンテキスト・メニューを使用して、置換された要素に子要素を追加できます。次の図はこれについて示しています。

- XSLTビューのターゲット・ペインでの要素置換
XSLTビューのターゲット・ペインでも置換を実行できます。ターゲット・ペインは、ターゲット・スキーマ・ドキュメントを表します。ターゲット・ペインで要素置換を実行後、次の図に示すように、置換された要素は元の要素の下にそのタイプに関連付けられている構造要素とともに追加されます。

必要に応じて、これらの要素を選択して、XSLTペインにドロップできます。これらの要素は、XSLTペインの使用可能な「スキーマからの子の追加」コンテキスト・メニュー・オプションにも表示されます。

6. 置換ノードを削除するには、「S」アイコンがあるノードを右クリックし、コンテキスト・メニューから「置換の削除」を選択します。

7. 置換が可能なすべてのノードを表示するには、ソース・ツリーまたはターゲット・ツリーを右クリックして、「置換ノード・アイコンの表示」を選択します。

図40-46 に示すように、置換が可能なすべてのノードには、「*」アイコンが表示されます。

図40-46 可能なすべての置換

8. アイコンを非表示にするには、右クリックして「置換ノード・アイコンの非表示」を選択します。

40.12 名前付きテンプレートの使用

名前付きテンプレートをXSLTマップに追加できます。これらのテンプレートはXSLTマップ・エディタ内で編集できます。名前付きテンプレートは、xsl:call-template命令を使用して起動できます。

名前付きテンプレートは、XSLTビューでのみ使用できます。名前付きテンプレートをXSLTマップに追加すると、そのマップはXSLTビューでのみ開くことができます。

40.12.1 名前付きテンプレートの作成方法

新規の名前付きテンプレートを作成する手順は次のとおりです。

1. XSLTペインで空白の領域を右クリックし、コンテキスト・メニューから「新規名前付きテンプレート」を選択します。あるいは、次のようにします。

- キャンバス・ペイン(中央)で空白の領域を右クリックし、コンテキスト・メニューから「作成」→「新規名前付きテンプレート」を選択します。

- ソース・ペインの任意のソース・ノードを右クリックし、コンテキスト・メニューから「新規名前付きテンプレート」を選択します。

- XSLTツールバーに緑色のプラス(+)アイコンで表示される「追加」ボタンを選択し、「新規名前付きテンプレート」を選択します。

「名前付きテンプレートの追加」ダイアログが表示されます。

2. テンプレートの名前を入力します。オプションで、ネームスペースを設定します。

「ヘルプ」をクリックすると、ダイアログで使用できるオプションのヘルプを表示できます。

3. 必要に応じて、緑色のプラス(+)アイコンで表される「追加」ボタンをクリックして、パラメータを追加します。「パラメータの追加」ダイアログが表示されます。

4. パラメータの名前を入力します。オプションで、ネームスペースを設定します。

パラメータが複合パラメータの場合は、パラメータにスキーマおよび要素定義を指定できます。ダイアログの「ヘルプ」ボタンをクリックすると、個々のフィールドの詳細情報が表示されます。

5. 「パラメータの追加」ダイアログで「OK」をクリックして、パラメータを追加します。

6. 名前付きテンプレートに必要なパラメータがあれば、さらに追加します。

7. 「名前付きテンプレートの追加」ダイアログで「OK」をクリックして、名前付きテンプレートを作成します。

40.12.2 名前付きテンプレートの編集方法

名前付きテンプレートは作成されるとまず、編集できるように、XSLTマップ・エディタで開かれます。XSLTツールバーのドロップダウン・リストを使用して、名前付きテンプレートの編集とXSLTマップの編集を切り替えることができます。

図40-47 は、XSLTマップ・エディタで編集されている名前付きテンプレートを示しています。左上隅にはドロップダウン・リストがあり、これを使用してXSLTマップと名前付きテンプレートのいずれかを選択できます。

ソース・ツリー、グローバル・パラメータおよび名前付きパラメータがある場合は、左側のソース・ペインに表示されます。右上のXSLTペインには、名前付きテンプレートに関連付けられたXSLTが表示されます。ターゲット・スキーマが使用される場合は、エディタの右下隅にターゲット・ツリーが表示されます。

図40-47 名前付きテンプレートの編集

40.12.3 既存の名前付きテンプレートへのパラメータの追加方法

既存の名前付きテンプレートにパラメータを追加する手順は次のとおりです。

1. 名前付きテンプレートがXSLTマップ・エディタに表示されることを確認します。名前付きテンプレートに切り替えるには、XSLTツールバーのドロップダウン・リストから名前付きテンプレートの名前を選択します。例は図40-47 を参照してください。

2. ソース・ノードを右クリックし、コンテキスト・メニューから「パラメータの追加」を選択します。あるいは、次のようにします。

- キャンバス・ペイン(中央)で空白の領域を右クリックし、コンテキスト・メニューから「作成」→「パラメータの追加」を選択します。

- XSLTツールバーで、緑色のプラス(+)アイコンで表示される「追加」ボタンをクリックします。表示されるドロップダウン・リストから「パラメータの追加」を選択します。

3. 「パラメータの追加」ダイアログでパラメータ名およびその他の詳細を指定します。ダイアログの「ヘルプ」ボタンをクリックすると、個々のフィールドの詳細情報が表示されます。

4. 「パラメータの追加」ダイアログで「OK」をクリックして、パラメータを追加します。

40.12.4 名前付きテンプレートの起動方法

名前付きテンプレートは、xsl:call-template命令を使用して起動します。xsl:call-template命令はXSLTペインでノードとして追加できます。

名前付きテンプレートを起動する手順は次のとおりです。

1. xsl:call-template命令をXSLTノードとして追加します。xsl:call-template命令は、コンテキスト・メニューまたは「コンポーネント」ウィンドウから追加できます。XSLT要素の追加の詳細は、「XSLT文の追加方法」を参照してください。

「属性の設定」ダイアログが表示されます。

2. 起動する名前付きテンプレートを選択します。「OK」をクリックします。

xsl:call-template命令がXSLTツリーに追加されます。パラメータ(xsl:use-param命令)は子ノードとして追加されます。

3. xsl:with-param XSLTノードに値をマッピングして、パラメータの値を設定します。

40.13 テンプレート・ルールの使用

テンプレート・ルールは、一致属性を含むxsl:template文です。テンプレート・ルールはXSLTマップ・エディタでサポートされます。テンプレート・ルールはXSLTビューでのみ使用できます。テンプレート・ルールはマップ・ビューではサポートされません。

XSLTマップ・エディタを使用すると、テンプレート・ルールを様々な方法で追加できます。テンプレート・ルールを手動で挿入したり、既存のマッピングをリファクタしてテンプレート・ルールを作成できます。

テンプレート・ルールを手動で追加する場合は、テンプレートをXSLTの適切な場所で起動するためにapply-templates文も挿入する必要があります。テンプレート・ルールを作成するために既存のマップをリファクタする場合は、apply-templates文が自動的に挿入されます。

40.13.1 テンプレート・ルールの作成方法

1. 次のいずれかの方法を使用して、「新規テンプレート・ルール」ダイアログを起動します。

- 一致ノードとして機能するノードをソース・ペインで右クリックします。表示されるコンテキスト・メニューから「新規テンプレート・ルール」を選択します。

- ターゲット・ペインでノードを右クリックします。表示されるコンテキスト・メニューから「新規テンプレート・ルール」を選択します。

- XSLTペインでノードを右クリックします。表示されるコンテキスト・メニューから「新規テンプレート・ルール」を選択します。

- キャンバス・ペイン(中央)の空白領域を右クリックします。表示されるコンテキスト・メニューから「作成」→「新規テンプレート・ルール」を選択します。

- XSLTツールバーに緑色のプラス(+)記号で表示される「追加」アイコンをクリックします。表示されるオプションのリストから「新規テンプレート・ルール」を選択します。

「新規テンプレート・ルール」ダイアログが表示されます。図40-48 に、「新規テンプレート・ルール」ダイアログを示します。

図40-48 「新規テンプレート・ルール」ダイアログ

「新規テンプレート・ルール」ダイアログには、次のフィールドがあります。

- 一致ノード: xsl:template定義で一致属性の値を指定します。
一致属性には、入力XMLドキュメントでノードの一致に使用されるパターンが含まれています。処理中のノードがテンプレートの一致属性に定義されているパターンと一致するときに、XSLTプロセッサはテンプレート内で命令を実行します。

- 「初期化」セクション: 新しいテンプレート・ルールの内容の決定に使用されます。
「空のテンプレートの作成」を選択すると、コンテンツのないxsl:template命令を作成できます。または、「テンプレートに生成するノードの選択」を選択して、テンプレートの実行時に作成するターゲット・スキーマ・ノードを表示および選択できます。

「テンプレートに生成するノードの選択」オプションは、ターゲット・スキーマが使用されている場合にのみ使用できます。

- ローカル名で検索:「テンプレートに生成するノードの選択」オプションが選択されている場合に、ターゲット・スキーマを表すツリーが表示されます。このオプションでは、ローカル名を使用してターゲット・スキーマ・ツリーでノードを検索できます。

ダイアログの起動で選択したモードによっては、「新規テンプレート・ルール」ダイアログ・ボックスに自動的にフィールドが移入されている場合があります。表40-2 は、各選択内容に応じてあらかじめ移入されるフィールドのリストです。起動方法がリストされていない場合、事前に移入されているフィールドはありません。

表40-2 「新規テンプレート・ルール」ダイアログの起動方法

起動元

自動的に移入される情報

ソース・ペインのノード

「一致ノード」にソース・ノードへの絶対パスが移入されます。必要に応じてこの値を編集できます。

「空のテンプレートの作成」オプションは、「初期化」セクションであらかじめ選択されています。必要に応じてこの選択内容を変更できます。

ターゲット・ペインのノード

「テンプレートに生成するノードの選択」オプションは、「初期化」セクションであらかじめ選択されており、ターゲット・スキーマが表示されます。「新規テンプレート・ルール」ダイアログの起動に使用されるターゲット・スキーマ・ノードは、ターゲット・ツリーであらかじめ選択されています。必要に応じてこの選択内容を変更できます。

「一致ノード」フィールドには、テンプレートに対して必要な一致パターンが移入される必要があります。

2. 「一致ノード」を必要に応じて設定します。一般的な例を次に示します。

- /ns0:PurchaseOrder/ns0:ShipToContact/ns0:Region: プロセッサがこのパスを持つノードを処理する際にテンプレートが実行されます。

- Item: プロセッサがItem名を持つノードを処理する際にテンプレートが実行されます。

- HighPriorityItems/Items/Item: HighPriorityItemsノードの子であるItemsノードの子のItemノードをプロセッサが処理する際にテンプレートが実行されます。

3. 「初期化」セクションで必要なコンテンツを選択します。テンプレートを作成する出力ノードがわかっている場合は、「テンプレートに生成するノードの選択」オプションを選択し、表示されるターゲット・スキーマ・ツリーから出力ノードを選択します。「ローカル名で検索」フィールドを使用して、ターゲット・スキーマ・ツリー内で検索できます。[Shift]キーを押したまま目的の各ノードをクリックすることで、ターゲット・ツリーで複数のノードを選択できます。

4. 「新規テンプレート・ルール」ダイアログで「OK」をクリックして、テンプレートを作成します。新しいxsl:template文がXSLTの最後に挿入されます。

5. テンプレート・ルールを起動する既存のapply-templates文がない場合は、適切なapply-templates文を挿入してテンプレート・ルールを起動します。

apply-templates文が存在しない場合は、xsl:template文に警告アイコンが、テンプレート内のすべてのノードに疑問符(?)アイコンが表示されます。次の図に例を示します。

通常、apply-templates文は、テンプレートに含まれるノードを生成する場所に挿入されます。たとえば前述の図では、apply-templates文は、Addressノードおよびその子ノードを作成する必要のある場所に挿入される必要があります。

テンプレート・ルールを起動するapply-templates文を挿入後、警告アイコンおよび疑問符(?)アイコンは表示されなくなります。

40.13.1.1 例: テンプレート・ルールの作成

例として、次に示すように、既存のマップのテンプレート・ルールを作成します。

この例では、ターゲットのShippedTo要素およびBilledTo要素にAddressを作成するために、ソースのShipTo要素およびBillTo要素のAddress情報を処理する1つのテンプレートを作成します。次の手順に処理を示します。

1. ソース・ペインのShipToノードまたはBillToノードの下にあるAddressノードを右クリックして、表示されるコンテキスト・メニューから「新規テンプレート・ルール」を選択します。
「新規テンプレート・ルール」ダイアログが表示されます。「一致ノード」には、ソース・ペインで選択したAddressノードへのパスがあらかじめ移入されています。この一致文字列は、ShipToの下にあるAddress要素に固有のものですが、ソース・ドキュメントのすべての「Address」フィールドを処理するテンプレートを作成する必要があります。

2. 名前Addressのみが含まれるように「一致ノード」の文字列を変更します。これによって、ドキュメントで表示される場所にかかわらず、ソース・ドキュメントのすべてのAddressノードが一致します。

3. 「テンプレートに生成するノードの選択」オプションを選択します。ターゲット・スキーマ・ツリーが表示されます。
テンプレート・ルールが起動されたら、ターゲットにAddress要素をその子とともに作成します。

4. ShippedTo要素またはBilledTo要素(どちらの要素も同じ構造です)の下にあるAddressノードを選択します。

5. Addressノードの子を選択するには、[Shift]キーを押したまま、Address要素の最後の子であるZip要素をクリックします。これによって、Address要素およびそのすべての子が選択されます。

6. 「OK」をクリックして、テンプレート・ルールを作成します。

ルールがマップでまだ起動されていないため、テンプレートには警告アイコンが表示され、テンプレートを作成したノードには疑問符(?)アイコンが表示されます。

40.13.1.1.1 テンプレートの起動

次に、ターゲットでShippedTo要素およびBilledTo要素にAddress要素を作成するために、ソースのShipTo要素およびBillTo要素の両方のAddress要素に対してテンプレートを起動する必要があります。XSLTで、これらのAddress要素を作成する場所にapply-templates文を作成する必要があります。次の手順に処理を示します。

1. XSLTペインでInvoiceノードを右クリックして、表示されるコンテキスト・メニューから「スキーマからの子の追加」→「BilledTo」の順に選択します。BilledToノードが、必要な子ノードとともに挿入されます。

2. XSLTペインでInvoiceノードを右クリックして、表示されるコンテキスト・メニューから「スキーマからの子の追加」→「ShippedTo」の順に選択します。ShippedToノードが、必要な子ノードとともに挿入されます。

3. ShippedTo/Addressノードを右クリックして、「削除」を選択します。BilledTo/Addressノードに対しても同じ操作を実行します。作成されたテンプレートを使用してAddressノードを作成します。

4. ShippedToノードを右クリックして、表示されるコンテキスト・メニューから「子の追加」→「XSL」→「apply-templates」の順に選択します。xsl:apply-templates文が追加されます。

5. BilledToノードを右クリックして、表示されるコンテキスト・メニューから「子の追加」→「XSL」→「apply-templates」の順に選択します。xsl:apply-templates文が追加されます。

6. ソース・ペインのShipTo/AddressノードからXSLTペインのShippedTo/apply-templatesノードに線をドラッグします。これによって、apply-templates文の属性の選択が設定されるため、xsl:apply-templates文ではShipTo/Addressノードのみが処理されます。

7. ソース・ペインのBillTo/AddressノードからXSLTペインのBilledTo/apply-templatesノードに線をドラッグします。これによって、apply-templates文の属性の選択が設定されるため、xsl:apply-templates文ではBillTo/Addressノードのみが処理されます。
テンプレートの起動を定義したため、この時点でテンプレート・ルール上の警告アイコンが表示されなくなります。テンプレート・ルールをクリックすると、次の図に示すとおり、このテンプレートで処理される2つのAddressノードがハイライト表示されます。

次に、テンプレート・ルールの下のノードをマッピングします。

8. BillTo/Addressノード、またはShipTo/Addressノードの下にある要素からAddressテンプレート・ルールの下の適切な要素に線をドラッグ・アンド・ドロップします。
ソースのどちらかのAddress (BillToまたはShipTo)からドラッグすると、両方のソースのAddressに線が引かれます。これは、BillTo/AddressとShipTo/Addressの両方がテンプレートのコンテキスト・ノードであるためです。

この時点のテンプレートのソース・コードは次のようになります。

<xsl:template match="Address">
<Address country="{@country}">
<Street>
<xsl:value-of select="concat (Street1, ', ' , Street2 )"/>
</Street>
<City>
<xsl:value-of select="City"/>
</City>
<State>
<xsl:value-of select="State"/>
</State>
<Zip>
<xsl:value-of select="Zipcode"/>
</Zip>
</Address>
</xsl:template>

40.13.2 テンプレート・ルールを作成するための既存のマップのリファクタ方法

既存のテンプレートからコードをリファクタして、新しいテンプレート・ルールを作成できます。これは、前の例でAddressテンプレート・ルールを作成した場合のように、作成した複数のテンプレート・ルールが再使用できる場合に有用です。

「テンプレートに作成」オプションを使用すると、XSLT命令のセクションを複数の場所から起動可能な別のテンプレートにリファクタできます。

次の例では、既存のマッピングをリファクタしてテンプレート・ルールを作成します。

次のマップでは、ソースの各Address要素を処理するXSLTが、各Addressノードに対して繰返されます。管理を容易にするために、冗長コードを再利用可能なテンプレートに統合することもできます。この方法では、後でコードが更新される場合に、複数のコピーを更新する必要がありません。

前述のマップでは、Street1およびStreet2からStreetを作成するXPath concat式を変更する必要がある場合、変更する必要のあるコピーは2つです。ただし、concat関数が、両方のAddress要素を作成するために再使用される1つのテンプレートに存在する場合は、今後変更が必要になるconcat文は1つのみです。

次の手順では、既存のマッピングをリファクタして、Address要素を処理する1つのテンプレートを作成します。

1. XSLTビューを使用していることを確認します。XSLTマップ・エディタの右上隅にある「XSLT」をクリックして、XSLTビューに切り替えることができます。

2. XSLTペインで「ShippedTo/Address」要素を右クリックして、表示されるコンテキスト・メニューから「テンプレートに作成」を選択します。

「新規テンプレート・ルール」ダイアログが表示されます。

「一致ノード」には、XSLTペインの選択したノードの下に含まれているXPath式から取得された推奨される一致パターンがあらかじめ移入されています。ターゲット・スキーマ・ツリーで選択された要素は、Addressノードおよびその子です。これらの要素が新しいテンプレート・ルールに移動されます。

3. 「OK」をクリックします。

新しいテンプレートが作成され、apply-templates文がAddressノードのかわりに挿入されます。XSLTペインのAddressノードの下の要素に定義されているXPath式は、新しいテンプレートのAddressノード(コンテキスト・ノード)への相対パスを含めるために更新されます。

次に、このテンプレートをShipToおよびBillToの両方のAddress要素に対して使用します。

4. 新しいテンプレート・ノードをダブルクリックします。「属性の設定」ダイアログが表示されます。

5. 「パターンの入力」にAddressと入力します。

6. 「OK」をクリックします。

7. XSLTペインで、BilledTo/Address要素を削除します。

8. BilledToノードを右クリックして、「子の追加」→「XSL」→「apply-templates」の順に選択します。これによって、xsl:apply-templates文がAddressノードのかわりに作成されます。

9. ソース・ペインのBillTo/AddressノードからXSLTペインの新しいBilledTo/apply-templatesノードに線をドラッグします。

BilledToおよびShippedTo両方のAddress要素が、1つのテンプレート・ルールを使用して作成されました。

40.14 実行ビューの使用

実行ビューには、XSLT文を実行する順序が表示されます。名前付きテンプレートやテンプレート・ルールを使用する複雑なXSLTを作成する際、XSLTテンプレートの実行順序の判断が難しくなることがあります。実行ビューでは、XSLTの実行ツリーを作成することにより、この問題への対応に役立ちます。

実行ツリーは、出力ノードの作成時に表示され、XSLTの実行中、様々な時点でどのテンプレートが起動されるかを正確に示します。

40.14.1 実行ビューを使用したランタイム・エラーの防止または対処方法

「実行ビュー」ダイアログを起動するには、キャンバス・ペイン(中央)を右クリックして、「実行ビュー」を選択します。または、XSLTツールバーで「XSLTマップの実行ビュー」ボタンをクリックします。

実行ビューはマップ・ビューとXSLTビューの両方で使用できます。ただしこれは、マップに複数のテンプレートが含まれ、そのテンプレートがいつ起動されるかをユーザーが理解している必要がある場合に特に役立ちます。

図40-49 は、複数のテンプレートが含まれるXSLTマップの「実行ビュー」ダイアログを示しています。実行ビューでは、match='/'が含まれるルート・テンプレートが最初に実行されます。次に、Invoice、DescriptionおよびIDノードが作成されます。さらに、apply-templates文がShipToテンプレートを起動し、続けてapply-templates文がBillToテンプレートを起動します。その後、その他のノードおよびテンプレートが作成されます。

図40-49 「実行ビュー」ダイアログおよび対応するXSLTツリー

「実行ビュー」ツリーで要素をクリックすると、対応する要素がXSLTツリーでハイライト表示されます。たとえば、図40-49 に示すように、BillToテンプレートを起動するapply-templatesノードを特定する場合は、「実行ビュー」でapply-templatesノードを選択すると、対応するapply-templates文がXSLTペインでハイライト表示されます。

実行ビューには、名前付きテンプレートへのコールも表示されます。「実行ビュー」ツリーで名前付きテンプレート・コール内のノードを選択すると、XSLTエディタ・ビューが更新され、選択したノードが名前付きテンプレートの実装で表示されます。

実行ビューは、XSLTスタイルシート全体のフローを理解するのに役立ちます。実行ビューを使用して、起動されないテンプレートに関連する問題や、不適切なテンプレートを起動しようとするapply-templates文を特定できます。

インポートされた名前付きテンプレートまたはテンプレート・ルールを使用する際は、対応するコールが実行ビューに表示されるので、実行ビューを使用して、インポートの優先順位などの問題に対処できます。ただし、実行ビューでは外部XSLTファイルには移動できません。

40.14.1.1 ノードの検索

「実行ビュー」ダイアログには検索機能があり、「実行ビュー」ツリーの特定のノードを検索できます。「ローカル名の検索」フィールド内をクリックして、検索する名前を入力します。

40.14.1.2 表示オプションの設定

実行ツリーで特定のXSLT要素を表示または非表示にする選択ができます。「オプション」をクリックして、「実行ビュー・オプション」ダイアログを表示します。図40-50 は、「実行ビュー・オプション」のデフォルトの選択内容を示しています。

図40-50 デフォルトの「実行ビュー・オプション」

40.15 XSLTマップのデバッグ

12.2.1以降はSOAデバッガを使用してXSLTマップをデバッグできます。XSLTマップの戦略的な場所にブレークポイントを追加できます。デバッグするとき、デバッガではブレークポイントで実行が停止し、これによってデータおよび出力を検証できます。

XSLTマップが複雑化し、デバッグが困難になる場合があります。たとえば、Java関数やその他の機能がある場合は、アプリケーション・サーバーでテストすることが最適です。また、XSLTはサーバー内の多数の異なるアプリケーションから起動されることがあるため、アプリケーション環境でデバッグする方が簡単な場合もあります。SOAデバッガには、アプリケーション・サーバーにデプロイされたXSLTマップ用のリモート・デバッグ機能が備えられています。

BPELプロセスまたはメディエータで使用されているXSLTトランスフォーメーションをデバッグできます。BPELプロセスまたはMediatorがコンポジットで起動されると、デバッガはマップに定義されているブレークポイントで一時停止します。XSLTマップはJDeveloperで開かれ、XSLT処理に対応するユーザー・データが「データ」ウィンドウに表示されます。

デバッガは、Oracle Service Busプロジェクトにも使用できます。Service Busプロジェクトでデバッガを使用する方法の詳細は、次を参照してください。

Oracle Service Busアプリケーションのデバッグ

40.15.1 XSLTマップ・エディタでのブレークポイントの設定

XSLTマップ・エディタの設計ビューでブレークポイントを設定できます。これにより、実行時にテスト・データまたはペイロードを使用してXSLTマップをデバッグできます。

ブレークポイントは、マップ・ビューまたはXSLTビューのいずれかで設定できます。ブレークは、ターゲットまたはXSLTペインの右側にあるブレークポイント・バーに赤い点で示されます。
ブレークポイントを設定する前に、XSLTマップが開かれ、「設計」が選択されていることを確認します。

次のいずれかの方法で、ブレークポイントを設定します。

- XSLT要素またはノードの右側にあるブレークポイント・バーをクリックします。

- XSLT要素またはノードの右側にあるブレークポイント・バーを右クリックし、表示されるコンテキスト・メニューから「ブレークポイントの切替え」を選択します。

- XSLT要素を右クリックし、表示されるコンテキスト・メニューから「デバッグ」→「ブレークポイントの切替え」を選択します。

注意:
前述の手順を使用して既存のブレークポイントを削除することもできます。
前述のコンテキスト・メニューから「ブレークポイントの無効化」を選択してブレークポイントを無効にすることもできます。無効にしたブレークポイントは、ブレークポイント・バーにグレーのアイコンで表示されます。

次の図に、ponumberノードに設定されたブレークポイントを示します。

40.15.2 XSLTマップでのデバッガの実行

デバッグ・セッションの開始

XSLTマップにブレークポイントを設定した後、次の手順に従ってSOAデバッガを開始します。

SOAコンポジット・アプリケーションのデバッグ

注意:
デバッガでXSLTマップをトレース実行するには、マップがSOAコンポジットのメディエータまたはBPELプロセスで起動されている必要があります。

XSLTマップ・エディタでのデバッガの使用

デバッガを実行した後、デバッガは、XSLTマップのブレークポイントに到達したときに実行を停止します。ブレークポイント・バーの左側の青い矢印は、デバッガの現在の位置を示します。また、点滅する青いアイコンが、対応するXSLT要素またはノードに表示されます。

デバッガがXSLTマップをたどる際、XSLTエディタですべての有効なブレークポイントが赤と緑の点に変わります。赤一色のままのブレークポイントは現在無効であり、デバッガによって無視されます。

注意:
XSLTマップを起動したプロセスの中には、タイムアウト制限を持つものがあります。XSLTマップの終了後、デバッガが予期せず終了した場合、起動元のプロセスにタイムアウト値が定義されている可能性があります。プロセス全体のデバッグをサポートするためにこのタイムアウト値を再定義する必要がある場合があります。デバッガが予期せず中途終了する場合、サーバー・ログ・ファイルで詳細を確認します。

次の図の例は、実行中に表示されるブレークポイントを示しています。tIDおよびItem要素にブレークポイントが表示されています。現在、デバッガはItemノードの位置にあり、そのことが青い矢印と点滅するアイコンで示されています。

JDeveloperのメイン・ツールバーにある「ステップ実行」ボタンを使用して、ステップ実行できます。トレース実行ボタンを使用すると、ループcall-template、apply-templateおよびapply-importsにステップ・インできます。「ステップ・アウト」ボタンを使用すると、call-template、apply-templateおよびapply-importsからステップ・アウトして次のXSLT文に進むことができます。

実行中の任意の時点で、パラメータおよび変数の現在の値をデバッガの「データ」ウィンドウで確認できます。「データ」ウィンドウには、コンテキスト・ノード、コンテキスト位置、コンテキスト・サイズおよびXSLT処理によって作成される出力ドキュメントも表示されます。デバッガの「データ」ウィンドウで表示可能な任意の項目を選択して、「ウォッチ」ウィンドウに追加することもできます。

次の図に、右側の「データ」ウィンドウに表示されたサンプルのデバッガ・データを示します。

デバッグ中にXSLTを編集することを選択できます。再度デバッグするには、プロジェクトを再デプロイする必要があります。

40.15.3 ブレークポイントの表示

ブレークポイントは、XSLTマップ・エディタの右端に沿ったブレークポイント・バーに表示されます。XSLTマップまたはSOAプロジェクトですべてのブレークポイントのリストを表示することを選択できます。

XSLTマップのすべてのブレークポイントのリスト表示

次のいずれかの方法で、現在のXSLTマップのすべてのブレークポイントを表示します。

- 中央のキャンバス・ペインで任意の場所を右クリックし、表示されるコンテキスト・メニューから「ブレークポイント」を選択します。

- ブレークポイント・バーの任意の場所を右クリックし、表示されるコンテキスト・メニューから「ブレークポイント」を選択します。

- XSLTツールバーで「ブレークポイント」をクリックします。

「ブレークポイント」ダイアログが表示され、XSLTマップのすべてのブレークポイントが一覧表示されます。現在、ブレークポイントがXSLTペインで非表示になっている場合、「ブレークポイント」ダイアログでブレークポイントをクリックすることにより、そこに移動できます。

「ブレークポイント」ダイアログを使用して、1つ以上のブレークポイントを無効または削除することもできます。無効になったブレークポイントは、ブレークポイント・バーにグレーの点で表示されます。

「有効」列は、ブレークポイントが現在有効かどうかを示します。XSLTマップの編集で無効にした場合、ブレークポイントが無効になります。無効なブレークポイントを削除することを選択できます。また、XSLTマップへの変更を取り消すと、無効なブレークポイントが再度有効になる可能性があります。

現在のプロジェクトのすべてのブレークポイントの表示

JDeveloperの「ブレークポイント」ウィンドウには、現在のプロジェクトのすべてのブレークポイントが表示されます。「ウィンドウ」メニューから「ブレークポイント」を選択して、「ブレークポイント」ウィンドウを表示します。「ブレークポイント」ウィンドウでブレークポイントをダブルクリックして、プロジェクト内のそのブレークポイントに移動できます。「ブレークポイント」ウィンドウからブレークポイントを編集または削除することもできます。ただし、「ブレークポイント」ウィンドウからブレークポイントを追加することはできません。

40.15.4 XSLTブレークポイントの条件の設定

ブレークポイントに条件を設定して、ブレークポイント条件がtrueと評価された場合にのみ実行を停止するようにできます。

次の手順を使用してXSLTブレークポイントに条件を設定します。

「ブレークポイント」ウィンドウが表示されていない場合は、JDeveloperの「ウィンドウ」メニューから「ブレークポイント」を選択できます。

1. 「ブレークポイント」ウィンドウでブレークポイントを右クリックします。表示されたコンテキスト・メニューから「編集」を選択します。
「XSLTブレークポイントの編集」ダイアログが表示されます。

2. 「条件」タブで、javascript構文を使用して条件式を入力します。
たとえば、次のブレークポイントは、$Part変数のPartNum属性がp1になったときに中断します。

3. 条件に「パスの回数」を設定することも選択できます。パスの回数は、特定の回数通過するまでブレークポイントを無視するようにデバッガに指示します。パスの回数が一致すると、デバッガはそのブレークポイントで実行を中断します。

4. 「OK」をクリックして、条件を設定します。

40.16 メモリーの問題のトラブルシューティング

大量のスキーマ・ドキュメントを使用している場合、自動マッピング中、テスト中およびレポート生成中に、メモリー不足エラーが発生する場合があります。XSLTマップ・エディタの使用中にメモリー不足エラーが発生した場合は、JVMのヒープ・サイズを増やして問題を解決する必要があります。

JVMのヒープ・サイズを増やす手順は、次のとおりです。

1. アプリケーション・インストールのconfigファイルを特定します。

共有Oracle JDeveloperのproduct.confファイルまたはオプションのツール固有の.confファイルをユーザーのホーム・ディレクトリで特定します。これらのファイルの場所は、ホスト・プラットフォームによって異なります。

- Windowsプラットフォームの場合:
通常、ユーザー・ファイルおよび製品ファイルの場所は、インストール中に構成されますが、おそらく次の場所にあります。

%APPDATA%\JDeveloper\product-version\product.conf

%APPDATA%\JDeveloper\product-version\jdev.conf

- UNIXプラットフォームの場合:
$HOME/.jdeveloper/product-version/product.conf

$HOME/.jdeveloper/product-version/jdev.conf

2. ファイルを編集して、AddVMOptionを必要な値に変更します。次に例を示します。

AddVMOption -Xmx1024M

注意:

AddVMOption値は、64ビット・マシンでは大きくできます。マシンで提供されるRAMのサイズに近づけるとパフォーマンスが向上します。

40.17 XSLマップ・プリファレンスの設定

「プリファレンス」ダイアログを使用して、XSLTマップに関連するプリファレンス(展開の深さなど)や、XSLTマップ・エディタに関連するプリファレンス(初期化オプションなど)を設定します。

40.17.1 XSLTマップのプリファレンスの設定方法

XSLTマップのプリファレンスを設定するには、「ツール」メニューから「プリファレンス」を選択します。「プリファレンス」ダイアログの左側のペインに表示されるナビゲーション・ツリーで「XSLマップ」をクリックします。図40-51 は、表示される「XSLマップ」ダイアログを示しています。

図40-51 XSLマップのプリファレンス

ソースおよびターゲット・ツリーの展開の深さなど、様々なオプションを設定できます。各フィールドの詳細は、「ヘルプ」ボタンをクリックして参照してください。

40.17.2 XSLエディタのプリファレンスの設定方法

XSLTマップのプリファレンスを設定するには、「ツール」メニューから「プリファレンス」を選択します。「プリファレンス」ダイアログの左側のペインに表示されるナビゲーション・ツリーで、「XSLマップ」の横にあるプラス記号(+)をクリックします。これで、XSLマップ・ノードが展開されます。「XSLエディタ」を選択します。図40-52 は、「XSLエディタのプリファレンス」ダイアログを示しています。

図40-52 XSLエディタのプリファレンス

初期化モードなど、XSLTマップ・エディタの様々なプリファレンスを設定できます。各フィールドの詳細は、「ヘルプ」をクリックしてください。

40.17.3 カスタマイズ・ファイルをインポートしてXSLTマップ・エディタの表示プリファレンスを指定する方法

XSLTマップ・エディタの表示プリファレンスを含むカスタマイズ・ファイルを指定できます。「XSLエディタのプリファレンス」ダイアログ(図40-52 )で、カスタム表示オプション構成ファイル・フィールドの右側にある「参照」ボタンをクリックします。インポートするファイルを選択します。

このカスタマイズ・ファイルはXMLファイルで、次の場所にあるbpm-ide-common.jarファイルのXSLTEditorOptions.xsdスキーマに従う必要があります。

oracle/tip/tools/ide/common/resource/XSLTEditorOptions.xsd

次の例は、サンプルのカスタマイズ・ファイルを示しています。このファイルの重要な要素については、例の後に説明します。

<?xml version="1.0" encoding="UTF-8" ?>
<customizeXSLTeditor>
<selectedArea>HL7</selectedArea>
<abbreviationLists>
<abbreviationList name="Siebel">
<abbreviation long="Account" short="Acct"/>
</abbreviationList>
<abbreviationList name="SalesGeneral">
<abbreviation long="SalesOrder" short="SO"/>
<abbreviation long="PurchaseOrder" short="PO"/>
<abbreviation long="BillOfMaterial" short="BOM"/>
<abbreviation long="CreateEngineeringChangeOrderList" short="CECOL"/>
</abbreviationList>
</abbreviationLists>
<customization area="HL7">
<showFixedValueInElementName>
<path>@LongName</path>
<path>@LongName2</path>
<path>@Name</path>
</showFixedValueInElementName>
<abbreviations>
<apply display="treeLabels">
<hideText part="matchValue" maxLength="13" hide="left"/>
<hideText part="namedTemplateName" maxLength="15" hide="left"/>
<hideText part="importHref" maxLength="20" hide="left"/>
</apply>
<apply display="dropDownLists">
<hideText part="namedTemplateName" maxLength="40" hide="center"/>
</apply>
</abbreviations>
</customization>
<customization area="AIA">
<abbreviations>
<applyAbbreviations list="Siebel"/>
<applyAbbreviations list="SalesGeneral"/>
<apply display="treeLabels">
<hideText part="matchValue" maxLength="13" hide="left"/>
<hideText part="namedTemplateName" maxLength="15" hide="left"/>
<hideText part="importHref" maxLength="20" hide="left"/>
</apply>
<apply display="dropDownLists">
<hideText part="namedTemplateName" maxLength="40" hide="center"/>
</apply>
</abbreviations>
</customization>
</customizeXSLTeditor>

次のリストは、前述の例の重要な要素について説明しています。

- <selectedArea>: エディタで使用するカスタマイズ領域を選択します。カスタマイズ領域のリストをこのファイルで定義できます。

- <abbreviationList name="listName">: カスタマイズ領域で参照できる略語リストを定義します。

- <abbreviation name="Account" short="Acct">: 略語リストで使用する個々の略語を定義します。

- <abbreviations>: カスタマイズ領域内で使用し、略語および、エディタのテキストのカットオフの長さを定義します。

- <applyAbbreviations>: このカスタマイズ領域で使用する略語リスト(複数可)を選択します。

- <apply display="treeLabels" | "dropDownLists">: テキストのカットオフが行われる領域を選択します。

- <hideText>: テキストが長すぎる場合にカットオフする特定のテキスト・フィールドを選択します。

- @part: "matchValue"、"namedTemplateName"または"importHref"です。

- @maxLength: テキスト値の長さの制限値です。

- @hide: テキストで非表示にする部分を指定します。"left"は左側のテキストを切り捨てます。"right"は右側のテキストを切り捨てます。"center"は中央のテキストを削除し、「…」に置き換えます。

- <showFixedValueInElementName>: カスタマイズ領域内で使用されます。この要素は、長い名前や、エディタのソースまたはターゲット・ツリーに要素名の一部として表示するその他のテキストを含む、固定値属性を選択します。
次に例を示します。

<showFixedValueInElementName>
<path>@LongName</path>
<path>@LongName2</path>
<path>@Name</path>
</showFixedValueInElementName>

前述の例では、XSLTマップ・エディタ・ツリーの任意の要素の1番目の固定値の名前はLongName、LongName2で、Nameが要素ツリー名の一部として表示されます。

固定属性値は、ツリー内の実際の要素名の右側のカッコ内に表示されます。これは、HL7スキーマで特に役立ちます。このスキーマでは、記述名がスキーマの固定属性値として追加されます。

41 XQueryマッパーを使用したトランスフォーメーションの作成

この章では、XQueryマッパーを使用して、XQueryトランスフォーメーションを作成、編集およびテストする方法を説明します。XQueryマッパーでは、様々なXMLタイプおよび非XMLタイプ間でデータを変換でき、異種アプリケーションを迅速に統合できます。XQueryマッパーを使用して作成されたXQuery (.xqy)ファイルを、Oracle BPEL Process Manager、Oracle MediatorまたはOracle Service Busのリソースとして使用できます。

この章の内容は次のとおりです。

- XQueryマッパーの概要

- XQueryマップ・ファイルの作成

- XQueryマッパーの使用

- XQuery関数の使用

- ライブラリ・モジュールの使用

- ゾーンおよびFLWORコンストラクトの使用

- XQueryパフォーマンス向上のためのタイプ注釈の使用

- XQueryマップのテスト

41.1 XQueryマッパーの概要

XQueryマッパーはXQuery 1.0をサポートします。古いXQuery 2004もサポートされます。

XQueryマッパーには次のビューがあります。

- XQueryマッパーのグラフィカル・ビュー

- XQueryマッパーのソース・エディタ

注意:

XQueryマッパーのグラフィカル・ビューは、XQuery 2004ファイルではサポートされていません。XQueryのこの古いバージョンでは、ソース・ビューのみがサポートされています。

新規XQueryファイルを作成すると、デフォルトではグラフィカル・ビューで開きます。グラフィカル・ビューには、XQueryマップ下部の「XQueryマッパー」タブをクリックしてアクセスすることもできます。

図41-1 は、XQueryマッパーのグラフィカル・ビューを示しています。

図41-1 XQueryマッパー

XQueryマッパーの左ペインには、XQuery関数の入力元やパラメータが表示されます。XQueryファイルに複数の関数がある場合、マッパー・ペインの上のツールバーを使用して関数を選択して表示できます。

右ペインには、XQuery関数の結果タイプに対応するターゲット・スキーマ・ツリーが表示されます。中央のペインは、XQuery関数を使用したソースおよびターゲット・スキーマ要素のマッピングに使用できます。

41.1.1 ソースおよびターゲット・ツリーについて

XQueryマッパーの左ペインにはソース・ツリー、右ペインにはターゲット・ツリーが表示されます。ツリーのノードは、XML要素、属性、および他のなんらかのXQueryコンストラクトとなります。

XML要素は<>アイコンで示されます。属性には別のアイコンが使用され、XPath式で表されるのと同様に、属性名の先頭に@記号が付きます。要素または属性の多重度は、次の標準接尾辞で示されます。

- ?: 0個または1個の要素/属性があります。

- +: 1個以上の要素/属性があります。

- *: 0個以上の要素/属性があります。

ソース・ツリーは、選択されたXQuery関数の入力元またはパラメータを示します。ルート・レベルの要素は、その関数の入力パラメータを表します。ルート・ノードが複合要素の場合、子要素および属性がルート・ノードの下に表示されます。

ターゲット・ツリーには、XML要素、属性、およびいくつかのプログラミング・コントロール構造を含めることが可能です。要素および属性は、次の形式で表示されることがあります。

- グレー表示のフォント: ターゲット・スキーマの一部で、未定義の要素。グレー表示の要素をソース要素にマッピングすると、その後は通常のフォントで表示されます。

- 通常のフォント: ソース内の要素コンストラクタに対応するか、またはソース・データから明示的にコピーされた要素。

- 下線付きフォント: 指定されたターゲット・スキーマに互換性のない要素。この要素は、要素コンストラクタで使用される要素名が正しくないため、またはシーケンス割当てのスキーマ・タイプが正しくないために表示される場合があります。

ターゲット・ツリーには、If-Then-Else、union演算子、comma演算子などのプログラミング・コントロール構造を含めることができます。

- If-Then-Else演算子: If-Then-Else演算子は、「条件付き」というノードとして表示されます。「条件付き」ノードには、If Then and Elseのネストされたブランチがあります。ノードのコンテキスト・メニューから「条件付け」オプションを選択して、ノードを条件付きにすることが可能です。

- union演算子(およびその他のシーケンス結合演算子): これらはXQueryマッパーのグラフィカル・ビューでは作成できません。ただし、ソース・ビューにこうした演算子が含まれる場合は、ターゲット・ツリーに「すべて」というノードで表示され、オペランドがすべてのノードのサブノードとして表示されます。

- comma演算子: comma演算子は、「リスト」というノードとして表示されます。サブノードは、comma演算子のカンマ区切りオペランドを表します。ターゲット・ツリー・ノードのコンテキスト・メニューから「クローン」オプションを選択して、comma演算子を適用できます。

41.1.2 XQueryマッパー・ツールバーの使用

XQueryマッパー・ツールバーはXQueryマッパーのペインの上にあります。このツールバーには、グラフィカル・マッパーで使用できる様々なツールが含まれています。XQueryマッパー・ツールバーを図に示します。

図41-2 XQueryマッパー・ツールバー

XQueryマッパー・ツールバーには次のツールが含まれています。

- 関数セレクタ: 「関数セレクタ」ボックスは、fの文字が付いた緑色のアイコンで示されます。関数セレクタを使用して、ソース・ペインに表示する関数を選択できます。これは、XQueryマップに複数の関数が含まれる場合に役立ちます。

- 新規関数の追加: 「新規関数の追加」ボタンは、緑色のプラス(+)記号で表示されます。新規関数の追加を使用して、XQueryマップ・ファイルに新規関数を追加します。

- 関数の名前変更: 「関数の名前変更」ボタンは「新規関数の追加」ボタンの右にあります。「関数の名前変更」を使用して、XQueryマップ・ファイルの関数の名前を変更します。

- 関数の削除: 関数の削除は、赤色のクロス(X)記号で表示されます。「関数の削除」を使用して、XQueryマップ・ファイルから関数を削除します。

- ライブラリ・モジュールのインポート: 「ライブラリ・モジュールのインポート」ボタンは「関数の削除」ボタンの右にあります。「ライブラリ・モジュールのインポート」を使用して、ライブラリXQuery関数をマップにインポートします。インポートするライブラリ・モジュール・ファイルを指定する必要があります。

- マッピング・モード: XQueryマッパーでは様々なマッピング・モードを使用できます。これらのモードは、ユーザーがソース・ノードからターゲット・ノードに線をドラッグ・アンド・ドロップする際に作成されるXQuery式に影響します。次の3つのボタンを使用して、対応するマッピング・モードを選択します。

- 値マッピング: 入力ソースからターゲットのXML要素および属性を構成し、XMLコンストラクタを使用して入力ソースの値をコピーします。次に例を示します。
<ID>{fn:data($pParam1/ID)}</ID>

前述のコードは、入力ソース・パラメータのID要素からターゲットのID要素を作成します。

値マッピングは、デフォルトのマッピング・モードです。

- マッピングの上書き: 入力ソース・パラメータのXML要素が結果シーケンスにコピーされます。既存のマッピングは新規マッピングに置き換えられます。次に例を示します。
{

$pParam1/Items

}

前述のコードは、Itemsサブツリーおよび、その子要素と属性をターゲット・ツリーにコピーします。

- マッピングの追加: このモードは、既存のマッピングが上書きされない点を除いて、マッピングの上書きと同様に動作します。新しく追加するマッピングが作成されます。

マッピング・モードの使用方法の詳細は、「XQueryマッパーの使用」を参照してください。

- ターゲット・タイプ差異の表示/非表示: 「ターゲット・タイプ差異の表示/非表示」ボタンを使用して、右側のターゲット・ツリーでXML要素および属性が表示されるかどうかを管理します。まだマッピングされていない要素および属性は非表示にする選択ができます。

- 検索: 「検索」フィールドを使用して、ソース・ツリーおよびターゲット・ツリーで要素、属性、データ・タイプなどを検索します。上矢印および下矢印を使用して、それぞれ次および前の項目を探します。

41.1.3 「プロパティ」ウィンドウの使用

「プロパティ」ウィンドウには、ターゲット・ツリーで選択したノードのXQuery式が表示されます。ドラッグ・アンド・ドロップを使用して作成されたXQuery式は、「プロパティ」ウィンドウで編集できます。「プロパティ」ウィンドウは、さらに複雑なXQuery式の作成にも使用できます。

「プロパティ」ウィンドウは、デフォルトではXQueryマッパーの下にあります。「プロパティ」ウィンドウが表示されていない場合は、JDeveloperの「ウィンドウ」メニューで「プロパティ」をクリックして、「プロパティ」ウィンドウを表示します。

ヒント:

XQueryマッパーを使用する際は、「プロパティ」ウィンドウを画面右下隅から、画面下部のマッパー・ウィンドウのすぐ下に移動できます。「プロパティ」ウィンドウが大きくなり、XQuery式の編集および変数ツリーが表示しやすくなります。

選択したターゲット・ノードのXQuery式は、「プロパティ」ウィンドウで直接編集できます。また、XQuery関数、コンストラクトおよび演算子を、「コンポーネント」ウィンドウから「プロパティ」ウィンドウのXQuery式にドラッグできます。「コンポーネント」ウィンドウは、デフォルトではXQueryマッパーの右側にあります。「コンポーネント」ウィンドウが表示されていない場合は、Oracle JDeveloperのメニュー・バーから「ウィンドウ」→「コンポーネント」の順に選択します。

変更内容を保存するには、「プロパティ」ウィンドウの左上隅にある「コミット」ボタンをクリックします。XQueryが再コンパイルされ、XQueryマッパー・ビューが更新されます。

XQuery式の編集で間違えた場合は、「プロパティ」ウィンドウの左上領域にある「マッパー・リソースに戻す」をクリックして、変更内容を元に戻して再度開始します。

「プロパティ」ウィンドウの左側にも変数ツリーがあります。変数ツリーには、すべての変数、ローカル変数およびXQuery関数パラメータの両方が表示され、現在のスコープで確認できます。このスコープは、ターゲット・ツリー・ペインでハイライトされたノードによって決まります。変数ツリーから右側のペインにあるXQuery式にノードをドラッグ・アンド・ドロップできます。

図41-3 に、「プロパティ」ウィンドウを示します。「プロパティ」ウィンドウは赤でハイライト表示されています。このコメント・ノードは、ターゲット・ツリーで選択されて表示されます。対応する変数ツリーおよびXQuery式(fn:data($pParam1/Comment))が「プロパティ」ウィンドウに表示されます。

図41-3 「プロパティ」ウィンドウ

41.1.4 「コンポーネント」ウィンドウの使用

「コンポーネント」ウィンドウには、XQueryマップで使用できるすべてのXQuery関数および演算子が含まれています。これらの関数および演算子は、XQueryマッパーの中央ペインにドラッグ・アンド・ドロップできます。また、ターゲット・ツリー・ノードが「挿入」コンテキスト・メニュー・オプションを使用してすでに作成されている場合は、ターゲット・ツリー・ノードに関数をドラッグ・アンド・ドロップできます。

注意:

また、前述の項の説明に従って、「プロパティ」ウィンドウのXQuery式に、関数および演算子をドラッグ・アンド・ドロップできます。

たとえば、関数はソース・ノードおよびターゲット・ノード間の既存のリンクにドラッグ・アンド・ドロップされると、そのリンクに対応する式の一部となります。パラメータを持たない一部の関数は、中央ペインの空白の領域にドラッグして、ターゲット・ノードと関連付ける必要があります。関数は、相互に連鎖させることもできます。

「コンポーネント」ウィンドウでは、XQuery関数および演算子を次のカテゴリにまとめています。

- XQuery関数: 集計関数、日付関数、数学関数、文字列関数など、様々なカテゴリのXQuery関数が含まれます。

- XQueryコンストラクト: If-Then-ElseやFLWORコンストラクトなど、標準のXQueryコンストラクトが含まれます。

- XQuery演算子: 論理演算子、ノード比較演算子など、様々なカテゴリのXQuery演算子が含まれます。

- ユーザー定義関数: 現在のXQueryマップ・ファイルで定義したすべての関数と、インポートされたライブラリ・モジュールのすべての関数が含まれます。

- コンポーネント: このカテゴリに追加できるお気に入りのコンポーネントが含まれます。最近使用した関数も含まれます。

41.1.5 ソース・エディタ

ソース・エディタでは、XQueryマップを直接編集でき、グラフィカル・ビューで直接実行できないタスクも実行できます。

XQueryマッパー・グラフィカル・ビューの左下にある「XQueryソース」タブをクリックして、ソース・エディタを表示します。図41-4 に、XQueryマッパーのソース・エディタを示します。

図41-4 XQueryマッパーのソース・エディタ

XQueryソース・ビューには、コード強調表示、コード補完、エラー強調表示、コード折りたたみなどのコード編集機能が用意されています。また、[Ctrl]キーを押しながら関数名、変数名、スキーマまたはスキーマ要素をクリック([Ctrl]キーを押し下げた状態で左マウス・ボタンをクリック)して、その関数、変数、スキーマまたはスキーマ要素それぞれに対応する宣言に移動することもできます。

41.2 XQueryマップ・ファイルの作成

Oracle JDeveloperを使用してXQueryマップを作成します。XQueryマップは、.xqyファイルとしてプロジェクトに含まれています。

XQueryマップは、メイン・モジュールおよびライブラリ・モジュールとして作成できます。メイン・モジュールは、XQueryの実行可能ファイルです。ライブラリ・モジュールは、XQuery関数のグループ化および格納に使用されます。ライブラリ・モジュールをメイン・モジュールにインポートすると、ライブラリ・モジュール内のすべての関数がメイン・モジュールで使用可能になります。

41.2.1 XQueryメイン/ライブラリ・モジュールの作成方法

XQueryメイン・モジュールおよびライブラリ・モジュールを作成する手順は、次のとおりです。

1. 「ファイル」メニューをクリックします。次のいずれかを選択します。

- XQueryメイン・モジュールを作成するには、「新規」→「XQueryファイル・バージョン1.0」の順に選択します。「XQueryマップ・メイン・モジュールの作成」ダイアログ・ボックスが表示されます。

図41-5 メイン・モジュールの作成ダイアログ

- XQueryライブラリ・モジュールを作成するには、「新規」→「XQueryライブラリ・バージョン1.0」の順に選択します。「XQueryマップ・ライブラリ・モジュールの作成」ダイアログ・ボックスが表示されます。

図41-6 ライブラリ・モジュールの作成ダイアログ

2. 「ファイル名」に、作成するXQueryマップ・ファイルの名前を入力します。ファイルには、.xqy拡張子が付いている必要があります。

3. 「ディレクトリ名」で、マップ・ファイルを作成するディレクトリを指定します。これは通常、プロジェクト・フォルダの「変換」ディレクトリです。右側のツリー・アイコンをクリックして、指定するディレクトリを参照して選択できます。

4. ライブラリ・モジュールを作成している場合は、「ターゲット・ネームスペースURI」の下でライブラリ・モジュールのターゲット・ネームスペースを選択します。必要に応じて、ネームスペースの「接頭辞」を編集します。

ライブラリ・モジュールに定義されたすべての関数で、ライブラリのターゲット・ネームスペースが自動的に使用されます。

5. 「関数の生成」を選択して、XQueryファイルに関数を作成します。これを選択しない場合は空白のXQueryファイルが作成され、後で関数を追加できます。

6. 「関数名」に、XQueryファイルに作成する関数の名前を入力します。

7. メイン・モジュールを作成している場合は、関数に関して次の追加のフィールドを選択します。

- 「NS URI」で関数のネームスペースを指定します。「NS URI」は自動的に移入されます。別のネームスペースを選択することもできます。

- 「接頭辞」で関数のネームスペース接頭辞を指定します。「接頭辞」は自動的に移入されます。推奨ネームスペース接頭辞を編集することもできます。

8. 「ソース」セクションに関数のパラメータを追加します。パラメータを追加するには、緑色のプラス記号(+)で表示される「ソースの追加」ボタンをクリックします。「関数パラメータ」ダイアログ・ボックスが表示されます。

図41-7 「関数パラメータ」ダイアログ

9. 「名前」に関数パラメータの名前を入力します。

10. 「ネームスペースの設定」を選択して、関数パラメータのネームスペースを指定します。

「NS URI」で、関数パラメータのネームスペースを選択します。ネームスペース接頭辞が「接頭辞」フィールドに表示されます。必要に応じて、これを編集できます。

11. 「順序タイプ」で、「鉛筆」アイコンで表示されるボタンをクリックし、パラメータのデータ・タイプを指定します。「関数パラメータ・タイプ」ダイアログ・ボックスが表示されます。

図41-8 「関数パラメータ・タイプ」ダイアログ

「XMLスキーマ」タブを使用して、関数パラメータのデータ・タイプにXMLスキーマ・タイプを指定します。「型なし」タブを使用して、タイプ指定されていない(非XMLスキーマ・ベース)フォームのパラメータを指定できます。この手順ではXMLスキーマ・タイプを使用します。

12. 「関数パラメータ・タイプ」ダイアログで、「スキーマ・オブジェクト参照」の右にあるボタン(ツリー・アイコンで表示されます)をクリックして、スキーマ・オブジェクトをデータ・タイプとして選択します。

これで「タイプ・チューザ」ダイアログ・ボックスが表示されます。「プロジェクトのスキーマ・ファイル」、「XMLスキーマ単純型」および「プロジェクトのWSDLファイル」に埋め込まれたスキーマから選択できます。目的のXMLタイプに移動して「OK」をクリックし、「タイプ・チューザ」ダイアログ・ボックスを閉じます。

13. 「関数パラメータ・タイプ」ダイアログで、「使用可能なシーケンス・タイプ・フォーム」、「スキーマの場所」および「接頭辞」は、「スキーマ・オブジェクト参照」での選択に応じて自動的に移入されます。オプションで、必要に応じて任意の値を変更します。

14. 「発生」で、オプションでパラメータの多重度を変更します。「結果XQuery式」に結果のXQuery式が表示されます。

15. 「OK」をクリックして、「関数パラメータ・タイプ」ダイアログ・ボックスを閉じます。

16. 「OK」をクリックして、「関数パラメータ」ダイアログ・ボックスを閉じます。

17. 「XQueryマップ・メイン・モジュールの作成/XQueryマップ・ライブラリ・モジュールの作成」ダイアログで、「ターゲット」セクションの下で関数の結果のデータ・タイプを指定します。「ターゲット」フィールドの右にある「鉛筆」アイコンの付いたボタンをクリックします。

「関数の結果タイプ」ダイアログ・ボックスが表示されます。このダイアログ・ボックスは「関数パラメータ・タイプ」ダイアログ・ボックスと同じものです。手順12から14の説明のとおりに関数の結果データ・タイプを指定します。

18. 「OK」をクリックして、「関数の結果タイプ」ダイアログ・ボックスを閉じます。

19. 「XQueryマップ・メイン・モジュールの作成/XQueryマップ・ライブラリ・モジュールの作成」ダイアログで、「オプション」セクションの下で「XQueryバージョン行の生成」を選択して、XQueryファイルの最初に標準の線を生成します。

たとえば、ファイルの先頭に次のような行が生成されます。

xquery version "1.0" encoding "utf-8";

20. 「スキーマ・タイプ注釈の使用」を選択して、スキーマ・オブジェクト参照のかわりにタイプ注釈を使用する弱タイプのXQueryファイルを作成します。これにより、特定のシナリオでは、XQueryのパフォーマンスが向上する場合があります。

このオプションを選択解除した場合、XQueryではスキーマ・オブジェクトへの参照を含めることが可能な強タイプのXQueryファイルを生成します。

タイプ注釈の詳細は、「XQueryパフォーマンス向上のためのタイプ注釈の使用」を参照してください。

21. 「OK」をクリックします。新規作成されたXQueryマップが、「XQueryマッパー」グラフィカル・ビューに表示されます。XQueryソース・エディタを表示するには、「XQueryソース」をクリックします。

41.3 XQueryマッパーの使用

この項では、次の項目について説明します。

- 「値マッピング」を使用してリーフ要素値をターゲット・リーフ要素にコピーする方法

- 「マッピングの上書き」を使用して要素サブツリーをターゲット・ツリーにコピーする方法

- 「マッピングの追加」を使用して要素サブツリーをターゲット・ツリーにコピーする方法

- 1回のドラッグ・アンド・ドロップ操作で複数の値マッピングを実行する方法

41.3.1 「値マッピング」を使用してリーフ要素値をターゲット・リーフ要素にコピーする方法

リーフ要素の値マップを作成する手順は次のとおりです。

1. XQueryツールバーで「値マッピング」モードが選択されていることを確認します。

2. 値をコピーする必要があるソース・リーフ要素を選択します。

3. 左マウス・ボタンを押したまま、マウス・ポインタをターゲット・リーフ要素にドラッグします。左マウス・ボタンを離します。

ソース・リーフ・ノードとターゲット・リーフ・ノードをつなぐ実線が表示されます。これで、ソース・リーフ要素は、ターゲット・リーフ要素に値がマッピングされました。

41.3.2 「マッピングの上書き」を使用して要素サブツリーをターゲット・ツリーにコピーする方法

要素サブツリーの上書きマップを作成する手順は次のとおりです。

1. XQueryツールバーで「マッピングの上書き」モードが選択されていることを確認します。

2. ソース要素を選択します。この要素は子要素を含んでいても、リーフ要素であってもかまいません。

3. 左マウス・ボタンを押したまま、マウス・ポインタをターゲット要素にドラッグします。左マウス・ボタンを離します。

ソース要素のサブツリーがターゲット・ツリーの指定された場所にコピーされます。コピー元のソース・サブツリーのルートとターゲット・サブツリーが実線でつながれます。ターゲット・スキーマとのタイプの不一致がない場合、コピーされた要素とその子要素は、通常のフォントで表示されます。不一致がある場合、要素は下線付きのフォントで表示されます。

41.3.3 「マッピングの追加」を使用して要素サブツリーをターゲット・ツリーにコピーする方法

要素サブツリーの追加マップを作成する手順は次のとおりです。

1. XQueryツールバーで「マッピングの追加」モードが選択されていることを確認します。

2. ソース要素を選択します。この要素は子要素を含んでいても、リーフ要素であってもかまいません。

3. 左マウス・ボタンを押したまま、マウス・ポインタをターゲット要素にドラッグします。左マウス・ボタンを離します。

ソース要素のサブツリーが選択された要素の子としてターゲット・ツリーに追加されます。ソース・サブツリーのルートとターゲットに追加されたサブツリーのルートが実線でつながれます。ターゲット・スキーマとのタイプの不一致がない場合、コピーされた要素とその子要素は、通常のフォントで表示されます。不一致がある場合、要素は下線付きのフォントで表示されます。

41.3.4 1回のドラッグ・アンド・ドロップ操作で複数の値マッピングを実行する方法

1回のドラッグ・アンド・ドロップ操作で複数の値マッピングを作成する手順は次のとおりです。

1. XQueryツールバーで「値マッピング」モードが選択されていることを確認します。

2. 非リーフ・ソース要素を選択します。

3. 左マウス・ボタンを押したまま、マウス・ポインタをターゲット要素にドラッグします。左マウス・ボタンを離します。

ソース要素とターゲット要素のスキーマ・タイプが同じ場合、ソース要素およびターゲット要素のすべての子要素に対して個別のマッピングが作成されます。ソース要素とターゲット要素の間にもマッピングが作成されます。

1つの要素が複数回出現する場合は、その要素に対してFLOWRサイクルが自動的に作成されます。たとえば、次のコード・セグメントでは、各Itemが反復してコピーされます。

for $Item in $pParam1/Items/Item
return <Item PartNum="{fn:data($Item/@PartNum)}">
<ProductName>{fn:data($Item/ProductName)}</ProductName>
<Quantity>{fn:data($Item/Quantity)}</Quantity>
<Price>{fn:data($Item/Price)}</Price>
<Currency>{fn:data($Item/Currency)}</Currency>
</Item>

41.4 XQuery関数の使用

XQuery関数を既存のXQueryマップに追加できます。「コンポーネント」ウィンドウには、ソース・エディタまたはXQueryマッパーの中央ペインにドラッグ・アンド・ドロップできるXQuery関数のリストが含まれています。

また、「コンポーネント」ウィンドウには、一連のXQueryコンストラクト(FLWORなど)およびXQuery演算子(論理ANDなど)も含まれています。これらのコンストラクトおよび演算子は、ソース・エディタにのみドラッグおよびドロップできます。

41.4.1 XQueryマッパーでのXQuery関数の追加方法

「コンポーネント」ウィンドウからXQueryマッパーの中央ペインにXQuery関数をドラッグ・アンド・ドロップできます。

41.4.1.1 XQuery関数を追加する手順:

1. 「コンポーネント」ウィンドウが表示されていることを確認します。デフォルト位置はOracle JDeveloperの右上隅です。
「コンポーネント」ウィンドウが表示されていない場合、「ウィンドウ」メニューから「コンポーネント」を選択します。

2. 「コンポーネント」ウィンドウで、「XQuery関数」ページを選択します。

3. 関数を含める「カテゴリ」をクリックします。たとえば、concat関数を追加するには「文字列関数」をクリックします。

4. 「コンポーネント」ウィンドウからXQueryマッパーの中央ペインに目的の関数をドラッグします。関数を中央ペインにドラッグすると、移動に伴って、関数の出力が様々なターゲット・ノードに接続されます。
図41-9 は、XQueryマッパーの中央ペインにドラッグされた関数を示しています。

図41-9 XQueryマッパーの中央ペインへの関数のドラッグ

5. 関数出力が目的のターゲット・ノードに接続されていることを示すときに、関数を中央ペインにドラッグします。

注意:

XQueryマッパーの中央ペインで、既存のマップ線に関数をドロップすることもできます。

この関数は、ソース(入力)とターゲット(出力)の両方のノードに接続されます。

6. 関数に追加の入力パラメータが必要な場合は、関数アイコンに警告アイコンが表示されます。ソース・ノードから関数の左端に線をドラッグして、入力パラメータを指定します。

7. 入力パラメータとして追加する必要のあるソース・ノードがまだある場合は、前述の手順を繰り返します。

41.4.1.2 関数のパラメータを編集する手順:

1. 中央ペインで関数アイコンをクリックします。関数に対応する式が「プロパティ」ウィンドウに表示されます。
「プロパティ」ウィンドウは、デフォルトではOracle JDeveloperの右下隅にあります。「プロパティ」ウィンドウが表示されない場合は、「ウィンドウ」メニューの「プロパティ」をクリックすると、「プロパティ」ウィンドウが表示されます。オプションで、「JDeveloper」ウィンドウ内の使いやすい場所に「プロパティ」ウィンドウをドラッグする選択ができます。また、「プロパティ」ウィンドウは必要に応じてサイズを変更できます。

2. 「プロパティ」ウィンドウの右側のペインに表示された式を編集します。
「プロパティ」ウィンドウの左側のペインには、現在のスコープで表示可能なすべての変数が含まれた変数ツリーが表示されます。右側の式に変数をドラッグ・アンド・ドロップすることで、関数定義の作成が容易になります。

3. 「プロパティ」ウィンドウの左上隅にある「コミット」をクリックして、変更内容を保存します。または、「マッパー・リソースに戻す」をクリックして、「プロパティ」ウィンドウで行った変更を元に戻します。

41.5 ライブラリ・モジュールの使用

「XQueryメイン/ライブラリ・モジュールの作成方法」では、ライブラリ・モジュール・ファイルの作成プロセスについて説明しています。ライブラリ・モジュールを使用するには、ライブラリ・モジュールをメイン・モジュールにインポートできます。これによって、ライブラリ・モジュールのすべての関数がメイン・モジュールで使用できるようになります。

41.5.1 ライブラリ・モジュールのインポート方法

メイン・モジュールのソース・エディタからライブラリ・モジュールをインポートできます。

ライブラリ・モジュールをインポートする手順は、次のとおりです。

1. XQueryマッパーで、XQueryメイン・モジュールのマップ・ファイルが開かれていることを確認します。

2. 「XQueryマッパー」ウィンドウの左下にある「XQueryソース」タブをクリックして、ソース・エディタに切り替えます。

3. 「ソース・エディタ」ウィンドウの任意の場所を右クリックします。コンテキスト・メニューが表示されます。

4. コンテキスト・メニューから「ライブラリ・モジュールのインポート」を選択します。「XQueryライブラリ・ファイルの選択」ダイアログが表示されます。

5. インポートするXQueryライブラリ・モジュール・ファイルを参照して選択します。「OK」をクリックします。

ライブラリ・モジュールに対応したimport文がメイン・モジュールのソース・ビューに追加されます。

41.6 ゾーンおよびFLWORコンストラクトの使用

ソース・ビューで、FLWOR (For、Let、Where、Order By、Return)式を作成できます。FLWOR式は、XQueryマッパーのターゲット・ツリーでゾーンとして表示されます。

ゾーンは、FLOWRコンストラクトまたはIf-Then-Else条件付きコンストラクトに関連付けられているターゲット・ツリーの領域を識別します。ゾーンは、ターゲット・ツリーの左側に黄色の大カッコで表示されます。

ゾーンを表す黄色の線にマウスを合せると、線が青色に変わります。FLWORゾーンでは、For-Let句、Where句およびOrder By句に対応した追加のボタンが表示されます。図41-10 に、ゾーンが表示されたXQueryのサンプルを示します。

図41-10 XQueryマッパーでのゾーンおよびFLWORゾーン

41.6.1 FLWORコンストラクトの編集方法

ソース・ビューでFLWORコンストラクトを直接編集できます。XQueryマッパーでも、FLOWRコンストラクトを制限付きで編集できます。

XQueryマッパーでFLWORコンストラクトを編集する手順は、次のとおりです。

1. FLWORゾーンを表す黄色の大カッコをクリックして、ゾーンを選択します。黄色の大カッコが青色に変わり、追加のボタンが表示されます。これらのボタンは、FLWORコンストラクトの様々な句に対応しています。

2. 「FL」ボタンをクリックして、FLWORコンストラクトのFor-Letプロパティを編集します。「プロパティ」ウィンドウにFor-Let句のプロパティが表示されます。

「プロパティ」ウィンドウで「ヘルプ」アイコンをクリックして、For-Letプロパティの編集についてのヘルプを表示します。

3. 「W」ボタンをクリックして、FLWORコンストラクトのWhereプロパティを編集します。

「プロパティ」ウィンドウでは、Where式を直接編集できます。「プロパティ」ウィンドウの左側のペインから変数をドラッグ・アンド・ドロップすることもできます。

4. 「O」ボタンをクリックして、FLWORコンストラクトのOrder Byプロパティを編集します。

「プロパティ」ウィンドウでは、Order By式を直接編集できます。「プロパティ」ウィンドウの左側のペインから変数をドラッグ・アンド・ドロップすることもできます。

41.7 XQueryパフォーマンス向上のためのタイプ注釈の使用

XQueryが実行されると、XQueryエンジンによって、XQueryを実行する前にXQueryファイル内のスキーマ・タイプの検証が実行されます。これによって、一部のアプリケーションでパフォーマンスのオーバーヘッドが発生する場合があります。

パフォーマンスのためにXQuery関数を最適化する必要がある場合は、タイプ注釈を使用してXQueryファイルでスキーマ情報を指定します。タイプ注釈を使用すると、スキーマ・タイプの定義をXQuery実行エンジンから隠すことができます。スキーマ定義はXqueryマッパーには表示されるため、XQueryマップを通常どおりに編集できます。

XQueryファイルでタイプ注釈を使用するには、新しいXQueryファイルの作成時に、「XQueryマップ・メイン・モジュールの作成」/「XQueryマップ・ライブラリ・モジュールの作成」ダイアログで「スキーマ・タイプ注釈の使用」を選択します。XQueryファイルの作成の詳細は、「XQueryメイン/ライブラリ・モジュールの作成方法」を参照してください。

XQueryファイルのタイプ注釈は、標準のXQueryコメントのように表示されます。標準のXQueryコメントは、カッコとコロンで区切られますが、タイプ注釈では、カッコと二重コロンが使用されます。そのため、次のようになります。

(: This is an XQuery comment :)
(:: This is a type annotation ::)

タイプ注釈を使用するXQueryファイルには、ファイルの最初のバージョン宣言の直後に次のようなバージョン注釈があります。

(:: OracleAnnotationVersion "1.0" ::)

次の例では、いくつかのXQueryコンストラクトをタイプ注釈のあるものとないもので比較します。

- スキーマのインポート(タイプ注釈なし):

import schema namespace ns1="http://www.oracle.com/pcbpel/po" at "../Schemas/PurchaseOrder.xsd";

スキーマのインポート(タイプ注釈あり):

declare namespace ns1="http://www.oracle.com/pcbpel/po";
(:: import schema at "../Schemas/PurchaseOrder.xsd" ::)

- 変数宣言(タイプ注釈なし):

declare variable $test_param as schema-element(ns1:PurchaseOrder) external;

変数宣言(タイプ注釈あり):

declare variable $test_param as element()
(:: schema-element(ns1:PurchaseOrder) ::) external;

41.8 XQueryマップのテスト

Oracle JDeveloper内でXQueryマップの実行をテストできます。設計時にXQueryをテストすると実行時エラーの予防に役立ちます。

41.8.1 XQueryマップのテスト方法

XQueryマップをテストするには、「ソース・エディタ」ビューを使用する必要があります。

XQueryマップをテストする手順は、次のとおりです。

1. XQueryマッパーで、XQueryメイン・モジュールが開かれていることを確認します。

2. 「ソース・エディタ」ビューを使用していない場合は、「XQueryマッパー」ウィンドウ下部にある「XQueryソース」タブをクリックして、ソース・エディタに切り替えます。

3. ソース・エディタの任意の場所を右クリックします。表示されるコンテキスト・メニューから「XQueryの実行」を選択します。

「XQueryの実行」ダイアログが表示されます。図41-11 に、「XQueryの実行」ダイアログを示します。

図41-11 「XQueryの実行」ダイアログ

4. 「ソース変数」セクションに表示されるすべてのソース変数に値を指定します。

単純なデータ型の場合は、「値」フィールドで値を直接指定できます。ソース変数で複雑なスキーマが使用されている場合は、省略記号(. . .)ボタンをクリックすると「変数の編集」ダイアログが表示されます。既存のXMLファイルを使用して変数のテスト・データを指定するか、テスト・データでXMLファイルを作成できます。「ヘルプ」をクリックすると、「変数の編集」ダイアログの入力に関するヘルプが表示されます。

5. テスト結果を表示するために新しいタブを使用する場合は、「JDeveloperの新規タブで結果を開く」を選択します。結果ファイルを保存するには「ターゲット・ファイルの保存」を選択します。これらのオプションは、1つまたは両方を選択する必要があります。

6. 「ターゲット・ファイル名」の右にある「保存」アイコンをクリックして、結果データを保存する結果ファイルを指定します。

前の手順で「ターゲット・ファイルの保存」を選択しなかった場合でも、「ターゲット・ファイル名」を指定する必要があります。

7. 必要に応じて「自動保存構成」を選択して、XQuery実行時に構成設定が自動的に保存されるようにします。次回XQueryの実行を試みると、構成設定が取得されます。

8. 「XQueryの実行」ダイアログで行った設定を保存する場合は、「構成の保存」をクリックします。

9. 以前保存した構成設定を削除する場合は、「構成の削除」をクリックします。

10. 「実行」をクリックしてXQueryを実行します。

42 ビジネス・イベントおよびイベント配信ネットワークの使用

この章では、SOAコンポジット・アプリケーションでOracle MediatorまたはBPELプロセスからビジネス・イベントをサブスクライブまたは公開する方法を説明します。ビジネス・イベントは、イベント配信ネットワーク(EDN)に公開され、ビジネス環境で発生した結果として送信されるメッセージ・データから構成されます。ビジネス・イベントが公開されると、他のサービス・コンポーネントはそれをサブスクライブできます。

この章の内容は次のとおりです。

- ビジネス・イベントの概要

- Oracle JDeveloperでのビジネス・イベントの作成

- サービス・コンポーネントからのビジネス・イベントのサブスクライブまたは公開

- BPELプロセス・サービス・コンポーネントからのビジネス・イベントのサブスクライブまたは公開

- Oracle ADF Business Componentビジネス・イベントをOracle Mediatorに統合する方法

ビジネス・イベントをサブスクライブするサービス・コンポーネントでのコンポジット・センサーの作成の詳細は、「コンポジット・センサーの定義」を参照してください。

スレッド数の指定、イベント配信の停止、最大配信数の指定などビジネス・イベントのトラブルシューティングの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の付録「Oracle SOA SuiteおよびOracle BPM Suiteのトラブルシューティング」を参照してください。

Oracle Enterprise Manager Fusion Middleware Controlからのビジネス・イベントの管理の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「ビジネス・イベントの管理」を参照してください。

ビジネス・イベント・チューニングの詳細は、『パフォーマンスのチューニング』を参照してください。

42.1 ビジネス・イベントの概要

目的の状況が発生したときにビジネス・イベントを起動できます。たとえば、ローン・フローのシナリオで、ローン・プロセスを実行しているBPELプロセス・サービス・コンポーネントは、プロセスの完了時にローン完了イベントを起動できます。このアプリケーションのインフラストラクチャ内の他のシステムは、これらのイベントをリスニングし、イベントのインスタンスの受信時に次の処理を実行できます。

- イベント・コンテキストを使用して、ビジネス・インテリジェンスまたはダッシュボード・データを導出します。

- 融資パッケージを顧客に送る必要があることをメール部門に知らせます。

- 別のビジネス・プロセスを起動します。

- Oracle Business Activity Monitoring (BAM)に情報を送信します。

通常、ビジネス・イベントは、ビジネスの状態変化に関する通知を送信するための一方向のfire-and-forget非同期方法です。ビジネス・プロセスは、次の処理を行いません。

- ビジネス・イベントの完了を受信するサービス・コンポーネントに依存しません。

- 他のサービス・コンポーネントがビジネス・イベントを受信しても関係ありません。

- サブスクライバの存在(存在する場合)およびデータがサブスクライバに与える影響を知る必要がありません。

これらは、Web Services Description Language (WSDL)ファイル規定に依存する直接サービス起動(SOAPサービス・クライアントなど)とビジネス・イベントの重要な相違点です。イベントの発生がイベントの受信者に依存する場合、メッセージは通常、ビジネス・イベントではなくサービス起動を通して配信する必要があります。直接サービス起動とは異なり、ビジネス・イベントはサーバーからクライアントを分離します。

ビジネス・イベントは、イベント定義言語(EDL)を使用して定義されます。EDLは、ビジネス・イベント定義の作成に使用するスキーマです。アプリケーションは、ビジネス・イベント定義のインスタンスと協調して動作します。

EDLは、次のもので構成されます。

- 定義済イベント
同じネームスペース(definitionsルート要素のtargetNamespace属性)を持つ1つ以上のイベント定義(event-definition要素)の場合、それぞれがローカル名(event-definition要素のname属性)を持ちます。ネームスペースおよびローカル名は、イベント名(QName)を構成します。

- ペイロード定義
定義には、XMLスキーマ(XSD)が最も一般的に使用されます。ビジネス・イベントのペイロードは、(schema-import要素を介して)EDLにインポートされたXSDで定義されます。定義済の各イベント(つまりevent-definition要素)には、インポートされたペイロードのXSD要素(content要素のelement属性)への参照を含めることができます。スキーマのURIは、ペイロードのルート要素に含まれます。

次の例は、BugReportイベント定義内に2つのビジネス・イベントbugUpdatedおよびbugCreatedがあるEDLファイルを示しています。ネームスペース(/model/events/edl/BugReport)および関連するスキーマ・ファイル(BugReport.xsd)が参照されます。

<?xml version = '1.0' encoding = 'UTF-8'?>
<definitions targetNamespace="/model/events/edl/BugReport"
xmlns:ns0="/model/events/schema/BugReport"
xmlns="http://schemas.oracle.com/events/edl">
<schema-import namespace="/model/events/schema/BugReport"
location="BugReport.xsd"/>

<event-definition name="bugCreated">
<content element="ns0:bugCreatedInfo"/>
</event-definition>

<event-definition name="bugUpdated">
<content element="ns0:bugUpdatedInfo"/>
</event-definition>
</definitions>

これら2つのイベントはOracle MediatorおよびBPELプロセスのサブスクリプションで使用できます。

ビジネス・イベントは、Oracle Metadata Servicesリポジトリ(MDSリポジトリ)にデプロイされます。ビジネス・イベントをそのアーティファクト(XSDなど)とともにMDSリポジトリにデプロイすることを、EDL (またはイベント定義)の公開とも呼びます。このアクションにより、EDLおよびそのアーティファクトがMDSリポジトリ内の共有領域に転送されます。MDSリポジトリ共有領域内のオブジェクトは、Oracle JDeveloperの「リソース」ウィンドウ内のすべてのアプリケーションで参照できます。EDLは公開後、Oracle MediatorやBPELプロセスなどのSOAコンポーネントでサブスクライブできます。

サブスクリプションは、特定の修飾名(QName)(x.y.z/newOrdersなど)に対して行います。QNameはタプル(URI、localName)であり、xmlns:prefix=URIなどのネームスペース宣言またはネームスペース・コンテキストとの組合せで、文字列prefix:localNameから導出できます。また、コンテンツ・ベースのフィルタを使用すると、サブスクリプションをさらに絞り込むことができます。

ビジネス・イベントは、EDNに公開されます。EDNはOracle SOA Suiteの各インスタンス内で実行されます。発生したイベントはEDNにより、サブスクライブするサービス・コンポーネントに配信されます。Oracle Mediatorサービス・コンポーネントとBPELプロセス・サービス・コンポーネントはイベントをサブスクライブし、公開できます。

EDNは、Oracle SOA SuiteコンポーネントとOracle SOA Suite以外のコンポーネントとの間のビジネス・イベントベースの相互作用をサポートする、標準のJMSメッセージング・インフラストラクチャに基づいています。EDNは次の2つのJMSベースのタイプを提供します。

- Oracle WebLogic Server JMS: デフォルトでは、すべてのビジネス・イベントで、1つのデフォルトOracle WebLogic Server JMSトピックを使用します。

- Oracle Advanced Queueing (AQ) JMS

追加のJMSトピック(Oracle WebLogic Server JMSまたはAQ JMS)を作成して、Oracle Enterprise Manager Fusion Middleware Controlでこれらの追加のJMSトピックに別々のイベント・タイプをマッピングできます。

注意:

- EDNでは、永続サブスクリプションはサポートされません(ネイティブのAQとOracle WebLogic Server JMSのどちらでサポートされている場合でも)。サブスクライブするサービス・コンポーネントを実行して、イベントを受信する必要があります。

42.1.1 Oracle SOA SuiteとのEDN統合

Oracle SOA Suite EDNには、次の機能があります。

- 次の機能を備えた標準JMSベースのメッセージング・インフラストラクチャ。

- JMSベースのイベントが、Oracle SOA SuiteクライアントおよびOracle SOA Suite以外のクライアント用のアーキテクチャを公開およびサブスクライブします。

- 双方向の相互作用をサポートします(Oracle SOA SuiteとOracle SOA Suite以外のクライアント間で公開とサブスクライブの両方を実行できます)。

- Oracle AQ JMSおよびOracle WebLogic Server JMSプロバイダの両方をサポートします。Oracle WebLogic Server JMSトピック(デフォルト)およびAQ JMSトピックは、インストール後にEDNを使用できるよう自動的に構成されます。デフォルトのJMSタイプは、Oracle Enterprise Manager Fusion Middleware Controlで、Oracle WebLogic Server JMS (デフォルト)からAQ JMSに切替え可能です。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「ビジネス・イベント」ページでのJMSトピック宛先へのビジネス・イベントのマッピングに関する項を参照してください。

- EDNが軽量マネージャとして、前述のJMSプロバイダをサポートします。

- プレーンJMS APIおよびOracle SOA Suite、リモート用に値を追加したEDN API、Oracle SOA Suiteとの統合に使用するOracle SOA Suite以外のクライアント。詳細は、『Oracle SOA Suiteイベント配信ネットワークのJava APIリファレンス』を参照してください。

- EDN配信を保証するJMSトランザクション(OAOO (one-and-only-one)と一貫性保証済メソッドの両方)。

- メッセージ・ロスを防ぐ、永続的な公開配信オプション。これらのデフォルト・オプションは、リモートのOracle SOA Suite以外のクライアントとの相互作用に役立ちます。

- 多数のJMSの機能の実装に内部で使用されるJMSアダプタ。JMSアダプタの詳細は、『テクノロジ・アダプタの理解』の「JMS用のOracle JCAアダプタ」を参照してください。

- マルチノード・クラスタではイベントを重複して処理しません。

- 非常に詳細なレベルのスケーラビリティ。これにより、様々なイベントを様々なJMSトピックの接続先にマッピングできるので、1箇所ですべてのイベントを処理する必要がなくなります。これにより、ボトルネックの可能性がなくなります。マッピングは、Oracle Enterprise Manager Fusion Middleware Controlの管理者が実行します。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のJMSトピックの接続先へのビジネス・イベントのマッピングに関する項を参照してください。

- 次の公開およびサブスクライブのシナリオをサポートします。

- 同じコンポジット間または別のコンポジット間でイベントを公開およびサブスクライブします。

- 自動的に提供されるデフォルトEDN Oracle WebLogic Server JMSトピックを使用します。

- Oracle Enterprise Manager Fusion Middleware Controlで提供される、イベントからJMSトピックへのカスタム・マッピングを使用します。

- 次のいずれかのAPIを使用して、リモートのOracle SOA Suite以外の参加者からイベントを公開およびサブスクライブします。

- プレーンJMS API (J2SEクライアント環境用)

- EDI API EdnJmsConnection (J2SEおよびJ2EEクライアント環境用)

- エラー・ホスピタルでインスタンス・トラッキングおよびフォルト・リカバリをサポートします。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

- MDSリポジトリのEDLファイルの記憶域。これにより、ファイルをOracle JDeveloperの「リソース」ウィンドウで参照できます。詳細は、「デザインタイムMDSリポジトリとの共有データの管理」を参照してください。

注意:

Oracle AQ JMSによるイベント配信ネットワーク(EDN)で大規模なペイロードを送信する際のメモリーの推奨サイズについては、「SOAコンポジット・アプリケーション用JVMメモリーのサイズ設定の推奨事項」を参照してください。

42.1.2 ビジネス・イベントAPIでのリモート・クライアントのサポート

Oracle SOA Suiteでイベントを公開およびサブスクライブするリモート・クライアントには、APIオプションがいくつかあります。表42-1に詳細を示します。

表42-1 リモートAPIオプション

オプション

説明

サポート

メリット/デメリット

プレーンJMS API

EDN JMSトピックとの直接対話に使用します。これは通常、RAW JMSアクセスを使用するJ2SEクライアントです。

リモート・クライアントでは、SOAサーバーを指すようにJNDIプロパティを構成する必要があります。

- Oracle WebLogic Server JMS

- AQ JMS

このメリットは、次のとおりです。

- 標準JMS APIをサポートします。つまり、多くのJMSソフトウェア・ツールを使用できます。

このデメリットは、次のとおりです。

- サービス・レベルが低下します。

- マッピングされたJMSやJNDIの構成を手動で探す必要があります。

- 内部EDNイベント構造の処理、フィルタ変換、サブジェクト伝播、トランザクション、エラー処理など、追加のコーディングが必要です。

EDN API - EdnJmsConnection

Oracle Event ProcessingなどのJ2SEクライアント用です。このオプションには、標準の公開およびサブスクライブ・オプションがすべて用意されています。

リモート・クライアントでは次のタスクを実行する必要があります。

- SOAサーバーを指すようにJNDIプロパティを構成します。

- EDNヘルパー・メソッドfindRelevantBEConnFactoryを呼び出して、適切なコネクション・ファクトリを返します。これにより、JMSコネクションでイベントの公開およびサブスクライブが使用可能になります。

- Oracle WebLogic Server JMS

- AQ JMS

このメリットは、次のとおりです。

- クライアントJNDIの構成またはJMSアダプタ・デプロイメントがありません。

- JMSのマッピング、変換および翻訳を処理します。

このデメリットは、次のとおりです。

- プレーンJMSコネクション・ファクトリおよびトピックをベースにしています。

JMSアダプタの詳細は、『テクノロジ・アダプタの理解』の「JMS用のOracle JCAアダプタ」を参照してください。

EDN APIの詳細は、『Oracle SOA Suiteイベント配信ネットワークのJava APIリファレンス』を参照してください。

42.1.2.1 BusinessEvent.setProperty APIを呼び出す際のイベント配信ネットワーク・プロパティの手動設定に関するガイドライン

イベント配信ネットワーク(EDN)ビジネス・イベントを公開する場合、ほとんどのプロパティではBusinessEvent.setProperty(String name, Object value) APIを呼び出して手動設定することはできません。

42.1.2.1.1 手動で設定できないプロパティ

次のEDNビジネス・イベント・プロパティは設定しないでください。これらのプロパティの値は内部で設定され、EDNによって使用されます。

- 一般プロパティ:

- BusinessEvent.EVENT_ID ("id")

- BusinessEvent.PARENT_ID ("parent-id")

- BusinessEvent.PUBLISHED_TIME ("published-time")

- BusinessEvent.OWNER ("owner")

- BusinessEvent.SOURCE ("source")

- BusinessEvent.MODE ("mode")

- すべてのトラッキング・プロパティの例:

- BusinessEvent.PROPERTY_ECID ("tracking.ecid")

- BusinessEvent.PROPERTY_COMPOSITE_INSTANCE_ID ("tracking.compositeInstanceId")

- BusinessEvent.PROPERTY_PARENT_COMPONENT_INSTANCE_ID ("tracking.parentComponentInstanceId")

- BusinessEvent.PROPERTY_CONVERSATION_ID ("tracking.conversationId")

- tracking.compositeInstanceCreatedTime"

42.1.2.1.2 手動で設定可能なプロパティ

次のプロパティを設定できます。

- BusinessEvent.PRIORITY ("priority")

- BusinessEvent.CONTEXT ("context")

42.1.3 ローカル・イベント接続およびリモート・イベント接続

1つのSOAコンポジット・アプリケーション・インスタンスは、1つのコンテナ内に配置することも、複数のコンテナにわたってクラスタ化することもできます。別のアプリケーション(Oracle Application Development Framework (ADF) Business Componentアプリケーションなど)を構成し、SOAコンポジット・アプリケーション・インスタンスと同じコンテナ内または異なるコンテナ内で実行できます。

ローカル・イベント接続またはリモート・イベント接続を通して、Java EEアプリケーションからイベントを発生させることができます。

- ローカル・イベント接続
パブリッシャがアプリケーションと同じOracle WebLogic Serverに存在し、パブリッシャがローカル・ビジネス・イベント・コネクション・ファクトリを使用する場合、イベントはローカル・イベント接続を通して発生します。

- リモート・イベント接続
コール元がアプリケーションと異なるコンテナ(異なるJVM)内に存在する場合、イベントはリモート・イベント接続を通して発生します。

別のアプリケーション(Oracle ADF Business Componentアプリケーションなど)を構成し、SOAコンポジット・アプリケーションと同じコンテナ内で実行すると、このアプリケーションはローカル・イベント接続を使用するように最適化されます。

42.2 Oracle JDeveloperでのビジネス・イベントの作成

この項では、ビジネス・イベントの作成方法およびサブスクライブ方法の高レベルな概要が提供されます。

42.2.1 ビジネス・イベントの作成方法

ビジネス・イベントを作成する手順は、次のとおりです。

1. SOAプロジェクトを空のコンポジットとして作成します。

2. 次の方法のいずれかにより、イベント定義の作成ウィザードを起動します。

a. 「ファイル」メイン・メニューで、「新規」→「イベント定義」を選択します。

b. 「ファイル」メイン・メニューで、「新規」→「アプリケーション」→「SOA層」→「サービス・コンポーネント」→「イベント定義」を選択します。

「イベント定義の作成」ダイアログが表示されます。

3. 表42-2 に記載されている詳細を入力します。

表42-2 「イベント定義の作成」ダイアログのフィールドと値

フィールド

値

名前

名前を入力するか、EventDefinitionnumberのデフォルト名をそのまま使用します。ここで入力した名前が「アプリケーション」ウィンドウの「EDLファイル名」になります。

注意: イベント名としてスラッシュ(/)を入力しないでください。スラッシュを入力すると、名前が拡張子のみのイベント定義ファイル(.edn)が作成されます。

ディレクトリ

イベント定義ファイルを作成するディレクトリ・パスを表示します。

ネームスペース

デフォルトのネームスペースをそのまま使用するか、イベントを配置するネームスペースに対する値を入力します。これにより、サブスクライバは指定されたネームスペースのイベントを受信します。

4. 「追加」アイコンをクリックして、イベントを追加します。
「イベントの作成」ダイアログが表示されます。

5. 「検索」アイコンをクリックしてペイロードを選択し、「OK」をクリックします。図42-1に詳細を示します。

図42-1 ペイロードの選択

「イベントの作成」ダイアログに戻ります。

6. 「名前」フィールドに、名前を入力します。

7. 「OK」をクリックします。
これで、追加されたイベントが「イベント」セクションに表示されます。図42-2に詳細を示します。

図42-2 イベント定義の作成

8. エディタの上部にある、event_definition_name.edlの横のxアイコンをクリックして、エディタを閉じます。

9. 変更を保存するように求められた場合は、「はい」をクリックします。変更を保存しないとイベントは作成されず、「イベント・チューザ」ウィンドウでは選択できません。
ビジネス・イベントがMDSリポジトリに公開され、に戻ります。「リソース」ウィンドウに、ビジネス・イベントが表示され参照できます。

42.3 Oracle Mediatorサービス・コンポーネントからのビジネス・イベントのサブスクライブまたは公開

この項では、Oracle Mediatorサービス・コンポーネントからビジネス・イベントをサブスクライブまたは公開する方法について説明します。

42.3.1 ビジネス・イベントをサブスクライブする方法

ビジネス・イベントをサブスクライブするには:

1. 「コンポーネント」ウィンドウからに、メディエータ・サービス・コンポーネントをドラッグします。このサービス・コンポーネントにより、ビジネス・イベントをサブスクライブできます。

2. 「名前」フィールドに、名前を入力します。

3. 「テンプレート」リストから、「イベントのサブスクライブ」を選択します。

ダイアログがリフレッシュされ、イベント表が表示されます。

4. 「追加」アイコンをクリックして、イベントを選択します。

「イベント・チューザ」ダイアログが表示されます。

5. 既存のイベントを選択するか、「追加」アイコンをクリックして新規イベントを作成し、「OK」をクリックします。

「メディエータの作成」ダイアログが再び表示されます。

6. ダイアログの残りのフィールドを完成します。表42-3に詳細を示します。

表42-3 「メディエータの作成」ダイアログのイベント表

要素

説明

一貫性

「一貫性」列内をクリックし、イベントに対する配信一貫性のレベルを選択します。

- 唯一
イベントは、それ自体のグローバル(つまりJTA)トランザクションのサブスクライバに配信されます。イベント処理が完了すると、そのトランザクション内でサブスクライバが行ったあらゆる変更がコミットされます。サブスクライバが失敗すると、トランザクションはロールバックされます。再試行可能例外で失敗したイベントは、リカバリのために「エラー・ホスピタル」に移動される(手動再試行の対象となる)前に、構成された回数だけ自動的に再試行されます。再試行不能な例外で失敗したイベントは、自動再試行せずに「エラー・ホスピタル」に移動され、リカバリできません。

- 保証付き
ローカルJMSトランザクションでサブスクライバにイベントを配信します。サブスクライバは、処理用にサブスクライバ自体のローカル・トランザクションの作成を選択できますが、他のイベント処理とは個別にコミットされます。「保証付き」一貫性レベルは、ローカル・トランザクションがグローバル・トランザクションのかわりに使用されるため、「唯一」よりも低品質のサービス・オプションです。再試行可能な例外で失敗したイベントは、リカバリ可能な「エラー・ホスピタル」に移動される(手動再試行の対象となる)前に、構成された回数が自動的に再試行されます。再試行不能な例外で失敗したイベントは、自動再試行せずに「エラー・ホスピタル」に移動され、リカバリできません。

「エラー・ホスピタル」の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のエラー・ホスピタルでのフォルトからのリカバリに関する項を参照してください。

恒久

恒久サブスクリプションでは、パブリッシャ、サブスクライバおよびフレームワークのライフ・サイクルの相違によるメッセージ・ロスを防ぎます。次のオプションを選択します。

- はい: サブスクライバが実行中でない場合、イベントが保持されます。これはデフォルト選択です。

- いいえ: サブスクライバが実行中でない場合、イベントが削除されます。

パブリッシャとして実行

セキュリティ公開オプションを選択します。

- はい: サブスクライバにイベント・パブリッシャのセキュリティIDがあります。これはデフォルト選択です。

- いいえ: サブスクライバにイベント・パブリッシャのセキュリティIDがありません。

フィルタ

イベントをフィルタリングするには、選択したイベントの「フィルタ」列をダブルクリックするか、またはイベントを選択して、表の上の「フィルタ」アイコン(最初のアイコン)をクリックします。これにより「式ビルダー」ダイアログが表示されます。このダイアログで、XPathフィルタ式を指定できます。フィルタ式では、サービスの起動前にメッセージのコンテンツ(ペイロードまたはヘッダー)が分析されるように指定します。たとえば、メッセージに顧客IDが含まれている場合のみサービスを起動することを指定するフィルタ式を適用できます。

式のロジックが満たされると、イベントの配信が可能になります。

フィルタの詳細は、「メッセージをフィルタリングする式の指定方法」を参照してください。

図42-3 は、「メディエータの作成」ダイアログを示しています。

図42-3 「メディエータの作成」ダイアログ

7. 「OK」をクリックします。

図42-4 に、イベント・サブスクリプションのためにOracle Mediatorが構成されたことを示す左側のアイコンを示します。

図42-4 イベント・サブスクリプションの構成

42.3.2 ビジネス・イベントを公開する方法

「ビジネス・イベントをサブスクライブする方法」でサブスクライブしたイベントを公開するための、2番目のOracle Mediatorを作成できます。ここには示されていませんが、イベントを公開するためのBPELコンポーネントも作成できます。

ビジネス・イベントを公開するには:

1. 最初のOracle Mediatorがサブスクライブしたイベントを公開する、2番目のOracle Mediatorサービス・コンポーネントを作成します。

2. 最初のOracle Mediatorサービス・コンポーネントに戻ります。

3. 「ルーティング・ルール」セクションで、「追加」アイコンをクリックします。

4. 「ターゲット・タイプ」ウィンドウでプロンプトが表示されたら、「サービス」をクリックします。

5. 2番目のOracle Mediatorサービス・コンポーネントを選択します。

6. 「ファイル」メイン・メニューから、「すべて保存」を選択します。

42.3.3 ビジネス・イベントの作成およびサブスクライブ時の処理内容

次の例のソース・コードに、Oracle Mediatorサービス・コンポーネントのサブスクライブするイベントに関する詳細を示します。

<component name="OrderPendingEvent">
<implementation.mediator src="OrderPendingEvent.mplan"/>
<business-events>
<subscribe
xmlns:sub1="/oracle/fodemo/storefront/entities/events/edl/OrderEO"
name="sub1:NewOrderSubmitted" consistency="oneAndOnlyOne"
durable="true" runAsRoles="$publisher"/>
</business-events>
</component>

この例では明示的に示されていませんが、イベントにおいてXPathフィルタを定義できます。次の例では、初期デポジットが50000を超える場合にのみ、イベントの配信が可能になります。

<business-events>
. . .
. . .
<filter>
<xpath xmlns:be="http://oracle.com/fabric/businessEvent"
xmlns:ns1="http://xmlns.oracle.com/singleString"
<xpath expression= "/be:business-event/be:content/
sub1:AccountInfo/Details[@initialDeposit > 50000]" />
</filter>
. . .
. . .
</business-events>

42.3.4 ビジネス・イベント公開時の処理内容

次の例には、2つのOracle Mediatorサービス・コンポーネントが示されています。1つのサービス・コンポーネント(OrderPendingEvent)はイベントをサブスクライブし、もう1つのサービス・コンポーネント(PublishOrderPendingEvent)はイベントを公開します。

<component name="PublishOrderPendingEvent">
<implementation.mediator src="PublishOrderPendingEvent.mplan"/>
<business-events>
<publishes xmlns:sub1="/oracle/fodemo/storefront/entities/events/edl/OrderEO"
name="pub1:NewOrderSubmitted" persistent="true" priority="7"
timeToLive="36000000"/>
</business-events>
</component>

<component name="OrderPendingEvent">
<implementation.mediator src="OrderPendingEvent.mplan"/>
<business-events>
<subscribe
xmlns:sub1="/oracle/fodemo/storefront/entities/events/edl/OrderEO"
name="sub1:NewOrderSubmitted" consistency="oneAndOnlyOne"
durable="true" runAsRoles="$publisher"/>
</business-events>
</component>

42.3.5 ビジネス・イベントのサブスクライブに関する必知事項

SOAコンポジット・アプリケーションのデフォルト・リビジョンのサブスクライバのみがビジネス・イベントを受信できます。たとえば、次の動作に注意してください。

ビジネス・イベントをサブスクライブするには:

1. M1という最初のOracle Mediatorサービス・コンポーネントとM2という2番目のOracle Mediatorサービス・コンポーネントを含む、コンポジット・アプリケーションを作成します。M1はイベントを公開し、M2はイベントをサブスクライブします。出力はディレクトリに書き込まれます。

2. コンポジット・アプリケーションをリビジョン1としてデプロイします。

3. コンポジット・アプリケーションを変更して、M3という3番目のOracle Mediatorサービス・コンポーネントを追加します。M3は、同じイベントをサブスクライブし、別のディレクトリに出力を書き込みます。

4. コンポジット・アプリケーションをリビジョン2(デフォルト)としてデプロイします。

5. リビジョン2のコンポジット・アプリケーションを起動します。

Oracle Mediator M2は、ディレクトリ内の1つのファイルに出力を書き込みます。Oracle Mediator M3は、予想どおりに、イベントを取得し、別のディレクトリに出力を正常に書き込みます。ただし、(リビジョン1の) Oracle Mediator M2は、コンポジット・アプリケーションのリビジョン2から公開されたイベントを取得しません。

42.3.6 SAFを使用するドメイン間でのイベント公開に関する必知事項

SAF (Store-and-Forward)を使用するドメイン間でイベントを公開する際、ローカル・サブスクライバはそのイベントをサブスクライブできません。たとえば、次のサブスクライバがあるとします。

- ローカル・サブスクライバ(イベント・パブリッシャと同じドメインでデプロイ)

- リモート・サブスクライバ(イベント・パブリッシャの外部のドメインにデプロイ)

いずれも、同じイベント(たとえばEという名前)をサブスクライブし、このイベントはSAFトピックをリスニングするよう構成されています。この環境では、リモート・サブスクライバのみがこのイベントをサブスクライブできます。ローカル・サブスクライバはこのイベントをサブスクライブできません。

EDNのJMSトピックは、インポート済SAFトピックとしてではなく、物理JMSトピックとしてプロビジョニングされる必要があります。これは、インポート済SAFトピックに、EDNではネイティブにサポートされていないコンテキスト参照およびセキュリティ・チェックの独自ルールがあるためです。

42.3.6.1 ローカル・サブスクライバの回避策

回避策として、次の手順を実行する必要があります。

1. パブリッシャから特定可能なローカルJMSトピックを作成します。たとえば、イベント・パブリッシャから特定可能なローカル・ドメインAで、標準のOracle WebLogic Server JMSトピック(たとえば、Taという名前)をイベントの公開先、およびこのトピックをリスニングするサブスクライバ(ドメインAのローカル)にプロビジョニングします。

2. リモート・サブスクライバから特定可能なリモート・ドメインBで、ドメインAのトピックTaにマッピングするインポート済SAFトピック(たとえば、safTbという名前)を作成し、リモート・サブスクライバがsafTbをリスニングするようにします。

手順2のかわりに、リモート・サブスクライバがリスニングするドメインBの別のJMSトピック(たとえば、Tbという名前)をプロビジョニングし、ソース・トピックTaと接続先トピックTbをブリッジするJMSブリッジを作成できます。

42.3.7 管理サーバー・アプリケーションでSOAサーバーにイベントを公開できるように外部JNDIプロバイダを構成する方法

この項では、公開側のアプリケーション(ADF EARファイルなど)がSOAサーバーではなく管理サーバーでデプロイされている場合に、外部JNDIプロバイダを構成する方法について説明します。

管理サーバー・アプリケーションでSOAサーバーにイベントを公開できるように外部JNDIプロバイダを構成する手順は、次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

http://host:port/console

2. 「ドメイン構造」セクションで、「サービス」→「外部JNDIプロバイダ」を展開します。

3. 「ロックして編集」をクリックします。

4. 「新規」をクリックします。

5. 「名前」フィールドに名前(SOA_JNDIなど)を入力し、「次」をクリックします。

6. 「AdminServer」チェック・ボックスを選択して、「終了」をクリックします。

7. 「名前」列で、手順5で入力したプロバイダ名をクリックします。

8. 表42-4 に記載されている詳細を入力し、「保存」をクリックします。

表42-4 構成の詳細

フィールド

説明

初期コンテキスト・ファクトリ

weblogic.jndi.WLInitialContextFactoryを入力します。

プロバイダURL

t3://hostname:soa_server_portを入力します。

ユーザー

Oracle WebLogic Serverユーザー名を入力します。

パスワードおよびパスワードの確認

Oracle WebLogic Serverユーザー名のパスワードを入力します。

9. 「リンク」→「新規」をクリックします。

10. 表42-5 に記載されている詳細を入力し、「OK」をクリックします。

表42-5 構成の詳細

フィールド

説明

名前

SOA_EDNDataSourceを入力します。

ローカル名

jdbc/EDNDataSourceを入力します。

リモート名

jdbc/EDNDataSourceを入力します。

11. 「新規」をクリックします。

12. 表42-6 に記載されている詳細を入力し、「OK」をクリックします。

表42-6 構成の詳細

フィールド

説明

名前

SOA_EDNLocalTxDataSourceを入力します。

ローカル名

jdbc/EDNLocalTxDataSourceを入力します。

リモート名

jdbc/EDNLocalTxDataSourceを入力します。

13. 「OK」をクリックします。

14. 「変更のアクティブ化」をクリックします。

15. LinuxのFMW_Home/user_projects/domains/domain_name/bin/setDomainEnv.shファイル(または、Windowsの場合はsetDomainEnv.batファイル)を次のように変更します。

WLS_JDBC_REMOTE_ENABLED="-Dweblogic.jdbc.remoteEnabled=true"

16. サーバーを再起動します。

42.3.8 Oracle WebLogic Server JMSがJMSアダプタと同じローカルJVMで動作しているときのコネクション・ファクトリの構成方法

Oracle WebLogic Server JMSをローカルJVM (JMSアダプタと同じJVM)で実行している場合は、isTransactedコネクタ・ファクトリ・プロパティを正しく構成する必要があります。サーブレット・クライアント(動作するOracle WebLogic Server JMSサーバーとともにローカルにコロケートされる)では、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインして、「デプロイメント」→「JMSAdapter」→「構成」→「アウトバウンド接続プール」の順に選択します。

2. グループおよびインスタンスを開き、「eis/wls/EDNLocalTxDurableTopic」と「eis/wls/EDNLocalTxTopic」の両方を選択します。

3. isTransactedをfalseに設定します。

4. 保存して、SOAサーバーを再起動します。

詳細は、『テクノロジ・アダプタの理解』の同期/非同期リクエスト・リプライ相互作用パターンに関する項を参照してください。

42.4 BPELプロセス・サービス・コンポーネントからのビジネス・イベントのサブスクライブまたは公開

この項では、BPELプロセス・サービス・コンポーネントからビジネス・イベントをサブスクライブまたは公開する方法について説明します。

42.4.1 ビジネス・イベントをサブスクライブする方法

ビジネス・イベントをサブスクライブするには:

1. 「コンポーネント」ウィンドウからに、BPELプロセス・サービス・コンポーネントをドラッグします。

2. 「名前」フィールドに、名前を入力します。他のデフォルトの選択は変更せずに、「OK」をクリックします。

BPELプロセス・サービス・コンポーネントが作成されます。

3. BPELプロセス・サービス・コンポーネントをダブルクリックします。Oracle BPELデザイナが開きます。または、BPELプロセス・サービス・コンポーネントを右クリックして「編集」をクリックすることもできます。

4. 「コンポーネント」ウィンドウからSOAコンポジット・エディタのreceiveInputアクティビティの下に、receiveアクティビティをドラッグします。

注意:

pickアクティビティのonMessageブランチは、EDNからイベントを受信するように設定することもできます。onMessageブランチの詳細は、「pickアクティビティのプロセスの待機または継続の選択」を参照してください。

5. receiveアクティビティをダブルクリックします。「Receive」ダイアログが開きます。または、receiveアクティビティを右クリックして「編集」をクリックすることもできます。

6. 「名前」フィールドに、名前を入力します。

7. 「相互作用タイプ」リストから「イベント」を選択します。「Receive」ダイアログのレイアウトが変更されます。

8. 「イベント」フィールドの右側にある「イベントの参照」アイコンをクリックします。図42-5 に示すように、「サブスクライブ済イベント」ダイアログが表示されます。

図42-5 「サブスクライブ済イベント」ダイアログ

9. 「追加」アイコンをクリックして、イベントを選択します。

図42-6 に示すように、「イベント・チューザ」ダイアログが表示されます。

図42-6 「イベント・チューザ」ダイアログ

10. 作成したイベントを選択し、「OK」をクリックします。

「サブスクライブ済イベント」ダイアログが再び表示されます。

11. イベントと一貫性がある配信のレベルを選択します。表42-7に詳細を示します。

表42-7 「サブスクライブ済イベント」ダイアログのイベント表

要素

説明

一貫性

「一貫性」列内をクリックし、イベントに対する配信一貫性のレベルを選択します。

- 唯一
イベントは、それ自体のグローバル(つまりJTA)トランザクションのサブスクライバに配信されます。イベント処理が完了すると、そのトランザクション内でサブスクライバが行ったあらゆる変更がコミットされます。サブスクライバが失敗すると、トランザクションはロールバックされます。再試行可能例外で失敗したイベントは、リカバリのために「エラー・ホスピタル」に移動される(手動再試行の対象となる)前に、構成された回数だけ自動的に再試行されます。再試行不能な例外で失敗したイベントは、自動再試行せずに「エラー・ホスピタル」に移動され、リカバリできません。

- 保証付き
ローカルJMSトランザクションでサブスクライバにイベントを配信します。サブスクライバは、処理用にサブスクライバ自体のローカル・トランザクションの作成を選択できますが、他のイベント処理とは個別にコミットされます。「保証付き」一貫性レベルは、ローカル・トランザクションがグローバル・トランザクションのかわりに使用されるため、「唯一」よりも低品質のサービス・オプションです。再試行可能な例外で失敗したイベントは、リカバリ可能な「エラー・ホスピタル」に移動される(手動再試行の対象となる)前に、構成された回数が自動的に再試行されます。再試行不能な例外で失敗したイベントは、自動再試行せずに「エラー・ホスピタル」に移動され、リカバリできません。

「エラー・ホスピタル」の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のエラー・ホスピタルでのフォルトからのリカバリに関する項を参照してください。

恒久

恒久サブスクリプションでは、パブリッシャ、サブスクライバおよびフレームワークのライフ・サイクルの相違によるメッセージ・ロスを防ぎます。次のオプションを選択します。

- はい: サブスクライバが実行中でない場合、イベントが保持されます。これはデフォルト選択です。

- いいえ: サブスクライバが実行中でない場合、イベントが削除されます。

パブリッシャとして実行

セキュリティ公開オプションを選択します。

- はい: サブスクライバにイベント・パブリッシャのセキュリティIDがあります。これはデフォルト選択です。

- いいえ: サブスクライバにイベント・パブリッシャのセキュリティIDがありません。

フィルタ

イベントをフィルタリングするには、選択したイベントの「フィルタ」列をダブルクリックするか、またはイベントを選択して、表の上の「フィルタ」アイコン(最初のアイコン)をクリックします。これにより「式ビルダー」ダイアログが表示されます。このダイアログで、XPathフィルタ式を指定できます。フィルタ式では、サービスの起動前にメッセージのコンテンツ(ペイロードまたはヘッダー)が分析されるように指定します。たとえば、メッセージに顧客IDが含まれている場合のみサービスを起動することを指定するフィルタ式を適用できます。

式のロジックが満たされると、イベントの配信が可能になります。

フィルタの詳細は、「メッセージをフィルタリングする式の指定方法」を参照してください。

12. 「OK」をクリックして、「サブスクライブ済イベント」ダイアログを閉じます。

「Receive」ダイアログが再び表示されます。

注意:

このreceiveアクティビティがBPELプロセス・サービス・コンポーネント・インスタンスを起動する起動receiveアクティビティの場合は、必要に応じて「インスタンスの作成」チェック・ボックスを選択できます。この操作によって、すべての起動に対して新しいBPELプロセス・サービス・コンポーネント・インスタンスを作成できます。

この receive アクティビティが中間プロセスの receive アクティビティで、BPELインスタンスがすでに起動されている場合、この receive アクティビティは、そのBPELインスタンスの実行を続行するために、別のイベントを待機します。

13. 「OK」をクリックします。

図42-7 に、イベント・サブスクリプション用に構成されたBPELプロセス・サービス・コンポーネントを示します。

図42-7 イベント・サブスクリプション用のBPELプロセス・サービス・コンポーネントの構成

42.4.2 ビジネス・イベントを公開する方法

ビジネス・イベントを公開するには:

1. invokeアクティビティを「コンポーネント」ウィンドウから、SOAコンポジット・エディタのreceiveアクティビティ(「ビジネス・イベントをサブスクライブする方法」で作成)の下にドラッグします。

2. invokeアクティビティをダブルクリックします。「Invoke」ダイアログが開きます。または、invokeアクティビティを右クリックして「編集」をクリックすることもできます。

3. 「名前」フィールドに、名前を入力します。

4. 「相互作用タイプ」リストから「イベント」を選択します。「Invoke」ダイアログのレイアウトが変更されます。

5. 「イベント」フィールドの右側にある「イベントの参照」アイコンをクリックします。「イベント・チューザ」ダイアログが表示されます。

6. 作成したイベントを選択し、「OK」をクリックします。

「Invoke」ダイアログが再び表示されます。

7. 「OK」をクリックします。

図42-8 は、イベントのサブスクリプションおよび公開用に構成されたBPELプロセス・サービス・コンポーネントを示します。左側にある丸囲みの青い稲妻は、イベントのサブスクリプションを示します。右側にある丸囲みの黄色い稲妻は、イベントの公開を示します。タイトル内の青い矢印をクリックすると、公開されたイベントのタイトルが表示されます。

図42-8 イベント・サブスクリプションおよび公開用のBPELプロセス・サービス・コンポーネントの構成

42.4.3 ビジネス・イベントのサブスクライブおよび公開時の処理内容

次の例のソース・コードに、BPELプロセス・サービス・コンポーネントのサブスクライブおよび公開するイベントに関するcomposite.xmlソース変更の様子を示します。

<component name="EventBPELProcess">
<implementation.bpel src="EventBPELProcess.bpel"/>
<property name="configuration.monitorLocation" type="xs:string"
many="false">EventBPELProcess.monitor</property>
<business-events>
<subscribe xmlns:sub1="http://mycompany.com/events/orders"
name="sub1:OrderReceivedEvent" consistency="oneAndOnlyOne"
durable="true" runAsRoles="$publisher"/>
<publishes xmlns:pub1="http://mycompany.com/events/orders"
name="pub1:ProductSoldAlert" persistent="true" priority="7"
timeToLive="36000000"/>/>
</business-events>
</component>

<business-events>
<publishes xmlns:sub1="/oracle/fodemo/storefront/entities/events/edl/OrderEO"
name="pub1:NewOrderSubmitted" persistent="true" priority="7"
timeToLive="36000000"/>
</business-events>
</component>

この例では明示的に示されていませんが、イベントにおいてXPathフィルタを定義できます。フィルタは、通常、イベント・サブスクリプションにあります。subscribe要素によって、このサービス・コンポーネントがサブスクライブされる対象のイベントのタイプが制限され、filterセクションによってさらに、コンポーネントが関連する特定のコンテンツにイベントが制限されます。次の例では、初期デポジットが50000を超える場合にのみ、イベントの配信が可能になります。

<business-events>
. . .
. . .
<filter>
<xpath xmlns:be="http://oracle.com/fabric/businessEvent"
xmlns:ns1="http://xmlns.oracle.com/singleString"
<xpath expression= "/be:business-event/be:content/
sub1:AccountInfo/Details[@initialDeposit > 50000]" />
</filter>
. . .
. . .
</business-events>

特別な属性のbpelx:eventNameを使用すると、receive、invoke、onMessageおよびonEvent (BPEL 2.0)などの標準BPELアクティビティが拡張されるため、BPELプロセス・サービス・コンポーネントでEDNイベント・バスからのイベントを受信できます。次の例に、eventName属性のスキーマを示します。

<xs:attribute name="eventName" type="xs:QName">
<xs:annotation>
<xs:appinfo>
<tns:parent>
<bpel11:onMessage/>
<bpel11:receive/>
<bpel11:invoke/>
</tns:parent>
</xs:appinfo>
</xs:annotation>
</xs:attribute>

次の例に、BPELソース・ファイルでのeventName属性の使用方法を示します。

<receive name="OrderPendingEvent" createInstance="yes"
bpelx:eventName="ns1:OrderReceivedEvent"/>
<invoke name="Invoke_1" bpelx:eventName="ns1:ProductSoldAlert"/>

bpelx:eventName属性をreceive、invoke、onMessageまたはonEvent (BPEL 2.0)の各アクティビティで使用した場合、partnerLink、operation、portType属性などの標準属性は存在しません。これは、bpelx:eventName属性の存在が、このアクティビティがEDNイベント・バスからのイベントの受信またはEDNイベント・バスへのイベントの公開のみを対象としていることを表しているためです。

BPELプロセス・サービス・コンポーネントのXSDファイルは若干変更され、partnerLink、operationおよびportType属性は必須ではなくなりました。bpelx:eventName属性、またはpartnerLink、operationおよびportType属性(どちらか一方)の存在については、Oracle JDeveloperで検証ロジックを実施されます。次の例は、BPELのreceiveアクティビティの変更されたスキーマ定義を示しています。

<complexType name="tReceive">
<complexContent>
<extension base="bpws:tExtensibleElements">
<sequence>
<element name="correlations" type="bpws:tCorrelations" minOccurs="0"/>
<group ref="bpws:activity"/>
</sequence>
<!- BPEL mandatory attributes relaxed to optional for supporting BPEL-EDN ->
<attribute name="partnerLink" type="NCName" use="optional"/>
<attribute name="portType" type="QName" use="optional"/>
<attribute name="operation" type="NCName" use="optional"/>
<attribute name="variable" type="NCName" use="optional"/>
</extension>
</complexContent>
</complexType>

invokeおよびonMessageアクティビティのスキーマ定義も同様に変更されています。

42.5 Oracle ADF Business Componentビジネス・イベントをOracle Mediatorに統合する方法

この項では、Oracle ADF Business Componentイベント条件をSOAコンポーネントに統合する方法に関する高レベルな概要が提供されます。SOAコンポーネントには、Oracle Mediatorサービス・コンポーネントとBPELプロセス・サービス・コンポーネントが含まれています。

Oracle ADF Business Componentのビジネス・イベントをSOAコンポーネントに統合する手順は、次のとおりです。

1. ビジネス・コンポーネント・プロジェクトを作成します。

2. ビジネス・イベント定義をプロジェクトに追加します。このアクションにより、EDLファイルおよびXSDファイルが生成されます。XSDファイルにはペイロードの定義が含まれます。また、作成時には、Oracle ADF Business Componentによってイベントが発生するように必ず指定します。

Oracle ADF Business Componentのビジネス・イベントの作成および公開の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。

3. SOAコンポジット・アプリケーションを作成し、EDLスキーマ・ファイルとXSDスキーマ・ファイルをSOAプロジェクトのルート・ディレクトリに手動でコピーします。次に例を示します。

JDeveloper/mywork/SOA_application_name/SOA_project_name

4. スキーマ・ファイルを、インポートに基づいて、EDLファイルからの適切な相対位置に格納します。

5. 「ビジネス・イベントをサブスクライブする方法」の説明に従って、Oracle Mediatorサービス・コンポーネントを作成します。

6. 「ビジネス・イベントをサブスクライブする方法」の説明に従って、「イベント・チューザ」ウィンドウでイベントのEDLファイルを選択します。

7. Oracle Mediatorを起動するために、同じSOAコンポジット・アプリケーション内にBPELプロセス・サービス・コンポーネントを作成します。手順2で作成したBusiness Componentビジネス・イベントXSDのペイロードを選択していることを確認します。

8. BPELプロセス・サービス・コンポーネントをダブルクリックします。

9. emailアクティビティをBPELプロセス・サービス・コンポーネントにドラッグします。

10. ビジネス・イベントXSDのペイロードを参照して、「件名」フィールドおよび「本文」フィールドに入力します。

11. のOracle Mediatorサービス・コンポーネントに戻ります。

12. BPELプロセス・サービス・コンポーネントまたは2番目のOracle Mediatorサービス・コンポーネントのように、イベントを公開する2番目のサービス・コンポーネントを設計します。

これで、SOAコンポジット・アプリケーションの設計は完了です。

43 相互参照の使用

この章では、Oracle SOA Suiteの相互参照機能を使用して、別のアプリケーションで作成された同等のエンティティの識別子を関連付ける方法を説明します。これには相互参照表のエントリの移入、表示および保守に使用できるXRef関数が含まれます。

この章の内容は次のとおりです。

- 相互参照の概要

- 相互参照表の概要

- 相互参照表の作成および変更

- 相互参照表への移入に関する項

- 相互参照表のルックアップに関する項

- 相互参照表値の削除に関する項

- 相互参照ユースケースの作成および実行

- 1M関数の相互参照の作成および実行

43.1 相互参照の概要

相互参照を使用すると、別のアプリケーションで作成された同等のエンティティの値を動的にマップできます。

注意:

相互参照機能ではアプリケーション間の値を動的に統合できるのに対し、ドメイン値マップでは設計時に値を指定して実行時に値を編集できます。ドメイン値マップの詳細は、「ドメイン値マップの使用」および「ドメイン値マップでのOracle SOAコンポーザの使用」を参照してください。

あるアプリケーションでオブジェクトを作成または更新した場合は、その変更内容を別のアプリケーションにも伝播させる必要があります。たとえば、SAPアプリケーションで新規顧客が作成された場合、同じ顧客に関するエントリをOracle E-Business Suiteアプリケーション(EBS)でも作成する場合があります。ただし、統合対象の各アプリケーションでは、同じ情報の表現に異なるエンティティを使用している可能性があります。たとえば、SAPアプリケーションでの新規顧客の場合、CustomerデータベースにはSAP_001などの一意IDとともに新規の1行が挿入されます。この情報がOracle E-Business SuiteアプリケーションとSiebelアプリケーションに伝播するときには、EBS_1001やSBL001などの異なるIDとともに新規の1行が挿入される必要があります。このような場合、異なるアプリケーションで同一エンティティを参照するIDとして解釈できるように、各IDを相互にマップするなんらかの機能が必要になります。相互参照を使用すると、このマッピングを実行できます。

43.2 相互参照表の概要

相互参照は表形式で保存されます。表43-1 に、様々なアプリケーションの顧客IDに関する情報を含む相互参照表を示します。

表43-1 相互参照表サンプル

SAP

EBS

SBL

SAP_001

EBS_1001

SBL001

SAP_002

EBS_1002

SBL002

あるアプリケーションで顧客情報が更新され、変更内容を他のアプリケーションに伝播させる必要がある場合にも、IDマッピングが必要になります。異なるIDを統合するには、相互参照表の全IDにマップする共通値統合パターンを使用する方法があります。たとえば、表43-1 の相互参照表に、さらにCommonという1列を追加できます。その後、更新された相互参照表は、表43-2 のように表示されます。

表43-2 Common列が追加された相互参照表

SAP

EBS

SBL

共通

SAP_001

EBS_1001

SBL001

CM001

SAP_002

EBS_1002

SBL002

CM002

図43-1 に、共通値統合パターンを使用して様々なアプリケーションのIDをマップする方法を示します。

図43-1 共通値統合パターンの例

相互参照表は、メタデータと実際のデータという2つの部分で構成されています。メタデータはOracle JDeveloperで作成された.xrefファイルとして保存され、XMLファイルとしてメタデータ・サービス(MDS)リポジトリに格納されています。実際のデータは、デフォルトでSOAインフラストラクチャ・データベース・スキーマにあるデータベースのXREF_DATA表に格納されます。相互参照エンティティごとにカスタム・データベース表を生成することもできます。データベース表は、相互参照エンティティのメタデータによって異なります。

次の2つの相互参照エンティティを考えてみます。

- SIEBEL、COMMONおよびEBSの相互参照列があるORDER(表43-3 を参照)

- EBS、COMMONおよびPORTALの相互参照列があるCUSTOMER (表43-4 を参照)

表43-3 ORDER表

列名

SIEBEL

COMMON

EBS

Column Value

SBL_101

COM_100

EBS_002

Column Value

COM_110

EBS_012

表43-4 CUSTOMER表

列名

EBS

COMMON

PORTAL

Column Value

EBS_201

COM_200

P2002

1つの汎用表にすべてのランタイム・データを保存するように選択すると、表43-5 に示すように、データはXREF_DATAコード表に保存されます。

表43-5 XREF_DATA表

XREF_TABLE_NAME

XREF_COLUMN_NAME

ROW_NUMBER

VALUE

IS_DELETED

ORDER

SIEBEL

100012345

SBL_101

N

ORDER

COMMON

100012345

COM_100

N

ORDER

EBS

100012345

EBS_002

N

ORDER

COMMON

110012345

COM_110

N

ORDER

EBS

110012345

EBS_012

N

CUSTOMER

EBS

200212345

EBS_201

N

CUSTOMER

COMMON

200212345

COM_200

N

CUSTOMER

PORTAL

200212345

P2002

N

このアプローチには、次のメリットがあります。

- 相互参照エンティティの列を追加、削除および変更するプロセスが単純です。

- アプリケーションに対して相互参照エンティティを作成および削除するプロセスが明快です。

一方、このアプローチには次のデメリットがあります。

- 各相互参照セルはデータベースの異なる行にマップされるため、データベースに多数の行が生成されます。そのため、問合せのパフォーマンスが低下します。

- 汎用表では、XREF_TABLE_NAME列およびXREF_COLUMN_NAME列のデータが多数の行で繰り返されます。

これらの問題を解決するために、相互参照エンティティごとにカスタム・データベース表を生成できます。カスタム・データベース表は、相互参照エンティティのメタデータによって異なります。たとえば、XREF_ORDER表およびXREF_CUSTOMER表には、表43-6 および表43-7 に示すようなカスタム・データベース表を生成できます。

表43-6 XREF_ORDER表

ROW_ID

SIEBEL

COMMON

EBS

100012345

SBL_101

COM_100

EBS_002

110012345

COM_110

EBS_012

表43-7 XREF_CUSTOMER表

ROW_ID

EBS

COMMON

PORTAL

200212345

EBS_201

COM_200

P2002

このアプローチでは、データ定義言語(DDL)スクリプトを実行してカスタム・データベース表を生成する必要があります。カスタム・データベース表の詳細は、「カスタム・データベース表の作成方法」を参照してください。

43.3 相互参照に対するOracle Data Integratorのサポート

Oracle Data Integrator (ODI)はE-LT(抽出、ロード、変換)モデルを使用してデータ統合を実現します。ODIを使用して、相互参照のニーズに役立てることができます。ODIには、次の機能を実行するSOA相互参照を処理するための3つのナレッジ・モジュールが用意されています。相互参照表の移入、ターゲット表の共通IDの作成、相互参照表への共通IDおよびソース主キーのプッシュ、およびソース主キーと共通ID間の相互参照を作成する一意の行番号の作成とプッシュ。モジュールを使用して、複数のソース表からターゲット表へのロードと、ソースの1つとターゲットとの間の相互参照の処理の両方を行う統合インタフェースを作成できます。

ODIおよび相互参照の詳細は、『Oracle Fusion Middleware Oracle Data Integrator接続およびナレッジ・モジュール・ガイド』のOracle SOA Suiteの相互参照に関する項を参照してください。

43.4 相互参照表の作成および変更

相互参照表はSOAコンポジット・アプリケーションで作成し、トランスフォーメーション中にBPELプロセス・サービス・コンポーネントまたはOracle Mediatorサービス・コンポーネントで使用できます。

注意:

また、Service Busプロジェクトに相互参照表を作成し、トランスフォーメーション中にそれをメッセージ・フローで使用できます。

43.4.1 相互参照メタデータの作成方法

相互参照メタデータを作成する手順は、次のとおりです。

1. Oracle JDeveloperで、相互参照を作成するSOAプロジェクトを選択します。

2. プロジェクトを右クリックし、「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

3. 「カテゴリ」セクションから「SOA層」を選択し、次に「トランスフォーメーション」を選択します。

4. 「項目」セクションから、「相互参照(XREF)」を選択します。

5. 「OK」をクリックします。

「相互参照(XREF)の作成」ダイアログが表示されます。

6. 「ファイル名」フィールドに、相互参照ファイルの名前を指定します。たとえば、Customerを指定します。

相互参照名は相互参照表を一意に識別するために使用します。相互参照リポジトリで2つの相互参照表に同じ名前を指定することはできません。相互参照ファイル名は、相互参照表の名前に拡張子.xrefが付いたものとなります。

7. 「説明」フィールドに、相互参照の説明を入力します。次に例を示します。

Cross reference of Customer identifiers.

8. 「エンド・システム」フィールドで、エンド・システム名を入力します。

エンド・システムを相互参照表の相互参照列にマップします。たとえば、最初のエンド・システム名をSAP、2番目のエンド・システム名をEBSに変更できます。各エンド・システム名は相互参照内で一意であることが必要です。

「相互参照(XREF)の作成」ダイアログのサンプルは、図43-2 に表示されています。

図43-2 「相互参照(XREF)の作成」ダイアログ

9. 「OK」をクリックします。

図43-3 に示すように、相互参照エディタが表示されます。このエディタを使用して相互参照を変更できます。

図43-3 相互参照エディタ

43.4.2 相互参照作成時の処理内容

拡張子.xrefの付いたファイルが作成され、「アプリケーション」ウィンドウに表示されます。すべての.xrefファイルは、次の例に示すスキーマ定義(XSD)ファイルに基づいています。

<?xml version="1.0" encoding="UTF-8" ?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xmlns.oracle.com/xref"
xmlns:tns="http://xmlns.oracle.com/xref" elementFormDefault="qualified">
<element name="xref" type="tns:xrefType"/>
<complexType name="xrefType">
<sequence>
<element name="table">
<complexType>
<sequence>
<element name="description" type="string" minOccurs="0"
maxOccurs="1"/>
<element name="columns" type="tns:columnsType" minOccurs="0"
maxOccurs="1"/>
<element name="rows" type="tns:rowsType" maxOccurs="1"
minOccurs="0"/>
</sequence>
<attribute name="name" type="string" use="required"/>
</complexType>
</element>
</sequence>
</complexType>

<complexType name="columnsType">
<sequence>
<element name="column" minOccurs="1" maxOccurs="unbounded">
<complexType>
<attribute name="name" type="string" use="required"/>
</complexType>
</element>
</sequence>
</complexType>

<complexType name="rowsType">
<sequence>
<element name="row" minOccurs="1" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="cell" minOccurs="1" maxOccurs="unbounded">
<complexType>
<attribute name="colName" type="string" use="required"/>
</complexType>
</element>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</schema>

43.4.3 カスタム・データベース表の作成方法

前述されているように、すべてのランタイム・データはデフォルトでXREF_DATA表に格納されます。カスタム・データベース表を作成する場合は、次の手順を実行します。

カスタム・データベース表を作成する手順は、次のとおりです。

1. 相互参照エディタの「最適化」リストで「はい」を選択します。

図43-4 に示すように、生成されるカスタム・データベース表の名前が「表名」フィールドに表示されます。

図43-4 カスタム・データベース表の生成

「表名」フィールドは編集可能で、カスタム表の名前を変更できます。カスタム・データベース表の名前には、xref_の接頭辞を付けてください。表名にxref_接頭辞を付けないと、表を生成する際に次のエラー・メッセージが表示されます。

Table name should begin with 'xref_' and cannot be 'xref_data' or
'xref_deleted_data' which are reserved table names for XREF runtime.

2. 「表DDLの生成」をクリックします。「XREFの最適化」ダイアログが表示されます。

3. 同じ名前の表がすでに存在している場合、その表と関連する索引を削除するには、「削除DDLの生成」チェック・ボックスを選択します。このオプションを選択して「実行」をクリックすると、「削除DDLの実行の警告」ダイアログに、次のメッセージが表示されます。

Running the Drop DDL will remove the table and indexes, do you want to
continue?

4. 「実行」をクリックします。「表DDLの実行」ダイアログが表示されます。

5. 「接続」リストから、使用するデータベース接続を選択します。

使用可能な接続がない場合は、「新規データベース接続を作成します。」をクリックし、図43-5 に示すように、「データベース接続の作成」ダイアログを開きます。既存の接続を編集する場合は、その接続を選択して「選択したデータベース接続の編集」をクリックし、「データベース接続の編集」ダイアログを開きます。

図43-5 「データベース接続の作成」ダイアログ

6. 必要な詳細をすべて入力し、「OK」をクリックします。「表DDLの実行」ダイアログの「接続」リストに値が移入されます。

注意:

データベース表は、データベースのsoainfraスキーマに作成します。

7. 「表DDLの実行」ダイアログで「OK」をクリックし、DDLスクリプトを実行します。

「表DDL実行結果」ダイアログに、DDLスクリプトの実行ステータスが表示されます。

カスタム・データベース表では、modeおよびdbtableの2つの追加の属性が、「相互参照作成時の処理内容」に記載されているスキーマ定義に追加されます。これらの属性は、次のように記述されてtable要素に追加されます。

<attribute name="mode" type="string" default="generic" />
<attribute name="dbtable" type="string" default="xref_data"/>

43.4.4 相互参照表へのエンド・システムの追加方法

相互参照表にエンド・システムを追加する手順は、次のとおりです。

1. 「追加」をクリックします。

新しい行が追加されます。

2. 新しく追加した行をダブルクリックします。

3. エンド・システム名を入力します。たとえば、SBLと入力します。

43.5 相互参照表の移入

Oracle JDeveloperのSOAコンポジット・アプリケーションで相互参照表を作成し、これを使用して実行時に列の値を参照できます。ただし、相互参照を使用して特定の値を参照するには、実行時に相互参照を移入する必要があります。相互参照表は、相互参照XPath関数を使用して移入できます。XPath関数を使用すると、相互参照列の移入、参照の実行および列の値の削除ができます。これらのXPath関数を「式ビルダー」ダイアログで使用して式を作成するか、またはXSLTマッパーで使用してトランスフォーメーションを作成できます。たとえば、xref:populateXRefRow関数を使用して1つの値を相互参照列に移入するか、またはxref:populateXRefRow1M関数を使用して複数の値を相互参照列に移入できます。

「式ビルダー」ダイアログには、BPELプロセス・サービス・コンポーネントまたはOracle Mediatorサービス・コンポーネントのassignアクティビティ、XSLトランスフォーメーションまたはフィルタ機能からアクセスできます。図43-6 に、「式ビルダー」ダイアログで相互参照関数を選択する様子を示します。

図43-6 「式ビルダー」ダイアログに相互参照関数が表示されている状態

XSLTマッパーは、XSLファイルを作成してXMLスキーマ間でデータを変換するときに表示されます。図43-7 に、XSLTマッパーで相互参照関数を選択する様子を示します。

図43-7 XSLTマッパー・ダイアログに相互参照関数が表示されている状態

相互参照表を使用するには、実行時に相互参照表を移入する必要があります。データは、デフォルトでSOAインフラストラクチャ・データベース・スキーマにあるXREF_DATA表に格納されます。xref:populateXRefRow関数を使用して1つの値を相互参照列に移入するか、またはxref:populateXRefRow1M関数を使用して複数の値を相互参照列に移入できます。

注意:

次の方法でデータ・ソースを構成することで、データを異なるデータベース・スキーマに格納することもできます。

- データ・ソースのJNDI名をjdbc/xrefと指定します。

- ORACLE_HOME/rcu/integration/soainfra/sql/xref/createschema_xref_oracle.sqlファイルをロードして、このデータ・ソースのXREF_DATA表を作成します。

43.5.1 xref:populateXRefRow関数

xref:populateXRefRow関数では、1つの値が相互参照列に移入されます。このxref:populateXRefRow関数では、移入対象の相互参照値である文字列値が返されます。たとえば、表43-8 に示すOrder表には、EBS、CommonおよびSBLという列があり、各列の値はそれぞれE100、100およびSBL_001です。

表43-8 列に1つの値がある相互参照表

EBS

共通

SBL

E100

100

SBL_001

注意:

この関数の使用時に同時性の問題がある場合は、populateLookupXRefRow関数を使用することもできます。populateLookupXRefRow関数は、同時更新が行われ、一意制約の違反が発生する場合にのみ使用する必要があります。この関数については、「xref:populateLookupXRefRow関数」で説明しています。

次の例は、xref:populateXRefRow関数の構文を示しています。

xref:populateXRefRow(xrefLocation as string, xrefReferenceColumnName as string,
xrefReferenceValue as string, xrefColumnName as string, xrefValue as string, mode
as string) as string

パラメータ

- xrefLocation: 相互参照表URI。

- xrefReferenceColumnName: 参照列の名前。

- xrefReferenceValue: 参照列名に対応する値。

- xrefColumnName: 移入される列の名前。

- xrefValue: 列に移入される値。

- mode: xref:populateXRefRow関数の列移入モード。値ADD、LINKまたはUPDATEを指定できます。表43-9 に、これらのモードを示します。

表43-9 xref:populateXRefRow関数のモード

モード

説明

例外の原因

ADD

参照値と追加対象の値を追加します。

たとえば、次のモードを考えてみます。

xref:populateXRefRow("customers.xref"
,"EBS","EBS100", "Common","CM001",
"ADD")

この場合、ESB参照列に参照値EBS100が、Common列に値CM001が追加されます。

次の理由により、例外が発生する可能性があります。

- 指定の相互参照表が見つからない場合。

- 指定の列が見つからない場合。

- 提供された値が空の場合。

- 追加される値が、対象表の対象列で一意でない場合。

- 対象行の列に値が含まれている場合。

- 参照値が存在する場合。

LINK

既存の参照値に対応する相互参照値を追加します。

たとえば、次のモードを考えてみます。

xref:populateXRefRow("customers.xref"
,"Common","CM001","SBL","SBL_
001","LINK")

この場合、Common列の値CM001が、SBL列の値SBL_001にリンクされます。

次の理由により、例外が発生する可能性があります。

- 指定の相互参照表が見つからない場合。

- 指定の列が見つからない場合。

- 提供された値が空の場合。

- 参照値が見つからない場合。

- リンク対象の値が対象表の対象列に存在する場合。

UPDATE

既存の参照列と値のペアに対応する相互参照値を更新します。

たとえば、次のモードを考えてみます。

xref:populateXRefRow("customers.xref"
,"SBL","SBL_001", "SBL","SBL_
1001","UPDATE")

この場合、SBL列の値SBL_001が値SBL_1001に更新されます。

次の理由により、例外が発生する可能性があります。

- 指定の相互参照表が見つからない場合。

- 指定の列が見つからない場合。

- 提供された値が空の場合。

- 更新対象の列に複数の値が見つかった場合。

- 参照値が見つからない場合。

- 対象行の列に値がない場合。

注意:

modeパラメータ値には大/小文字区別があり、表43-9 のように大文字のみで指定する必要があります。

表43-10 に、xref:populateXRefRow関数のモードと各モードの例外条件を示します。

表43-10 xref:populateXRefRow関数のモードと結果

モード

参照値

追加される値

結果

ADD

Absent

Present

Present

Absent

Absent

Present

正常終了

例外

例外

LINK

Absent

Present

Present

Absent

Absent

Present

例外

正常終了

例外

UPDATE

Absent

Present

Present

Absent

Absent

Present

例外

例外

正常終了

43.5.2 xref:populateLookupXRefRow関数

xref:populateXRefRow関数と同様に、xref:populateLookupXRefRow関数では相互参照列に単一の値が移入されます。xref:populateXRefRow関数とは異なり、xref:populateLookupXRefRow関数では、同じIDのレコードが同時に追加されたときに一意制約の違反エラーはスローされません。かわりに、ルックアップとして動作してエラーの原因となった既存のソース値を返し、処理フローを停止しません。xref:populateXRefRow関数の使用時に発生する可能性がある同時性の問題を解決するには、この関数を使用します。

xref:populateLookupXRefRow関数は文字列値を返します。この文字列値は、移入される相互参照値か、または一意制約の違反がある場合は、最初にコミットされたスレッドによってすでに移入されている相互参照値になります。たとえば、表43-8 に示すXREF_CUSTOMER_DATA表には、EBS、CommonおよびSBLという列があります。xref:populateLookupXRefRow関数は、2つのスレッドによって、次の値を使用して並行して起動されます。

- スレッド1: xref: populateLookupXRefRow ("default/xref/example.xref", "EBS", "EBS100", "Common" "CM001", "ADD")

- スレッド2: xref: populateLookupXRefRow ("default/xref/example.xref", "EBS", "EBS100", "Common" "CM002", "ADD")

表43-11 に示すように表に移入されます。スレッド1が最初にコミットされるため、スレッド2はコール元に「CM001」を返します。

表43-11 xref:populateLookupXRefRowによって移入される相互参照表

EBS

共通

SBL

EBS100

CM001

次の例は、xref:populateLookupXRefRow関数の構文を示しています。

xref:populateLookupXRefRow(xrefMetadataURI as string, xrefReferenceColumnName as
string, xrefReferenceValue as string, xrefColumnName as string, xrefValue as
string, mode as string) as string

パラメータ

- xrefMetadataURI: 相互参照表URI。

- xrefReferenceColumnName: 参照列の名前。

- xrefReferenceValue: 参照列名に対応する値。

- xrefColumnName: 移入される列の名前。

- xrefValue: 列に移入される値。

- mode: xref:populateXRefRow関数の列移入モード。ADDまたはLINKを指定できます。表43-10 に、これらのモードと各モードの例外条件を示します。

注意:

modeパラメータ値には大/小文字区別があり、大文字のみで指定する必要があります。

表43-12 xref:populateLookupXRefRow関数のモードと結果

モード

参照値

追加される値

結果

ADD

Absent

Present

Present

Absent

Absent

Present

正常終了

例外(例外が一意制約違反の場合にのみ成功)

例外(例外が一意制約違反の場合にのみ成功)

LINK

Absent

Present

Present

Absent

Absent

Present

例外

正常終了

例外

使用上の注意

- カスタム表の方法を使用する場合は、相互参照表で一意であることが必要な列に対して、主制約を追加する必要があります。表43-11 を例として使用すると、SQL文は次のようになります。

alter table xref_customer_data add constraint xref_vnx_data_pk
primary key (common, ebs);

最初に主制約列に移入してから、後続のコールで残りの列に移入します。

- データの非一貫性の問題が隠される可能性があるため、プライマリ・オブジェクトの相互参照を追加するためにこの関数を使用しないでください。主要な依存オブジェクトに対するセカンダリ・オブジェクトにのみこの関数を使用します。たとえば、顧客アカウントを作成する際にアカウントがすでに存在するかどうかを確認するためにこの関数を使用しないでください。これらの顧客アカウントの住所が同期されている場合に使用してください。

43.5.3 xref:populateXRefRow1M関数

あるエンド・システム内の2つの値を、別のシステム内の1つの値に対応付けることができます。このようなシナリオでは、xref:populateXRefRow1M関数を使用して相互参照列に値を移入する必要があります。たとえば、表43-13 に示すように、SAP_001およびSAP_0011の値でEBSおよびSBLアプリケーションの1つの値を参照します。SAPなどの列を移入するには、xref:populateXRefRow1M関数を使用できます。

表43-13 列に複数の値がある相互参照表

SAP

EBS

SBL

SAP_001

SAP_0011

EBS_1001

SBL001

SAP_002

EBS_1002

SBL002

次の例は、xref:populateXRefRow1M関数の構文を示しています。

xref:populateXRefRow1M(xrefLocation as string, xrefReferenceColumnName as string,
xrefReferenceValue as string, xrefColumnName as string, xrefValue as string, mode
as string) as string

パラメータ

- xrefLocation: 相互参照URI。

- xrefReferenceColumnName: 参照列の名前。

- xrefReferenceValue: 参照列名に対応する値。

- xrefColumnName: 移入される列の名前。

- xrefValue: 列に移入される値。

- mode: xref:populateXRefRow関数の列移入モード。ADDまたはLINKのいずれかの値を指定できます。表43-14 に、これらのモードを示します。

表43-14 xref:populateXRefRow1M関数のモード

モード

説明

例外の原因

ADD

参照値と追加対象の値を追加します。

たとえば、次のモードを考えてみます。

xref:populateXRefRow1M("customers.xref","
EBS","EBS_1002", "SAP","SAP_0011","ADD")

この場合、EBS参照列に参照値EBS_1002が、SAP列に値SAP_0011が追加されます。

次の理由により、例外が発生する可能性があります。

- 指定の相互参照表が見つからない場合。

- 指定の列が見つからない場合。

- 提供された値が空の場合。

- 追加される値が、対象表の対象列で一意でない場合。

- 参照値が存在する場合。

LINK

既存の参照値に対応する相互参照値を追加します。

たとえば、次のモードを考えてみます。

xref:populateXRefRow1M("customers.xref","
EBS","EBS_1002", "SAP","SAP_002","LINK")

この場合、SAP列の値SAP_002が、EBS列の値EBS_1002にリンクされます。

次の理由により、例外が発生する可能性があります。

- 指定の相互参照表が見つからない場合。

- 指定の列が見つからない場合。

- 提供された値が空の場合。

- 参照値が見つからない場合。

- 追加される値が、対象表の列で一意でない場合。

表43-15 に、xref:populateXRefRow1M関数のモードと各モードの例外条件を示します。

表43-15 xref:populateXRefRow1M関数のモードと結果

モード

参照値

追加される値

結果

ADD

Absent

Present

Present

Absent

Absent

Present

正常終了

例外

例外

LINK

Absent

Present

Present

Absent

Absent

Present

例外

正常終了

例外

43.5.4 相互参照表の列の移入方法

相互参照表に1列を移入する手順は、次のとおりです。

1. XSLTマッパーで、「ソース」および「ターゲット」ペインのツリーを開きます。

2. ソース要素をターゲット要素にドラッグ・アンド・ドロップします。

3. 「コンポーネント」ウィンドウで、「詳細」を選択します。

4. 「XREF関数」を選択します。

5. ソース・オブジェクトをターゲット・オブジェクトに接続している線に、「populateXRefRow」関数をドラッグ・アンド・ドロップします。
接続線上に「populateXRefRow」アイコンが表示されます。

6. 「populateXRefRow」アイコンをダブルクリックします。
図43-8 に示すように、「関数の編集 – populateXRefRow」ダイアログが表示されます。

図43-8 「関数の編集 – populateXRefRow」ダイアログ

7. 「関数の編集 – populateXRefRow」ダイアログの各フィールドで、次の値を指定します。

a. 「xrefLocation」フィールドに、相互参照ファイルのロケーションURIを入力します。
「xrefLocation」フィールドの右側にある「参照」をクリックして、相互参照ファイルを選択します。「リソース・パレット」を使用して、MDSおよびMDSの共有ロケーションからもすでにデプロイした相互参照を選択できます。

b. 「referenceColumnName」フィールドに、相互参照列の名前を入力します。
「referenceColumnName」フィールドの右側にある「参照」をクリックして、以前に選択した相互参照に定義されている列から列名を選択できます。

c. 「referenceValue」フィールドでは、値を手動で入力するか、[Ctrl]キーを押しながら[Space]キーを押してXPathビルディング・アシスタントを起動できます。上へ移動および下へ移動するキーを押して、リスト内のオブジェクトを配置し、[Enter]キーを押してそのオブジェクトを選択します。

d. 「columnName」フィールドに、相互参照列の名前を入力します。
「columnName」フィールドの右側にある「参照」をクリックして、以前に選択した相互参照に定義されている列から列名を選択できます。

e. 「value」フィールドでは、値を手動で入力するか、[Ctrl]キーを押しながら[Space]キーを押してXPathビルディング・アシスタントを起動できます。

f. 「mode」フィールドに、相互参照表の列を移入する際のモードを入力します。たとえば、ADDと入力します。
「参照」をクリックしてモードを選択することもできます。モードを選択できる「移入モードの選択」ダイアログが表示されます。

8. 「OK」をクリックします。
図43-9 に、移入後の「関数の編集 – populateXRefRow」ダイアログを示します。

図43-9 移入後の「関数の編集 – populateXRefRow」ダイアログ

43.6 相互参照表の参照

移入後の相互参照表を使用して、値を参照できます。xref:lookupXRefおよびxref:lookupXRef1M関数を使用すると、1つおよび複数の値の相互参照をそれぞれ参照できます。

43.6.1 xref:lookupXRef関数

xref:lookupXRef関数を使用すると、参照列の値に対応する値を相互参照列で参照できます。たとえば、次の関数では、表43-2 で説明した相互参照表のCommon列で、SAP列のSAP_001値に対応する値を参照します。

xref:lookupXRef("customers.xref","SAP","SAP_001","Common",true())

次の例は、xref:lookupXRef関数の構文を示しています。

xref:lookupXRef(xrefLocation as string, xrefReferenceColumnName as string,
xrefReferenceValue as string, xrefColumnName as string, needAnException as
boolean) as string

パラメータ

- xrefLocation: 相互参照URI。

- xrefReferenceColumnName: 参照列の名前。

- xrefReferenceValue: 参照列名に対応する値。

- xrefColumnName: 値が参照される列の名前。

- needAnException: 値がtrueに設定されると、値が見つからない場合に例外がスローされます。そうでない場合は、空の値が返されます。

例外の原因

実行時に、次の理由で例外が発生することがあります。

- 指定された名前の相互参照表が見つからない。

- 指定された列名が見つからない。

- 指定された参照値が空である。

- 複数の値が見つかった。

43.6.2 xref:lookupXRef1M関数

xref:lookupXRef1M関数を使用すると、参照列の値に対応する複数の値を相互参照列で参照できます。xref:lookupXRef1M関数では、複数のノードを含んだノードセットが返されます。ノードセット内の各ノードに値が含まれています。

たとえば、次の関数では、表43-13 のSAP列で、EBS列のEBS_1001値に対応する複数の値を参照します。

xref:lookupXRef1M("customers.xref","EBS","EBS_1001","SAP",true())

次の例は、xref:lookupXRefRow1M関数の構文を示しています。

xref:lookupXRef1M(xrefLocation as String, xrefReferenceColumnName as String,
xrefReferenceValue as String, xrefColumnName as String, needAnException as
boolean) as node-set

パラメータ

- xrefLocation: 相互参照URI。

- xrefReferenceColumnName: 参照列の名前。

- xrefReferenceValue: 参照列名に対応する値。

- xrefColumnName: 値が参照される列の名前。

- needAnException: 値がtrueに設定されると、参照値が見つからない場合に例外がスローされます。そうでない場合は、空のノードセットが返されます。

xref:lookupXRefRow1M関数の例

表43-16 に示すように、Siebel、Billing1およびBilling2の3つの列があるOrder表について考えてみます。

表43-16 Order表

Siebel

Billing1

Billing2

100

101

102

110

111

112

1対1マッピングの場合、xref:lookupPopulatedColumns("Order","Siebel","100","false")メソッドは、次の例に示す値を返します。

<column name="BILLING1">101</column>
<column name="BILLING2">102</column>

この場合は、Billing1とBilling2の両方の列が移入されます。

1対多マッピングの場合、xref:lookupPopulatedColumns("Order","Siebel","110","false")メソッドは、次の例に示す値を返します。

<column name="BILLING2">111</column>
<column name="BILLING2">112</column>

この場合、Billing1列は移入されません。

例外の原因

次の理由により、例外が発生する可能性があります。

- 指定された名前の相互参照表が見つからない。

- 指定された列名が見つからない。

- 指定された参照値が空である。

43.6.3 xref:lookupPopulatedColumns関数

xref:lookupPopulatedColumns関数を使用すると、特定の相互参照表、相互参照列および値に対して移入されたすべての列を参照できます。xref:lookupPopulatedColumns関数では、各ノードに列名と対応する値が含まれたノードセットが返されます。

次の例は、xref:LookupPopulatedColumns関数の構文を示しています。

xref:LookupPopulatedColumns(xrefTableName as String,xrefColumnName as
String,xrefValue as String,needAnException as boolean)as node-set

パラメータ

- xrefTableName: 参照表の名前。

- xrefColumnName: 参照列の名前。

- xrefValue: 参照列名に対応する値。

- needAnException: 値がtrueに設定されると、参照列に値が見つからない場合に例外がスローされます。そうでない場合は、空のノードセットが返されます。

例外の原因

次の理由により、例外が発生する可能性があります。

- 指定された名前の相互参照表が見つからない。

- 指定された列名が見つからない。

- 指定された参照値が空である。

43.6.4 相互参照表の値の参照方法

相互参照表列を参照する手順は、次のとおりです。

1. XSLTマッパーで、「ソース」および「ターゲット」ペインのツリーを開きます。

2. ソース要素をターゲット要素にドラッグ・アンド・ドロップします。

3. 「コンポーネント」ウィンドウで、「詳細」を選択します。

4. 「XREF関数」を選択します。

5. ソース・オブジェクトをターゲット・オブジェクトに接続している線に、「lookupXRef」関数をドラッグ・アンド・ドロップします。
接続線上に「lookupXRef」アイコンが表示されます。

6. 「lookupXRef」アイコンをダブルクリックします。
図43-10 に示すように、「関数の編集 – lookupXRef」ダイアログが表示されます。

図43-10 「関数の編集 – lookupXRef」ダイアログ

7. 「関数の編集 – lookupXRef」ダイアログのフィールドで、次の値を指定します。

a. 「xrefLocation」フィールドに、相互参照ファイルのロケーションURIを入力します。
「xrefLocation」フィールドの右側にある「参照」をクリックして、相互参照ファイルを選択します。「リソース・パレット」を使用して、MDSおよびMDSの共有ロケーションからもすでにデプロイされた相互参照を選択できます。

b. 「referenceColumnName」フィールドに、相互参照列の名前を入力します。
「referenceColumnName」フィールドの右側にある「参照」をクリックして、以前に選択した相互参照に定義されている列から列名を選択できます。

c. 「referenceValue」フィールドでは、値を手動で入力するか、[Ctrl]キーを押しながら[Space]キーを押してXPathビルディング・アシスタントを使用できます。上へ移動および下へ移動するキーを押して、リスト内のオブジェクトを配置し、[Enter]キーを押してそのオブジェクトを選択します。

d. 「columnName」フィールドに、相互参照列の名前を入力します。
「columnName」フィールドの右側にある「参照」をクリックして、以前に選択した相互参照に定義されている列から列名を選択できます。

e. 「needException」フィールドの右側にある「参照」をクリックします。「例外が必要」ダイアログが表示されます。値が見つからない場合に例外が発生するように指定するには、「はい」を選択します。それ以外の場合は「いいえ」を選択します。

8. 「OK」をクリックします。
図43-11 に、移入後の「関数の編集 – lookupXRef」ダイアログを示します。

図43-11 移入後の「関数の編集 – lookupXRef」ダイアログ

43.7 相互参照表の値の削除

xref:markForDelete関数を使用すると、相互参照表の値を削除できます。関数に渡された列値を含む行は、XREF_DATA表から削除され、XREF_DELETED_DATA表に移動されます。削除に成功すると、trueを返します。それ以外は、falseを返します。

相互参照表行には最低2つのマッピングが必要です。1行に存在するマッピングが2つのみの場合、一方の値に削除マークを付けると、他方の列の値も削除されます。

次の例は、xref:markForDelete関数の構文を示しています。

xref:markForDelete(xrefTableName as string, xrefColumnName as string,
xrefValueToDelete as string) return as boolean

パラメータ

- xrefTableName: 相互参照表の名前。

- xrefColumnName: 削除対象の値を含む列の名前。

- xrefValueToDelete: 削除する値。

例外の原因

次の理由により、例外が発生する可能性があります。

- 指定された名前の相互参照表が見つからない。

- 指定した列名が見つからない場合。

- 指定した値が空の場合。

- 指定した値が列内で見つからない場合。

- 複数の値が見つかった。

43.7.1 相互参照表の値の削除方法

相互参照表の値を削除する手順は、次のとおりです。

1. XSLTマッパーで、「ソース」および「ターゲット」ペインのツリーを開きます。

2. ソース要素をターゲット要素にドラッグ・アンド・ドロップします。

3. 「コンポーネント」ウィンドウで、「詳細」を選択します。

4. 「XREF関数」を選択します。

5. ソース・オブジェクトをターゲット・オブジェクトに接続している線に、「markForDelete」関数をドラッグ・アンド・ドロップします。
接続線上に「markForDelete」アイコンが表示されます。

6. 「markForDelete」アイコンをダブルクリックします。
図43-12 に示すように、「関数の編集 – markForDelete」ダイアログが表示されます。

図43-12 「関数の編集 – markForDelete」ダイアログ

7. 「関数の編集 – markForDelete」ダイアログの各フィールドで次の値を指定します。

a. 「xrefLocation」フィールドに、相互参照ファイルのロケーションURIを入力します。
「xrefLocation」フィールドの右側にある「検索」アイコンをクリックして、相互参照ファイルを選択します。「リソース・パレット」を使用して、MDSおよびMDSの共有ロケーションからもすでにデプロイされた相互参照を選択できます。

b. 「columnName」フィールドに、相互参照表列の名前を入力します。
「columnName」フィールドの右側にある「検索」アイコンをクリックして、以前に選択した相互参照に定義されている列から列名を選択できます。

c. 「value」フィールドは、値を手動で入力するか、[Ctrl]キーを押しながら[Space]キーを押してXPathビルディング・アシスタントを起動します。上へ移動および下へ移動するキーを押して、リスト内のオブジェクトを配置し、[Enter]キーを押してそのオブジェクトを選択します。

図43-13 に、移入後の「関数の編集 – markForDelete」ダイアログを示します。

図43-13 移入後の「関数の編集 – markForDelete」ダイアログ

8. 「OK」をクリックします。

43.8 相互参照ユースケースの作成および実行

この相互参照ユースケースは、Oracle EBS、SAPおよびSiebelインスタンス間の統合シナリオを実装します。このユースケースでは、SAP_01表で挿入、更新または削除操作を実行すると、EBSおよびSBL表で対応するデータが挿入または更新されます。図43-14 に、このユースケースの概要を示します。

図43-14 のXrefCustAppユースケース

この項で説明するサンプル・ファイルをダウンロードするには、Oracle SOA Suiteサンプル・ページを参照してください。

43.8.1 ユース-ケースの作成方法

この項では、SOAコンポジット・アプリケーションを作成、構築およびデプロイするための設計時タスクを説明します。これらのタスクは、表示されている順番で実行する必要があります。

43.8.1.1 タスク1: Oracle Databaseおよびデータベース・アダプタの構成方法

Oracle Databaseおよびデータベース・アダプタを構成する手順は、次のとおりです。

1. このユースケースには、SCOTTデータベース・アカウントとパスワードTIGERが必要です。SCOTTアカウントのロックが解除されている必要があります。

SYSDBAでログインしてから、XrefOrderApp1M/sqlディレクトリにあるsetup_user.sqlスクリプトを実行してアカウントのロックを解除できます。

2. XrefOrderApp1M/sqlディレクトリにあるcreate_schema.sqlスクリプトを実行して、このユースケースに必要な表を作成します。

3. XrefOrderApp1M/sqlディレクトリにあるcreate_app_procedure.sqlスクリプトを実行して、この統合に組み込む様々なアプリケーションをシミュレートするプロシージャを作成します。

4. OH/rcu/integration/soainfra/sql/xref/ディレクトリにあるcreateschema_xref_oracle.sqlスクリプトを実行し、ランタイムの相互参照データを格納する相互参照表を作成します。

5. ra.xmlファイルとweblogic-ra.xmlファイルを、$BEAHOME/META-INFから、使用しているコンピュータで新規作成したMETA-INFディレクトリにコピーします。

6. 次のとおり、$BEAHOME/META-INFディレクトリにあるweblogic-ra.xmlファイルを編集します。

- 次のように、プロパティをxADataSourceNameに変更します。

<property>
<name>xADataSourceName</name>
<value>jdbc/DBConnection1</value>
</property>

- jndi-nameを次のように変更します。

<jndi-name> eis/DB/DBConnection1</jndi-name>

このサンプルではeis/DB/DBConnection1を使用して新規メッセージのSAP表をポーリングし、Oracle EBSおよびSiebelインスタンスをシミュレートするプロシージャに接続します。

7. ra.xmlファイルとweblogic-ra.xmlファイルをRARファイルとしてパッケージ化し、Oracle WebLogic Server管理コンソールを使用してそのRARファイルをデプロイします。

8. Oracle WebLogic Server管理コンソールを使用して、次の値を持つデータ・ソースを作成します。

- jndi-name=jdbc/DBConnection1

- user=scott

- password=tiger

- url=jdbc:oracle:thin:@host:port:service

- connection-factory factory-class=oracle.jdbc.pool.OracleDataSource

9. Oracle WebLogic Server管理コンソールを使用して、次の値を持つデータ・ソースを作成します。

- jndi-name=jdbc/xref

- user=scott

- password=tiger

- url=jdbc:oracle:thin:@host:port:service

- connection-factory factory-class=oracle.jdbc.pool.OracleDataSource

43.8.1.2 タスク2: Oracle JDeveloperのアプリケーションおよびプロジェクトの作成方法

Oracle JDeveloperのアプリケーションおよびプロジェクトを作成する手順は、次のとおりです。

1. Oracle JDeveloperで「ファイル」をクリックし、「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「新規ギャラリ」で「一般」ノードを開き、「アプリケーション」カテゴリを選択します。

3. 「項目」リストで「SOAアプリケーション」を選択し、「OK」をクリックします。

SOAアプリケーションの作成ウィザードが表示されます。

4. 「アプリケーション名」フィールドでXrefCustAppと入力し、「次へ」をクリックします。

「SOAプロジェクトの名前付け」ページが表示されます。

5. 「プロジェクト名」フィールドにXrefCustAppと入力し、「次へ」をクリックします。

「SOA設定の構成」ページが表示されます。

6. 「コンポジット・テンプレート」リストから「空のコンポジット」を選択し、「終了」をクリックします。

Oracle JDeveloperの「アプリケーション」ウィンドウは新しいアプリケーションおよびプロジェクトで更新され、「SOAコンポジット・エディタ」には空白のコンポジットが含まれています。

7. 「ファイル」メニューから「すべて保存」を選択します。

43.8.1.3 タスク3: 相互参照の作成方法

ユースケース用のアプリケーションおよびプロジェクトを作成した後は、相互参照表を作成する必要があります。

相互参照表を作成する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「XrefCustApp」プロジェクトを右クリックして「新規」を選択します。

2. 「新規ギャラリ」ダイアログで「SOA層」ノードを開き、「トランスフォーメーション」カテゴリを選択します。

3. 「項目」リストで「相互参照(XREF)」を選択し、「OK」をクリックします。

「相互参照(XREF)の作成」ダイアログが表示されます。

4. 「ファイル名」フィールドで、customer.xrefと入力します。

5. 「エンド・システム」フィールドで、SAP_01およびEBS_i76と入力します。

6. 「OK」をクリックします。

相互参照エディタが表示されます。

7. 「追加」をクリックします。

新しい行が追加されます。

8. 新しく追加された行にエンド・システム名としてSBL_78を入力します。

9. 「追加」をクリックし、エンド・システム名としてCommonを入力します。

図43-15 に示すように、相互参照エディタが表示されます。

図43-15 顧客の相互参照

10. 「ファイル」メニューから、「すべて保存」を選択して、相互参照エディタを閉じます。

43.8.1.4 タスク4: データベース・アダプタ・サービスの作成方法

データベース・アダプタ・サービスを作成する手順は、次のとおりです。

1. Oracle JDeveloperの「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「データベース」を選択し、「公開されたサービス」スイムレーンにドラッグします。

アダプタ構成ウィザードの「ようこそ」ページが表示されます。

3. 「次へ」をクリックします。

「サービス名」ページが表示されます。

4. 「サービス名」フィールドに、SAPと入力します。

5. 「次へ」をクリックします。

「サービス接続」ページが表示されます。

6. 「アプリケーション接続」フィールドで、「DBConnection1」を選択します。

7. 「JNDI名」フィールドに、eis/DB/DBConnection1と入力します。

8. 「次へ」をクリックします。

「操作タイプ」ページが表示されます。

9. 「表の新規レコードまたは更新されたレコードをポーリング」を選択し、「次へ」をクリックします。

「表の選択」ページが表示されます。

10. 「表のインポート」をクリックします。

「表のインポート」ダイアログが表示されます。

11. 「スキーマ」から「Scott」を選択します。

12. 「名前フィルタ」フィールドで%SAP%と入力し、「問合せ」をクリックします。

「選択可能」フィールドにSAP_01表名が移入されます。

13. 「SAP_01」をダブルクリックします。

「選択済」フィールドに「SAP_01」が移入されます。

14. 「OK」をクリックします。

ここで「表の選択」ページに「SAP_01」表が含まれます。

15. 「SAP_01」を選択し、「次へ」をクリックします。

「主キーの定義」ページが表示されます。

16. 「ID」を主キーとして選択し、「次へ」をクリックします。

「リレーションシップ」ページが表示されます。

17. 「次へ」をクリックします。

「属性のフィルタ処理」ページが表示されます。

18. 「次へ」をクリックします。

「読取り後」ページが表示されます。

19. 「[SAP_01]表のフィールドの更新 (論理削除)」を選択し、「次へ」をクリックします。

「論理削除」ページが表示されます。

20. 「論理削除フィールド」フィールドで、「LOGICAL_DEL」を選択します。

21. 「読取り値」フィールドで、Yと入力します。

22. 「未読取り値」フィールドで、Nと入力します。

図43-16 は、アダプタ構成ウィザードの「論理削除」ページを示しています。

図43-16 「論理削除」ページ: アダプタ構成ウィザード

23. 「次へ」をクリックします。

「ポーリング・オプション」ページが表示されます。

24. 「次へ」をクリックします。

「選択条件の定義」ページが表示されます。

25. 「次へ」をクリックします。

「終了」ページが表示されます。

26. 「終了」をクリックします。

図43-17 に示すように、SAPという名前のデータベース・アダプタ・サービスが作成されます。

図43-17 のSAPデータベース・アダプタ・サービス

27. 「ファイル」メニューから「すべて保存」を選択します。

43.8.1.5 タスク5: EBSおよびSBL外部参照の作成方法

EBSおよびSBL外部参照を作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「データベース・アダプタ」を選択し、「外部参照」スイムレーンにドラッグします。

アダプタ構成ウィザードの「ようこそ」ページが表示されます。

3. 「次へ」をクリックします。

「サービス名」ページが表示されます。

4. 「サービス名」フィールドに、EBSと入力します。

5. 「次へ」をクリックします。

「サービス接続」ページが表示されます。

6. 「アプリケーション接続」フィールドで、「DBConnection1」を選択します。

7. 「JNDI名」フィールドに、eis/DB/DBConnection1と入力します。

8. 「次へ」をクリックします。

「操作タイプ」ページが表示されます。

9. 「ストアド・プロシージャまたはファンクションの呼出し」を選択し、「次へ」をクリックします。

「ストアド・プロシージャの指定」ページが表示されます。

10. 「スキーマ」から「Scott」を選択します。

11. 「参照」をクリックします。

「ストアド・プロシージャ」ダイアログが表示されます。

12. 図43-18 に示すように、「POPULATE_APP_INSTANCE」を選択します。

図43-18 「ストアド・プロシージャ」ダイアログ

13. 「OK」をクリックします。

図43-19 に示すように、「ストアド・プロシージャの指定」ページが表示されます。

図43-19 アダプタ構成ウィザードの「ストアド・プロシージャの指定」ページ

14. 「次へ」をクリックします。

「終了」ページが表示されます。

15. 「終了」をクリックします。

図43-20 に、のEBS参照を示します。

図43-20 のEBS参照

16. 「ファイル」メニューから「すべて保存」を選択します。

17. ステップ2からステップ16を繰り返し、SBLという名前の外部参照をもう1つ作成します。

このタスクを完了すると、図43-21 に示すように、が表示されます。

図43-21 のSBL参照

43.8.1.6 タスク6: Loggerファイル・アダプタ外部参照の作成方法

Loggerファイル・アダプタ外部参照を作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「ファイル・アダプタ」を選択し、「外部参照」スイムレーンにドラッグします。

アダプタ構成ウィザードの「ようこそ」ページが表示されます。

3. 「次へ」をクリックします。

「サービス名」ページが表示されます。

4. 「サービス名」フィールドに、Loggerと入力します。

5. 「次へ」をクリックします。

「操作」ページが表示されます。

6. 「操作タイプ」フィールドで、「Write File」を選択します。

7. 「次へ」をクリックします。

「ファイル構成」ページが表示されます。

8. 「発信ファイルのディレクトリ(物理パス)」フィールドに、ファイルを書き込むディレクトリの名前を入力します。

9. ファイル命名規則フィールドで、output.xmlと入力し、「次へ」をクリックします。

「メッセージ」ページが表示されます。

10. 「検索」をクリックします。

「タイプ・チューザ」ダイアログが表示されます。

11. 「タイプ・エクスプローラ」→「プロジェクトのスキーマ・ファイル」→「SCOTT_POPULATE_APP_INSTANCE.xsd」の順に移動し、「OutputParameters」を選択します。

12. 「OK」をクリックします。

13. 「次へ」をクリックします。

「終了」ページが表示されます。

14. 「終了」をクリックします。

図43-22 に、のLogger参照を示します。

図43-22 のLogger参照

15. 「ファイル」メニューから「すべて保存」を選択します。

43.8.1.7 タスク7: Oracle Mediatorサービス・コンポーネントの作成方法

Oracle Mediatorサービス・コンポーネントを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウから「メディエータ」アイコンをドラッグし、SOAコンポジット・エディタの「コンポーネント」セクションにドロップします。

「メディエータの作成」ダイアログが表示されます。

2. 「テンプレート」リストから、「インタフェースを後で定義」を選択します。

3. 「OK」をクリックします。

Mediator1という名前のOracle Mediatorが作成されます。

4. 図43-23 に示すように、「SAP」サービスを「Mediator1」に接続します。

図43-23 SAPサービスのMediator1への接続

5. 「ファイル」メニューから「すべて保存」を選択します。

6. 「コンポーネント」ウィンドウから別の「メディエータ」アイコンをドラッグし、SOAコンポジット・エディタの「コンポーネント」セクションにドロップします。

「メディエータの作成」ダイアログが表示されます。

7. 「テンプレート」リストから、「WSDLからのインタフェース定義」を選択します。

8. 「SOAPバインディングを持つコンポジット・サービスの作成」の選択を解除します。

9. 「WSDLファイル」フィールドの右側にある「既存のWSDLを検索します。」をクリックします。

10. Common.wsdlファイルに移動して選択します。Common.wsdlファイルは、Samplesフォルダにあります。

11. 「OK」をクリックします。

12. 「OK」をクリックします。

Commonという名前のOracle Mediatorが作成されます。

43.8.1.8 タスク8: Oracle Mediatorサービス・コンポーネントのルーティング・ルールの指定方法

次の操作のルーティング・ルールを指定する必要があります。

- 挿入

- 更新

- ID更新

- 削除

43.8.1.8.1 挿入操作のルーティング・ルールを作成する手順:

1. 「Mediator1」Oracle Mediatorをダブルクリックします。
メディエータ・エディタが表示されます。

2. 「ルーティング・ルール」セクションで、「新規ルーティング・ルールを作成します。」アイコンをクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

3. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

4. 「XrefCustApp」→「メディエータ」→「Common」→「サービス」→「Common」の順に移動します。

5. 「insert」を選択し、「OK」をクリックします。

6. 「フィルタ」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

7. 「式」フィールドに、次の式を入力します。

$in.Sap01Collection/top:Sap01Collection/top:Sap01/top:operation='INSERT'

8. 「OK」をクリックします。

9. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

10. 「新規マッパー・ファイルの作成」を選択し、SAP_TO_COMMON_INSERT.xslと入力します。

11. 「OK」をクリックします。
XSLTマッパーに、「SAP_TO_COMMON_INSERT.xsl」ファイルが表示されます。

12. 「top:SAP01」ソース要素を「inp1:Customer」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。

13. 「自動マップ中」オプションから、「祖先名を考慮した要素の一致」の選択を解除します。

14. 「OK」をクリックします。
図43-24 に示すように、トランスフォーメーションが作成されます。

図43-24 SAP_TO_COMMON_INSERT.xslトランスフォーメーション

15. 「コンポーネント」ウィンドウで、「詳細」を選択します。

16. 「XREF関数」を選択します。

17. 「コンポーネント」ウィンドウからtop:id要素とinp1:id要素を接続している線まで「populateXRefRow」関数をドラッグ・アンド・ドロップします。

18. 「populateXRefRow」アイコンをダブルクリックします。
「関数の編集 - populateXRefRow」ダイアログが表示されます。

19. 「xrefLocation」フィールドの右側にある「検索」をクリックします。
「SOAリソース・ルックアップ」ダイアログが表示されます。

20. 「customer.xref」を選択し、「OK」をクリックします。

21. 「referenceColumnName」フィールドで"SAP_01"と入力するか、または「検索」をクリックして列名を選択します。

22. 「referenceValue」列に、/top:Sap01Collection/top:Sap01/top:idと入力します。

23. 「columnName」フィールドで"Common"と入力するか、「検索」をクリックして列名を選択します。

24. 「value」フィールドに、oraext:generate-guid()と入力します。

25. 「mode」フィールドで"Add"と入力するか、「検索」をクリックして、このモードを選択します。
図43-25 は、移入後の「関数の編集 – populateXRefRow」ダイアログを示しています。

図43-25 「関数の編集 – populateXRefRow」ダイアログ: XrefCustAppユースケース

26. 「OK」をクリックします。

27. 「ファイル」メニューから、「すべて保存」を選択して、「SAP_TO_COMMON_INSERT.xsl」ファイルを閉じます。
図43-26 に示すように、「ルーティング・ルール」セクションが表示されます。

図43-26 挿入操作を行う「ルーティング・ルール」セクション

43.8.1.8.2 更新操作のルーティング・ルールを作成する手順:

1. 「ルーティング・ルール」セクションで、「新規ルーティング・ルールを作成します。」アイコンをクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

2. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

3. 「XrefCustApp」→「メディエータ」→「Common」→「サービス」→「Common」の順に移動します。

4. 「update」を選択し、「OK」をクリックします。

5. 「フィルタ」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

6. 「式」フィールドに、次の式を入力します。

$in.Sap01Collection/top:Sap01Collection/top:Sap01/top:operation='UPDATE'

7. 「OK」をクリックします。

8. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

9. 「新規マッパー・ファイルの作成」を選択し、SAP_TO_COMMON_UPDATE.xslと入力します。

10. 「OK」をクリックします。
「SAP_TO_COMMON_UPDATE.xsl」ファイルが表示されます。

11. 「top:Sap01」ソース要素を「inp1:Customer」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。

12. 「OK」をクリックします。

13. 「コンポーネント」ウィンドウで、「詳細」を選択します。

14. 「XREF関数」を選択します。

15. 「コンポーネント」ウィンドウからtop:id要素とinp1:id要素を接続している線まで「lookupXRef」関数をドラッグ・アンド・ドロップします。

16. 「lookupXRef」アイコンをダブルクリックします。
「関数の編集 - lookupXRef」ダイアログが表示されます。

17. 「xrefLocation」フィールドの右側にある「検索」をクリックします。
「SOAリソース・ルックアップ」ダイアログが表示されます。

18. 「customer.xref」を選択し、「OK」をクリックします。

19. 「referenceColumnName」フィールドで"SAP_01"と入力するか、または「検索」をクリックして列名を選択します。

20. 「referenceValue」列に、/top:Sap01Collection/top:Sap01/top:idと入力します。

21. 「columnName」フィールドで"COMMON"と入力するか、「検索」をクリックして列名を選択します。

22. 「needException」フィールドでtrue()と入力するか、「検索」をクリックして、このモードを選択します。
図43-27 は、移入後の「関数の編集 – lookupXRef」ダイアログを示しています。

図43-27 「関数の編集 – lookupXRef」ダイアログ: XrefCustAppユースケース

23. 「OK」をクリックします。

24. 「ファイル」メニューから、「すべて保存」を選択して、「SAP_TO_COMMON_UPDATE.xsl」ファイルを閉じます。
図43-28 に示すように、「ルーティング・ルール」セクションが表示されます。

図43-28 挿入操作と更新操作

43.8.1.8.3 ID更新操作のルーティング・ルールを作成する手順:

次のタスクを実行して、updateID操作のルーティング・ルールを作成します。

1. 「ルーティング・ルール」セクションで、「新規ルーティング・ルールを作成します。」アイコンをクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

2. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

3. 「XrefCustApp」→「メディエータ」→「Common」→「サービス」→「Common」の順に移動します。

4. 「updateid」を選択し、「OK」をクリックします。

5. 「フィルタ」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

6. 「式」フィールドに、次の式を入力します。

$in.Sap01Collection/top:Sap01Collection/top:Sap01/top:operation = 'UPDATEID'

7. 「OK」をクリックします。

8. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

9. 「新規マッパー・ファイルの作成」を選択し、SAP_TO_COMMON_UPDATEID.xslと入力します。

10. 「OK」をクリックします。
「SAP_TO_COMMON_UPDATEID.xsl」ファイルが表示されます。

11. 「top:Sap01」ソース要素を「inp1:Customer」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。

12. 「OK」をクリックします。

13. 「コンポーネント」ウィンドウで、「詳細」を選択します。

14. 「XREF関数」を選択します。

15. 「コンポーネント」ウィンドウからtop:id要素とinp1:id要素を接続している線まで「populateXRefRow」関数をドラッグ・アンド・ドロップします。

16. 「populateXRefRow」アイコンをダブルクリックします。
「関数の編集 - populateXRefRow」ダイアログが表示されます。

17. 「xrefLocation」フィールドの右側にある「検索」をクリックします。
「SOAリソース・ルックアップ」ダイアログが表示されます。

18. 「customer.xref」を選択し、「OK」をクリックします。

19. 「referenceColumnName」フィールドで"SAP_01"と入力するか、または「検索」をクリックして列名を選択します。

20. 「referenceValue」列に、/top:Sap01Collection/top:Sap01/top:refIdと入力します。

21. 「columnName」フィールドで"SAP_01"と入力するか、「検索」をクリックして列名を選択します。

22. 「value」フィールドに、/top:Sap01Collection/top:Sap01/top:Idと入力します。

23. 「mode」フィールドで"UPDATE"と入力するか、「検索」をクリックして、このモードを選択します。
図43-29 は、移入後の「関数の編集 – populateXRefRow」ダイアログを示しています。

図43-29 「関数の編集 – populateXRefRow」ダイアログ: XrefCustAppユースケース

24. 「コンポーネント」ウィンドウからtop:id要素とinp1:id要素を接続している線まで「lookupXRef」関数をドラッグ・アンド・ドロップします。

25. 「lookupXRef」アイコンをダブルクリックします。
「関数の編集 - lookupXRef」ダイアログが表示されます。

26. 「xrefLocation」フィールドの右側にある「検索」をクリックします。
「SOAリソース・ルックアップ」ダイアログが表示されます。

27. 「customer.xref」を選択し、「OK」をクリックします。

28. 「referenceColumnName」フィールドで"SAP_01"と入力するか、または「検索」をクリックして列名を選択します。

29. 「referenceValue」列に、次の値を入力します。

xref:populateXRefRow("customer.xref","SAP_
01",/top:Sap01Collection/top:Sap01/top:refId,"SAP_
01",/top:Sap01Collection/top:Sap01/top:id,"UPDATE").

30. 「columnName」フィールドで"COMMON"と入力するか、「検索」をクリックして列名を選択します。

31. 「needException」フィールドでfalse()と入力するか、「検索」をクリックして、このモードを選択します。
図43-30 は、移入後の「関数の編集 – lookupXRef」ダイアログを示しています。

図43-30 「関数の編集 – lookupXRef」ダイアログ: XrefCustAppユースケース

32. 「OK」をクリックします。

33. 「ファイル」メニューから、「すべて保存」を選択して、「SAP_TO_COMMON_UPDATEID.xsl」ファイルを閉じます。
図43-31 に示すように、「ルーティング・ルール」セクションが表示されます。

図43-31 挿入操作、更新操作およびID更新操作

43.8.1.8.4 削除操作のルーティング・ルールを作成する手順:

1. 「ルーティング・ルール」セクションで、「新規ルーティング・ルールを作成します。」アイコンをクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

2. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

3. 「XrefCustApp」→「メディエータ」→「Common」→「サービス」→「Common」の順に移動します。

4. 「delete」を選択し、「OK」をクリックします。

5. 「フィルタ」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

6. 「式」フィールドに、次の式を入力します。

$in.Sap01Collection/top:Sap01Collection/top:Sap01/top:operation = 'DELETE'

7. 「OK」をクリックします。

8. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

9. 「新規マッパー・ファイルの作成」を選択し、SAP_TO_COMMON_DELETE.xslと入力します。

10. 「OK」をクリックします。
「SAP_TO_COMMON_DELETE.xsl」ファイルが表示されます。

11. <sources>を右クリックし、「パラメータの追加」を選択します。
「パラメータの追加」ダイアログが表示されます。

12. 「ローカル名」フィールドに、COMMONIDと入力します。

13. 「デフォルト値の設定」を選択します。

14. 「式」を選択します。

15. 「XPath式」フィールドに、次の式を入力します。

xref:lookupXRef("customer.xref","SAP_
01",/top:Sap01Collection/top:Sap01/top:id,"COMMON",false()).

16. 「OK」をクリックします。

17. 「top:Sap01」ソース要素を「inp1:Customer」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。

18. 「OK」をクリックします。

19. 「top:id」と「inp1:id」を接続している線を削除します。

20. 「COMMONID」を「inp1:id」に接続します。

21. 「inp1:id」を右クリックして「XSLノードの追加」を選択してから、「if」を選択します。
新しいノード「if」が、「inp1:customer」と「inp1:id」の間に挿入されます。

22. 「top:id」を「if」ノードに接続します。

23. 「コンポーネント」ウィンドウで、「詳細」を選択します。

24. 「XREF関数」を選択します。

25. 「コンポーネント」ウィンドウからtop:idとifノードを接続している線まで「markForDelete」関数をドラッグ・アンド・ドロップします。

26. 「markForDelete」アイコンをダブルクリックします。
「関数の編集 - markForDelete」ダイアログが表示されます。

27. 「xrefLocation」フィールドの右側にある「検索」をクリックします。
「SOAリソース・ルックアップ」ダイアログが表示されます。

28. 「customer.xref」を選択し、「OK」をクリックします。

29. 「columnName」フィールドで"SAP_01"と入力するか、「検索」をクリックして列名を選択します。

30. 「value」フィールドに、/top:Sap01Collection/top:Sap01/top:Idと入力します。
図43-32 は、移入後の「関数の編集 – markForDelete」ダイアログを示しています。

図43-32 「関数の編集 – markForDelete」ダイアログ: XrefCustAppユースケース

31. 「OK」をクリックします。
図43-33 に示すように、「SAP_TO_COMMON_DELETE.xsl」ファイルが表示されます。

図43-33 SAP_TO_COMMON_DELETE.xsl

32. 「ファイル」メニューから、「すべて保存」を選択して、「SAP_TO_COMMON_DELETE.xsl」ファイルを閉じます。
図43-34 に示すように、「ルーティング・ルール」セクションが表示されます。

図43-34 挿入操作、更新操作、ID更新操作および削除操作

43.8.1.9 タスク9: 「Common」Oracle Mediatorのルーティング・ルールの指定方法

「Common」Oracle Mediatorの次の操作についてルーティング・ルールを指定する必要があります。

- 挿入

- 削除

- 更新

- ID更新

43.8.1.9.1 挿入操作のルーティング・ルールを作成する手順:

1. 「Common」Oracle Mediatorをダブルクリックします。
メディエータ・エディタが表示されます。

2. 「ルーティング・ルール」セクションで、「新規ルーティング・ルールを作成します。」アイコンをクリックします。

「ターゲット・タイプ」ダイアログが表示されます。

3. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

4. 「XrefCustApp」→「参照」→「SBL」の順に移動します。

5. 「SBL」を選択し、「OK」をクリックします。

6. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

7. 「新規マッパー・ファイルの作成」を選択し、COMMON_TO_SBL_INSERT.xslと入力します。

8. 「OK」をクリックします。
「COMMON_TO_SBL_INSERT.xsl」ファイルが表示されます。

9. 「inp1:Customers」ソース要素を「db:InputParameters」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。

10. 「OK」をクリックします。
図43-35 に示すように、トランスフォーメーションが作成されます。

図43-35 COMMON_TO_SBL_INSERT.xslトランスフォーメーション

11. 「ファイル」メニューから、「すべて保存」を選択して、「COMMON_TO_SBL_INSERT.xsl」ファイルを閉じます。

12. 「同期リプライ」セクションで、「ターゲット・サービス操作を参照します。」をクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

13. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

14. 「XrefCustApp」→「参照」→「Logger」の順に移動します。

15. 「Write」を選択し、「OK」をクリックします。

16. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リプライ・トランスフォーメーション・マップ」ダイアログが表示されます。

17. 「新規マッパー・ファイルの作成」を選択し、SBL_TO_COMMON_INSERT.xslと入力します。

18. 「リクエストをリプライ・ペイロードに含める」を選択します。

19. 「OK」をクリックします。
「SBL_TO_COMMON_INSERT.xsl」ファイルが表示されます。

20. 「inp1:Customers」ソース要素を「db:X:APP_ID」に接続します。

21. 「コンポーネント」ウィンドウから接続線まで「populateXRefRow」関数をドラッグ・アンド・ドロップします。

22. 「populateXRefRow」アイコンをダブルクリックします。
「関数の編集 - populateXRefRow」ダイアログが表示されます。

23. 表示されたフィールドに次の情報を入力します。

- xrefLocation: "customer.xref"

- referenceColumnName: "Common"

- referenceValue: $initial.Customers/inp1:Customers/inp1:Customer/inp1:Id

- columnName: "SBL_78"

- value: /db:OutputParameters/db:X_APP_ID

- mode: "LINK"

24. 「OK」をクリックします。
図43-36 に示すように、「SBL_TO_COMMON_INSERT.xsl」ファイルが表示されます。

図43-36 SBL_TO_COMMON_INSERT.xslトランスフォーメーション

25. 「ファイル」メニューから、「すべて保存」を選択して、「SBL_TO_COMMON_INSERT.xsl」ファイルを閉じます。

26. 「同期リプライ」セクションで、「値の割当て」アイコンをクリックします。
「値の割当て」ダイアログが表示されます。

27. 「追加」をクリックします。
「値の割当て」ダイアログが表示されます。

28. 「From」セクションで、「式」を選択します。

29. 「式ビルダーの起動」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

30. 「式」フィールドに次の式を入力し、「OK」をクリックします。

concat('INSERT-',$in.OutputParameters/db:OutputParameters/db:X_APP_ID,'.xml')

31. 「To」セクションで、「プロパティ」を選択します。

32. 「jca.file.FileName」プロパティを選択し、「OK」をクリックします。

33. 「OK」をクリックします。
図43-37 に示すように、「insert」操作セクションが表示されます。

図43-37 SBLターゲット・サービスで行う挿入操作

34. 「ファイル」メニューで、「すべて保存」を選択します。

35. ステップ2からステップ34を繰り返し、EBSというもう1つのターゲット・サービスおよびそのルーティング・ルールを指定します。
図43-38 に、SBLおよびEBSターゲット・サービスの「insert」操作セクションを示します。

図43-38 SBLターゲット・サービスとEBSターゲット・サービスで行う挿入操作

43.8.1.9.2 削除操作のルーティング・ルールを作成する手順:

次のタスクを実行して、削除操作のルーティング・ルールを作成します。

1. 「ルーティング・ルール」セクションで、「新規ルーティング・ルールを作成します。」アイコンをクリックします。

「ターゲット・タイプ」ダイアログが表示されます。

2. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

3. 「XrefCustApp」→「参照」→「SBL」の順に移動します。

4. 「SBL」を選択し、「OK」をクリックします。

5. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

6. 「新規マッパー・ファイルの作成」を選択し、COMMON_TO_SBL_DELETE.xslと入力します。

7. 「OK」をクリックします。
「COMMON_TO_SBL_DELETE.xsl」ファイルが表示されます。

8. 「inp1:Customers」ソース要素を「db:InputParameters」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。

9. 「OK」をクリックします。
図43-39 に示すように、トランスフォーメーションが作成されます。

図43-39 COMMON_TO_SBL_DELETE.xslトランスフォーメーション

10. 「コンポーネント」ウィンドウからinp1:idとdb:XCUSTOMER_IDを接続している線まで「lookupXRef」関数をドラッグ・アンド・ドロップします。

11. 「lookupXRef」アイコンをダブルクリックします。
「関数の編集 - lookupXRef」ダイアログが表示されます。

12. 表示されたフィールドに次の情報を入力します。

- xrefLocation: "customer.xref"

- referenceColumnName: "Common"

- referenceValue: /inp1:Customers/inp1:Customer/inp1:Id

- columnName: "SBL_78"

- needException: false()

13. 「OK」をクリックします。

14. 「ファイル」メニューから、「すべて保存」を選択して、「COMMON_TO_SBL_DELETE.xsl」ファイルを閉じます。

15. 「同期リプライ」セクションで、「ターゲット・サービス操作を参照します。」をクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

16. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

17. 「XrefCustApp」→「参照」→「Logger」の順に移動します。

18. 「Write」を選択し、「OK」をクリックします。

19. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リプライ・トランスフォーメーション・マップ」ダイアログが表示されます。

20. 「新規マッパー・ファイルの作成」を選択し、SBL_TO_COMMON_DELETE.xslと入力します。

21. 「OK」をクリックします。
「SBL_TO_COMMON_DELETE.xsl」ファイルが表示されます。

22. 「db:X_APP_ID」ソース要素を「db:X:APP_ID」ターゲットに接続します。

23. 「コンポーネント」ウィンドウから接続線まで「markForDelete」関数をドラッグ・アンド・ドロップします。

24. 「markForDelete」アイコンをダブルクリックします。
「関数の編集 - markForDelete」ダイアログが表示されます。

25. 表示されたフィールドに次の情報を入力します。

- xrefLocation: "customer.xref"

- columnName: "SBL_78"

- value: /db:OutputParameters/db:X_APP_ID

26. 「OK」をクリックします。

27. 「ファイル」メニューから、「すべて保存」を選択して、「SBL_TO_COMMON_DELETE.xsl」ファイルを閉じます。

28. 「同期リプライ」セクションで、「値の割当て」アイコンをクリックします。
「値の割当て」ダイアログが表示されます。

29. 「追加」をクリックします。
「値の割当て」ダイアログが表示されます。

30. 「From」セクションで、「式」を選択します。

31. 「式ビルダーの起動」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

32. 「式」フィールドに次の式を入力し、「OK」をクリックします。

concat('DELETE-',$in.OutputParameters/db:OutputParameters/db:X_APP_ID,'.xml')

33. 「To」セクションで、「プロパティ」を選択します。

34. 「jca.file.FileName」プロパティを選択し、「OK」をクリックします。

35. 「OK」をクリックします。
図43-40 に示すように、「delete」操作セクションが表示されます。

図43-40 SBLターゲット・サービスで行う削除操作

36. 「ファイル」メニューで、「すべて保存」を選択します。

37. ステップ1からステップ36を繰り返し、EBSというもう1つのターゲット・サービスおよびルーティング・ルールを指定します。
図43-41 に、SBLおよびEBSターゲット・サービスの「delete」操作セクションを示します。

図43-41 SBLターゲット・サービスとEBSターゲット・サービスで行う削除操作

43.8.1.9.3 更新操作のルーティング・ルールを作成する手順:

次のタスクを実行して、更新操作のルーティング・ルールを作成します。

1. 「ルーティング・ルール」セクションで、「新規ルーティング・ルールを作成します。」アイコンをクリックします。

「ターゲット・タイプ」ダイアログが表示されます。

2. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

3. 「XrefCustApp」→「参照」→「SBL」の順に移動します。

4. 「SBL」を選択し、「OK」をクリックします。

5. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

6. 「新規マッパー・ファイルの作成」を選択し、COMMON_TO_SBL_UPDATE.xslと入力します。

7. 「OK」をクリックします。
「COMMON_TO_SBL_UPDATE.xsl」ファイルが表示されます。

8. 「inp1:Customers」ソース要素を「db:InputParameters」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。

9. 「OK」をクリックします。
図43-39 に示すように、トランスフォーメーションが作成されます。

10. 「コンポーネント」ウィンドウからinp1:idとdb:XCUSTOMER_IDを接続している線まで「lookupXRef」関数をドラッグ・アンド・ドロップします。

11. 「lookupXRef」アイコンをダブルクリックします。
「関数の編集 - lookupXRef」ダイアログが表示されます。

12. 表示されたフィールドに次の情報を入力します。

- xrefLocation: "customer.xref"

- referenceColumnName: "Common"

- referenceValue: /inp1:Customers/inp1:Customer/inp1:Id

- columnName: "SBL_78"

- needException: true()

13. 「OK」をクリックします。

14. 「ファイル」メニューから、「すべて保存」を選択して、「COMMON_TO_SBL_UPDATE.xsl」ファイルを閉じます。

15. 「同期リプライ」セクションで、「ターゲット・サービス操作を参照します。」をクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

16. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

17. 「XrefCustApp」→「参照」→「Logger」の順に移動します。

18. 「Write」を選択し、「OK」をクリックします。

19. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リプライ・トランスフォーメーション・マップ」ダイアログが表示されます。

20. 「新規マッパー・ファイルの作成」を選択し、SBL_TO_COMMON_UPDATE.xslと入力します。

21. 「OK」をクリックします。
「SBL_TO_COMMON_UPDATE.xsl」ファイルが表示されます。

22. 「db:X:APP_ID」ソース要素を「db:X:APP_ID」に接続します。

23. 「ファイル」メニューから、「すべて保存」を選択して、「SBL_TO_COMMON_UPDATE.xsl」ファイルを閉じます。

24. 「同期リプライ」セクションで、「値の割当て」アイコンをクリックします。
「値の割当て」ダイアログが表示されます。

25. 「追加」をクリックします。
「値の割当て」ダイアログが表示されます。

26. 「From」セクションで、「式」を選択します。

27. 「式ビルダーの起動」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

28. 「式」フィールドに次の式を入力し、「OK」をクリックします。

concat('UPDATE-',$in.OutputParameters/db:OutputParameters/db:X_APP_ID,'.xml')

29. 「To」セクションで、「プロパティ」を選択します。

30. 「jca.file.FileName」プロパティを選択し、「OK」をクリックします。

31. 「OK」をクリックします。
図43-42 に示すように、「update」操作セクションが表示されます。

図43-42 SBLターゲット・サービスで行う更新操作

32. 「ファイル」メニューで、「すべて保存」を選択します。

33. ステップ1からステップ32を繰り返し、EBSというもう1つのターゲット・サービスおよびそのルーティング・ルールを指定します。
図43-43 に、SBLターゲット・サービスおよびEBSターゲット・サービスの「update」操作セクションを示します。

図43-43 SBLターゲット・サービスとEBSターゲット・サービスで行う更新操作

43.8.1.9.4 ID更新操作のルーティング・ルールを作成する手順:

次のタスクを実行して、ID更新操作のルーティング・ルールを作成します。

1. 「ルーティング・ルール」セクションで、「新規ルーティング・ルールを作成します。」アイコンをクリックします。

「ターゲット・タイプ」ダイアログが表示されます。

2. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

3. 「XrefCustApp」→「参照」→「SBL」の順に移動します。

4. 「SBL」を選択し、「OK」をクリックします。

5. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

6. 「新規マッパー・ファイルの作成」を選択し、COMMON_TO_SBL_UPDATEID.xslと入力します。

7. 「OK」をクリックします。
「COMMON_TO_SBL_UPDATEID.xsl」ファイルが表示されます。

8. 「inp1:Customers」ソース要素を「db:InputParameters」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。

9. 「OK」をクリックします。
図43-39 に示すように、トランスフォーメーションが作成されます。

10. 「コンポーネント」ウィンドウからinp1:idとdb:X_CUSTOMER_IDを接続している線まで「lookupXRef」関数をドラッグ・アンド・ドロップします。

11. 「lookupXRef」アイコンをダブルクリックします。
「関数の編集 - lookupXRef」ダイアログが表示されます。

12. 表示されたフィールドに次の情報を入力します。

- xrefLocation: customer.xref

- referenceColumnName: Common

- referenceValue: /inp1:Customers/inp1:Customer/inp1:Id

- columnName: SBL_78

- needException: false()

13. 「OK」をクリックします。

14. 「ファイル」メニューから、「すべて保存」を選択して、「COMMON_TO_SBL_UPDATEID.xsl」ファイルを閉じます。

15. 「同期リプライ」セクションで、「ターゲット・サービス操作を参照します。」をクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

16. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

17. 「XrefCustApp」→「参照」→「Logger」の順に移動します。

18. 「Write」を選択し、「OK」をクリックします。

19. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リプライ・トランスフォーメーション・マップ」ダイアログが表示されます。

20. 「リクエストをリプライ・ペイロードに含める」を選択します。

21. 「OK」をクリックします。
「SBL_TO_COMMON_UPDATEID.xsl」ファイルが表示されます。

22. 「inp1:Customers」ソース要素を「db:X:APP_ID」に接続します。

23. 「コンポーネント」ウィンドウから接続線まで「populateXRefRow」関数をドラッグ・アンド・ドロップします。

24. 「populateXRefRow」アイコンをダブルクリックします。
「関数の編集 - populateXRefRow」ダイアログが表示されます。

25. 表示されたフィールドに次の情報を入力します。

- xrefLocation: customer.xref

- referenceColumnName: Common

- referenceValue: $initial.Customers/inp1:Customers/inp1:Customer/inp1:Id

- columnName: SBL_78

- value: /db:OutputParameters/db:X_APP_ID

- mode: UPDATE

26. 「OK」をクリックします。

27. 「ファイル」メニューから、「すべて保存」を選択して、「SBL_TO_COMMON_UPDATEID.xsl」ファイルを閉じます。

28. 「同期リプライ」セクションで、「値の割当て」アイコンをクリックします。
「値の割当て」ダイアログが表示されます。

29. 「追加」をクリックします。
「値の割当て」ダイアログが表示されます。

30. 「From」セクションで、「式」を選択します。

31. 「式ビルダーの起動」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

32. 「式」フィールドに次の式を入力し、「OK」をクリックします。

concat('UPDATEID-',$in.OutputParameters/db:OutputParameters/db:X_APP_ID,'.xml')

33. 「To」セクションで、「プロパティ」を選択します。

34. 「jca.file.FileName」プロパティを選択し、「OK」をクリックします。

35. 「OK」をクリックします。
図43-44 に示すように、「updateid」操作セクションが表示されます。

図43-44 SBLターゲット・サービスで行うID更新操作

36. 「ファイル」メニューで、「すべて保存」を選択します。

37. ステップ1からステップ36を繰り返し、EBSというもう1つのターゲット・サービスおよびルーティング・ルールを指定します。
図43-45 に、SBLおよびEBSターゲット・サービスの「updateid」操作セクションを示します。

図43-45 SBLターゲット・サービスとEBSターゲット・サービスで行うID更新操作

43.8.1.10 タスク10: アプリケーション・サーバー接続の構成方法

SOAコンポジット・アプリケーションをデプロイするには、アプリケーション・サーバー接続が必要です。アプリケーション・サーバー接続の作成方法の詳細は、「アプリケーション・サーバー接続の作成」を参照してください。

43.8.1.11 タスク11: コンポジット・アプリケーションのデプロイ方法

次の手順で、XrefCustAppコンポジット・アプリケーションをデプロイします。

- アプリケーション・デプロイメント・プロファイルの作成

- アプリケーション・サーバーへのアプリケーションのデプロイ

これらの手順の詳細は、「単一のSOAコンポジットのデプロイ方法」を参照してください。

43.8.2 XrefCustAppアプリケーションの実行方法と監視方法

デプロイしたXrefCustAppアプリケーションは、XrefCustApp/sqlフォルダのinsert_sap_record.sqlファイルから任意のコマンドを使用することで実行できます。正常に完了すると、レコードがEBSおよびSBL表に挿入および更新され、Logger参照がoutput.xmlファイルに出力を書き出します。

実行中のインスタンスの監視には、次のURLにあるOracle Enterprise Manager Fusion Middleware Controlを使用できます。

http://hostname:port_number/em

ここで、hostnameは、Oracle SOA Suiteインフラストラクチャをインストールしたホストです。port_numberはサービスを実行するポートです。

43.9 1M関数の相互参照の作成および実行

相互参照ユースケースは、2つのエンド・システム(Oracle EBSインスタンスおよびSAPインスタンス)間の統合シナリオを実装します。このユースケースでは、注文はSAPからEBSに渡されます。SAPでは注文は一意のIDで表されますが、EBSではこの注文がID1とID2の2つの注文に分割されます。このシナリオはデータベース・アダプタを使用して作成されます。SAP表の更新レコードまたは新規レコードをポーリングすると、SAPインスタンスが作成されます。EBSでは、このインスタンスがプロシージャによってシミュレートされ、表に移入されます。図43-46 に、このユースケースの概要を示します。

図43-46 のXrefOrderAppユースケース

この項で説明するサンプル・ファイルをダウンロードするには、Oracle SOA Suiteサンプル・ページを参照してください。

43.9.1 ユース-ケースの作成方法

この項では、SOAコンポジット・アプリケーションを作成、構築およびデプロイするための設計時タスクを説明します。これらのタスクは、表示されている順番で実行する必要があります。

43.9.1.1 タスク1: Oracle Databaseおよびデータベース・アダプタの構成方法

Oracle Databaseおよびデータベース・アダプタを構成する手順は、次のとおりです。

1. このユースケースには、SCOTTデータベース・アカウントとパスワードTIGERが必要です。SCOTTアカウントのロックが解除されている必要があります。

SYSDBAでログインしてから、XrefOrderApp1M/sqlフォルダにあるsetup_user.sqlスクリプトを実行してアカウントのロックを解除できます。

2. XrefOrderApp1M/sqlフォルダにあるcreate_schema.sqlスクリプトを実行して、このユースケースに必要な表を作成します。

3. XrefOrderApp1M/sqlフォルダにあるcreate_app_procedure.sqlスクリプトを実行して、この統合に組み込む様々なアプリケーションをシミュレートするプロシージャを作成します。

4. Oracle_Home/rcu/integration/soainfra/sql/xref/フォルダにあるcreateschema_xref_oracle.sqlスクリプトを実行し、ランタイムの相互参照データを格納する相互参照表を作成します。

5. ra.xmlファイルとweblogic-ra.xmlファイルを、$BEAHOME/META-INFから、使用しているコンピュータで新規作成したMETA-INFディレクトリにコピーします。

6. weblogic-ra.xmlファイルを編集します。このファイルは、SOAアプリケーションの$BEAHOME/src/oracle/tip/adapter/db/test/deploy/weblogic/META-INFフォルダにあります。

- 次のように、プロパティをxADataSourceNameに変更します。

<property>
<name>xADataSourceName</name>
<value>jdbc/DBConnection1</value>
</property>

- jndi-nameを次のように変更します。

<jndi-name> eis/DB/DBConnection1</jndi-name>

このサンプルではeis/DB/DBConnection1を使用して新規メッセージのSAP表をポーリングし、Oracle EBSおよびSiebelインスタンスをシミュレートするプロシージャに接続します。

7. ra.xmlファイルとweblogic-ra.xmlファイルをRARファイルとしてパッケージ化し、Oracle WebLogic Server管理コンソールを使用してそのRARファイルをデプロイします。

8. Oracle WebLogic Server管理コンソールを使用して、次の値を持つデータ・ソースを作成します。

- jndi-name=jdbc/DBConnection1

- user=scott

- password=tiger

- url=jdbc:oracle:thin:@host:port:service

- connection-factory factory-class=oracle.jdbc.pool.OracleDataSource

9. Oracle WebLogic Server管理コンソールを使用して、次の値を持つデータ・ソースを作成します。

- jndi-name=jdbc/xref

- user=scott

- password=tiger

- url=jdbc:oracle:thin:@host:port:service

- connection-factory factory-class=oracle.jdbc.pool.OracleDataSource

43.9.1.2 タスク2: Oracle JDeveloperのアプリケーションおよびプロジェクトの作成方法

Oracle JDeveloperのアプリケーションおよびプロジェクトを作成する手順は、次のとおりです。

1. Oracle JDeveloperで「ファイル」をクリックし、「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「新規ギャラリ」で「一般」ノードを開き、「アプリケーション」カテゴリを選択します。

3. 「項目」リストで「SOAアプリケーション」を選択し、「OK」をクリックします。

SOAアプリケーションの作成ウィザードが表示されます。

4. 「アプリケーション名」フィールドでXRefOrderAppと入力し、「次へ」をクリックします。

「プロジェクトの名前付け」ページが表示されます。

5. 「プロジェクト名」フィールドにXRefOrderAppと入力し、「次へ」をクリックします。

「SOA設定の構成」ページが表示されます。

6. 「コンポジット・テンプレート」リストで「空のコンポジット」を選択し、「終了」をクリックします。

Oracle JDeveloperの「アプリケーション」ウィンドウは新規のアプリケーションおよびプロジェクトで更新され、「SOAコンポジット・エディタ」には空白のプロジェクトがあります。

7. 「ファイル」メニューから「すべて保存」を選択します。

43.9.1.3 タスク3: 相互参照の作成方法

ユースケース用のアプリケーションおよびプロジェクトを作成した後は、相互参照表を作成する必要があります。

相互参照表を作成する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「XRefOrderApp」プロジェクトを右クリックして「新規」を選択します。

2. 「新規ギャラリ」ダイアログで「SOA層」ノードを開き、「トランスフォーメーション」カテゴリを選択します。

3. 「項目」リストで「相互参照(XREF)」を選択し、「OK」をクリックします。

「相互参照(XREF)の作成」ダイアログが表示されます。

4. 「ファイル名」フィールドにorder.xrefと入力します。

5. 「エンド・システム」フィールドで、SAP_05およびEBS_i75と入力します。

6. 「OK」をクリックします。

相互参照エディタが表示されます。

7. 「追加」をクリックします。

新しい行が追加されます。

8. 「エンド・システム」名としてCOMMONを入力します。

図43-47 に示すように、相互参照エディタが表示されます。

図43-47 顧客の相互参照

9. 「ファイル」メニューから、「すべて保存」を選択して、相互参照エディタを閉じます。

43.9.1.4 タスク4: データベース・アダプタ・サービスの作成方法

データベース・アダプタ・サービスを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「データベース・アダプタ」を選択し、「公開されたサービス」スイムレーンにドラッグします。

アダプタ構成ウィザードの「ようこそ」ページが表示されます。

3. 「次へ」をクリックします。

「サービス名」ページが表示されます。

4. 「サービス名」フィールドに、SAPと入力します。

5. 「次へ」をクリックします。

「サービス接続」ページが表示されます。

6. 「接続」フィールドで、「DBConnection1」を選択します。

7. 「JNDI名」フィールドに、eis/DB/DBConnection1と入力します。

8. 「次へ」をクリックします。

「操作タイプ」ページが表示されます。

9. 「表の新規レコードまたは更新されたレコードをポーリング」を選択し、「次へ」をクリックします。

「表の選択」ページが表示されます。

10. 「表のインポート」をクリックします。

「表のインポート」ダイアログが表示されます。

11. 「スキーマ」から「Scott」を選択します。

12. 「名前フィルタ」フィールドで%SAP%と入力し、「問合せ」をクリックします。

「選択可能」フィールドに「SAP_05」表名が移入されます。

13. 「SAP_05」をダブルクリックします。

「選択済」フィールドに「SAP_05」が移入されます。

14. 「OK」をクリックします。

ここで「表の選択」ページに「SAP_05」表が含まれます。

15. 「SAP_05」を選択し、「次へ」をクリックします。

「主キーの定義」ページが表示されます。

16. 「ID」を主キーとして選択し、「次へ」をクリックします。

「リレーションシップ」ページが表示されます。

17. 「次へ」をクリックします。

「属性のフィルタ処理」ページが表示されます。

18. 「次へ」をクリックします。

「読取り後」ページが表示されます。

19. 「[SAP_05]表のフィールドの更新 (論理削除)」を選択し、「次へ」をクリックします。

「論理削除」ページが表示されます。

20. 「論理削除フィールド」フィールドで、「LOGICAL_DEL」を選択します。

21. 「読取り値」フィールドで、Yと入力します。

22. 「未読取り値」フィールドで、Nと入力します。

図43-16 は、アダプタ構成ウィザードの「論理削除」ページを示しています。

23. 「次へ」をクリックします。

「ポーリング・オプション」ページが表示されます。

24. 「次へ」をクリックします。

「選択条件の定義」ページが表示されます。

25. 「次へ」をクリックします。

「詳細オプション」ページが表示されます。

26. 「次へ」をクリックします。

「終了」ページが表示されます。

27. 「終了」をクリックします。

図43-48 に示すように、SAPという名前のデータベース・アダプタ・サービスが作成されます。

図43-48 のSAPデータベース・アダプタ・サービス

28. 「ファイル」メニューから「すべて保存」を選択します。

43.9.1.5 タスク5: EBS外部参照の作成方法

EBS外部参照を作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「データベース・アダプタ」を選択し、「外部参照」スイムレーンにドラッグします。

アダプタ構成ウィザードの「ようこそ」ページが表示されます。

3. 「次へ」をクリックします。

「サービス名」ページが表示されます。

4. 「サービス名」フィールドに、EBSと入力します。

5. 「次へ」をクリックします。

「サービス接続」ページが表示されます。

6. 「接続」フィールドで、「DBConnection1」を選択します。

7. 「JNDI名」フィールドに、eis/DB/DBConnection1と入力します。

8. 「次へ」をクリックします。

「操作タイプ」ページが表示されます。

9. 「ストアド・プロシージャまたはファンクションの呼出し」を選択し、「次へ」をクリックします。

「ストアド・プロシージャの指定」ページが表示されます。

10. 「スキーマ」から「Scott」を選択します。

11. 「参照」をクリックします。

「ストアド・プロシージャ」ダイアログが表示されます。

12. 図43-49 に示すように、「POPULATE_APP_INSTANCE_IM」を選択します。

図43-49 「ストアド・プロシージャ」ダイアログ

13. 「OK」をクリックします。

図43-50 に示すように、「ストアド・プロシージャの指定」ページが表示されます。

図43-50 アダプタ構成ウィザードの「ストアド・プロシージャの指定」ページ

14. 「次へ」をクリックします。

「詳細オプション」ページが表示されます。

15. 「次へ」をクリックします。「終了」ページが表示されます。

16. 「終了」をクリックします。

図43-51 に、のEBS参照を示します。

図43-51 のEBS参照

17. 「ファイル」メニューから「すべて保存」を選択します。

43.9.1.6 タスク6: Loggerファイル・アダプタ外部参照の作成方法

Loggerファイル・アダプタ外部参照を作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「ファイル・アダプタ」を選択し、「外部参照」スイムレーンにドラッグします。

アダプタ構成ウィザードの「ようこそ」ページが表示されます。

3. 「次へ」をクリックします。

「サービス名」ページが表示されます。

4. 「サービス名」フィールドに、Loggerと入力します。

5. 「次へ」をクリックします。

「アダプタ・インタフェース」ページが表示されます。

6. 「操作およびスキーマから定義(後で指定)」をクリックします。

「操作」ページが表示されます。

7. 「操作タイプ」フィールドで、「Write File」を選択します。

8. 「次へ」をクリックします。

「ファイル構成」ページが表示されます。

9. 「発信ファイルのディレクトリ(物理パス)」フィールドに、ファイルを書き込むディレクトリの名前を入力します。

10. ファイル命名規則フィールドで、output.xmlと入力し、「次へ」をクリックします。

「メッセージ」ページが表示されます。

11. 「検索」をクリックします。

「タイプ・チューザ」ダイアログが表示されます。

12. 「タイプ・エクスプローラ」→「プロジェクトのスキーマ・ファイル」→「SCOTT_POPULATE_APP_INSTANCE_1M.xsd」の順に移動し、「OutputParameters」を選択します。

13. 「OK」をクリックします。

14. 「次へ」をクリックします。

「終了」ページが表示されます。

15. 「終了」をクリックします。

図43-52 に、のLogger参照を示します。

図43-52 のLogger参照

16. 「ファイル」メニューから「すべて保存」を選択します。

43.9.1.7 タスク7: Oracle Mediatorサービス・コンポーネントの作成方法

サービス・コンポーネントを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウから「メディエータ」アイコンをドラッグし、「コンポーネント」スイムレーンにドロップします。

「メディエータの作成」ダイアログが表示されます。

2. 「テンプレート」リストから、「インタフェースを後で定義」を選択します。

3. 「OK」をクリックします。

Mediator2という名前のOracle Mediatorが作成されます。

4. 図43-53 に示すように、「SAP」サービスを「Mediator2」に接続します。

図43-53 SAPサービスのMediator2への接続

5. 「ファイル」メニューから「すべて保存」を選択します。

6. 「コンポーネント」ウィンドウから「メディエータ」アイコンをドラッグし、SOAコンポジット・エディタの「コンポーネント」セクションにドロップします。

「メディエータの作成」ダイアログが表示されます。

7. 「テンプレート」リストから、「WSDLからのインタフェース定義」を選択します。

8. 「SOAPバインディングを持つコンポジット・サービスの作成」の選択を解除します。

9. 「WSDLファイル」フィールドの右側にある「既存のWSDLを検索します。」をクリックします。

10. Common.wsdlファイルに移動して選択します。Common.wsdlファイルは、Samplesフォルダにあります。

11. 「OK」をクリックします。

12. 「OK」をクリックします。

Commonという名前のOracle Mediatorが作成されます。

43.9.1.8 タスク8: Oracle Mediatorコンポーネントのルーティング・ルールの指定方法

次の操作のルーティング・ルールを指定する必要があります。

- 挿入

- 更新

43.9.1.8.1 挿入操作のルーティング・ルールを作成する手順:

1. 「Mediator2」Oracle Mediatorをダブルクリックします。
メディエータ・エディタが表示されます。

2. 「ルーティング・ルール」セクションで、「新規ルーティング・ルールを作成します。」アイコンをクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

3. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

4. 「XrefOrderApp」→「メディエータ」→「Common」→「サービス」→「Common」の順に移動します。

5. 「insert」を選択し、「OK」をクリックします。

6. 「フィルタ」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

7. 「式」フィールドに、次の式を入力します。

$in.Sap05Collection/top:Sap05Collection/top:Sap05/top:operation='INSERT'

8. 「OK」をクリックします。

9. 「トランスフォーメーションの使用」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

10. 「新規マッパー・ファイルの作成」を選択し、SAP_TO_COMMON_INSERT.xslと入力します。

11. 「OK」をクリックします。
「SAP_TO_COMMON_INSERT.xsl」ファイルが表示されます。

12. 「top:SAP05」ソース要素を「inp1:Order」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。

13. 「自動マップ中」オプション・リストから、「祖先名を考慮した要素の一致」の選択を解除します。

14. 「OK」をクリックします。
図43-54 に示すように、トランスフォーメーションが作成されます。

図43-54 SAP_TO_COMMON_INSERT.xslトランスフォーメーション

15. 「コンポーネント」ウィンドウで、「詳細」を選択します。

16. 「XREF関数」を選択します。

17. 「コンポーネント」ウィンドウからtop:id要素とinp1:id要素を接続している線まで「populateXRefRow1M」関数をドラッグ・アンド・ドロップします。

18. 「populateXRefRow1M」アイコンをダブルクリックします。
「関数の編集 - populateXRefRow」ダイアログが表示されます。

19. 「xrefLocation」フィールドの右側にある「検索」をクリックします。
「SOAリソース・ルックアップ」ダイアログが表示されます。

20. 「Order.xref」を選択し、「OK」をクリックします。

21. 「referenceColumnName」フィールドで"SAP_05"と入力するか、または「検索」をクリックして列名を選択します。

22. 「referenceValue」列に、/top:Sap05Collection/top:Sap05/top:idと入力します。

23. 「columnName」フィールドで"Common"と入力するか、「検索」をクリックして列名を選択します。

24. 「value」フィールドに、orcl:generate-guid()と入力します。

25. 「mode」フィールドで"Add"と入力するか、「検索」をクリックして、このモードを選択します。
図43-55 は、移入後の「関数の編集 – populateXRefRow1M」ダイアログを示しています。

図43-55 「関数の編集 – populateXRefRow1M」ダイアログ: XrefOrderAppユースケース

26. 「OK」をクリックします。

27. 「ファイル」メニューから、「すべて保存」を選択して、「SAP_TO_COMMON_INSERT.xsl」ファイルを閉じます。
図43-56 に示すように、「ルーティング・ルール」セクションが表示されます。

図43-56 挿入操作を行う「ルーティング・ルール」セクション

43.9.1.8.2 更新操作のルーティング・ルールを作成する手順:

次のタスクを実行して、更新操作のルーティング・ルールを作成します。

1. 「ルーティング・ルール」セクションで、「新規ルーティング・ルールを作成します。」アイコンをクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

2. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

3. 「XrefOrderApp」→「メディエータ」→「Common」→「サービス」→「Common」の順に移動します。

4. 「update」を選択し、「OK」をクリックします。

5. 「フィルタ」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

6. 「式」フィールドに、次の式を入力します。

$in.Sap05Collection/top:Sap05Collection/top:Sap05/top:operation='UPDATE'

7. 「OK」をクリックします。

8. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

9. 「新規マッパー・ファイルの作成」を選択し、SAP_TO_COMMON_UPDATE.xslと入力します。

10. 「OK」をクリックします。
「SAP_TO_COMMON_UPDATE.xsl」ファイルが表示されます。

11. 「top:Sap05」ソース要素を「inp1:Order」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。

12. 「OK」をクリックします。

13. 「コンポーネント」ウィンドウで、「詳細」を選択します。

14. 「XREF関数」を選択します。

15. 「コンポーネント」ウィンドウからtop:id要素とinp1:id要素を接続している線まで「lookupXRef」関数をドラッグ・アンド・ドロップします。

16. 「lookupXRef」アイコンをダブルクリックします。
「関数の編集 - lookupXRef」ダイアログが表示されます。

17. 「xrefLocation」フィールドの右側にある「検索」をクリックします。
「SOAリソース・ルックアップ」ダイアログが表示されます。

18. 「customer.xref」を選択し、「OK」をクリックします。

19. 「referenceColumnName」フィールドで"SAP_05"と入力するか、または「検索」をクリックして列名を選択します。

20. 「referenceValue」列に、/top:Sap05Collection/top:Sap05/top:idと入力します。

21. 「columnName」フィールドで"COMMON"と入力するか、「検索」をクリックして列名を選択します。

22. 「needException」フィールドでtrue()と入力するか、「検索」をクリックして、このモードを選択します。
図43-57 は、移入後の「関数の編集 – lookupXRef」ダイアログを示しています。

図43-57 「関数の編集 – lookupXRef」ダイアログ: XRefOrderAppユースケース

23. 「OK」をクリックします。

24. 「ファイル」メニューから、「すべて保存」を選択して、「SAP_TO_COMMON_UPDATE.xsl」ファイルを閉じます。
図43-58 に示すように、「ルーティング・ルール」セクションが表示されます。

図43-58 挿入操作と更新操作

43.9.1.9 タスク9: 「Common」Oracle Mediatorのルーティング・ルールの指定方法

「Common」Oracle Mediatorの次の操作についてルーティング・ルールを指定する必要があります。

- 挿入

- 更新

43.9.1.9.1 挿入操作のルーティング・ルールを作成する手順:

1. 「Common」Oracle Mediatorをダブルクリックします。
メディエータ・エディタが表示されます。

2. 「ルーティング・ルール」セクションで、「新規ルーティング・ルールを作成します。」アイコンをクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

3. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

4. 「XrefOrderApp」→「参照」→「EBS」の順に移動します。

5. 「EBS」を選択して、「OK」をクリックします。

6. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

7. 「新規マッパー・ファイルの作成」を選択し、COMMON_TO_EBS_INSERT.xslと入力します。

8. 「OK」をクリックします。
「COMMON_TO_EBS_INSERT.xsl」ファイルが表示されます。

9. 「inp1:Order」ソース要素を「db:InputParameters」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。

10. 右側の「db:X_APP_INSTANCE」ノードの値をEBS_i75に設定します。
「OK」をクリックします。

図43-59 に示すように、トランスフォーメーションが作成されます。

図43-59 COMMON_TO_EBS_INSERT.xslトランスフォーメーション

11. 「ファイル」メニューから、「すべて保存」を選択して、「COMMON_TO_EBS_INSERT.xsl」ファイルを閉じます。

12. 「同期リプライ」セクションで、「ターゲット・サービス操作を参照します。」をクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

13. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

14. 「XrefOrderApp」→「参照」→「Logger」の順に移動します。

15. 「Write」を選択し、「OK」をクリックします。

16. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リプライ・トランスフォーメーション・マップ」ダイアログが表示されます。

17. 「新規マッパー・ファイルの作成」を選択し、EBS_TO_COMMON_INSERT.xslと入力します。

18. 「リクエストをリプライ・ペイロードに含める」を選択します。

19. 「OK」をクリックします。
「EBS_TO_COMMON_INSERT.xsl」ファイルが表示されます。

20. 「inp1:Order」ソース要素を「db:X:APP_ID」に接続します。

21. 「コンポーネント」ウィンドウから接続線まで「populateXRefRow」関数をドラッグ・アンド・ドロップします。

22. 「populateXRefRow」アイコンをダブルクリックします。
「関数の編集 - populateXRefRow」ダイアログが表示されます。

23. 表示されたフィールドに次の情報を入力します。

- xrefLocation: order.xref

- referenceColumnName: Common

- referenceValue: $initial.Customers/inp1:Customers/inp1:Order/inp1:Id

- columnName: EBS_75

- value: /db:OutputParameters/db:X_APP_ID

- mode: LINK

24. 「OK」をクリックします。
図43-60 に示すように、「EBS_TO_COMMON_INSERT.xsl」ファイルが表示されます。

図43-60 EBS_TO_COMMON_INSERT.xslトランスフォーメーション

25. 「ファイル」メニューから、「すべて保存」を選択して、「EBS_TO_COMMON_INSERT.xsl」ファイルを閉じます。

26. 「同期リプライ」セクションで、「値の割当て」アイコンをクリックします。
「値の割当て」ダイアログが表示されます。

27. 「追加」をクリックします。
「値の割当て」ダイアログが表示されます。

28. 「From」セクションで、「式」を選択します。

29. 「式ビルダーの起動」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

30. 「式」フィールドに次の式を入力し、「OK」をクリックします。

concat('INSERT-',$in.OutputParameters/db:OutputParameters/db:X_APP_ID,'.xml')

31. 「To」セクションで、「プロパティ」を選択します。

32. 「jca.file.FileName」プロパティを選択し、「OK」をクリックします。

33. 「OK」をクリックします。
図43-61 に示すように、「insert」操作セクションが表示されます。

図43-61 EBSターゲット・サービスで行う挿入操作

34. 「ファイル」メニューで、「すべて保存」を選択します。

43.9.1.9.2 更新操作のルーティング・ルールを作成する手順:

次のタスクを実行して、更新操作のルーティング・ルールを作成します。

1. 「ルーティング・ルール」セクションで、「新規ルーティング・ルールを作成します。」アイコンをクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

2. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

3. 「XrefOrderApp」→「参照」→「EBS」の順に移動します。

4. 「EBS」を選択して、「OK」をクリックします。

5. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

6. 「新規マッパー・ファイルの作成」を選択し、COMMON_TO_EBS_UPDATE.xslと入力します。

7. 「OK」をクリックします。
「COMMON_TO_EBS_UPDATE.xsl」ファイルが表示されます。

8. 「inp1:Orders」ソース要素を「db:InputParameters」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。

9. 「OK」をクリックします。
図43-39 に示すように、トランスフォーメーションが作成されます。

10. 「コンポーネント」ウィンドウからinp1:idとdb:X_APP_IDを接続している線まで「lookupXRef」関数をドラッグ・アンド・ドロップします。

11. 「lookupXRef」アイコンをダブルクリックします。
「関数の編集 - lookupXRef」ダイアログが表示されます。

12. 表示されたフィールドに次の情報を入力します。

- xrefLocation: order.xref

- referenceColumnName: Common

- referenceValue: /inp1:Customers/inp1:Order/inp1:Id

- columnName: EBS_i75

- needException: true()

13. 「OK」をクリックします。

14. 「ファイル」メニューから、「すべて保存」を選択して、「COMMON_TO_EBS_UPDATE.xsl」ファイルを閉じます。

15. 「同期リプライ」セクションで、「ターゲット・サービス操作を参照します。」をクリックします。
「ターゲット・タイプ」ダイアログが表示されます。

16. 「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。

17. 「XrefOrderApp」→「参照」→「Logger」の順に移動します。

18. 「Write」を選択し、「OK」をクリックします。

19. 「次を使用して変換」フィールドの横にある「トランスフォーメーション」アイコンをクリックします。
「リプライ・トランスフォーメーション・マップ」ダイアログが表示されます。

20. 「新規マッパー・ファイルの作成」を選択し、EBS_TO_COMMON_UPDATE.xslと入力します。

21. 「OK」をクリックします。
「EBS_TO_COMMON_UPDATE.xsl」ファイルが表示されます。

22. 「db:X:APP_ID」ソース要素を「db:X:APP_ID」に接続します。

23. 「ファイル」メニューから、「すべて保存」を選択して、「EBS_TO_COMMON_UPDATE.xsl」ファイルを閉じます。

24. 「同期リプライ」セクションで、「値の割当て」アイコンをクリックします。
「値の割当て」ダイアログが表示されます。

25. 「追加」をクリックします。
「値の割当て」ダイアログが表示されます。

26. 「From」セクションで、「式」を選択します。

27. 「式ビルダーの起動」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。

28. 「式」フィールドに次の式を入力し、「OK」をクリックします。

concat('UPDATE-',$in.OutputParameters/db:OutputParameters/db:X_APP_ID,'.xml')

29. 「To」セクションで、「プロパティ」を選択します。

30. 「jca.file.FileName」プロパティを選択し、「OK」をクリックします。

31. 「OK」をクリックします。
図43-62 に示すように、「update」操作セクションが表示されます。

図43-62 EBSターゲット・サービスで行う更新操作

32. 「ファイル」メニューで、「すべて保存」を選択します。

43.9.1.10 タスク10: アプリケーション・サーバー接続の構成方法

SOAコンポジット・アプリケーションをデプロイするには、アプリケーション・サーバー接続が必要です。アプリケーション・サーバー接続の作成方法の詳細は、「olink:TKADP212」を参照してください。

43.9.1.11 タスク11: コンポジット・アプリケーションのデプロイ方法

次の手順で、XrefOrderAppコンポジット・アプリケーションをアプリケーション・サーバーにデプロイします。

- アプリケーション・デプロイメント・プロファイルの作成

- アプリケーション・サーバーへのアプリケーションのデプロイ

これらの手順の詳細は、「単一のSOAコンポジットのデプロイ方法」を参照してください。

44 ドメイン値マップの使用

この章では、異なるドメインで同じエンティティを表すために使用される用語をマップする、ドメイン値マップを作成および使用して、あるドメインの特定のフィールドで使用される値を、他のドメインの同じフィールドで使用される値にマップする方法について説明します。この章では、ドメイン値の参照に使用されるXPath関数についても説明します。

この章の内容は次のとおりです。

- ドメイン値マップの概要

- ドメイン値マップの作成

- ドメイン値マップの編集

- ドメイン値マップ関数の使用

- 階層ルックアップ用のドメイン値マップ・ユースケースの作成

- 複数の値のドメイン値マップ・ユースケースの作成

44.1 ドメイン値マップの概要

異なるドメイン間で情報を送信する場合に、各ドメインで同じエンティティを表すのに異なる用語や処理コードを使用している場合があります。たとえば、あるドメインではメッセージ内で完全な都市名(Boston)を使用し、別のドメインでは都市を示すコード(BO)を使用している可能性があります。各ドメインでこれらのデータをいずれかの用語セットに標準化しなくても、ドメイン値マップを使用して、あるドメインで使用されている用語と他のドメインで使用されている用語をマップできます。ドメイン値マップは、実行時にアプリケーションを介して送信されるメッセージ内の実際の値に対して機能します。

通常、各ドメイン値マップでは、1つのフィールドまたはカテゴリのみのマッピングを定義しますが、1つのSOAコンポジットで複数のカテゴリのマッピングが必要になる場合もあります。そのため、1つのSOAコンポジットに複数のドメイン値マップを含めることもできます。たとえば、都市名のマッピングを定義したドメイン値マップと、州名のマッピングを定義したドメイン値マップと、国名のマッピングを定義したドメイン値マップを使用できます。

2つ以上のドメインの間で直接値をマップする方法は、ポイントツーポイント・マッピングと呼ばれます。表44-1 に、2つのドメインの間で都市名をポイントツーポイント・マッピングする方法を示します。

表44-1 ポイントツーポイント・マッピング

CityCode

CityName

BELG_MN_STLouis

BelgradeStLouis

BELG_NC

BelgradeNorthCarolina

BO

Boston

NP

Northport

KN_USA

KensingtonUSA

KN_CAN

KensingtonCanada

ドメイン値マップの値は静的です。ドメイン値マップの値は、設計時にOracle JDeveloperを使用して指定し、実行時にアプリケーションによってドメイン値マップの値のルックアップが実行されます。Oracle SOAコンポーザを使用して実行時のドメイン値マップを編集する方法の詳細は、「ドメイン値マップでのOracle SOAコンポーザの使用」を参照してください。

注意:

アプリケーション間の各値を動的に統合するために、Oracle SOA Suiteの相互参照機能を使用できます。相互参照の詳細は、「相互参照の使用」を参照してください。

44.1.1 ドメイン値マップ機能

Oracle SOA Suiteのドメイン値マップでは、実行時に実行されるドメイン値マップのルックアップのパフォーマンスおよび結果をより詳細に調整できます。たとえば、修飾情報を指定して、マッピングを補助する追加情報を提供します。また、ドメイン値マップでは、1対多マッピングもサポートされています。

44.1.1.1 修飾子ドメイン

修飾子ドメインには、マッピングを明確にするためだけの情報が含まれます。この追加情報が定義されていないと、マッピングが不明確である場合があります。たとえば、Kensingtonという都市はCanadaとUSAの両方にあるため、都市名のマッピングを定義したドメイン値マップにKNとKensingtonのマッピングが複数存在する可能性があります。そのため、このマッピングには、どちらのマッピングを使用するかを示す修飾子(USAまたはCanada)が必要です。この例を表44-2 に示します。

表44-2 修飾子サポートの例

Country (修飾子)

CityCode

CityName

USA

BO

Boston

USA

BELG_NC

Belgrade

USA

BELG_MN_Streams

Belgrade

USA

NP

Northport

USA

KN

Kensington

Canada

KN

Kensington

ドメイン値マップには、複数の修飾子ドメインを含めることができます。たとえば、表44-3 では、さらに州名でマッピングを修飾しています。

表44-3 複数の修飾子サポートの例

Country (修飾子)

State (修飾子)

CityCode

CityName

USA

Massachusetts

BO

Boston

USA

North Carolina

BELG

Belgrade

USA

Minnesota

BELG

Belgrade

USA

Alabama

NP

Northport

USA

Kansas

KN

Kensington

Canada

Prince Edward Island

KN

Kensington

修飾子は、マッピングを修飾するときにのみ使用します。そのため、修飾子の値はルックアップできません。

44.1.1.2 修飾子の階層

複数の修飾子ドメインが存在する場合は、修飾子の順序を指定して、実行時のルックアップ時にそれらの修飾子ドメインがどのように使用されるかを指定できます。修飾子の順序は、より正確な一致を定義する際に、その修飾子の役割によって上位から下位に変化します。表44-3 の場合は、Stateの一致がより正確な一致を示すため、State修飾子をCountry修飾子より上位の順序に指定することが考えられます。

ドメイン値マップは階層ルックアップをサポートします。ルックアップ時に修飾子の値を指定し、正確な一致が検出されなかった場合は、ルックアップ・メカニズムによって上位順序の修飾子が空の引用符("")に設定され、より一般的な一致の検出が試行されます。これは、一致が検出されるか、可能なかぎりのルックアップが終了して一致が検出されなくなるまで実行されます。図44-1 に、(表44-3 の値に基づいた)次のルックアップで階層ルックアップが実行される手順を示します。

State=Arkansas, Country=Canada, CityCode=KN_USA

この例では、State修飾子の順序は1で、Country修飾子の順序は2です。図44-1 に示すように、ルックアップ・メカニズムでは上位順序の修飾子Stateに正確なルックアップ値Arkansasを設定し、下位順序の修飾子CountryにCanada|""を使用します。

図44-1 階層ルックアップの例

一致が検出されない場合、ルックアップ・メカニズムでは上位順序の修飾子Stateに値""を設定し、次に上位である修飾子Countryに正確な値Canadaを設定します。一致が検出されない場合、ルックアップ・メカニズムでは以前に上位順序の修飾子であったCountryに値""を設定します。CityCodeがKN_USAである一致行が1行検出された場合は、値としてKensingtonが返されます。

表44-4 に、これらの手順の要約を示します。

表44-4 ドメイン値マップ・ルックアップ結果

状態

国

短い値

ルックアップ結果

Arkansas

CANADA|" "

KN_USA

No Match

" "

CANADA

KN_USA

No Match

" "

" "

KN_USA

Kensington

44.1.1.3 1対多マッピング

ドメイン値マップでは、1つの値を複数の値にマップできます。たとえば、支払い条件のドメイン値マップには、表44-5 に示すように、支払い条件と、値引率、値引期間、正味掛売り期間などの複数の値とのマッピングを格納できます。

表44-5 1対多マッピング・サポート

支払条件

値引率

値引期間

正味掛売り期間

GoldCustomerPaymentTerm

10

20

30

SilverCustomerPaymentTerm

5

20

30

RegularPaymentTerm

2

20

30

44.2 ドメイン値マップの作成

Oracle JDeveloperのSOAコンポジット・アプリケーションで1つ以上のドメイン値マップを作成し、実行時に、そのマップを使用してマップされている値をルックアップできます。ドメイン値マップを作成すると、.dvmの拡張子が付いたファイルがアプリケーション・ファイル構造に作成されます。

44.2.1 ドメイン値マップの作成方法

ドメイン値マップは、Oracle JDeveloperの「ドメイン値マップ(DVM)・ファイルの作成」ダイアログを使用して作成および構成します。このダイアログでは、それぞれ1つの値を持つ2つのドメインを定義します。完了すると、ドメイン値マップ・エディタが表示され、追加のドメインおよび対応する値を定義できます。

ドメイン値マップを作成する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、ドメイン値マップを作成するプロジェクトを右クリックして、「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「SOA層」ノードを開き、「トランスフォーメーション」カテゴリを選択します。

3. 「項目」リストで、「ドメイン値マップ(DVM)」を選択し、「OK」をクリックします。

「ドメイン値マップ(DVM)・ファイルの作成」ダイアログが表示されます。

4. 「ファイル名」フィールドに、ドメイン値マップ・ファイルのわかりやすい一意の名前を入力します。ファイル名には.dvm拡張子を付ける必要があります。

5. 「説明」フィールドに、ドメイン値マップの説明を入力します。このフィールドはオプションです。

6. 「ドメイン名」フィールドに、各ドメインの名前を入力します。これらの名前はドメイン値マップの列名で、それぞれのドメインにおけるフィールドを表します。

注意:

ドメイン名は、タイプNCName (non-colonized name、コロンを含まない有効なXML要素名)である必要があります。各ドメイン名は、ドメイン値マップ内で一意である必要があります。後で、さらにドメインを追加できます。

7. 「ドメイン値」フィールドに、各ドメインの対応する値を入力します。たとえば、図44-2 に示すように、CityCodeドメインにBOを、CityNameドメインにBostonを入力します。

図44-2 移入後の「ドメイン値マップ・ファイルの作成」ダイアログ

8. 「OK」をクリックします。

ドメイン値マップ・エディタに新しいドメイン値マップが表示されます。

44.2.2 ドメイン値マップ作成時の処理内容

図44-3 に示すように、拡張子が.dvmのファイルがプロジェクト・ファイル構造に作成され、「アプリケーション」ウィンドウに表示されます。

図44-3 「アプリケーション」ウィンドウのドメイン値マップ・ファイル

すべての.dvmファイルは、次の例に示すスキーマ定義(XSD)ファイルに基づいています。

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Copyright (c) 2006, Oracle. All rights reserved.  -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xmlns.oracle.com/dvm"
xmlns:tns="http://xmlns.oracle.com/dvm"
elementFormDefault="qualified"
attributeFormDefault="unqualified">

<xsd:element name="dvm">
<xsd:annotation>
<xsd:documentation>The Top Level Element
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="description" minOccurs="0" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The DVM Description.  This is optional
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="columns">
<xsd:annotation>
<xsd:documentation>This element holds DVM's column List.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="column" minOccurs="2" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>This represents a DVM Column
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="name" use="required" type="xsd:string"/>
<xsd:attribute name="qualifier" default="false" type="xsd:boolean"
use="optional"/>
<xsd:attribute name="order" use="optional" type="xsd:positiveInteger"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="rows" minOccurs="0">
<xsd:annotation>
<xsd:documentation>This represents all the DVM Rows.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="row" minOccurs="1" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
Each DVM row of values
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="cell" minOccurs="2" maxOccurs="unbounded"
type="xsd:string">
<xsd:annotation>
<xsd:documentation>This is the value for this row and for
each column in the same order as defined in Columns.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="name" use="required" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:annotation>
<xsd:documentation>This Schema is used to validate the DVM Document got for
creation and
update of a DVM.
</xsd:documentation>
</xsd:annotation>
</xsd:schema>

44.3 ドメイン値マップの編集

ドメイン値マップのフレームワークを作成した後は、ドメイン値マップ・エディタを使用して、ドメインとそれに対応するドメイン値をマップに追加できます。

44.3.1 ドメイン値マップへのドメインの追加方法

マップへの追加ドメインを定義でき、それらはドメイン値マップに列として表されます。また、それぞれの新規ドメインに含まれる値を実行時のルックアップに含めるのか、それともマッピングを修飾するためだけに使用するのかを指定できます。ドメイン(列)名は、タイプNCName (コロンなしの名前)である必要があります。それは、コロンが付いていない有効なXML要素名です。

ドメイン値マップにドメインを追加するには:

1. ドメイン値マップ・エディタでマップ・ファイルが開かれていない場合は、「アプリケーション」ウィンドウで「DVMファイル」をダブルクリックします。

2. 「マップ表」で、「追加」をクリックし、「ドメインの追加」を選択します。

「ドメインの作成」ダイアログが表示されます。

3. 「名前」フィールドに、列の名前を入力します。

4. 「修飾子」フィールドで、この列を修飾子として設定する場合は「True」を選択します。そうでない場合は「False」を選択します。

ヒント:

修飾子ドメインおよび修飾子の順序の詳細は、「修飾子ドメイン」および「修飾子の階層」を参照してください。

5. 「修飾子順」フィールドに、修飾子ドメインの優先度を示す数値を入力します。

このフィールドが有効になるのは、「修飾子」フィールドで「True」を選択した場合のみです。

図44-4 ドメイン値マップ - 「ドメインの作成」ダイアログ

6. 「OK」をクリックします。

「マップ表」に新しい列が表示されます。

44.3.2 ドメインの編集方法

ドメイン値マップにドメインを追加した後は、名前を変更したり、修飾子ドメインであるかどうかや修飾子の順序を変更できます。

ドメインを編集する手順は、次のとおりです。

1. ドメイン値マップ・エディタで、変更するドメインの名前を選択します。

2. 「ドメイン/値の編集」をクリックします。

「ドメインの編集」ダイアログが表示されます。

図44-5 ドメイン値マップ - 「ドメインの編集」ダイアログ

3. ダイアログで任意のフィールドを変更し、「OK」をクリックします。

注意:

ドメイン名は、タイプNCName (non-colonized name、コロンを含まない有効なXML要素名)である必要があります。

44.3.3 ドメイン値マップへのドメイン値の追加方法

ドメイン値はドメイン値マップの行に表示され、それぞれのドメインの各行に含まれる値がマップされます。ドメイン間のマッピングを完全に定義するために必要な数のドメイン値を追加できます。

ドメイン値マップにドメイン値を追加するには:

1. ドメイン値マップ・エディタで、「追加」をクリックし、「ドメイン値の追加」を選択します。

「マップ表」の既存の行の下に新しい行が表示されます。

2. 新しい行に各ドメインの値を入力します。

3. さらに行を作成するには、前述の手順を繰り返します。変更が終了したら、Oracle JDeveloperツールバーの「すべて保存」をクリックします。

44.3.4 ドメイン値の編集方法

ドメイン値マップにドメイン値を追加した後は、必要に応じて値を変更できます。

ドメイン値を変更する手順は、次のとおりです。

1. ドメイン値マップ・エディタで、変更する値が含まれている行を選択します。

2. 「ドメイン/値の編集」をクリックします。

「ドメイン値の編集」ダイアログが表示されます。

図44-6 ドメイン値マップ - 「ドメイン値の編集」

3. ダイアログで任意のフィールドを変更し、「OK」をクリックします。

44.4 ドメイン値マップ関数の使用

ドメイン値マップを作成した後は、実行時にドメイン値マップのXPath関数を使用して適切な値をルックアップし、アプリケーションにターゲットを移入できます。

44.4.1 ドメイン値マップ関数の理解

dvm:lookupValueおよびdvm:lookupValue1MのXPath関数は、実行時に単一の値または複数の値についてドメイン値マップをルックアップします。

44.4.1.1 dvm:lookupValue

dvm:lookupValue関数では、ソース列に指定のソース値を含むドメイン値マップでターゲット列の値をルックアップすることにより、文字列が返されます。

- 次のコードは、dvm:lookupValue関数の構文の例を示しています。

dvm:lookupValue(dvmMetadataURI as string, SourceColumnName as string,
SourceValue as string, TargetColumnName as string, DefaultValue as string) as
string

次のコードは、dvm:lookupValue関数の使用方法の例を示しています。

dvm:lookupValue('cityMap.dvm','CityCodes','BO', 'CityNames',
'CouldNotBeFound')

- 次のコードは、dvm:lookupValue関数の構文の別の例を示しています。

dvm:lookupValue(dvmMetadataURI as string, SourceColumnName as string,
SourceValue as string, TargetColumnName as string, DefaultValue as string,
(QualifierSourceColumn as string, QualifierSourceValue as string)*) as string

次のコードは、dvm:lookupValue関数の使用方法の別の例を示しています。

dvm:lookupValue ('cityMap.dvm','CityCodes','BO','CityNames',
'CouldNotBeFound', 'State', 'Massachusetts')

引数

- dvmMetadataURI - ドメイン値マップのURI。

- SourceColumnName - ソース列名。

- SourceValue - ソース値(XSLTトランスフォーメーションのソース文書にバインドされるXPath式)。

- targetColumnName - ターゲット列名。

- DefaultValue - 値が見つからない場合は、デフォルト値が返されます。

- QualifierSourceColumn: 修飾子列の名前。

- QualifierSourceValue: 修飾子の値。

44.4.1.2 dvm:lookupValue1M

dvm:lookupValue1M関数では、ソース列の値がソース値と等しいドメイン値マップの複数のターゲット列の値を格納する、XML文書フラグメントが返されます。次の例に詳細を示します。

dvm:lookupValue1M(dvmMetadataURI as string, SourceColumnName as string,
SourceValue as string,(TargetColumnName as string)?)as nodeset

引数

- dvmMetadataURI - ドメイン値マップのURI。

- SourceColumnName - ソース列名。

- SourceValue - ソース値(XSLTトランスフォーメーションのソース文書にバインドされるXPath式)。

- TargetColumnName - ターゲット列名。1つ以上の列名を指定する必要があります。疑問符記号(?)は複数のターゲット列名を指定できることを示します。

次の例は、dvm:lookupValue1M関数の使用方法の例を示しています。

dvm:lookupValue1M ('cityMap.dvm','CityCode','BO','CityName',
'CityNickName')

次の例に、結果を示します。

<CityName>Boston</CityName>
<CityNickName>BeanTown</CityNickName>

44.4.2 トランスフォーメーションでのドメイン値マップ関数の使用方法

ドメイン値マップ関数は、BPELプロセス・サービス・コンポーネントまたはメディエータ・サービス・コンポーネントによるトランスフォーメーションに使用できます。トランスフォーメーションの実行には、XSLファイルを作成してXMLスキーマ間でデータを変換するときに表示されるXSLTマッパーを使用します。

XSLTマッパーの詳細は、「XSLTマップ・エディタを使用したトランスフォーメーションの作成」を参照してください。

トランスフォーメーションでlookupValue1M関数を使用する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「XSLファイル」をダブルクリックして、XSLTマッパーを開きます。

2. XSLTマッパーで、「ソース」および「ターゲット」ペインのツリーを開きます。

3. 「コンポーネント」ウィンドウで下矢印をクリックして、「詳細」を選択します。

4. 図44-7 に示すように、「DVM関数」を選択します。

図44-7 「コンポーネント」ウィンドウのドメイン値マップ関数

5. ソースとターゲットの接続線にlookupValue1Mをドラッグ・アンド・ドロップします。
接続線上に「dvm:lookupValue1M」アイコンが表示されます。

6. 「lookupValue1M」アイコンをダブルクリックします。
図44-8 に示すように、「関数の編集 - lookupValue1M」ダイアログが表示されます。

図44-8 「関数の編集 – lookupValue1M」ダイアログ

7. 「関数の編集 – lookupValue1M」ダイアログの次のフィールドに値を指定します。

a. 「dvmLocation」フィールドで、ドメイン値マップ・ファイルのロケーションURIを入力するか、「dvmLocation」フィールドの右側にある「参照」をクリックして、ドメイン値マップ・ファイルを選択します。MDS(メタデータ・サービス)およびMDSの共有ロケーションからもすでにデプロイされたドメイン値マップを選択できます。これを実行するには、「リソース・パレット」を選択します。

b. 「sourceColumnName」フィールドに、ソース要素の値に関連付けられているドメイン値マップの列名を入力するか、「参照」をクリックして、以前に選択したドメイン値マップに定義されている列から列名を選択します。

c. 「sourceValue」フィールドでは、値を入力するか、[Ctrl]キーを押しながら[Space]キーを押してXPathビルディング・アシスタントを使用できます。上矢印キーおよび下矢印キーを押して、リスト内のオブジェクトを配置し、[Enter]キーを押してその項目を選択します。

d. 「targetColumnName」フィールドに、ターゲット要素の値に関連付けられているドメイン値マップの列名を入力するか、「参照」をクリックして、以前に選択したドメイン値マップに定義されている列から列名を選択します。

e. 「追加」をクリックして別の列をターゲット列として追加し、列の名前を入力します。

図44-9 に、移入後の「関数の編集 - lookupValue1M」ダイアログを示します。

図44-9 移入後の「関数の編集 – lookupValue1M」ダイアログ

8. 「OK」をクリックします。
XSLTマッパーが、「lookupValue1M」関数アイコンとともに表示されます。

9. 「ファイル」メニューで、「すべて保存」を選択します。

デプロイ済のドメイン値マップを選択する方法の詳細は、「での複数のSOAコンポジット・アプリケーション間の共有データのデプロイ方法および使用方法」を参照してください。

44.4.3 XPath式でのドメイン値マップ関数の使用方法

「式ビルダー」ダイアログでは、ドメイン値マップ関数を使用してXpath式を作成できます。「式ビルダー」ダイアログには、Oracle Mediatorサービス・コンポーネントのフィルタ式または値の割当て機能からアクセスできます。

値の割当て機能の詳細は、「値の割当て方法」を参照してください。

「式ビルダー」ダイアログでlookupValue関数を使用する手順は、次のとおりです。

1. 「関数」リストから「DVM関数」を選択します。

2. dvm:lookupValue関数をダブルクリックして、「式」フィールドに追加します。

3. lookupValue関数の様々な引数を指定します。次に例を示します。

dvm:lookupValue('citymap.dvm','CityCodes',$in.Customer/inp1:Customer/Address/Ci
ty,'CityNames','NotFound')

図44-10 にも示すように、この式では、都市コードと等価の都市名のドメイン値マップがルックアップされます。都市コードの値は実行時に指定された値によって異なります。

図44-10 「式ビルダー」ダイアログのドメイン値マップ関数

44.4.4 実行時の処理内容

実行時には、BPELプロセス・サービス・コンポーネントまたはメディエータ・サービス・コンポーネントが、ドメイン値マップを使用して適切な値をルックアップします。

44.5 階層ルックアップ用のドメイン値マップ・ユースケースの作成

この項では、SOAコンポジットでドメイン値マップを使用する場合のチュートリアルを紹介します。このユースケースは、ドメイン値マップの階層ルックアップ機能を示します。階層ルックアップのユースケースは次の手順で構成されます。

1. ReadOrdersという名前のアダプタ・サービスにより、ファイルがディレクトリから取得されます。

2. ReadOrdersアダプタ・サービスがファイル・データをProcessOrdersというメディエータに送信します。

3. 次にProcessOrdersメディエータはメッセージをアダプタ参照で必要となる構造に変換します。トランスフォーメーション中、メディエータは、UnitsOfMeasureドメイン値マップのCommonドメインの対応値をルックアップします。

4. ProcessOrdersメディエータは、WriteOrdersという外部参照にメッセージを送信します。

5. WriteOrders参照は、指定された出力ディレクトリにメッセージを書き込みます。

この項で説明するサンプル・ファイルをダウンロードするには、Oracle SOA Suiteサンプル・ページを参照してください。

44.5.1 HierarchicalValueユースケースの作成方法

この項では、SOAコンポジット・アプリケーションを作成、構築およびデプロイするための設計時タスクを説明します。これらのタスクは、表示されている順番で実行する必要があります。

44.5.1.1 タスク1: Oracle JDeveloperのアプリケーションおよびプロジェクトの作成方法

Oracle JDeveloperのアプリケーションおよびプロジェクトを作成する手順は、次のとおりです。

1. Oracle JDeveloperで「ファイル」をクリックし、「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「新規ギャラリ」で「一般」ノードを開き、「アプリケーション」カテゴリを選択します。

3. 「項目」リストで「SOAアプリケーション」を選択し、「OK」をクリックします。

SOAアプリケーションの作成ウィザードが表示されます。

4. 「アプリケーション名」フィールドにHierarchicalと入力し、「次へ」をクリックします。

「プロジェクトの名前付け」ページが表示されます。

5. 「プロジェクト名」フィールドにHierarchicalValueと入力し、「次へ」をクリックします。

「SOA設定の構成」ページが表示されます。

6. 「コンポジット・テンプレート」リストで「空のコンポジット」を選択し、「終了」をクリックします。

Oracle JDeveloperの「アプリケーション」ウィンドウには新規のアプリケーションおよびプロジェクトが移入され、SOAコンポジット・エディタには空白のコンポジットが含まれています。

7. 「ファイル」メニューから「すべて保存」を選択します。

44.5.1.2 タスク2: ドメイン値マップの作成方法

ユースケース用のアプリケーションおよびプロジェクトを作成した後は、ドメイン値マップを作成します。

ドメイン値マップを作成する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「HierarchicalValue」プロジェクトを右クリックして「新規」を選択します。

2. 「新規ギャラリ」ダイアログで「SOA層」ノードを開き、「トランスフォーメーション」カテゴリを選択します。

3. 「項目」リストで、「ドメイン値マップ(DVM)」を選択し、「OK」をクリックします。

「ドメイン値マップ(DVM)・ファイルの作成」ダイアログが表示されます。

4. 「ファイル名」フィールドに、UnitsOfMeasure.dvmと入力します。

5. 「ドメイン名」フィールドに、SiebelとCommonを入力します。

6. Siebelドメインに対応する「ドメイン値」フィールドに、Eaと入力します。

7. Commonドメインに対応する「ドメイン値」フィールドに、Eachと入力します。

8. 「OK」をクリックします。

ドメイン値マップ・エディタが表示されます。

9. 「追加」をクリックし、次に「列の追加」を選択します。

DVM列の作成ダイアログが表示されます。

10. 「名前」フィールドに、TradingPartnerと入力します。

11. 「修飾子」リストから「true」を選択します。

12. 「修飾子順」フィールドに1を入力し、「OK」をクリックします。

13. 手順9から手順12を繰り返して、StandardCodeという名前で修飾子の順序の値が2の修飾子をもう1つ作成します。

14. 「追加」をクリックし、「ドメイン値の追加」を選択します。

この手順を繰り返し、さらに2行追加します。

15. ドメイン値マップ表に新たに追加した行に、表44-6 に示す情報を入力します。

表44-6 ドメイン値マップ表の各行の情報

Siebel

共通

TradingPartner

StandardCode

EC

Each

OAG

E-RN

Each

A.C.Networks

RN

EO

Each

ABC Inc

RN

図44-11 に示すように、ドメイン値マップ・エディタが表示されます。

図44-11 UnitsOfMeasureのドメイン値マップ

16. 「ファイル」メニューから「すべて保存」を選択して、ドメイン値マップ・エディタを閉じます。

44.5.1.3 タスク3: ファイル・アダプタ・サービスの作成方法

ドメイン値マップを作成した後は、ディレクトリからXMLファイルを読み取るReadOrdersという名前のファイル・アダプタ・サービスを作成します。

注意:

Oracle Mediatorは、Oracle Real Application Clusters (Oracle RAC)の計画的停止に対して実行する際、同じファイルを2回処理する可能性があります。これは、ファイル・アダプタがXAに準拠していないアダプタであるためです。したがって、グローバル・トランザクションに組み入れると、各ファイルを1回のみ処理するXAインタフェース仕様に逸脱する可能性があります。

ファイル・アダプタ・サービスを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「ファイル・アダプタ」を選択し、「公開されたサービス」スイムレーンにドラッグします。

3. アダプタ構成ウィザードの「ようこそ」ページが開いた場合は、「次へ」をクリックします。

サービス名ページが表示されます。

4. 「サービス名」フィールドにReadOrdersと入力し、「次へ」をクリックします。

「操作」ページが表示されます。

5. 「操作タイプ」フィールドで「Read File」を選択し、「次へ」をクリックします。

「ファイル・ディレクトリ」ページが表示されます。

6. 「着信ファイル用のディレクトリ(物理パス)」フィールドに、ファイルの読取り先のディレクトリを入力します。

7. 「次へ」をクリックします。

「ファイルのフィルタ処理」ページが表示されます。

8. 「インクルード・ファイルの名前パターン」フィールドに*.xmlと入力し、「次へ」をクリックします。

「ファイル・ポーリング」ページが表示されます。

9. 「ポーリング頻度」フィールドの値を10秒に変更し、「次へ」をクリックします。

「メッセージ」ページが表示されます。

10. 「検索」をクリックします。

「タイプ・チューザ」ダイアログが表示されます。

11. 「スキーマ・ファイルのインポート」をクリックします。

「スキーマ・ファイルのインポート」ダイアログが表示されます。

12. 「検索」をクリックして、Samplesフォルダに存在するOrder.xsdファイルを選択します。

13. 「OK」をクリックします。

14. 「タイプ・エクスプローラ」→「インポートしたスキーマ」→「Order.xsd」の順にナビゲーション・ツリーを開きます。

15. 「listOfOrder」を選択して、「OK」をクリックします。

16. 「次へ」をクリックします。

終了ページが表示されます。

17. 「終了」をクリックします。

18. 「ファイル」メニューから「すべて保存」をクリックします。

図44-12 に、のReadOrdersサービスを示します。

図44-12 のReadOrdersサービス

44.5.1.4 タスク4: ProcessOrdersメディエータ・コンポーネントの作成方法

ProcessOrdersという名前のメディエータを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウから「メディエータ」アイコンをドラッグし、SOAコンポジット・エディタの「コンポーネント」セクションにドロップします。

「メディエータの作成」ダイアログが表示されます。

2. 「名前」フィールドに、ProcessOrdersと入力します。

3. 「テンプレート」リストから、「インタフェースを後で定義」を選択します。

4. 「OK」をクリックします。

ProcessOrdersという名前のメディエータが作成されます。

5. 図44-13 に示すように、で、「ReadOrders」サービスを「ProcessOrders」Oracle Mediatorに接続します。

この操作により、ファイルを入力ディレクトリから読み込む間に、ProcessOrdersメディエータを起動するファイル・アダプタ・サービスが指定されます。

図44-13 ReadOrdersサービスからProcessOrdersメディエータへの接続

6. 「ファイル」メニューから「すべて保存」を選択します。

44.5.1.5 タスク5: ファイル・アダプタ参照の作成方法

ファイル・アダプタ参照を作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「ファイル・アダプタ」を選択し、「外部参照」スイムレーンにドラッグします。

「アダプタ構成ウィザード」の「ようこそ」ページが表示されます。

3. 「次へ」をクリックします。

サービス名ページが表示されます。

4. 「サービス名」フィールドに、WriteCommonOrderと入力します。

5. 「次へ」をクリックします。

「操作」ページが表示されます。

6. 「操作タイプ」フィールドで、「Write File」を選択します。

7. 「次へ」をクリックします。

「ファイル構成」ページが表示されます。

8. 「発信ファイルのディレクトリ(物理パス)」フィールドに、ファイルを書き込むディレクトリの名前を入力します。

9. ファイル・ネーミング規則フィールドにcommon_order_%SEQ%.xmlと入力して、「次へ」をクリックします。

「メッセージ」ページが表示されます。

10. 「検索」をクリックします。

「タイプ・チューザ」ダイアログが表示されます。

11. 「タイプ・エクスプローラ」→「プロジェクトのスキーマ・ファイル」→「Order.xsd」の順に移動し、「listOfOrder」を選択します。

12. 「OK」をクリックします。

13. 「次へ」をクリックします。

終了ページが表示されます。

14. 「終了」をクリックします。

図44-14 に、のWriteCommonOrder参照を示します。

図44-14 のWriteCommonOrder参照

15. 「ファイル」メニューから「すべて保存」を選択します。

44.5.1.6 タスク6: ルーティング・ルールの指定方法

メッセージが経由するReadOrdersアダプタ・サービスから外部参照へのパスを指定する必要があります。

ルーティング・ルールを指定する手順は、次のとおりです。

1. 図44-15 に示すように、「ProcessOrders」Oracle Mediatorを「WriteCommonOrder」参照に接続します。

図44-15 ProcessOrdersメディエータからWriteCommonOrder参照への接続

2. 「ProcessOrders」Oracle Mediatorをダブルクリックします。

3. 「次を使用して変換」フィールドの右側にあるアイコンをクリックします。

「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

4. 「新規マッパー・ファイルの作成」を選択し、「OK」をクリックします。

XSLTマッパーに、「listOfOrder_To_listOfOrder.xsl」ファイルが表示されます。

5. 「imp1:listOfOrder」ソース要素を「imp1:listOfOrder」ターゲット要素にドラッグ・アンド・ドロップします。

「自動マップ・プリファレンス」ダイアログが表示されます。

6. 「自動マップ中」オプションから、「祖先名を考慮した要素の一致」の選択を解除します。

7. 「OK」をクリックします。

図44-16 に示すように、「listOfOrder_To_listOfOrder.xsl」ファイルが表示されます。

図44-16 imp1:listOfOrderからimp1:listOfOrderへのトランスフォーメーション

8. 「コンポーネント」ウィンドウで、「詳細」を選択します。

9. 「DVM関数」をクリックします。

10. 図44-17 に示すように、lookupValueをunitsOfMeasure要素の接続線にドラッグ・アンド・ドロップします。

図44-17 imp1:listOfOrderからimp1:listOfOrder.xslへのlookupValue関数の追加

11. 「lookupvalue」アイコンをダブルクリックします。

「関数の編集 - lookupValue」ダイアログが表示されます。

12. 「dvmLocation」フィールドの右側にある「検索」をクリックします。

「SOAリソース・ルックアップ」ダイアログが表示されます。

13. 「UnitsofMeasure.dvm」を選択して、「OK」をクリックします。

14. 「sourceColumnName」フィールドの右側にある「検索」をクリックします。

DVM列の選択ダイアログが表示されます。

15. 「Siebel」を選択して、「OK」をクリックします。

16. 「sourceValue」列に、次の値を入力します。

/imp1:listOfOrder/imp1:order/imp1:baseData/imp1:unitOfMeasure

17. 「targetColumnName」フィールドの右側にある「検索」をクリックします。

DVM列の選択ダイアログが表示されます。

18. 「Common」を選択して、「OK」をクリックします。

19. 「defaultValue」フィールドに"No_Value_Found"と入力します。

20. 「追加」をクリックします。

「qualifierColumnName」行が追加されます。

21. 「qualifierColumnName」フィールドに"StandardCode"と入力します。

22. 「追加」をクリックします。

「qualifierValue」行が追加されます。

23. 「qualifierValue」フィールドに、次の値を入力します。

/imp1:listOfOrder/imp1:order/imp1:baseData/imp1:standard

24. 「追加」をクリックして、別の「qualifierColumnName」行を挿入します。

25. 「qualifierColumnName」フィールドに"TradingPartner"と入力します。

26. 「追加」をクリックして、別の「qualifierValue」行を挿入します。

27. 「qualifierValue」フィールドに、次の値を入力します。

/imp1:listOfOrder/imp1:order/imp1:baseData/imp1:tp

図44-18 に示すように、「関数の編集 - lookupValue」ダイアログが表示されます。

図44-18 「関数の編集 - lookupValue関数」ダイアログ: 階層ルックアップ・ユースケース

28. 「OK」をクリックします。

図44-19 に示すように、トランスフォーメーションが表示されます。

図44-19 imp1:listOfOrderからimp1:listOfOrderへのトランスフォーメーションの完了

29. 「ファイル」メニューから「すべて保存」を選択して、上部にある「listOfOrder_To_listOfOrder.xsl」ファイルを閉じます。

44.5.1.7 タスク7: アプリケーション・サーバー接続の構成方法

SOAコンポジット・アプリケーションをデプロイするには、アプリケーション・サーバー接続が必要です。アプリケーション・サーバー接続の作成方法の詳細は、「アプリケーション・サーバー接続の作成」を参照してください。

44.5.1.8 タスク8: コンポジット・アプリケーションのデプロイ方法

次の手順で、HierarchicalValueコンポジット・アプリケーションをアプリケーション・サーバーにデプロイします。

- アプリケーション・デプロイメント・プロファイルの作成

- アプリケーション・サーバーへのアプリケーションのデプロイ

これらの手順の詳細は、「単一のSOAコンポジットのデプロイ方法」を参照してください。

44.5.2 HierarchicalValueアプリケーションの実行方法と監視方法

デプロイしたHierarchicalValueアプリケーションは、入力XMLファイルであるsampleorder.xmlを入力フォルダにコピーすることで実行できます。このファイルはsamplesフォルダにあります。正常終了した場合、common_order_1.xmlという名前のファイルが、指定された出力ディレクトリに作成されます。

実行中のインスタンスの監視には、次のURLにあるOracle Enterprise Manager Fusion Middleware Controlを使用できます。

http://hostname:port/em

ここで、hostnameは、Oracle SOA Suiteインフラストラクチャをインストールしたホストです。

これらの手順の詳細は、「単一のSOAコンポジットのデプロイ方法」を参照してください。

44.6 複数の値のドメイン値マップ・ユースケースの作成

この項では、ルックアップ用の複数の値を持つドメイン値マップを作成する方法のチュートリアルを紹介します。このユースケースは、複数の値をルックアップするために、2つのエンドポイント間でドメイン値マップ・ルックアップを使用する統合シナリオを示します。たとえば、インバウンド値が州の場合、アウトバウンド値は州の略称、言語および首都になります。複数の値ルックアップのユースケースは次の手順で構成されます。

1. readFileという名前のアダプタ・サービスにより、ファイルがディレクトリから取得されます。

2. readFileアダプタ・サービスがファイル・データをLookupMultiplevaluesMediatorというOracle Mediatorに送信します。

3. 次にLookupMultiplevaluesMediator Oracle Mediatorはメッセージをアダプタ参照で必要となる構造に変換します。トランスフォーメーション中、Oracle MediatorはLongnameおよびShortnameドメインの等価値に対するmultivalueドメイン値マップをルックアップします。

4. LookupMultiplevaluesMediator Oracle Mediatorは、writeFileという外部参照にメッセージを送信します。

5. writeFile参照は、指定された出力ディレクトリにメッセージを書き込みます。

この項で説明するサンプル・ファイルをダウンロードするには、Oracle SOA Suiteサンプル・ページを参照してください。

44.6.1 Multivalueユースケースの作成方法

この項では、SOAコンポジット・アプリケーションを作成、構築およびデプロイするための設計時タスクを説明します。これらのタスクは、表示されている順番で実行します。

44.6.1.1 タスク1: Oracle JDeveloperのアプリケーションおよびプロジェクトの作成方法

Oracle JDeveloperのアプリケーションおよびプロジェクトを作成する手順は、次のとおりです。

1. Oracle JDeveloperで「ファイル」をクリックし、「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「新規ギャラリ」で「一般」ノードを開き、「アプリケーション」カテゴリを選択します。

3. 「項目」リストで「SOAアプリケーション」を選択し、「OK」をクリックします。

SOAアプリケーションの作成ウィザードが表示されます。

4. 「アプリケーション名」フィールドにMultivalueと入力し、「次へ」をクリックします。

「プロジェクトの名前付け」ページが表示されます。

5. 「プロジェクト名」フィールドにMultivalueと入力し、「次へ」をクリックします。

「SOA設定の構成」ページが表示されます。

6. 「コンポジット・テンプレート」リストから「空のコンポジット」を選択し、「終了」をクリックします。

Oracle JDeveloperの「アプリケーション」ウィンドウには新規のアプリケーションおよびプロジェクトが移入され、SOAコンポジット・エディタには空白のコンポジットが含まれています。

7. 「ファイル」メニューから「すべて保存」を選択します。

44.6.1.2 タスク2: ドメイン値マップの作成方法

ユースケース用のアプリケーションおよびプロジェクトを作成した後は、ドメイン値マップを作成します。

ドメイン値マップを作成する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「Multivalue」プロジェクトを右クリックして「新規」を選択します。

2. 「新規ギャラリ」ダイアログで「SOA層」ノードを開き、「トランスフォーメーション」カテゴリを選択します。

3. 「項目」リストで、「ドメイン値マップ(DVM)」を選択し、「OK」をクリックします。

「ドメイン値マップ(DVM)・ファイルの作成」ダイアログが表示されます。

4. 「ファイル名」フィールドに、multivalue.dvmと入力します。

5. 「ドメイン名」フィールドに、Longname、Shortname、LanguageおよびCapitalを入力します。

6. Longnameドメインに対応する「ドメイン値」フィールドに、Karnatakaと入力します。

7. Shortnameドメインに対応する「ドメイン値」フィールドに、KAと入力します。

8. Languageドメインに対応する「ドメイン値」フィールドに、Kannadaと入力します。

9. Capitalドメインに対応する「ドメイン値」フィールドに、Bangaloreと入力します。

10. 「OK」をクリックします。

ドメイン値マップ・エディタが表示されます。

11. 「追加」をクリックし、次に「行の追加」を選択します。

この手順を繰り返し、さらに2行追加します。

12. ドメイン値マップ表に新たに追加した行に、表44-7 に示す情報を入力します。

表44-7 ドメイン値マップ表の各行の情報

Longname

Shortname

言語

Capital

Karnataka

KA

Kannada

Bangalore

Tamilnadu

TN

Tamil

Chennai

Andhrapradesh

AP

Telugu

Hyderbad

Kerala

KL

Malayalam

Trivandram

図44-20 に示すように、ドメイン値マップ・エディタが表示されます。

図44-20 Multivalueのドメイン値マップ

13. 「ファイル」メニューから「すべて保存」を選択して、ドメイン値マップ・エディタを閉じます。

44.6.1.3 タスク3: ファイル・アダプタ・サービスの作成方法

ドメイン値マップを作成した後は、ディレクトリからXMLファイルを読み取るreadFileという名前のファイル・アダプタ・サービスを作成します。

注意:

メディエータは、Oracle RACの計画的停止に対して実行する際、同じファイルを2回処理する可能性があります。これは、ファイル・アダプタがXAに準拠していないアダプタであるためです。したがって、グローバル・トランザクションに組み入れると、各ファイルを1回のみ処理するXAインタフェース仕様に逸脱する可能性があります。

ファイル・アダプタ・サービスを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「ファイル・アダプタ」を選択し、「公開されたサービス」スイムレーンにドラッグします。

3. アダプタ構成ウィザードの「ようこそ」ページが開いた場合は、「次へ」をクリックします。

サービス名ページが表示されます。

4. 「サービス名」フィールドにreadFileと入力し、「次へ」をクリックします。

「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」をクリックし、「次へ」をクリックします。

「操作」ページが表示されます。

6. 「操作タイプ」フィールドで「Read File」を選択し、「次へ」をクリックします。

「ファイル・ディレクトリ」ページが表示されます。

7. 「着信ファイル用のディレクトリ(物理パス)」フィールドに、ファイルの読取り先のディレクトリを入力します。

8. 「次へ」をクリックします。

「ファイルのフィルタ処理」ページが表示されます。

9. 「インクルード・ファイルの名前パターン」フィールドに*.xmlと入力し、「次へ」をクリックします。

「ファイル・ポーリング」ページが表示されます。

10. 「ポーリング頻度」フィールドの値を1秒に変更し、「次へ」をクリックします。

「メッセージ」ページが表示されます。

11. 「検索」をクリックします。

「タイプ・チューザ」ダイアログが表示されます。

12. 「スキーマ・ファイルのインポート」をクリックします。

「スキーマ・ファイルのインポート」ダイアログが表示されます。

13. 「検索」をクリックして、「サンプル」フォルダに存在するinput.xsdファイルを選択します。

14. 「OK」をクリックします。

15. 「タイプ・エクスプローラ」→「インポートしたスキーマ」→「input.xsd」の順にナビゲーション・ツリーを開きます。

16. 「Root-Element」を選択して、「OK」をクリックします。

17. 「次へ」をクリックします。

終了ページが表示されます。

18. 「終了」をクリックします。

19. 「ファイル」メニューから「すべて保存」を選択します。

図44-21 に、のreadFileサービスを示します。

図44-21 のreadFileサービス

44.6.1.4 タスク4: LookupMultiplevaluesMediatorメディエータの作成方法

LookupMultiplevaluesMediatorメディエータを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウから「メディエータ」アイコンをドラッグし、SOAコンポジット・エディタの「コンポーネント」セクションにドロップします。

「メディエータの作成」ダイアログが表示されます。

2. 「名前」フィールドに、LookupMultiplevaluesMediatorと入力します。

3. 「テンプレート」リストから、「インタフェースを後で定義」を選択します。

4. 「OK」をクリックします。

LookupMultiplevaluesMediatorという名前のOracle Mediatorが作成されます。

5. 図44-22 に示すように、で、「readFile」サービスを「LookupMultiplevaluesMediator」Oracle Mediatorに接続します。

この操作により、ファイルを入力ディレクトリから読み込む間に、LookupMultiplevaluesMediator Oracle Mediatorを起動するファイル・アダプタ・サービスが指定されます。

図44-22 readFileサービスからLookupMultiplevaluesMediatorメディエータへの接続

6. 「ファイル」メニューから「すべて保存」を選択します。

44.6.1.5 タスク5: ファイル・アダプタ参照の作成方法

ファイル・アダプタ参照を作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「ファイル・アダプタ」を選択し、「外部参照」スイムレーンにドラッグします。

「アダプタ構成ウィザード」の「ようこそ」ページが表示されます。

3. 「次へ」をクリックします。

サービス名ページが表示されます。

4. 「サービス名」フィールドにwriteFileと入力し、「次へ」をクリックします。

「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」をクリックし、「次へ」をクリックします。

「操作」ページが表示されます。

6. 「次へ」をクリックします。

「操作」ページが表示されます。

7. 「操作タイプ」フィールドで、「Write File」を選択します。

8. 「次へ」をクリックします。

「ファイル構成」ページが表示されます。

9. 「発信ファイルのディレクトリ(物理パス)」フィールドに、ファイルを書き込むディレクトリの名前を入力します。

10. ファイル・ネーミング規則フィールドにmultivalue_%SEQ%.xmlと入力して、「次へ」をクリックします。

「メッセージ」ページが表示されます。

11. 「検索」をクリックします。

「タイプ・チューザ」ダイアログが表示されます。

12. 「タイプ・エクスプローラ」→「プロジェクトのスキーマ・ファイル」→「output.xsd」の順に移動し、「Root-Element」を選択します。

13. 「OK」をクリックします。

14. 「次へ」をクリックします。

終了ページが表示されます。

15. 「終了」をクリックします。

図44-23 に、のwriteFile参照を示します。

図44-23 のwriteFile参照

16. 「ファイル」メニューから「すべて保存」を選択します。

44.6.1.6 タスク6: ルーティング・ルールの指定方法

メッセージが経由するreadFileアダプタ・サービスから外部参照へのパスを指定する必要があります。

ルーティング・ルールを指定する手順は、次のとおりです。

1. 図44-24 に示すように、「LookupMultiplevaluesMediator」メディエータを「writeFile」参照に接続します。

図44-24 LookupMultiplevaluesMediatorメディエータからwriteFile参照への接続

2. 「LookupMultiplevaluesMediator」メディエータをダブルクリックします。

3. 「次を使用して変換」フィールドの右側にあるアイコンをクリックします。

「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

4. 「新規マッパー・ファイルの作成」を選択し、「OK」をクリックします。

XSLTマッパーに、「Input_To_Output_with_multiple_values_lookup.xsl」ファイルが表示されます。

5. 「imp1:Root-Element」ソース要素を「ns2:Root-Element」ターゲット要素にドラッグ・アンド・ドロップします。

「自動マップ・プリファレンス」ダイアログが表示されます。

6. 「自動マップ中」オプション・リストから、「祖先名を考慮した要素の一致」の選択を解除します。

7. 「OK」をクリックします。

図44-25 に示すように、XSLTマッパーに「Input_To_Output_with_multiple_values_lookup.xsl」ファイルが表示されます。

図44-25 imp1:Root-Elementからns2:Root-Elementへのトランスフォーメーション

8. 「コンポーネント」ウィンドウで、「詳細」を選択します。

9. 「DVM関数」をクリックします。

10. 図44-26 に示すように、lookupValue1Mを中央のパネルにドラッグ・アンド・ドロップします。

図44-26 imp1:Root-Elementからns2:Root-ElementへのlookupValue関数の追加

11. 「lookupvalue1M」アイコンをダブルクリックします。

「関数の編集 - lookupValue1M」ダイアログが表示されます。

12. 「dvmLocation」フィールドの右側にある「検索」をクリックします。

「SOAリソース・ルックアップ」ダイアログが表示されます。

13. 「multivalue.dvm」を選択して、「OK」をクリックします。

14. 「sourceColumnName」フィールドの右側にある「検索」をクリックします。

DVM列の選択ダイアログが表示されます。

15. 「Longname」を選択して、「OK」をクリックします。

16. 「sourceValue」列に、次の値を入力します。

/imp1:Root-Element/imp1:Details/imp1:Longname

17. 「targetColumnName」フィールドの右側にある「検索」をクリックします。

DVM列の選択ダイアログが表示されます。

18. 「Shortname」を選択して、「OK」をクリックします。

19. 「追加」をクリックします。

「targetColumnName」行が追加されます。

20. 「targetColumnName」フィールドに、"Language"と入力します。

21. 「追加」をクリックして、別の「targetColumnName」行を挿入します。

22. 「targetColumnName」フィールドに、"Capital"と入力します。

図44-27 に示すように、「関数の編集 - lookupValue」ダイアログが表示されます。

図44-27 「関数の編集 - lookupValue関数」ダイアログ: 複数の値ルックアップ・ユースケース

23. 「OK」をクリックします。

図44-28 に示すように、トランスフォーメーションが表示されます。

図44-28 imp1:Root-Elementからns2:Root-Elementへのトランスフォーメーションの完了

24. 「ファイル」メニューから「すべて保存」を選択して、「Input_To_Output_with_multiple_values_lookup.xsl」ファイルを閉じます。

44.6.1.7 タスク7: アプリケーション・サーバー接続の構成方法

SOAコンポジット・アプリケーションをデプロイするには、アプリケーション・サーバー接続が必要です。アプリケーション・サーバー接続の作成方法の詳細は、「アプリケーション・サーバー接続の作成」を参照してください。

44.6.1.8 タスク8: コンポジット・アプリケーションのデプロイ方法

次の手順で、Multivalueコンポジット・アプリケーションをアプリケーション・サーバーにデプロイします。

- アプリケーション・デプロイメント・プロファイルの作成

- アプリケーション・サーバーへのアプリケーションのデプロイ

これらの手順の詳細は、「単一のSOAコンポジットのデプロイ方法」を参照してください。

44.6.2 Multivalueアプリケーションの実行方法と監視方法

デプロイしたMultivalueアプリケーションは、入力XMLファイルであるsampleinput.xmlを入力フォルダにコピーすることで実行できます。このファイルはsamplesフォルダにあります。正常終了した場合、multivalue_1.xmlという名前のファイルが、指定された出力ディレクトリに作成されます。

実行中のインスタンスの監視には、次のURLにあるOracle Enterprise Manager Fusion Middleware Controlを使用できます。

http://hostname:port/em

ここで、hostnameは、Oracle SOA Suiteインフラストラクチャをインストールしたホストです。

Oracle Enterprise Manager Fusion Middleware ControlでMultivalueをクリックすると、プロジェクト・ダッシュボードが表示されます。

詳細な実行証跡を表示するには、インスタンス列のインスタンスIDをクリックします。「フローのトレース」ページが表示されます。

44.7 初回使用を高速化するためのDVMキャッシュの事前ロード

DVMを初めて呼び出して使用するときに、DVMはMDSからキャッシュにロードされます。以後、DVMはキャッシュから取り出されるので、ルックアップが高速になります。

DVMに多数のレコードが含まれている場合は、サーバーの起動時にDVMをキャッシュにあらかじめロードしておけば、初回使用時にもDVMがすぐに使用可能になります。

サーバー起動時のDVMキャッシュの事前ロードを選択するには、Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザ内で、MBeanプロパティLoadDVMsAtStartupを使用します。LoadDVMsAtStartupをtrueに設定すると、サーバーの起動時にすべてのDVMがキャッシュにロードされます。LoadDVMsAtStartupのデフォルト値はfalseです。

44.7.1 サーバー起動時のDVMキャッシュの事前ロード方法

サーバーの起動時にDVMキャッシュの事前ロードを行う手順は、次のとおりです。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 「SOAインフラストラクチャ」メニューから、「SOA管理」→「共通プロパティ」の順に選択します。

3. 「SOAインフラストラクチャの共通プロパティ」ページの下部で、「詳細SOAインフラ拡張構成プロパティ」をクリックします。

4. 「LoadDVMsAtStartup」をクリックします。

5. 「値」フィールドで、「true」を選択します。

6. 「適用」をクリックします。

7. 「戻る」をクリックします。

45 ドメイン値マップでのOracle SOAコンポーザの使用

この章では、Oracle SOAコンポーザを使用して実行時にOracle SOA Suiteプロジェクトのドメイン値マップを変更する方法について説明します。ドメイン値マップを使用すると、特定のドメインで使用されているある用語を、異なるドメインで使用されている別の用語にマップできます。

以前のリリースでは、実行時のドメイン値マップを編集するには、最初にOracle JDeveloperで変更を加えた後に、そのドメイン値マップをアプリケーション・サーバーに再デプロイする必要がありました。現在は、Oracle SOAコンポーザによって、実行時のドメイン値マップを編集するためのサポートが提供されています。

この章の内容は次のとおりです。

- Oracle SOAコンポーザの概要

- 実行時のドメイン値マップの表示

- 実行時のドメイン値マップの編集

- 実行時の変更内容のパブリッシュ

- 競合の検出

ドメイン値マップの詳細は、「ドメイン値マップの使用」を参照してください。

45.1 Oracle SOAコンポーザの概要

Oracle SOAコンポーザは、Oracle SOA Suiteインストールの一部としてインストールされるEARファイルです。Oracle SOAコンポーザを使用すると、ドメイン値マップを使用するプロジェクトを再デプロイすることなく、実行時にデプロイされたドメイン値マップを管理できます。ドメイン値マップのメタデータは、1つのSOAコンポジット・アプリケーションに関連付けたり、複数のコンポジット・アプリケーション間で共有することもできます。図45-1 は、Oracle SOAコンポーザを使用してメタデータ・サービス(MDS)リポジトリからドメイン値マップにアクセスする方法を示しています。

図45-1 Oracle SOAコンポーザの高レベルなデプロイメント・トポロジ

45.1.1 Oracle SOAコンポーザへのログイン方法

Oracle SOAコンポーザにログインする手順は、次のとおりです。

1. Webブラウザに次のURLを入力します。

http://hostname:port/soa/composer

図45-2 に示すように、Oracle SOAコンポーザのログイン・ページが表示されます。

図45-2 Oracle SOAコンポーザのログイン・ページ

2. 「ユーザー名」フィールドに、ユーザー名を入力します。

3. 「パスワード」フィールドに、パスワードを入力します。

4. 「ログイン」をクリックします。

Oracle SOAコンポーザにログインすると、図45-3 に示すように、Oracle SOAコンポーザのホームページが表示されます。

図45-3 Oracle SOAコンポーザのホームページ

Oracle SOAコンポーザのメタデータにアクセスするには、SOADesignerアプリケーション・ロールが必要です。このロールは、デフォルトで、Oracle Enterprise Manager Fusion Middleware Controlの管理者権限があるすべてのユーザーに付与されます。このロールが付与されていないユーザーがOracle SOAコンポーザにログインすると、次のメッセージが表示されます。

Currently logged in user is not authorized to modify SOA metadata.

管理者権限を持たないユーザーにSOADesignerアプリケーション・ロールを追加する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

45.2 実行時のドメイン値マップの表示

実行時のドメイン値マップを表示できます。ドメイン値マップを開いて表示するには、次の手順を実行します。

45.2.1 実行時のドメイン値マップの表示方法

実行時のドメイン値マップを表示する手順は、次のとおりです。

1. 左側の「アプリケーション」ウィンドウ・パネルで「タイプ・ビュー」を選択します。

2. 「ドメイン値マップ」フォルダの前にある右矢印のアイコンをクリックして、このフォルダを展開します。

3. 表示または編集するドメイン値マップ・ファイル(.dvm)を選択します。

4. 「開く」アイコンをクリックしてドメイン値マップを開きます。

5. 「開く」メニューから「DVMを開く」を選択します。DVMの詳細がビュー・モードで表示されます。

図45-4 は、SOAコンポーザのドメイン値マップのサンプルを示しています。

図45-4 SOAコンポーザでのドメイン値マップの表示

注意:

選択したドメイン値マップへの直接リンクを取得するには、「ブックマーク」をクリックします。

45.3 実行時のドメイン値マップの編集

ドメイン値マップを使用するアプリケーションの実行中に、ドメイン値マップを編集できます。

注意:

SOAコンポーザを使用してDVMを更新する場合は、更新されたDVMを使用してDVMキャッシュも更新されます。

45.3.1 実行時のドメイン値マップの編集方法

デフォルトでは、ドメイン値マップはビュー・モードで開きます。編集モードに変更すると、行の情報を変更できるようになります。変更を終了したときは、「実行時の変更内容のパブリッシュ」で説明されているように、変更内容を必ず保存し、コミットしてください。

45.3.1.1 編集モードへの変更

編集モードに変更する手順は、次のとおりです。

1. 「実行時のドメイン値マップの表示方法」の説明に従って、表示するドメイン値マップを開きます。

2. 「SOAコンポーザ」ウィンドウの右上のセクションにある「セッションの作成」をクリックします。以前にアクティブだったセッションがある場合は、「セッションの編集」をクリックする必要があります。

ドメイン値マップが編集モードで開きます。

45.3.1.2 行の追加

行を追加する手順は、次のとおりです。

行を追加する手順は、次のとおりです。

1. 「ドメイン値の追加」をクリックします。

「ドメイン値の追加」ダイアログが表示されます。

2. 値を入力し、「OK」をクリックします。

入力した値がドメイン値マップに追加されます。

3. SOAコンポーザの右上のセクションにある「保存」をクリックします。

45.3.1.3 行の編集

行を編集する手順は、次のとおりです。

行を編集する手順は、次のとおりです。

1. 編集する行を選択します。

2. 「ドメイン値の編集」をクリックします。

「ドメイン値の編集」ダイアログが表示されます。

3. 必要に応じて値を編集し、「OK」をクリックします。

4. SOAコンポーザの右上のセクションにある「保存」をクリックします。

45.3.1.4 行の削除

行を削除する手順は、次のとおりです。

行を削除する手順は、次のとおりです。

1. 削除する行を選択します。

2. 「ドメイン値の削除」をクリックします。

3. SOAコンポーザの右上のセクションにある「保存」をクリックします。

45.4 実行時の変更内容のパブリッシュ

編集セッションでドメイン値マップを開くたびに、各ユーザーのドメイン値マップごとにサンドボックスが1つ作成されます。変更内容を保存すると、そのサンドボックスに変更内容が保存されます。

変更内容をランタイムに反映してMDSリポジトリに永続的に保存するには、変更内容をパブリッシュする必要があります。セッションでは、変更内容をパブリッシュせずに保存することもできます。その場合、ドメイン値マップは保存済の状態のままです。後でドメイン値マップを再度開いて変更内容をパブリッシュできます。

45.4.1 実行時に変更内容をパブリッシュする方法

実行時に変更内容をパブリッシュする手順は、次のとおりです。

1. SOAコンポーザの右上のセクションにある「パブリッシュ」をクリックします。確認のダイアログが表示されます。

2. セッション内で行った変更に関するオプションの説明を入力します。「OK」をクリックします。

45.4.2 実行時に変更内容を破棄する方法

セッション中にDVMに対して行った変更を破棄することもできます。

実行時に変更内容を破棄する手順は、次のとおりです。

1. SOAコンポーザの右上のセクションにある「破棄」をクリックします。確認のダイアログが表示されます。

2. セッション中に行った変更内容を破棄するには、「OK」をクリックします。これには、サンドボックスに保存した変更内容も含まれます。

45.5 競合の検出

Oracle SOAコンポーザは、同時ユーザー間で発生する可能性のある競合を検出します。別のユーザーが編集しているドメイン値マップを開くと、編集を続行するかどうか確認するダイアログが表示されます。

ドメイン値マップの編集を続行する場合は、「はい」をクリックして変更を加えることができます。

他のユーザーがそのドメイン値マップを変更してコミットした場合は、自分の変更内容をコミットしようとすると通知メッセージが表示されます。

「はい」をクリックして変更内容をコミットすると、他のユーザーが加えた変更が上書きされます。

第VIII部 アプリケーションの完成

この部では、アプリケーションの設計を完成する方法について説明します。

この部は、次の章で構成されています。

- ポリシーおよびメッセージ暗号化を使用したセキュリティの有効化

- SOAコンポジット・アプリケーションのデプロイ

- Oracle SOA Suite開発Mavenプラグインの使用

- SOAコンポジット・アプリケーションのデバッグおよび監査

- SOAコンポジット・アプリケーションのテストの自動化

46 ポリシーおよびメッセージ暗号化を使用したセキュリティの有効化

この章では、SOAコンポジット・アプリケーション内で設計時にバインディング・コンポーネントとサービス・コンポーネントにポリシーを添付する方法、およびメッセージの特定のフィールドを暗号化および復号化する方法を説明します。ポリシーはメッセージの配信にセキュリティを適用します。この章では、ポリシー構成プロパティ値のオーバーライド方法についても説明します。

この章の内容は次のとおりです。

- ポリシーの概要

- バインディング・コンポーネントおよびサービス・コンポーネントへのポリシーの添付

- メッセージの特定フィールドの暗号化と復号化

46.1 ポリシーの概要

Oracle Fusion Middlewareは、ポリシー・ベースのモデルを使用して、組織全体のWebサービスを管理および保護します。ポリシーはメッセージの配信にセキュリティを適用します。ポリシーは、開発者が設計時環境で管理することも、システム管理者が実行時環境で管理することもできます。

ポリシーは、1つ以上のアサーションで構成されています。1つのポリシー・アサーションが、特定のアクションを実行するポリシーの最小単位となります。ポリシー・アサーションはリクエスト・メッセージとレスポンス・メッセージで実行され、どちらのタイプのメッセージでも同じアサーション・セットが実行されます。アサーションは、それらがポリシーに表示される順序で実行されます。

表46-1 に、サポートされるポリシー・カテゴリを示します。

表46-1 サポートされるポリシー・カテゴリ

カテゴリ

説明

メッセージ送信最適化メカニズム(MTOM)

添付ファイルがMTOM形式であることを保証します。この形式を使用することで、バイナリ・データをWebサービスとの間で送受信できます。これによりワイヤ上の伝送サイズが削減されます。

信頼性

WS-Reliable Messagingプロトコルをサポートします。これにより、メッセージのエンドツーエンドの配信を保証します。

アドレッシング

Simple Object Access Protocol (SOAP)メッセージに、WS-Addressing仕様に準拠したWS-Addressingヘッダーが含まれていることを検証します。トランスポート・レベル・データは、この情報を渡すためにネットワーク・レベル・トランスポートに依存するのではなく、XMLメッセージに含まれます。

セキュリティ

WS-Security 1.0および1.1標準を実装します。ユーザーの認証と認可、アイデンティティ伝播およびメッセージ保護(メッセージ整合性とメッセージの機密性)を適用します。

管理

リクエスト、レスポンスおよびフォルト・メッセージをメッセージ・ログに記録します。管理ポリシーにもカスタム・ポリシーを含めることができます。

カテゴリ・タイプごとに、1つ以上のアタッチ可能なポリシー・タイプがあります。たとえば、信頼性カテゴリを選択した場合、次のタイプを選択できます。

- oracle/no_reliable_messaging_policy
上位のスコープで構成された、信頼性のあるメッセージングの無効化をサポートします

- oracle/no_wsrm_policy
グローバルにアタッチされたWeb Services信頼できるメッセージング・ポリシーの無効化をサポートします

- oracle/reliable_messaging_policy
Webサービスの信頼性のあるメッセージングの有効化をサポートします

- oracle/wsrm10_policy
バージョン1.0のWeb Services信頼できるメッセージング・プロトコルをサポートします

- oracle/wsrm11_policy
バージョン1.1のWeb Services信頼できるメッセージング・プロトコルをサポートします

使用可能なポリシー、自分の環境で使用するポリシーおよびグローバル・ポリシーの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。

46.2 バインディング・コンポーネントおよびサービス・コンポーネントへのポリシーの添付

SOAコンポジット・アプリケーションのサービス・バインディング・コンポーネント、サービス・コンポーネントおよび参照バインディング・コンポーネントとの間で、ポリシーを添付したり、ポリシーの添付を解除できます。設計時環境でセキュリティをテストするために、Oracle JDeveloperを使用してポリシーを添付します。アプリケーションを本番環境にデプロイする準備が整った場合は、Oracle Enterprise Manager Fusion Middleware Controlで実行時ポリシーを添付したり、ポリシーの添付を解除できます。

ポリシーの実行時管理の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

46.2.1 ポリシーをバインディング・コンポーネントおよびサービス・コンポーネントに添付する方法

バインディング・コンポーネントおよびサービス・コンポーネントにポリシーを添付する手順は、次のとおりです。

1. SOAコンポジット・エディタで、サービス・バインディング・コンポーネントまたは参照バインディング・コンポーネントを右クリックします。

2. 「SOA WSポリシーの構成」を選択します。

SOAコンポジット・アプリケーションのインタフェース定義に応じて、オプションの追加メニューが表示される場合があります。

- 選択したサービスまたは参照が同期のBPELプロセス・サービス・コンポーネントまたはOracle Mediatorサービス・コンポーネントとインタフェースしている場合は、リクエスト・メッセージとレスポンス・メッセージの両方に対して単一のポリシーが使用されます。「SOA WSポリシーの構成」ダイアログが即時に表示されます。手順4に進みます。

- サービスまたは参照が非同期のBPELプロセス・サービス・コンポーネントまたはOracle Mediatorサービス・コンポーネントとインタフェースしている場合は、リクエスト・メッセージとレスポンス・メッセージに対して個別のポリシーを構成する必要があります。コールバックのポリシーは、サービスからクライアントに送信されるレスポンスに使用されます。追加のメニューが表示されます。手順3に進みます。

3. 使用するバインディングのタイプを選択します。

- リクエスト対象:
バインドするサービス・コンポーネントのリクエスト・バインディングを選択します。選択できるリクエスト・バインディングは1つのみです。このアクションにより、バインディング・コンポーネントとサービス・コンポーネント間の通信が可能になります。

「公開されたサービス」スイムレーンでリクエスト・バインディングがサービスに対して構成されると、そのサービスはサーバーとして機能します。「外部参照」スイムレーンでリクエスト・バインディングが参照に対して構成されると、その参照はクライアントとして機能します。

- コールバック対象: (非同期プロセスとの相互作用が必要な場合のみ)
バインドするサービス・コンポーネントのコールバック・バインディングを選択します。このアクションにより、バインディング・コンポーネントとサービス・コンポーネント間のメッセージ通信が可能になります。選択できるコールバック・バインディングは1つのみです。

「公開されたサービス」スイムレーンでコールバック・バインディングがサービスに対して構成されると、そのサービスはクライアントとして機能します。「外部参照」スイムレーンでコールバック・バインディングが参照に対して構成されると、その参照はサーバーとして機能します。

図46-1 に示す「SOA WSポリシーの構成」ダイアログが表示されます。この例では、サービス・バインディング・コンポーネントに対して「リクエスト対象」オプションが選択されています。「コールバック対象」を選択した場合も、同じタイプのポリシー・カテゴリが使用可能です。

図46-1 「SOA WSポリシーの構成」ダイアログ

4. 添付するポリシーのタイプの隣にある「追加」アイコンをクリックします。

- MTOM

- 信頼性

- アドレッシング

- セキュリティ

- 管理

この例では、「セキュリティ」が選択されています。図46-2 に示すダイアログが表示されます。

図46-2 セキュリティ・ポリシー

5. ポリシー名の右側にあるアイコンをクリックすると、ポリシーの機能の説明が表示されます。

6. 添付するポリシーのタイプを選択します。

7. 「OK」をクリックします。

図46-3 に示す「SOA WSポリシーの構成」ダイアログに戻ります。添付されたセキュリティ・ポリシーが「セキュリティ」セクションに表示されます。

図46-3 添付されたセキュリティ・ポリシー

8. 必要に応じて、さらにポリシーを追加します。

「選択したポリシーの無効化」アイコンをクリックして、ポリシーを一時的に無効にできます。図46-4に詳細を示します。このアクションはポリシーの添付を解除するものではありません。

図46-4 「選択したポリシーの無効化」アイコン

9. ポリシーを再び有効にするには、左側の「選択したポリシーの有効化」アイコンをクリックします。

10. ポリシーの添付を解除するには、「削除」アイコンをクリックします。

11. 完了後に、「SOA WSポリシーの構成」ダイアログで「OK」をクリックします。

SOAコンポジット・エディタに戻ります。

12. サービス・バインディング・コンポーネントのアイコン上にカーソルを置いて、添付されたポリシーの詳細を表示します。図46-5に詳細を示します。

図46-5 「ポリシーの説明」アイコン

46.2.1.1 ポリシーをサービス・コンポーネントに添付する手順:

1. サービス・コンポーネントを右クリックします。

2. 「SOA WSポリシーの構成」を選択します。
図46-6 に示す「SOA WSポリシーの構成」ダイアログが表示されます。

図46-6 「SOA WSポリシーの構成」ダイアログ

3. 添付するポリシーのタイプの隣にある「追加」アイコンをクリックします。

- セキュリティ

- 管理

選択したタイプに対応するダイアログが表示されます。

4. 添付するポリシーのタイプを選択します。

5. 「OK」をクリックします。

6. 必要に応じて、さらにポリシーを追加します。

7. 完了後に、「SOA WSポリシーの構成」ダイアログで「OK」をクリックします。

Oracle Enterprise Manager Fusion Middleware Control実行時のポリシーの添付については、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

46.2.2 ポリシー構成プロパティ値のオーバーライド方法

使用する環境には、同じポリシーのクライアントまたはサーバーが複数含まれている場合があります。ただし、各クライアントまたはサーバーにはそれぞれ固有のポリシー要件が設定されている可能性があります。これらのポリシー・プロパティ値は、実行時の要件に基づいてオーバーライドできます。

46.2.2.1 クライアント構成プロパティ値のオーバーライド

クライアント・ポリシー構成プロパティのデフォルト値は、各クライアントに新しいポリシーを作成しなくても、クライアントごとにオーバーライドできます。この方法では、デフォルトの構成値を定義し、その値を実行時の要件に基づいてカスタマイズするクライアント・ポリシーをオーバーライドできます。

1. 次のいずれかのバインディング・コンポーネントを右クリックします。

- 「公開されたサービス」スイムレーンでサービス・バインディング・コンポーネントを右クリックし、「コールバック対象」を選択します。

- 「外部参照」スイムレーンで参照バインディング・コンポーネントを右クリックし、「リクエスト対象」を選択します。

2. 「セキュリティ」および「管理」セクションに移動します。これらの手順は、これらのセクションにポリシーがすでに添付されていることを前提にしています。

両方のセクションで「編集」アイコンが使用可能です。図46-7に詳細を示します。

図46-7 クライアント・ポリシーの選択

3. 「編集」アイコンをクリックします。

4. 「オーバーライド値」列で、「値」列に表示されたデフォルト値をオーバーライドする値を入力します。図46-8に詳細を示します。

図46-8 クライアント・ポリシーのオーバーライド値

5. 「OK」をクリックして「構成オーバーライド・プロパティ」ダイアログを閉じます。

6. 「OK」をクリックして「SOA WSポリシーの構成」ダイアログを閉じます。

ポリシー設定のオーバーライドの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。

46.2.2.2 サーバー構成プロパティ値のオーバーライド

サーバー・ポリシー構成プロパティのデフォルト値は、各サーバーに新しいポリシーを作成しなくても、サーバーごとにオーバーライドできます。この方法では、デフォルトの構成値を定義し、その値を実行時の要件に基づいてカスタマイズするサーバー・ポリシーをオーバーライドできます。

サーバー構成プロパティ値をオーバーライドする手順は、次のとおりです。

1. 次のいずれかのバインディング・コンポーネントを右クリックします。

- 「公開されたサービス」スイムレーンでサービス・バインディング・コンポーネントを右クリックし、「リクエスト対象」を選択します。

- 「外部参照」スイムレーンで参照バインディング・コンポーネントを右クリックし、「コールバック対象」を選択します。

2. 「セキュリティ」または「管理」セクションに移動します。これらの手順は、これらのセクションにポリシーがすでに添付されていることを前提にしています。

デフォルトでは、両方のセクションで「編集」アイコンは使用不可です。このアイコンを使用可能にするには、明示的にポリシーを選択する必要があります。これは、サーバーのプロパティ値はほとんどオーバーライドできないためです。図46-9に詳細を示します。

図46-9 サーバー・ポリシーの選択

3. 値のオーバーライドが許可されている添付済ポリシーを選択し、「編集」アイコンをクリックします。

4. 「オーバーライド値」列で、「値」列に表示されたデフォルト値をオーバーライドする値を入力します。図46-10に詳細を示します。ポリシー・ストアが使用不可の場合は、「ストアにプロパティ・ストアが見つかりません」というメッセージが「値」列に赤色で表示されます。

図46-10 サーバー・ポリシーのオーバーライド値

5. 「OK」をクリックして「構成オーバーライド・プロパティ」ダイアログを閉じます。

6. 「OK」をクリックして「SOA WSポリシーの構成」ダイアログを閉じます。

ポリシー設定のオーバーライドの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。

46.3 メッセージの特定フィールドの暗号化と復号化

Oracle SOA SuiteおよびOracle Service BusでWebサービスとJCAアダプタ内を流れる機密データ(個人の身元を特定する情報(PII)と呼ばれる)を保護するために、メッセージのフィールドを暗号化および復号化できます。この機能は、このようなデータが管理コンソールでクリア・テキストで表示されるのを防ぐため、特定のフィールド(たとえば、SSN)を不明瞭化します。

図46-11 は、サービス・バインディング・コンポーネント内でSOAコンポジット・アプリケーションに入力されるときに暗号化される受信メッセージ、および参照バインディング・コンポーネント内でSOAコンポジット・アプリケーションから出力されるときに復号化される送信メッセージを示しています。コンポジット外部のメッセージは、他のメッセージ保護ポリシー(WS-Security/SSL)によって保護できます。

図46-11 SOAコンポジット・アプリケーションでのメッセージの暗号化と復号化

次のコードは、暗号化されていないメッセージの例を示しています。PIIフィールドは、nameとdriversLicenseです。

<person>
<name>John</name>
<driversLicense>B1234</driversLicense>
<ssn>123-456-789</ssn>
</person>

次のコードは、nameおよびdriversLicenseフィールドが暗号化書式で暗号化されたメッセージの例を示しています。

<person>
<name>John</name>
<driversLicense>encrypted:fdslj[lmsfwer09fsn;keyname=pii-csf-key</driversLicense>
<ssn>encrypted:gdf45md%mfsd103k;keyname=pii-csf-key</ssn>
</person>

暗号化書式は次のとおりです。

encrypted:<CIPHER_TEXT>;keyname:<CSF_KEY_NAME>

注意:

PIIポリシーと認可ポリシーの両方がSOAコンポジット・アプリケーションにアタッチされている場合は、PIIポリシーの前に認可ポリシーが実行されます。これは、PIIポリシーが認可に使用されるフィールドを暗号化することがあるためです。

認可ポリシーがコンポーネントにアタッチされ、すでに暗号化されたフィールドが必要な場合は、認可は失敗します。

46.3.1 メッセージの特定フィールドを暗号化および復号化する方法

注意:

- 暗号化メッセージをコンポジットと切り離す場合は、PIIを復号化する必要があります。PIIポリシーをサービス・バインディング・コンポーネントにアタッチしているが、参照バインディング・コンポーネントにアタッチしない場合、アウトバウンド・メッセージのPIIは復号化されません。これは推奨されておらず、実行時エラーが表示されます。

- あるSOAコンポジット・アプリケーション内で暗号化されたPIIは、別のSOAコンポジット・アプリケーションでは復号化できません。

メッセージの特定のフィールドを暗号化および復号化する手順は、次のとおりです。

1. サービス・バインディング・コンポーネントを右クリックして、「機密データの保護」→「リクエスト・データの暗号化」を選択します。

図46-12 に示すような「PII構成」ダイアログが表示されます。

ここで、受信メッセージに対して初期の暗号化を実行する必要があります。

図46-12 暗号化用の「PII構成」ダイアログ

2. 「編集」アイコンをクリックして、暗号化するスキーマ内の要素を指定します。

「暗号化するフィールドを選択します」フィールドの「入力」タブが表示されます。

3. 「追加」アイコンをクリックして、暗号化するリクエスト・メッセージのフィールド(たとえば、ユーザーの名前、クレジット・カード番号、社会保障番号など)を指定するXPath式を作成します。

4. 「CSF」タブをクリックします。

5. 使用するCredential Store Framework (CSF)キーを選択します。資格証明ストアは、資格証明キーを安全に保管するために使用されます。

暗号化が完了した後、メッセージはSOAコンポジット・アプリケーションのサービス・コンポーネントを通過します。

メッセージが参照バインディング・コンポーネントに到達し、SOAコンポジット・アプリケーションから抜け出る準備ができたら、暗号化メッセージを復号化する必要があります。

6. 参照バインディング・コンポーネントを右クリックして、「機密データの復号化」を選択します。図46-13に詳細を示します。

図46-13 復号化用の「PII構成」ダイアログ

7. 「編集」アイコンをクリックします。

「復号化するフィールドを選択します」フィールドの「入力」タブが表示されます。非同期プロセスには、入力メッセージ用と出力メッセージ用の2つの手順があります。

8. 「追加」アイコンをクリックして「式ビルダー」ダイアログを呼び出し、復号化するフィールド(たとえば、クレジット・カード番号、運転免許などのフィールド)を指定するXPath式を作成します。

9. 完了後に「OK」をクリックします。

oracle/pii_security_policyを使用してコンポジットを構成した後、資格情報ストアにキーとユーザー資格情報を追加する必要があります。

10. createCred WLSTコマンドを使用して、csf-keyユーザー資格情報に関するoracle.wsm.security資格情報マップにエントリを作成します。

connect("weblogic","password","t3://myAdminServer.example.com:7001")

wls:/DefaultDomain/serverConfig> createCred(map="oracle.wsm.security",
key="pii-csf-key", user="weblogic", password="password", desc="Key for
pii_security_policy")

この作業を実行しなければ、次のエラーが発生します。

oracle.wsm.security.SecurityException: WSM-00016 : The
username/password credentials or certificates pii-csf-key are missing.

47 SOAコンポジット・アプリケーションのデプロイ

この章では、SOAコンポジット・アプリケーションのデプロイメントのライフ・サイクルについて説明します。さらに、Oracle JDeveloperおよびantスクリプト・ツールを使用して1つのコンポジット、複数のコンポジット、およびWSDL、XSD、他のファイル・タイプなどの共有データを使用するコンポジットをデプロイする方法、および異なる環境の間でSOAコンポジット・アプリケーションを移動するための構成プランを作成する方法についても説明します。ここでは、デプロイメントの前提条件、パッケージ化、準備および構成タスクについても説明します。また、Oracle WebLogic Scripting Tool (WLST)ユーティリティを使用したデプロイに関するドキュメントへの参照についても記載します。

この章の内容は次のとおりです。

- デプロイメントの概要

- デプロイメントの前提条件

- パッケージ化による影響の理解

- コンポジットの構造

- ターゲット環境の準備

- デプロイメント前にターゲット環境に応じてアプリケーションをカスタマイズする方法

- Oracle JDeveloperでのSOAコンポジット・アプリケーションのデプロイ

- WLSTユーティリティを使用したSOAコンポジット・アプリケーションのデプロイおよび管理

- antスクリプトを使用したSOAコンポジット・アプリケーションのデプロイおよび管理

- SOAコンポジット・アプリケーションのOracle Enterprise Manager Fusion Middleware Controlからのデプロイ

- クラスタへのSOAコンポジット・アプリケーションのデプロイ

- 実行中のサーバーがない状態でのSOAコンポジット・アプリケーションのデプロイ

- デプロイ後の構成

- テストおよびトラブルシューティング

- SOAコンポジットの実行中のインスタンスへのパッチ適用

Oracle Enterprise Manager Fusion Middleware ControlからSOAコンポジット・アプリケーションをデプロイする手順の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。WLSTユーティリティを使用してSOAコンポジット・アプリケーションをデプロイする手順の詳細は、SOA Suite用WLSTコマンド・リファレンスを参照してください。

47.1 デプロイメントの概要

この章では、デプロイメントのライフ・サイクルに関する次の項目について説明します。

- デプロイメントの前提条件

- パッケージ化の詳細

- コンポジットの構造

- ターゲット環境の準備

- ターゲット環境の構成タスク

- コンポジットのデプロイメント

- デプロイメント後の構成タスク

- コンポジット・アプリケーションのテストおよびトラブルシューティング

デプロイメントのライフ・サイクルの詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

47.2 デプロイメントの前提条件

この項では、SOAコンポジット・アプリケーションの作成とデプロイに必要な基本的な前提条件を説明します。

47.2.1 Oracle SOA Suiteスキーマの作成

Oracle SOA Suiteコンポーネントにはスキーマが必要です。このスキーマはOracleまたはMicrosoft SQL Serverのデータベースにインストールされている必要があります。スキーマの作成とロードは、リポジトリ作成ユーティリティ(RCU)を使用してデータベース内で行います。スキーマのインストールおよび構成の詳細は、『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』および『リポジトリ作成ユーティリティを使用したスキーマの作成』を参照してください。

開発環境でOracle SOA Suiteのクイック・スタート・インストールを使用する場合は、スキーマはJavaデータベースに自動的に作成されます。詳細は、『SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』を参照してください。

47.2.2 SOAドメインの作成

インストール後は、Oracle Fusion Middleware構成ウィザードを使用して、新しいOracle WebLogic Serverドメインを作成および構成し、そのドメイン内で構成する製品(Oracle SOA Suiteなど)を選択します。この新しいドメインには、構成するように選択した製品に応じて、管理サーバーおよびその他の管理対象サーバーが含まれます。

詳細は、『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』を参照してください。

Oracle SOA Suiteのクイック・スタートをインストールした場合は、Oracle JDeveloperで統合WebLogic Serverのデフォルト・ドメインを構成できます。詳細は、『SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』のドメインの構成に関する項を参照してください。

47.2.3 SOAクラスタの構成

SOAコンポジット・アプリケーションはクラスタ化された環境にもデプロイできます。クラスタ化された環境の作成および構成の詳細は、『高可用性ガイド』を参照してください。

47.3 パッケージ化による影響の理解

SOAコンポジット・アプリケーションのプロジェクト内で必要なすべてのアーティファクト・ファイルは、次のツールを使用してSOAアーカイブ(SAR) JARファイルに個別にパッケージ化できます。

- Oracle JDeveloper
「デプロイメント・アクション」ページでデプロイ中に「SARファイルの生成」オプションを選択します。詳細は、「プロファイルのデプロイ」を参照してください。

- antスクリプト
ant-sca-packageスクリプトを使用して、アーティファクトをパッケージ化します。詳細は、「コンポジットSARファイルにSOAコンポジット・アプリケーションをパッケージ化するためのantの使用方法」を参照してください。

- WLSTコマンド
sca_packageスクリプトを使用して、アーティファクトをパッケージ化します。詳細は、SOA Suite用WLSTコマンド・リファレンスを参照してください。

- Mavenプラグイン
Mavenプラグインは、Maven環境でSOAコンポジット・アプリケーションのコンパイル、パッケージ化、デプロイ、テスト、およびアンデプロイを行うために使用します。詳細は、「Oracle SOA Suite Development Mavenプラグインの使用」を参照してください。

SARファイルは、sca_という接頭辞(たとえばsca_HelloWorld_rev1.0.jar)を必要とする特殊なJARファイルです。

さらに、Oracle JDeveloperの「デプロイメント・アクション」ページで「アプリケーション・サーバーへのデプロイ」オプションを選択してSOAコンポジット・アプリケーションをデプロイする場合、プロジェクト内で必要なすべてのアーティファクト・ファイルは次のいずれかのファイルに自動的にパッケージ化されます。

- 自己完結型のJARファイル(単一のSOAコンポジット・アプリケーションの場合)
自己完結型のコンポジットの詳細は、「Oracle JDeveloperでの単一のSOAコンポジットのデプロイ方法」および「Oracle JDeveloperでの複数のSOAコンポジットのデプロイ方法」を参照してください。

- メタデータを相互に共有する複数のSOAコンポジット・アプリケーションのZIPファイル
SOAコンポジット・アプリケーション間で共有データをデプロイして使用できます。共有データは、アプリケーション・サーバー上のSOAインフラストラクチャに、Oracle Metadata Services (MDS)リポジトリのアーカイブJARファイルとしてデプロイされます。このアーカイブ・ファイルには、すべての共有リソースが含まれています。詳細は、「Oracle JDeveloperでの複数のSOAコンポジット・アプリケーション間の共有データのデプロイ方法および使用方法」を参照してください。

47.4 コンポジットの構造

Oracle JDeveloperでSOAコンポジット・アプリケーションをデプロイすると、そのコンポジットはJARファイル(単一のコンポジット・アプリケーションの場合)またはZIPファイル(複数のSOAコンポジット・アプリケーションの場合)にパッケージ化されます。これらのファイルには、次のアーティファクトを含めることができます。

- バインディング・コンポーネントおよびサービス・コンポーネント。

- Oracle B2Bアグリーメント、Oracle Web Service Manager (OWSM)のポリシー、およびヒューマン・ワークフロー・タスク・フローへの参照。

- WSDLファイル、XSDファイルなどの共有データ。すべての共有データは、サーバー上の既存のSOAインフラストラクチャ・パーティションにデプロイされます。このデータは、/appsネームスペースの下にデプロイされます。Oracle JDeveloperでSOA-MDS接続を使用してこのアーティファクトを参照する場合、URLには接頭辞oramdsが付加されます。

47.5 ターゲット環境の準備

ターゲット環境とは、SOAコンポジット・アプリケーションをデプロイする先のSOAインフラストラクチャ環境です。この環境は通常、開発、テストまたは本番の環境です。あるターゲット環境から別のターゲット環境にアプリケーションを移動するときは、コンポジット・アプリケーションで使用しているコンポーネント、アイデンティティ・サービス・プロバイダおよびセキュリティ・ポリシーに応じて、追加の構成ステップが必要になる場合があります。この項では、それらのタスクについて説明します。

47.5.1 データ・ソースおよびキューの作成方法

Java Database Connectivity (JDBC)データ・ソースは、JDBC接続のプールが含まれているJava Naming and Directory Interface (JNDI)ツリーにバインドされているオブジェクトです。アプリケーションでは、JNDIツリーでデータ・ソースを参照し、そのデータ・ソースからのデータベース接続を予約できます。送信メッセージをエンキューしたり受信メッセージをデキューするためのキューを作成します。表47-1 に示すOracle JCAアダプタには、デプロイメントの前に、JDBCデータ・ソースおよびキューを構成する必要があります。

表47-1 Oracle JCAアダプタのタスク

アダプタ

構成タスク

関連項目

データベース・アダプタ

JDBCデータ・ソース

『テクノロジ・アダプタの理解』のデプロイメントに関する項

AQアダプタ

JDBCデータ・ソース

『テクノロジ・アダプタの理解』のOracle WebLogic Server管理コンソールでのデータ・ソースの構成に関する項

JMSアダプタ

キュー

『テクノロジ・アダプタの理解』のアダプタ構成ウィザードを使用したOracle JMSアダプタの構成に関する項

47.5.1.1 JMSリソースの作成およびJMSアダプタの再デプロイメント用のスクリプト

次の例は、JMSリソースの作成およびJMSアダプタの再デプロイメント用のスクリプトを示しています。

注意:

このスクリプトはデモ用です。使用する環境に応じて、このスクリプトの変更が必要になる場合があります。

# lookup the JMSModule
jmsSOASystemResource = lookup("SOAJMSModule","JMSSystemResource")

jmsResource = jmsSOASystemResource.getJMSResource()

cfbean = jmsResource.lookupConnectionFactory('DemoSupplierTopicCF')
if cfbean is None:
print "Creating DemoSupplierTopicCF connection factory"
demoConnectionFactory =
jmsResource.createConnectionFactory('DemoSupplierTopicCF')
demoConnectionFactory.setJNDIName('jms/DemoSupplierTopicCF')
demoConnectionFactory.setSubDeploymentName('SOASubDeployment')

topicbean = jmsResource.lookupTopic('DemoSupplierTopic')
if topicbean is None:
print "Creating DemoSupplierTopic jms topic"
demoJMSTopic = jmsResource.createTopic("DemoSupplierTopic")
demoJMSTopic.setJNDIName('jms/DemoSupplierTopic')
demoJMSTopic.setSubDeploymentName('SOASubDeployment')

try:
save()
# activate the changes
activate(block="true")
print "jms topic and factory for SOA Fusion Order Demo successfully created"
except:
print "Error while trying to save and/or activate!!!"
dumpStack()

print "Creating jms adapter connection factory information"
try:
redeploy('JmsAdapter', '@deployment.plan@', upload='true', stageMode='stage')

except:
print "Error while modifying jms adapter connection factory"

JMSキューとトピックおよびコネクション・ファクトリの詳細は、『Oracle WebLogic Server JMSリソースの管理』の基本JMSシステム・リソースの構成に関する項を参照してください。

47.5.1.2 データベース・リソースの作成およびデータベース・アダプタの再デプロイメント用のスクリプト

次の例は、データベース・リソースの作成およびデータベース・アダプタの再デプロイメント用のスクリプトを示しています。

注意:

このスクリプトはデモ用です。使用する環境に応じて、このスクリプトの変更が必要になる場合があります。

import os
connect(userName,passWord,'t3://'+wlsHost+':'+adminServerListenPort)
edit()
startEdit()

soaJDBCSystemResource1 = create('DBAdapterTestDataSource',"JDBCSystemResource")
soaJDBCResource1 = soaJDBCSystemResource1.getJDBCResource()
soaJDBCResource1.setName('DBAdapterDataSource')

soaConnectionPoolParams1 = soaJDBCResource1.getJDBCConnectionPoolParams()
soaConnectionPoolParams1.setTestTableName("SQL SELECT 1 FROM DUAL")

soaConnectionPoolParams1.setInitialCapacity(10)
soaConnectionPoolParams1.setMaxCapacity(100)

soaDataSourceParams1 = soaJDBCResource1.getJDBCDataSourceParams()
soaDataSourceParams1.addJNDIName('jdbc/dbSample')
soaDriverParams1 = soaJDBCResource1.getJDBCDriverParams()
soaDriverParams1.setUrl('jdbc:oracle:thin:@'+db_host_name+':'+db_port+':'+db_sid)
soaDriverParams1.setDriverName('oracle.jdbc.xa.client.OracleXADataSource')
soaDriverParams1.setPassword('my_password')

soaDriverProperties1 = soaDriverParams1.getProperties()
soaProperty1 = soaDriverProperties1.createProperty("user")
soaProperty1.setValue('scott')

varSOAServerTarget = '/Servers/'+serverName
soaServerTarget = getMBean(varSOAServerTarget)

soaJDBCSystemResource1.addTarget(soaServerTarget)

dumpStack()

try :

save()

activate(block="true")

except:
print "Error while trying to save and/or activate!!!"
dumpStack()

print "Creating DB adapter resource  information"
try:
redeploy('DBAdapter', '@deployment.plan@', upload='true', stageMode='stage')

except:
print "Error while modifying db adapter connection factory"

JDBCデータ・ソースの詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの構成に関する項を参照してください。

47.5.2 コネクション・ファクトリおよび接続プールの作成方法

Oracle JCAアダプタは、JCA 1.5リソース・アダプタとしてOracle WebLogic Serverコンテナにデプロイされます。アダプタは、JAR形式を使用して、リソース・アダプタ・アーカイブ(RAR)ファイルとしてパッケージ化されます。このRARファイルはアダプタのデプロイ時に使用され、アダプタはOracle WebLogic Serverまたは中間層プラットフォームにコネクタとして登録されます。RARファイルの内容は次のとおりです。

- ra.xmlファイル。これは、リソース・アダプタに関するデプロイメント固有の情報を含むデプロイメント記述子XMLファイルです。

- Oracle WebLogic Serverとリソース・アダプタ間の規定に関する宣言情報

アダプタは、接続ファクトリのエンドポイントを定義するweblogic-ra.xmlテンプレート・ファイルもパッケージ化します。

コネクション・ファクトリおよび接続プールの作成の詳細は、『テクノロジ・アダプタの理解』を参照してください。

47.5.3 セキュリティを有効化する方法

ヒューマン・ワークフローでアイデンティティ・サービス・プロバイダを使用したり、認証および認可ポリシーを添付する場合は、次の追加設定タスクを実行する必要があります。

- ヒューマン・ワークフローのアイデンティティ・サービス・プロバイダ
デフォルトでは、アイデンティティ・サービスでは、Oracle WebLogic Serverの組込みLDAPサーバーがデフォルトの認証プロバイダとして使用されます。ヒューマン・ワークフローを使用する場合は、Oracle Internet Directory、Microsoft Active Directory、Oracle iPlanetなどの代替アイデンティティ・サービス・プロバイダを使用するようにOracle WebLogic Serverを構成できます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。組込みLDAPサーバーは、クラスタ化された環境ではサポートされません。

- 認証プロバイダ(OWSMポリシー)
特定タイプのトークン(例: ユーザー名トークン、X.509トークン、SAMLトークンなど)を使用するポリシーには、認証プロバイダが必要です。認証プロバイダの選択と構成の詳細は、『Webサービスの管理』を参照してください。

- 認可プロバイダ(OWSMポリシー)
ユーザーが認証された後は、認可ポリシーを使用して、そのユーザーがWebサービスへのアクセスを認可されていることを検証する必要があります。認可ポリシーは、いくつかのタイプのアサーション・テンプレートを使用して作成できます。認可ポリシーおよび保護するリソースの詳細は、『Webサービスの管理』を参照してください。

47.5.4 設計時のビジネス・フロー・インスタンス名またはコンポジット・インスタンス名の設定方法

Oracle MediatorおよびOracle BPEL Process Managerでは、設計時にSOAコンポジット・アプリケーションのビジネス・フロー・インスタンス名またはコンポジット・インスタンス名を設定できます。この名前は、Oracle Enterprise Manager Fusion Middleware ControlでSOAコンポジット・アプリケーションの「フロー・インスタンス」ページの「名前」列に表示されます。Oracle Enterprise Manager Fusion Middleware Controlで、SOAコンポジット・アプリケーション、パーティションまたはSOAインフラストラクチャの「フロー・インスタンス」ページに検索基準を指定するときに、この名前を「名前」フィールドに指定できます。

47.5.4.1 Oracle Mediatorでのビジネス・フロー・インスタンス名の設定

Oracle Mediatorでビジネス・フロー・インスタンス名を設定する手順は、次のとおりです。

assignアクティビティでXPath式関数oraext:setFlowInstanceTitle()を使用します。次に例を示します。

<assign>
<copy
target="$out.property.tracking.setFlowInstanceTitle"
expression="oraext:setFlowInstanceTitle("sample")"
xmlns:med="http://schemas.oracle.com/mediator/xpath"/>
</assign>

47.5.4.2 BPELプロセスでのビジネス・フロー・インスタンス名の設定

1つのビジネス・フロー・インスタンスは、1つのエンドツーエンド・ビジネス・トランザクションに相当します。ビジネス・フローは、単一のSOAコンポジット・アプリケーションまたは特定のビジネス・プロセスを実現するために組み合された複数のSOAコンポジット・アプリケーションで構成されます。

BPELプロセスでビジネス・フロー・インスタンス名を設定する手順は、次のとおりです。

1. Java BPEL exec拡張要素bpelx:execを使用します。この拡張要素には組込みメソッドsetFlowInstanceTitle(String title)が含まれており、ビジネス・フロー・インスタンス名を設定できます。

ビジネス・フロー・インスタンス名の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「ビジネス・フロー・インスタンスのトラッキング」を参照してください。

47.5.4.3 BPELプロセスでのコンポジット・インスタンス名の設定

setCompositeInstanceTitleメソッドは下位互換性を維持するために提供されています。コンポジット・インスタンス名は、ビジネス・フロー・インスタンス名とは異なります。1つのビジネス・フロー・インスタンスには、複数のコンポジット・インスタンスが参加できます。フロー・インスタンス名とコンポジット・インスタンス名の間には、1対多の関係が構成されます。

BPELプロセスにコンポジット・インスタンス名を設定する手順は、次のとおりです。

1. Java BPEL exec拡張要素bpelx:execを使用します。この拡張要素には組込みメソッドsetCompositeInstanceTitle(String title)が含まれており、インスタンス名を設定できます。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

47.5.5 取引パートナ・アグリーメントおよびタスク・フローのデプロイ方法

Oracle B2Bまたはヒューマン・タスクを使用する場合は、次の追加設定タスクを実行する必要があります。

取引パートナ・アグリーメントおよびタスク・フローをデプロイする手順は、次のとおりです。

- 取引パートナ・アグリーメントのデプロイ
取引パートナ・アグリーメントには、2つの取引パートナ、つまりイニシエータと応答者がビジネス文書を交換する際の条件が定義されています。これによって、取引パートナ、取引パートナID、ドキュメント定義およびチャネルが識別されます。アグリーメントは、設計時リポジトリから実行時リポジトリにデプロイする必要があります。詳細は、『Oracle B2Bユーザーズ・ガイド』を参照してください。

- タスク・フローのデプロイ
Oracle BPM Worklistでタスク・フローを使用するには、そのタスク・フローをデプロイする必要があります。詳細は、「プロファイルのデプロイ」を参照してください。

47.5.6 アプリケーション・サーバー接続の作成方法

データを他のコンポジットと共有しないSOAコンポジット・アプリケーションをデプロイするには、「アプリケーション・サーバー接続の作成」ウィザードを使用して、アプリケーション・サーバー接続を作成します。詳細は、「アプリケーション・サーバー接続の作成」を参照してください。

47.5.7 SOA-MDS接続の作成方法

データを他のコンポジットと共有するSOAコンポジット・アプリケーションをデプロイするには、「SOA-MDS接続の作成」ウィザードを使用して、データベース・ベースのOracle MDSリポジトリ・サーバーへの接続を作成します。詳細は、「SOA-MDS接続の作成」を参照してください。

47.5.7.1 SOA-MDS接続によるcomposite.xmlファイルのオープンに関する必知事項

Oracle JDeveloperでSOA-MDS接続を作成し、接続を展開し、「リソース」ウィンドウからコンポジットのcomposite.xmlファイルを開く場合、ファイルが正しくロードされない場合があります。コンポジットは「アプリケーション」ウィンドウでのみ開けます。

Oracle MDSリポジトリの詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

47.6 デプロイメント前にターゲット環境に応じてアプリケーションをカスタマイズする方法

開発、テストおよび本番環境間を移動するとき、すべてのカスタマイズ・タスクを手動で実行する必要はありません。この項では、構成プランを使用して、次に進むターゲット環境に応じてSOAコンポジット・アプリケーションを自動的に構成する方法について説明します。

47.6.1 ターゲット環境に応じてSOAコンポジット・アプリケーションをカスタマイズするための構成プランの使用方法

通常、プロジェクトをある環境から別の環境に(たとえば、テスト環境から本番環境に)移動する場合は、JDBC接続文字列や様々なサーバーのホスト名など、環境固有の値をいくつか変更する必要があります。構成プランと呼ばれる単一のテキスト(XML)ファイルを使用して、これらの値を変更できます。構成プランは、Oracle JDeveloper内で作成するか、またはWLSTコマンドを使用して作成します。プロセスのデプロイメント時に、構成プランを使用してSOAプロジェクトを検索し、プロジェクトを次に進むターゲット環境に適応させるために置換する必要がある値を検索します。

47.6.1.1 構成プランの概要

この項では、構成プランの作成方法と添付方法の概要を説明します。

- 次の属性やプロパティを置換できる構成プラン・ファイルを作成して編集します。

- SOAコンポジット・アプリケーション・ファイル(composite.xml)内のすべてのコンポジット、サービス・コンポーネント、参照、サービスおよびバインディング・プロパティ

- バインディング用の属性値(例: binding.wsの場所)

- WSDLファイル内のインポートのschemaLocation属性

- WSDLファイル内のインクルードのlocation属性

- XSDファイル内のインクルード、インポートおよび再定義のschemaLocation属性

- JCAアダプタ・ファイル内のすべてのプロパティ

- 次のもののためのポリシー参照

- サービス・コンポーネント

- サービス・バインディング・コンポーネントおよび参照バインディング・コンポーネント

注意:

構成プランは、SOAコンポジット・アプリケーションのXSLTアーティファクトを変更しません。XSLを変更するには、XSLTマップ・エディタを使用します。構成プランの使用は有効ではありません。たとえば、構成プラン・ファイルを使用してXSLの参照を変更することはできません。かわりに、テスト、開発および本番環境の間を移動するときに、Oracle JDeveloperのXSLTマップ・エディタで参照を手動で変更する必要があります。これにより、設計時にXSLTマップ・エディタが問題なく開きます。ただし、参照を未変更のままにしても実行時の動作に影響はありません。トランスフォーメーションおよびXSLTマップ・エディタの詳細は、「XSLTマップ・エディタを使用したトランスフォーメーションの作成」を参照してください。

- デプロイメント時には、次のいずれかのツールを使用して、構成プラン・ファイルをSOAコンポジット・アプリケーションのJARファイルまたはZIPファイル(SOAバンドルをデプロイする場合)に添付します。

- Oracle JDeveloper
詳細は、「プロファイルのデプロイ」を参照してください。

- antスクリプト
詳細は、「SOAコンポジット・アプリケーションをデプロイするためのantの使用方法」を参照してください。

- WLSTコマンド
詳細は、SOA Suite用WLSTコマンド・リファレンスを参照してください。

- デプロイメント時に、構成プラン・ファイルを使用して、SOAコンポジット・アプリケーションのJARまたはZIPファイルにあるcomposite.xml、WSDLおよびXSDファイルを検索し、プロジェクトを次に進むターゲット環境に適応させるために置換する必要がある値を検索します。

47.6.1.2 構成プラン・ファイルの概要

次の例は、次の項目を変更する構成プランを示しています。

- コンポジットFileAdaptorCompositeのinFileFolderプロパティは、mytestserver/newinFileFolderで置換されます。

- 次の場所のホスト名(myserver17)は、test-serverで置換され、ポート8888は8198で置換されます。

- すべてのインポートWSDL

- すべての参照binding.wsの場所

composite.xmlファイルは次の例のようになります。

<composite .....>
<import namespace="http://example.com/hr/"
location="http://myserver17.us.example.com:8888/hrapp/HRAppService?WSDL"
importType="wsdl"/>
<service name="readPO">
<interface.wsdl
interface="http://xmlns.oracle.com/pcbpel/adapter/file/readPO/#wsdl.interface(Read
_ptt)"/>
<binding.jca config="readPO_file.jca"/>
<property name="inFileFolder" type="xs:string" many="false"
override="may">/tmp/inFile</property>
</service>
<reference name="HRApp">
<interface.wsdl
interface="http://example.com/hr/#wsdl.interface(HRAppService)"/>
<binding.ws
port="http://example.com/hr/#wsdl.endpoint(HRAppService/HRAppServiceSoapHttpPort)"
location="http://myserver17.us.example.com:8888/hrapp/HRAppService?WSDL"/>
<binding.java serviceName="{http://example.com/hr/}HRAppService"
registryName="HRAppCodeGen_JBOServiceRegistry"/>
</reference>
</composite>

構成プラン・ファイルは次の例のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<SOAConfigPlan
xmlns:jca="http://platform.integration.oracle/blocks/adapter/fw/metadata"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
xmlns:edl="http://schemas.oracle.com/events/edl"
xmlns="http://schemas.oracle.com/soa/configplan">
<composite name="FileAdaptorComposite">
<service name="readPO">
<binding type="*">
<property name="inFileFolder">
<replace>/mytestserver/newinFileFolder</replace>
</property>
</binding>
</service>
</composite>
<!-- For all composite replace host and port in all imports wsdls -->
<composite name="*">
<import>
<searchReplace>
<search>myserver17</search>
<replace>test-server</replace>
</searchReplace>
<searchReplace>
<search>8888</search>
<replace>8198</replace>
</searchReplace>
</import>
<reference name="*">
<binding type="ws">
<attribute name="location">
<searchReplace>
<search>myserver17</search>
<replace>test-server</replace>
</searchReplace>
<searchReplace>
<search>8888</search>
<replace>8198</replace>
</searchReplace>
</attribute>
</binding>
</reference>
</composite>
</SOAConfigPlan>

ポリシーは、同じURIに対するポリシーが使用可能な場合は置換されます。それ以外の場合は追加されます。これは、変更されるが追加はされないプロパティとは異なります。

47.6.1.3 構成プランのユースケースの概要

次の手順では、開発環境からテスト環境に移動するときに構成プランを使用する方法の概要を説明します。

1. ユーザーAはSOAコンポジット・アプリケーションFooを作成します。

2. ユーザーAはFooを開発サーバーにデプロイし、ステージング領域でテストする準備が整うまで不具合を修正してプロセスを調整します。

3. ユーザーAはFoo用の構成プランを作成して編集します。これにより、テスト環境に適合するようにアプリケーション内のURLおよびプロパティを変更できます。

4. ユーザーAは、Oracle JDeveloperまたは一連のコマンドライン・スクリプト(WLSTベース可能)を使用して、Fooをテスト・サーバーにデプロイします。ステップ3で作成した構成プランにより、Foo内のURLおよびプロパティが変更されます。

5. ユーザーAは、今後、SOAコンポジット・アプリケーションBarをデプロイし、デプロイメント時に同じプランを適用します。URLおよびプロパティも変更されます。

47.6.1.3.1 環境に依存しないプロセスを作成するときに構成プランを使用する方法

次の手順では、環境に依存しないプロセスを作成するときに構成プランを使用する方法の概要を説明します。

注意:

このユースケースは、独自の開発サーバー、および共通の開発およびテスト・サーバーを持つユーザーが、同じプロセスの開発を共有している場合に役立ちます。同じデプロイメント環境(つまり、同じ開発サーバー)を共有するユーザーには、このユースケースは参考にならない場合があります。

1. ユーザーAはSOAコンポジット・アプリケーションFooを作成します。

2. ユーザーAはFooを開発サーバーにデプロイし、ステージング領域でテストする準備が整うまで不具合を修正してプロセスを調整します。

3. ユーザーAはFoo用の構成プランを作成します。これにより、ユーザーAの環境の設定に適合するようにプロセス内のURLおよびプロパティを変更できます。

4. ユーザーAは、ソース・コントロール・システムに対して、Fooおよびステップ3で作成した構成プランをチェックインします。

5. ユーザーBは、ソース・コントロールからFooをチェックアウトします。

6. ユーザーBは、環境に適合する構成プランのコピーを作成し、新規の構成プランをFooのアーティファクトに適用します。

7. ユーザーBはアプリケーションをOracle JDeveloperにインポートし、いくつかの変更を行います。

8. ユーザーBは、Fooおよび(ユーザーBの環境に適合する)構成プランBの両方をチェックインします。

9. ユーザーAは、両方の構成プランとともに、Fooを再度チェックアウトします。

47.6.1.4 Oracle JDeveloperでの構成プランの作成方法

この項では、構成プランの作成方法と使用方法を説明します。特に、次の項目について説明します。

- 構成プランの作成および編集

- SOAコンポジット・アプリケーションのJARファイルへの構成プランの添付

- 構成プランの検証

- 構成プランが含まれるSOAコンポジット・アプリケーションのJARまたはZIPファイルのデプロイ

Oracle JDeveloperで構成プランを作成する手順は、次のとおりです。

1. Oracle JDeveloperを開きます。

2. 「アプリケーション」ウィンドウで、構成プランを作成するプロジェクトのcomposite_nameファイル(composite.xmlとも呼ばれます)を右クリックして、「構成プランの生成」を選択します。図47-1に詳細を示します。

図47-1 構成プランの生成

図47-2 に示すように、「コンポジット構成プラン・ジェネレータ」が表示されます。

図47-2 「コンポジット構成プラン・ジェネレータ」ダイアログ

3. 表47-2 に示すように、構成プラン・ファイルを作成して編集します。

表47-2 構成プランの生成

フィールド

説明

構成プランのファイル名(.xml)を指定してください

構成プランの特定の名前を入力するか、またはデフォルト名をそのまま使用します。ファイルはプロジェクトのディレクトリ内に作成され、SOAコンポジット・アプリケーションのJARまたはZIPファイルにパッケージ化されます。

注意: デプロイメント時にプロンプトが表示された時点で、デプロイメント・ウィザードの「構成のデプロイ」ページで別の構成ファイルを指定できます。詳細は、「プロファイルのデプロイ」を参照してください。

既存ファイルの上書き

既存の構成プラン・ファイルをプロジェクト・ディレクトリ内の別のファイルで上書きする場合に選択します。

4. 「OK」をクリックします。

これにより、単一の構成プラン・ファイルが作成され、編集のために開かれます。SOAコンポジット・アプリケーションのcomposite.xml、WSDLおよびスキーマ・ファイルのURLとプロパティを変更できます。図47-3に詳細を示します。

図47-3 構成プラン・エディタ

5. サーバー名、ポート番号などの値を既存の構文に追加します。また、新しい値を指定するときは、置換専用の構文を追加できます。各セクションに複数の検索コマンドや置換コマンドを追加できます。

6. 「ファイル」メニューから「すべて保存」を選択します。

7. エディタの上部で、ファイル名の右側にあるxをクリックして構成プラン・ファイルを閉じます。

8. 「アプリケーション」ウィンドウで、composite_nameファイルを再度右クリックして、「構成プランを検証します」を選択します。

図47-4 に示すように、「コンポジット構成プラン・バリデータ」が表示されます。

図47-4 構成プランの検証

9. 検証する構成プランを選択します。この手順では、デプロイメント中に行われた検索および置換による変更がすべて識別されます。このオプションをデバッグのためにのみ使用します。

10. 検証結果が記述されたレポートが作成されたディレクトリをメモし、「OK」をクリックします。

Oracle JDeveloperの「ログ」ウィンドウには、検証が成功したかどうかが表示され、SOAコンポジット・アプリケーションのデプロイメント中に実行された検索コマンドと置換コマンドがすべてリストされます。この情報は検証レポートにも書き込まれます。

注意:

古いcomposite.xml、WSDLおよびXSDファイルは、次に進む環境に適したURLおよびプロパティの新しい値を含むファイルに置換されません。このような置換は、SOAコンポジット・アプリケーションがデプロイされた場合のみ発生します。

11. 次のいずれかの項で説明する手順に従って、SOAコンポジット・アプリケーションをデプロイします。

- 「Oracle JDeveloperでの単一のSOAコンポジットのデプロイ方法」

- 「Oracle JDeveloperでの複数のSOAコンポジット・アプリケーションのデプロイ方法」

- 「Oracle JDeveloperでの複数のSOAコンポジット・アプリケーション間の共有データのデプロイ方法および使用方法」

Oracle JDeveloperでデプロイメント中に、「プロファイルのデプロイ」の手順4に示されている「構成のデプロイ」ページで、SOAコンポジット・アプリケーション・アーカイブを含める構成プランを選択するよう促されます。

12. SOAコンポジット・アプリケーションとともに含める構成プランを選択します。

13. 「OK」をクリックします。

47.6.1.5 WLSTユーティリティを使用した構成プランの作成方法

Oracle JDeveloperのかわりにWLSTコマンドライン・ユーティリティを使用して、次の構成プラン管理タスクを実行できます。

- 構成プランの生成および編集

sca_generatePlan(configPlan, sar, composite, overwrite, verbose)

- SOAコンポジット・アプリケーションのJARファイルへの構成プラン・ファイルの添付

sca_attachPlan(sar, configPlan, overwrite, verbose)

- 構成プランの検証

sca_validatePlan(reportFile, configPlan, sar, composite, overwrite, verbose)

- JARファイルにパッケージ化された構成プランの抽出および編集

sca_extractPlan(sar, configPlan, overwrite, verbose)

これらのコマンドの使用方法の詳細は、SOA Suite用WLSTコマンド・リファレンスを参照してください。

47.6.1.6 スクリプトを使用した構成プランの添付方法

デプロイメント時には、Oracle JDeveloperのかわりにantスクリプトを使用して、構成プラン・ファイルをSOAコンポジット・アプリケーションのJARまたはZIPファイルに添付できます。手順は、「SOAコンポジット・アプリケーションをデプロイするためのantの使用方法」を参照してください。

47.6.1.7 グローバル・トークン変数の作成方法

SOAコンポジット・アプリケーションの特定のURIに対してグローバル・トークン変数を定義できます。たとえば、10個の異なる構成プランでSOAコンポジット・アプリケーション名を更新するかわりに、その名前をグローバルに設定できます。値が取得され、その値で、デプロイ済SOAコンポジット・アプリケーションのcomposite.xmlファイルのコンポジット名に対するグローバル・トークン変数の値が置換されます。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

47.7 Oracle JDeveloperでのSOAコンポジット・アプリケーションのデプロイ

この項では、次のタイプのSOAコンポジット・アプリケーションをデプロイする方法について説明します。

- Oracle JDeveloperでの単一のコンポジットのデプロイ

- Oracle JDeveloperでの複数のコンポジットのデプロイ

- Oracle JDeveloperでの共有データのデプロイおよび使用

- Oracle JDeveloperでの既存のSOAアーカイブのデプロイ

- WLSTおよびantスクリプトを使用したSOAコンポジット・アプリケーションの管理

- Oracle Enterprise Manager Fusion Middleware Controlからのデプロイ

- クラスタへのSOAコンポジット・アプリケーションのデプロイ

- 実行中のサーバーがない状態でのSOAコンポジット・アプリケーションのデプロイ

47.7.1 Oracle JDeveloperでの単一のSOAコンポジットのデプロイ方法

Oracle JDeveloperでは、SOAプロジェクトとアプリケーションをOracle WebLogic Serverにデプロイするためにプロファイルを使用する必要があります。

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

SOAコンポジット・アプリケーションのデプロイ先となるアプリケーション・サーバーへの接続を作成する必要があります。次の手順は、Oracle WebLogic Serverへの接続の作成方法です。Oracle SOA Suiteクイック・インストールで使用可能なIntegratedWebLogicServer接続の使用方法の詳細は、『SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』を参照してください。

注意:

アプリケーション・サーバー接続は、「ウィンドウ」→「アプリケーション・サーバー」の順に選択してから、「アプリケーション」ウィンドウで「アプリケーション・サーバー」ノードを右クリックして、「新規アプリケーション・サーバー」を選択することでも作成できます。このオプションでは、スタンドアロン・サーバー接続または統合WebLogic Server接続を作成することを求めるプロンプトが表示されます。

アプリケーション・サーバー接続を作成するには:

1. 「ファイル」メイン・メニューから、「新規」を選択します。

2. 「一般」リストから、「接続」を選択します。

3. 「アプリケーション・サーバー接続」を選択し、「OK」をクリックします。

「名前とタイプ」ページが表示されます。

4. 「接続名」フィールドに、接続の名前を入力します。

5. 「接続タイプ」リストで「WebLogic 12.x」を選択して、Oracle WebLogic Serverへの接続を作成します。

6. 「次へ」をクリックします。

「認証」ページが表示されます。

7. 「ユーザー名」フィールドに、アプリケーション・サーバーにアクセスする権限があるユーザーを入力します。

8. 「パスワード」フィールドに、このユーザーのパスワードを入力します。

9. 「次へ」をクリックします。

「構成」ページが表示されます。

10. 「Weblogicホスト名(管理サーバー)」フィールドに、Oracle WebLogic Serverがインストールされているホストを入力します。

11. 「ポート」および「SSLポート」フィールドに適切なポート値を入力するか、デフォルト値をそのまま使用します。

12. Secure Sockets Layer (SSL)を使用する場合は、「常にSSLを使用」チェック・ボックスを選択します。表47-3 は、このチェック・ボックスを選択したときの動作について説明しています。

表47-3 HTTPSおよびHTTPサーバーへのデプロイ

このチェック・ボックスの状態

結果

選択済

SSLでコンポジットをデプロイするには、HTTPSサーバーURLが存在している必要があります。そうでない場合、デプロイメントは失敗します。

サーバーにHTTP URLのみがある場合もデプロイメントは失敗します。このオプションにより、SSLデプロイメントが確実に非SSL HTTP URLでは行われず、HTTPS URLでのみ行われるようにします。

選択解除

非SSL環境にデプロイするには、HTTPサーバーURLが存在している必要があります。そうでない場合、デプロイメントは失敗します。

サーバーにHTTPSとHTTPの両方のURLがある場合、デプロイメントは非SSL接続で行われます。このオプションは、サーバーがSSL対応であってもOracle JDeveloperからの非SSLデプロイメントを強制的に行えるようにするためのオプションです。

13. 「WebLogicドメイン」フィールドに、Oracle SOA Suiteのドメインを入力します。ドメインの指定の詳細は、「ヘルプ」をクリックしてください。図47-5に詳細を示します。

図47-5 サーバー名およびドメインの選択

14. 「次へ」をクリックします。

15. 「接続のテスト」をクリックして、サーバー接続をテストします。

16. 接続が成功したら「終了」をクリックします。それ以外の場合は、「戻る」をクリックして前のダイアログで修正を行います。接続テストに失敗しても、接続は作成されます。図47-6に詳細を示します。

図47-6 アプリケーション・サーバー接続のテスト

47.7.1.2 (オプション)プロジェクト・デプロイメント・プロファイルの作成

必要なデプロイメント・プロファイルは、プロジェクトに対して自動的に作成されます。アプリケーション・プロファイルには、SOAプロジェクトのJARファイルが含まれています。必要に応じて、追加のプロファイルを作成できます。

プロジェクト・デプロイメント・プロファイルを作成する手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「SOA」プロジェクトを右クリックします。

2. 「プロジェクト・プロパティ」を選択します。

「プロジェクト・プロパティ」ダイアログが表示されます。

3. 「デプロイメント」をクリックします。

4. 「新規プロファイル」アイコンをクリックします。

「デプロイメント・プロファイルの作成」ダイアログが表示されます。

5. 表47-4 に示されている値を入力します。

表47-4 「デプロイメント・プロファイルの作成」ダイアログのフィールドと値

フィールド

説明

プロファイル・タイプ

「SOA-SARファイル」を選択します。

SARは、SOAコンポジット・アプリケーションを記述するデプロイメント・ユニットです。SARは、BPELプロセス、ビジネス・ルール、ヒューマン・タスクおよびOracle Mediatorルーティング・サービスなどのサービス・コンポーネントを単一のアプリケーションにパッケージ化します。SARファイルは、以前のリリースのBPELスーツケース・アーカイブと類似していますが、上位のコンポジット・レベルで対応し、アプリケーションに含まれる追加サービス・コンポーネント(ヒューマン・タスク、ビジネス・ルールおよびOracle Mediatorルーティング・サービスなど)があります。

デプロイメント・プロファイル名

デプロイメント・プロファイル名を入力します。

説明

プロファイル名の説明を入力します。

6. 「OK」をクリックします。

図47-7 に示すような、「SARデプロイメント・プロファイルのプロパティ」ダイアログが表示されます。

図47-7 SARデプロイメント・プロファイルのプロパティ

7. 必要に応じて、SARファイルを保存するターゲット・フォルダを指定します。

8. 「OK」をクリックして「SARデプロイメント・プロファイルのプロパティ」ダイアログを閉じます。

図47-8 に示すデプロイメント・プロファイルが、「プロジェクト・プロパティ」ダイアログに表示されます。

図47-8 プロジェクト・プロファイル

47.7.1.3 プロファイルのデプロイ

次に、プロジェクト・プロファイルをOracle WebLogic Serverにデプロイします。デプロイメントを実行するには、アプリケーション・サーバー接続の作成が必要です。デプロイメント時に接続を作成するには、ステップ10で「追加」アイコンをクリックします。またはデプロイメント前に接続を作成するには、「アプリケーション・サーバー接続の作成」の手順に従います。

プロファイルをデプロイする手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「SOA」プロジェクトを右クリックします。

2. 「デプロイ」→「project_name」の順に選択します。
project_nameの値は、SOAプロジェクト名です。

「Project_Nameのデプロイ」ウィザードの「デプロイメント・アクション」ページが表示されます。図47-9 に例を示します。

図47-9 「デプロイメント・アクション」ページ

3. 次のいずれかのデプロイメント・オプションを選択します。

- アプリケーション・サーバーへのデプロイ
選択したSOAプロジェクトのJARファイルが作成され、Oracle WebLogic Serverなどのアプリケーション・サーバーにデプロイされます。

- SARファイルの生成
選択したSOAプロジェクトのSAR (JAR)ファイルが作成されますが、Oracle WebLogic Serverなどのアプリケーション・サーバーにはデプロイされません。このオプションは次のような環境に便利です。

- Oracle WebLogic Serverは実行中でないが、アーティファクトJARファイルを作成する場合。

- バッチ・スクリプトから複数のJARファイルをOracle WebLogic Serverにデプロイする場合。このオプションは、Oracle JDeveloperですべてのプロジェクト・プロファイル(所有権がないものが含まれている可能性があります)を開いて、それらをデプロイする方法の代替手段として提供されています。

表示されるページは、選択内容によって異なります。

4. 環境に適したデプロイメント・オプションを選択します。表47-5に詳細を示します。

表47-5 デプロイメント・ターゲット

選択

次のステップ

アプリケーション・サーバーへのデプロイ

ステップ44.a

SARファイルの生成

ステップ44.b

a. 図47-10 に示す「構成のデプロイ」ページが表示されていることを確認します。

図47-10 アプリケーション・サーバーへのデプロイメント用の「構成のデプロイ」ページ

b. 図47-11 に示す「構成のデプロイ」ページが表示されていることを確認します。

図47-11 SARファイルの生成の「構成のデプロイ」ページ

5. 表47-6 に従って、手順4で選択したデプロイメント・オプションに適した値を指定します。アプリケーション・サーバーにデプロイすることを選択した場合は、追加のフィールドが表示されます。

表47-6 「SOAデプロイメントと構成ダイアログ」

フィールド

説明

コンポジット・リビジョンID

プロジェクトの詳細を展開表示します。

- プロジェクト

プロジェクト名が表示されます。

- 現在のリビジョンID

プロジェクトの現在のリビジョンIDが表示されます。

- 新規リビジョンID

必要に応じて、SOAコンポジット・アプリケーションのリビジョンIDを変更します。新しい値を指定するか、現在の値を引き続き使用することもできます。このリビジョンIDは、アプリケーション名の${composite.revision_id}変数の値になります。たとえば、OrderBookingという名前のコンポジットの新しいリビジョンIDとして2.0を入力した場合、${composite.revision_id}が_rev2.0 (sca_OrderBooking_rev2.0.jar)に置換されます。

SOA構成プラン

構成プランの詳細を展開表示します。

構成プランを使用して、異なる環境で使用するURLおよびプロパティ値を定義できます。構成プランは、プロセスのデプロイメント時に、プロジェクトを別のターゲット環境に適合させるために置換する必要のある値に関するSOAプロジェクトを検索する際に使用されます。

- 添付不可

構成プランをSOAコンポジット・アプリケーションのJARファイルに含めない場合に選択します。構成プランを作成していない場合、このフィールドは無効化されています。これはデフォルト選択です。

- Configuration_plan.xml

特定の計画を選択します。この選択を使用できるようにするには、SOAプロジェクトに構成プランが存在している必要があります。

構成プランの作成手順は、「ターゲット環境に応じてSOAコンポジット・アプリケーションをカスタマイズするための構成プランの使用方法」を参照してください。

BPELモニター

BPELモニターに関する詳細を表示する場合に展開します。

- BPELモニターのデプロイメント・エラーを無視します

注意: このチェック・ボックスは、アプリケーションに少なくとも1つの.monitorファイルがある場合のみ表示されます。

BPELモニターのデプロイメント・エラーを表示する場合は、このチェック・ボックスの選択を解除します。このチェック・ボックスは、monitor.config BPELプロジェクト・ファイルのignoreErrorsプロパティに対応しています。このファイルには、Oracle BAMサーバーに接続してOracle BAMデータ・オブジェクトとダッシュボードを作成するために必要なランタイム・プロパティとデプロイメント・プロパティが定義されています。Oracle BAMサーバーに接続できないときに、ignoreErrorsがtrueに設定されていると、コンポジットのデプロイメントは停止しません。falseに設定され、Oracle BAMサーバーが使用できない場合は、デプロイメントに失敗します。

コンポジット・リビジョンをデフォルトとしてマークします。

新規リビジョンをデフォルトにしない場合は、このボックスの選択を解除できます。デフォルトでは、新しくデプロイしたコンポジット・リビジョンがデフォルトになります。新しい要求が受信される場合に、このリビジョンはインスタンス化されます。

このオプションは、「デプロイメント・アクション」ページで「アプリケーション・サーバーにデプロイ」を選択した場合のみ表示されます。

同じリビジョンIDで既存のコンポジットを上書きします。

同じリビジョン値を持つ既存のSOAコンポジット・アプリケーションを上書きする場合に選択します。

このオプションは、「デプロイメント・アクション」ページで「アプリケーション・サーバーにデプロイ」を選択した場合のみ表示されます。

再デプロイ後にインスタンスの実行を続行します。

注意: このオプションはOracle JDeveloperにOracle BPM Suiteがインストールされている場合にのみ表示され、Oracle BPMコンポジットのデプロイに対してのみサポートされます。次をデプロイする場合はこのオプションを選択しないでください。

- Oracle BPM SuiteもインストールされているOracle JDeveloper環境のSOAコンポジット・アプリケーション

- 永続的なBPELプロセスが含まれているOracle BPMコンポジット(そのプロセスが変更されているかどうかにかかわらず)。永続的なBPELプロセスとは、実行が完了するまで時間がかかるプロセスです。永続的なBPELプロセスの例には、非同期プロセス(非同期プロセスは常に永続プロセスです)や、waitアクティビティなどの永続的なアクティビティが含まれる同期プロセスがあります。
このオプションを選択して永続的なBPELプロセスを再デプロイしようとすると、デプロイメントは失敗します。

上書きされたリビジョンの既存のインスタンスを有効にして、中断するのではなく実行を継続する場合に選択します。これらのインスタンスは、Oracle BPMコンポジット・アプリケーションの新規リビジョンで作成した新規インスタンスと並んで実行されます。

互換性のないプロセスのデプロイメントを強制します

このオプションは、Oracle BPM Suiteコンポジットに対してのみ表示されます。

「再デプロイ後にインスタンスの実行を続行します。」が選択されている場合、このオプションが表示されます。互換性のないBPMプロセスのデプロイメントを強制するには、このチェック・ボックスを選択します。BPMプロセスを含むコンポジットが上書きされる場合、上書きされるBPMプロセスがデプロイされるプロセスと互換性があるかどうかがチェックされます。互換性がある場合、これらのプロセスのインスタンスの実行は中断としてマークされず、デプロイメントは正常に実行されます。互換性がない場合は、このチェック・ボックスを選択しないとデプロイメントは失敗します。

すべてのコンポジットにSOA構成プランを使用します

「参照」をクリックして、すべてのコンポジット・アプリケーションに対して使用する同じ構成プランを選択します。このオプションは、複数のコンポジット・アプリケーションをデプロイする場合に使用します。

6. 終了したら、「次へ」をクリックします。

7. デプロイメント対象として選択したSOAプロジェクトに、ヒューマン・タスク用に定義したタスク・フロー・プロジェクトが含まれている場合は、図47-12 に示すように、「タスクフロー・デプロイメント」ダイアログが表示されます。
保存しない場合は、手順10に進みます。

ヒューマン・タスクのタスク・フロー・フォームに対するEnterprise Resource Archive (EAR)ファイルを作成または構成します。EARファイルは、このダイアログの「デプロイ可能なタスクフロー・プロジェクト」表で選択したWeb Resource Archive (WAR)プロファイルで構成されます。

図47-12 「タスクフロー・デプロイメント」ページ

8. 表47-7 の説明に従って、環境に適した値を指定します。

表47-7 「タスクフロー・デプロイメント」ダイアログ

フィールド

説明

アプリケーション名

デプロイメントに含めるEARファイルを選択します。このリストには、現行のOracle JDeveloperアプリケーションで使用可能なすべてのEARプロファイルが表示されます。これらのEARプロファイルは、EARプロファイルを作成し、「デプロイ可能なタスクフロー・プロジェクト」表で選択したWARプロファイルに基づいてデプロイする際に、テンプレートとして使用されます。デプロイする任意のEARプロファイル名を入力することもできます。

特定のコンポジット・リビジョンおよびパーティションにデプロイ

コンポジットのリビジョン番号をEARファイル名に追加する場合に選択します。このチェック・ボックスを選択すると、コンポジット・リビジョンがEAR名、WARプロファイルおよびコンテキスト・ルートに含められます。このオプションによって、コンポジット・リビジョン固有のアプリケーションをデプロイできます。

生成されたプロファイルをアプリケーションに追加

生成されたEARプロファイルを現行のSOAコンポジット・アプリケーションのEARデプロイメント・プロファイル・リストに追加する場合に選択します。生成されたEARプロファイルを保持するには、アプリケーションの保存が必要になる場合があります。デプロイメント・プロファイルが使用可能になると、「アプリケーション」→「デプロイ」の順に選択してEARプロファイルをデプロイできます。タスク・フロー・アプリケーションのデプロイメントのみが必要な場合は、このオプションを使用すると、「SOAデプロイ」ウィザードを使用する必要がありません。

既存のアプリケーションを上書き

サーバー上のEARファイルの既存のバージョンを上書きする場合に選択します。

デプロイ可能なタスクフロー・プロジェクト

EARファイルに含めるタスク・フロー・プロジェクトのWARプロファイルを選択します。タスク・フロー・プロジェクトのWARプロファイルは、そのタスク・フロー・プロジェクトに関連するヒューマン・タスクを含むコンポジットに従ってグループ化されます。「生成されたプロファイルをアプリケーションに追加」チェック・ボックスが選択されている場合は、WARのコンテキスト・ルートが変更されます。

注意: WARプロファイルを選択しないと、タスク・フローはデプロイされません。

- プロジェクト

「デプロイ可能なタスクフロー・プロジェクト」リストから選択するか、または「プロジェクト」チェック・ボックスを選択して使用可能なすべてのタスク・フローを選択します。タスク・フローは、デプロイメント対象として選択したSOAプロジェクトまたはバンドルに含まれるコンポジットに基づいて表示されます。

- WARプロファイル

タスク・フロー・プロジェクトのWARファイルを選択します。選択できるのは、最近作成または変更されたヒューマン・タスクのタスク・フローのみです。

- アプリケーション・コンテキスト・ルート

WARプロファイルの選択内容に基づいて、アプリケーション・コンテキスト・ルート・ディレクトリが表示されます。

ヒューマン・タスク用のタスク・フォームをデプロイすると、通知の一部として、タスク・フォームの詳細が電子メールに含められます。動的なペイロードの場合、この電子メールに含まれるペイロードの内容は、特定の時点のものとなります。

タスク・フローのあるSOAコンポジット・アプリケーションの複数パーティション環境へのデプロイの詳細は、「タスク・フローのあるヒューマン・タスク・コンポジットのパーティションへのデプロイに関する必知事項」を参照してください。

9. 「次へ」をクリックします。

10. 手順3で、アプリケーション・サーバーへのデプロイを選択した場合は、「サーバーの選択」ページが表示されます。このページでは、Oracle WebLogic Serverなどのアプリケーション・サーバーへの既存の接続をリストから選択するか、または「追加」アイコンをクリックしてサーバーへの新規接続を作成します。図47-13に詳細を示します。

手順3でSARファイルを生成することを選択した場合は、手順15に進みます。

図47-13 「サーバーの選択」ページ

11. 「次へ」をクリックします。

12. このアーカイブをデプロイするターゲットSOAサーバーを選択します。複数のサーバーまたはクラスタ・ノードがある場合は、1つまたは複数のサーバーあるいはノードへのデプロイを選択します。図47-14に詳細を示します。

13. このアーカイブをデプロイするパーティションを選択します。サーバーにパーティションがない場合、このアーカイブはデプロイできません。また、サーバーが実行中の状態でない場合も、このアーカイブはデプロイできません。デフォルトでは、Oracle SOA Suiteには、defaultという名前のパーティションが自動的に含まれています。パーティションは、Oracle Enterprise Manager Fusion Middleware Controlの「パーティションの管理」ページで作成します。

注意:

タスク・マップ属性(以前のフレックス・フィールド・マッピング)およびルール(例: 休暇ルール)などのヒューマン・ワークフロー・アーティファクトは、タスク定義のネームスペースに基づいて定義されます。そのため、ヒューマン・ワークフロー・タスクのあるSOAコンポジット・アプリケーションを複数のパーティションにデプロイする場合は、次の問題が発生します。

- タスク定義タイプが同じ場合は、あるパーティションで定義されたマップ属性は他のパーティションでも参照できます。

- あるパーティションのタスク定義で定義されたルールは、他のパーティションの同じ定義に適用できます。

図47-14 「SOAサーバー」ページ

14. 「次へ」をクリックします。

15. 図47-15 に示されている「サマリー」ページでアーカイブの詳細を確認し、「終了」をクリックします。

図47-15 「サマリー」ページ

16. 手順3で、アプリケーション・サーバーへのデプロイを選択した場合は、Oracle JDeveloperの下部にあるデプロイメント・ログ・ウィンドウに表示されるメッセージを確認します。

17. ユーザー名とパスワードを入力し、「OK」をクリックします。
デプロイメントに成功した場合は、次の処理が実行されます。

- SOAプロジェクト用のJARファイルが、sca_composite_name_revrevision_number.jarの命名規則で作成されます。

- プロジェクトが、「リソース」ウィンドウの「application_server_connection_name」→「SOA」→「SOA_server_name」→「partition_name」の下に表示されます。

- プロジェクトが、「application_server_connection_name」→「SOA」→「SOA_server_name」→「partition_name」の下の「アプリケーション・サーバー」ウィンドウに表示されます。

これで、Oracle Enterprise Manager Fusion Middleware Controlからアプリケーションを監視できるようになります。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

デプロイメントに失敗した場合は、デプロイメント・ログ・ウィンドウに表示されているメッセージを確認して、修正処理を実行してください。詳細は、「テストおよびトラブルシューティング」を参照してください。

パーティションの作成の詳細は、次のドキュメントを参照してください。

- antスクリプトを使用したSOAコンポジット・アプリケーションのデプロイおよび管理

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

- SOA Suite用WLSTコマンド・リファレンス

注意:

同じバージョンのSOAコンポジット・アプリケーションを再デプロイする場合、コンポジット名は変更できません。「構成のデプロイ」ページで「同じリビジョンIDで既存のコンポジットを上書きします。」チェック・ボックスを選択した場合は、同じリビジョン番号でデプロイできます。

47.7.1.4 タスク・フローのあるヒューマン・タスク・コンポジットのパーティションへのデプロイに関する注意事項

タスク・フローのあるSOAコンポジット・アプリケーションをOracle JDeveloperから複数パーティション環境にデプロイするには、デプロイ先パーティションがSOAコンポジット・アプリケーションのデプロイ先と同じであるタスク・フローを選択します。

EARプロファイル(EARデプロイヤを使用してタスク・フローをデプロイ)のみを使用してデプロイしたタスク・フローの場合、そのタスク・フローはパーティションに非対応です。したがって、生成されるEARファイルにパーティション名が含まれるように、hwtaskflow.xmlファイルを変更する必要があります(ファイルのプロジェクト・バージョンは変更されずに残ります)。このファイルはTaskFormプロジェクトのadfmsrcディレクトリの下に配置されます(例: HelpDeskRequestTaskFlow\adfmsrc\hwtaskflow.xml)。次の例に詳細を示します。

<hwTaskFlows
xmlns="http://xmlns.oracle.com/bpel/workflow/hwTaskFlowProperties">
<ApplicationName>worklist</ApplicationName>
<LookupType>LOCAL</LookupType>
<TaskFlowDeploy>false</TaskFlowDeploy>
<PartitionName>partition2</PartitionName>

すべてのパーティションでSOAコンポジット・アプリケーションのタスク・フローをデプロイする場合は、PartitionNameを空白のままにします。異なるパーティション上のコンポジットにそれぞれ異なるタスク・フローを使用する場合は、PartitionNameを指定する必要があります。

なお、別のパーティションで同じタスク・フロー・プロジェクトを再利用する場合は、Webコンテキスト・ルートを変更する必要があります。

47.7.2 Oracle JDeveloperでの複数のSOAコンポジット・アプリケーションのデプロイ方法

SOAバンドル・プロファイルを使用して、複数のSOAコンポジット・アプリケーションをOracle WebLogic Serverなどのアプリケーション・サーバーに同時にデプロイできます。このプロファイルにより、1つ以上のSARプロファイルをバンドルに含めて、そのバンドルをアプリケーション・サーバーにデプロイできます。

注意:

- この項では、アプリケーション・サーバー接続が作成済であることを前提にしています。作成していない場合は、「アプリケーション・サーバー接続の作成」で手順を参照してください。

- 同じSOAバンドル・プロファイル内で相互に依存している複数のSOAアプリケーションはデプロイできません。たとえば、アプリケーションAがアプリケーションBをコールする場合は、最初にアプリケーションBを個別にデプロイする必要があります。

複数のSOAコンポジット・アプリケーションをデプロイする手順は、次のとおりです。

1. 図47-16 に示すように、「アプリケーション」メニューから「アプリケーション・プロパティ」を選択します。

図47-16 「アプリケーション・プロパティ」

2. 「アプリケーション・プロパティ」ダイアログで、「デプロイメント」をクリックします。

3. 「新規」をクリックします。

「デプロイメント・プロファイルの作成」ダイアログが表示されます。

4. 「アーカイブ・タイプ」リストから、「SOAバンドル」を選択します。

5. 「名前」フィールドに、名前を入力します。

図47-17に詳細を示します。

図47-17 「SOAバンドル」の選択

6. 「OK」をクリックします。

7. 左側のナビゲータで、「依存性」ノードを選択します。

8. 図47-18 に示すように、このバンドルに含めるSARを選択します。

図47-18 SARの選択

9. 「OK」をクリックします。

10. 「OK」をクリックして「アプリケーション・プロパティ」ダイアログを閉じます。

11. 「アプリケーション」メニューを再度選択し、「デプロイ」→「SOA_Bundle_Name」の順に選択します。

これによりデプロイメント・ウィザードが起動します。

12. 指定する値に関する詳細は、ステップ3を参照してください。

47.7.3 Oracle JDeveloperでの複数のSOAコンポジット・アプリケーション間の共有データのデプロイ方法および使用方法

この項では、複数のSOAコンポジット・アプリケーション間でWSDL、XSD、および他のファイル・タイプなど共有データをデプロイおよび使用する方法について説明します。

共有データは、アプリケーション・サーバー上のSOAインフラストラクチャにJARファイルとしてデプロイされます。JARファイルには、共有するすべてのリソースが含まれている必要があります。Oracle JDeveloperでは、共有アーティファクト・アーカイブを作成するためのJARプロファイルを作成できます。

すべての共有データは、サーバー上の既存のSOAインフラストラクチャ・パーティションにデプロイされます。このデータは、/appsネームスペースの下にデプロイされます。たとえば、JARファイルにMyProject/xsd/MySchema.xsdファイルがある場合、このファイルはサーバー上の/appsネームスペースの下にデプロイされます。Oracle JDeveloperでSOA-MDS接続を使用してこのアーティファクトを参照する場合、URLはoramds:/apps/MyProject/xsd/MySchema.xsdになります。

注意:

- 常に、/appsの場所にデプロイします。ディレクトリ階層は、デプロイするJARファイル内に存在している必要があります。最初にOracle MDSリポジトリ内にディレクトリ階層を作成してから、その場所にJARファイルをデプロイしないでください。たとえば、/apps/demo/credit cardにデプロイするには、JARファイル内にdemo/credit cardディレクトリ階層が含まれている必要があります。

- ピリオドから始まるファイル(.designerなど)は、複数のSOAコンポジット・アプリケーション間で共有できません。

この項では、次のタスクの実行方法について説明します。

- JARプロファイルの作成および共有するアーティファクトの組込み

- JARプロファイルを組み込むSOAバンドルの作成

- アプリケーション・サーバーへのSOAバンドルのデプロイ

47.7.3.1 JARプロファイルの作成および共有するアーティファクトの組込み

JARプロファイルを作成し、共有するアーティファクトを組み込む手順は、次のとおりです。

1. 「アプリケーション」ウィンドウで、「SOA」プロジェクトを右クリックします。

2. 「プロジェクト・プロパティ」を選択します。

「プロジェクト・プロパティ」ダイアログが表示されます。

3. 左側のナビゲーション・ツリーにある「デプロイメント」をクリックします。

4. 「新規」をクリックします。

「デプロイメント・プロファイルの作成」ダイアログが表示されます。

5. 「アーカイブ・タイプ」リストから、「JARファイル」を選択します。

6. 「名前」フィールドに、名前を入力します(この例ではshared_archiveが入力されています)。

「デプロイメント・プロファイルの作成」ダイアログは、図47-19 のようになります。

図47-19 JARファイルの選択

7. 「OK」をクリックします。

「JARデプロイメント・プロファイルのプロパティ」ダイアログが表示されます。

8. 左側のナビゲーション・ツリーから「JARオプション」を選択します。

9. 図47-20 に示すように、「manifestファイルを含める(META-INF/MANIFEST.MF)」の選択を解除します。

選択を解除すると、アーカイブ・ジェネレータによってmanifestファイル(META-INF/MANIFEST.MF)がJARファイルに追加されることはありません。

図47-20 JARファイルのオプション

10. 左側のナビゲーション・ツリーから、「ファイル・グループ」→「プロジェクトの出力」→「コントリビュータ」の順に選択します。

11. 図47-21 に示すように、「プロジェクトの出力ディレクトリ」および「プロジェクトの依存性」オプションの選択を解除します。

選択を解除すると、アーカイブ・ジェネレータによって、プロジェクトの出力およびプロジェクトの依存性の内容がアーカイブに追加されることはありません。

図47-21 「コントリビュータ」

12. 「追加」をクリックして、新しいコントリビュータを追加します。

「コントリビュータの追加」ダイアログが表示されます。このダイアログで、アーティファクトをアーカイブに追加できます。

13. 「参照」をクリックします。

14. 図47-22 に示すように、アーティファクトが存在するフォルダを選択します。この選択によって、アーカイブ内のアーティファクトの階層も決まります。

図47-22 アーティファクトの選択

15. 「選択」をクリックして、「ディレクトリの選択」ダイアログを閉じます。

16. 「OK」をクリックして「コントリビュータの追加」ダイアログを閉じます。

17. 左側のナビゲーション・ツリーから、「ファイル・グループ」→「プロジェクトの出力」→「フィルタ」の順に選択します。

18. 図47-23 に示すように、アーカイブに組み込むアーティファクトのみ選択します。この例では、次のXSDファイルが含まれます。

- SOADemoComposite/xsd/DemoProcess.xsd

- SOADemoComposite/xsd/Quote.xsd

- SOADemoComposite/xsd/VacationRequest.xsd

図47-23 アーカイブに組み込むアーティファクト

19. 「OK」をクリックして、変更内容をJARデプロイメント・プロファイルに保存します。

20. 「OK」をクリックして、新規デプロイメント・プロファイルを保存します。

21. 「ファイル」メイン・メニューから、「すべて保存」を選択します。

47.7.3.2 JARプロファイルを組み込むSOAバンドルの作成

JARプロファイルを組み込むSOAバンドルを作成する手順は、次のとおりです。

1. 「アプリケーション・メニュー」から、「アプリケーション・プロパティ」→「デプロイメント」の順に選択します。

2. 「新規」をクリックして、SOAバンドル・プロファイルを作成します。

「デプロイメント・プロファイルの作成」ダイアログが表示されます。

3. 「アーカイブ・タイプ」リストから、「SOAバンドル」を選択します。バンドルは、複数のSOAコンポジット・アプリケーションの集まりです。

4. 「名前」フィールドに名前(例ではsharedArtifactBundle)を入力します。図47-24に詳細を示します。

図47-24 SOAバンドルの作成

5. 「OK」をクリックします。

6. 左側のナビゲーション・ツリーから「依存性」を選択します。

7. 以前に作成したJARファイルおよびSOA-SARプロファイルを選択します(この例では、それぞれshared_archiveおよびsharedArtifactBundle)。JAR、SOA-SARまたは両方のいずれかを選択できます。図47-25に詳細を示します。

図47-25 デプロイメント・プロファイルの依存性

8. 「OK」をクリックして、SOAバンドル・デプロイメント・プロファイルの変更内容を保存します。

9. 「OK」をクリックして、新規デプロイメント・プロファイルを保存します。

10. 「ファイル」メイン・メニューから、「すべて保存」を選択します。

47.7.3.3 Oracle JDeveloperでのSOAバンドルのデプロイ

Oracle JDeveloperでSOAバンドルをデプロイする手順は、次のとおりです。

1. 「アプリケーション」メニューを右クリックし、「デプロイ」→「SOA_Bundle_Name」の順に選択します。

これによりデプロイメント・ウィザードが起動します。

2. 指定するレスポンスの詳細は、「プロファイルのデプロイ」の手順3を参照してください。

これによって、SOAバンドルがアプリケーション・サーバーにデプロイされます(共有アーティファクトがOracle SOA SuiteのOracle MDSリポジトリ・データベースにデプロイされます)。

47.7.3.3.1 antでSOAバンドルをデプロイする手順:

「SOAコンポジット・アプリケーションをデプロイするためのantの使用方法」を参照してください。

47.7.3.4 共有データの使用

この項では、「Oracle JDeveloperでの複数のSOAコンポジット・アプリケーション間の共有データのデプロイ方法および使用方法」で作成した共有データを参照および選択する方法について説明します。

47.7.3.4.1 SOA-MDS接続の作成

SOA-MDS接続を作成するには:

1. 「ファイル」メニューから、「新規」→「アプリケーション」→「接続」→「SOA-MDS接続」を選択します。

図47-26 に示す「SOA-MDS接続の作成」ダイアログが表示されます。

図47-26 「SOA-MDS接続の作成」ダイアログ

2. 表47-8 に示すように、環境に適した値を指定します。

表47-8 「SOA-MDS接続の作成」ダイアログ

フィールド

説明

接続の作成場所

「IDE接続」が選択されていることを確認します。このオプションを選択すると、「リソース」ウィンドウに接続が表示され、複数のアプリケーションで接続が使用できるようになります。

「アプリケーション・リソース」オプションで接続を作成することはできません。この選択は無効化されています。

接続名

接続名を入力します。この接続の作成が正常に完了すると、この名前が「リソース」ウィンドウのSOA-MDSの下に表示されます。

接続タイプ

接続タイプを選択します。Oracle MDSリポジトリはファイル・ベースまたはデータベース・ベースのいずれかです。選択内容に基づいてダイアログがリフレッシュされます。

- DBベースMDS
ほとんどの本番環境では、データベース・ベース・リポジトリを使用します。Oracle SOA Suiteなど、ほとんどのコンポーネントではスキーマがデータベースにインストールされている必要があるため、データベース・ベース・リポジトリを使用する必要があります。データベース・ベース・リポジトリを使用するには、最初に、このリポジトリをリポジトリ作成ユーティリティを使用して作成する必要があります。

- ファイル・ベースMDS

データベース接続を選択します。

既存の接続を選択するか、MDSスキーマが含まれているOracle SOA Suiteデータベースへの新規接続を作成します。

MDSパーティションの選択

MDSパーティション(例: soa-infra)を選択します。

接続のテスト

SOA-MDS接続をテストする場合にクリックします。

注意: 接続テストに失敗した場合でも接続は作成されます。

ステータス

接続テストのステータスが表示されます。

3. 「OK」をクリックします。

これで、「リソース」ウィンドウ内の接続を参照し、/appsノードの下の共有アーティファクトを表示できます。

47.7.3.4.2 BPELプロセスの作成

これで、様々なSOAコンポジット・アプリケーションから共有データを参照し、使用できる状態になりました。この例では、様々なアプリケーションにBPELプロセス・サービス・コンポーネントを作成します。

BPELプロセスを作成する手順は、次のとおりです。

1. 様々なアプリケーションに新規BPELプロセス・サービス・コンポーネントを作成します。

2. 「BPELプロセスの作成」ダイアログで、「入力」フィールドの右側にある「参照」アイコンをクリックします。

「タイプ・チューザ」ダイアログが表示されます。

3. 右上隅にある「スキーマ・ファイルのインポート」アイコンをクリックします。

「スキーマ・ファイルのインポート」ダイアログが表示されます。

4. 「URL」フィールドの右側にある「参照」アイコンをクリックします。

「SOAリソース・ブラウザ」ダイアログが表示されます。

5. ダイアログの最上部で「SOA-MDS」を選択します。

6. 共有データを選択します。この例では、「JARプロファイルの作成および共有するアーティファクトの組込み」の手順18でアーカイブへの組込みを選択したQuote.xsdファイルが選択されています。

7. 「OK」をクリックします。

8. 「スキーマ・ファイルのインポート」ダイアログで「OK」をクリックします。

9. 「タイプ・チューザ」ダイアログで、Quote.xsdのノード(この例ではQuoteRequest)を選択し、「OK」をクリックします。

10. 「BPELプロセスの作成」ダイアログで、「OK」をクリックして作成を完了します。

11. 「アプリケーション」ウィンドウで、BPELプロセスのWSDLファイルを選択します。

12. 「ソース」をクリックします。

WSDLファイルには、次の定義が含まれています。

<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://www.mycompany.com/ns/salesquote"
schemaLocation="oramds:/apps/SOADemoComposite/xsd/Quote.xsd" />
</schema>
</wsdl:types>

13. 必要に応じて、BPELプロセスのモデル化を続行します。

14. BPELプロセスを組み込んだSOAコンポジット・アプリケーションをデプロイします。

「タイプ・チューザ」ダイアログには「最近使用したファイル」フォルダが含まれ、このフォルダの情報はOracle JDeveloperセッションの間保持されます。たとえば、新しいBPELプロセスを作成し、SOAデザインタイムMDSリポジトリのスキーマから入力変数を定義する場合は、一度このスキーマに移動します。同じスキーマから出力変数を定義する場合は、そのスキーマは「最近使用したファイル」フォルダに引き続き表示されています。

47.7.4 Oracle JDeveloperでの既存のSOAアーカイブのデプロイ方法

Oracle JDeveloperの「アプリケーション・サーバー」ウィンドウから、既存のSOAアーカイブをデプロイできます。

注意:

- アーカイブは存在している必要があります。「SOAアーカイブのデプロイ」ダイアログではアーカイブを作成できません。

- ここで説明する手順は、SOAインフラストラクチャがデプロイされたOracle WebLogic管理サーバーまたはその他のサポートされているアプリケーション・サーバーへのアプリケーション・サーバー接続が作成済であることを前提にしています。Oracle WebLogic管理サーバーへの接続を作成すると、同じドメインにデプロイされたSOAコンポジット・アプリケーションを参照できます。「ファイル」メイン・メニューから、「新規」→「アプリケーション」→「接続」→「アプリケーション・サーバー接続」を選択して、接続を作成します。

Oracle JDeveloperから既存のSOAアーカイブをデプロイする手順は、次のとおりです。

1. 「ウィンドウ」メニューから、「アプリケーション・サーバー」を選択します。

2. 「アプリケーション」ウィンドウで、接続名を開きます。

3. 「SOA」フォルダを右クリックします。

4. 「SOAアーカイブのデプロイ」を選択します。

図47-27 「アプリケーション」ウィンドウからのSOAアーカイブ・デプロイメント

図47-28 に示す「SOAアーカイブのデプロイ」ダイアログが表示されます。

図47-28 「SOAアーカイブのデプロイ」ダイアログ

5. 表47-9 の説明に従って、環境に適した値を指定します。

表47-9 「SOAアーカイブのデプロイ」ダイアログのフィールドと値

フィールド

説明

SOAサーバー

アーカイブをデプロイするSOAサーバーを選択します。

パーティション

アーカイブをデプロイするパーティションを選択します。サーバーにパーティションがない場合、このアーカイブはデプロイできません。デフォルトでは、Oracle SOA Suiteには、defaultという名前のパーティションが自動的に含まれています。

ステータス

サーバーのステータスが表示されます。サーバーが実行中の状態でない場合、このアーカイブはデプロイできません。

サーバーURL

サーバーのURLが表示されます。

アーカイブの場所

「参照」をクリックして、ビルトインのSOAコンポジット・アプリケーション・アーカイブを選択します。アーカイブは、単一アプリケーションのJARファイル、または複数のアプリケーションを含むSOAバンドルZIPファイルで構成されています。

構成プラン(オプション)

「参照」をクリックして、SOAコンポジット・アプリケーション・アーカイブに添付する構成プランを選択します。構成プランを使用して、異なる環境で使用するURLおよびプロパティ値を定義できます。構成プランは、プロセスのデプロイメント時に、プロジェクトを別のターゲット環境に適合させるために置換する必要のある値に関するSOAプロジェクトを検索する際に使用されます。

構成プランの作成方法の詳細は、「Oracle JDeveloperでの構成プランの作成方法」または「WLSTユーティリティを使用した構成プランの作成方法」を参照してください。

コンポジット・リビジョンをデフォルトとしてマークします。

新規リビジョンをデフォルトにしない場合は、このボックスの選択を解除できます。デフォルトでは、新しくデプロイしたコンポジット・リビジョンがデフォルトになります。新しい要求が受信される場合に、このリビジョンはインスタンス化されます。

同じリビジョンIDで既存のコンポジットを上書きします。

同じリビジョンIDを持つ既存のSOAコンポジット・アプリケーションを上書き(再デプロイ)する場合に選択します。このアクションの結果は次のようになります。

- SOAコンポジット・アプリケーションの新規バージョン1.0が再デプロイされ、以前にデプロイした1.0バージョンが上書きされます。

- 現在デプロイされているこのリビジョンの古いバージョンは削除(上書き)されます。

- 古い方のバージョン、つまりこのリビジョンの現在デプロイされているバージョンがインスタンスを実行している場合、インスタンスの状態が中止になります。

6. 「OK」をクリックします。

「アプリケーション・サーバー」ウィンドウからSOAコンポジット・アプリケーションをデプロイおよびテストする方法の詳細は、「SOAコンポジット・アプリケーションの管理とテスト」を参照してください。

47.8 WLSTユーティリティを使用したSOAコンポジット・アプリケーションのデプロイおよび管理

WLSTユーティリティを使用して、SOAコンポジット・アプリケーションを管理できます。このユーティリティは、自動化に適しており、既存リリースのプロセスに容易に統合できます。手順は、SOA Suite用WLSTコマンド・リファレンスを参照してください。

47.9 antスクリプトを使用したSOAコンポジット・アプリケーションのデプロイおよび管理

antユーティリティを使用して、SOAコンポジット・アプリケーションを管理できます。antはJavaベースのビルド・ツールであり、SOAコンポジット・アプリケーションを管理するためにOracle SOA Suiteで使用されます。構成ファイルはXMLベースであり、様々なタスクが実行されるターゲット・ツリーをコールします。 ant ユーティリティは、自動化に適しており、既存リリースのプロセスに容易に統合できます。

注意:

Oracle SOA Suiteのantスクリプトを使用する前に、setDomainEnv.shスクリプト(Linuxの場合)またはsetDomainEnv.cmdスクリプト(Windowsの場合)を実行する必要があります。このスクリプトによって、antを使用するために必要なJARファイルがクラスパスに追加されます。

表47-10 に、Middleware_Home\SOA_Suite_Home\binディレクトリで使用可能なantスクリプトを示します。

表47-10 ant管理スクリプト

スクリプト

説明

ant-sca-test.xml

SOAコンポジット・アプリケーションのテストを自動化します。

ant-sca-compile.xml

SOAコンポジット・アプリケーションをコンパイルします。

ant-sca-package.xml

SOAコンポジット・アプリケーションをコンポジットSARファイルにパッケージ化します。

ant-sca-deploy.xml

SOAコンポジット・アプリケーションをデプロイします。

ant-sca-deploy.xml undeploy

SOAコンポジット・アプリケーションをアンデプロイします。

ant-sca-deploy.xml exportComposite

コンポジットをSARファイルにエクスポートします。

ant-sca-deploy.xml exportUpdates

コンポジットのデプロイメント後の変更をJARファイルにエクスポートします。

ant-sca-deploy.xml importUpdates

コンポジットのデプロイメント後の変更をインポートします。

ant-sca-deploy.xml exportSharedData

指定されたパターンの共有データをJARファイルにエクスポートします。

ant-sca-deploy.xml removeSharedData

最上位の共有データ・フォルダを削除します。

ant-sca-mgmt.xml startComposite

SOAコンポジット・アプリケーションを起動します。

ant-sca-mgmt.xml stopComposite

SOAコンポジット・アプリケーションを停止します。

ant-sca-mgmt.xml activateComposite

SOAコンポジット・アプリケーションをアクティブ化します。

ant-sca-mgmt.xml retireComposite

SOAコンポジット・アプリケーションをリタイアします。

ant-sca-mgmt.xml assignDefaultComposite

デフォルトのリビジョン・バージョンを割り当てます。

ant-sca-mgmt.xml listDeployedComposites

デプロイ済のSOAコンポジット・アプリケーションが一覧表示されます。

ant-sca-mgmt.xml listPartitions

SOAインフラストラクチャで使用可能なすべてのパーティションが一覧表示されます。

ant-sca-mgmt.xml listCompositesInPartition

パーティション内のすべてのコンポジットを一覧表示します。

ant-sca-mgmt.xml createPartition

SOAインフラストラクチャにパーティションを作成します。

ant-sca-mgmt.xml deletePartition

パーティションを削除する前に、パーティション内のすべてのコンポジットをアンデプロイします。

ant-sca-mgmt.xml startCompositesInPartition

パーティション内のすべてのコンポジットを起動します。

ant-sca-mgmt.xml stopCompositesInPartition

パーティション内のすべてのコンポジットを停止します。

ant-sca-mgmt.xml activateCompositesInPartition

パーティション内のすべてのコンポジットをアクティブ化します。

ant-sca-mgmt.xml retireCompositesInPartition

パーティション内のすべてのコンポジットをリタイアします。

ant-sca-upgrade.xml

BPELおよびOracle Enterprise Service Bus (ESB)リリース10.1.3のメタデータをリリース11gに移行します。

注意: プロジェクト内にJavaコードが含まれている場合、11gのコンパイラで正常にコンパイルするには、コードを手動で変更する必要があります。BPELプロセスのインスタンス・データについては、10.1.3 Oracle BPEL Serverで使用されるアクティブ・データは移行されません。

antの詳細は、次のURLを参照してください。

http://ant.apache.org

47.9.1 SOAコンポジット・アプリケーションのテストを自動化するためのantの使用方法

次に、テスト・ケースの実行例を示します。テスト・ケースを使用すると、SOAコンポジット・アプリケーションのテストを自動化できます。

ant -f ant-sca-test.xml -Dscatest.input=MyComposite
-Djndi.properties=/home/jdoe/jndi.properties

表47-11 に、構文を示します。

表47-11 antテスト・コマンド

引数

定義

scatest

使用可能な入力は、次のとおりです。

- java.passed.home
JAVA_HOMEの環境値から取得されます。オーバーライドする場合は、この入力を指定します。

- wl_home
Oracle WebLogic Serverホームの場所です(デフォルトはOracle_Home/.../wlserver_10.3)。

- scatest.input
テストするコンポジットの名前。

- scatest.format
出力ファイルのフォーマット(デフォルトはnative。他のオプションはjunit)。

- scatest.result
出力ファイルを格納する結果のディレクトリ(デフォルトはtemp_dir/out)。

- jndi.properties.input
使用するjndi.propertiesファイル。

jndi. properties

JNDIプロパティ・ファイルの絶対パス。これは、サーバーに接続するためのJNDIプロパティが含まれているプロパティ・ファイルです。次に例を示します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.provider.url=t3://myserver.us.example.com:8001/soa-infra
java.naming.security.principal=weblogic
dedicated.connection=true
dedicated.rmicontext=true

(テスト・スイート内の)コンポジット・テストはSOAインフラストラクチャで実行されるため、このプロパティ・ファイルには接続情報が含まれています。この例では、これらのプロパティによって、myserver.us.example.com、ポート8001でホストされるSOAインフラストラクチャへの接続が作成され、ユーザー名weblogicが使用されます。パスワードについては、指定を求めるプロンプトが表示されます。

通常は、1つのjndi.propertiesファイルを(たとえば/home/myhome/jndi.propertiesに)作成し、そのファイルをすべてのテスト実行に対して使用します。

SOAコンポジット・アプリケーションにおけるテストの作成方法および実行方法の詳細は、「SOAコンポジット・アプリケーションのテストの自動化」および『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

47.9.2 SOAコンポジット・アプリケーションをコンパイルするためのantの使用方法

次に、SOAコンポジット・アプリケーションのコンパイル例を示します。このコンパイルでは、アプリケーションの構造および構文が検証されます。

ant -f ant-sca-compile.xml
-Dscac.input=/myApplication/myComposite/composite.xml

表47-12 に、構文を示します。

表47-12 antコンパイル・コマンド

引数

定義

scac

使用可能な入力は、次のとおりです。

- java.passed.home
JAVA_HOMEの環境値から取得されます。オーバーライドする場合は、この入力を指定します。

- wl_home
これはOracle WebLogic Serverホームの場所です。

- scac.input
コンパイルするcomposite.xmlファイル。

- scac.output
scacの結果が格納される出力ファイル(デフォルトはtemp_dir/out.xml)。

- scac.error
scacのエラーが格納されるファイル(デフォルトはtemp_dir/out.err)。

- scac.application.home
.adfディレクトリが内部に含まれている、コンパイル中のSOAコンポジット・アプリケーションのOracle JDeveloperアプリケーション・ホーム・ディレクトリ。

- scac.displayLevel
scac.outputファイルに書き込まれるログのレベルを制御します。値は、1、2または3のいずれかです(デフォルトは1)。

47.9.3 コンポジットSARファイルにSOAコンポジット・アプリケーションをパッケージ化するためのantの使用方法

次に、SOAコンポジット・アプリケーションをコンポジットSARファイルにパッケージ化する例を示します。このコマンドの結果はSOAアーカイブです。結果ファイルの正確な場所については、コマンドの出力を確認してください。

ant -f ant-sca-package.xml
-DcompositeDir=C:\demo\end2end-105-POProcessing\po\solutions\ch9\POProcessing\POPr
ocessing
-DcompositeName=POProcessing
-Drevision=6-cmdline
-Dsca.application.home=C:\demo\end2end-105-POProcessing\po\solutions\ch9\POProces
sing

表47-13 に、構文を示します。

表47-13 antパッケージ化コマンド

引数

定義

compositeDir

コンポジット・アーティファクトを含むディレクトリの絶対パス。

compositeName

コンポジットの名前。

revision

コンポジットのリビジョンID。

sca.application.home

アプリケーション・ホーム・ディレクトリの絶対パス。このプロパティは、SOAコンポジット・アプリケーションがMDSリポジトリ内の共有アーティファクトにアクセスする場合に必要です。それ以外の場合は、オプションです。

oracle.home

オプション。oracle.homeプロパティ。

47.9.4 SOAコンポジット・アプリケーションをデプロイするためのantの使用方法

次に、SOAコンポジット・アプリケーションのデプロイ例を示します。このコマンドを使用して、複数のSOAコンポジット・アプリケーション間でWSDL、XSD、および他のファイル・タイプなど共有データをデプロイすることもできます。共有データの詳細は、「Oracle JDeveloperでの複数のSOAコンポジット・アプリケーション間の共有データのデプロイ方法および使用方法」を参照してください。

ant -f ant-sca-deploy.xml
-DserverURL=http://localhost:8001
-DsarLocation=C:\demo\end2end-105-POProcessing\po\solutions\ch9\POProcessing\POPro
cessing\deploy\sca_POProcessing_rev6-cmdline.jar
-Doverwrite=true
-Duser=weblogic
-DforceDefault=true
-Dconfigplan=C:\demo\end2end-105-POProcessing\po\solutions\ch9\POProcessing\POProc
essing\demed_cfgplan.xml
-Dscac.user.classpath=C:\jarfolder\custom.jar
-Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-14 に、構文を示します。

表47-14 antデプロイメント・コマンド

引数

定義

serverURL

SOAインフラストラクチャ・アプリケーションをホストするサーバーのURL(例: http://myhost10:8001)。

sarLocation

次のいずれかの絶対パス。

- SARファイル

- 複数のSARを含むZIPファイル

overwrite

オプション。サーバー上の既存のSOAコンポジット・アプリケーションを上書きするかどうかを指定します。

- false (デフォルト): ファイルは上書きされません。

- true: ファイルは上書きされます。

user

オプション。基本認証が構成される場合、コンポジット・デプロイヤ・サーブレットにアクセスするためのユーザー名。

password

オプション。基本認証が構成される場合、コンポジット・デプロイヤ・サーブレットにアクセスするためのパスワード。

ユーザー名を入力した場合、ここでパスワードを指定しないとパスワードの入力を求めるプロンプトが表示されます。

forceDefault

オプション。デプロイするバージョンを、そのコンポジット・アプリケーションに対するデフォルト・バージョンとして設定するかどうかを指定します。

- true (デフォルト): そのコンポジットをデフォルト・コンポジットにします。

- false: そのコンポジットをデフォルト・コンポジットにしません。

configplan

ZIPファイルに含まれる特定のSARファイルまたはすべてのSARファイルに適用される構成プランの絶対パス。

sysPropFile

デバッグ用、SSL構成用など、特別なシステム・プロパティの設定に有効なシステム・プロパティ・ファイルを渡します。

ファイル名(例: tmp-sys.properties)を指定した場合は、プロパティを次のように定義できます。

javax.net.debug=all

scac.user.classpath

オプション。外部カスタム・ライブラリの名前。SOAコンポジット・アプリケーションのBPELプロセス・サービス・コンポーネントでカスタムJARファイルを参照している場合は、このプロパティを設定します。

partition

オプション。SOAコンポジット・アプリケーションをデプロイするパーティションの名前。デフォルト値はdefaultです。パーティションを指定しないと、コンポジットはdefaultパーティションに自動的にデプロイされます。

注意:

タスク・マップ属性(以前のフレックス・フィールド・マッピング)およびルール(例: 休暇ルール)などのヒューマン・ワークフロー・アーティファクトは、タスク定義のネームスペースに基づいて定義されます。そのため、ヒューマン・ワークフロー・タスクのあるSOAコンポジット・アプリケーションを複数のパーティションにデプロイする場合は、次の問題が発生します。

- タスク定義タイプが同じ場合は、あるパーティションで定義されたマップ属性は他のパーティションでも参照できます。

- あるパーティションのタスク定義で定義されたルールは、他のパーティションの同じ定義に適用できます。

47.9.5 SOAコンポジット・アプリケーションをアンデプロイするためのantの使用方法

次に、SOAコンポジット・アプリケーションのアンデプロイ例を示します。

ant -f ant-sca-deploy.xml undeploy
-DserverURL=http://localhost:8001
-DcompositeName=POProcessing
-Drevision=rev6-cmdline
-Duser=weblogic
-Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-15 に、構文を示します。

表47-15 antアンデプロイメント・コマンド

引数

定義

serverURL

SOAインフラストラクチャ・アプリケーションをホストするサーバーのURL (たとえば、http://myhost10:7001)。

compositeName

SOAコンポジット・アプリケーションの名前。

revision

SOAコンポジット・アプリケーションのリビジョンID。

user

オプション。基本認証が構成される場合、コンポジット・デプロイヤ・サーブレットにアクセスするためのユーザー名。

ユーザー名を入力すると、対応するパスワードの入力を求めるプロンプトが表示されます。

password

オプション。基本認証が構成される場合、コンポジット・デプロイヤ・サーブレットにアクセスするためのパスワード。

partition

オプション。SOAコンポジット・アプリケーションが置かれているパーティションの名前。デフォルト値はdefaultです。パーティションを指定しないと、SOAコンポジット・アプリケーションのdefaultパーティションが検索されます。他のパーティションは検索されません。

47.9.6 SARファイルにコンポジットをエクスポートするためのantの使用方法

次に、SARファイルへのコンポジットのエクスポート例を示します。

ant -f ant-sca-deploy.xml exportComposite -DserverURL=server.url
-DupdateType=update.type -DsarFile=sar.file
-DcompositeName=composite.name -Drevision=revision -Duser=user

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-16 に、構文を示します。

表47-16 antエクスポート・コマンド

引数

定義

serverURL

SOAインフラストラクチャ・アプリケーションをホストするサーバーのURL(例: http://myhost:8001)。

updateType

エクスポートに含めるデプロイメント後の変更のタイプ。

- none: デプロイメント後の変更を含めません。

- all: デプロイ後の変更がすべて含まれます。

- property: プロパティの変更が含まれます(バインディング・コンポーネント・プロパティ、監査レベル設定やペイロード検証ステータスなどのコンポジット・プロパティ、およびポリシー・アタッチメント)。

- runtime: デプロイ後の実行時の変更が含まれます(ルール・ディクショナリおよびドメイン値マップ(DVM))。

sarFile

生成されるSARファイルの絶対パス。

compositeName

エクスポートするコンポジットの名前。

revision

エクスポートするコンポジットのリビジョン。

user

オプション。サーバーにアクセスするためのユーザー名(基本構成が行われている場合)。

password

オプション。サーバーにアクセスするためのパスワード(基本構成が行われている場合)。

次の例は、デプロイメント後の変更を含めずにコンポジットをエクスポートする方法を示しています。

ant -f ant-sca-deploy.xml exportComposite -DserverURL=http://myhost:8001
-DupdateType=none
-DsarFile=/tmp/sca_HelloWorld_rev1.0.jar -DcompositeName=HelloWorld
-Drevision=1.0

次の例は、デプロイメント後のすべての変更を含めてコンポジットをエクスポートする方法を示しています。

ant -f ant-sca-deploy.xml exportComposite -DserverURL=http://myhost:8001
-DupdateType=all
-DsarFile=/tmp/sca_HelloWorld_rev1.0-all.jar -DcompositeName=HelloWorld
-Drevision=1.0

次の例は、デプロイメント後のプロパティ更新を含めてコンポジットをエクスポートする方法を示しています。

ant -f ant-sca-deploy.xml exportComposite -DserverURL=http://myhost:8001
-DupdateType=property
-DsarFile=/tmp/sca_HelloWorld_rev1.0-prop.jar -DcompositeName=HelloWorld
-Drevision=1.0

次の例は、デプロイメント後のランタイム/メタデータ更新を含めてコンポジットをエクスポートする方法を示しています。

ant -f ant-sca-deploy.xml exportComposite -DserverURL=http://myhost:8001
-DupdateType=runtime
-DsarFile=/tmp/sca_HelloWorld_rev1.0-runtime.jar
-DcompositeName=HelloWorld -Drevision=1.0

47.9.7 JARファイルにコンポジットのデプロイメント後の変更をエクスポートするためのantの使用方法

次に、コンポジットのデプロイメント後の変更をJARファイルにエクスポートする例を示します。

ant -f ant-sca-deploy.xml exportUpdates -DserverURL=server.url
-DupdateType=update.type -DjarFile=jar.file
-DcompositeName=composite.name -Drevision=revision -Duser=user

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-17 に、構文を示します。

表47-17 antデプロイメント後エクスポート・コマンド

引数

定義

serverURL

SOAインフラストラクチャ・アプリケーションをホストするサーバーのURL(例: http://myhost:8001)。

updateType

エクスポートするデプロイ後の変更のタイプ。

- all: デプロイ後の変更をすべて含みます。

- property: プロパティのデプロイ後の変更のみを含みます(バインディング・コンポーネント・プロパティ、監査レベル設定やペイロード検証ステータスなどのコンポジット・プロパティ、およびポリシー・アタッチメント)。

- runtime: ランタイム変更のみを含めます(ルール・ディクショナリおよびドメイン値マップ(DVM))。

jarFile

生成されるJARファイルの絶対パス。

compositeName

エクスポートするコンポジットの名前。

revision

エクスポートするコンポジットのリビジョン。

user

オプション。サーバーにアクセスするためのユーザー名(基本構成が行われている場合)。

password

オプション。サーバーにアクセスするためのパスワード(基本構成が行われている場合)。

次の例は、デプロイメント後のすべての更新をエクスポートする方法を示しています。

ant -f ant-sca-deploy.xml exportUpdates -DserverURL=http://myhost:8001
-DupdateType=all
-DjarFile=/tmp/all-HelloWorld_rev1.0.jar -DcompositeName=HelloWorld
-Drevision=1.0

次の例は、デプロイメント後のプロパティ更新をエクスポートする方法を示しています。

ant -f ant-sca-deploy.xml exportUpdates -DserverURL=http://myhost:8001
-DupdateType=property
-DjarFile=/tmp/prop-HelloWorld_rev1.0.jar -DcompositeName=HelloWorld
-Drevision=1.0

次の例は、デプロイメント後のランタイム/メタデータ更新をエクスポートする方法を示しています。

ant -f ant-sca-deploy.xml exportUpdates -DserverURL=http://myhost:8001
-DupdateType=runtime
-DjarFile=/tmp/runtime-HelloWorld_rev1.0.jar -DcompositeName=HelloWorld
-Drevision=1.0

47.9.8 コンポジットのデプロイメント後の変更をインポートするためのantの使用方法

次に、コンポジットのデプロイメント後の変更をインポートする例を示します。

ant -f ant-sca-deploy.xml importUpdates -DserverURL=server.url -DjarFile=jar.file
-DcompositeName=composite.name -Drevision=revision -Duser=user

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-18 に、構文を示します。

表47-18 antデプロイメント後インポート・コマンド

引数

定義

serverURL

SOAインフラストラクチャ・アプリケーションをホストするサーバーのURL(例: http://myhost:8001)。

jarFile

デプロイメント後の変更が含まれるJARファイルの絶対パス。

compositeName

デプロイメント後の変更をインポートするコンポジットの名前。

revision

デプロイメント後の変更をインポートするコンポジットのリビジョン。

user

オプション。サーバーにアクセスするためのユーザー名(基本構成が行われている場合)。

password

オプション。サーバーにアクセスするためのパスワード(基本構成が行われている場合)。

次の例は、コンポジットのデプロイメント後の変更をインポートする方法を示しています。

ant -f ant-sca-deploy.xml importUpdates -DserverURL=http://myhost:8001
-DjarFile=/tmp/prop-HelloWorld_rev1.0.jar -DcompositeName=HelloWorld
-Drevision=1.0

47.9.9 JARファイルへ指定したパターンの共有データをエクスポートするためのantの使用方法

次に、指定したパターンの共有データをJARファイルにエクスポートする例を示します。

ant -f ant-sca-deploy.xml exportSharedData -DserverURL=server.url
-DjarFile=jar.file -Dpattern=pattern -Duser=user

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-19 に、構文を示します。

表47-19 ant共有データ・エクスポート・コマンド

引数

定義

serverURL

SOAインフラストラクチャ・アプリケーションをホストするサーバーのURL(例: http://myhost:8001)。

jarFile

生成されるJARファイルの絶対パス。

pattern

Oracle MDSリポジトリ転送APIによってサポートされているファイル・パターン。複数のパターンを指定する場合はデリミタとしてセミコロン(;)を使用します。パターンでは、共有データ・ネームスペース/appsを除外します。次に例を示します。

/Project1/**;/Project2/**

この例では、/apps/Project1および/apps/Project2にあるすべてのドキュメントをエクスポートします。

user

オプション。サーバーにアクセスするためのユーザー名(基本構成が行われている場合)。

password

サーバーにアクセスするためのパスワード(基本構成が行われている場合)。このパラメータはオプションです。

次の例は、指定したパターンの共有データをJARファイルにエクスポートする方法を示しています。

ant -f ant-sca-deploy.xml exportSharedData -DserverURL=http://myhost:8001
-DjarFile=/tmp/MySharedData.jar
-Dpattern="/Project1/**"

47.9.10 トップレベルの共有データ・フォルダを削除するためのantの使用方法

次に、トップレベルの共有データ・フォルダを削除する例を示します(サービス・エンジンにデプロイされたコンポジットがある場合を含む)。

ant -f ant-sca-deploy.xml removeSharedData -DserverURL=server.url
-DfolderName=folder.name -Duser=user

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-20 に、構文を示します。

表47-20 ant共有データ・フォルダ削除コマンド

引数

定義

serverURL

SOAインフラストラクチャ・アプリケーションをホストするサーバーのURL(例: http://myhost10:8001)。

foldername

削除するトップレベルの共有データ・フォルダの名前。

user

オプション。サーバーにアクセスするためのユーザー名(基本構成が行われている場合)。

password

オプション。サーバーにアクセスするためのパスワード(基本構成が行われている場合)。

次の例は、Project1という名前のトップレベルの共有データ・フォルダを削除する方法を示しています。

ant -f ant-sca-deploy.xml removeSharedData -DserverURL=http://myhost:8001
-DfolderName=Project1

47.9.11 SOAコンポジット・アプリケーションを起動するためのantの使用方法

次に、SOAコンポジット・アプリケーションの起動例を示します。

ant -f ant-sca-mgmt.xml startComposite -Dhost=myhost -Dport=8001 -Duser=weblogic
-DcompositeName=HelloWorld -Drevision=1.0 -Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-21 に、構文を示します。

表47-21 ant SOAコンポジット・アプリケーション起動コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

compositeName

SOAコンポジット・アプリケーションの名前。

revision

SOAコンポジット・アプリケーションのリビジョン。

label

オプション。SOAコンポジット・アプリケーションのラベル。ラベルは、アプリケーションに関連付けられるMDSアーティファクトを識別します。ラベルを指定しない場合、システムによって最新のラベルが取得されます。

partition

オプション。SOAコンポジット・アプリケーションが置かれているパーティションの名前。デフォルト値はdefaultです。パーティションを指定しないと、SOAコンポジット・アプリケーションのdefaultパーティションが検索されます。他のパーティションは検索されません。

47.9.12 SOAコンポジット・アプリケーションを停止するためのantの使用方法

次に、SOAコンポジット・アプリケーションの停止例を示します。

ant -f ant-sca-mgmt.xml stopComposite -Dhost=myhost -Dport=8001 -Duser=weblogic
-DcompositeName=HelloWorld -Drevision=1.0 -Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-22 に、構文を示します。

表47-22 ant SOAコンポジット・アプリケーション停止コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

compositeName

SOAコンポジット・アプリケーションの名前。

revision

SOAコンポジット・アプリケーションのリビジョン。

label

オプション。SOAコンポジット・アプリケーションのラベル。ラベルは、アプリケーションに関連付けられるMDSアーティファクトを識別します。ラベルを指定しない場合、システムによって最新のラベルが取得されます。

partition

オプション。SOAコンポジット・アプリケーションが置かれているパーティションの名前。デフォルト値はdefaultです。パーティションを指定しないと、SOAコンポジット・アプリケーションのdefaultパーティションが検索されます。他のパーティションは検索されません。

47.9.13 SOAコンポジット・アプリケーションをアクティブ化するためのantの使用方法

次に、SOAコンポジット・アプリケーションのアクティブ化の例を示します。

ant -f ant-sca-mgmt.xml activateComposite -Dhost=myhost -Dport=8001
-Duser=weblogic-DcompositeName=HelloWorld -Drevision=1.0 -Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-23 に、構文を示します。

表47-23 ant SOAコンポジット・アプリケーション・アクティブ化コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

compositeName

SOAコンポジット・アプリケーションの名前。

revision

SOAコンポジット・アプリケーションのリビジョン。

label

オプション。SOAコンポジット・アプリケーションのラベル。ラベルは、アプリケーションに関連付けられるMDSアーティファクトを識別します。ラベルを指定しない場合、システムによって最新のラベルが取得されます。

partition

オプション。SOAコンポジット・アプリケーションが置かれているパーティションの名前。デフォルト値はdefaultです。パーティションを指定しないと、SOAコンポジット・アプリケーションのdefaultパーティションが検索されます。他のパーティションは検索されません。

47.9.14 SOAコンポジット・アプリケーションをリタイアするためのantの使用方法

次に、SOAコンポジット・アプリケーションのリタイア例を示します。

ant -f ant-sca-mgmt.xml retireComposite -Dhost=myhost -Dport=8001 -Duser=weblogic
-DcompositeName=HelloWorld -Drevision=1.0 -Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-24 に、構文を示します。

表47-24 ant SOAコンポジット・アプリケーション・リタイア・コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

compositeName

SOAコンポジット・アプリケーションの名前。

revision

SOAコンポジット・アプリケーションのリビジョン。

label

オプション。SOAコンポジット・アプリケーションのラベル。ラベルは、アプリケーションに関連付けられるMDSアーティファクトを識別します。ラベルを指定しない場合、システムによって最新のラベルが取得されます。

partition

オプション。SOAコンポジット・アプリケーションが置かれているパーティションの名前。デフォルト値はdefaultです。パーティションを指定しないと、SOAコンポジット・アプリケーションのdefaultパーティションが検索されます。他のパーティションは検索されません。

47.9.15 SOAコンポジット・アプリケーションにデフォルト・バージョンを割り当てるためのantの使用方法

次に、デフォルト・バージョンをSOAコンポジット・アプリケーションに割り当てる例を示します。

ant -f ant-sca-mgmt.xml assignDefaultComposite -Dhost=myhost -Dport=8001
-Duser=weblogic -DcompositeName=HelloWorld -Drevision=1.0 -Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-25 に、構文を示します。

表47-25 ant SOAコンポジット・アプリケーション・デフォルト・バージョン割当てコマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

compositeName

SOAコンポジット・アプリケーションの名前。

revision

SOAコンポジット・アプリケーションのリビジョン。

partition

オプション。SOAコンポジット・アプリケーションが置かれているパーティションの名前。デフォルト値はdefaultです。パーティションを指定しないと、SOAコンポジット・アプリケーションのdefaultパーティションが検索されます。他のパーティションは検索されません。

47.9.16 デプロイ済SOAコンポジット・アプリケーションを一覧表示するためのantの使用方法

次に、デプロイされたSOAコンポジット・アプリケーションを一覧表示する例を示します。

ant -f ant-sca-mgmt.xml listDeployedComposites -Dhost=myhost -Dport=8001
-Duser=weblogic

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-26 に、構文を示します。

表47-26 ant SOAコンポジット・アプリケーション・デプロイメント一覧表示コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

47.9.17 SOAインフラストラクチャで使用可能なすべてのパーティションを一覧表示するためのantの使用方法

次に、SOAインフラストラクチャで使用可能なすべてのパーティションを一覧表示するための構文を示します。

ant -f ant-sca-mgmt.xml listPartitions -Dhost=host -Dport=port -Duser=user

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-27 に、構文を示します。

表47-27 ant SOAインフラストラクチャ・パーティション一覧表示コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

次に、SOAインフラストラクチャで使用可能なすべてのパーティションを一覧表示する例を示します。

ant -f ant-sca-mgmt.xml listPartitions -Dhost=myhost10 -Dport=8001

47.9.18 パーティション内のすべてのコンポジットを一覧表示するためのantの使用方法

次に、パーティション内のすべてのコンポジットを一覧表示するための構文を示します。

ant -f ant-sca-mgmt.xml listCompositesInPartition -Dhost=host -Dport=port -Duser=user -Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-28 に、構文を示します。

表47-28 ant コンポジット・パーティション一覧表示コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

partition

パーティションの名前。

次に、myPartitionというパーティション内のすべてのコンポジットを一覧表示する例を示します。

ant -f ant-sca-mgmt.xml listCompositesInPartition -Dhost=myhost10 -Dport=8001 -Dpartition=myPartition

47.9.19 SOAインフラストラクチャでパーティションを作成するためのantの使用方法

次に、SOAインフラストラクチャにパーティションを作成するための構文を示します。

ant -f ant-sca-mgmt.xml createPartition -Dhost=host -Dport=port -Duser=user
-Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-29 に、構文を示します。

表47-29 antパーティション作成コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

partition

作成するパーティションの名前。

次に、SOAインフラストラクチャにmyPartitionというパーティションを作成する例を示します。

ant -f ant-sca-mgmt.xml createPartition -Dhost=myhost10 -Dport=8001
-Dpartition=myPartition

47.9.20 SOAインフラストラクチャでパーティションを削除するためのantの使用方法

次に、SOAインフラストラクチャのパーティションを削除するための構文を示します。このコマンドは、パーティションを削除する前に、パーティション内のすべてのコンポジットをアンデプロイします。

ant -f ant-sca-mgmt.xml deletePartition -Dhost=host -Dport=port -Duser=user
-Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-30 に、構文を示します。

表47-30 antパーティション削除コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

partition

削除するパーティションの名前。

次に、SOAインフラストラクチャにあるmyPartitionというパーティションを削除する例を示します。

ant -f ant-sca-mgmt.xml deletePartition -Dhost=myhost10 -Dport=8001
-Dpartition=myPartition

47.9.21 パーティション内のすべてのコンポジットを起動するためのantの使用方法

次に、パーティション内のすべてのコンポジットを起動するための構文を示します。

ant -f ant-sca-mgmt.xml startCompositesInPartition -Dhost=host -Dport=port
-Duser=user -Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-31 に、構文を示します。

表47-31 antパーティション起動コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

partition

パーティションの名前。

次に、myPartitionというパーティション内のすべてのコンポジットを起動する例を示します。

ant -f ant-sca-mgmt.xml startCompositesInPartition -Dhost=myhost10 -Dport=8001
-Dpartition=myPartition

47.9.22 パーティション内のすべてのコンポジットを停止するためのantの使用方法

次に、パーティション内のすべてのコンポジットを停止するための構文を示します。

ant -f ant-sca-mgmt.xml stopCompositesInPartition -Dhost=host -Dport=port
-Duser=user -Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-32 に、構文を示します。

表47-32 antパーティション・コンポジット停止コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

partition

パーティションの名前。

次に、myPartitionというパーティション内のすべてのコンポジットを停止する例を示します。

ant -f ant-sca-mgmt.xml stopCompositesInPartition -Dhost=myhost10 -Dport=8001
-Dpartition=myPartition

47.9.23 パーティション内のすべてのコンポジットをアクティブ化するためのantの使用方法

次に、パーティション内のすべてのコンポジットをアクティブ化するための構文を示します。

ant -f ant-sca-mgmt.xml activateCompositesInPartition -Dhost=host -Dport=port
-Duser=user -Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-33 に、構文を示します。

表47-33 antパーティション・コンポジット・アクティブ化コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

partition

パーティションの名前。

次に、myPartitionというパーティション内のすべてのコンポジットをアクティブ化する例を示します。

ant -f ant-sca-mgmt.xml activateCompositesInPartition -Dhost=myhost10 -Dport=8001
-Dpartition=myPartition

47.9.24 パーティション内のすべてのコンポジットをリタイアするためのantの使用方法

次に、パーティション内のすべてのコンポジットをリタイアするための構文を示します。

ant -f ant-sca-mgmt.xml retireCompositesInPartition -Dhost=host -Dport=port
-Duser=user -Dpartition=partition.name

注意:

ユーザー名の指定後、プロンプトが表示された場合はパスワードを入力してください。

表47-34 に、構文を示します。

表47-34 antパーティション・コンポジット・リタイア・コマンド

引数

定義

host

Oracle WebLogic Serverのホスト名(例: myhost)。

port

Oracle WebLogic Serverのポート(例: 7001)。

user

実行中のサーバーに接続しMBean情報を取得するためのユーザー名(たとえば、weblogic)。

password

ユーザー名のパスワード。

partition

パーティションの名前。

次に、myPartitionというパーティション内のすべてのコンポジットをリタイアする例を示します。

ant -f ant-sca-mgmt.xml retireCompositesInPartition -Dhost=myhost10 -Dport=8001
-Dpartition=myPartition

47.9.25 SOAコンポジット・アプリケーションを管理するためのantの使用方法

antスクリプトを使用して、アプリケーションをコンパイル、パッケージ化、およびデプロイできます。初期antビルド・ファイルを作成するには、「ファイル」メイン・メニューから、「新規」→「アプリケーション」→「Ant」→「プロジェクトからのビルドファイル」の順に選択します。

図47-29 に、作成後に「アプリケーション」ウィンドウに表示されるbuild.propertiesファイルおよびbuild.xmlファイルを示します。

図47-29 antビルド・ファイル

- build.properties
環境を反映するために編集するファイル(例: OracleホームおよびJavaホーム・ディレクトリの指定、デプロイメントに使用するホスト名やポート番号などのサーバー・プロパティの設定、デプロイするアプリケーションの指定など)。

- build.xml
antによって、build.propertiesファイルで指定したコンポジット・アプリケーションのコンパイル、ビルド、およびサーバーへのデプロイのために使用されます。

1. 環境を反映するようにbuild.propertiesファイルを変更します。

2. 「ビルド」メニューから、「project_nameでAntを実行」を選択します。

この結果、現在のプロジェクトのビルド・ファイルに定義されているターゲットがビルドされます。

47.10 SOAコンポジット・アプリケーションのOracle Enterprise Manager Fusion Middleware Controlからのデプロイ

SOAコンポジット・アプリケーションは、Oracle Enterprise Manager Fusion Middleware Controlからデプロイできます。最初に、デプロイ可能なアーカイブをOracle JDeveloperで作成するか、antやWLSTコマンドライン・ツールを使用して作成する必要があります。このアーカイブは、JARファイル内の単一のSOAコンポジット・アプリケーションのリビジョン、またはZIPファイル内の複数のコンポジット・アプリケーションのリビジョン(SOAバンドルと呼ばれます)で構成できます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

47.11 クラスタへのSOAコンポジット・アプリケーションのデプロイ

SOAコンポジット・アプリケーションはクラスタ化された環境にもデプロイできます。詳細は、『高可用性ガイド』の「Oracle Fusion Middleware SOA Suiteの高可用性の構成」を参照してください。

47.12 実行中のサーバーがない状態でのSOAコンポジット・アプリケーションのデプロイ

管理対象のSOAサーバーまたは管理サーバーが実行されていない状態で、SOAコンポジット・アプリケーションと共有データ(たとえば、WSDLファイルとXSDファイル)をデプロイできます。これは、オフライン・デプロイメント・モードと呼ばれます。サーバーを再起動すると、SOAコンポジット・アプリケーションと共有データがデプロイされます。

オフライン・デプロイメントは、次のユース・ケースで役に立ちます。

- 共有データと新規SOAコンポジット・アプリケーション(たとえば、システムが新しく、デプロイされたコンポーネントが存在しない)。

- 単一のSOAコンポジット・アプリケーション(新規またはパッチ適用)、共有データのリソース・バンドルなどを含む、単発のパッチ。

オフライン・デプロイメントの使用時には、次のガイドラインに注意してください。

- SOAコンポジット・アプリケーションと共有データは、Oracleホーム・ディレクトリに読取り専用フォーマットで提供されます。コンポジットを削除または更新できません。

- オフライン・デプロイメントを行う際には、サポートされるユース・ケースの1つまたはすべてに同じSOAコンポジット・アプリケーション、または共有データ・ファイルを含めることができます。ただし、SOAコンポジット・アプリケーションによっては、ただ1つのコンポジットSARまたは共有データ・ファイルが、製品データ・ルート・ディレクトリを基準とした相対データ・ロケーションに存在します。すべてのケースで、同じルート製品データ・ディレクトリを指定する必要があります。適用されたユース・ケースの順序によって、同じコンポジット・データが上書きされます。

- オフライン・デプロイメントでは、SOAコンポジット・アプリケーションを再デプロイまたはアンデプロイできません。

- 共有データにはリビジョンの概念がないので、共有データ(リソース・バンドル)の再デプロイメントはサポートされます。

- オフライン・デプロイメントに対して、個々のSOAコンポジット・アプリケーションおよび共有データの追加と削除を行うためのWLSTコマンドが提供されています。詳細は、SOA Suite用WLSTコマンド・リファレンスのSOAコンポジット・アプリケーションのオフライン管理デプロイメントに関する項を参照してください。

- オフライン・デプロイメントでは、構成プランはサポートされません。

SARファイルの命名規則の詳細は、「デプロイ済サービス・アーカイブ」を参照してください。

共有データの詳細は、「Oracle JDeveloperでの複数のSOAコンポジット・アプリケーション間の共有データのデプロイ方法および使用方法」を参照してください。

注意:

- オフライン・モードでZIPファイルをデプロイできません。これは、ZIPファイルに他のアーカイブが含まれているからです。

- オフライン・デプロイメントでは、特定のコンポジットSARファイルを1つのパーティションにのみデプロイできます。

47.12.1 オフライン・デプロイメント構成ファイル

次の2つの構成ファイルがオフライン・デプロイメントを制御します。

- soa-configuration.xml (オフライン・デプロイメント構成リスト・ファイル)

- composite-offline-deployments-version_number.xml (オフライン・デプロイメント構成ファイル)。version_numberには任意の値を指定できますが、composite-offline-deployments-部分は固定で必須です。

47.12.1.1 オフライン・デプロイメント構成リスト・ファイル

オフライン・デプロイメント構成リスト・ファイルは、オフライン・デプロイメント構成ファイルを読み取るロケーションを指定します。ファイルの名前はsoa-configuration.xmlで、$DOMAIN/config/fmwconfigディレクトリ内にあります。オフライン・デプロイメント処理は、この構成ファイルを使用して、オフライン・デプロイメントに使用する統合構成リストを生成します。次の例は、2つのディレクトリ・ロケーションがリストされているsoa-configuration.xmlファイルを示しています。

<?xml version="1.0" encoding="UTF-8"?>
<soa-configuration xmlns="http://xmlns.oracle.com/config/soa">
<soa-directories>
<soa-directory>/scratch/aime/appTop/common/soa-composiste/soa1</soa-directory>
<soa-directory>/scratch/aime/appTop/common/soa-composiste/soa2</soa-directory>
</soa-directories>
</soa-configuration>

47.12.1.2 オフライン・デプロイメント構成ファイル

オフライン・デプロイメント構成ファイルは、オフライン・デプロイメントに関する次の要素を指定します。

- SOAコンポジット・アプリケーションと共有リソースをデプロイする前に、必要に応じてパーティションが作成されます。パーティションの使用には次の優先順位があることに注意してください。

- <partition>要素に指定されたパーティションが作成されます。

- <composite-deployment>で使用されるパーティションが<partition>要素に指定されていない場合は、暗黙的に作成されます。

- partition属性が<composite-deployment>要素に指定されていない場合、コンポジットはdefaultパーティションにデプロイされます。

- 共有リソース
共有リソースは、SOAコンポジット・アプリケーションより前にデプロイされます。

- SOAコンポジット・アプリケーション
ファイルに複数のSOAコンポジット・アプリケーションをリストできます。ただし、これらはファイル内にリストされている順序ではデプロイされません。

ファイルの命名規則はcomposite-offline-deployments-version_number.xmlで、version_numberには任意の値を指定できますが、composite-offline-deployments-部分は固定で必須です。

次の例は、オフライン・デプロイメント・ファイルの構造を示しています。ファイルは、パーティション、SOAコンポジット・アプリケーション、および共有データを表す3つのセクションに分割されます。

<offline-configuration>
<partitions>?
<partition name="partition_name"/>*
</partitions>
<composite-deployments>?
<composite-deployment location="/some/path" partition="partition_name"?>*
</composite-deployments>
<shared-resources>?
<shared-resource location="/some/path"/>*
</shared-resources>
</offline-configuration>

次の例は、次の項目を定義するオフライン・デプロイメント構成ファイルを示しています。

- パーティションoneとtwoが作成されます。

- コンポジットSARファイル/some/path/sca_composite1.jarは、パーティションoneにデプロイされます。

- コンポジットSARファイル/another/path/sca_composite2.jarは、パーティションtwoにデプロイされます。

- コンポジットSARファイル/yet/another/path/sca_composite3.jarは、defaultパーティションにデプロイされます。

- 共有データJARファイル/some/path/shareddata1.jarおよび/another/path/shareddata2.jarは、共有データ・ロケーションにデプロイされます。

<offline-configuration>
<composite-deployments>
<composite-deployment location="/some/path/sca_composite1.jar"
partition="one">
<composite-deployment location="/another/path/sca_composite2.jar"/
partition="two">
<composite-deployment location="/yet/another/path/sca_composite3.jar"/>
</composite-deployments>
<shared-resources>
<shared-resource location="/some/path/shareddata1.jar"/>
<shared-resource location="/another/path/shareddata2.jar"/>
</shared-resources>
</offline-configuration>

次の例は、オフライン構成デプロイメント・ファイルを示しています。このファイルには、次の内容が指定されています。

- 共有データJARファイルshareddata.jarがデプロイされます。

- コンポジットSARファイルsca_soaApp1.jarは、myPartitionパーティションにデプロイされます。

- コンポジットSARファイルsca_soaApp2.jarは、明示的に定義されたパーティションがないので、デフォルトでdefaultパーティションにデプロイされます。

<offline-configuration>
<composite-deployments>
<composite-deployment
location="/scratch/aime/appTop/soa1/sca_soaApp1.jar“
partition=“myPartition“/>
<composite-deployment
location="/scratch/aime/appTop/soa1/sca_soaApp2.jar“/>
</composite-deployments>
<shared-resources>
<shared-resource location="/scratch/aime/appTop/soa1/shareddata.jar"/>
</shared-resources>
</offline-configuration>

次の例は、定義された2つのディレクトリ内にある共有データのみをデプロイする場合のオフライン・デプロイメント構成ファイルを示しています。

<offline-configuration>
<shared-resources>
<shared-resource location="/some/path/shareddata1.jar"/>
<shared-resource location= "/another/path/shareddata2.jar"/>
</shared-resources>
</offline-configuration>

次の例は、パーティションoneとtwoを作成する場合のオフライン・デプロイメント・ファイルを示しています。SOAコンポジット・アプリケーションまたは共有データはデプロイされません。

<offline-configuration>
<partitions>
<partition name="one"/>
<partition name="two"/>
</partitions>
</offline-configuration>

47.12.1.3 構成ファイルの相対パス

オフライン・デプロイメント構成ファイルでは、相対パスもサポートされています。次の例は、soa-configuration.xmlファイルを示しています。

<?xml version="1.0" encoding="UTF-8"?>
<soa-configuration xmlns="http://xmlns.oracle.com/config/soa">
<soa-directories>
<soa-directory>/scratch/aime/appTop/common/soa-composiste/soa1</soa-directory>
</soa-directories>
</soa-configuration>

次の例は、オフライン・デプロイメントのcomposite-offline-deployments-1.0.xmlファイルを示しています。2つのコンポジットSARファイル、および1つの共有データJARファイルは、すべて前の例に示すsoa1ディレクトリに配置されます。

<offline-configuration>
<composite-deployments>
<composite-deployment location="sca_soaApproval.jar" >
<composite-deployment location="sca_soaNotification.jar">
</composite-deployments>
<shared-resources>
<shared-resource location="soashareddata.jar"/>
</shared-resources>
</offline-configuration>

47.12.1.4 デプロイメントの順序

オフライン・デプロイメントは、次の順序で処理されます。

- soa-configuration.xmlオフライン・デプロイメント構成リスト・ファイルが読み取られ、オフライン・デプロイメント構成ファイル(composite-offline-deployments-version.xml)のロケーションが識別されます。

- composite-offline-deployments-version.xmlファイルが読み取られ、ファイル・ロケーションに基づいて統合されたリストが作成されます。統合されたリストには、パーティション、共有データ・ファイル、およびSOAコンポジット・アプリケーション・ファイルが含まれます。

- 統合されたリストは、次の順序で処理されます。

- パーティション

- 共有データファイル

- SOAコンポジット・アプリケーション・ファイル

47.12.2 実行中のサーバーがない状態でSOAコンポジット・アプリケーションと共有データをデプロイする方法

この項では、実行中のサーバーがない状態でSOAコンポジット・アプリケーションと共有データをデプロイする手順を概説します。

実行中のサーバーがない状態でSOAコンポジット・アプリケーションと共有データをデプロイする手順は、次のとおりです。

1. オフライン・デプロイメント構成リスト・ファイルを作成します。このファイルは、オフライン・デプロイメント構成ファイルを読み取るロケーションを指定します。このファイルの内容の例は、「オフライン・デプロイメント構成リスト・ファイル」を参照してください。

2. オフライン・デプロイメント構成ファイルを作成します。このファイルは、オフライン・デプロイメントに含める要素(パーティション、共有データ、またはSOAコンポジット・アプリケーション)を指定します。このファイルの内容の例は、「オフライン・デプロイメント構成ファイル」を参照してください。

3. SOAサーバーを再起動します。

コンポジットのデプロイと表示は、Oracle Enterprise Manager Fusion Middleware Controlの「SOAインフラストラクチャ」の「デプロイ済コンポジット」タブで行います。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAインフラストラクチャ・レベルでのすべてのアプリケーションの状態管理に関する項を参照してください。

トラブルシューティングが必要な場合は、SOAサーバー診断ログ・ファイルでデプロイメント結果を確認できます。

47.12.3 クラスタ環境でのオフライン・コンポジット・デプロイメントに関する必知事項

オフライン・コンポジット・デプロイメント時にサーバーが起動すると、SOAコンポジット・アプリケーションがクラスタ内のすべてのノードにデプロイされます。登録ファイルは、1つの物理ドメイン・ロケーションでサポートされ、クラスタ内のすべての物理ドメイン・ロケーションでファイルは同期されません。ドメイン・ロケーションが様々な物理ホストに存在するようにクラスタが構成されている場合、1つのホスト上でドメイン・ディレクトリを選択し、そのディレクトリをオフライン登録ロケーションとして使用します。

47.12.4 MDSリポジトリにない共有データを参照するSOAコンポジット・アプリケーションのデプロイに関する必知事項

オフライン・デプロイメントを行うと、共有データがMDSリポジトリに存在しなくても、MDSリポジトリ内の共有アーティファクトを参照するSOAコンポジット・アプリケーションをデプロイできます。

これは予想された動作です。サーバーの起動時間を節約するために、オフライン・デプロイメントはデフォルトで遅延ロードを使用します。遅延ロードを行うと、コンポジットが存在しない共有データを参照している場合、サーバー起動時にコンポジットがデプロイされるときにデプロイメント・エラーは表示されません。ただし、コンポジットの初回起動時に障害が発生します。存在しない共有データをコンポジットが参照すると障害が発生します。遅延ロードでは障害ポイントが異なり、デプロイメント時ではなく初回起動時になります。

47.13 デプロイメント後の構成

この項では、デプロイメント後の構成タスクについて説明します。

47.13.1 セキュリティ

SOAコンポジット・アプリケーションの保護の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

47.13.2 接続の更新

アプリケーション・サーバーまたはMDSリポジトリに対して作成したすべての接続が、次のターゲット環境に適用可能なサーバーを指すように再作成されていることを確認します。詳細は、「アプリケーション・サーバー接続の作成」および「SOA-MDS接続の作成」を参照してください。

47.13.3 データ・ソースおよびキューの更新

構成済のすべてのJDBCデータ・ソース、キューおよびコネクション・ファクトリの場所が、次に進むターゲット環境に適用可能であることを確認します。詳細は、「データ・ソースおよびキューの作成方法」および「コネクション・ファクトリおよび接続プールの作成方法」を参照してください。

47.13.4 ポリシーの添付

Oracle Enterprise Manager Fusion Middleware Controlでの実行中に、デプロイ済SOAコンポジット・アプリケーションにポリシーを添付できます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

47.14 テストおよびトラブルシューティング

この項では、SOAコンポジット・アプリケーションのテストおよびトラブルシューティングの方法について説明します。

47.14.1 デプロイメントの検証

SOAコンポジット・アプリケーションがSOAインフラストラクチャに正常にデプロイされたことを検証できます。正常にデプロイされた場合は、Oracle Enterprise Manager Fusion Middleware Controlの「SOAインフラストラクチャ」ページの「デプロイ済コンポジット」タブにデプロイされたコンポジットが表示されます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

47.14.2 デプロイ済コンポジットのインスタンスの開始

デプロイ済SOAコンポジット・アプリケーションのインスタンスは、Oracle Enterprise Manager Fusion Middleware Controlの「Webサービスのテスト」ページから開始できます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

47.14.3 デプロイ済コンポジットのテストの自動化

SOAコンポジット・アプリケーションのテストを自動化するテスト・ケースを作成、デプロイおよび実行できます。テスト・ケースを使用すると、本番環境へのデプロイメントの前に、SOAコンポジット・アプリケーションとWebサービス・パートナ間の相互作用をシミュレートできます。Oracle JDeveloperでテスト・ケースを作成し、SOAコンポジット・アプリケーションに組み込みますが、このアプリケーションは、その後、Oracle JDeveloperまたはOracle Enterprise Manager Fusion Middleware Controlのいずれかからデプロイされて実行されます。

Oracle JDeveloperからのテスト・ケースの作成および実行の詳細は、「SOAコンポジット・アプリケーションのテストの自動化」を参照してください。

Oracle Enterprise Manager Fusion Middleware Controlからのテスト・ケースの実行の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

47.14.4 デプロイメント・エラー受取り後のプロジェクトの再コンパイル

Oracle JDeveloperからのSOAコンポジット・アプリケーションのデプロイ時に次の例に示すエラーを受け取った場合は、プロジェクトを再コンパイルし、コンポジットを再デプロイします。このエラーは断続的に発生するため、再度発生しないようにする必要があります。

Error deploying BPEL suitcase.
error while attempting to deploy the BPEL component file
"/scratch/aime1/work/mw9507/user_projects/domains/WLS_SOAWC/deployed-composites
/ManagementChainParticipantRuleComposite_rev1.0/sca_ManagementChainParticipantR
uleComposite_rev1.0/soa_59d10d76-08a5-41f0-ba89-32dcc2250002";
the exception reported is: java.lang.Exception: BPEL 1.1 compilation failed

This error contained an exception thrown by the underlying deployment module.
Verify the exception trace in the log (with logging level set to debug mode).

at
com.collaxa.cube.engine.deployment.DeploymentManager.deployComponent(Deployment
Manager.java:197)
at
com.collaxa.cube.ejb.impl.CubeServerManagerBean._deployOrLoadComponent(CubeServ
erManagerBean.java:820)
at
com.collaxa.cube.ejb.impl.CubeServerManagerBean.deployComponent(CubeServerManag
erBean.java:119)

47.14.5 Javaのコンパイル・エラーを解決するためのJavaコード・サイズの削減

次の例に示すJavaのコンパイル・エラーがサーバーのログ・ファイルに表示された場合は、Javaクラス内のコードが多すぎる可能性があります。

Failed to compile bpel generated classes.
failure to compile the generated BPEL classes for BPEL process
"Review_Supply_Plan_ProcessProcess" of composite "default/Review_Supp
ly_Plan_Process!1.0*a9ca2907-8540-4375-b672-ceb560d7b826"
The class path setting is incorrect.
Ensure that the class path is set correctly. If this happens on the server
side, verify that the custom classes or jars which this BPEL process is
depending on are deployed correctly. Also verify that the runtime is using
the same release/version.
. . .
. . .
at
com.collaxa.cube.lang.compiler.template.CubeProcessGenerator.compile(CubeProce
ssGenerator.java:304)
at
com.collaxa.cube.lang.compiler.template.CubeProcessGenerator.generate(CubeProc
essGenerator.java:164)
at
com.collaxa.cube.lang.compiler.BPEL1Processor.transform(BPEL1Processor.java:25
7)
at
com.collaxa.cube.lang.compiler.BPEL1Processor.process(BPEL1Processor.java:161)

Javaのコンパイル・エラーを解決するためにJavaコード・サイズを削減する手順は、次のとおりです。

1. $MIDDLEWARE_HOME/user_projects/domains/domain_name/bin/SetDomainEnv.shファイル(Linux)またはSetDomainEnv.batファイル(Windows)を開きます。

2. このファイルでEXTRA_JAVA_PROPERTIES="-Dorabpel.codegen.density"プロパティを見つけます。このプロパティが明示的に設定されていない場合、デフォルトで64,32の値に設定されます。

3. 次のように値を削減します。

EXTRA_JAVA_PROPERTIES="-Dorabpel.codegen.density=32,16"

これらの2つの値を削減することによって、コンパイルされたプロセス・マップに対して生成されるクラスおよびメソッドの数を増やします。デフォルト設定を使用したコンパイルのプロセスが失敗した場合は、ベスト・プラクティスとして、プロパティをより小さい値に設定します。次の値の組合せを試してみることをお薦めします。

32,16
16,8
8,4
4,2

4. 変更を保存します。

5. サーバーを再起動します。

6. SOAコンポジット・アプリケーションを再コンパイルします。

47.14.6 デプロイメントに関する共通のエラーのトラブルシューティング

この項では、デプロイメントに関する共通のエラーのトラブルシューティング方法について説明します。

コンポジット・アプリケーションの一般的なトラブルシューティングの問題は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

47.14.6.1 Oracle JDeveloperでのデプロイメントに関する共通の問題

この項では、チェックが必要なデプロイメントに関する共通の問題について説明します。

- 単一のコンポジット・アプリケーションをデプロイする場合は、「プロジェクト」メニューからデプロイしていることを確認してください。「アプリケーション」ウィンドウでプロジェクト名を右クリックして、「デプロイ」→「SOA_profile_name」の順に選択します。

- 複数のコンポジット・アプリケーションをデプロイする場合は、「アプリケーション」メニューからデプロイしていることを確認してください(「アプリケーション」ウィンドウでアプリケーション名を右クリックして、「デプロイ」→「SOA_bundle_profile_name」の順に選択します。)

- 「デプロイ」をクリックしてプロファイル名を選択した後に、デプロイメント・ウィザードの「デプロイメント・アクション」ページが表示されることを確認してください。

- 必要に応じて、新規リビジョンID(オプション)を入力し、構成プラン(ある場合)を選択します。

- デプロイするコンポジット・アプリケーションが同じリビジョンIDでサーバー上にすでに存在している場合は、デプロイメント・ウィザードの「構成のデプロイ」ページで「同じリビジョンIDで既存のコンポジットを上書きします。」チェック・ボックスを選択します。このオプションを選択しないと、デプロイメントは失敗します。

- コンパイルが失敗すると、デプロイメント・エラーではなくコンパイル・エラーが発生します。このエラーは、プロジェクトのコンパイル時にのみ表示されます。

- コンパイラのメッセージで不十分な場合は、コンパイラ・ログを確認してください。このログ・ファイル(scac.log)へのリンクは、「メッセージ」タブに表示されます。このメッセージは次の例のようになります。

Compilation of project 'FirstComposite.jpr' finished. Check '/scratch/myhome/
jdevWorkarea/mywork/Application11/FirstComposite/SCA-INF/classes/scac.log' for
details.

- コンパイルが成功すると、コンポジットに対してSAR/SOAバンドル・アーカイブが作成されます。SARアーカイブの場合は、次の例に示すメッセージが「デプロイメント」タブに表示されます。

Wrote Archive Module to
/scratch/myhome/jdevWorkarea/mywork/Application11/FirstComposite/deploy/sca_
FirstComposite_rev1.0.jar

SOAバンドル・アーカイブの場合は、次の例に示すメッセージが「デプロイメント」タブに表示されます。

Wrote Archive Module to
/scratch/myhome/jdevWorkarea/mywork/Application11/SecondComposite/deploy/sca_
SecondComposite_rev1.0.jar
Wrote Archive Module to
/scratch/myhome/jdevWorkarea/mywork/Application11/FirstComposite/deploy/sca_
FirstComposite_rev1.0.jar
Wrote Archive Module to
/scratch/myhome/jdevWorkarea/mywork/Application11/deploy/soabundle1.zip

- SARファイルのすべてのURLが、次の形式であることを確認します。

sca_CompositeName_revRevisionID.jar

たとえば、sca_FirstComposite_rev1.0.jarのようになります。

- この後、Oracle JDeveloperはサーバーにアーカイブ・バイナリを送信します。次のメッセージが「デプロイメント」タブに表示されます。この時点で、Oracle JDeveloperのデプロイメント・ロールは終了し、サーバー(SOAインフラストラクチャ)がデプロイメントを制御します。

Deploying sca_FirstComposite_rev1.0.jar to myhost19:7001

- デプロイメントが成功すると、次の例に示すメッセージが「デプロイメント」タブに表示されます。

Received HTTP response from the server, response code=200 Successfully deployed
archive soa_bundle_name.zip to soa_server_name

- デプロイメントが失敗すると、次の例に示すメッセージ、およびサーバーからのエラー・メッセージ(ある場合)が「デプロイメント」タブに表示されます。

Error deploying the archive. Check server log for more details.
Connection refused.
Elapsed time for deployment: 8 seconds

- ほとんどの場合、サーバー上で発生したエラーに関する情報はサーバーから提供されます。サーバーからのエラー・メッセージが表示されない場合は、サーバーでsoa_server1-diagnostic.logをチェックして追加情報を検索してください(soa_server1は管理対象サーバーの名前です)。このファイルは、サーバーのdomain_home/servers/soa_server1/logsにあります。

47.14.6.2 構成プランに関する共通の問題

この項では、チェックが必要な構成プランに関する共通の問題について説明します。

- デプロイするために選択した構成プランがサーバー上で有効にならない場合は、その構成プランが含まれているSARファイルを開きます。ファイルの場所は、Oracle JDeveloperの「デプロイメント」タブで検索できます。次の例に詳細を示します。

Wrote Archive Module to
/scratch/myhome/jdevWorkarea/mywork/Application11/FirstComposite/deploy/sca_
FirstComposite_rev1.0.jar

- JARファイルを開き、soaconfigplan.xmlファイルが含まれていることを確認します。このファイルは、選択した構成プランに基づいてデプロイメント時に生成されます。

- このファイルが存在しない場合は、コンポジット・アプリケーションを再度デプロイして、デプロイメント・ウィザードの「構成のデプロイ」ページで構成プランを正しく選択したことを確認してださい。

47.14.6.3 管理対象Oracle WebLogic Serverへのデプロイ

Oracle WebLogic管理サーバーを起動せずに管理対象Oracle WebLogic Serverを起動し(独立モードでの実行と呼ばれます)、Oracle JDeveloperからSOAコンポジット・アプリケーションをデプロイしようとすると、次のエラーが発生します。

Deployment cannot continue! No SOA Configured target servers found

Oracle WebLogic管理サーバーは実行中である必要があります。デプロイメントでは、Oracle SOA Suiteを実行しているサーバーの識別にOracle WebLogic管理サーバー接続が使用されます。さらに、管理対象サーバーへのアプリケーション・サーバー接続は作成しないでください。Oracle WebLogic管理サーバーへの接続のみ作成してください。

また、SOA構成済Oracle WebLogic Serverの状態が正常でない場合も同様のエラーが発生する場合があります。この状態は、Oracle WebLogic Server管理コンソールの「サーバー」ページの「ヘルス」列に表示されます。

WLSTを使用すると、Oracle WebLogic管理サーバーを起動せずに、SOAコンポジット・アプリケーションを管理対象Oracle WebLogic Serverにデプロイできます。詳細は、「WLSTユーティリティを使用したSOAコンポジット・アプリケーションのデプロイおよび管理」を参照してください。

47.14.6.4 双方向のSSL対応Oracle WebLogic Serverへのデプロイ

Oracle JDeveloperから双方向のSSL対応Oracle WebLogic Serverへのデプロイメントは、サポートされていません。

47.14.6.5 接続できないプロキシ・サーバーを使用したデプロイ

Oracle JDeveloperで設定したプロキシ・サーバーがホストから接続できない場合は、SOAコンポジット・アプリケーションのデプロイメント時に、図47-30 に示すようなエラーが表示されます。

図47-30 デプロイメント・エラー・メッセージ

ネットワークの外部にあるSOAインフラストラクチャ(例: soa_server1)にアクセスするには、有効なプロキシ設定が必要です。SOAインフラストラクチャがネットワーク内にある場合は、次のいずれかの処理を実行します。

プロキシ設定を変更する手順は、次のとおりです。

1. 「ツール」メニューから、「プリファレンス」→「Webブラウザとプロキシ」の順に選択します。

2. SOAサーバーがネットワーク内にある場合は、次のいずれかのタスクを実行します。

a. プロキシを使用せずにSOAインフラストラクチャに直接アクセスする場合は、「HTTPプロキシ・サーバーを使用」の選択を解除します。

b. 「例外」フィールドに、接続できないSOAサーバーのホスト名を入力します。

47.14.6.6 ADFタスク・フォームのEARファイルのデプロイメント・エラーを解決するためのロックの解放

SOAコンポジット・アプリケーションのJARファイルおよびADFタスク・フォームのEARファイルをデプロイする場合、SOA JARファイルは正常にデプロイされますが、EARファイルのデプロイ時に次のエラーが表示されます。

[wldeploy] weblogic.management.ManagementException: [Deployer:149163]The
domain edit lock is owned by another session in non-exclusive mode - this
deployment operation requires exclusive access to the edit lock and hence
cannot proceed. If you are using "Automatically Aquire Lock and Activate
Changes" in the console, then the lock will expire shortly so retry this
operation.

このエラーは、EARファイルを正常にデプロイするには、最初にOracle WebLogic Server管理コンソールでロックを解放する必要があることを示しています。

ADFタスク・フォームのEARファイルのデプロイメント・エラーを解決するためにロックを解放する手順は、次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. ページの一番上にあるコンソール・バナーの下で、「プリファレンス」→「ユーザー・プリファレンス」をクリックします。

3. 「ロックを自動取得して変更をアクティブ化」の選択を解除します。

4. 「保存」をクリックすると、「ロックして編集」や「構成の解放」などのボタンが表示されます。

Oracle WebLogic Server管理コンソールに次の説明が表示されます。

Automatically acquire the lock that enables configuration editing and
automatically activate changes as the user modifies, adds and deletes items
(for example, when the user clicks the 'Save' button). This feature is not
available in production mode.

このエラーは、使用しているデプロイ方法(Oracle JDeveloperを使用したデプロイや、antスクリプトを使用したデプロイなど)とは無関係に発生します。

47.14.6.7 メモリー増加によるコンパイル・エラーのリカバリ

SOAコンポジット・アプリケーションのコンパイル中にメモリー不足のエラーが発生した場合は、次の手順を実行してメモリーを増やします。

1. $ORACLE_HOME/binディレクトリのant-sca-compile.xmlファイルを開きます。

2. scac要素下のメモリー設定を増やします。次に例を示します。

<jvmarg value="-Xmx512M"/>

47.14.6.8 相関セットを使用したreceiveアクティビティのプロパティ・エイリアス定義が存在しないときのOracle JDeveloperコンパイル・エラー

相関セットを使用したreceiveアクティビティのプロパティ・エイリアス定義が存在しない場合、Oracle JDeveloperコンパイラはSCAC-50012エラーで失敗します。

47.14.6.9 ADFバインディング・サービス名は、デプロイされたすべてのSOAコンポジット・アプリケーション間で一意であることが必要

すべてのADFバインディングのサービス名は、デプロイされたすべてのSOAコンポジット・アプリケーション間で一意であることが必要です。

たとえば、次のような場合を考えてみます。

1. SOAサーバーに複数のコンポジットを組み込むSOAコンポジット・アプリケーションをビルドし、正常にデプロイします。

2. 新規のコンポーネントとアウトバウンド外部参照を追加して、SOAコンポジット・アプリケーション内のコンポジットの1つを変更します。

3. 更新したSOAコンポジットをリビジョン2.0としてコンパイルし、正常にビルドします。

4. 更新したSOAコンポジット・アプリケーションを、同じパーティションまたは別のパーティションにデプロイします。

次のエラーが出されることがあります。

<Oct 7, 2013 11:52:01 AM EDT> <Error> <ServletContext-/soa-infra>
<BEA-000000> <Error during deployment
oracle.fabric.common.FabricException: Deployment Failed: The serviceName
attribute "OrderProcessorService" has already been used.   ServiceName must
be unique among all deployed composites.  The new service will overwrite the
old one.
at
oracle.integration.platform.blocks.deploy.StandaloneCompositeDeploymentCoordin
atorImpl.coordinateCompositeDeployment(StandaloneCompositeDeploymentCoordinato
rImpl.java:99)
. . .
. . .

このエラーが発生した理由は、すべてのADFバインディングのサービス名が、デプロイされたすべてのSOAコンポジット・アプリケーション間で一意であることが必要だからです。

5. 回避策として、composite.xmlファイルを編集して、binding.adfセクションでサービスに別の名前を割り当てる必要があります。次に例を示します。

<binding.adf serviceName="OrderProcessorService_v2" registryName=""/>
<!-- exposed for using via direct binding api -->

47.15 SOAコンポジットの実行中のインスタンスへのパッチ適用

Oracle SOA Suite 12c (12.2.1)では、コンポジット・インスタンスへのパッチ適用がサポートされており、コンポジットの実行中のインスタンスにパッチを適用したり、ランタイムにパッチを適用した後にフォルトが発生したインスタンスをリカバリできます。これらの修正は、コンポジット・インスタンスへのパッチ適用と互換性のあるパッチにのみ含めることができます。Oracle JDeveloperで「SOAパッチ開発者」ロールを使用して、修正を行い、パッチを作成します。

コンポジット・インスタンスへのパッチ適用により、長時間実行中のインスタンスが選択可能な緊急のコンポジット修正を配信できます。進行中のインスタンスを中断せずに、互換性のある/許可された変更を行うことができます。パッチが適用された実行中のインスタンスが、パッチによって修正されたBPELトランスフォーメーションなどのビジネス・プロセスに遭遇した場合、インスタンスはビジネス・プロセスに適用された修正を取得します。

注意:
このSOA Suite機能は、Oracle Integration Continuous Availabilityの一部です。Oracle SOA Suite for Middlewareのオプションの詳細は、Oracle Fusion Middlewareライセンス情報を参照してください。

パッチを設計する場合、JDeveloperの「SOAパッチ開発者」モードによって、パッチに対して行うことができない変更は自動的に無効化されます。行うことができる互換性のある変更には、次のものがあります。

- スキーマ関連でないXSLT変更、フォルト・ポリシー、センサー・データおよび分析データに対する変更。

- トランスフォーメーション・アクティビティ、割当て操作などの互換性があるBPEL変更。

- JCAアダプタ構成プロパティ。

デプロイメント時にはコンポジット・バージョンを指定しません。Oracle JDeveloperでは、パッチを作成するコンポジット・リビジョンがパッチのデプロイ先のコンポジット・リビジョンとなります。

パッチをデプロイする前に検証できます。

次の手順を使用して、パッチを作成し、ランタイムにデプロイします。

1. Oracle JDeveloperで「SOAパッチ開発者」ロールを使用して、コンポジットに変更を加え、パッチを作成します。
詳細は、「JDeveloperでの「SOAパッチ開発者」モードの使用」を参照してください。

2. WLSTコマンドライン・ユーティリティを使用してパッチを検証し、デプロイします。
詳細は、「WLSTを使用したパッチの検証およびデプロイ」を参照してください。
パッチにコンポジットに対する修正が含まれている場合は、パッチのデプロイ後にEnterprise Manager Fusion Middleware Controlでフォルトが発生したインスタンスをリカバリできます。

47.15.1 JDeveloperでの「SOAパッチ開発者」モードの使用

JDeveloperで「SOAパッチ開発者」モードを使用して、デプロイ済コンポジットに対して修正を含むパッチを作成します。このモードで作成したパッチは、デプロイ済コンポジットのバージョン番号を変更せずに、現在デプロイされているコンポジットに適用できます。コンポジットに実行中のインスタンスがある場合でも、ランタイムにパッチを適用できます。

JDeveloperで「SOAパッチ開発者」モードを使用する手順は、次のとおりです。

- JDeveloperですでにプロジェクトを開いている場合は、「SOAパッチ開発者」モードに切り替える必要があります。Oracle JDeveloperのメニュー・バーから「ツール」→「ロールの切替え」→「SOAパッチ開発者」の順に選択します。

「再起動の確認」ダイアログが表示されます。

ダイアログによって、「SOAパッチ開発者」モードでは限定的な編集のみを行えることが示されます。「OK」をクリックしてJDeveloperを再起動します。

- Oracle JDeveloperを開いていない場合は、JDeveloperを起動し、「ロールの選択」ダイアログで「SOAパッチ開発者」ロールを選択します。

JDeveloperが「SOAパッチ開発者」モードで起動した後、コンポジット・エディタには「SOAパッチ・モード」ラベルが付いています。これは、パッチ・モードと互換性がある編集のみを行えることを示しています。

また、たとえば、BPELコンポーネントを編集する場合にも、BPELエディタに「パッチ・モード」ラベルが付きます。

BPELプロセスの特定のアクティビティのみが編集可能であり、それ以外はグレーで表示されます。また、「コンポーネント」ウィンドウには「SOAパッチ開発者」モードで使用可能なコンポーネントのみが表示されることにも注意してください。多数のプロパティは読取り専用モードで表示されます。

47.15.1.1 パッチXMLファイルの生成

Oracle JDeveloperの「SOAパッチ開発者」モードでコンポジットに変更を加え、変更を保存すると、patch.xmlファイルが自動的に生成されます。patch.xmlファイルは、コンポジットに加えた変更を示します。

次の手順では、JDeveloperでのpatch.xmlファイルの作成および表示について説明します

「SOAパッチ開発者」モードを開始し、編集用にSOAコンポジットを開いていることを確認します。

1. コンポジットに必要な変更または修正を適用します。
「SOAパッチ開発者」モードでは、限定的な変更のみが許可されます。実行中のインスタンスに影響を与えずにランタイムにデプロイできる変更があります。

たとえば、BPELトランスフォーメーション・アクティビティに関連付けられているXSLTマップに修正を加えることができます。

2. JDeveloperですべてのファイルを保存します。
たとえば、JDeveloperメイン・ツールバーで「すべて保存」ボタンをクリックできます。

patch.xmlファイルがproject_directory/SOA/SCA-INFディレクトリに自動的に作成されます。patch.xmlファイルは、「SOAパッチ開発者」モードでコンポジットに変更を加えて保存するたびに更新されます。

3. 必要に応じて、patch.xmlファイルを表示します。
メイン・メニュー・バーから「アプリケーション」→「概要」を選択し、「XMLファイル」の下で「patch.xml」を選択できます。「編集」をクリックしてpatch.xmlファイルを開きます。

次の図は、patch.xmlファイルのサンプルを示しています。XSLトランスフォーメーションおよびBPELプロセスにパッチが適用されていることを確認できます。

注意:

パッチにはセンサー情報も含まれます。これにより、すべての実行時デザインタイム(DT@RT)関連の変更が確実に保持されます。

47.15.1.2 スパース・デプロイメント・プロファイルの作成

「SOAパッチ開発者」モードでパッチを作成した後、ランタイムに変更をデプロイするためのスパース・デプロイメント・プロファイルを作成します。これにより、ランタイムにデプロイできるdeployディレクトリにパッチjarファイルが作成されます。

次の手順を使用して、JDeveloperを使用してスパース・デプロイメント・プロファイルを作成します。

1. 「アプリケーション」ウィンドウでプロジェクト名を右クリックして、「デプロイ」→「Your_Project_Name」の順に選択します。
新しいデプロイメント・プロファイルを作成することもできます。

Project_Nameのデプロイウィザードが表示されます。

2. プロジェクトをデプロイする場合と同様に、ウィザードの手順を完了します。
「構成のデプロイ」画面では、新しいバージョンを作成したり、既存のバージョンを上書きできないことに注意してください。これは、パッチは別のバージョンを作成せず、実行中のインスタンスに影響を与えずにランタイムにデプロイされるためです。

「サマリー」画面に、deployディレクトリに作成されるsca_projectname_patch.jarファイルの名前とパスが表示されます。

3. 「終了」をクリックして、パッチjarファイルを作成します。
project_name/deployディレクトリに、元のプロジェクトjarに加えてパッチjarが含められます。
パッチjarを開き、含まれているコンポーネントを表示できます。パッチjarには、「SOAパッチ開発者」モードで変更したコンポーネントのみが含まれています。

47.15.2 WLSTを使用したパッチの検証およびデプロイ

WLSTコマンドライン・ツールを使用して、パッチjarファイルを検証し、デプロイできます。sca_validatePatchコマンドおよびsca_patchCompositeコマンドを使用して、パッチ・ファイルをそれぞれ検証し、デプロイします。

次の手順を使用して、パッケージ化されたjar (コンポジットSAR)を検証し、ランタイムにデプロイします。

1. sca_validatePatchコマンドを使用して、パッチjarファイルを検証します。
help('sca_validatePatch')を使用して、sca_validatePatchコマンド構文および引数に関する詳細を取得できます。

次に例を示します。

sca_validatePatch('http://my_soa_server:8001', 'weblogic', 'welcome', '/home/sca_HelloWorld_patch.jar')

前述のコマンドでは、sca_HelloWorld_patch.jarパッチ・ファイルをmy_soa_server SOAサーバー・ランタイムに正常にデプロイできるかどうかが検証されます。

次のメッセージは、パッチが正常に検証されたことを示しています。

Composite patch has been validated successfully.

2. sca_patchCompositeコマンドを使用して、パッチjarファイルをランタイムにデプロイします。
help('sca_patchComposite')を使用して、sca_patchCompositeコマンド構文および引数に関する詳細を取得できます。

次に例を示します。

sca_patchComposite('http://my_soa_server:8001', 'weblogic', 'welcome', '/home/sca_HelloWorld_patch.jar')

前述のコマンドでは、sca_HelloWorld_patch.jarパッチ・ファイルを使用して、my_soa_serverランタイムのHelloWorldコンポジットにパッチを適用します。

次のメッセージは、パッチが正常に適用されたことを示しています。

Composite has been patched successfully.

ランタイムのコンポジットに正常にパッチが適用されました。Enterprise Manager Fusion Middleware Controlで、このパッチの適用後にリカバリできるフォルトが発生したフロー・インスタンスが以前にあった場合は、リカバリを試すことができます。

47.15.3 パッチ・ファイルの削除

JDeveloperで「SOAパッチ開発者」以外のロールを使用してSOAプロジェクトを開こうとしたときに、コンポジットに既存のパッチ・ファイルがあった場合、プロジェクトを編集する前にpatch.xmlファイルを削除する必要があることを示す警告が表示されます。

すでにパッチを適用した場合は、patch.xmlファイルを削除するオプションを問題なく選択できます。

これで、引き続きSOAプロジェクトを編集できます。

48 Oracle SOA Suite開発Mavenプラグインの使用

この章では、Oracle SOA Suite開発Mavenプラグインを使用してSOAコンポジット・アプリケーション・プロジェクトをビルドし、管理する方法を説明します。Oracle SOA Suite開発Mavenプラグインを使用して、Maven環境でSOAコンポジット・アプリケーションのコンパイル、パッケージ化、デプロイ、テスト、およびアンデプロイを実行できます。

この章の内容は次のとおりです。

- Mavenプラグインの概要

- Mavenプラグインのインストール

- Maven Archetypeの使用

Oracle Fusion MiddlewareでのMavenの使用の詳細は、『継続的統合によるアプリケーションの開発』、および『Oracle WebLogic Serverアプリケーションの開発』のWebLogic開発Mavenプラグインの使用に関する項を参照してください。

Mavenを使用したアプリケーションとプロジェクトのビルドの詳細は、http://maven.apache.org/users/index.htmlを参照してください。

48.1 Oracle SOA Suite Mavenプラグインの概要

Mavenは、ランタイム・プロジェクトの作成と管理を可能にするビルド自動化ツールです。Oracle SOA Suite Mavenプラグインを使用して、SOAコンポジット・アプリケーションをビルドおよび管理できます。Mavenは、すべての依存関係についてアーティファクト・リポジトリに準拠します。インストール済のOracleライブラリはすべてMavenリポジトリに伝播されます。これにより、Mavenはこれらをアーティファクトと認識し、プロジェクト・オブジェクト・モデル(POM)ファイル内で指定できます。

48.1.1 POMファイルおよびArchetype

Mavenプロジェクトは、POMファイルを使用して構成されます。POMファイルは、コンポジットのビルドに必要なSOAインフラストラクチャ・ツールなどの依存関係を記述します。

Archetypeは、プロジェクトを作成するためのテンプレートです。Archetypesは、単一のSOAプロジェクトを含む新しいSOAアプリケーションを作成するため、または既存のSOAアプリケーションに追加のSOAプロジェクトを追加するために提供されています。これらのArchetypesを使用して、SOAコンポジット・アプリケーションのコンパイル、パッケージ化、デプロイ、テストおよびアンデプロイを行うことができます。

次の例は、Oracle SOA Suite用のMaven POMのサンプル・ファイルを示しています。

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>MyComposite</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>sar</packaging>

<!--
This POM was generated from the SOA Maven Archetype.
Comments in this POM guide you how to use it with your project.
This POM relates to this SOA Composite, i.e. the one in this same
directory. There is another POM in the SOA Application directory (up
one) which handles the whold SOA Application, which may contain
additional projects.

The parent points to the common SOA parent POM.  That is a special POM
that is shipped by Oracle as a point of customization (only).  You can
add default values for properties like serverUrl, etc. to the SOA
common parent POM, so that you do not have to specify them over and
over in every project POM.
-->
<parent>
<groupId>com.oracle.soa</groupId>
<artifactId>soa-project-common</artifactId>
<version>12.1.3-0-0</version>
</parent>

<properties>
<!-- these parameters are used by the compile goal -->
<scac.input.dir>${project.basedir}/SOA/</scac.input.dir>
<scac.output.dir>${project.basedir}/target</scac.output.dir>
<scac.input>${scac.input.dir}/composite.xml</scac.input>
<scac.output>${scac.output.dir}/out.xml</scac.output>
<scac.error>${scac.output.dir}/error.txt</scac.error>
<scac.displayLevel>1</scac.displayLevel>
<!-- if you are using a config plan, uncomment the following line and
update to point to your config plan -->
<!--<configplan>${scac.input.dir}/configplan.xml</configplan>-->

<!-- these parameters are used by the deploy and undeploy goals -->
<composite.name>${project.artifactId}</composite.name>
<composite.revision>${project.version}</composite.revision>
<composite.partition>default</composite.partition>
<serverUrl>serverUrl</serverUrl>
<user>user</user>
<password>password</password>
<overwrite>true</overwrite>
<forceDefault>true</forceDefault>
<regenerateRulebase>false</regenerateRulebase>
<keepInstancesOnRedeploy>false</keepInstancesOnRedeploy>

<!-- these parameters are used by the test goal -->
<!-- if you are using the sca-test (test) goal, you need to uncomment the
following line and point it to your jndi.properties file. -->
<jndi.properties.input>${basedir}/jndi.properties</jndi.properties.input>
<scatest.result>${scac.output.dir}/testResult</scatest.result>
<!--  input is the name of the composite to run test suties against -->
<input>MyComposite</input>
</properties>

<!--
These refer to the properties defined above.  You should probably not
need to make any changes beflow this point - these just point to the
properties above.
-->
<build>
<plugins>
<plugin>
<groupId>com.oracle.soa.plugin</groupId>
<artifactId>oracle-soa-plugin</artifactId>
<version>12.1.3-0-0</version>
<configuration>
<compositeName>MyComposite</compositeName>
<composite>${scac.input}</composite>
<sarLocation>${scac.output.dir}/sca_${project.artifactId}_
rev${composite.revision}.jar</sarLocation>
<serverUrl>${serverUrl}</serverUrl>
<!-- note: compositeRevision is needed to package, revision is
needed to undeploy -->
<compositeRevision>${composite.revision}</compositeRevision>
<revision>${composite.revision}</revision>
<scacInputDir>${scac.input.dir}</scacInputDir>
<!-- note: if this composite contains a component that depends
on MDS to build, e.g. a Human Task or Business Rule, then
you will need to uncomment the next line, and edit it to
point to your application directory (which contains
.adf/adf-config.xml file with MDS configuration in it -->
<!--<appHome>${project.basedir}/..</appHome>-->
<!--  If you have a composite which contains a component that
depends on MDS (eg. Human Task, Business Rule) AND you
want to use a file-based MDS repository, then you
need to do either:
1. update the .adf/META-INF/adf-config.xml to point to
the correct location of the file based repository,
i.e. remove the reference to ${oracle.home} in that
file, or
2. define oracleHome here and leave the adf-config.xml
file as is.  Note that the correct value is the path
to your SOA Quickstart or JDeveloper install
directory, with "/soa" appended to it.
-->
<!--<oracleHome>JDEV_HOME/soa</oracleHome>-->
<user>${user}</user>
<password>${password}</password>
<input>${input}</input>
</configuration>
<!-- extensions=true is needed to use the custom sar packaging
type -->
<extensions>true</extensions>
</plugin>
</plugins>
</build>
</project>

注意:

ヒューマン・タスクやビジネス・ルールなどのMDSに依存するコンポジットでコンポーネントを使用している場合は、<appHome>${project.basedir}/..</appHome>行をコメント解除して、使用するアプリケーション・ディレクトリを指すように編集します。

MDSに依存するコンポーネントを使用している場合で、デフォルトのadf-config.xmlファイルから参照されるようなファイルベースのMDSを使用する場合も、<oracleHome>JDEV_HOME/soa</oracleHome>をコメント解除して、/soaを付加し、使用するSOAクイック・スタートまたはJDeveloperインストール・ディレクトリを指すように編集する必要があります。

次の例は、Oracle SOA Suiteアプリケーションを作成するためのPOMファイル内のArchetype座標を示しています。

<groupId>com.oracle.soa.archetype</groupId>
<artifactId>oracle-soa-application</artifactId>
<version>12.1.3-0-0</version>

48.1.2 Mavenプラグインのゴール

ゴールは、コンポジット・ライフ・サイクルの様々なフェーズに関連しています。

ライフ・サイクル・フェーズに関連付けられているゴールを起動すると、指定したゴールまで(そのゴールを含む)マップされているすべてのゴールが実行されます。たとえば、testゴールを実行すると、compile、packageおよびdeployのゴールがtestゴールの前に実行されます。この項の各ゴールの説明には、各コールが起動されたときに実行されるアクションがリストされています。

SOAコンポジット・アプリケーションのビルドとデプロイのライフ・サイクルをサポートするために、次の実行可能プラグイン・ゴールが提供されています。

- compile (scac)

- package (sar)

- deploy

- test (sca-test)

- undeploy

ゴールを実行する前に、そのゴールに必要なすべてのパラメータがPOMファイルに指定されていることを確認してください。POMファイルのサンプルについては、「POMファイルおよびArchetype」を参照してください。

注意:

プロジェクト、コンポジットまたはプロジェクト・ディレクトリの名前を変更した場合は、これらのゴールを実行する前に新しい名前でPOMファイルを更新してください。

次の例は、POMファイル内のOracle SOA SuiteプラグインのgroupId、artifactId、およびversionの各座標を示しています。

<groupId>com.oracle.soa.plugin</groupId>
<artifactId>oracle-soa-plugin</artifactId>
<version>12.1.3-0-0</version>

48.1.2.1 compile

compileゴールは、SOAコンポジット・アプリケーションをコンパイルします。Oracle SOA Suiteは、このゴール用のネイティブMaven実装を提供しています。次のコマンドは、SOAコンポジット・アプリケーションをコンパイルします。

mvn compile

48.1.2.2 package

packageゴールは、SOAコンポジット・アプリケーションのアーティファクトをSOAアーカイブ(SAR)ファイルにパッケージ化します。次のコマンドは、SOAコンポジット・アプリケーションをコンパイルし、パッケージ化します。

mvn package

48.1.2.3 deploy

deployゴールは、SOAコンポジット・アプリケーションをデプロイします。Oracle SOA Suiteは、このゴール用のネイティブMaven実装を提供しています。次のコマンドは、SOAコンポジット・アプリケーションをコンパイルし、コンポジットをSARファイルにパッケージ化し、SARファイルをサーバーにデプロイします。

mvn pre-integration-test

48.1.2.4 test

testゴールは、SOAコンポジット・アプリケーションのテストを実行します。Oracle SOA Suiteは、このゴール用のネイティブMaven実装を提供しています。

Oracle JDeveloperでテストを作成してからtestゴールを実行する必要があります。JDeveloperを使用したテストの作成方法の詳細は、「SOAコンポジット・アプリケーションのテストの自動化」を参照してください。

testゴールを実行する前に、jndi.properitesファイルを含める必要もあります。POMファイルで次の行を編集して、jndi.properties file: <jndi.properties.input>${basedir}/jndi.properties</jndi.properties.input>を指すようにします。

次に、jndi.propertiesファイルのサンプルを示します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.provider.url=t3://servername:7103/soa-infra
java.naming.security.principal=weblogic
java.naming.security.credentials=welcome1
dedicated.connection=true
dedicated.rmicontext=true

次のコマンドは、コンポジットをコンパイルし、コンポジットをSARファイルにパッケージ化し、SARファイルをサーバーにデプロイして、コンポジットをテストします。

mvn verify

48.1.2.5 undeploy

undeployゴールは、SOAコンポジット・アプリケーションをアンデプロイします。Oracle SOA Suiteは、このゴール用のネイティブMaven実装を提供しています。次のコマンドはコンポジットをアンデプロイします。

注意:

undeployゴールは、ライフ・サイクル・フェーズにマッピングされません。このステップは、名前を指定して明示的に呼び出す必要があります。

mvn com.oracle.soa.plugin:oracle-soa-plugin:undeploy

48.1.3 Mavenオンライン・ヘルプの使用

Mavenオンライン・ヘルプでは、ゴールとその関連コマンドのリストが提供されます。たとえば、次のコマンドを入力すると、Maven testゴールのオンライン・ヘルプが表示されます。

mvn help:describe -Ddetail=true -Dplugin=com.oracle.soa.plugin:oracle-soa-plugin:12.1.3-0-0 -Dgoal=test

このコマンドは、次のヘルプ詳細を表示します。

oracle-soa:test
Description: Description: To execute SCA Test Suites.
Implementation: com.oracle.soa.plugin.SoaTest
Language: java
Bound to phase: verify
Goal Prefix: oracle-soa

Available parameters:

format (Default: native)
User property: format
The format of the output - 'native' or 'junit'.

input
Required: true
User property: input
The name of the composite to execute tests against.

jndiPropertiesInput
Required: true
User property: jndi.properties.input
Path to JNDI properties file required for SCA Test execution.
This file should contain contents similar to the following:
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.provider.url=t3://servername:7103/soa-infra
java.naming.security.principal=weblogic
java.naming.security.credentials=welcome1
dedicated.connection=true
dedicated.rmicontext=true

partition (Default: default)
User property: partition
Which SOA partition the composite is deployed in.

result (Default: ${java.io.tmpdir}/out)
User property: result
Where to place the results.

timeout (Default: 300)
User property: timeout
How long to wait for tests to complete before timing out.

48.2 Oracle SOA Suite Mavenプラグインのインストール

Maven 3.0.5のディストリビューションは、次の場所のOracle Fusion Middlewareに含まれています。

Middleware_Home/Oracle_Home/oracle_common/modules/org.apache.maven_3.0.5

Oracle Fusion MiddlewareでのMavenのインストールの詳細は、『継続的統合によるアプリケーションの開発』の「ビルド自動化と依存性管理のためのMavenのインストールおよび構成」を参照してください。第5.1項「Mavenディストリビューションの設定」および第5.2項「Maven設定のカスタマイズ」の設定手順に従ってください。

48.2.1 Oracle SOA Suite Mavenプラグインの構成方法

Oracle SOA Suite Mavenプラグインを使用する前に、MavenリポジトリにOracle Artifactsを移入する必要があります。リポジトリの移入の詳細は、『継続的統合によるアプリケーションの開発』のMavenリポジトリ・マネージャへの移入に関する項を参照してください。次の各手順は、このガイドの特定の項にリンクされています。

Oracle SOA Suite開発Mavenプラグインを構成する手順は、次のとおりです。

1. ORACLE_HOME/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.1.3に移動します。

2. 次のコマンドを実行してMaven同期プラグインをインストールします。

mvn install:install-file -DpomFile=oracle-maven-sync-12.1.3.pom -Dfile=oracle-maven-sync-12.1.3.jar

その他のオプションについては、「Oracle Maven同期プラグインのインストール」を参照してください。

3. 次のコマンドを実行して、Oracle SOA Suite開発MavenプラグインをMavenリポジトリにシードします。

mvn com.oracle.maven:oracle-maven-sync:push -DoracleHome=ORACLE_HOME

ここでORACLE_HOMEは、Oracle Fusion Middlewareインストールのフルパスです。その他のオプションについては、「Oracle Maven同期プラグインの実行」を参照してください。

4. Maven help:describeゴールを使用して、プラグインのインストールが成功したかどうかを検証します。

mvn help:describe -DgroupId=com.oracle.soa.plugin
-DartifactId=oracle-soa-plugin -Dversion=12.1.3-0-0

Oracle SOA Suiteプラグインのインストールを確認する情報の抜粋を次に示します。

Name: Oracle SOA Maven Plugin
Description: This plugin allows users to compile, package, deploy, test and  undeploy SOA composites.
Group Id: com.oracle.soa.plugin
Artifact Id: oracle-soa-plugin
Version: 12.1.3-0-0
Goal Prefix: oracle-soa
This plugin has 6 goals:
oracle-soa:compile

48.3 Oracle SOA Suite Maven Archetypeの使用

Oracle SOA SuiteのArchetypeを使用して、SOAアプリケーション用のPOMファイルを生成します。SOAアプリケーションを追加するディレクトリの親ディレクトリから次のコマンドを実行します。SOAアプリケーションは、artifactIdプロパティの値から名前が付けられたサブディレクトリに作成されます。

注意:

Oracle SOA Suite Maven Archetypeを使用して作成されたSOAアプリケーションは、SOAアプリケーションの作成ウィザードを使用してOracle JDeveloperに作成されたものと同じです。

mvn archetype:generate
-DarchetypeGroupId=com.oracle.soa.archetype
-DarchetypeArtifactId=oracle-soa-application
-DarchetypeVersion=12.1.3-0-0
-DarchetypeRepository=local
-DgroupId=org.my.test
-DartifactId=test-soa-application
-DprojectName=test-soa-project
-Dversion=1.0-SNAPSHOT

説明:

プロパティ

説明

archetypeGroupId

使用するArchetypeのグループIDを入力します(com.oracle.soa.archetype)。

archetypeArtifactId

使用するArchetypeのアーティファクトIDを入力します(oracle-soa-application)。

archetypeVersion

Archetypeバージョンを入力します(12.1.3-0-0)。

archetypeRepository

使用するMavenリポジトリを入力します。(オプション)

groupId

ビルドするプロジェクトのグループIDを入力します(この例では、org.my.test)。

artifactId

ビルドするプロジェクトのアーティファクトIDを入力します。これは、現行ディレクトリ内のサブディレクトリの名前になります(この例では、test-soa-project)。SOAアプリケーションおよび最初のSOAプロジェクトがこのサブディレクトリに作成されます。

projectName

SOAアプリケーション内に作成されるSOAプロジェクトの名前を入力します。これはコンポジットの名前にもなります。

package

SOAアプリケーション内に作成されるSOAプロジェクトの名前を入力します。(オプション)

version

ビルドするプロジェクトのバージョンを入力します(この例では、1.0-SNAPSHOT)

49 SOAコンポジット・アプリケーションのデバッグおよび監査

この章では、Oracle JDeveloperでSOAデバッガを使用してSOAコンポジット・アプリケーションをデバッグする方法、HTTPアナライザでHTTPリクエストとレスポンス・メッセージをテストする方法およびSOAコンポジット・アプリケーションでBPELプロセス・アクティビティの監査を構成する方法を説明します。

この章の内容は次のとおりです。

- SOAデバッガの概要

- SOAコンポジット・アプリケーションのデバッグ

- HTTPアナライザを使用したSOAコンポジット・アプリケーションのテスト

- BPELアクティビティ・レベルでのSOAコンポジット・アプリケーションの監査

49.1 SOAデバッガの概要

Oracle JDeveloperでは、SOAデバッガを使用して、SOAコンポジット・アプリケーションをテストおよびデバッグできます。SOAデバッガは、Oracle JDeveloper内でトラブルシューティング環境を提供することによって、SOAコンポジット・アプリケーションの開発サイクルを短縮します。これにより、SOAコンポジット・アプリケーションをOracle JDeveloperでビルドし、それをSOAインフラストラクチャにデプロイし、Oracle Enterprise Manager Fusion Middleware Controlを起動して監査証跡とフロー・トレースのテストまたは表示を行ってから、Oracle JDeveloperに戻って作業を繰り返すという時間のかかるプロセスが必要なくなります。かわりに、次に示すコンポーネントのトラブルシューティングのために、Oracle JDeveloperでブレークポイントを設定できます。

- SOAコンポジット・アプリケーションのバインディング・コンポーネントとサービス・コンポーネント

- 同期および非同期BPELプロセス

- Oracle BPMプロセス

- Oracle Service Busパイプライン(『Oracle Service Busでのサービスの開発』のOracle Service Busアプリケーションのデバッグに関する項を参照)

SOAデバッガを使用する際には、次のガイドラインに注意してください。

- SOAコンポジット・アプリケーション名とOracle JDeveloperのプロジェクト名は同じである必要があります。

- デバッグ・セッション中に発生したすべてのSOAコンポジット・アプリケーションは、Oracle JDeveloperの現在アクティブなワークスペースに存在する必要があります。

- デバッグはOracle JDeveloperの設計ビューでのみ実行できます。Oracle Enterprise Manager Fusion Middleware ControlではSOAデバッガを実行できません。

- デバッグは、ローカライズされたユーザー操作です。別のタスク(インスタンスの検索やOracle Enterprise Manager Fusion Middleware Controlの同じコンポジットの新しいインスタンスの起動など)に切り替える場合は、デバッグ・セッションを閉じます。

- RESTサービスにブレークポイントは設定できません。

- Oracle JDeveloperの1つのインストールのSOAコンポジット・アプリケーションでデバッグするために作成したブレークポイントは、他のOracle JDeveloperインストールでは使用できません。ブレークポイントをデバッグ用に再度作成する必要があります。

- 埋込み統合WebLogic Serverを使用しているデバッグ・セッション中に、埋込みサーバーに含まれるOracle Enterprise Manager Fusion Middleware Controlのバージョンを使用して新しいインスタンスを生成したりインスタンスを問い合せることはできません。統合WebLogic Serverの詳細は、『SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』を参照してください。

- Java execアクティビティ、XSLTおよびXQueryの変換などの、言語間機能はデバッグできません。

- Oracle SOA Suiteがインストールされているサーバー上で、SOAコンポジット・アプリケーションをデバッグできます。たとえば、Oracle SOA Suiteが管理対象サーバー上で実行されている場合、クライアントは管理対象サーバーのホストとポートを使用して接続する必要があります。

- 一度に1つのクライアントのみがSOAデバッガに接続できます。

- 同じSOAコンポジット・アプリケーションの複数インスタンスを同時にデバッグできません。ただし、Oracle JDeveloperによってこのアクションは制限されません。これは正しい方法ではありません。SOAデバッガは開発ツールです。ユーザーの責任で、同時にデバッグされるインスタンスをただ1つに保つ必要があります。

- アダプタ・エンドポイント・エラーは、Oracle JDeveloperのSOAデバッガには表示されません。これらのエラーは、ログ・ファイルに記録されます。

- サーバーが開発モードの場合にのみデバッグできます。本番モードでのデバッグはサポートされていません。

- Oracle B2BおよびOracle SOAのHealthcareサービス・コンポーネントおよび参照バインディング・コンポーネントは、両方のコンポーネントでデバッグ・ポイントを設定できる場合でも、SOAデバッガを使用してデバッグすることはできません。

- SOAコンポジット・アプリケーション対SOAコンポジット・アプリケーションのデバッグはサポートされていません。

49.2 SOAコンポジット・アプリケーションのデバッグ

この項では、Oracle JDeveloperでSOAコンポジット・アプリケーションのブレークポイントを作成し、デバッグする方法を説明します。

注意:

非常に大きなペイロードを持つSOAコンポジット・アプリケーションのデバッグを試みないでください。このようなデバッグを試みると、SOAデバッガのブレークポイントがアウトバウンド方向でハングします。

49.2.1 SOAデバッガを開始する方法

SOAデバッガを開始する手順は、次のとおりです。

1. 統合WebLogic Serverを起動します。Start Server Instanceオプションを使用した統合WebLogic Serverの起動の詳細は、『SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』の「Oracle SOA Suite Quick Start for Developersのインストール」を参照してください。

2. 次のいずれかの方法でSOAデバッガを起動します。これは、単一コンポジットのデバッグに制限されます。

a. SOAコンポジット・エディタ上部にあるデバッガ・アイコン(図49-1 を参照)をクリックします。

図49-1 SOAコンポジット・エディタのデバッガ・アイコン

b. 「アプリケーション」ウィンドウでSOAコンポジット・アプリケーションを右クリックして、「デバッグ」を選択します。図49-2に詳細を示します。

図49-2 「アプリケーション」ウィンドウのSOAコンポジット・アプリケーションの「デバッグ」メニュー・オプション

図49-3 に示すように、「SOAデバッガ接続設定」ダイアログが表示されます。このダイアログにより、使用するSOAデバッグ・サーバーを定義できます。

図49-3 「SOAデバッガ接続設定」ダイアログ

3. 環境に適した値を入力し、「OK」をクリックします。表49-1に詳細を示します。

表49-1 「SOAデバッガ接続設定」ダイアログ

フィールド

説明

ホスト

接続するデバッグ・サーバーを選択します。デフォルトでは、ローカル・ホストの名前が表示されます。これはOracle JDeveloperの埋込み統合WebLogic Serverです。リモート・サーバーを入力することもできます。プロジェクトが別のホストからインポートされると、そこで使用されていたホストがここに表示されます。

ポート

デバッグ・エージェントがリスニングするポートを入力します。デフォルト値は5004です。Oracle SOA Suiteの開発者用クイック・インストールを実行すると、デバッグが開発環境で自動的に有効になります。デバッガは、本番モードまたはサーバーがクラスタの一部の場合は有効にできません。開発環境では、setDomainEnv.shファイルに次のプロパティ設定を追加することでデバッガをオーバーライドできます。

export SOA_DEBUG_FLAG="true"
export SOA_DEBUG_PORT="5004"

タイムアウト

デバッグ・セッションの確立を試みる際に、停止する前にクライアントが待機する必要のある時間を秒単位で指定します。デフォルト値は5分です。同期プロセスの場合は、次のようにデフォルト値を増やすことができます。

- Oracle Enterprise Manager Fusion Middleware ControlのSyncMaxWaitTimeプロパティを増やします。詳細は、「トランザクションのタイムアウト値の指定方法」を参照してください。

- Oracle WebLogic Server管理コンソールで、Enterprise JavaBeansプロパティBPELDeliveryBeanの「アイドル・タイムアウト」と「トランザクション・タイムアウト」の値を増やします。これらのプロパティへのアクセスの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のリモートWebサービスのエラー出力の長時間実行同期コール、または非同期トランザクションが、長時間経過した後にエラーを出して戻る場合に関する項を参照してください。

- Oracle WebLogic Server管理コンソールのホームページにある「JTA」リンクで、Java Transaction API (JTA)のタイムアウト値を増やしてください。

次回にこのページを表示しない

次にデバッガ・セッションを開始するときにこのダイアログを表示しない場合に選択します。前に定義した設定が使用されます。

「アプリケーション」ウィンドウでプロジェクトを右クリックすることで、このダイアログを再度表示できます。「プロジェクト・プロパティ」→「実行/デバッグ」→「編集」→「ツール設定」→「デバッガ」→「リモート」の順に選択し、「デバッガ接続前にダイアログ・ボックスを表示」チェック・ボックスを選択します。

注意:

これらのプロパティは、「アプリケーション」ウィンドウでプロジェクトを右クリックし、「プロジェクト・プロパティ」→「実行/デバッグ」→「編集」→「ツール設定」→「デバッガ」→「リモート」の順に選択しても編集できます。

デバッグ対象として選択されたSOAコンポジット・アプリケーションがデプロイされているかどうかを判別するチェックが行われます。表49-2に詳細を示します。

表49-2 SOAコンポジット・アプリケーションがデプロイ済かどうか判別するためのチェック

SOAコンポジット・アプリケーションの状況

結果

デプロイ済

サービス・バインディング・コンポーネントの右側のハンドルに、次のメッセージが表示されます。

Use context menu to initiate WS debugging

このメッセージの例は図49-5 を参照してください。

デバッグを開始する準備ができました。「ブレークポイントを設定してデバッグを開始する方法」に進みます。

- 未デプロイ

- デプロイ済、ただしデプロイ後にコンポジット内で設計変更があった。
注意: 「同じリビジョンIDで既存のコンポジットを上書きします。」チェック・ボックスを選択して2度目にデプロイされたコンポジットには、追加のデプロイメントは必要ありません。

- デプロイ済、ただしOracle JDeveloperのシステム・フォルダを削除した。システム・フォルダは、「ヘルプ」→「バージョン情報」→「プロパティ」を選択して、ide.system.dirを検索することで特定されます。

- 1つのOracle JDeveloperでデプロイされたが、SOAコンポジット・アプリケーションのZIPファイルはOracle JDeveloperの別のインストールで開かれた。

「Project_Nameのデプロイ」ウィザードの「デプロイメント・アクション」ページが表示され、コンポジットをデプロイする必要があります。

a. 「アプリケーション・サーバーにデプロイ」を選択します。

b. ウィザードの各ページの指示に従って、SOAコンポジット・アプリケーションをアプリケーション・サーバーにデプロイします。
SOAコンポジット・アプリケーションのデプロイの詳細は、「プロファイルのデプロイ」を参照してください。

c. デプロイメントが完了したら、「ブレークポイントを設定してデバッグを開始する方法」に進みます。

ログ・ウィンドウに次のメッセージが表示されたら、デバッグ・セッションを開始する準備ができています。

Debugger attempting to connect to remote process at host_name 5004
Debugger connected to remote process at host_name 5004
Debugger process virtual machine is SOA Debugger.

49.2.2 ブレークポイントを設定してデバッグを開始する方法

ブレークポイントは、SOAコンポジット・アプリケーション内でデバッグのために設定する意図的な一時停止位置です。次のコンポーネントに対してブレークポイントを設定できます。

- サービス・バインディング・コンポーネント

- BPELプロセス・アクティビティおよびBPMプロセスのサービス・コンポーネントのインバウンド部分とアウトバウンド部分

- Webサービス、JCAアダプタなどの参照バインディング・コンポーネント

- Oracle Service Busサービス(『Oracle Service Busでのサービスの開発』のOracle Service Busアプリケーションのデバッグに関する項を参照)

ブレークポイントが設定されているコンポーネントは、赤のリクエスト(アウトバウンド)アイコン、リプライ(インバウンド)アイコン、またはリクエスト/リプライ(アウトバウンド/インバウンド)アイコンによって示されます。図49-4 に、ブレークポイント・アイコンが設定されているSOAコンポジット・アプリケーションの例を示します。

図49-4 ブレークポイントが設定されたSOAコンポジット・アプリケーション

ブレークポイントを設定してデバッグを開始する手順は、次のとおりです。

1. 表49-3 に示すように、ブレークポイントを設定するコンポーネントを選択します。

表49-3 ブレークポイントを設定するコンポーネント

ブレークポイントを設定する対象

移動先の手順

サービス・バインディング・コンポーネント

2

参照バインディング・コンポーネント

3

BPELプロセスやBPMプロセスなどのサービス・コンポーネント

4

2. サービス・バインディング・コンポーネントにブレークポイントを設定する手順は、次のとおりです。

a. 次のメッセージが表示されているサービスの右側のハンドルを右クリックします。

Use context menu to initiate WS debugging

このアクションにより、図49-5 に示すコンテキスト・メニューが開きます。

図49-5 SOAデバッガのブレークポイント・メニューのオプション

b. 表49-4 に示すものから、該当するブレークポイント相互作用オプションを選択します。

表49-4 ブレークポイント相互作用オプション

オプション

説明

ブレークポイント・ペアの作成

リクエスト/リプライ(アウトバウンド/インバウンド)相互作用の場合に設定します。これは、リクエストとリプライの両方が重要であるシナリオに役立ちます。

リクエスト・ブレークポイントの作成

リクエスト(アウトバウンド)相互作用の場合に設定します。これは、リクエストのみが重要であるシナリオに役立ちます。

リプレイ・ブレークポイントの作成

リプライ(インバウンド)相互作用の場合に設定します。これは、リプライのみが重要であるシナリオに役立ちます。

WSデバッグの開始

デバッグ・セッションを開始します。たとえば、デバッグ・セッションには、WebサービスからBPELプロセス、アダプタ参照バインディング・コンポーネントへの開始SOAPリクエストが含まれます。

相互作用の選択項目を表す赤のアイコンが追加されます。

たとえば、「ブレークポイント・ペアの作成」を選択した場合は、リクエストとリプライのブレークポイント・アイコンが追加されます。図49-6に詳細を示します。

図49-6 サービス・バインディング・コンポーネントのリクエストおよびリプライのブレークポイント・アイコン

c. ステップ5に進みます。

3. 参照バインディング・コンポーネントにブレークポイントを設定する手順は、次のとおりです。

a. 該当する参照バインディング・コンポーネント(たとえば、Webサービスまたはデータベース・アダプタ)を右クリックし、表49-4 で説明するブレークポイント・オプションの1つを選択します。
たとえば、いくつかの参照に対して「ブレークポイント・ペアの作成」を選択した場合は、リクエストとリプライのブレークポイント・アイコンが追加されます。図49-7に詳細を示します。

図49-7 参照バインディング・コンポーネントに対して設定されるブレークポイント

b. ステップ5に進みます。

4. サービス・コンポーネントにブレークポイントを設定する手順は、次のとおりです(この例では、BPELプロセスが選択されています)。

a. 図49-8 に示すように、「編集」を選択します。

図49-8 BPELプロセスのリクエストおよびリプライのブレークポイント・アイコン

これにより、Oracle BPELデザイナでBPELプロセスが開きます。

b. ブレークポイントを設定するBPELアクティビティを右クリックして、「ブレークポイントの切替え」を選択します。図49-9に詳細を示します。

図49-9 BPELプロセスのブレークポイント設定

アイコンがアクティビティに追加されます。これらのブレークポイント・アイコンは、単なる赤い点です。これは、フローが必ず1方向に進むからです。ブレークポイントは、常に、非同期BPELプロセス内の最初のアクティビティに設定することをお薦めします。

c. ブレークポイントを無効にするには、右クリックして「ブレークポイントの切替え」を再び選択します。赤いドットが削除されます。BPELプロセス内のすべてのブレークポイントのリストを表示するには、アクティビティを右クリックして「ブレークポイント」を選択します。このダイアログでは、ブレークポイントを有効化および無効化することもできます。

d. ステップ5に進みます。

5. SOAコンポジット・アプリケーションのデバッグを開始するには、図49-5 に示すサービス・バインディング・コンポーネントの右側のハンドルを右クリックして、メニューから「WSデバッグの開始」を選択します。

これによりHTTPアナライザが起動します。

6. 送信するリクエスト・メッセージ・データを入力して「リクエストの送信」をクリックするか、「HTTPコンテンツ」をクリックし、XMLファイルからコンテンツをコピーして貼り付けます。フィールドごとにデータを入力するか、XMLドキュメントをコピー・アンド・ペーストできます。図49-10に詳細を示します。

図49-10 SOAデバッガのメッセージ・データ

デバッガは、最初に設定したブレークポイントで停止します(この例では、サービス・バインディング・コンポーネントで)。

7. Oracle JDeveloperの下部にあるログ・ウィンドウで、「データ」をクリックします。

8. メッセージのコンテンツを展開します。図49-11に詳細を示します。値をダブルクリックして変更できます。XML以外の変数では、右クリックして「値の表示」を選択します(この例では、データベース・アダプタから返されるメッセージ)。

図49-11 デバッガ起動後のメッセージのコンテンツ

49.2.3 デバッグ・セッションでのステップ実行方法

ブレークポイントを作成すると、図49-12 に示すように、対応するフレームが「構造」ウィンドウに作成されます。このフレームは、サービス・バインディング・コンポーネントのリクエスト/リプライ・エントリ・ポイント用に作成されたものです。

フレームとは場所のことです。フレームのスタックは、現在の場所までの各場所のブレッド・クラム証跡です。これは、スタック・トレースと同じです。自分の場所およびそこに進むための方法を示します。フレームは、ブレークポイントとは関係なく作成されます。ブレークポイントで停止すると、「構造」ウィンドウでそれまでに作成したすべてのフレームが表示されます。スタック・フレームにも、その時点に存在したデータが含まれています。「構造」ペインで別のスタック・フレームをクリックしても、「データ」タブが更新されます。

たとえば、参照用にBPELプロセスに接続されたWebサービスがあるときに、参照にブレークポイントを設定した場合、スタックは多くの場合、次のように表示されます。

- 参照

- BPEL起動

- BPELスコープ

- Webサービス

「Webサービス」フレームをクリックすると、「データ」タブにSOAPペイロードが表示されます。次に「BPEL起動」フレームをクリックすると、様々なBPEL変数およびその他の詳細が「データ」タブに表示されます。

フレームをステップ実行して、別のロケーション(別のブレークポイントなど)からデバッグを開始できます。この例では、LoanProcess BPELプロセスから開始します。デバッグに進むと、次のフレームが作成されます。フレームは、変数が存在する場所です。

- 「スコープ」フレーム: スコープ変数が含まれています。

- 「プロセス」フレーム: グローバル変数が含まれています。

変数は、上のフレームから下のフレームまで、プロセスから参照できます。フレームは、「構造」ウィンドウに表示されます。

図49-12 「構造」ウィンドウのフレーム

デバッグ・セッションでステップ実行するには:

1. Oracle JDeveloperのツールバーに進みます。ステップ・オプションを図49-13 に示します。

図49-13 Oracle JDeveloperのステップ・オプション

表49-5 に、各オプションを示します。

表49-5 Oracle JDeveloperメイン・メニューのステップ・オプション

アイコン

説明

デバッグ・セッションを終了または切断します。

フレームをステップ実行します。

これにより、次のブレークポイントに進みます(たとえば、図49-9 でブレークポイントを設定したBPELプロセス内のreceiveアクティビティ)。ブレークポイントが存在しない場合は、すべてのフレームをステップ実行して最初のフレームに戻ります。

[F8]を押してフレームをステップ実行することもできます。

次の有効なロケーションまでトレース実行します。

このロケーションは、新規フレームまたは同じフレーム(ただし別のロケーションにある)です。

[F7]を押してフレームでステップ実行することもできます。

フレームのステップ・アウトを行います。

このオプションは、BPELスコープまたはシーケンスのアクティビティを処理するためにのみ使用されます。スコープ処理の完了後、プロセス内で次にあるスコープまたはアクティビティで一時停止します。[Shift]キーを押しながら[F7]を押すこともできます。

ステップ操作を再開します。

[F9]を押して再開することもできます。

2. 「ステップ実行」オプションを選択した場合は、receiveアクティビティで停止します。

3. ログ・ウィンドウ内で、「データ」をクリックし、図49-14 に示すように内容を展開してBPELプロセスに定義された変数を表示します。デバッグ時にBPELプロセス変数を編集できます。図49-14 に示す例では、ペイロードは空です。

図49-14 空のペイロード

これは、図49-15 に示すように、receiveアクティビティのブレークポイントがまだ実行されていないためです。

図49-15 Receiveアクティビティのブレークポイント実行前の空のペイロード

4. 表49-5 で説明するように、「トレース実行」オプションをクリックします。

これにより、図49-16 に示すreceiveアクティビティが実行されます。

図49-16 Receiveアクティビティのブレークポイント実行後のデータ取込み済ペイロード

5. ペイロードを展開します。

「ブレークポイントを設定してデバッグを開始する方法」のステップ6で入力したデータが、ペイロードに取り込まれます。図49-17に詳細を示します。

図49-17 開いた状態のペイロード

6. 表49-5 で説明するように、「ステップ実行」オプションを選択します。デバッガは次のブレークポイントで一時停止します(この例では、図49-7 に示したように、Webサービス参照バインディング・コンポーネント)。

Webサービス・コールへのリクエスト・メッセージの内容を図49-18 に示します。

図49-18 リクエスト・メッセージのペイロードの内容

7. 「ステップ実行」オプションを選択します。

8. ペイロードを展開して、メッセージのリプライを表示します。図49-19に詳細を示します。

図49-19 リクエスト・メッセージのペイロードの内容

9. デバッグを続行します。

assignアクティビティのコピー・ルールを実行すると、SOAデバッガによって、assignアクティビティにあるコピー・ルールを示すウィンドウが表示されます。ウィンドウには、すべてのコピー・ルールが表示された表があり、コピー・ルールの横にはデバッガを停止する「ブレークポイント」アイコンがあります。

注意:

アダプタ(たとえば、データベース・アダプタ)にブレークポイントを設定した場合、SOAデバッガはBPELプロセス・サービス・コンポーネントのステップ・アウトを行い、SOAコンポジット・エディタに進みます。

49.2.4 デバッグ・セッションを終了または切断する方法

デバッグ・セッションを終了または連結解除するには:

1. ツール・メニューのボタンをクリックして、デバッグ・セッションを終了します。図49-20に詳細を示します。

図49-20 デバッグ・セッションの終了または切断

デバッガ・プロセスの終了ダイアログが表示されます。

2. オプションを選択します。表49-6に詳細を示します。

表49-6 ブレークポイント・メニューのオプション

オプション

説明

連結解除

デバッグ処理を終了せずにデバッガを除去します。

終了

デバッグ処理を終了します。

3. 「連結解除」を選択した場合は、図49-1 に示したSOAコンポジット・エディタの上部のデバッガ・アイコンをクリックしてデバッグを再開します。

4. 「終了」を選択した場合は、右クリックして「WSデバッグの開始」を選択することによってデバッガを再び開始し、新規デバッグ・セッションを開始します。

49.2.5 ブレークポイントを削除する方法

個々のブレークポイントを削除することも、すべてのブレークポイントを削除することもできます。

ブレークポイントを削除する手順は、次のとおりです。

1. 個々のブレークポイントを削除する手順は、次のとおりです。

- ブレークポイントが設定されているアクティビティを右クリックして、「ブレークポイントの切替え」を選択します。

- Oracle BPELデザイナ上部にある「ブレークポイント」アイコンをクリックして、「ブレークポイント」ダイアログでブレークポイントを削除するアクティビティを選択します。

2. すべてのブレークポイントを削除するには、SOAコンポジット・アプリケーション内で右クリックして、「すべてのブレークポイントを削除」を選択します。

3. 図49-21 に示すように、Oracle BPELデザイナ内でBPELプロセスの上部にあるアイコンをクリックします。

図49-21 Oracle BPELデザイナのブレークポイント・アイコン

図49-22 に示すように、「ブレークポイント」ダイアログが起動します。

図49-22 「ブレークポイント」ダイアログ

4. 「有効化」チェック・ボックスで、無効にするBPELプロセスのブレークポイントを選択します。

49.2.6 アダプタ・プロパティを表示する方法

ログ・ウィンドウの「データ」タブで、アダプタのプロパティを表示できます。

アダプタのプロパティを表示する手順は、次のとおりです。

1. データベース・アダプタなどの参照バインディング・コンポーネントのブレークポイントで停止するまで、「ステップ実行」アイコンをクリックします。図49-23に詳細を示します。

図49-23 JCAアダプタのプロパティ

顧客の存在を確認するためにプロセスが停止します。アダプタ・エンドポイントのプロパティが表示されます。図49-24に詳細を示します。実行されるSQL構文も表示されます。

図49-24 アダプタの出力

2. プロパティを右クリックし、「全値の表示」を選択して、顧客に渡されるデータを表示します(この例では、nativePayloadが選択されています)。図49-25 は、渡される顧客IDを示しています。「全値の表示」は、XML以外のBPEL変数にも有用です。

図49-25 渡されるリクエスト・メッセージのコンテンツ

3. 「ステップ実行」アイコンをクリックして、データベース・アダプタを実行します。

4. プロパティを右クリックし、「全値の表示」を選択して顧客のリプライ・メッセージ・データを表示します。この例では、値1は顧客が存在することを示しています。図49-26に詳細を示します。

図49-26 返されるリプライ・メッセージのコンテンツ

5. 値を変更するには、プロパティを右クリックして「値の変更」を選択します。

49.2.7 スレッドを表示する方法

プロセス・インスタンスは常に、単一の論理スレッド(同期、非同期にかかわらず)で実行されます(プロセスIDはスレッドと考えられます)。SOAデバッガは、論理スレッドを確認して使用します。プロセスにflowアクティビティまたはflowNアクティビティがある場合、複数の論理スレッドがそのflowアクティビティまたはflowNアクティビティを実行します。

スレッドを表示する手順は、次のとおりです。

1. メイン・メニューから、「ウィンドウ」→「デバッガ」→「スレッド」を選択します。

「構造」ウィンドウに「スレッド」タブが表示されます。

2. BPELプロセスのサービス・バインディング・コンポーネントをトレース実行して、デバッグを開始します。

図49-27 の「構造」ウィンドウに示すように、リクエストのスレッド値は40です。

図49-27 リクエストのスレッド値

3. 非同期BPELプロセスのreceiveアクティビティをトレース実行します。

図49-28 に示すように、リプライのスレッド値は41です。

図49-28 リプライのスレッド値

49.3 HTTPアナライザを使用したSOAコンポジット・アプリケーションのテスト

Oracle JDeveloperのHTTPアナライザを使用して、SOAコンポジット・アプリケーション内のHTTPリクエストとレスポンスをテストできます。HTTPアナライザを使用して、HTTPリクエスト/レスポンス・パッケージ・ペアのコンテンツを検査できます。リクエスト・パッケージの内容を編集して再送信し、戻されるレスポンス・パケットを確認できます。HTTPアナライザの詳細は、Oracle JDeveloperによるアプリケーションの開発の「Javaプロジェクトの監査と監視」を参照してください。

HTTPアナライザを使用してSOAコンポジット・アプリケーションをテストする手順は、次のとおりです。

1. 「ウィンドウ」メイン・メニューから、「アプリケーション・サーバー」 を選択します。

2. 「アプリケーション・サーバー」ウィンドウで、SOAコンポジット・アプリケーションを展開します。

3. テストするコンポーネント(この例では、Webサービス・バインディング・コンポーネント)を右クリックして、「Webサービスのテスト」を選択します。図49-29に詳細を示します。

図49-29 「アプリケーション・サーバー」ウィンドウ内のテスト対象コンポーネント

HTTPアナライザが表示されます。

4. 送信するリクエスト・メッセージ・データを入力して「リクエストの送信」をクリックするか、「HTTPコンテンツ」をクリックし、XMLファイルからコンテンツをコピーして貼り付けます。図49-30に詳細を示します。

図49-30 HTTPアナライザ

正常に実行されると、図49-31 に示すような出力が右側のペインに表示されます。

図49-31 レスポンスHTTPヘッダー

「Webサービスのテスト」ページを使用してもテストを実行できます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のビジネス・フローのテスト・インスタンスの起動に関する項を参照してください。

49.4 BPELアクティビティ・レベルでのSOAコンポジット・アプリケーションの監査

監査証跡データは、データベースに永続保存される状態データの大きな割合を占めることがよくあります。永続保存される状態データの量を削減するために、BPELプロセス・アクティビティ・レベルで細分性の高い監査レベルを指定できます。これらの設定は、サービス・コンポーネント、SOAコンポジット・アプリケーション、BPELプロセス・サービス・エンジン、およびSOAインフラストラクチャのレベルで構成された監査証跡設定より優先されます。

次の手順を実行します。

- SOAコンポジット・アプリケーション内でBPELアクティビティに対して実行する監査のレベルを定義する、監査ポリシーXMLファイルを作成および構成します。

- 監査ポリシーをBPELプロセスにバインドする監査ポリシー・バインディングXMLファイルを作成し、構成します。

- composite.xmlファイルと同じディレクトリ・ロケーション、またはcomposite.xmlファイル内のプロパティで指定した別のディレクトリに、これらのファイルを配置します。

- SOAコンポジット・アプリケーションをSOAインフラストラクチャにデプロイします。

- Oracle Enterprise Manager Fusion Middleware ControlのSOAコンポジット・アプリケーションのフロー・トレース内で、BPELプロセス・アクティビティの監査証跡を表示します。

次のガイドラインに留意してください。

- 監査ポリシーは、標準のBPEL 1.1および2.0のアクティビティおよびスコープと、BPEL拡張アクティビティ(たとえば、電子メール、通知、その他すべて)の両方の監査をサポートします。親スコープ内で、監査対象にする特定の子スコープ、および監査対象にしないその他の子スコープを構成できます。

- サポートされる監査レベルを表49-7 に示します。

表49-7 監査レベル

レベル

説明

Inherit

ロギングは、Oracle Enterprise Manager Fusion Middleware Controlの「SOAインフラストラクチャの共通プロパティ」ページで設定したSOAインフラストラクチャ監査レベルと一致します。これがデフォルトの設定です。

Production

ビジネス・フロー・インスタンスに関する最小限の情報が収集されます。たとえば、BPELプロセス・サービス・エンジンはペイロードを収集しません。したがって、フローの監査証跡でペイロード詳細は使用できません。このレベルは、標準の操作とテストに最適です。

Development

BPELプロセス・アクティビティに関する完全な情報が収集されます。このオプションを選択すると、コンポジット・インスタンスのトラッキングとペイロード・トラッキングの両方が実行されます。ただし、メッセージ・フローの各ステップでペイロードが格納されるため、パフォーマンスに影響を与える可能性があります。この設定は、デバッグする際に便利です。

Off

ロギングは実行されません。コンポジット・インスタンスのトラッキング情報とペイロード・トラッキング情報は収集されません。

- フォルト・ポリシー・バインディング・ファイルでは、プロセス名とリビジョン番号のワイルドカード・マッチングがサポートされています。次に例を示します。

- Order*と入力すると、コンポジットOrderProcess、OrderRejected、およびOrderConfirmedに含まれるBPELプロセス・サービス・コンポーネントに一致します。

<process auditPolicy="noLoops" name="Order*"/>

- 1*と入力すると、コンポジット・リビジョン1.0、1.1、および1.2に一致します。

<process auditPolicy="noAssign" name="*" revision="1.*"/>

次の例は、使用する監査ポリシー・スキーマを示しています。

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://schemas.oracle.com/bpel/auditpolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://schemas.oracle.com/bpel/auditpolicy"
elementFormDefault="qualified">
<!-- activity can have a type or a name as optional attribute.-->
<!-- Audit rules apply to all activities if no specific type or name is -->
<!-- provided -->
<xs:complexType name="Activity">
<xs:attribute name="type" type="xs:QName" use="optional"/>
<xs:attribute name="name" type="tns:idType" use="optional"/>
<xs:attribute name="auditLevel" type="tns:auditLevelType" use="required"/>
</xs:complexType>
<xs:simpleType name="idType">
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="auditLevelType">
<xs:restriction base="xs:string">
<xs:enumeration value="off"/>
<xs:enumeration value="minimal"/>
<xs:enumeration value="production"/>
<xs:enumeration value="development"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="auditPolicy">
<xs:complexType>
<xs:sequence>
<xs:element name="activity" type="tns:Activity" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="tns:idType" use="required"/>
<xs:attribute name="version" type="xs:string" default="1.0"/>
</xs:complexType>
<!-- we restrict users to provide mulitple rules for same activity -->
<xs:key name="UniqueActivity">
<xs:selector xpath="tns:activity"/>
<xs:field xpath="@type"/>
<xs:field xpath="@name"/>
</xs:key>
</xs:element>
</xs:schema>

次の例は、使用する監査ポリシー・バインディング・スキーマを示しています。

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://schemas.oracle.com/bpel/auditpolicyBinding"
xmlns:tns="http://schemas.oracle.com/bpel/auditpolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:complexType name="Process">
<xs:attribute name="auditPolicyId" type="tns:idType" use="optional"/>
<xs:attribute name="name" type="tns:idType" use="optional"/>
<xs:attribute name="revision" type="tns:idType" use="optional"/>
</xs:complexType>
<xs:simpleType name="idType">
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="auditPolicyBinding">
<xs:complexType>
<xs:sequence>
<xs:element name="process" type="tns:Process"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string"
default="1.0"/>
</xs:complexType>
<xs:key name="UniqueActivity">
<xs:selector xpath="tns:process"/>
<xs:field xpath="@name"/>
<xs:field xpath="@revision"/>
</xs:key>
</xs:element>
</xs:schema>

49.4.1 BPELアクティビティ・レベルでSOAコンポジット・アプリケーションを監査する方法

この項では、監査ポリシーと監査ポリシー・バインディング・ファイルを作成し、構成する方法を説明します。

BPELアクティビティ・レベルでSOAコンポジット・アプリケーションを監査する手順は、次のとおりです。

1. BPELアクティビティの監査レベル設定を定義する監査ポリシー・ファイル(たとえば、audit-policy.xmlという名前)を作成し、構成します。ファイルには任意の名前を付けることができ、前の項で説明したスキーマに従っている必要があります。

<auditPolicies xmlns="http://schemas.oracle.com/bpel/auditpolicy"
xmlns:bpel="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:bpelx="http://schemas.oracle.com/bpel/extension" version="1.0">
<auditPolicy name="whilePolicy">
<!-- enabling this will cause all assign activities to not log -->
<!-- anything to the audit trail -->
<activity type="bpel:assign" auditLevel="production"/>

<!-- enabling this will cause all scope activities and all -->
<!-- enclosed activities to not log anything to the audit trail -->
<activity type="bpel:scope" auditLevel="production"/>
<!-- enabling this will cause all while activities to log with -->
<!-- minimak level  -->
<activity type="bpel:while" auditLevel="production"/>
<activity type="bpel:reply" auditLevel="production"/>
<activity type="bpel:flow" auditLevel="production"/>
<activity type="bpel:switch" auditLevel="off"/>
<activity type="bpel:terminate" auditLevel="production"/>
<activity type="bpel:empty" auditLevel="development"/>
<activity type="bpel:wait" auditLevel="production"/>
<activity type="bpel:throw" auditLevel="off"/>
<activity type="bpel:catchAll" auditLevel="production"/>
<activity type="bpel:sequence" auditLevel="off"/>
<activity type="bpel:receive" auditLevel="production"/>
</auditPolicy>
</auditPolicies>

注意:

BPEL拡張の監査を有効にするには、該当する監査レベル(たとえば、production)を指定してbpelx:execを入力します。

<activity type="bpelx:exec" auditLevel="production"/>

2. 監査ポリシーをBPELプロセスにバインドする監査ポリシー・バインディングXMLファイル(たとえば、audit-binding.xmlという名前)を作成し、構成します。ファイルには任意の名前を付けることができ、前の項で説明したスキーマに従っている必要があります。この例では、myProcessで始まるすべてのBPELプロセスの監査が有効になるように、ワイルドカード・オプションを使用しています。その他いくつかの監査オプションはコメント化されています。

<auditPolicyBindings xmlns="http://schemas.oracle.com/bpel/auditpolicyBinding"
version="1.0">
<!-- enabling this will cause all processes in the domain to use this -->
<!-- policy audit -->
<!-- <process auditPolicyName="whilePolicy" name="BPELProcess*"/> -->
<!-- enabling this will cause all processes that start with the name -->
<!-- myProcess to use the audit policy 'noLoops' -->
<process auditPolicyName="noLoops" name="myProcess*"/>
<!-- enabling this will cause all processes -->
<!-- process auditPolicyName="noAssign" name="*"/> -->
</auditPolicyBindings>

3. composite.xmlファイルと同じディレクトリにXMLファイルを配置します。

4. composite.xmlファイル内でaudit-policy.xmlファイルとaudit-binding.xmlファイルを定義します。

<property name="oracle.composite.bpelAuditPolicyFile">audit-policy.xml</property>
<property
name="oracle.composite.bpelAuditBindingFile">audit-binding.xml</property>

5. SOAコンポジット・アプリケーションをデプロイします。

50 SOAコンポジット・アプリケーションのテストの自動化

この章では、SOAコンポジット・アプリケーションのテストを自動化するテスト・ケースの作成、デプロイおよび実行方法について説明します。SOAコンポジット・アプリケーションに含まれているBPELプロセス・サービス・コンポーネントをテストするためのテスト・ケースを作成することもできます。テスト・ケースを使用すると、本番環境へのデプロイメントの前に、SOAコンポジット・アプリケーションとWebサービス・パートナ間の相互作用をシミュレートできます。これにより、本番環境へのデプロイメント準備が完了するときに、プロセスとWebサービス・パートナの相互作用が期待どおりであるかを確認できます。

この章の内容は次のとおりです。

- コンポジット・テスト・フレームワークの概要

- テスト・スイートのコンポーネントの概要

- コンポジット・テストの作成ウィザードを使用したテスト・スイートとテスト・ケースの作成

- SOAコンポジット・エディタのテスト・モードによるテスト・ケースのコンテンツの編集

- BPELプロセス・サービス・コンポーネントのテスト

- テスト・スイートのデプロイおよび実行

50.1 コンポジット・テスト・フレームワークの概要

Oracle SOA Suiteには、SOAコンポジット・アプリケーションに対して反復可能なテストを作成して実行するための、自動化されたテスト・スイート・フレームワークが用意されています。

テスト・スイート・フレームワークの機能は、次のとおりです。

- Webサービス・パートナの相互作用のシミュレート

- テスト・データによるプロセス・アクションの検証

- テスト結果のレポートの作成

50.1.1 テスト・ケースの概要

テスト・フレームワークは、SOAコンポジット・アプリケーション・レベルでのテストをサポートしています。このタイプのテストでは、ワイヤ、サービス・バインディング・コンポーネント、サービス・コンポーネント(BPELプロセスやOracle Mediatorのサービス・コンポーネントなど)、および参照バインディング・コンポーネントがテストされます。

詳細は、「コンポジット・テストの作成ウィザードを使用したテスト・スイートとテスト・ケースの作成」を参照してください。

50.1.2 テスト・スイートの概要

テスト・スイートは、1つ以上のテスト・ケースの論理的な集合で構成されます。各テスト・ケースには、テスト・インスタンスの実行時に実行される一連のコマンドが含まれています。テスト・スイートの実行は、テスト実行と呼ばれます。各テストは、単一のSOAコンポジット・アプリケーション・インスタンスに対応しています。

詳細は、次を参照してください。

- コンポジット・テストの作成ウィザードを使用したテスト・スイートとテスト・ケースの作成

- SOAコンポジット・エディタのテスト・モードによるテスト・ケースのコンテンツの編集

50.1.3 エミュレーションの概要

エミュレーションにより、SOAコンポジット・アプリケーションが実行中に相互作用する次のコンポーネントの動作をシミュレートできます。

- コンポジット内部の内部サービス・コンポーネント

- コンポジット外部のバインディング・コンポーネント

別のサービス・コンポーネントまたはバインディング・コンポーネントを起動せずに、コンポーネントまたは参照からのレスポンスを指定できます。

詳細は、次を参照してください。

- 「エミュレーション」

- SOAコンポジット・エディタのテスト・モードによるテスト・ケースのコンテンツの編集

50.1.4 アサーションの概要

アサーションにより、変数データやプロセス・フローを検証できます。次のタイプのアサーションを実行できます。

- XML文書全体のアサーション
XML文書全体の要素値を予想される要素値と比較します。たとえば、融資申請のXML文書全体の内容を別の文書と正確に比較します。XMLUnitパッケージ内のXMLTestCaseクラスには、XMLファイル間でアサーションを実行するための一連のメソッドが含まれています。これらのメソッドの詳細は、次のURLを参照してください。

http://xmlunit.sourceforge.net

- メッセージのパート・セクションのアサート
メッセージのパート・セクションの値を予想値と比較します。例として、XML文書メッセージ全体のペイロード・パートなどがあります。

- 非リーフ要素のアサーション
XMLフラグメントの値を予想値と比較します。例として、リーフ要素のSSN、email、customerNameおよびloanAmountが記載された融資申請があります。

- リーフ要素のアサーション
選択した文字列要素や数値要素の値、または正規表現パターンを予想値と比較します。例として、融資申請のSSNがあります。

アサートの詳細は、「アサーション」を参照してください。

50.2 テスト・スイートのコンポーネントの概要

この項では、テスト・ケースを構成するテスト・コンポーネントについて例をあげて説明します。これらのテストを作成してプロセスにインポートする方法についてはこの章で後述します。

50.2.1 プロセスの開始

最初に、SOAP Webサービスなどのバインディング・コンポーネント・サービスにおけるプロセスの操作を定義します。次の例では、TestFwk SOAコンポジット・アプリケーションを開始するinitiateの操作を定義しています。また、開始ペイロードも定義されています。

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SCA Test Modeler version 1.0 at [6/13/07 10:50 AM]. -->
<compositeTest compositeDN="TestFwk"
xmlns="http://xmlns.oracle.com/sca/2006/test">
<about></about>
<initiate serviceName="client" operation="initiate" isAsync="true">
<message>
<part partName="payload">
<content>
<loanApplication xmlns="http://www.autoloan.com/ns/autoloan">
<SSN>111222333</SSN>
<email>joe.smith@example.com</email>
<customerName>Joe Smith</customerName>
<loanAmount>20000</loanAmount>
<carModel>Camry</carModel>
<carYear>2007</carYear>
<creditRating>800</creditRating>
</loanApplication>
</content>
</part>
</message>
</initiate>
</compositeTest>

50.2.2 エミュレーション

エミュレーションを作成して、SOAコンポジット・アプリケーションがWebサービス・パートナから受け取るメッセージ・データをシミュレートします。

次の例のテスト・コードでは、エラーのある融資申請が開始されます。Webサービス・パートナから返信のフォルト・メッセージを受け取ります。

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SCA Test Modeler version 1.0 at [7/3/07 3:29 PM]. -->
<compositeTest compositeDN="CompositeTest"
xmlns="http://xmlns.oracle.com/sca/2006/test">
<about></about>
<initiate serviceName="client" operation="initiate" isAsync="true">
<message>
<part partName="payload">
<filePath>loanApplication.xml</filePath>
</part>
</message>
</initiate>
<wireActions wireSource="LoanBroker/CreditRatingService" operation="process">
<emulate duration="PT0S">
<fault faultName="ser:NegativeCredit" xmlns:ser="http://services.otn.com">
<message>
<part partName="payload">
<filePath>creditRatingFault.xml</filePath>
</part>
</message>
</fault>
</emulate>
</wireActions>
</compositeTest>

このエミュレーションでは、loanApplication.xmlとcreditRatingFault.xmlの2つのメッセージ・ファイルが起動します。loanApplication.xmlの融資申請に0で始まる社会保障番号が記載されている場合、creditRatingFault.xmlファイルは次の例に示すフォルト・メッセージを返します。

<error xmlns="http://services.otn.com">
Invalid SSN, SSN cannot start with digit '0'.
</error>

詳細は、「SOAコンポジット・エディタのテスト・モードによるテスト・ケースのコンテンツの編集」を参照してください。

50.2.3 アサーション

アサーションを作成し、SOAコンポジット・アプリケーション実行中の特定時点で、XML文書全体、メッセージのパート・セクション、非リーフ要素またはリーフ要素を検証します。次の例は、customerName変数の内容を指定した内容と一致させるようにOracle SOA Suiteに指示するものです。

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SCA Test Modeler version 1.0 at [6/13/07 10:51 AM]. -->
<compositeTest compositeDN="TestFwk"
xmlns="http://xmlns.oracle.com/sca/2006/test">
<about></about>
<initiate serviceName="client" operation="initiate" isAsync="true">
<message>
<part partName="payload">
<content>
<loanApplication xmlns="http://www.autoloan.com/ns/autoloan">
<SSN>111222333</SSN>
<email>joe.smith@example.com</email>
<customerName>Joe Smith</customerName>
<loanAmount>20000</loanAmount>
<carModel>Camry</carModel>
<carYear>2007</carYear>
<creditRating>800</creditRating>
</loanApplication>
</content>
</part>
</message>
</initiate>
<wireActions wireSource="client" operation="initiate">
<assert comparisonMethod="string">
<expected>
<location key="input" partName="payload"
xpath="/s1:loanApplication/s1:customerName"
xmlns:s1="http://www.autoloan.com/ns/autoloan"/>
<simple>Joe Smith</simple>
</expected>
</assert>
</wireActions>
</compositeTest>

詳細は、「SOAコンポジット・エディタのテスト・モードによるテスト・ケースのコンテンツの編集」を参照してください。

50.2.4 メッセージ・ファイル

メッセージ・インスタンス・ファイルを使用すると、Webサービス・パートナから返されたメッセージ・データをシミュレートできます。受け取ったメッセージ・データをXMLファイルに手動で入力したり、SOAコンポジット・エディタのテスト・モードを使用してファイルをロードすることができます。たとえば、次のメッセージ・ファイルは、パートナから返された信用格付け結果900をシミュレートします。

<rating xmlns="http://services.otn.com">900</rating>

テスト・モードでのメッセージ・ファイルのロードの詳細は、「SOAコンポジット・エディタのテスト・モードによるテスト・ケースのコンテンツの編集」を参照してください。

50.3 コンポジット・テストの作成ウィザードを使用したテスト・スイートとテスト・ケースの作成

この項では、SOAコンポジット・アプリケーション用のテスト・スイートとそのテスト・ケースを作成する方法について説明します。テスト・ケースは、テスト・インスタンスの実行時に実行される一連のコマンドで構成されています。

次に示す2つの方法のどちらかで、テスト・スイートとテスト・ケースを作成できます。

- 「アプリケーション」ウィンドウで

- Oracle JDeveloperメイン・メニューから

どちらのオプションも、「コンポジット・テストの作成」ウィザードを起動します。このウィザードでは、開始操作、コールバック操作、および入出力メッセージを定義できます。

注意:

テスト・スイート名またはテスト・ケース名としてマルチバイト文字列を入力しないでください。マルチバイト文字列を入力すると、Oracle Enterprise Manager Fusion Middleware Controlからテストを実行するときにエラーが発生します。

1. 次のいずれかの手順を実行して、新規テスト・スイートを作成するか、既存のテスト・スイート内に新規コンポジット・テストを作成します。表50-1に詳細を示します。

表50-1 テスト・スイートの作成または選択

場所

実行する手順

Oracle JDeveloperメイン・メニュー

a. 「ファイル」→「新規」→「アプリケーション」→「SOA層」→「テスト」→「コンポジット・テスト・スイート」を選択します。
「テスト・スイートの作成」ダイアログが表示されます。

b. テスト・スイート名を入力し、「OK」をクリックします。

または

a. 「ファイル」→「ギャラリから」→「SOA層」→「テスト」→「コンポジット・テスト・スイート」を選択します。
「テスト・スイートの作成」ダイアログが表示されます。

b. テスト・スイート名を入力し、「OK」をクリックします。

「アプリケーション」ウィンドウ

a. testsuitesフォルダを右クリックして、「テスト・スイートの作成」を選択します。
「テスト・スイートの作成」ダイアログが表示されます。

b. テスト・スイート名を入力し、「OK」をクリックします。

「構造」ウィンドウ

a. 「テスト・スイート」を右クリックし、「テスト・スイートの作成」を選択します。
「テスト・スイートの作成」ダイアログが表示されます。

b. テスト・スイート名を入力し、「OK」をクリックします。

Oracle JDeveloperメイン・メニュー

a. 「ファイル」→「新規」→「アプリケーション」→「SOA層」→「テスト」→「コンポジット・テスト」を選択します。

または

a. 「ファイル」→「新規」→「コンポジット・テスト」を選択します。

注意: どちらを選択した場合も、新規テスト・スイートを作成するか、または既存のテスト・スイートを選択して新規コンポジット・テストを組み込むかを選択するオプションがあります。

図50-1 に示すように、「コンポジット・テストの作成」ウィザードの「テスト名とテスト・スイート」ページが表示されます。

図50-1 「コンポジット・テストの作成」ウィザードの「テスト名とテスト・スイート」ページ

このウィザードを使用すると、「SOAコンポジット・エディタのテスト・モードによるテスト・ケースのコンテンツの編集」で説明するように、SOAコンポジット・エディタをテスト・モードで使用してテストの詳細を手動で作成することなく、単純なテストを作成できます。このエディタをテスト・モードで手動で使用する必要があるのは、エミュレーションなどの追加のテスト・メタデータを追加する場合のみです。

2. 表50-2 で説明するように、環境に適した値を指定して、「次へ」をクリックします。

表50-2 「コンポジット・テストの作成」ウィザードの「テスト名とテスト・スイート」ページ

フィールド

説明

テスト名

テストの名前を入力します。

説明

テストのオプション説明を入力します。この説明は、Oracle Enterprise Manager Fusion Middleware Controlの「ユニット・テスト」タブの「テスト・ケース」ページにある「説明」列に表示されます。

テスト・スイート

このテストを組み込む既存のテスト・スイートを選択するか、「テスト・スイートの作成」ダイアログで新規テスト・スイートを作成するためのアイコンをクリックします。

図50-2 に示すように、「コンポジット・テストの作成」ウィザードの「サービスと操作」ページが表示されます。

図50-2 「コンポジット・テストの作成」ウィザードの「サービスと操作」ページ

3. 表50-3 で説明するように、環境に適した値を指定して、「次へ」をクリックします。

表50-3 「コンポジット・テストの作成」ウィザードの「サービスと操作」ページ

フィールド

説明

サービス

テストするSOAコンポジット・アプリケーションを選択します。

演算子

操作を選択します。

コールバック操作

オプションでコールバック(レスポンス)操作を選択します。

図50-3 に示すように、「コンポジット・テストの作成」ウィザードの「入力メッセージ」ページが表示されます。このページでは、操作をテストするための入力メッセージを指定できます。

図50-3 「コンポジット・テストの作成」ウィザードの「入力メッセージ」ページ

表50-4 で説明するように、環境に適した値を指定して、「次へ」をクリックします。

表50-4 「コンポジット・テストの作成」ウィザードの「入力メッセージ」ページ

フィールド

説明

パート

入力を含むメッセージ・パート(例: payload)を選択します。操作入力メッセージが複数のパートからなる場合は、パート名を1つずつ変更してそれぞれのメッセージ・パートを指定します。

メッセージ・パートごとに、XMLドキュメントのコンテンツを手動で入力することも、XMLファイルからドキュメントをロードすることもできます。

値

次の方法で、Webサービス・パートナに送信するシミュレート済入力メッセージを作成します。

- 手動で入力

クリックすると、「値の入力」フィールドにメッセージ・データを手動で入力できます。「サンプルの生成」ボタンをクリックすると、テスト用のメッセージ・パート・スキーマからサンプル・ファイルが自動的に生成されます。同じテスト、または同じテスト・スイート内の他のテストに後で使用するためにサンプル・ファイルを保存するには、「別名保存」をクリックします。

- ファイルからロード

「参照」アイコンをクリックすると、メッセージ・データをファイルからロードできます。このファイルは、「アプリケーション」ウィンドウの「メッセージ」フォルダに追加されます。

図50-4 に示すように、「コンポジット・テストの作成」ウィザードの「出力メッセージ」ページが表示されます。このページは、操作またはコールバック操作から発行されることが予期される出力メッセージを指定します。

図50-4 「コンポジット・テストの作成」ウィザードの「出力メッセージ」ページ

表50-5 の説明に従って環境に適した値を指定して、「終了」をクリックします。

表50-5 「コンポジット・テストの作成」ウィザードの「出力メッセージ」ページ

フィールド

説明

送信元

メッセージを受信する元の外部Webサービスを選択します。

パート

出力を含むメッセージ・パート(例: payload)を選択します。操作入力メッセージが複数のパートからなる場合は、パート名を1つずつ変更してそれぞれのメッセージ・パートを指定します。

メッセージ・パートごとに、XMLドキュメントのコンテンツを手動で入力することも、XMLファイルからドキュメントをロードすることもできます。

値

次の方法で、Webサービス・パートナから返されるシミュレート済出力メッセージを作成します。

- 手動で入力

クリックすると、「値の入力」フィールドにメッセージ・データを手動で入力できます。「サンプルの生成」ボタンをクリックすると、テスト用のサンプル・ファイルが自動的に生成されます。「別名保存」をクリックして、サンプル・ファイルを保存します。

- ファイルからロード

「参照」アイコンをクリックすると、メッセージ・データをファイルからロードできます。このファイルは、「アプリケーション」ウィンドウの「メッセージ」フォルダに追加されます。

テスト・スイートが作成され、SOAコンポジット・エディタのテスト・モードでテストが表示されます。図50-5に詳細を示します。必要な場合は、エミュレーションなどのテスト・メタデータを追加できます。現在のテストが完了した場合は、ツールバーのテスト・イメージ・ボタンをクリックして、別のテストの作成に進むことができます。テストを実行する場合は、緑色の矢印ボタンを押すことができます。

図50-5 テスト・スイートの作成

次のサブフォルダとともに、テストが「アプリケーション」ウィンドウに作成されます。

- componenttests

- includes

- messages
テスト・モード・ユーザー・インタフェースを使用してこのディレクトリにロードしたメッセージ・テスト・ファイルが格納されます。

- tests
テスト・スイート用のXMLファイルを含んでいます。

テスト・スイートに基づく名前が付けられたフォルダも「構造」ウィンドウに表示されます。これは、のテスト・モードであることを示しています。テストの開始、アサーションおよびエミュレーションをテスト・モードで作成できます。テスト・モードでは、他の変更(サービス・コンポーネントのプロパティ・ダイアログの編集、サービス・コンポーネントのエディタへのドロップなど)は実行できません。

次のオペレーティング・システム・テスト・スイート・ディレクトリも作成されます。

C:\JDeveloper\mywork\application_name\project_name\testsuites\test_suite_name

4. テスト・モードを終了しての設計モードに戻るには、デザイナ上部の最後にあるアイコンをクリックします。図50-6に詳細を示します。

図50-6 テスト・モードの終了

5. プロンプトが表示されたら変更内容を保存します。

6. 「アプリケーション」ウィンドウの「テスト・スイート」フォルダにあるXMLファイル名をダブルクリックして、テスト・モードに戻ります。図50-7に詳細を示します。

図50-7 テスト・モードへのアクセス

注意:

- testsuitesフォルダのサブフォルダの下に表示されるfilelist.xmlファイルは編集しないでください。これらのファイルは設計時に自動的に作成され、実行時にテスト・ケースの数を計算するために使用されます。

- テスト・スイート内に別のテスト・スイートを作成することはできません。ただし、テスト・スイートをサブディレクトリに編成することは可能です。

50.4 SOAコンポジット・エディタのテスト・モードによるテスト・ケースのコンテンツの編集

「コンポジット・テストの作成」ウィザードを使用してテスト・スイートとテスト・ケースの基本的なコンテンツを作成した後、SOAコンポジット・エディタのテスト・モードでさらに更新を行うことができます。

テスト・ケースは、プロセスの開始、エミュレーションおよびアサーションで構成されます。プロセスの開始を作成して、SOAコンポジット・アプリケーションへのクライアント・インバウンド・メッセージを開始します。エミュレーションを作成して、SOAコンポジット・アプリケーションがWebサービス・パートナから受け取る入出力メッセージ・データ、フォルト・データ、コールバック・データあるいはこれらすべてのタイプをシミュレートします。アサーションを作成して、プロセスの実行時に、XML文書全体、メッセージのパート・セクション、非リーフ要素およびリーフ要素を検証します。

注意:

プロパティ・インスペクタでテスト・ケースのコンテンツを編集することもできます。編集するコンポーネントまたはワイヤをシングルクリックすると、ページの下部でプロパティ・インスペクタが編集のために起動します。

50.4.1 インバウンド・メッセージの開始方法

インバウンド・メッセージを開始する手順は、次のとおりです。

最初に、SOAコンポジット・アプリケーションへのインバウンド・クライアント・メッセージの送信を開始する必要があります。

1. テスト・モードでSOAコンポジット・アプリケーションに移動します。

2. 図50-8 に示すサービス・バインディング・コンポーネントをダブルクリックします。

図50-8 サービス・バインディング・コンポーネントへのアクセス

「起動メッセージ」ダイアログが表示されます。

3. 表50-6 に記載されている詳細を入力します。

表50-6 「起動メッセージ」ダイアログのフィールドと値

フィールド

値

サービス

バインディング・コンポーネント・サービスの名前(client)が表示されます。

操作

サービス・バインディング・コンポーネントの操作タイプ(initiate)が表示されます。

パート

送信するインバウンド・メッセージのタイプ(例: payload)を選択します。

値

次の方法で、クライアントから送信されるシミュレート済メッセージを作成します。

- 手動で入力

クリックすると、「値の入力」フィールドにメッセージ・データを手動で入力できます。「サンプルの生成」ボタンをクリックすると、テスト用のサンプル・ファイルが自動的に生成されます。「別名保存」をクリックして、サンプル・ファイルを保存します。

- ファイルからロード

「参照」アイコンをクリックすると、メッセージ・データをファイルからロードできます。このファイルは、「アプリケーション」ウィンドウの「メッセージ」フォルダに追加されます。

図50-9 に、このダイアログを示します。

図50-9 「起動メッセージ」ダイアログ

クライアントからのインバウンド・プロセス開始メッセージは、次のようになります。

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SCA Test Modeler version 1.0 at [7/12/07 8:36 AM]. -->
<compositeTest compositeDN="CompositeTest"
xmlns="http://xmlns.oracle.com/sca/2006/test">
<about/>
<initiate serviceName="client" operation="initiate" isAsync="true">
<message>
<part partName="payload">
<filePath>loanApplication.xml</filePath>
</part>
</message>
</initiate>
. . .
. . .

プロセス開始ファイルで参照されるloanApplication.xmlには、次のように融資申請ペイロードが含まれます。

<loanApplication xmlns="http://www.autoloan.com/ns/autoloan">
<SSN>111222333</SSN>
<email>joe.smith@example.com</email>
<customerName>Joe Smith</customerName>
<loanAmount>20000</loanAmount>
<carModel>Camry</carModel>
<carYear>2007</carYear>
<creditRating>800</creditRating>
</loanApplication>

4. 「OK」をクリックします。

50.4.2 アウトバウンド・メッセージのエミュレート方法

アウトバウンド・メッセージをエミュレートする手順は、次のとおりです。

注意:

テスト・ケースのインスタンス内での複数エミュレーションの作成がサポートされるのは、一方のエミュレーションが出力メッセージ用で、他方のエミュレーションがコールバック・メッセージ用の場合のみです。

同期のWebサービス・パートナから返されるメッセージをシミュレートできます。

1. テスト・モードでSOAコンポジット・アプリケーションに移動します。

2. 「アプリケーション」ウィンドウの「テスト・スイート」フォルダの下にあるテスト・ケースをダブルクリックします。図50-10に詳細を示します。

図50-10 テスト・ケースへのアクセス

内のSOAコンポジット・アプリケーションがリフレッシュされて、テスト・モードで表示されます。このモードでは、テスト情報を定義できます。

3. テストするSOAコンポジット・アプリケーション領域のワイヤをダブルクリックします。図50-11 に示す例では、LoanBrokerプロセスと同期のCreditRating Webサービスの間のワイヤが選択されています。

図50-11 ワイヤへのアクセス

これにより、図50-12 に示す「ワイヤ・アクション」ダイアログが表示されます。このダイアログでは、SOAコンポジット・アプリケーションの選択したパートに対するエミュレーションとアサーションを設計できます。

図50-12 「ワイヤ・アクション」ダイアログ

4. 「エミュレート」タブをクリックします。

5. 「追加」アイコンをクリックします。

6. 「出力のエミュレート」をクリックします。

7. 表50-7 に記載されている詳細を入力します。

表50-7 出力メッセージのエミュレート・ダイアログのフィールドと値

フィールド

値

パート

出力を含むメッセージ・パート(例: payload)を選択します。

値

次の方法で、Webサービス・パートナから返されるシミュレート済出力メッセージを作成します。

- 手動で入力

クリックすると、「値の入力」フィールドにメッセージ・データを手動で入力できます。「サンプルの生成」ボタンをクリックすると、テスト用のサンプル・ファイルが自動的に生成されます。「別名保存」をクリックして、サンプル・ファイルを保存します。

- ファイルからロード

「参照」アイコンをクリックすると、メッセージ・データをファイルからロードできます。このファイルは、「アプリケーション」ウィンドウの「メッセージ」フォルダに追加されます。

期間

Webサービス・パートナからメッセージが配信されるまでの最大待機時間を入力します。

図50-13 に、このダイアログを示します。

図50-13 「出力のエミュレート」が選択された状態の「エミュレート」ダイアログ

手動入力またはファイルからロードして作成する、同期のWebサービス・パートナからのシミュレート済出力メッセージは、次のようになります。

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SCA Test Modeler version 1.0 at [7/3/07 3:26 PM]. -->
<compositeTest compositeDN="CompositeTest"
xmlns="http://xmlns.oracle.com/sca/2006/test">
<about></about>
<initiate serviceName="client" operation="initiate" isAsync="true">
<message>
<part partName="payload">
<filePath>loanApplication.xml</filePath>
</part>
</message>
</initiate>
<wireActions wireSource="LoanBroker/CreditRatingService" operation="process">
<emulate duration="PT0S">
<message>
<part partName="payload">
<filePath>creditRatingResult.xml</filePath>
</part>
</message>
</emulate>
</wireActions>
</compositeTest>

出力メッセージで参照されるcreditRatingResult.xmlメッセージ・ファイルは、信用格付け結果の詳細を提供します。

<rating xmlns="http://services.otn.com">900</rating>

8. 「OK」をクリックします。

50.4.3 コールバック・メッセージのエミュレート方法

コールバック・メッセージをエミュレートする手順は、次のとおりです。

注意:

テスト・ケースのインスタンス内での複数エミュレーションの作成がサポートされるのは、一方のエミュレーションが出力メッセージ用で、他方のエミュレーションがコールバック・メッセージ用の場合のみです。

非同期のWebサービス・パートナから返されるコールバック・メッセージをシミュレートできます。

1. 「アウトバウンド・メッセージのエミュレート方法」のステップ1からステップ3を実行して、ワイヤ・アクション・ダイアログにアクセスします。

2. 「エミュレート」タブをクリックします。

3. 「追加」アイコンをクリックします。

4. 「コールバックのエミュレート」をクリックします。このフィールドは非同期プロセスの場合のみ有効になります。

5. 表50-8 に記載されている詳細を入力します。

表50-8 コールバック・メッセージのエミュレートのフィールド

フィールド

値

コールバック操作

コールバック操作(例: onResult)を選択します。

コールバック・メッセージ

非同期プロセスのコールバック・メッセージ名が表示されます。

パート

コールバックを含むメッセージ・パート(例: payload)を選択します。

値

次の方法で、非同期のWebサービス・パートナから返されるシミュレート済コールバック・メッセージを作成します。

- 手動で入力

クリックすると、「値の入力」フィールドにメッセージ・データを手動で入力できます。「サンプルの生成」ボタンをクリックすると、テスト用のサンプル・ファイルが自動的に生成されます。「別名保存」をクリックして、サンプル・ファイルを保存します。

- ファイルからロード

「参照」アイコンをクリックすると、メッセージ・データをファイルからロードできます。このファイルは、「アプリケーション」ウィンドウの「メッセージ」フォルダに追加されます。

期間

Webサービス・パートナからコールバック・メッセージが配信されるまでの最大待機時間を入力します。

図50-14 に、このダイアログを示します。

図50-14 「コールバックのエミュレート」が選択された状態の「エミュレート」ダイアログ

Webサービス・パートナからのシミュレート済コールバック・メッセージは、次のようになります。このメッセージは手動で入力するか、ファイルからロードします。

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SCA Test Modeler version 1.0 at [7/3/07 3:27 PM]. -->
<compositeTest compositeDN="CompositeTest"
xmlns="http://xmlns.oracle.com/sca/2006/test">
<about></about>
<initiate serviceName="client" operation="initiate" isAsync="true">
<message>
<part partName="payload">
<filePath>loanApplication.xml</filePath>
</part>
</message>
</initiate>
<wireActions wireSource="LoanBroker/LoanService" operation="initiate">
<emulate callbackOperation="onResult" duration="PT0S">
<message>
<part partName="payload">
<filePath>loanOffer.xml</filePath>
</part>
</message>
</emulate>
</wireActions>
</compositeTest>

コールバック・メッセージで参照されるloanOffer.xmlメッセージ・ファイルは、信用格付け承認の詳細を提供します。

<loanOffer xmlns="http://www.autoloan.com/ns/autoloan">
<providerName>Bank Of America</providerName>
<selected>false</selected>
<approved>true</approved>
<APR>1.9</APR>
</loanOffer>

6. 「OK」をクリックします。

50.4.4 フォルト・メッセージのエミュレート方法

フォルト・メッセージをエミュレートする手順は、次のとおりです。

Webサービス・パートナから返されるフォルト・メッセージをシミュレートできます。このシミュレーションによって、プロセス内のフォルト処理機能をテストできます。

1. 「アウトバウンド・メッセージのエミュレート方法」のステップ1からステップ3を実行して、ワイヤ・アクション・ダイアログにアクセスします。

2. 「エミュレート」タブをクリックします。

3. 「追加」アイコンをクリックします。

4. 「フォルトのエミュレート」をクリックします。

5. 表50-9 に記載されている詳細を入力します。

表50-9 「フォルトのエミュレート」メッセージ・フィールド

フィールド

値

フォルト

パートナから返されるフォルトのタイプ(例: NegativeCredit)を選択します。

フォルト・メッセージ

メッセージ名が表示されます。

パート

フォルトを含むメッセージ・パート(例: payload)を選択します。

値

次の方法で、Webサービス・パートナから返されるシミュレート済フォルト・メッセージを作成します。

- 手動で入力

クリックすると、「値の入力」フィールドにメッセージ・データを手動で入力できます。「サンプルの生成」ボタンをクリックすると、テスト用のサンプル・ファイルが自動的に生成されます。「別名保存」をクリックして、サンプル・ファイルを保存します。

- ファイルからロード

「参照」アイコンをクリックすると、メッセージ・データをファイルからロードできます。このファイルは、「アプリケーション」ウィンドウの「メッセージ」フォルダに追加されます。

期間

Webサービス・パートナからフォルト・メッセージが配信されるまでの最大待機時間を入力します。

図50-15 に、このダイアログを示します。

図50-15 「フォルトのエミュレート」が選択された状態の「エミュレート」ダイアログ

手動入力またはファイルからロードして作成する、Webサービス・パートナからのシミュレート済フォルト・メッセージの例は、「エミュレーション」を参照してください。

6. 「OK」をクリックします。

50.4.5 アサーションの作成方法

アサーションを作成する手順は、次のとおりです。

アサーションを実行して、変数データやプロセス・フローを検証します。アサーションを使用すると、プロセスの実行時に、XML文書全体のテスト・データ、メッセージのパート・セクション、非リーフ要素またはリーフ要素を検証できます。この検証は、値を抽出し、その値を予想値と比較して行います。

1. 「アウトバウンド・メッセージのエミュレート方法」のステップ1からステップ3を実行して、ワイヤ・アクション・ダイアログにアクセスします。

2. 「アサート」タブをクリックします。

図50-16 に、このダイアログを示します。

図50-16 「アサート」タブが選択された状態の「ワイヤ・アクション」ダイアログ

3. 「追加」アイコンをクリックします。

「アサートの作成」ダイアログが表示されます。

4. 表50-10 に示すように、ダイアログの上部で、実行するアサーションのタイプを選択します。この操作で入力メッセージのみがサポートされる場合は、「入力のアサート」ボタンが有効になります。この操作で入力メッセージと出力メッセージの両方がサポートされる場合は、「入力のアサート」と「出力のアサート」ボタンの両方が有効になります。

表50-10 アサーションのタイプ

タイプ

説明

入力のアサート

インバウンド方向のアサーションを作成する場合に選択します。

出力のアサート

アウトバウンド方向のアサーションを作成する場合に選択します。

コールバックのアサート

コールバックのアサーションを作成する場合に選択します。

フォルトのアサート

フォルトをアプリケーション・フローにアサートする場合に選択します。

5. 実行するアサーションのタイプに応じて、表50-11 に示す各項を参照してください。

表50-11 アサーションのタイプ

アサーションの対象

参照先

- 文書のパート・セクション

- 非リーフ要素

- XML文書全体

パート・セクション、非リーフ要素またはXML文書全体に対するアサーションの作成

リーフ要素

リーフ要素に対するアサーションの作成

50.4.5.1 パート・セクション、非リーフ要素またはXML文書全体に対するアサーションの作成

パート・セクション、非リーフ要素またはXML文書全体に対してアサーションを作成する手順は、次のとおりです。

このテストでは、各値が予想値と比較されます。

注意:

メッセージに複数のパート(たとえば、payload1、payload2およびpayload3)がある場合は、各パートに対して個別のアサーションを作成する必要があります。

1. 「参照」をクリックして、アサートの対象となるターゲットのパート・セクション、非リーフ要素またはXML文書全体を選択します。

「アサート・ターゲットの選択」ダイアログが表示されます。

2. 値を選択して、「OK」をクリックします。たとえば、payloadなどの変数を選択してパート・セクション・アサーションを実行します。

図50-17 に、このダイアログを示します。この例は、パート・セクション・アサーションの実行方法を示していますが、XML文書全体アサーションの例では、LoanBrokerRequestMessageが選択され、非リーフ・アサーションの例では、loanApplicationが選択されます。

図50-17 メッセージのパート・セクションの選択

「アサートの作成」ダイアログは、選択した変数に基づいてリフレッシュされます。

3. 残りのフィールドに、表50-12 に記載されている詳細を入力します。

表50-12 「アサートの作成」ダイアログのフィールドと値

フィールド

値

フォルト

アサートするフォルトのタイプ(例: NegativeCredit)を選択します。このフィールドは、「アサーションの作成方法」の手順4で「フォルトのアサート」を選択した場合のみ表示されます。

ターゲットのアサート

ステップ2で選択したアサート・ターゲットが表示されます。

比較方法

比較の厳密度を指定します。

- xml-identical: XML文書の要素と属性間で正確な一致が必要な場合に使用します。2つのXML文書の間に差異がある場合、比較は失敗します。たとえば、一方の文書で要素名のpurchaseOrderが使用され、他方の文書で要素名のinvoiceが使用されている場合、比較は失敗します。また、この比較は、2つの要素の子属性は同じだが、各要素内の属性の順序が異なる場合も失敗します。

- xml-similar: コンテンツの類似性を比較するが、正確な一致は必要ない場合に使用します。たとえば、双方で同じネームスペースURIが使用されているが、それぞれのネームスペース接頭辞が異なる場合は、比較に成功します。この比較は、双方に同じ子属性を持つ同じ要素はあるが、各要素内の属性の順序が異なる場合も成功します。
前述の2つ例の差異は、リカバリ可能とみなされるため、同一と判断されます。

XMLファイルのコンテンツ比較の詳細は、XMLUnitに関する次のWebサイトを参照してください。

http://xmlunit.sourceforge.net/userguide/html/ar01s03.html#The%20Difference%20Engine

パート

XML文書を含むメッセージ・パート(例: payload)を選択します。

値

次の方法で、コンテンツをアサート・ターゲットのコンテンツと比較するXML文書を作成します。

- 手動で入力

クリックすると、「値の入力」フィールドにメッセージ・データを手動で入力できます。「サンプルの生成」ボタンをクリックすると、テスト用のサンプル・ファイルが自動的に生成されます。「別名保存」をクリックして、サンプル・ファイルを保存します。

- ファイルからロード

「参照」アイコンをクリックすると、メッセージ・データをファイルからロードできます。このファイルは、「アプリケーション」ウィンドウの「メッセージ」フォルダに追加されます。

説明

説明を入力します(オプション)。

図50-18 に、「入力のアサート」が選択された状態のダイアログを示します。

図50-18 「入力のアサート」が選択された状態の「アサートの作成」ダイアログ

4. 「OK」をクリックします。

図50-19 に示すように、「ワイヤ・アクション」ダイアログに、選択した内容が表示されます。

図50-19 「アサート」タブが選択された状態の「ワイヤ・アクション」ダイアログ

5. 「OK」をクリックします。

50.4.5.2 リーフ要素に対するアサーションの作成

リーフ要素に対してアサーションを作成する手順は、次のとおりです。

このテストでは、値が予想値と比較されます。

1. 「参照」をクリックして、アサートするリーフ要素を選択します。

「アサート・ターゲットの選択」ダイアログが表示されます。

2. リーフ要素を選択して、「OK」をクリックします。たとえば、loanAmountを選択してアサーションを実行します。図50-20に詳細を示します。

図50-20 リーフ要素の選択

「アサートの作成」ダイアログは、選択したXML文書全体に基づいてリフレッシュされます。

3. 残りのフィールドに、表50-13 に記載されている詳細を入力します。

表50-13 「アサートの作成」ダイアログのフィールドと値

フィールド

値

フォルト

アサートするフォルトのタイプ(例: NegativeCredit)を選択します。このフィールドは、「アサーションの作成方法」の手順4で「フォルトのアサート」を選択した場合のみ表示されます。

コールバック操作

アサートするコールバックのタイプ(例: onResult)を選択します。このフィールドは、「アサーションの作成方法」のステップ4で「コールバックのアサート」を選択した場合にのみ表示されます。

ターゲットのアサート

ステップ2で選択した変数アサート・ターゲットが表示されます。

比較方法

次の比較タイプを選択します。

- string: 文字列値を比較します。

- number: 数値を比較します。

- pattern-match: 正規表現パターン(例: [0-9]*)を比較します。Java Development Kit (JDK)の正規表現(regexp)コンストラクトがサポートされています。たとえば、パターンab[0-9]*cdの入力は、ab123cdまたはab456cdの値が適正であることを意味します。アスタリスク(*)は、任意の発生数を示します。

値のアサート

予想値を入力します。この値はアサート・ターゲットの値と比較されます。

説明

説明を入力します(オプション)。

図50-21 に、「入力のアサート」が選択された状態のダイアログを示します。

図50-21 「アサートの作成」ダイアログ

4. 「OK」をクリックします。

図50-22 に示すように、「ワイヤ・アクション」ダイアログに、選択した内容が表示されます。

図50-22 「アサート」タブが選択された状態の「ワイヤ・アクション」ダイアログ

50.4.6 アサーションに関する必知事項

テストが実行されて、返されたレスポンス・タイプが想定されているタイプと異なる場合、アサーションはスキップされます。たとえば、特定のメッセージに対してフォルト(RemoteFault)が返されることを想定していたが、かわりにレスポンス(BpelResponseMessage)が返される場合です。

常に想定されている動作をアサートおよびエミュレーションすることをお薦めします。

50.5 BPELプロセス・サービス・コンポーネントのテスト

「コンポジット・テストの作成」ウィザードを使用してテスト・スイートとテスト・ケースの基本的なコンテンツを作成した後、新規または既存のSOAコンポジット・アプリケーションのテスト・スイートに含まれている、個別のBPELプロセス・サービス・コンポーネントのテストを自動化できます。本番環境にデプロイする前に、これらのテスト・ケースを使用して、BPELプロセスとそのWebサービス・パートナの間の相互作用をシミュレートできます。これにより、本番環境へのデプロイメント準備が完了するまでに、BPELプロセスとWebサービス・パートナの相互作用が期待どおりであるかを確認できます。

次に、LoanBroker BPELプロセス・サービス・コンポーネントに対するコンポーネント・テストを含む、SOAコンポジット・アプリケーションのテスト・スイートの例を示します。

<compositeTest compositeDN="TestFwk"
xmlns="http://xmlns.oracle.com/sca/2006/test">
<about></about>
<initiate serviceName="client" operation="initiate" isAsync="true">
<message>
<part partName="payload">
<content>
<loanApplication xmlns="http://www.autoloan.com/ns/autoloan">
<SSN>111222333</SSN>
<email>joe.smith@example.com</email>
<customerName>Joe Smith</customerName>
<loanAmount>20000</loanAmount>
<carModel>Camry</carModel>
<carYear>2007</carYear>
<creditRating>800</creditRating>
</loanApplication>
</content>
</part>
</message>
</initiate>
<componentTest componentName="LoanBroker" filePath="assert.xml"/>
</compositeTest>

前の例では、assert.xmlテストによって、変数およびフォルトに対してアサーションが指定されています。

注意:

ビジネス・ルール、ヒューマン・タスク、Oracle MediatorまたはSpringサービス・コンポーネントのテストは自動化できません。

50.5.1 BPELプロセスのアクティビティのアサーションの概要

BPELプロセスのアクティビティに対して、変数アサーションおよびフォルト・アサーションを作成できます。次の例では、BPELプロセスでtextVarおよびcrOutputのコンテンツが指定されたコンテンツと必ず一致するように指示しています。

<bpelTest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/sca/2006/test"
componentName="LoanBroker">
<activityActions activityName="elementAssign">
<assert comparisonMethod="number">
<description>Some other assertion.</description>
<expected>
<location key="textVar"
xmlns:loan="http://www.autoloan.com/ns/autoloan"/>
<simple>111222333</simple>
</expected>
</assert>
</activityActions>
<activityActions activityName="invokeCR">
<assert comparisonMethod="number">
<description>Make sure we got the output.</description>
<expected>
<location key="crOutput" partName="payload" xpath="/tns:rating"
xmlns:tns="http://services.otn.com"/>
<simple>560</simple>
</expected>
</assert>
</activityActions>
</bpelTest>

BPELプロセスのアクティビティに対するアサーションの作成の詳細は、「アサーションの作成方法」を参照してください。

50.5.2 Waitアクティビティの早送りアクションの概要

waitアクティビティを使用すると、プロセスは指定された期間または時間制限に達するまで待機できます。BPELプロセス・サービス・コンポーネントをテストするときには、waitアクティビティをバイパスしてテストを続行することが必要となる場合があります。早送りアクションを使用すると、waitアクティビティをバイパスして、テスト・シナリオを進める時間を指定できます。次の例では、BPELプロセスにwaitアクティビティを1秒間バイパスするように指示しています。

<bpelTest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/sca/2006/test
TestFwk.xsd"
xmlns="http://xmlns.oracle.com/sca/2006/test"
componentName="LoanBroker">
<activityActions activityName="wait1">
<fastForward duration="PT1S"/>
</activityActions>
</bpelTest>

waitアクティビティの早送りアクションの作成の詳細は、「waitアクティビティのバイパス方法」を参照してください。

50.5.3 Assertアクティビティの実行の概要

BPELプロセスでアクティビティが実行される回数を指定して検証できます。次の例では、invoke、elementAssign、invokeCRおよびreplyOutputの各アクティビティをそれぞれ1回実行するよう、BPELプロセスに対して指示しています。

<bpelTest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/sca/2006/test"
componentName="LoanBroker">
<assertActivityExecuted activityName="invoke" executionCount="1"/>
<assertActivityExecuted activityName="elementAssign" executionCount="1"/>
<assertActivityExecuted activityName="invokeCR" executionCount="1"/>
<assertActivityExecuted activityName="replyOutput" executionCount="1"/>
</bpelTest>

assertアクティビティ実行の作成の詳細は、「アクティビティの実行回数の指定方法」を参照してください。

50.5.4 BPELプロセス・サービス・コンポーネントのテストの作成方法

BPELプロセス・サービス・コンポーネントのテストを作成する手順は、次のとおりです。

1. テスト・スイートのBPELプロセスをダブルクリックします(この例ではLoanBroker)。

テスト・スイートをまだ作成していない場合は、「コンポジット・テストの作成ウィザードを使用したテスト・スイートとテスト・ケースの作成」を参照してください。作成するBPELプロセス・サービス・コンポーネントのテストは、SOAコンポジット・アプリケーションのテスト・スイート全体に含まれます。

図50-23 に示すように、「コンポーネント・テストの作成」ダイアログが表示されます。

図50-23 「コンポーネント・テストの作成」ダイアログ

2. 図50-23 に示すように、デフォルト名をそのまま使用するか、または別の名前を入力します。

3. 「OK」をクリックします。

図50-24 に示すように、テスト・モードのBPELプロセスが表示されます。

左下にある「構造」ウィンドウに、「アサート」、「早送り」および「アサート実行数」フォルダが表示されます。これらのフォルダを右クリックして、アサーション、早送り(waitアクティビティの実行をバイパスします)およびアサーションの実行数をそれぞれ作成します。

デザイナの上部に、次のボタンが表示されます。

- BPEL: クリックすると、Oracle BPELデザイナの設計モード(テスト・モード以外)で、BPELプロセス・サービス・コンポーネントにアクセスできます。図50-24 では、BPELプロセスのテスト・モードであるため、このボタンは現在有効になっています。

- 監視: クリックすると、Oracle BPELデザイナでBPELプロセス・モニターを構成できます。BPELプロセス・モニターでは、データを分析してグラフィカル表示するために、Oracle BAMアダプタを介してデータをOracle BAMに送信できます。

- テスト: BPELプロセス・サービス・コンポーネントのテスト・モードであるため、このボタンは現在無効になっています。このボタンは、「BPEL」ボタンをクリックしてOracle BPELデザイナの設計モードになると有効になります。

- 分析: クリックすると、Oracle BPMN、ヒューマン・ワークフロー、BPELプロセスなどのOracle SOA Suiteコンポーネントで分散データを収集するための共通測定メカニズムを作成できます。

図50-24 テスト・モードのBPELプロセス・サービス・コンポーネント

50.5.5 アサーションの作成方法

BPELプロセスのアクティビティで、変数およびフォルトに対してアサーションを作成できます。

アサーションを作成する手順は、次のとおりです。

1. 次の方法のいずれかを使用してアサーションを作成するアクティビティを選択します。

a. 「構造」ウィンドウで、「アサート」フォルダを右クリックして「作成」を選択するか、または「アサート」フォルダを選択して「追加」ボタンをクリックします。
「Assert」ダイアログが表示されます。

b. 「アクティビティ名」フィールドで、「参照」アイコンをクリックしてアクティビティを選択します。

または

a. デザイナで特定のBPELアクティビティを右クリックし、「アクティビティ・テスト・データの編集」を選択します。

b. 「アサート」タブをクリックします。

c. 「追加」アイコンをクリックします。
選択したアクティビティが「アクティビティ名」フィールドに表示されます。

2. 表50-14 に示すように、残りのフィールドに詳細を入力します。

図50-14 BPELアクティビティに対するアサーション

フィールド

値

変数のアサート

変数をアサートする場合に選択します。

フォルトのアサート

フォルトをアサートする場合に選択します。

ターゲット

次のようにアサートするターゲットを選択します。

- 「変数のアサート」を選択した場合は、「参照」アイコンをクリックしてアサートする変数のタイプ(/autoloan:loanApplication/autoloan:SSNなど)を選択します。

- 「フォルトのアサート」を選択した場合は、「参照」アイコンをクリックしてアサートするフォルトのタイプ(NegativeCreditなど)を選択します。

比較方法

XMLドキュメントを比較する場合は、比較の厳密度を指定します。

- XML Identical: XML文書の要素と属性間で正確な比較が必要な場合に使用します。2つのXML文書の間に差異がある場合、比較は失敗します。たとえば、一方の文書で要素名のpurchaseOrderが使用され、他方の文書で要素名のinvoiceが使用されている場合、比較は失敗します。また、この比較は、2つの要素の子属性は同じだが、各要素内の属性の順序が異なる場合も失敗します。

- XML Similar: コンテンツの類似性を比較するが、正確な一致は必要ない場合に使用します。たとえば、双方で同じネームスペースURIが使用されているが、それぞれのネームスペース接頭辞が異なる場合は、比較に成功します。この比較は、双方に同じ子属性を持つ同じ要素はあるが、各要素内の属性の順序が異なる場合も成功します。
前述の2つ例の差異は、リカバリ可能とみなされるため、同一と判断されます。

変数を比較する場合は、次のようにタイプを指定します。

- 文字列: 文字列値を比較する場合に選択します。

- Java正規表現によるパターン一致: 正規表現によるパターン(たとえば、[0-9]*)を比較する場合に選択します。Java Development Kit (JDK)の正規表現(regexp)コンストラクトがサポートされています。たとえば、パターンab[0-9]*cdの入力は、ab123cdまたはab456cdの値が適正であることを意味します。アスタリスク(*)は任意の発生数を表します。

- 数値: 数値を比較する場合に選択します。

パート

XML文書を含むメッセージ・パート(例: payload)を選択します。

値

次の方法で、コンテンツをアサート・ターゲットのコンテンツと比較するXML文書を作成します。

- 手動で入力

クリックすると、「値の入力」フィールドにメッセージ・データを手動で入力できます。「インスタンス・サンプルの生成」アイコンをクリックすると、テスト用のサンプル・ファイルが自動的に生成されます。「別名保存」アイコンをクリックして、サンプル・ファイルを保存します。

- ファイルからロード

「参照」アイコンをクリックすると、メッセージ・データをファイルからロードできます。このファイルは、「アプリケーション」ウィンドウの「メッセージ」フォルダに追加されます。

説明

説明を入力します(オプション)。

3. 「OK」をクリックします。
「構造」ウィンドウで「アサート」フォルダを展開し、アサートを作成したアクティビティを表示します。図50-25に詳細を示します。

図50-25 「構造」ウィンドウの「アサート」フォルダ

50.5.6 waitアクティビティのバイパス方法

waitアクティビティをバイパスして、テスト・シナリオを進める時間を指定できます。時間制限が時間切れになると、waitアクティビティは処理されます。

waitアクティビティをバイパスする手順は、次のとおりです。

1. 次の方法のいずれかを使用して、バイパスするwaitアクティビティを選択します。

a. 「構造」ウィンドウで、「早送り」フォルダを右クリックして「作成」を選択するか、または「早送り」フォルダを選択して「追加」ボタンをクリックします。
「早送り」ダイアログが表示されます。

b. 「アクティビティ名」フィールドで、「参照」アイコンをクリックしてwaitアクティビティを選択します。

または

a. デザイナで特定のwaitアクティビティを右クリックし、「アクティビティ・テスト・データの編集」を選択します。

b. 「早送り」タブをクリックします。このタブは、BPELプロセスにwaitアクティビティが存在する場合にのみ表示されます。

c. 「追加」アイコンをクリックします。
選択したwaitアクティビティが「アクティビティ名」フィールドに表示されます。

2. 「期間」リストで、waitアクティビティをバイパスする期間(1秒など)を指定します。

3. 「OK」をクリックします。

4. 「構造」ウィンドウで「早送り」フォルダを展開して、waitアクティビティをバイパスして、テスト・シナリオを進める時間を表示します。図50-26に詳細を示します。

図50-26 「構造」ウィンドウの「早送り」フォルダ

waitアクティビティの詳細は、「waitアクティビティによる有効期限の設定」を参照してください。

50.5.7 アクティビティの実行回数の指定方法

アクティビティを指定した回数実行するよう指定できます。これにより、アクティビティがプロセス・フローで適切な回数だけ実行されることを確認できます(Whileアクティビティが適切な回数だけ実行されることを確認するなど)。

アクティビティの実行回数を指定する手順は、次のとおりです。

1. 次の方法のいずれかを使用して、実行するアクティビティを選択します。

a. 「構造」ウィンドウで、「アサート実行数」フォルダを右クリックして「作成」を選択するか、または「アサート実行数」フォルダを選択して「追加」ボタンをクリックします。
「アサート実行数」ダイアログが表示されます。

b. 「アクティビティ名」フィールドで、「参照」アイコンをクリックして実行するアクティビティを選択します。

または

a. デザイナで特定のBPELアクティビティを右クリックし、「アクティビティ・テスト・データの編集」を選択します。

b. 「アサート実行数」タブをクリックします。

c. 「追加」アイコンをクリックします。
選択したアクティビティが「アクティビティ名」フィールドに表示されます。

2. 「カウント」リストで値を選択します。

3. 「OK」をクリックします。
「アクティビティ・テスト・データ」ダイアログは、図50-27 のようになります。

図50-27 「アクティビティ・テスト・データ」ダイアログ

4. 「構造」ウィンドウで「アサート実行数」フォルダを展開し、アクティビティに割り当てた実行数を表示します。図50-28に詳細を示します。

図50-28 「構造」ウィンドウの「アサート実行数」フォルダ

50.6 テスト・スイートのデプロイおよび実行

テスト・ケースのテスト・スイートを作成した後は、そのスイートをSOAコンポジット・アプリケーションの一部としてデプロイします。その後、Oracle JDeveloper、Oracle Enterprise Manager Fusion Middleware Control、Oracle WebLogic Scripting Tool (WLST)スクリプト、またはantコマンドからテスト・スイートを実行できます。

50.6.1 Oracle JDeveloperからテスト・スイートをデプロイして実行する方法

Oracle JDeveloperからテスト・スイートを実行できます。テスト・スイートを作成した後、実行する複数のテスト・スイート、実行する個々のテスト・スイートまたは実行するテスト・スイート内の個々のテストを選択できます。

Oracle JDeveloperからテスト・スイートをデプロイして実行する手順は、次のとおりです。

1. 表50-15 に示す、該当するタスクを実行します。

表50-15 テスト・スイートの実行オプション

用途

「アプリケーション」ウィンドウで

SOAコンポジット・エディタ内で現在テスト・モードで開いているテスト・スイートを実行する。

a. SOAコンポジット・エディタ上部にある「テストの実行」アイコンをクリックします。

すべてのテスト・スイートを実行する。

a. testsuitesフォルダを右クリックして、「スイート・テストの実行」を選択します。

個々のテスト・スイートを実行する。

a. テスト・スイート名を右クリックして、「スイート・テストの実行」を選択します。

テスト・スイート内の個々のテストを実行する。

a. testsフォルダ内の個々のテストを右クリックして、「テストの実行」を選択します。

使用するテスト・サーバーを構成していない場合は、「テスト・サーバーの指定」ダイアログが表示されます。

2. テスト・サーバー・ホスト名を入力し、必要に応じて「今後は確認せず、「ツール」->「プリファレンス」->「SOA」で保存します」チェック・ボックスを選択します。これを選択すると、「ツール」→「プリファレンス」→「SOA」に進んで構成を変更するまで、このダイアログが再び表示されなくなります。

3. 「OK」をクリックします。
「テスト実行」ダイアログが表示されます。

4. 次の手順を実行します。

a. テスト実行名を指定します。

b. 実行するテストを選択または選択解除します。

c. テスト・サーバー上でテストを実行する際のタイムアウト値を秒数で指定します。

d. 「OK」をクリックします。

図50-29に詳細を示します。

図50-29 「テスト実行」ダイアログ

SOAコンポジット・アプリケーション(テストを含む)がテスト・サーバーにデプロイされているかどうかのチェックが行われます。テスト・サーバー上でテストを実行する前に、コンポジットをまずデプロイする必要があります。

5. SOAコンポジット・アプリケーションのデプロイメント状況に応じて、表50-16 に示す手順を実行します。

表50-16 SOAコンポジット・アプリケーションがデプロイ済かどうか判別するためのチェック

SOAコンポジット・アプリケーションの状況

結果

デプロイされている。

ステップ6に進みます。

- テスト・サーバー上にまだデプロイされていない。

- テスト・サーバー上にはデプロイされたが、コンポジット(テストを含む)が前回のデプロイメント以後に変更された。

「コンポジットのデプロイの確認」ダイアログが表示されます。

a. 「OK」をクリックしてSOAコンポジット・アプリケーションをデプロイします。
「Project_Nameのデプロイ」ウィザードの「デプロイメント・アクション」ページが表示されます。

b. 「アプリケーション・サーバーにデプロイ」を選択します。

c. ウィザードの各ページの指示に従って、SOAコンポジット・アプリケーションをアプリケーション・サーバーにデプロイします。
SOAコンポジット・アプリケーションのデプロイの詳細は、「プロファイルのデプロイ」を参照してください。

d. デプロイメントが完了したら、ステップ6に進みます。

デプロイメントが完了したら、テストがテスト・サーバー上で実行されます。

6. テスト結果を表示します。図50-30に詳細を示します。「テスト結果」ダイアログは、テスト・サーバーおよびコンポジットDNごとに表示されます。テスト・サーバーURL (SOAサーバーのホスト名とポート番号)およびコンポジットDNが右上隅に表示されて、コンテキストを示します。テストは必要な回数だけ実行でき、同じテスト・サーバーまたは異なるテスト・サーバー上で、異なるテストの組合せを選択して実行できます。

図50-30 「テスト結果」ダイアログ

テスト結果は、3つの折りたたみ可能なテーブル(マスターから詳細まで)に表示されます。表50-17に詳細を示します。

表50-17 「テスト結果」テーブル

テスト実行

テスト・ケース

アサート結果

テスト実行の発行直後の場合、現在のテスト実行とそのステータスのサマリーが表示されます。テスト実行についてテスト・サーバーに問い合せた直後の場合、問合せ基準に一致するすべてのテスト実行がテーブルに表示されます。

- 「テスト実行」ダイアログに入力したテスト実行の名前。

- テスト実行のステータス(成功または失敗)。テスト実行内のすべてのテスト・ケースが成功した場合は、ステータスは成功になります。そうでなければステータスは失敗になり、これは少なくとも1つのテスト・ケースが失敗したことを示しています。

- テスト実行の成功率。

- テスト・ケースの総数。

- 成功、失敗、エラー、および実行中のテスト・ケースの数。

- テスト実行の開始時刻と終了時刻。

「テスト実行」テーブルから選択したテスト実行のすべてのテスト・ケース、およびステータスを表示します。「リフレッシュ」ボタンをクリックすると、テスト・ケースのステータスがリフレッシュされます。

- テスト・ケースのテスト・ファイル名。クリックするとテスト・エディタにアクセスします。

- テスト・ケースのステータス(成功または失敗)。テスト・ケース内のすべてのアサーションが成功した場合、ステータスは成功です。そうでなければステータスは失敗になり、これは少なくとも1つのアサーションが失敗したことを示しています。

- テスト・ケースのテスト・スイート。

「テスト・ケース」テーブルから選択したテスト・ケースのアサーション結果がすべて表示されます。

- アサーションの場所。これは、ワイヤ・アサートの場合はワイヤ・ソース(サービスまたは参照)、コンポーネント・アサートの場合はコンポーネント(BPELプロセス)アクティビティ名です。これは、テスト・エディタ内でのアサートの場所を示すハイパーリンクです。図50-31に詳細を示します。

- アサーションのステータス(成功または失敗)。実際値が予想値と一致する場合は、ステータスは成功になります。

- アサートの予想値と実際値。これは、単純値アサートの場合は単純値、XML値アサートの場合はXML値を表示するポップアップのハイパーリンクです。

- ステータスが失敗の場合、エラー・メッセージです。

- アサーション・タイプ(ワイヤまたはコンポーネント)。ワイヤとは、コンポジット・ワイヤに対するアサートを意味します。コンポーネントとは、コンポーネント内でのアサートを意味します(BPELプロセス)。

- 作成時にアサーションに対して入力したアサーションの説明。

図50-31 アサーションXML結果

7. 図50-30 の「テスト実行」テーブルで、次の追加作業を実行します。

a. 「テスト実行」テーブルの上にある「検索」アイコンをクリックし、検索基準を指定することによって、テスト・サーバーにテスト実行について問い合せます。

b. 「テスト実行」テーブルの上にある「リフレッシュ」アイコンをクリックして、テスト実行のステータスをリフレッシュします。

8. 図50-30 の「テスト・ケース」テーブルで、次の追加作業を実行します。

a. 「テスト・ケース」テーブルの上にある「リフレッシュ」アイコンをクリックして、テスト・ケースのステータスをリフレッシュします。

9. 図50-30 の「アサート結果」テーブルで、次の追加作業を実行します。

a. 「アサート結果」表の上にある「失敗のみを表示」チェック・ボックスを選択して、失敗したアサートのみを表示します。

50.6.2 Oracle Enterprise Manager Fusion Middleware Controlからテスト・スイートをデプロイして実行する方法

SOAコンポジット・アプリケーションのデプロイ、およびOracle Enterprise Manager Fusion Middleware Controlからのテスト・スイートの実行の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

50.6.3 WLSTコマンドを使用してテスト・スイートをデプロイして実行する方法

sca_test WLSTコマンドを使用したテスト・スイートの実行の詳細は、SOA Suite用WLSTコマンド・リファレンスのsca_testに関する項を参照してください。

50.6.4 antスクリプトを使用してテスト・スイートをデプロイして実行する方法

ant-sca-test.xmlのantスクリプトを使用したテスト・スイートの実行の詳細は、「SOAコンポジット・アプリケーションのテストを自動化するためのantの使用方法」を参照してください。

第IX部 高度なトピック

この部では、高度なトピックについて説明します。

この部は、次の章で構成されています。

- 大規模ドキュメントおよび多数のインスタンスの管理

- SOAコンポジット・アプリケーションのカスタマイズ

- コンポジット・センサーの定義

- 動的ビジネス・プロセスの作成

- Spring Frameworkを使用したSOAコンポジット・アプリケーションへの統合

51 大規模ドキュメントおよび多数のインスタンスの管理

この章では、Oracle SOA Suiteで大規模ドキュメントとメタデータを管理する場合、および多数のインスタンスがある環境を管理する場合のベスト・プラクティスについて説明します。また、大規模ドキュメントの処理のユースケース、大規模ドキュメントの同時処理に関する制限およびチューニングに関する推奨事項についても説明します。

この章の内容は次のとおりです。

- 大規模ドキュメントを処理する場合のベスト・プラクティス

- 大規模メタデータを処理する場合のベスト・プラクティス

- 多数のインスタンスを処理する場合のベスト・プラクティス

Oracle SOA Suiteのチューニングとパフォーマンスの詳細は、『パフォーマンスのチューニング』を参照してください。

Oracle SOA Suiteの問題のトラブルシューティングの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「Oracle SOA SuiteおよびOracle BPM Suiteのトラブルシューティング」を参照してください。

大量のデータを迅速に移動し、複雑なデータ変換を処理するOracle Data Integratorの使用については、次のURLにアクセスしてください。

http://www.oracle.com/technetwork/middleware/data-integrator

51.1 大規模ドキュメントを処理する場合のベスト・プラクティス

この項では、大規模ドキュメントを処理する次のシナリオについて説明し、各シナリオに対するベスト・プラクティスなアプローチを示します。大規模なペイロードを開発および実行する前に、これらのベスト・プラクティスに従うことをお薦めします。

51.1.1 大規模ドキュメントを処理する場合のユースケース

この項では、大規模ドキュメントを処理する場合のユースケースについて説明します。

51.1.1.1 XMLペイロードへのバイナリ・オブジェクトのBase64エンコード・テキストとしての受け渡し

この項では、バイナリ・オブジェクトをBase64エンコード・テキストとしてXMLペイロードに渡す場合のユースケースについて説明します。

51.1.1.1.1 SOAPインライン

このユースケースでは、バイナリ・アタッチメント(画像など)がテキストとしてBase64でエンコードされ、インラインでXML文書に渡されます。表51-1に詳細を示します。

表51-1 機能

機能

説明

セキュリティ

サポートされています。

フィルタ/トランスフォーメーション/割当て

トランスフォーメーションを使用すると、パフォーマンスの低下またはメモリー不足のエラー(あるいはその両方)につながる場合があります。

ファンアウト

サポートされています。

バインディング

WSバインディングが、バイナリ・アタッチメントをドキュメント・オブジェクト・モデル(DOM)として送信します。

Oracle BPEL Process Manager/Oracle Mediator

BPELプロセスでJavaのexecを使用してデコードできます。

51.1.1.1.2 SOAP MTOM

このユースケースでは、バイナリ・アタッチメント(画像など)がテキストとしてBase64でエンコードされ、MTOM(メッセージ転送最適化メカニズム)ドキュメントとして渡されます。表51-2に詳細を示します。

表51-2 機能

機能

説明

セキュリティ

サポートされています。

フィルタ/トランスフォーメーション/割当て

assignアクティビティはサポート対象です。

ファンアウト

サポートされています。

バインディング

WSバインディングが、MTOMとして送信されるアタッチメントをマテリアライズし、Base64エンコード形式で内部に配置します(ストリーミングはサポートされていません)。

Oracle BPEL Process Manager/Oracle Mediator

追加作業は不要です。

51.1.1.1.3 ファイル/FTPアダプタによって渡される不透明(Opaque)コンテンツ

このユースケースでは、バイナリ・アタッチメント(画像など)がテキストとしてBase64でエンコードされ、インラインでXML文書に渡されます。表51-3に詳細を示します。

表51-3 機能

機能

説明

セキュリティ

サポートされていません。

フィルタ/トランスフォーメーション/割当て

パス・スルー。

ファンアウト

サポートされています。

バインディング

アダプタがBase64形式にエンコードします。

Oracle BPEL Process Manager/Oracle Mediator

サポートされています。不透明(Opaque)コンテンツは、assignアクティビティまたはtransformアクティビティでは操作できません。

51.1.1.1.4 Oracle B2Bによって渡される不透明(Opaque)コンテンツ

このユースケースでは、バイナリ・アタッチメント(画像など)がエンコード・テキストとしてBase64でエンコードされます。表51-4に詳細を示します。

表51-4 機能

機能

説明

セキュリティ

サポートされていません。

フィルタ/トランスフォーメーション/割当て

パス・スルー。

ファンアウト

サポートされています。

Oracle B2B

Oracle B2Bは、ネイティブ・ペイロードをBase64形式にエンコードします。このシナリオの場合は、Oracle B2Bバインディングのドキュメント定義の処理が不透明になるように構成する必要があります。

51.1.1.2 アタッチメントのエンドツーエンドのストリーミング

この項では、アタッチメントをエンドツーエンドでストリーミングする場合のユースケースについて説明します。

注意:

Direct Internet Message Encapsulation (DIME)アタッチメントはサポートされていません。

51.1.1.2.1 アタッチメント付きのSOAP

このユースケースでは、バイナリ・アタッチメント(画像など)がストリームとしてエンドツーエンドで渡されます。表51-5に詳細を示します。

表51-5 機能

機能

説明

セキュリティ

サポートされていません。

フィルタ/トランスフォーメーション/割当て

パス・スルー。Oracle BPEL Process ManagerでXPath拡張関数を使用する必要があります。

バインディング

WSバインディングが、SOAPアタッチメントに対するストリーム・イテレータを作成します。

Oracle BPEL Process Manager/Oracle Mediator

Oracle Mediatorは、マテリアライズなしのパス・スルーを実行できます。Oracle BPEL Process Managerはアタッチメントを保持します。

チューニング

Oracle BPEL Process Managerで使用する場合は、データベース表領域を管理します。

アタッチメント付きSOAPの定義用のWSDLコード

<mime:part>
<mime:content part="bin" type=“image/jpeg"/>
</mime:part>

注意:

- アタッチメントをWebサービスのコールバック・レスポンスの一部としてストリームすることはできません。

- Springサービス・コンポーネントでは、MIMEアタッチメントの処理がサポートされていません。サポートされるのは、MTOMアタッチメントのみです。

- 直接バインディング、Webサービスなどの様々なバインディング・コンポーネントを使用すると、大規模アタッチメントを処理できます。ただし、直接バインディングを使用した大規模アタッチメントの処理はメモリー不足のエラーにつながるため、お薦めできません。

51.1.1.2.2 ストリーミング・アタッチメントの使用

Oracle Fusion MiddlewareのWebサービスでは、大規模アタッチメントをストリームとして渡すことができます。アタッチメント全体がメモリー内にある場合と同様にアタッチメントを処理するJAX-RPCのAPIとは異なり、ストリームではプログラミング・モデルをより効率的に使用します。また、ストリームを使用すると、サービスの実行前にアタッチメントをメモリーにロードする必要がないため、パフォーマンスおよびスケーラビリティが向上します。

ストリーム・アタッチメントは、埋込みアタッチメントと同様に、MIMEマルチパートのバイナリ形式に準拠しています。埋込みアタッチメントとは、インラインまたはエンコードのアタッチメントを指します。

ワイヤ上では、ストリーム・アタッチメント付きのメッセージはアタッチメント付きの他のSOAPメッセージと同じです。

次の例に、ストリーム添付ファイル付きのサンプル・メッセージを示します。メッセージの最初のパートはSOAPエンベロープ(<SOAP-ENV:Envelope...)です。2番目のパートがアタッチメント(この例ではmyImage.gif)です。

MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
Content-Description: This is the optional message description.

--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: NotSure/DoesntMatter

<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
. . .
<DocumentName>MyImage.gif</DocumentName>
. . .
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-ID: AnythingYoudLike

...binary GIF image...
--MIME_boundary--

51.1.1.2.3 MIMEアタッチメントを使用するコンポジットの作成

次の手順を実行して、MIMEアタッチメントを使用するコンポジットを作成します。

MIMEアタッチメントを使用するコンポジットの作成

1. ペイロード・スキーマを使用してコンポジット(たとえば、Oracle Mediatorを介してアウトバウンドWebサービスに接続するインバウンドWebサービス)を作成します。

2. Oracle MediatorのWSDLファイル内で、次の手順を実行します。

a. WSDLデザイナから、Oracle MediatorのWSDLファイルを開きます。

b. バインディングを中央のスイムレーンにドラッグ・アンド・ドロップします。

c. RPCバインディングを選択します。

d. 名前を入力します。

e. WSDLの「ソース」ビューに移動し、MIMEマルチパートを使用してWSDLの入力と出力を変更します。

<wsdl:input>
<mime:multipartRelated>
<mime:part>
<soap:body parts="payload" use="literal"/>
</mime:part>
<mime:part>
<mime:content part="bin" type="application/octet-stream"/>
</mime:part>
</mime:multipartRelated>
</wsdl:input>

f. リクエスト/レスポンス・メッセージのMIMEパートを追加します。

<wsdl:message name="BPELProcess1RequestMessage">
<wsdl:part name="payload" element="ns1:purchaseOrder" />
<!--add below part-->
<wsdl:part name="bin" type="xsd:base64Binary"/>
</wsdl:message>

g. WSDL定義にネームスペースを追加します。

xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/">

完了すると、MIMEアタッチメントを参照するWSDLが表示されます。

<wsdl:definitions
name="PhotoCatalogService"
targetNamespace="http://examples.com/PhotoCatalog"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:types="http://examples.com/PhotoCatalog/types"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tns="http://examples.com/PhotoCatalog">
<wsdl:message name="addPhotoRequest">
<wsdl:part name="photo" type="xsd:hexBinary"/>
</wsdl:message>
<wsdl:message name="addPhotoResponse">
<wsdl:part name="status" type="xsd:string"/>
</wsdl:message>
<wsdl:message name="replacePhotoRequest">
<wsdl:part name="oldPhoto" type="xsd:string"/>
<wsdl:part name="newPhoto" type="xsd:hexBinary"/>
</wsdl:message>
<wsdl:message name="replacePhotoResponse">
<wsdl:part name="status" type="xsd:string"/>
</wsdl:message>
<wsdl:portType name="PhotoCatalog">
<wsdl:operation name="addPhoto">
<wsdl:input message="tns:addPhotoRequest"/>
<wsdl:output message="tns:addPhotoResponse"/>
</wsdl:operation>
<wsdl:operation name="replacePhoto">
<wsdl:input message="tns:replacePhotoRequest"/>
<wsdl:output message="tns:replacePhotoResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="PhotoCatalogBinding" type="tns:PhotoCatalog">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="addPhoto">
<wsdl:input>
<mime:multipartRelated>
<mime:part>
<soap:body use="literal"/>
</mime:part>
<mime:part>
<mime:content part="photo"
type="image/jpeg"/>
</mime:part>
</mime:multipartRelated>
</wsdl:input>
<wsdl:output>
<mime:multipartRelated>
<mime:part>
<soap:body use="literal"/>
</mime:part>
<mime:part>
<mime:content part="status" type="text/plain"/>
<mime:content part="status" type="text/xml"/>
</mime:part>
</mime:multipartRelated>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="replacePhoto">
<wsdl:input>
<mime:multipartRelated>
<mime:part>
<soap:body parts="oldPhoto" use="literal"/>
</mime:part>
<mime:part>
<mime:content part="newPhoto"
type="image/jpeg"/>
</mime:part>
</mime:multipartRelated>
</wsdl:input>
<wsdl:output>
<soap:body parts="status" use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>

51.1.1.2.4 パフォーマンス・オーバーヘッドとパス・スルー・アタッチメント

Oracle Mediatorはステートレスであるため、パス・スルー・アタッチメントに関するパフォーマンス・オーバーヘッドはありません。ただし、Oracle BPEL Process Managerでは、アタッチメントをデハイドレーション(圧縮して格納)するため、パス・スルー・アタッチメントの場合でもパフォーマンス・オーバーヘッドがあります。Oracle BPEL Process Managerでアタッチメントを一定の期間使用すると、SOAインフラストラクチャ・スキーマが最大サイズまで増加し、メモリーの問題が発生する可能性があります。大規模アタッチメントに対応するために、SOAインフラストラクチャ・スキーマに対するデータベース表領域を適切に拡張することをお薦めします。同時に、purgeスクリプトを使用して、表の添付ファイルとともに完了インスタンスをパージすることもできます。

パージ・スクリプトの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

表領域の拡張の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の表領域の拡張による実行時の問題の回避に関する項を参照してください。

同じコンポジット内の1番目のBPELプロセスが2番目のBPELプロセスをコールするシナリオでは、2番目のBPELプロセスは同じアタッチメントを再度デハイドレーションしません。

コンポジット1の1番目のBPELプロセスがコンポジット2の2番目のBPELプロセスを起動し、最適化が無効化されているシナリオでは、コンポジット1がコンポジット2へのSOAPコールを実行します。2番目のBPELプロセスがアタッチメントをデハイドレーションします。

51.1.1.2.5 アタッチメントをストリーミングするためのプロパティ

アタッチメントをストリームするには、composite.xmlファイルに次のプロパティを追加します。最適化が有効化されている場合は、SOAPコールのかわりにネイティブ・コールが使用されます。次の例に詳細を示します。

<binding.ws
port="http://services.otn.com#wsdl.endpoint(MIMEService/MIMEService)"
xmlns:ns="http://xmlns.oracle.com/sca/1.0"
streamIncomingAttachments="true" streamOutgoingAttachments="true">
<!--Add this prop to reference bindings to make a SOAP call. -->
<property name="oracle.webservices.local.optimization">false</property>
</binding.ws>

oracle.webservices.local.optimizationプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のコンポジット間呼出しでのポリシー・アタッチメントおよびローカルの最適化に関する項およびローカルの最適化の構成に関する項を参照してください。

注意:

Oracle Web Services Manager (OWSM)では、ストリームのアタッチメントに関するポリシーの確認や実施は行いません。OWSMの詳細は、『Webサービスの管理』を参照してください。

51.1.1.2.6 SOA Webサービスのバインディング・レイヤーからのストリーミング・アタッチメント

SOA Webサービス(WS)のバインディング・レイヤーからのアタッチメントをストリーミングすると、次の例に示すエラーが発生する可能性があります。

java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2271)
at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
at
java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
at
java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
at

このエラーを解決するには、次のプロパティをcomposite.xmlファイルのサービス・コンポーネントおよび参照バインディング・コンポーネントに追加します。

- streamIncomingAttachments="true"

- streamOutgoingAttachments="true"

これらのプロパティの設定の詳細は、前の項を参照してください。

51.1.1.2.7 SOAPアタッチメントのコンテンツの読取りおよびエンコード

BPELプロセスでは、ora:getAttachmentContent関数がSOAPアタッチメントのコンテンツを読み取り、そのデータをBase64形式でエンコードします。そのためには、BPEL変数をSOAPアタッチメントのhrefを指定する引数として指定します。次の例は、この関数の使用方法を示しています。

<copy>
<from expression="ora:getAttachmentContent('input','bin')"/>
<to variable="initiateTaskInput" part="payload"
query="/taskservice:initiateTask/task:task/task:attachment/task:content"/>
</copy>

前の例では、"input/bin"変数にhrefが格納された添付コンテンツを、Base64でエンコードされた形式のcontent変数にコピーしています。

51.1.1.2.8 アタッチメント・ストリームの送信

Oracle BPEL Process Managerでは、複数のレシーバへのアタッチメント・ストリームの送信がサポートされています。Oracle BPEL Process Managerで複数のレシーバにストリームを送信する場合は、readBinaryFromFile XPath関数を使用してデータベースからアタッチメント・ストリームを読み取り、そのストリームを適切なターゲットに渡す必要があります。

デフォルトの構成では、Oracle Mediatorはアタッチメント・ストリームを1つのターゲット・レシーバにのみ渡すことができ、これは別のコンポーネントやWebサービス/アダプタの場合があります。2番目のターゲットはアタッチメントを受信できません。Oracle Mediatorコンポーネントに対してpersistStreamAttachmentプロパティを定義した場合、Oracle Mediatorではアタッチメント・ストリームを複数のターゲット・レシーバに渡すことができます。

Oracle Mediatorでは、アタッチメントが含まれているソース・メッセージが複数のターゲット・レシーバによって共有されている場合、ストリーミング・アタッチメントにpersistStreamAttachmentプロパティが必要です。複数のターゲットに対するアタッチメントのストリーミングを有効にするには、composite.xmlでこのプロパティをtrueに設定します。次の例に詳細を示します。

component name="Mediator1">
<implementation.mediator src="Mediator1.mplan"/>
<property name="persistStreamAttachment">true</property>
</component>

51.1.1.2.9 Oracle Mediatorでのアタッチメントのパス・スルー設定のオーバーライド

Oracle Mediatorでは、パス・スルーの(つまり、トランスフォーメーションや割当てのルールが含まれない) Oracle Mediatorコンポーネントのアタッチメントはターゲット・レシーバに自動的に伝播されますが、パス・スルーでないOracle Mediatorコンポーネントのアタッチメントは伝播されません。passThroughAttachmentプロパティを使用して、アタッチメント専用のパス・スルー設定をオーバーライドできます。このプロパティをtrueに設定すると、すべてのアタッチメントがターゲット・レシーバに暗黙的にコピーされます。

パス・スルーでないOracle Mediatorコンポーネントの場合は、このプロパティを使用してアタッチメントを伝播し、パス・スルーのOracle Mediatorコンポーネントの場合は、このプロパティを使用してアタッチメントをブロックします。パス・スルー・アタッチメントのオーバーライドを実装するには、このプロパティをプロジェクトのcomposite.xmlファイルのOracle Mediatorコンポーネントに対応するcomponent要素に追加します。パス・スルーでないOracle Mediatorコンポーネントをオーバーライドするには、プロパティをtrueに設定します。パス・スルー・コンポーネントをオーバーライドするには、falseに設定します。次の例に詳細を示します。

<component name="Mediator">
<implementation.mediator src="Mediator.mplan"/>
<property name="passThroughAttachment">true</property>
</component>

51.1.1.2.10 同期フローを使用したアタッチメントの共有

Oracle BPEL Process Managerベースのコンポジットで同期フローを使用してアタッチメントを共有する場合は、同じエンドツーエンドのトランザクションを使用する必要があります。これは、コロケートされ、ローカル・コールまたは最適化されたコールを使用するコンポジットに適用できます。これを実行するには、コール・チェーンでコールされるすべてのBPELコンポーネント(コール先)に、次の例に示すプロパティを設定します。

<property name="bpel.config.transaction" many="false"
type="xs:string">required</property>

このようなコンポジットが同じトランザクション・コンテキストの一部として実行されない場合、コール・チェーンの最初のBPELコンポーネントで保存されたアタッチメント・データはコール・チェーンの他のBPELコンポーネントに表示されません。さらに、そのコンポジットではデータベースがロックされ、次のタイムアウト例外が発生します。

"ORA-02049: timeout: distributed transaction waiting for lock"

51.1.1.2.11 ファイル/FTPアダプタのアタッチメント・オプション

このユースケースでは、アダプタがバイナリ・データをデータベース・ストアにストリームし、サービス・エンジン(Oracle BPEL Process ManagerまたはOracle Mediator)にhrefを公開します。表51-6に詳細を示します。

表51-6 機能

機能

説明

セキュリティ

なし。

フィルタ/トランスフォーメーション/割当て

アタッチメントのフィルタおよびトランスフォーメーションはサポートされていません。

ファンアウト

サポートされています。

バインディング

アダプタが非XMLをデータベースにバイナリ・ラージ・オブジェクト(BLOB)としてストリームし、そのキーをサービス・エンジンに渡します。

Oracle BPEL Process Manager/Oracle Mediator

サポートされています。

チューニング

- Oracle SOA Suiteスキーマのデータベース表領域を拡張します。

- メッセージ処理の完了後にアタッチメントを削除します。

ドキュメント

『テクノロジ・アダプタの理解』を参照してください。

アウトバウンド・ファイル・アダプタを使用したアタッチメントの書込み

次の例は、ファイル・アダプタを使用してアタッチメントをディスクに書き込むことができるサンプル・スキーマを示しています。

<?xml version="1.0" encoding="windows-1252" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://xmlns.oracle.com/attachment"
targetNamespace="http://xmlns.oracle.com/attachment"
elementFormDefault="qualified">
<xsd:element name="attach">
<xsd:complexType>
<xsd:attribute name="href" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>

フローでOracle Mediatorを使用する場合は、Oracle Mediatorのassignを使用して、ソース(Oracle Mediator)のアタッチメント・パートをターゲット(ファイル・アダプタ)にマップします。

Oracle BPEL Process Managerを使用すると、アタッチメントがデハイドレーション・ストアに書き込まれ、処理速度が低下します。

ora:doStreamingTranslate XPath関数を使用したアタッチメントの変換

ora:doStreamingTranslate XPath関数の使用は、Oracle BPEL Process ManagerまたはOracle Mediatorサービス・コンポーネント内でアタッチメントを変換する場合にのみお薦めします。この関数は、アタッチメントの場所がサーバー上の相対パスで指定されることを想定しています。また、受信アタッチメント・ストリームを変換できません。

この関数の詳細は、「doStreamingTranslate」を参照してください。

51.1.1.2.12 Oracle B2Bアタッチメント

このユースケースでは、Oracle B2Bがバイナリ・データをデータベースに格納し、Oracle B2B定義のXSDに基づいてサービス・エンジン(Oracle BPEL Process ManagerまたはOracle Mediator)にhrefを公開します。Oracle B2Bプロトコルがアタッチメントを定義します。表51-7に詳細を示します。

表51-7 機能

機能

説明

セキュリティ

なし。

フィルタ/トランスフォーメーション/割当て

アタッチメントのフィルタおよびトランスフォーメーションはサポートされていません。

ファンアウト

サポートされています。

バインディング

Oracle B2Bが、アタッチメントをhrefキーとしてサービス・エンジンに渡します。

チューニング

Oracle SOA Suiteスキーマのデータベース表領域を拡張します。

51.1.1.3 SOAコンポジット・アプリケーションとのMTOM最適化メッセージの送受信

SOAコンポジット・アプリケーションでは、MTOM (MIMEバイナリ)最適化メッセージを送受信するように、サービスおよび参照のバインディング・コンポーネントにOracle WS-MTOMポリシーを添付する必要があります。Oracle WS-MTOMポリシーにサービス・バインディング・コンポーネント(composite.xmlファイル内のbinding.wsの下に定義)が構成されている場合は、Oracle SOA SuiteのMTOMメッセージ処理機能が使用されます。Oracle WS-MTOMポリシーに参照バインディング・コンポーネント(これもcomposite.xmlファイル内のbinding.wsの下に定義)が構成されている場合は、Oracle SOA SuiteはMTOM最適化メッセージを送信します。

MTOMアタッチメントについては、次の点に注意してください。

- 添付をインラインにエンコードしている場合は、ファイルへの添付の書込みにファイル・アダプタを使用しないことをお薦めします。

- デフォルトのmtomThreshold値は1024バイトで、変更できません。添付が1024バイト未満の場合、アウトバウンド構成については、Oracle SOA Suiteは添付をインライン添付として送信します。サイズが1024バイトを超える場合は、添付はメッセージ内のhref属性のアタッチメント・パートとして送信され、ワイヤ上のWSDL定義形式として送信されます。ただし、(別のWebサービス・プロバイダからなどの)着信リクエストに小さいバイナリ・データ(サイズが1024バイト未満)のxop hrefノードがある場合、Oracle SOA Suiteは、フロー・トレースでペイロード内の同じhref属性を使用します。次に例を示します。

<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"
href="cid:e29caf23dc8045908451fdfaafa26dce" />

- コンポジットのサービス・バインディング・コンポーネントにOracle WS-MTOMポリシー参照が含まれていない場合は、サービスで非MTOMメッセージが受入れ可能であることを示します。これは、コール元のコンポジット(該当する参照バインディング)にOracle WS-MTOMポリシー参照がなく、そのサービスに非MTOMメッセージを送信可能であることを示します。

- 添付のMTOMストリーミングはOracle SOA Suiteではサポートされません。

- MTOMアタッチメントは、Webサービス・バインディングでのみサポートされています。他のバインド(HTTPバインディングなど)はサポートされません。

- Oracle Mediatorパス・スルー・シナリオがサポートされます。Oracle Mediatorにトランスフォーメーション文も割当て文も含まれていない場合、これはパス・スルーOracle Mediatorと呼ばれます。受信したメッセージと添付は、ペイロードと添付を変更せずにターゲットに伝播されます。同じメッセージ内の複数のMTOMアタッチメントも同様にOracle SOA Suiteで送受信されます。

- ストリーミングとMTOMメッセージ処理機能の両方を添付の送受信に使用しないことをお薦めします。ストリーミングまたはMTOMメッセージ処理機能のどちらかを使用してください。

注意:

入力がtext/xmlタイプの場合、MTOM形式でのファイル送信に大幅なファイル・サイズの減少はありません。

- ベスト・プラクティスとしては、バイナリ・データの伝播にXSLTマップ・エディタを使用しないことをお薦めします。かわりに、assignアクティビティを使用します。バイナリ・データの伝播にスタイルシートを使用する必要がある場合は、xsl:copy-ofによる方法(copy-ofにより属性を含むすべてをコピー)を使用するか、ソースからターゲットへ属性をコピーするカスタム関数を使用することをお薦めします。

- MTOMアタッチメントのサイズはGB単位にはできません。かわりに、大きいサイズの添付にはアタッチメント付きのSOAPストリーミング機能を使用します。詳細は、「アタッチメント付きのSOAP」を参照してください。

51.1.1.3.1 SwAおよびMTOM最適化アタッチメントをデータベースに格納するためのシナリオ

BPELプロセスを含むSOAコンポジット・アプリケーションがMTOM最適化SOAPメッセージを受信すると、そのMTOM最適化要素(<xop href="">が付いたもの)それぞれのアタッチメントのコンテンツがデハイドレーション・ストアに格納されます。同様に、1つ以上のアタッチメントとともにアタッチメント付きのSOAPメッセージ(SwA)メッセージを受信すると、各アタッチメントはデハイドレーション・ストアに格納されます。これらのアタッチメントは、データベース内でそれらを識別するhref属性を使用する参照によって、受け渡すことができます。実際に、このhref属性によって、これらのアタッチメント要素のテキスト・コンテンツのすべてが削除され、置換されます。MTOM最適化メッセージの場合、<xop>要素の受信href属性の同じ値が再使用されます。同様に、SwAの場合、アタッチメント要素のhref属性が再使用されます。

メッセージがBPELプロセス・サービス・エンジンに配信されるとき(受信メッセージがDLV_MESSAGE表に保存されるとき)に、アタッチメントはデハイドレーション・ストアに格納されます。したがって、それは、composite.xmlファイルでbpel.config.oneWayDeliveryPolicyがasync.persist (デフォルト値)に設定されている一方向および非同期BPELプロセスに対してのみ適用できます。

アタッチメントは、次のユース・ケースでは永続化されません。

- SOAPメッセージが、bpel.config.oneWayDeliveryPolicyをsyncまたはasync.cacheに設定した同期BPELプロセスまたは一方向/非同期BPELプロセスによって受信された場合。

- インライン・バイナリ・コンテンツ付きのSOAPリクエスト内のすべての要素のコンテンツが永続化されず、そのままで渡されます。(つまり、それらには子要素<xop:Include>はないが、子としてbase64エンコード文字列があります。)MTOM最適化メッセージは、インラインbase64データを持つ1つ以上の要素と、いずれかのレベルでXOPパッケージ化された1つ以上の要素の組合せにすることができます。

注意:

サービス・バインディング・コンポーネントがMTOM対応であっても、それが、自動的に、そのサービスがMTOM最適化メッセージを受信することを示すわけではありません。コール元のサービスまたはアプリケーションは、MTOM最適化メッセージが確実に受信されるようにするには、ワイヤを介してそのメッセージを送信する必要があります。MTOM対応バインディングは、通常の非MTOMメッセージも受信できます。したがって、それが受信したときに、サービスに着信したSOAPリクエストには、データベースに保存されない非最適化インライン・バイナリ・データ要素が含まれていることがあります。

MTOM最適化要素またはSwAアタッチメントのコンテンツの値が実行時にhref属性によって置換される場合でも、それらの設計時のWSDLが変更されることありません。Oracle JDeveloperでこれらの変更は表示されません。これらの要素タイプ定義が、hexBinary、base64Binaryなどから、href属性を持つ空のコンテンツの定義に変更されることはありません。

ただし、これは、ユーザーとって透過的です。たとえば、assignアクティビティを使用してそれらのコンテンツ全体をコピーすると、実行時にhref値がコピーされます。同様に、Webサービス、アダプタなどアウトバウンド参照を起動すると、Oracle SOA Suiteによってhref属性が実際のデータに自動的に解決され、起動が実行されます。

51.1.1.4 繰返しコンストラクトを使用した大規模XMLの処理

この項では、繰返しコンストラクトを使用して大規模XMLを処理する場合のユースケースについて説明します。

51.1.1.4.1 ファイル/FTPアダプタによるデバッチ

このユースケースでは、インバウンド・アダプタがソース・ドキュメントを複数のバッチのレコードに分割し、各バッチがコンポジット・インスタンスを起動します。表51-8に詳細を示します。

表51-8 機能

機能

説明

セキュリティ

なし。

フィルタ/トランスフォーメーション/割当て

サポートされています。

ファンアウト

サポートされています。

バインディング

ファイル/FTPアダプタが、ソース・ドキュメントをネイティブのXSD (NXSD)定義に基づいて小さいチャンクにデバッチします。

Oracle BPEL Process Manager/Oracle Mediator

サポートされています。

チューニング

ペイロード全体のサイズと比較して繰返し構造の方が小さいペイロードであるシナリオの場合は、繰返し構造に対してXSLTがサポートされます。assignアクティビティではシャドウ・コピーが実行されるため、assignアクティビティでの置換をお薦めします。

ドキュメント

『テクノロジ・アダプタの理解』を参照してください。

51.1.1.4.2 ファイル/FTPアダプタによるチャンク

このユースケースでは、BPELプロセス内のループが一度に1チャンクのレコードとプロセス(つまりカーソル)を読み取ります。表51-9に詳細を示します。

表51-9 機能

機能

説明

セキュリティ

サポートされています。

フィルタ/トランスフォーメーション/割当て

サポートされています。

ファンアウト

サポートされています。

Oracle BPEL Process Manager/Oracle Mediator

Oracle BPEL Process Managerでのみサポート対象。

ドキュメント

『テクノロジ・アダプタの理解』を参照してください。

51.1.1.5 複雑な構造の大規模XML文書の処理

この項では、複雑な構造の大規模XML文書を処理する場合のユースケースについて説明します。

51.1.1.5.1 ファイル/FTPアダプタによるストリーム

このユースケースでは、Oracle SOA Suiteを介して大規模XMLファイルをストリームします。表51-10に詳細を示します。

表51-10 機能

機能

説明

セキュリティ

なし。

フィルタ/トランスフォーメーション/割当て

サポート対象ですが、問題を回避するために最適化する必要があります。

ファンアウト

サポートされています。

バインディング

アダプタがペイロードをデータベースにSDOMとしてストリームし、そのキーをサービス・エンジンに渡します。

ドキュメント

『テクノロジ・アダプタの理解』を参照してください。

51.1.1.5.2 Oracle B2Bストリーム

このユースケースでは、大規模XMLファイルがSDOMとしてOracle B2BからOracle SOA Suiteに渡されます。これが実行されるのは、大規模ペイロード・サイズがOracle B2Bユーザー・インタフェースで定義されている場合のみです。表51-11に詳細を示します。

表51-11 機能

機能

説明

セキュリティ

なし。

フィルタ/トランスフォーメーション/割当て

サポート対象ですが、問題を回避するために最適化する必要があります。

ファンアウト

サポートされています。

バインディング

Oracle B2BがペイロードをデータベースにSDOMとしてストリームし、そのキーをサービス・エンジンに渡します。

Oracle BPEL Process Manager/Oracle Mediator

XPath拡張関数を使用してペイロードを操作できます。

51.1.2 大規模ドキュメントの同時処理に関する制限

この項では、大規模ドキュメントの同時処理に関する制限について説明します。

51.1.2.1 大規模ペイロードを処理するための不透明(Opaque)スキーマ

大規模なペイロードを処理するために不透明(Opaque)スキーマを使用する場合は、制限があります。不透明(Opaque)トランスレータのデータ全体が、単一のBase64エンコード文字列に変換されます。不透明(Opaque)スキーマは通常、比較的小さいデータに使用されます。大規模なデータの場合は、不透明(Opaque)トランスレータのかわりにアタッチメント機能を使用してください。

51.1.3 SOAコンポジット・アプリケーション用JVMメモリーのサイズ設定の推奨事項

サイズが100MB以上のペイロードでメッセージを送信する場合、適切にチューニングされていないとJVMヒープ・サイズの制限を超える場合があります。

たとえば、Oracle advanced queueing (AQ) JMSを使用してイベント配信ネットワーク(EDN)で大規模ペイロードを送信する場合、最初に標準的なメッセージ・ペイロード・サイズおよび可能性のある最大のメッセージ・サイズでテストして、最大メモリー値を設定してください。少ないメモリー値を使用することでORACLE.JMS.AQJMSEXCEPTIONエラーが発生する可能性があります。たとえば、100MBのペイロードの送信では、JTAタイムアウトおよび最大メモリーを5GBに変更することをお薦めします。

JVMヒープ・サイズのチューニングの詳細は、「チューニングに関する一般的な推奨事項」および『Oracle WebLogic Serverのパフォーマンスのチューニング』のJava HotSpot VMヒープ・サイズのオプションに関する項を参照してください。

51.1.4 チューニングに関する一般的な推奨事項

この項では、チューニングに関する一般的な推奨事項について説明します。

Oracle SOA Suiteのチューニングとパフォーマンスの詳細は、『パフォーマンスのチューニング』を参照してください。

51.1.4.1 一般的な推奨事項

この項では、チューニングに関する一般的な推奨事項について説明します。

- Oracle WebLogic Server管理コンソールで、JTAトランザクションのタイムアウトを500秒に増やします。手順は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の接続タイムアウトの解決に関する項を参照してください。

- Oracle Enterprise Manager Fusion Middleware Controlで、SOAコンポジット・アプリケーション・レベルの監査レベルを「オフ」または「本番」に設定します。詳細は、「大規模なペイロードの処理に対する監査レベルの設定」を参照してください。

- setDomainEnv.sh (Linux)またはsetDomainEnv.bat (Windows)のJAVA_OPTIONSで次の行を非コメント化して、サーバーを再起動します。この行が存在しない場合は追加します。この設定を行わないと、大規模ペイロード・シナリオは、デハイドレーション・データ・ソースに対してResourceDisabledExceptionエラーで失敗します。

-Dweblogic.resourcepool.max_test_wait_secs=30

- 次のように、setSOADomainEnv.shまたはsetDomainEnv.batのヒープのサイズを更新します。

DEFAULT_MEM_ARGS="-Xms1024m -Xmx2048m"

- 最適化されたトランスレーション機能(ora:doTranslateFromNative、ora:doTranslateToNative、ora:doStreamingTranslateなど)を使用します。この機能は大規模なペイロードのトランスフォーメーションおよびトランスレーション実行時に使用できます。
これらの関数の詳細は、「XPath拡張関数」を参照してください。

- 大規模アタッチメントを処理するためにデータ・ファイルを拡張します。詳細は、を参照してください。

- Oracle WebLogic Server管理コンソールでSocketException: Broken pipeエラーに対するHTTP POSTタイムアウトを増やします。「HTTP POSTタイムアウトを増やす」を参照してください

- 大規模ドキュメントの処理時にタイムアウト・エラーが発生した場合は、次のタスクを実行します。

- タイムアウト・プロパティ値を増やします。

- 「スタック・スレッド最大時間」プロパティ値を増やします。

詳細は、「タイムアウト値を増やす」を参照してください。

51.1.4.1.1 HTTP POSTタイムアウトを増やす

Oracle WebLogic Server管理コンソールでSocketException: Broken pipeエラーに対するHTTP POSTタイムアウトを増やします。

1. 「ドメイン構造」から、「soainfra」→「サーバー」→「server_name」→「プロトコル」→「HTTP」の順に選択します。

2. 「POSTタイムアウト」フィールドに、120 (最大)と入力します。

51.1.4.1.2 タイムアウト値を増やす

タイムアウト・プロパティ値は次のように増加します。

1. Oracle Web Services Manager管理コンソールにログインします。

2. 「デプロイメント」→「soa-infra」→「EJB」の順に移動します。

3. 次に示すBeanをそれぞれクリックし、「構成」を選択してタイムアウト値を増加します。

- BpelEngineBean

- BpelDeliveryBean

- CompositeMetaDataServiceBean

「スタック・スレッド最大時間」プロパティ値を増やす手順は、次のとおりです。

手順は、『Oracle WebLogic Serverのパフォーマンスのチューニング』の「WebLogic 8.1のスレッド・プール・モデルの使用」を参照してください。

51.1.4.2 大規模なペイロードの処理に対するOracle Enterprise Managerからの監査レベルの設定

大規模なペイロードを処理する際は、特定のコンポジットに対する監査レベルのロギングをオフにしてください。Oracle Enterprise Manager Fusion Middleware Controlで、コンポジットの監査レベルのオプションを「オフ」または「本番」に設定できます。コンポジットの監査レベルのオプションを「開発」に設定した場合は、大規模なペイロード全体がインメモリー文字列にシリアライズされ、メモリー不足のエラーが発生する可能性があります。

監査レベルの設定の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

51.1.4.3 Oracle BPEL Process ManagerおよびOracle Mediatorでのassignアクティビティの使用

Oracle BPEL Process ManagerまたはOracle Mediatorで、大規模なペイロードを操作するためにassignアクティビティを使用する場合は、メッセージ全体を割り当てないでください。かわりに、ペイロードの必要な部分のみを割り当ててください。

また、Oracle BPEL Process Managerでassignアクティビティを使用する場合は、可能なかぎりプロセス変数ではなくローカル変数を使用することをお薦めします。ローカル変数は、BPELプロセスのスコープ内に制限されます。これらの変数は、スコープを閉じた後はメモリーおよびデータベースから削除されます。ただし、グローバル変数のライフ・サイクルは、インスタンスのライフ・サイクルと関連付けられています。これらの変数は、インスタンスが完了するまで、メモリー内またはディスク内にとどまります。したがって、プロセス変数またはグローバル変数より、ローカル変数をお薦めします。

51.1.4.4 大規模ペイロード(Oracle BPEL Process Manager)でのXSLTトランスフォーメーションの使用

11gリリース1 11.1.1.3までは、Oracle BPEL Process ManagerでのXSLT操作は、結果のドキュメント全体がバイナリXML形式でメモリーにキャッシュされていました。これは、大規模ドキュメント処理の場合、メモリー不足エラーの原因となりました。11g リリース1 11.1.1.4からは、streamResultToTempFileプロパティが追加されました。このプロパティでは、XSLTの結果が一時ファイルにストリーミングされ、一時ファイルからロードされます。大規模ペイロードをXSLTを使用して処理する場合は、streamResultToTempFileをyesに設定します。デフォルト値はnoです。

このプロパティは、次のBPEL XPath関数を使用する場合に適用可能です。

- ora:processXSLT('template','input','properties'?)

- ora:doXSLTransformForDoc('template','input','name', 'value')

大きなXML文書をXSLTを使用して処理するよう構成する手順は、次のとおりです。

1. BPEL共通プロパティ・スキーマを作成します。次に例を示します。

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace ="http://schemas.oracle.com/service/bpel/common"
xmlns:common = "http://schemas.oracle.com/service/bpel/common"
xmlns:xs = "http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" blockDefault="#all">

<xs:element name="serviceProperties"  type="common:PropertiesType"/>
<xs:element name="anyProperties"  type="common:ArrayOfNameAnyTypePairType"/>
<xs:complexType name="NameValuePairType">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="value" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArrayOfNameValuePairType">
<xs:sequence>
<xs:element name="item" type="common:NameValuePairType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NameAnyTypePairType">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="value" type="xs:anyType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArrayOfNameAnyTypePairType">
<xs:sequence>
<xs:element name="item" type="common:NameAnyTypePairType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PropertiesType">
<xs:sequence>
<xs:element name="property" type="common:NameValuePairType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArrayOfAnyTypeType">
<xs:sequence>
<xs:element name="item" type="xs:anyType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

2. BPELプロセス内で、importセクションにネームスペースを追加します。

xmlns:common = "http://schemas.oracle.com/service/bpel/common"

3. グローバル変数を作成します(この例では、propertiesXMLVarという名前で作成):

<variable name="propertiesXMLVar" element="common:anyProperties"/>

4. streamResultToTempFileプロパティをyesに設定します。このassignアクティビティはXSLTトランスフォーメーションの実行前に存在している必要があります。

<assign name="Assign_xsltprop">
<copy>
<from>
<common:anyProperties>
<common:item>
<common:name>streamResultToTempFile</common:name>
<common:value>yes</common:value>
</common:item>
</common:anyProperties>
</from>
<to variable="propertiesXMLVar"/>
</copy>
</assign>

51.1.4.5 大規模ペイロード(Oracle Mediator)でのXSLTトランスフォーメーションの使用

11gリリース1 11.1.1.3までは、Oracle MediatorでのXSLT操作は、結果のドキュメント全体がバイナリXML形式でメモリーにキャッシュされていました。これは、大規模ドキュメント処理の場合、メモリー不足エラーの原因となりました。11g リリース1 11.1.1.4からは、streamResultToTempFileプロパティが追加されました。このプロパティでは、XSLTの結果が一時ファイルにストリーミングされ、一時ファイルからロードされます。大規模ペイロードをXSLTを使用して処理する場合は、streamResultToTempFileをyesに設定します。デフォルト値はnoです。

注意:

このプロパティは、大規模なペイロードを処理する場合にのみお薦めします。このプロパティを有効にすると、通常のペイロードのパフォーマンスが低下する可能性があります。

大きなXML文書をXSLTを使用して処理するよう構成する手順は、次のとおりです。

1. Oracle MediatorコンポーネントでOracle SOA Suiteプロジェクトを作成します。

2. 「ソース」ビューでプロジェクトのcomposite.xmlファイルを開きます。

3. composite.xmlファイルで、大規模なXMLドキュメントを処理するOracle Mediatorコンポーネントを定義するコンポーネント要素までスクロールし、streamResultToTempFileプロパティを追加します。次に示すように、プロパティをyesに設定します。

<component name="Mediator1">
<implementation.mediator src="Mediator1.mplan"/>
<property name="streamResultToTempFile">yes</property>
</component>

4. ファイルを保存して閉じます。

51.1.4.6 繰返し構造に対するXSLTトランスフォーメーションの使用

ペイロード全体と比較して繰返し構造の方がペイロードが小さい場合は、現在のXSLT実装ではDOM全体がメモリーにマテリアライズされるため、XSLTトランスフォーメーションの使用をお薦めします。たとえば、PurchaseOrder.LineItem.Supplier(大規模ペイロードの一部分)を使用します。

また、assignアクティビティではシャドウ・コピーが実行されるため、assignアクティビティを使用して置換することもできます。シャドウ・コピーではDOMはマテリアライズされませんが、ソース文書を指し示すシャドウ・ノードが作成されます。

また、大規模なペイロードのトランスフォーメーション/トランスレーション実行時に、次に示す最適化されたトランスレーション機能を使用することもできます。

- ora:doTranslateFromNativeまたはmed:doTranslateFromNative

- ora:doTranslateToNativeまたはmed:doTranslateToNative

- ora:doStreamingTranslateまたはmed:doStreamingTranslate

これらの関数の詳細は、「XPath拡張関数」および『テクノロジ・アダプタの理解』を参照してください。

51.1.4.7 Oracle B2Bでの大規模ドキュメントの処理

Oracle B2Bで大規模ドキュメントを処理する場合は、次のパラメータをチューニングします。

- mdsCache

- Cache Size

- Protocol Message Size

- Number of threads

- Stuck Thread Max Time

- Tablespace

- 大きなペイロード・サイズ

次の各項では、Oracle B2Bで大規模ドキュメントを処理する場合に設定する必要があるパラメータについて説明します。詳細は、『Oracle B2Bユーザーズ・ガイド』の大規模なペイロードを処理するためのドキュメント・ストリームの使用に関する項を参照してください。

51.1.4.7.1 MDSインスタンス・キャッシュ・サイズ

Oracle Metadata Services (MDS)リポジトリのインスタンス・キャッシュ・サイズを設定するには、Oracle Enterprise Manager Fusion Middleware Controlを使用します。このプロパティは、メタデータのサイズに依存します。メタデータまたはエンドポイントのカウントに基づいて値を指定します。デフォルト値は100000です。詳細は、『Oracle B2Bユーザーズ・ガイド』のFusion Middleware ControlでのB2B構成プロパティの設定に関する項を参照してください。

51.1.4.7.2 プロトコル・メッセージ・サイズ

Oracle B2Bで10MBを超えるメッセージを送受信する場合、またはインポート/エクスポート構成が10MBを超える場合は、Oracle WebLogic Server管理コンソールで次の設定を変更します。

プロトコル・メッセージ・サイズを構成する手順は、次のとおりです。

1. 「ドメイン構造」で、「環境」→「サーバー」の順に選択します。

2. 表の「名前」列で、「soa_server」を選択します。

3. 「プロトコル」タブを選択します。

4. 「最大メッセージ・サイズ」の値を変更します。

この設定は、$DOMAIN_HOME/config/config.xmlファイルで追加または変更することもできます。サーバー名構成の次で追加または変更します。次に例を示します。

<name>soa_server1</name>
<max-message-size>150000000</max-message-size>

注意:

デフォルトで、max-message-sizeはconfig.xmlファイルで使用可能ではありません。

51.1.4.7.3 スレッド数

このパラメータは、Oracle B2Bのメッセージ処理機能を向上させるため、Oracle Enterprise Manager Fusion Middleware Controlで設定する必要があります。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle B2Bサーバーのプロパティの構成に関する項を参照してください。

- b2b.inboundThreadCount

- b2b.inboundSleepTime

- b2b.outboundThreadCount

- b2b.outboundSleepTime

- b2b.defaultThreadCount

51.1.4.7.4 スタック・スレッド最大時間パラメータ

「スタック・スレッド最大時間」パラメータは、サーバーがスレッドをスタック状態であると判断するまでに、スレッドが継続的に動作している必要のある秒数をチェックします。Oracle WebLogic Server管理コンソールで次の設定を変更する必要があります。

スタック・スレッド最大時間パラメータを構成する手順は、次のとおりです。

1. 「ドメイン構造」で、「環境」→「サーバー」の順に選択します。

2. 表の「名前」列で、「soa_server」を選択します。

3. 「チューニング」タブを選択します。

4. 「スタック・スレッド最大時間」の値を変更します。

51.1.4.7.5 表領域

150MBを超える構成をデータ・ファイルに格納する必要がある場合は、次の例に示すように、データ・ファイルを拡張または追加して、表領域のサイズを増やす必要があります。

ALTER TABLESPACE sh_mds add DATAFILE 'sh_mds01.DBF' SIZE 100M autoextend on next
10M maxsize unlimited;
ALTER TABLESPACE sh_ias_temp add TEMPFILE 'sh_ias_temp01.DBF' SIZE 100M autoextend
on next 10M maxsize unlimited;

51.1.4.8 インバウンドWebサービスのメッセージ・サイズに対するサイズ制限の設定

インバウンドWebサービスのメッセージ・サイズにサイズ制限を設定する場合は、composite.xmlファイルでバインディング・コンポーネントのプロパティmax-message-sizeを構成します。プロパティ値は基礎となるWebサービス・インフラストラクチャで使用可能となり、値は受信メッセージ・サイズに対するテストに使用されます。指定した値を超えると、メッセージ・サイズが大きすぎることを示す例外がスローされ、トランザクションは処理されません。次の例に詳細を示します。

<composite name="LrgMsg" revision="1.0" label="2011-09-08_22-53-53_259"
mode="active" state="on">
<import namespace="http://xmlns.oracle.com/LargeMsg/LrgMsg/BPELProcess1"
location="BPELProcess1.wsdl" importType="wsdl"/>
<service name="bpelprocess1_client_ep" ui:wsdlLocation="BPELProcess1.wsdl">
<interface.wsdl
interface="http://xmlns.oracle.com/LargeMsg/LrgMsg/BPELProcess1# wsdl.interface
(BPELProcess1)"/>

<binding.ws port="http://xmlns.oracle.com/LargeMsg/LrgMsg/BPELProcess1
#wsdl.endpoint(bpelprocess1_client_ep/BPELProcess1_pt)">
<property name="max-message-size" type="xs:integer" many="false"
override="may">4</property>
</binding.ws>
</service>

<component name="BPELProcess1" version="1.1">
<implementation.bpel src="BPELProcess1.bpel"/>
</component>

<wire>
<source.uri>bpelprocess1_client_ep</source.uri>
<target.uri>BPELProcess1/bpelprocess1_client</target.uri>
</wire>
</composite>

51.1.4.9 XPath関数を使用したファイル・システムへの大規模なXSLT/XQuery出力の書込み

次の関数を使用して、大規模なXSLT/XQuery操作の結果をディレクトリ・システム内の一時ファイルに書き込むことができます。その後、ドキュメントは必要なときに一時ファイルからロードされます。これにより、ドキュメント全体をバイナリXMLとしてメモリーにキャッシュする必要がなくなります。

- ora:processXSLT

- ora:doXSLTransformForDoc

この機能を有効化にするには、ora:processXSLT関数でproperties引数を使用します。

ora:processXSLT('template','input','properties'?)

この引数の値は、XSLT内で、XSL変数からデータを抽出するのと同様な方法で取得します。properties引数は、次の例に示されているような構造のXML要素です。大きいペイロードの結果(10MBを超えるなど)に対しては、streamResultToTempFileをyesに設定します。一時ファイルに書き込む必要のない小さいペイロードの結果には、このプロパティをデフォルト値のnoの設定のままにしておきます。

<propertiesXMLVar>
<common:item  xmlns:common="http://schemas.oracle.com/service/bpel/common">
<common:name>streamResultToTempFile</common:name>
<common:value>yes</common:value>
</common:item>
</propertiesXMLVar>

XSLT内で、名前streamResultToTempFileおよびその値yesを介して、このパラメータにアクセスできます。

Oracle BPEL Process Managerでは、ora:processXSLT('template','input','properties'?)にプロパティを移入するためにリテラルのassignが実行されます。

この関数の使用の詳細は、「processXSLT」を参照してください。

ora:doXSLTransformForDoc関数では、この機能を有効にするために、nameおよびvalueプロパティを設定します。

ora:doXSLTransformForDoc('template','input','name', 'value')

この関数では、nameにstreamResultToTempFileおよびvalueにyesが渡されます。

この関数の使用の詳細は、「doXSLTransformForDoc」を参照してください。

51.2 大規模メタデータを処理する場合のベスト・プラクティス

この項では、大規模メタデータの処理に関する推奨事項について説明します。

51.2.1 BPELプロセスでの多数のアクティビティの処理に対する境界

BPELプロセスで実行できるアクティビティ数には制限があります。この制限を超えると、システム・メモリーが一杯になり、タイムアウトが発生する可能性があります。たとえば、次のパラメータを使用すると、タイムアウトによって2つのフォルト・インスタンスが発生します。

- 100スレッド

- 思考時間(秒数): 1

- 1000の着信リクエスト・メッセージ

システム・メモリーの安定性を確保するために、受信リクエスト・メッセージ数を適切なレベルに保つようにしてください。

51.2.2 BPELプロセスでの多数のアクティビティの使用(flowNを使用しない場合)

多数のアクティビティ(例: 50,000)があるBPELプロセスをデプロイするには、次の設定が必要です。

MEM_ARGS: -Xms512m -Xmx1024m -XX:PermSize = 128m -XX:MaxPermSize = 256m
Number of Concurrent Threads = 20
Number of Loops = 5 Delay = 100 ms

この設定によって、flowNアクティビティを使用せずにwhileループのみを使用するBPELプロセスを、正常にデプロイおよび実行できるようになります。

51.2.3 BPELプロセスでの多数のアクティビティの使用(flowNを使用する場合)

多数のアクティビティ(例: 50,000)があるBPELプロセスをデプロイするには、次の設定が必要です。

USER_MEM_ARGS: -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=256m
Number of Concurrent Threads= 10
Number of Loops=5 Delay=100 ms

Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで、StatsLastNプロパティを-1に設定します。

この設定によって、flowNアクティビティを使用するBPELプロセスを、正常にデプロイおよび実行できるようになります。

詳細は、「BPEL 1.1のflowNアクティビティによるflowアクティビティ数のカスタマイズ」、および『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のBPELプロセス・サービス・エンジン・プロパティの構成に関する項を参照してください。

51.2.4 複数シーケンスを含むフローの使用

7000までのアクティビティがあるBPELプロセスを、次の設定で正常にデプロイおよび実行できます。

USER_MEM_ARGS: -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=256m

注意:

8000を超えるアクティビティがあるBPELプロセスをデプロイすると、Oracle BPEL Process Managerのコンパイルでエラーがスローされます。

51.2.5 単一シーケンスを含むフローの使用

7000までのアクティビティがあるBPELプロセスを、次の設定で正常にデプロイおよび実行できます。

USER_MEM_ARGS: -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=512m

注意:

10,000を超えるアクティビティがあるBPELプロセスをデプロイすると、そのプロセスのコンパイルに失敗します。

51.2.6 シーケンスを含まないフローの使用

多数のアクティビティ(例: 5000まで)があるBPELプロセスを、正常にデプロイおよび実行できます。

BPELプロセスのコンパイルは、6000アクティビティの場合は失敗する可能性があります。

51.2.7 コンポジットの多数のOracle Mediator

単一のコンポジットに50を超えるOracle Mediatorを含めないことをお薦めします。環境にあわせて、JTAトランザクション・タイムアウトを高い値に増やします。

51.2.8 Oracle B2Bへの大規模データ・セットのインポート

大規模なデータ・セットのインポートには、ブラウザは使用せずにコマンドライン・ユーティリティを使用することをお薦めします。大規模なデータの構成には、次のユーティリティ・コマンドを使用してください。

- purge: リポジトリ全体をパージします。

- import: 指定したZIPファイルをインポートします。

- deploy: 名前を指定してアグリーメントをデプロイします。名前を指定しない場合は、すべてのアグリーメントがデプロイされます。

ただし、purgeimportdeployオプションは、Oracle B2B構成の転送またはデプロイには使用しないことをお薦めします。

詳細は、『Oracle B2Bユーザーズ・ガイド』を参照してください。

51.3 多数のインスタンスを処理する場合のベスト・プラクティス

この項では、多数のインスタンスおよびフォルト・メトリックの処理に関する推奨事項について説明します。

51.3.1 パージ・スクリプトまたはOracle Enterprise Manager Fusion Middleware Controlを使用したインスタンスと拒否されたメッセージの削除

PL/SQLパージ・スクリプトを使用するか、Oracle Enterprise Manager Fusion Middleware Controlの「自動パージ」ページを使用して、大量のインスタンスと拒否されたメッセージを削除できます。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

52 SOAコンポジット・アプリケーションのカスタマイズ

この章では、BPELプロセス・サービス・コンポーネントで使用可能なカスタマイズ機能を使用して、SOAコンポジット・アプリケーションをカスタマイズする方法について説明します。ここでは、カスタマイズ可能なアプリケーションの作成、バーティカル・バージョンのアプリケーションのカスタマイズ、および顧客バージョンのアプリケーションのカスタマイズを行う方法について説明します。また、次のバージョンのアプリケーションにアップグレードする方法についても説明します。

この章の内容は次のとおりです。

- SOAコンポジット・アプリケーションのカスタマイズの概要

- カスタマイズ可能なコンポジットの作成

- バーティカル・アプリケーションのカスタマイズ

- 顧客バージョンのカスタマイズ

- コンポジットのアップグレード

52.1 SOAコンポジット・アプリケーションのカスタマイズの概要

この項では、SOAコンポジット・アプリケーションをカスタマイズするライフ・サイクルについて説明します。たとえば、次の各組織では、同じコンポジットを使用する必要があるとします。ただし、若干の変更が必要です。

- コア・アプリケーション開発チーム

- バーティカル・アプリケーション・チーム

- 顧客

コア・アプリケーション開発チームでは、カスタマイズ可能な基本コンポジットを作成し、バーティカル・アプリケーション・チームに提供します。バーティカル・アプリケーション・チームでは、提供されたコンポジットを特定の業界(通信業界など)向けにカスタマイズします。調整されたソリューションは、通信業の顧客に販売されます。顧客は、特定の地理的なビジネス・ニーズに対応するためにコンポジットをさらにカスタマイズします。原則的には、1つの基本コンポジットと、複数レイヤーのカスタマイズ・コンポジットがあります。コンポジット・ライフ・サイクルの後半で、コア・アプリケーション開発チームは基本コンポーネントの新バージョンを作成し、バーティカル・アプリケーション・チームと顧客のアップグレード・サイクルをトリガーします。

レイヤー値は、指定されたカスタマイズ・レイヤーの値です。レイヤーとそのレイヤー値は1対多の関係です。カスタマイズを実行するレイヤーからレイヤー値を選択します。たとえば、Countryというカスタマイズ・レイヤーを表すカスタマイズ・クラスを指定するとします。次に、USA、China、Indiaなどの、その値に対する国を指定できます。Oracle JDeveloperをカスタマイズを実行するために「カスタマイズ開発者」ロールで再起動する場合、Oracle JDeveloperの「カスタマイズ・コンテキスト」ウィンドウからレイヤーのUSAなどのレイヤー値(つまり国)から1つを選択する必要があり、これは、その国に対するカスタマイズを作成することを意味します。

52.2 カスタマイズ可能なコンポジットの作成

この項では、カスタマイズ可能な基本SOAコンポジット・アプリケーションの作成に必要な手順の概要を示します。

52.2.1 カスタマイズ・クラスの作成方法

この項では、カスタマイズ・クラスを作成する方法について説明します。この例では、MyCustomizationLayerという名前のカスタマイズ・レイヤーのクラスを作成します。

カスタマイズ・クラスを作成する手順は、次のとおりです。

1. Oracle JDeveloperでJavaクラスの作成ウィザードを起動するには、「ファイル」→「ギャラリから」→「一般」→「Java」の順に選択します。

2. 次のクラスを拡張するJavaクラスを作成します。

oracle.tip.tools.ide.fabric.custom.GenericSOACustomizationClass

3. カスタマイズ・クラスに次のコンテンツを指定します。

package myCustomizationPackage;

import oracle.tip.tools.ide.fabric.custom.GenericSOACustomizationClass;

public class MyCustomizationClass extends GenericSOACustomizationClass {

public MyCustomizationClass() {
super();

// set the customization layer name
setName("MyCustomizationLayer");
}
}

カスタマイズ・クラスに正しいカスタマイズ・レイヤーが設定されるようにするには、コンストラクタに次をパラメータなしで追加して、カスタマイズ・レイヤー名を設定する必要があります。

// set the customization layer name
setName("MyCustomizationLayer");

オプションで、パラメータ付きのコンストラクタを削除することもできます。

「Javaクラスの作成」ウィザードによって次のコンテンツが自動的に生成されます。

package myCustomizationPackage;

import oracle.tip.tools.ide.fabric.custom.GenericSOACustomizationClass;

public class MyCustomizationClass extends GenericSOACustomizationClass {
public MyCustomizationClass(String string, String string1) {
super(string, string1);
}

public MyCustomizationClass() {
super();
}
}

カスタマイズ・クラスを有効にするには、SOAプロジェクトをビルドしてカスタマイズ・クラスをコンパイルします。

4. 「アプリケーション」ウィンドウで、「SOAプロジェクト」を右クリックして「ビルドSOA_project_name.jpr」を選択します。

5. Oracle JDeveloperの下部にある「ログ」ウィンドウで出力を確認して、ビルドが成功したことを確認します。

52.2.2 カスタマイズ可能なコンポジットの作成方法

カスタマイズ可能なコンポジットを作成する手順は、次のとおりです。

1. Oracle JDeveloperを起動し、「デフォルトのロール」を選択します。

2. 「ファイル」メニューから「新規」→「アプリケーション」→「SOAアプリケーション」の順に選択し、「OK」をクリックします。

3. SOAアプリケーションの作成ウィザードで、次の手順に従います。

4. SOAアプリケーションの作成ウィザードの「SOA設定の構成」ダイアログ(手順3の3)で、「BPELプロセスによるコンポジット」と「カスタマイズ可能」の両方のチェック・ボックスを選択して、「終了」をクリックします。

5. BPELプロセスを設計します。

注意:

変換を設計する場合は、XSLTマップ・エディタでのカスタマイズに関する次の制限に注意してください。

- ターゲット・パネル内のノードを右クリックすると表示される「テンプレートに作成」オプションが無効になります。

- 「XSLマップのテスト」オプションは、インポートされたXSLファイルに対するテンプレートの呼出しとテンプレートの適用については無効になります。このオプションは名前付きテンプレートに対して適用され、一致属性を持つテンプレート・ルールには適用されません。

6. scopeアクティビティを作成して、BPELプロセスをカスタマイズします。デフォルトではBPELプロセスはカスタマイズ可能でないため、このアクションが必要です。

注意:

「カスタマイズ開発者」ロールでOracle JDeveloperにログインしている場合は、composite.xmlファイル、.bpelファイル(Oracle BPEL Process Managerの場合)、.xslマップ・ファイルおよび.mplanファイル(Oracle Mediatorの場合)のみカスタマイズできます。

7. スコープを右クリックし、「カスタマイズ可能」を選択します。スコープを開いて右クリックすると、「カスタマイズ可能」オプションは表示されません。

8. 「アプリケーション」ウィンドウで、「アプリケーション・リソース」→「ディスクリプタ」→「ADF META_INF」の順に開きます。

9. adf-config.xmlファイルを開き、「MDS」タブを選択します。

10. 図52-1 に示すように、「追加」アイコンをクリックして必要なカスタマイズ・クラスを追加します。

実際の環境では、「SOAコンポジット・アプリケーションのカスタマイズの概要」の例に示すとおり、カスタマイズ・クラスは、コア・アプリケーション・チームによって提供されます。独自のカスタマイズ・クラスを使用する場合は、カスタマイズ・クラスのJARファイルをプロジェクトに追加して、adf-config.xmlファイルでそのクラスを使用できるようにする必要があります。

図52-1 カスタマイズ・クラス

11. SOAプロジェクトを右クリックし、「デプロイ」を選択します。

注意:

scopeアクティビティが空の場合は、コンパイル・エラーが返されます。空のアクティビティをscopeアクティビティにドラッグして、コンパイルを渡すことができます。

12. 「デプロイメント・アクション」ページで「SARファイルの生成」を選択します。これにより、JARファイル・パッケージが作成されます。このJARは、SOAアーカイブ(SAR)とも呼ばれます。

13. アプリケーションをソース・コード・コントロール・システムにチェックインします。これで、バーティカル・アプリケーション・チームに提供するファイルの準備が整いました。

カスタマイズ・クラスの作成方法の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。

52.2.3 XSDまたはWSDLファイルの追加方法

XSDまたはWSDLファイルを追加する手順は、次のとおりです。

「カスタマイズ開発者」ロールでログインすると、XMLスキーマまたはWSDLドキュメントをOracle JDeveloperで追加することができます。

1. 「アプリケーション」ウィンドウで「Oracle SOA Suite」プロジェクトを右クリックします。

2. 「SOA」を選択します。

3. 作成するアーティファクトを次の中から選択します。

- XMLスキーマの作成
プロジェクトで新しいXMLスキーマ・ファイルを追加する、「XMLスキーマの作成」ダイアログを起動します。完了すると、新しいスキーマ・ファイルが自動的に開きます。

- WSDLドキュメントの作成
プロジェクトで新しいWSDLファイルを追加する、WSDLの作成ダイアログを起動します。

52.2.4 BPELプロセスでのカスタマイズ・アクティビティの検索方法

Oracle JDeveloperのBPELプロセスでカスタマイズ・アクティビティを検索できます。

カスタマイズしたアクティブを検索する手順は、次のとおりです。

1. 「カスタマイズ開発者」ロールを使用してOracle JDeveloperにアクセスします。

2. デザイナの上部にあるBPELプロセスの「検索」メニューで、図52-2に示すように「カスタマイズ検索」 を選択します。

図52-2 「カスタマイズ検索」オプション

デザイナの下部にある「ログ」ウィンドウの「カスタマイズの検索」タブに検索結果が表示されます。

52.2.5 Oracle JDeveloperでの検証エラーの解決に関する必知事項

カスタマイズ・ロールでは、Oracle Metadata Services (MDS)リポジトリによってカスタマイズとベース・メタデータがマージされます。マージにより、スキーマに対して無効なXMLドキュメントが作成される可能性があります。MDSリポジトリのマージでは、マージによって常に有効なXMLドキュメントが作成されることを確認するためのスキーマ検証は起動されません。このため、メタデータUIエディタをレンダリングするためにメタデータの妥当性に依存するMDSクライアントに問題が発生する可能性があります。

composite.xmlなどのSOAファイルが無効になる場合は、Oracle JDeveloperの「ソース」ビューに切り替えて、XMLソースを直接修正する必要があります。「ソース」ビューが編集不可(「カスタマイズ開発者」ロールを使用してOracle JDeveloperにアクセスした場合など)の場合は、Oracle JDeveloperの「構造」ウィンドウを使用してXMLソースを修正する必要があります。

たとえば、カスタマイズ可能なスコープを含むBPELプロセスで基本SOAコンポジット・アプリケーションを作成したとします。基本アプリケーションのSARファイルが新しいアプリケーションにインポートされ、「カスタマイズ開発者」ロールでOracle JDeveloperにアクセスするとき、次のコンポーネントが追加されました。

- アウトバウンド・ファイル・アダプタ

- ファイル・アダプタを起動するためのinvokeアクティビティ(カスタマイズ可能なスコープに追加)

バージョン2の基本SOAコンポジット・アプリケーションが作成されたときに、同期Oracle Mediatorサービス・コンポーネントが追加されました。これにより、BPELプロセス・サービス・コンポーネントへのルーティング・ルールが更新されました。

その後、バージョン2のベース・アプリケーションのSARファイルが、カスタマイズされたアプリケーションにインポートされました。ユーザーが「カスタマイズ開発者」ロールを使用してOracle JDeveloperにアクセスしたときに、無効なコンポジット・エラーが表示されました。「構造」ウィンドウのcomposite.xmlファイルには、次のように、一連のサービス・コンポーネントおよび参照バインディング・コンポーネントの無効な構造が表示されました。次の例に詳細を示します。

<component> </component>
<reference> </reference>
<component> </component>

<reference>コンポーネント(この場合、バージョン1のベース・アプリケーションでは、ユーザーが「カスタマイズ開発者」ロールを使用してOracle JDeveloperにアクセスしたときに追加されたアウトバウンド・ファイル・アダプタ)は、最後に表示されている必要があります。次の例に詳細を示します。

<component> </component>
<component> </component>
<reference> </reference>

このエラーを解決するには、「構造」ウィンドウに移動し、これらのコンポーネントをコピーして正しい順序で貼り付けます。このアクションにより、コンポジット検証エラーが解決されます。

52.2.6 シーケンスの競合の解決に関する必知事項

この項では、シーケンスの競合の解決方法の例を説明します。

シーケンスの複雑さを解決する手順は、次のとおりです。

1. バージョン1のSOAコンポジット・アプリケーションをカスタマイズします。

たとえば、「カスタマイズ開発者」ロールでOracle JDeveloperにログインしているときに、BPELプロセスのカスタマイズ可能なscopeアクティビティに新しいアクティビティを追加します。BPELプロセスにより、新しいアクティビティが追加されるsequenceアクティビティが作成されます。

2. バージョン2のSOAコンポジット・アプリケーションを作成します。

バージョン2コンポジットで、同じカスタマイズ可能なスコープに新しいアクティビティを追加すると、新しいsequenceアクティビティが作成されます。

3. バージョン2のSOAコンポジット・アプリケーションをカスタマイズされたアプリケーションにインポートします。

4. 「カスタマイズ開発者」ロールでOracle JDeveloperを開きます。

次のエラーが表示されます。

Sequence element is not expected

52.2.6.1 競合を解決する手順:

1. 「構造」ウィンドウに移動します。

2. シーケンスを展開します。

3. 各コンポーネントをコピーし、別のシーケンスに貼り付けます。

4. コピー元のシーケンス内のコンポーネントを削除します。

5. シーケンスが空の場合は削除します。

52.2.7 カスタマイズされたアプリケーションのコンパイルおよびデプロイに関する必知事項

コア・アプリケーション、バーティカル・アプリケーションまたは顧客レベルでカスタマイズされたアプリケーションをデプロイまたはコンパイルすると、次の例に示すように、予期しないID属性を説明した警告メッセージが表示されます。これらのメッセージは無視して問題ありません。スキーマ定義に必要な単純型要素が含まれていないために、これらのメッセージが表示されます。これらのメッセージにより、カスタマイズされたコンポジットが正常にデプロイされないわけではありません。

[scac] warning: in
/scratch/qizhong/my-jdev/mywork/CompositeTestApp2/Project2/composite.xml(22,32):
Schema validation failed for
/scratch/qizhong/my-jdev/mywork/CompositeTestApp2/Project2/composite.xml<Line 22,
Column 32>: XML-24535: (Error) Attribute
'http://www.w3.org/XML/1998/namespace:id' not expected.
[scac] warning: in
/scratch/qizhong/my-jdev/mywork/CompositeTestApp2/Project2/composite.xml(23,32):
Schema validation failed for
/scratch/qizhong/my-jdev/mywork/CompositeTestApp2/Project2/composite.xml<Line 23,
Column 32>: XML-24535: (Error) Attribute
'http://www.w3.org/XML/1998/namespace:id' not expected.

52.3 バーティカル・アプリケーションのカスタマイズ

この項では、バーティカルSOAコンポジット・アプリケーションのカスタマイズに必要な手順の概要を示します。

注意:

異なるレイヤー値の同じSOAコンポジット・アプリケーションをカスタマイズしないでください。レイヤー値は、「SOAコンポジット・アプリケーションのカスタマイズの概要」で説明するとおり、ベース・コンポジットに対して行ったカスタマイズです。カスタマイズ用にサポートされているのは、1つのレイヤー値のみです。別のレイヤー値をサポートする必要がある場合は、必ずベース・コンポジットを別のプロジェクトにインポートし、コンポジット名を、カスタマイズするレイヤー値に固有のものに変更します。このアプローチは、同じコンポジット名で異なるレイヤー値をデプロイしないようにするデプロイメントの場合にも便利です。

52.3.1 バーティカル・アプリケーションのカスタマイズ方法

バーティカル・アプリケーションをカスタマイズする手順は、次のとおりです。

1. 次のいずれかの方法を使用して、カスタマイズ・レイヤーのレイヤー値を追加します。

a. アプリケーション固有のレイヤー値を追加するには、図52-3 に示すように、「デザインタイム・カスタマイズ・レイヤー値の構成」リンクをクリックします。

図52-3 「デザインタイム・カスタマイズ・レイヤー値の構成」リンク

b. レイヤー値を追加します。
値を指定してファイルを保存すると、「アプリケーション・リソース」のMDS DTフォルダにCustomizationLayerValues.xmlファイルが表示されます。カスタマイズ・クラスはレイヤー名を提供し、CustomizationLayerValues.xmlファイルはレイヤー値を提供します。どちらも必要です。この場所のファイルをダブルクリックすると、その他の変更を行うためのエディタが開きます。

または

a. すべてのアプリケーションに適用可能なグローバル値を追加するには、$JDEV_HOME/jdeveloper/jdevのCustomizationLayerValues.xmlファイルを開き、カスタマイズ・レイヤーのレイヤー値を追加します。たとえば、値Communicationsをindustryレイヤーに追加します。

<cust-layers xmlns="http://xmlns.oracle.com/mds/dt">
<cust-layer name="industry">
<cust-layer-value value="communications" display-name="Communications"/>
</cust-layer>
</cust-layers>

2. Oracle JDeveloperを起動し、「デフォルトのロール」を選択します。

3. コア・アプリケーションとは異なる名前で新しいSOAアプリケーションを作成します。

4. 「ファイル」メニューから、「インポート」→「SOAアーカイブをSOAプロジェクトへ」の順に選択します。

5. 「参照」をクリックし、「カスタマイズ可能なコンポジットの作成」でコア・アプリケーション・チームが作成したコンポジット・アーカイブのJARファイルを選択します。

6. 「コンポジット名」フィールドで、コアSOAプロジェクトとは別の名前を入力します。

注意:

SOAプロジェクトは選択しないでください。インポートするJARファイルには、新規SOAプロジェクトを作成する必要があります。

7. 「カスタマイズ用にインポート」チェック・ボックスを選択します。

8. 「アプリケーション」ウィンドウで、プロジェクトを右クリックし、「SOA」→「カスタマイズ可能」の順に選択します。

9. Oracle JDeveloperを再起動します。
「カスタマイズ・コンテキスト」ダイアログに、使用可能なカスタマイズ・レイヤーとレイヤー値が表示されます。

10. 図52-4 に示すように、カスタマイズするレイヤーおよび値を選択します(この例では、レイヤーindustryおよび値Communicationsが選択されています)。

図52-4 カスタマイズ・コンテキスト

11. SOAコンポジット・エディタで、BPELプロセスをダブルクリックしてOracle BPELデザイナにアクセスします。
編集できるのは、カスタマイズ可能に設定されているscopeアクティビティのみです。図52-5 に示す例では、コア・アプリケーション・チームが1つのスコープのみをカスタマイズ可能に設定しています。BPELプロセスのその他のアクティビティは無効になり、編集できません。

図52-5 カスタマイズ可能な1つのスコープ

12. 「アプリケーション」ウィンドウで「SOAプロジェクト」を右クリックし、「デプロイ」を選択してカスタマイズ・コンポジット(SAR)のJARファイルを作成します。
デプロイメントはカスタマイズ・ロールが使用可能な状態で起動されるため、現在のカスタマイズ・コンテキストに基づいて適切なレイヤーの基本コンポジットが自動的にマージされます。

13. アプリケーションをソース・コード・コントロール・システムにチェックインします。
JARファイルには、次のカスタマイズ・レベルの基本プロセスとして順に機能するマージされたコンポジットが格納されます。これで、JARファイルを顧客に提供できるようになりました。

注意:

「カスタマイズ開発者」ロールでOracle JDeveloperにログインしているときに、WSDLファイルおよびXSDファイルを作成できます。「アプリケーション」ウィンドウで、プロジェクト名を右クリックし、「SOA」→「WSDLドキュメントの作成」または「SOA」→「XMLスキーマの作成」の順に選択します。

52.4 顧客バージョンのカスタマイズ

この項では、顧客バージョンのSOAコンポジット・アプリケーションのカスタマイズに必要な手順の概要を示します。

52.4.1 顧客バージョンのカスタマイズ方法

顧客バージョンをカスタマイズする手順は、次のとおりです。

1. 次のいずれかの方法を使用して、カスタマイズ・レイヤーのレイヤー値を追加します。

a. アプリケーション固有のレイヤー値を追加するには、「バーティカル・アプリケーションのカスタマイズ」の手順1に示すように、「デザインタイム・カスタマイズ・レイヤー値の構成」リンクをクリックします。

b. レイヤー値を追加します。
値を指定してファイルを保存すると、「アプリケーション・リソース」のMDS DTフォルダにCustomizationLayerValues.xmlファイルが表示されます。この場所のファイルをダブルクリックすると、その他の変更を行うためのエディタが開きます。

または

a. すべてのアプリケーションに適用可能なグローバル値を追加するには、$JDEV_HOME/jdeveloper/jdevのCustomizationLayerValues.xmlファイルを開き、カスタマイズ・レイヤーのレイヤー値を追加します。たとえば、North America値およびAsia Pacific値をsiteレイヤーに追加します。

<cust-layers xmlns="http://xmlns.oracle.com/mds/dt">
<cust-layer name="site">
<cust-layer-value value="communications" display-name="North America"/>
<cust-layer-value value="communications" display-name="Asia Pacific"/>
</cust-layer>
</cust-layers>

2. Oracle JDeveloperを起動し、「デフォルトのロール」を選択します。

3. コア・アプリケーションまたはカスタマイズ・アプリケーションとは異なる名前で新しいSOAアプリケーションを作成します。

4. 「ファイル」メニューから、「インポート」→「SOAアーカイブをSOAプロジェクトへ」の順に選択します。

5. 「参照」をクリックし、「バーティカル・アプリケーションのカスタマイズ」でバーティカル・アプリケーション・チームが作成したコンポジット・アーカイブのJARファイルを選択します。

6. 「カスタマイズ用にインポート」チェック・ボックスを選択します。

7. 「ツール」メニューから、「ロールの切替え」→「カスタマイズ開発者」を選択します。

8. Oracle JDeveloperを再起動します。
「カスタマイズ・コンテキスト」ダイアログに、使用可能なカスタマイズ・レイヤーとレイヤー値が表示されます。

9. 図52-6 に示すように、カスタマイズするレイヤーと値を選択します(この例では、siteレイヤーとNorth America値が選択されています)。

図52-6 カスタマイズ・コンテキスト

10. BPELプロセスをカスタマイズします。

11. SOAプロジェクトを右クリックし、「デプロイ」を選択して北米地域のJARファイル(SAR)を作成します。

12. アプリケーションをソース・コード・コントロール・システムにチェックインします。

52.5 コンポジットのアップグレード

この項では、SOAコンポジット・アプリケーションの次のバージョンへのアップグレードに必要な手順の概要を示します。

52.5.1 コア・アプリケーション・チーム・コンポジットのアップグレード方法

コア・アプリケーション・チームは、不具合の修正、製品の拡張および次のバージョンのコンポジットの作成を実施します。

コア・アプリケーション・チーム・コンポジットをアップグレードする手順は、次のとおりです。

1. 「カスタマイズ可能なコンポジットの作成」で作成したアプリケーションをソース・コントロールからチェックアウトします。

2. Oracle JDeveloperを起動し、「デフォルトのロール」を選択します。

3. 不具合を修正し、製品を拡張します。

4. コンポジットをデプロイし、次のバージョンのJARファイルを作成します。

5. JARファイルをバーティカル・アプリケーション・チームに提供します。

52.5.2 バーティカル・アプリケーション・チーム・コンポジットのアップグレード方法

バーティカル・アプリケーション・チームは、新しい基本コンポジットをカスタマイズしてJARファイル・バージョンを作成します。

バーティカル・アプリケーション・チーム・コンポジットをアップグレードする手順は、次のとおりです。

1. 「バーティカル・アプリケーションのカスタマイズ」で作成したアプリケーションをソース・コントロールからチェックアウトします。

2. Oracle JDeveloperを起動し、「デフォルトのロール」を選択します。

3. チェックアウトしたアプリケーションを開きます。

4. 「アプリケーション」ウィンドウでプロジェクト・ノードを選択し、現在のプロジェクト・コンテキストを設定します。次の手順のインポート・コマンドでは、選択したプロジェクトにSOAアーカイブをインポートして基本をアップグレードするため、この手順は重要です。

5. Oracle JDeveloperの「ファイル」メニューから、「コア・アプリケーション・チーム・コンポジットのアップグレード方法」で作成された新規リビジョンのJARファイルをインポートします。

6. 「ツール」メニューから、「ロールの切替え」→「カスタマイズ開発者」の順に選択します。

7. Oracle JDeveloperを再起動します。

8. 「カスタマイズ・コンテキスト」ダイアログで、カスタマイズするレイヤーと値を選択します(たとえば、industryレイヤーとCommunicationsの値を選択します)。

9. BPELプロセスを開き、前の手順で選択したコンテキストのレイヤーに、新しい基本コンポーネントをマージできるかどうかを確認します。

10. ログ・ウィンドウで潜在的な警告およびエラーを確認します。

11. 必要な場合は、プロセスを変更してエラーおよび警告を修正します。これにより、レイヤーがバックグラウンドで編集されます。

12. コンポジットをデプロイして、カスタマイズされたJARファイルの次のリビジョンを作成し、アップグレードする顧客に提供します。

52.5.3 カスタマ・コンポジットのアップグレード方法

顧客は、「バーティカル・アプリケーション・チーム・コンポジットのアップグレード方法」のバーティカル・アプリケーション・チームと同じ手順に従って、新しいベース・コンポジットに独自のレイヤーを適用します。

53 コンポジット・センサーの定義

この章では、SOAコンポジット・アプリケーションでメッセージにトラッキング可能なフィールドを実装する手段を提供する、コンポジット・センサーを定義する方法について説明します。ここでは、ビジネス・イベントをサブスクライブしているバインディング・コンポーネントおよびサービス・コンポーネント上でセンサーを定義する方法について説明します。コンポジット・センサーの使用に関する制限と、Oracle SOAコンポーザの実行時にコンポジット・センサーを管理する方法についても説明します。

この章の内容は次のとおりです。

- コンポジット・センサーの概要

- コンポジット・センサーの追加

- 実行時のコンポジット・センサー・データの監視

- Oracle SOAコンポーザからのコンポジット・センサーの実行時の作成および管理

BPELプロセスにおけるアクティビティ、フォルト、変数の各センサーの詳細は、「Oracle BPEL Process Managerセンサーと分析の使用」を参照してください。

ビジネス・シナリオでのコンポジット・センサーの使用例は、『Oracle SOA Suiteの理解』を参照してください。

53.1 コンポジット・センサーの概要

コンポジット・センサーは、メッセージにトラッキング可能なフィールドを実装する手段を提供します。コンポジット・センサーを使用すると、次のタスクを実行できます。

- 受信メッセージおよび送信メッセージを監視できます。

- Oracle Enterprise Manager Fusion Middleware ControlのSOAインフラストラクチャ、パーティションおよびSOAコンポジット・アプリケーションの「フロー・インスタンス」ページにある検索ユーティリティで、コンポジット・センサーの詳細を指定します。このアクションにより、コンポジット・センサーを含む特定インスタンスの詳細を表示できます。

- 受信メッセージおよび送信メッセージから計算されたJMSデータをパブリッシュします。

- ビジネス・イベント・サブスクリプションによって開始されたコンポジット・インスタンスを追跡します。

コンポジット・センサーは、Oracle JDeveloperでビジネス・イベント・サブスクリプションがあるサービス・バインディング・コンポーネントおよび参照バインディング・コンポーネント、またはサービス・コンポーネントに定義します。この機能は、BPELプロセスの変数センサーに類似しています。実行時に、コンポジット・センサー・データはデータベースに維持されます。

Oracle SOAコンポーザの実行時にコンポジット・センサーを定義することもできます。Oracle SOAコンポーザの変更は実行時にすぐに取得されますが、Oracle JDeveloperを使用して行った変更ではSOAコンポジット・アプリケーションを再デプロイする必要があります。

Oracle Enterprise Manager Fusion Middleware Controlでのコンポジット・センサーの検索の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAインフラストラクチャまたはパーティション・レベルでのビジネス・フロー・インスタンスのトラッキングに関する項を参照してください。

53.1.1 コンポジット・センサー使用上の制限

コンポジット・センサーの使用に関して、次の制限に注意してください。

- XPath式の関数は、プロパティとともに使用できません。

- 式によって定義されるコンポジット・センサーは常に、値を文字列として取得します。このため、センサー・タイプは常に文字列です。このアクションにより検索が可能になります。
文字列から派生したXMLタイプを扱う際には、値を文字列として取得すると便利な場合があります。次の例に詳細を示します。

<xs:element name="CardNum">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:length value="16"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

式が数値であっても、文字列として取得されます。<、>、=、これらの組合せなど、他の論理演算子を使用できません。

- 変数によって定義されるコンポジット・センサーは、変数タイプを使用してセンサー・タイプを決定します。センサーは次のいずれかのタイプです。

- STRING

- NUMBER

- DATE

- DATE_TIME

- 複合XML

- コンポジット・センサーでは、Enterprise ManagerおよびJMSの2つのタイプのセンサー・アクションのみがサポートされます。

- Webサービス・バインディングに対しては、ヘッダー・ベースのセンサーのみがサポートされています。

- Oracle B2B、サービス・データ・オブジェクト(SDO)、Web Services Invocation Framework (WSIF)およびOracle Business Activity Monitoringのバインディングに対するセンサー・アクションは、サポートされていません。

- フィルタリング用のXPath式を作成する場合は、ノードセットを返すすべての関数を文字列として明示的にキャストする必要があります。

xpath20:upper-case(string($in.request/inp1:updateOrderStatus/inp1:orderStatus) ) = "PENDING"

- ビジネス・イベントを公開するサービス・コンポーネント上でセンサーを構成することはできません。

- ビジネス・イベント・ヘッダーに基づいたセンサーは許可されません(ペイロードのみが許可されます)。

- PL/SQLサブスクリプションはサポートされていません。

53.2 コンポジット・センサーの追加

SOAコンポジット・エディタで、SOAコンポジット・アプリケーションの次のコンポーネントにセンサーを追加します。

- サービス・バインディング・コンポーネントまたは参照バインディング・コンポーネント

- ビジネス・イベントをサブスクライブしているBPELプロセスやOracle Mediatorなどのサービス・コンポーネント

53.2.1 コンポジット・センサーの追加方法

コンポジット・センサーを追加する手順は、次のとおりです。

1. 次のいずれかのオプションを使用して、SOAコンポジット・エディタでコンポジット・センサーを追加します。

a. 「公開されたサービス」または「外部参照」スイムレーン、あるいはビジネス・イベントをサブスクライブしているサービス・コンポーネントで特定のサービスまたは参照バインディング・コンポーネントを右クリックします。ビジネス・イベントをサブスクライブしているサービス・コンポーネントには、サブスクライブ済という語が含まれます。

b. 「センサーの構成」を選択します。

注意:

「センサーの構成」オプションが表示されるためには、サービス・コンポーネントにすでにビジネス・イベントがサブスクライブされている必要があります。

バインディング・コンポーネントを選択すると、「コンポジット・センサー」ダイアログに詳細が表示されます(図53-1 を参照)。この例では、サービス・バインディング・コンポーネントが選択されています。

図53-1 選択したバインディング・コンポーネントの「コンポジット・センサー」ダイアログ

サービス・コンポーネントを選択すると、図53-2 に示す詳細が「コンポジット・センサー」ダイアログに表示されます。

図53-2 選択したサービス・コンポーネントの「コンポジット・センサー」ダイアログ

c. ダイアログで、バインディング・コンポーネントまたはサービス・コンポーネントを選択して、「追加」アイコンをクリックします。

または

a. 図53-3 に示すように、SOAコンポジット・エディタ上部にある「コンポジット・センサー」アイコンをクリックします。

図53-3 「コンポジット・センサー」アイコン

図53-4 に示すように、SOAコンポジット・アプリケーションの「コンポジット・センサー」ダイアログが表示されます。このオプションでは、SOAコンポジット・アプリケーションの、サブスクライブされたビジネス・イベントがあるすべてのサービスおよび参照のバインディング・コンポーネントとサービス・コンポーネントが表示されます。

図53-4 「コンポジット・センサー」ダイアログ

b. コンポジット・センサーを追加するサービス、参照またはビジネス・イベントを選択し、「追加」アイコンをクリックします。

サービスなどのバインディング・コンポーネントを選択すると、図53-5 に示すように「コンポジット・センサーの作成」ダイアログが表示されます。

図53-5 サービス・バインディング・コンポーネントの「コンポジット・センサーの作成」ダイアログ

ビジネス・イベント・サブスクリプションがあるサービス・コンポーネントを選択すると、図53-6 に示すように「コンポジット・センサーの作成」ダイアログが表示されます。

図53-6 サービス・コンポーネントの「コンポジット・センサーの作成」ダイアログ

2. 表53-1 に記載されている詳細を入力します。

表53-1 「コンポジット・センサーの作成」ダイアログ

名前

説明

名前

コンポジット・センサーの名前を入力します。「式」フィールドの「編集」アイコンを使用可能にするには、名前を入力する必要があります。

サービス

サービス名が表示されます。このフィールドが表示されるのは、サービス・バインディング・コンポーネントに対するコンポジット・センサーを作成している場合のみです。このフィールドは編集できません。

サービス・センサーは、サービスが外部または別のコンポジット・アプリケーションから受信するメッセージを監視します。

参照

参照名が表示されます。このフィールドが表示されるのは、参照バインディング・コンポーネントに対するコンポジット・センサーを作成している場合のみです。このフィールドは編集できません。

参照センサーは、参照が外部または別のコンポジット・アプリケーションに送信するメッセージを監視します。

操作

サービスまたは参照のポート・タイプに対する操作を選択します。このフィールドは、サービスまたは参照バインディング・コンポーネントに対してのみ表示されます。

イベント

サービス・コンポーネントの名前が表示されます。このフィールドが表示されるのは、サービス・コンポーネントに対するコンポジット・センサーを作成している場合のみです。このフィールドは編集できません。

イベント・センサーはビジネス・イベントによって開始されたコンポジット・インスタンスを追跡します。ビジネス・イベントごとに複数のセンサーを作成できます。

イベント・タイプ

「サブスクライブ」ビジネス・イベント・タイプが表示されます。このフィールドは編集できません。パブリッシュ・ビジネス・イベント・タイプはサポートされていません。

式

「編集」アイコンをクリックすると、作成する式のタイプを選択するドロップダウン・リストが表示されます。

- 変数: 変数に対する式の値を作成する場合に選択します。手順は、「変数の追加方法」を参照してください。

- 式: XPath式を作成するための「式ビルダー」ダイアログを起動する場合に選択します。このアクションは、常に値を文字列として取得します。手順は、「式の追加方法」を参照してください。

- プロパティ: 正規化されたメッセージ・ヘッダー・プロパティに対する式の値を作成する場合に選択します。これらは、invokeアクティビティ、receiveアクティビティ、replyアクティビティ、scopeアクティビティのOnEventブランチ(BPEL 2.0の場合)、およびpickアクティビティとscopeアクティビティ(BPEL 2.0の場合)のonMessageブランチの「プロパティ」タブの下に表示される同じプロパティです。手順は、「プロパティの追加方法」を参照してください。

フィルタ

「編集」アイコンをクリックすると、式用のXPathフィルタを作成する「式ビルダー」ダイアログが起動します。このフィールドを使用可能にするには、最初に式を作成する必要があります。

たとえば、10,000を超える発注金額をトラッキングする式を作成できます。

$in.inDict/tns:inDict/ns2:KeyValueOfstringstring/ns2:Value > 10000.00

コンポジット・センサー・アクション

サポートされているセンサー・アクションを表示します。この機能を使用すると、ランタイム・センサー・データを格納できます。「Enterprise Manager」と「JMSキュー」または「JMSトピック」のいずれかとの両方を選択できます。

- Enterprise Manager
選択すると、Oracle Enterprise Manager Fusion Middleware ControlのSOAコンポジット・アプリケーションの「フロー・インスタンス」タブでランタイム・センサー・データを検索できるようになります。この選択は、前のリリースのDBSensorActionの選択と同じです。

注意: 「Enterprise Manager」が選択されている場合、センサー・データはトラッキング可能フィールド表に送られます。選択されていない場合、データは送られません。ただし、いずれの場合も、Oracle Enterprise Manager Fusion Middleware Controlにはこのフィールドが表示され、センサーに基づいたコンポジット・インスタンスの検索が可能です。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

- JMSキュー
コンポジット・センサー・データ(XMLペイロード)をJMSキューに格納する場合に選択します。JMSコネクション・ファクトリおよびキュー名を指定する必要があります。

- JMSトピック
コンポジット・センサー・データ(XMLペイロード)をJMSトピックに格納する場合に選択します。JMSコネクション・ファクトリおよびトピック名を指定する必要があります。

注意: 「JMSキュー」および「JMSトピック」を選択すると、コンポジット・センサー・データ(XMLペイロード)がOracle Business Activity Monitoring (BAM)やOracle Complex Event Processingなどの他のコンシューマでも使用できるようになります。どちらを選択した場合も、Oracle WebLogic ServerによるネイティブのJMSサポートが使用され、『テクノロジ・アダプタの理解』の説明にあるようなOracle SOA Suite JMSアダプタは使用されません。JMSメッセージはOracle WebLogic Server管理コンソールで表示できます。

3. 完了後に「OK」をクリックします。
サービスまたは参照バインディング・コンポーネントでは、図53-7 に示すように、コンポジット・センサー・アイコンが右上隅に表示されます。

図53-7 バインディング・コンポーネントのセンサー・アイコン

サービス・コンポーネントでは、図53-8 に示すように、コンポジット・センサー・アイコンも右上隅に表示されます。

図53-8 サービス・コンポーネントのセンサー・アイコン

4. コンポジット・センサー・アイコンの上にカーソルを置くと、コンポジット・センサーに関する詳細が表示されます。

53.2.1.1 変数の追加方法

図53-9 に示す「XPath式の選択」では、トラッキングする要素を選択できます。

変数を追加する手順は、次のとおりです。

1. ツリーを開き、トラッキングする要素を選択します(この例では、注文ID)。

図53-9 変数

2. 完了後に「OK」をクリックします。

53.2.1.2 式の追加方法

図53-10 に示す「式ビルダー」ダイアログでは、トラッキングする式を作成できます。

式を追加する手順は、次のとおりです。

1. トラッキングする要素のXPath式を作成します。

図53-10 式

2. 完了後に「OK」をクリックします。

53.2.1.3 プロパティの追加方法

図53-11 に示す「プロパティの選択」ダイアログでは、トラッキングする正規化されたメッセージ・ヘッダー・プロパティを選択できます。

プロパティを追加する手順は、次のとおりです。

1. トラッキングする正規化されたメッセージ・ヘッダー・プロパティを選択します。

図53-11 プロパティ

2. 完了後に「OK」をクリックします。

正規化されたメッセージの詳細は、「メッセージ・ヘッダーを介した正規化メッセージ・プロパティの伝播」を参照してください。

53.2.2 重複するコンポジット・センサー名に関する必知事項

コンポジット・センサーに重複する名前を使用する場合は、次の詳細に注意してください。

- 重複する名前を持つコンポジット・センサーを作成すると、定義の内容全体が比較されます。重複する名前は、1つ以上の追加パラメータが異なる場合に許可されます(たとえば、異なる構成タイプや異なる式、フィルタ、操作名など)。重複する名前が許可されるためには、定義で何かが異なっている必要があります。

- 重複するセンサー定義がある場合は、最後に実行されたセンサー値のみが維持されます。このため、相互に排他的なパスに対してこのタイプの構成を使用できます(たとえば、コンポジットはサービス1またはサービス2によって起動されます)。したがって、両方のサービスで同じセンサー名を定義できます。ただし、サービス1と参照1に同じ名前を定義した場合、参照1のセンサー値(最後に実行されたセンサー)のみが格納されます。

- 通常は、同じ名前の複数のセンサーを使用して、異なるソースから抽出された同じ論理エンティティを指します(たとえば、Oracle Enterprise Manager Fusion Middleware Controlでは、最終的なセンサー値が表示されます)。このため、異なるソースから電子メール値と社会保障値を抽出する場合に同じセンサー名を使用すると、混乱を招く可能性があります。

- センサー・アクションは、同じセンサー名のすべての発生に適用されます。この状況は、最近定義された同じ名前のセンサーのセンサー・アクションが優先されることを意味します。

次の例のsensor.xmlに示すシナリオでは:

- Service1という名前に最初の2つのセンサーは同一です。さらに、構成タイプはどちらもserviceConfig(サービス・バインディング・コンポーネントで定義されたコンポジット・センサー)です。したがって、センサーは1つのエントリになります(2番目のセンサーは無視されます)。

- Service1という名前の3番目のセンサーは、異なる構成タイプeventConfig(ビジネス・イベントで定義されたコンポジット・センサー)を持ちます。したがって、このセンサーは別のエントリで表されます。

- PurchaseOrder Idという名前の2つのセンサーは、構成タイプが異なります(eventConfigおよびserviceConfig)。したがって、これらは別のエントリで表されます。

- PurchaseOrderという名前の2つのセンサーは、構成タイプは同じ(eventConfig)ですが、式は異なります。したがって、これらは別のエントリで表されます。

<sensors xmlns="http://xmlns.oracle.com/bpel/sensor">
<sensor sensorName="Service1" kind="service" target="undefined" filter="">
<serviceConfig service="OrderPublisher_ep"
expression="$in.property.tracking.ecid" operation="execute"
outputDataType="string" outputNamespace="http://www.w3.org/2001/XMLSchema"/>
</sensor>
<sensor sensorName="Service1" kind="service" target="undefined" filter="">
<serviceConfig service="OrderPublisher_ep"
expression="$in.property.tracking.ecid" operation="execute"
outputDataType="string" outputNamespace="http://www.w3.org/2001/XMLSchema"/>
</sensor>
<sensor sensorName="Service1" kind="event" target="undefined" filter=""
xmlns:po="http://www.mycompany.com/ns/order">
<eventConfig component="EventMediator"
expression="$in/po:PurchaseOrder/po:OrderID"
event="{http://mycompany.com/events/orders}OrderReceivedEvent"
outputDataType="string" outputNamespace="http://www.w3.org/2001/XMLSchema"/>
<sensor sensorName="Event1" kind="event" target="undefined" filter="">
<eventConfig component="EventMediator" actionType="Subscribe"
expression="$in.property.tracking.ecid"
event="{http://mycompany.com/events/orders}OrderReceivedEvent"
outputDataType="string" outputNamespace="http://www.w3.org/2001/XMLSchema"/>
</sensor>
<sensor sensorName="PurchaseOrder Id" kind="event" target="undefined" filter=""
xmlns:po="http://www.mycompany.com/ns/order">
<eventConfig component="EventMediator"
expression="$in/po:PurchaseOrder/po:OrderID"
event="{http://mycompany.com/events/orders}OrderReceivedEvent"
outputDataType="string" outputNamespace="http://www.w3.org/2001/XMLSchema"/>
</sensor>
<sensor sensorName="PurchaseOrder Id" kind="service" target="undefined"
filter="">
<serviceConfig service="OrderPublisher_ep"
expression="$in.property.tracking.ecid" operation="execute"
outputDataType="string" outputNamespace="http://www.w3.org/2001/XMLSchema"/>
</sensor>
<sensor sensorName="PurchaseOrder" kind="event" target="undefined" filter=""
xmlns:po="http://www.mycompany.com/ns/order">
<eventConfig component="EventMediator" expression="$in/po:PurchaseOrder"
event="{http://mycompany.com/events/orders}OrderReceivedEvent"
outputDataType="PurchaseOrder"
outputNamespace="http://mycompany.com/events/orders"/>
</sensor>
<sensor sensorName="PurchaseOrder" kind="event" target="undefined" filter=""
xmlns:po="http://www.mycompany.com/ns/order">
<eventConfig component="EventMediator"
expression="$in/po:PurchaseOrder/po:OrderID"
event="{http://mycompany.com/events/orders}OrderReceivedEvent"
outputDataType="string" outputNamespace="http://www.w3.org/2001/XMLSchema"/>
</sensor>
</sensor>
</sensors>

53.3 実行時のコンポジット・センサー・データの監視

実行時に、Oracle Enterprise Manager Fusion Middleware Controlでコンポジット・センサー・データを監視できます。

- コンポジット・センサー・データは、SOAコンポジット・アプリケーションのフローのトレースに表示されます。

- 「フロー・インスタンス」ページで、コンポジット・センサーのデータをSOAインフラストラクチャ、個々のパーティション、およびSOAコンポジット・アプリケーションのレベルで検索できます。

Oracle Enterprise Manager Fusion Middleware Controlでのコンポジット・センサーの検索の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAインフラストラクチャ・レベルでのSOAコンポジット・アプリケーション・インスタンスの監視と削除に関する項、およびアプリケーション・ホームページからのSOAコンポジット・アプリケーション・インスタンスの監視と削除に関する項を参照してください。

53.4 Oracle SOAコンポーザからのコンポジット・センサーの実行時の作成および管理

SOAコンポジット・アプリケーションを再デプロイせずに、Oracle SOAコンポーザからコンポジット・センサーの作成、更新および削除を実行時にできます。次の例では、コンポジット・センサーを作成する方法を説明します。コンポジット・センサーに対する変更は、パッチを介して新しいバージョンのコンポジットに継承できます。

コンポジット・センサーに重複する名前を使用する場合の問題について理解していることを確認してください。詳細は、「重複するコンポジット・センサー名に関する必知事項」を参照してください。

Oracle SOAコンポーザから実行時にコンポジット・センサーを作成および管理する手順は、次のとおりです。

1. Oracle SOAコンポーザにログインします。

http://host:soa_server_port/soa/composer

2. 左側のナビゲータを展開し、変更を行うコンポジットをダブルクリックします。図53-12に詳細を示します。

図53-12 Oracle SOAコンポーザ

3. 「セッションの作成」をクリックします。

ページがリフレッシュされ、「追加」、「編集」、および「削除」の各アイコンが表示されます。

4. 「追加」アイコンをクリックして、次のオプションを選択します。

- サービス・センサーの作成: サービス・バインディング・コンポーネントのコールからデータを取得します。

- 参照センサーの作成: 参照バインディング・コンポーネントのコールからデータを取得します。

- イベント・センサーの作成: ビジネス・イベントにサブスクライブしたサービス・コンポーネントからデータを取得します。

この例では、サービス・バインディング・コンポーネントのコールからデータを取得するので「サービス・センサーの作成」を選択します。図53-13に詳細を示します。

図53-13 コンポジット・センサーの作成

「コンポジット・センサーの作成」ダイアログが表示されます。

5. 「式」セクションの「編集」アイコンをクリックして、次のオプションを選択します。

- 変数: 変数に対する式の値を作成する場合に選択します。

- 式: XPath式を作成するための「式ビルダー」ダイアログを起動する場合に選択します。このアクションは、常に値を文字列として取得します。

- プロパティ: 正規化されたメッセージ・ヘッダー・プロパティに対する式の値を作成する場合に選択します。これらは、invokeアクティビティ、receiveアクティビティ、replyアクティビティ、scopeアクティビティのOnEventブランチ(BPEL 2.0の場合)、およびpickアクティビティとscopeアクティビティ(BPEL 2.0の場合)のonMessageブランチの「プロパティ」タブの下に表示される同じプロパティです。

この例では、XPath式を作成するために「式」を選択します。

図53-14に詳細を示します。

図53-14 「コンポジット・センサーの作成」ダイアログのXPath式の選択

変数、式およびヘッダーのプロパティの選択項目は、表53-1 で説明したOracle JDeveloperの「コンポジット・センサーの作成」ダイアログと同じです。

「式ビルダー」ダイアログが表示されます。

6. XPath式を作成し、「OK」をクリックします。作成したカスタムXPath式を選択することもできます。

「コンポジット・センサーの作成」ダイアログに戻ります。

7. このコンポジット・センサーをOracle Enterprise Manager Fusion Middleware ControlのSOAコンポジット・アプリケーションの「フロー・インスタンス」ページで検索およびトラッキング可能なフィールドにするために、図53-15 の「Enterprise Manager」チェック・ボックスを選択して、「OK」をクリックします。このチェック・ボックスを選択しない場合は、コンポジット・センサーは検索可能になりません。

図53-15 コンポジット・センサーの作成

新しいコンポジット・センサーが表示されます。表示内容には、センサー名、センサーの定義を含むコンポーネントのタイプと名前、センサーに対して定義されたXPath式またはフィルタ、実行時センサー・データのストレージ・ロケーション(Enterprise ManagerまたはJMSキューとトピック)、およびJMSターゲットが含まれます。図53-16に詳細を示します。

図53-16 Oracle SOAコンポーザのコンポジット・センサー

8. 「保存」をクリックします。

9. 右上隅にある「パブリッシュ」をクリックして、このセッションをパブリッシュします。図53-17に詳細を示します。

図53-17 「パブリッシュ」ボタン

10. プロンプトが出されたらセッションのオプションの説明を入力して、「OK」をクリックします。

コンポジット・センサーは、デプロイされたSOAコンポジット・アプリケーション内で自動的に実行されます。

11. Oracle Enterprise Manager Fusion Middleware Controlの「Webサービスのテスト」ページに進んで、新規インスタンスを起動します。「Webサービスのテスト」ページの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAコンポジット・アプリケーションのテスト・インスタンスの開始に関する項を参照してください。

12. コンポジット・センサーを含むSOAコンポジット・アプリケーションの新規インスタンスを作成して(この例では、名前はloanAmount)、「起動」をクリックします。

13. SOAインフラストラクチャの「フロー・インスタンス」ページに進みます。

14. 「検索オプション」セクションの「フロー・インスタンス」部分の「センサー名」フィールドで、追加したコンポジット・センサーを指定します。図53-18に詳細を示します。

図53-18 検索可能フィールド

15. 「検索」をクリックします。

16. 「検索結果」テーブルでSOAコンポジット・センサーのインスタンスを選択して、「詳細の表示」をクリックします。

インスタンスの詳細は、ページ下部にある「フォルト」、「コンポジット・センサー値」、「コンポジット」および「リシーケンス・グループ」の各タブに表示されます。

17. 「コンポジット・センサー値」タブをクリックします。

このタブには、選択したビジネス・フロー内で検出されたコンポジット・センサーの値が表示されます。

- 名前: コンポジット・センサー名を表示します(この例では、loanAmount)。

- 値: コンポジット・センサーに割り当てられた値を表示します。

- 場所: コンポジット・センサーが定義されているサービス・バインディング・コンポーネント、参照バインディング・コンポーネント、またはサービス・コンポーネントが表示されます。

- コンポジット: コンポジット・センサーが定義されているSOAコンポジット・アプリケーションが表示されます。

18. コンポジット・センサーを編集または削除する場合は、図53-16 に示すOracle SOAコンポーザに戻って、「セッションの作成」をクリックします。

ページが再びリフレッシュされ、「追加」、「編集」、および「削除」の各アイコンが表示されます。

19. Oracle WebLogic Server起動スクリプト・システム・プロパティoracle.soacomposer.composite.showSensorXmlFilesを設定すると、ページの下部に「センサーXMLファイルを表示します」ボタンが表示されます。

20. このプロパティをクリックすると、sensor.xmlおよびsensor-action.xmlの内容が表示されます。この機能は、これら両方をテストして、意図したとおりになっているか確認するために便利です。

このSOAコンポジット・アプリケーションを後でOracle JDeveloperにインポートする場合は、Oracle SOAコンポーザの実行時に作成されたコンポジット・センサーが表示されます。

53.4.1 Oracle SOAコンポーザでのコンポジット・センサーの変更の表示に関する必知事項

Oracle SOAコンポーザでコンポジット・センサーを追加または削除した場合は、変更を確認するには、「コンポジット・センサー」表の上にあるそのプロジェクトのタブを閉じてから再度開く必要があります。次に例を示します。

1. コンポジット・センサーでSOAコンポジット・アプリケーションを作成およびデプロイします(この例では、p1という名前です)。

2. Oracle SOAコンポーザにログインして、ナビゲータでコンポジットを選択します。

p1コンポジット・センサーが表示されます。

3. コンポジットに追加のコンポジット・センターを作成し(この例では、p2という名前)、再デプロイします。

4. Oracle SOAコンポーザのナビゲータ・ツリーで、「リフレッシュ」ボタンをクリックして、コンポジットを選択します。

コンポジット・センサーp1のみが表示され、p2は表示されません。

5. 「コンポジット・センサー」ページ上部のプロジェクトのタブを閉じ(図53-19 を参照)、ナビゲータでコンポジットを選択して再度開きます。

図53-19 「コンポジット・センサー」ページの「コンポジット」タブ

これによって、コンポジット・センターp1とp2が表示されるようになります。

54 動的ビジネス・プロセスの作成

この章では、2レイヤーのビジネス・プロセス管理(BPM)の使用方法について説明します。2レイヤーのBPMを使用すると、動的ビジネス・プロセスを作成できます。動的ビジネス・プロセスの実行は、設計時に事前定義された要素ではなく、そのビジネス・プロセスが実行されるコンテキストの要素に基づいています。このような要素の例には、顧客のタイプ、地理的位置、チャネルなどがあります。

具体的に説明するために、様々なプロセスを使用してマルチチャネル・バンキングを実行するアプリケーションを使用していると仮定します。このシナリオでは、各プロセスの実行は、特定のプロセス・インスタンスごとのチャネルに基づいています。

この章の内容は次のとおりです。

- 2レイヤーのビジネス・プロセス管理の概要

- phaseアクティビティの作成

- 動的ルーティング・デシジョン表の作成

54.1 2レイヤーのビジネス・プロセス管理の概要

2レイヤーのBPMを使用すると、レイヤー・アプローチを使用してビジネス・プロセスをモデル化できます。このモデルの第1レベルは、ビジネス・プロセスに関する抽象的な仕様です。第1レベルのプロセスのアクティビティは、第2レベルのプロセスまたはサービスに作業を委任します。図54-1 に、この動作を示します。

図54-1 2レイヤーのBPM

図54-1 では、ビジネス・プロセスのPhase Iアクティビティは、その作業を対応するレイヤーIIのプロセスのタスク1.1、タスク1.2またはタスク1.3のいずれかに委任できます。

2レイヤーのBPM機能を使用すると、重要な要素(つまり、phaseアクティビティ)を宣言的に作成できます。

Oracle Business Rulesのデザインタイムおよびランタイム機能を使用すると、ビジネス・プロセスを再デプロイせずに、さらにチャネルを動的に追加できます。実行時デザインタイムでは、実行時に複数のルール(複数の列)を動的ルーティング・デシジョン表に追加できます。実行中にビジネス・プロセス・インスタンスはそれらの新規ルールを考慮し、最終的にリクエストを別のチャネルにルーティングします。

また、Oracle Business Rulesの実行時デザインタイム機能を使用すると、phaseアクティビティから起動されるサービスのエンドポイント参照を別のサービスを指し示すように変更できます。

注意:

Oracle SOAコンポーザとOracle Business Rules SDKを通じて、Oracle Business Rulesの実行時デザインタイム機能を使用できます。

Oracle SOAコンポーザとOracle Business Rules SDKの使用の詳細は、次を参照してください。

- Oracle Business Process Managementを使用したビジネス・ルールの設計

- Oracle Business Rules Java APIリファレンス

54.2 phaseアクティビティの作成

2レイヤーのBPMでは、フェーズはBPELプロセスのレベル1アクティビティです。これは、既存の上位レベルのOracle Business Rulesおよびヒューマン・タスクBPELアクティビティを補完します。

Oracle BPELデザイナで、phaseアクティビティをプロセスに宣言的に追加するには、「コンポーネント」ウィンドウの「Oracle Extensions」セクションからこのアクティビティをプロセス・モデルにドラッグ・アンド・ドロップします。図54-2に詳細を示します。

図54-2 Oracle BPELデザイナでのphaseアクティビティ

注意:

参照WSDL(レイヤー2またはコールした参照)には、自動作成されるフェーズ参照と同じ抽象的なWSDLが必要です。

54.2.1 phaseアクティビティの作成方法

コンポジット・アプリケーションのphaseアクティビティは、必要な変数を作成した後に作成します。

phaseアクティビティを作成する手順は、次のとおりです。

1. phaseアクティビティをダブルクリックします。

2. 「名前」フィールドに、値を入力します。

3. 「入力変数および出力変数」セクションで、入出力変数を追加する「追加」アイコンを選択します。

4. 「入力変数の追加」を選択します。変数を選択するためのダイアログが表示されます。

5. 既存の変数を選択するか、「変数」フォルダを選択し、「追加」アイコンをクリックして、新規変数を作成します。

6. 「OK」をクリックします。変数が移入された状態の「Phase」ダイアログが表示されます。

7. 「入力変数および出力変数」アイコンから「出力変数の追加」を選択します。変数を選択するためのダイアログが表示されます。既存の変数を選択するか、「変数」フォルダを選択し、「追加」アイコンをクリックして新規変数を作成します。

8. 「OK」をクリックします。入出力変数名が移入された状態の「Phase」ダイアログが表示されます。「OK」をクリックします。Oracle BPELデザイナにBPELプロセスが表示されます。

9. 「ファイル」メニューから「すべて保存」を選択します。

10. BPELプロセスを閉じます。

11. Oracle BPELデザイナの上の「composite_name」リンク(composite.xmlファイル)をクリックします。SOAコンポジット・エディタが表示されます。

54.2.2 phaseアクティビティ作成時の処理内容

phaseアクティビティを作成すると、表54-1 に記載されているアーティファクトが作成されます。

表54-1 phaseアクティビティとともに作成されるアーティファクト

アーティファクト

説明

BPELスコープ

phaseアクティビティをドロップしたBPELプロセス内の場所に、新しいBPELスコープが作成されてBPELプロセスに挿入されます。スコープには、phaseアクティビティの名前が指定されます。スコープ内にはいくつかの標準BPELアクティビティが作成されます。最も重要なアクティビティは、Oracle MediatorへのinvokeアクティビティとOracle Mediatorからのreceiveアクティビティです。

Oracle Mediatorコンポーネント

BPELプロセス・サービス・コンポーネントのSOAコンポジット・アプリケーションとともに、新しいOracle Mediatorサービス・コンポーネントが作成されます。Oracle Mediatorサービス・コンポーネントは、BPELコンポーネントのphaseアクティビティに接続されます。このBPELコンポーネントは、プロセス・モデル内でphaseアクティビティがドロップされたレベル1のBPELプロセスを構成するコンポーネントです。Oracle Mediatorサービス・コンポーネントの入出力は、phaseアクティビティの入出力によって定義されます。

Oracle Mediatorプラン(Oracle Mediatorサービス・コンポーネントの処理命令)は非常に単純です。処理命令の作成はOracle Business Rulesサービス・コンポーネントに委任されます。

Oracle Business Rulesコンポーネント

BPELプロセス・サービス・コンポーネントのSOAコンポジット・アプリケーション内に、新しいOracle Business Rulesサービス・コンポーネントが作成され、BPELプロセス・サービス・コンポーネントのphaseアクティビティに関連付けられているOracle Mediatorコンポーネントに接続されます。Oracle Business Rulesサービス・コンポーネントには、ルール・ディクショナリが含まれています。ルール・ディクショナリには、ファクト・タイプ、ルールセット、ルール、デシジョン表や同様のアーティファクトなど、Oracle Business Rulesエンジン・アーティファクトのメタデータが含まれています。ルール・ディクショナリは、Oracle Business Rulesサービス・コンポーネントの作成過程で、次のデータを使用して事前に初期化されます。

- ファクト・タイプ・モデル: ルールのモデル化に使用するデータ・モデル。ルール・ディクショナリには、phaseアクティビティの入力に対応するファクト・タイプ・モデルと、Oracle Mediatorサービス・コンポーネントとOracle Business Rulesサービス・コンポーネント間の規定の一部として必要な固定データ・モデルの一部が移入されます。

- ルールセット: ルールのコンテナであり、ルールのグループ化メカニズムとして使用されます。ルールセットはサービスとして公開できます。1つのルールセットがルール・ディクショナリ内に作成されます。

- デシジョン表: Oracle Business Rulesから見ると、デシジョン表は、ルールの条件およびアクション部分のファクト・タイプ・モデルの要素が同じルールの集合であるため、それらのルールは表形式で表示できます。新規デシジョン表はルールセット内に作成されます。

- デシジョン・サービス: ルールセットをOracle Business Rulesサービス・コンポーネントのサービスとして公開するために作成されます。Oracle Mediatorでは、サービス・インタフェースを使用してデシジョン表を評価します。

54.2.3 phaseアクティビティを作成した場合の実行時の処理内容

phaseアクティビティの入力は、実行時に動的ルーティング・デシジョン表を評価するために使用されます。評価は、phaseアクティビティの特定のデシジョン・コンポーネントによって実行されます。この評価の結果が、Oracle Mediatorに対する指示になります。Oracle Mediatorは、デシジョン・コンポーネントからの指示に基づいて、リクエストをサービスにルーティングします。

注意:

現在のリリースでは、非同期のphaseアクティビティがサポートされています。同期または一方向のphaseアクティビティはサポートされていません。

54.2.4 phaseアクティビティの作成に関する必知事項

phaseアクティビティを作成する場合は、次の事項について理解している必要があります。

- デシジョン・サービスで構成または作成する必要のあるルール。これは、ルールの評価に使用するペイロードのデータに基づきます。

- デシジョン・サービスで作成した各ルールがtrueと評価されたときに起動する必要のある、対応するエンドポイントURLを認識している必要があります。Oracle Mediatorでは、このエンドポイントURLを使用してレイヤー2のサービスを起動します。

注意:

ペイロードに対するトランスフォーメーション、割当てまたは検証は実行できません。

54.3 動的ルーティング・デシジョン表の作成

動的ルーティング・デシジョン表は、Oracle Business Rulesによって評価されるデシジョン表です。phaseアクティビティの入力データに対して条件が評価されます。この評価の結果が、Oracle Mediatorに対するルーティング指示になります。

54.3.1 動的ルーティング・デシジョン表の作成方法

phaseアクティビティを作成すると、ウィザードによってOracle JDeveloperのOracle Business Rulesデザイナが起動され、動的ルーティング・デシジョン表を編集できるようになります。図54-3 に、Oracle Business Rulesデザイナ内のデシジョン表のサンプルを示します。

図54-3 デシジョン表のサンプル

レベル2のプロセス・フェーズのモデリング中には情報を空にしておき、Oracle SOAコンポーザを使用してレベル1のプロセスをデプロイした後で完了できます。

動的ルーティング・デシジョン表を作成および編集すると、図54-4 に示すように、新規のレベル1のphaseアクティビティがOracle JDeveloperのBPELプロセスに表示されます。

図54-4 Oracle JDeveloperでの完成したレベル1フェーズ

54.3.2 動的ルーティング・デシジョン表作成時の処理内容

動的ルーティング・デシジョン表を作成することで、着信ペイロードに適用される条件を動的に評価し、対応するルーティング・ルールをOracle Mediatorに提供するデシジョン・サービスが構成されます。その後、Oracle Mediatorは、これらのルールをレイヤー2のサービスの起動時に実行します。

動的ルーティング・デシジョン表を作成すると、具体的には、設計時に次の処理が行われます。

- 新しいデシジョン・コンポーネントがプロジェクトのコンポジットに作成されます。

- 新しいルール・ディクショナリがコンポジット・プロジェクトのディレクトリに作成されます。

- ルール・ディクショナリに、フェーズ入力のデータ・モデルを反映するデータ・モデルが移入されます。つまり、フェーズ入力のXMLスキーマがルール・ディクショナリにインポートされます。

55 Spring Frameworkを使用したSOAコンポジット・アプリケーションへの統合

この章では、Spring Frameworkを使用して、Javaインタフェースを使用するコンポーネントをSOAコンポジット・アプリケーションに統合する方法について説明します。Oracle SOA Suiteでは、Oracle WebLogic ServerのWebLogic Service Component Architecture (SCA)で提供されるSpring Framework機能を使用します。また、この章では、Javaインタフェースを使用するコンポーネントとWSDLファイルを使用するコンポーネントを同じSOAコンポジット・アプリケーション内に統合する方法についても説明します。また、JavaクラスをXMLデータにマップするための、Java Architecture for XML Binding (JAXB)およびEclipseLink O/X-Mapper (OXM)の使用についても説明します。

この章の内容は次のとおりです。

- Springサービス・コンポーネントの概要

- 同じSOAコンポジット・アプリケーション内でのJavaベース・コンポーネントとWSDLベース・コンポーネントの統合

- Oracle JDeveloperでのSpringサービス・コンポーネントの作成

- グローバルSpringコンテキストを介したカスタムSpring Beanの定義

- 事前定義済のSpring Beanの使用

- JAXBおよびOXMのサポート

- Springサービス・コンポーネントによるGroovyおよびAspectjクラスの構成

- Springエラーのトラブルシューティング

Oracle SOA Suiteで使用するWebLogic SCA機能の詳細は、『Oracle WebLogic Server WebLogic SCAアプリケーションの開発』を参照してください。

Spring Frameworkの使用方法の例は、Oracle SOA Suiteのサンプルのサイトを参照してください。

55.1 Springサービス・コンポーネントの概要

Spring Frameworkは、様々なタイプのサービスを簡単に使用できるようにする軽量のコンテナです。この軽量のコンテナは、特定のタイプのコンポーネントではなく、すべてのJavaBeanを受け入れることができます。

WebLogic SCAによって、ユーザーはSpring Frameworkを使用して、plain old Java object (POJO)を使用するJavaアプリケーションを作成し、コンポーネントをSCAサービスおよび参照として公開できます。SCAの観点では、WebLogic Spring Framework SCAアプリケーションは、各クラスをSCAサービスおよび参照と結び付けるSpring SCA コンテキスト・ファイルとPOJOの集合です。

Spring Frameworkを使用すると、サービス・コンポーネントを作成し、依存関係インジェクション機能を使用してSOAコンポジット・アプリケーション内に接続できます。Spring Framework機能は、SCAによって次のように拡張できます。

- Spring Beanを、他のSCAコンポーネントまたはリモート・クライアントがアクセスできるSCAコンポーネント・サービスとして公開します。

- 他のコンポーネントのサービスに接続されたサービス参照のSpring Beanを提供します。

すべてのサービス・コンポーネントと同様に、Springコンポーネントはcomposite.xmlファイルで定義されます。composite.xmlファイルで定義されたSpringコンポーネントには、binding.javaを使用するサービスおよび参照要素があります。

サービスはBeanによって実装され、Springコンテキスト・ファイルでターゲット設定されます。参照は、実行時に暗黙的(または仮想的)なBeanとしてSpringコンテキスト・ファイルで提供されます。

Javaインタフェースを使用してEnterprise JavaBeans (EJB)をSOAコンポジット・アプリケーションに統合することもできます(SDOパラメータは不要です)。詳細は、「Enterprise JavaBeansとコンポジット・アプリケーションの統合」を参照してください。

55.2 同じSOAコンポジット・アプリケーション内でのJavaベース・コンポーネントとWSDLベース・コンポーネントの統合

SOAコンポジット・エディタを使用して、Javaインタフェースを使用するコンポーネントとWSDLファイルを同じSOAコンポジット・アプリケーション内で統合できます。この統合によって、たとえば、Springサービス・コンポーネントでOracle BPEL Process Managerを起動したり、Oracle Mediatorサービス・コンポーネントでEJBを起動することができます。

次のタイプのコンポーネント統合がサポートされています。

- JavaコンポーネントからWSDLコンポーネント
Javaインタフェース(EJBサービス、Springサービス・コンポーネントなど)からJavaインタフェースをサポートしていないコンポーネント(Oracle Mediator、Oracle BPEL Process Managerなど)にワイヤをドラッグすると、コンポーネント・インタフェースに対して互換性のあるWSDLが生成されます。

- WSDLコンポーネントからJavaコンポーネント
WSDLインタフェースから、WSDLファイルをサポートしていないコンポーネント(Springサービス・コンポーネントなど)にワイヤをドラッグすると、互換性のあるJavaインタフェースが自動的に生成されます。さらに、既存のWSDLインタフェースを既存のJavaインタフェースに接続することも可能です。この場合、WSDLインタフェースとJavaインタフェース間の互換性はチェックされません。互換性が適正であることを確認する必要があります。

- JavaコンポーネントからJavaコンポーネント
Springサービス・コンポーネントの作成時には、Javaインタフェース・ベースのEJBサービス・バインディング・コンポーネントと参照バインディング・コンポーネントを使用して、Springサービス・コンポーネントを自動的に構成できます。WSDLファイルは不要です。

55.2.1 JavaベースおよびWSDLベースの統合例

2つのサービス・コンポーネント(またはサービス・コンポーネントとバインディング・コンポーネント)を接続するときは、接続の両端にインタフェースを定義します。XMLを使用する場合、これらのインタフェースで同じWSDL定義を指定する必要があり、composite.xmlファイルのinterface.wsdlを使用して定義されます。

JAX-WSの観点からは、(interface.javaで定義された)JavaインタフェースをWSDLインタフェースに接続すると、2つのインタフェースは互換性があるとみなされます。通常、これはOracle JDeveloperで規定され自動化されます。

注意:

この項で説明するcomposite.xmlおよびSpringコンテキスト・ファイルの作成および変更には、「設計」ビューでOracle JDeveloperのみを使用します。これらのファイルは、「ソース」ビューで直接編集しないでください。次の各例は、JavaインタフェースとWSDLファイルをSOAコンポジット・アプリケーションに統合する方法を示しています。Oracle JDeveloperを使用してこの機能を実現する方法については、この章の後続の項で説明します。

たとえば、次の例に示すように、サービスのJavaインタフェースがあるとします。

public interface PortfolioService {
public double getPorfolioValue(String portfolioId);
}

実装では、別のコンポーネント(外部Webサービス、EJBなど)によって実装された追加のStockQuoteサービスを使用できるとします。次の例に詳細を示します。

public interface StockQuote {
public double getQuote (String symbol);
}

Spring Frameworkのcomposite.xmlファイルには、interface.java定義を使用するPortfolioServiceサービスおよびStockQuoteサービスがリストされます。次の例に詳細を示します。

<component name="PortfolioComp">
<implementation.spring src="Spring/PortfolioComp.xml"/>
<componentType>
<service name="PortfolioService">
<interface.java interface="com.bigbank.PortfolioService"/>
</service>
<reference name="StockService">
<interface.java interface="com.bigbank.StockQuote"/>
</reference>
</componentType>
</component>

実装クラスによって、サービス・インタフェースが実装され、参照インタフェースのセッターが提供されます。次の例に詳細を示します。

public class PortfolioServiceImpl implements PortfolioService {
StockQuote stockQuoteRef;

public void setStockService (StockQuote ref) {
stockQuoteRef = ref;
}

public double getPorfolioValue(String portfolioId) {
//--  use stock service
//--  return value
}
}

Springコンテキスト・ファイルは、サービスおよび参照をコールアウトして実装にバインドします。次の例に詳細を示します。

<beans ...>
<sca:service  name="PortfolioService" type="com.bigbank.PortfolioService"
target="impl">
</sca:service>

<sca:reference  name="StockService" type="com.bigbank.StockQuote">
</sca:reference>

<bean id ="impl" class ="com.bigbank.PortfolioServiceImpl">
<property name="stockService" ref="StockService"/>
</bean>
</beans>

55.2.2 Spring Frameworkでのコールバックの使用

Oracle SOA Suiteでは、interface.wsdlおよびinterface.javaの両方でコールバックを使用します。ただし、Spring Frameworkにはコールバックの概念が存在しません。Oracle SOA Suiteのサービスおよび参照の場合、コールバックは、interface.wsdlの2番目のポート・タイプ、またはinterface.javaの2番目のJava名として(メタデータに)指定されます。Springメタデータには、sca:servicesおよびsca:referencesのみが含まれ、コールバックを指定する方法がありません。

Springでコールバックを設計するには、特定の名前を指定したsca:servicesおよびsca:referencesを用意する必要があります。命名規則のsomeServiceおよびsomeServiceCallbackを使用してsca:serviceおよびsca:referenceの両方を作成すると、Oracle SOA Suiteでは、この命名規則が認識され、コールバックがある単一のサービスまたは参照が作成されます。

たとえば、Oracle JDeveloperのSpringエディタを使用して、Springコンテキスト・ファイルに次の例に示すような構文を作成するとします。

<sca:service  name="StockService"
type="oracle.integration.platform.blocks.java.callback.StockService"
target="impl" />
<sca:reference  name="StockServiceCallback"
type="oracle.integration.platform.blocks.java.callback.StockServiceReply" />

Oracle SOA Suiteでは、次の例に示すように、単一のサービスを自動的に作成します。

<service name="StockService">
<interface.java
interface="oracle.integration.platform.blocks.java.callback.StockService"
callbackInterface="oracle.integration.platform.blocks.java.callback.StockServiceRe
ply"/>
</service>

SOAコンポジット・エディタで、コールバック・インタフェースがあるSpringのinterface.javaをWSDLコンポーネント(Oracle BPEL Process Manager、Oracle Mediatorなど)にドラッグすると、2つのポート・タイプがあるWSDLが生成されます(技術的にはラッパーWSDLと呼ばれ、それぞれ単一のポート・タイプがある別の2つのWSDLをインポートするWSDLです)。

コールバックがあるWSDLインタフェースまたはJavaインタフェースをSpringサービス・コンポーネントにドラッグすると、SOAコンポジット・エディタには単一のインタフェースが表示されます。ただし、Springエディタには、同じ命名規則(someServiceおよびsomeServiceCallback)を使用するsca:serviceおよびsca:referenceの両方が表示されます。

55.3 Oracle JDeveloperでのSpringサービス・コンポーネントの作成

この項では、Oracle JDeveloperでSpringサービス・コンポーネントを作成し、そのコンポーネントを次のように接続する方法について説明します。

- Javaインタフェース・ベースのEJBサービスおよび参照への接続(JavaからJavaへの統合)

- Oracle Mediatorサービス・コンポーネントへの接続(JavaからWSDLへの統合)

55.3.1 Oracle JDeveloperでのSpringサービス・コンポーネントの作成方法

Oracle JDeveloperでSpringサービス・コンポーネントを作成する手順は、次のとおりです。

1. 図55-1 に示すように、「コンポーネント」ウィンドウで、「Spring」サービス・コンポーネントをにドラッグします。

図55-1 「Springコンテキスト」サービス・コンポーネント

「Springの作成」ダイアログが表示されます。

2. 「名前」フィールドに、Springサービス・コンポーネントの名前を入力します。この名前は、コンポーネント名とSpringコンテキスト・ファイル名の両方になります。図55-2に詳細を示します。
既存のコンテキストの使用を選択し、「参照」をクリックして、既存のSpringファイルを選択することもできます。たとえば、Oracle JDeveloperで作成されたがOracle SOA Suiteの外部にあるSpringコンテキストをインポートできます。別のプロジェクトから参照して選択したSpringコンテキストは、SOAプロジェクトにコピーされます。

図55-2 「Springの作成」ダイアログ

注意:

WebLogic SCAのスタンドアロンのSpringバージョンも使用可能です。通常、このバージョンはOracle SOA Suiteの外部で使用されます。このバージョンにアクセスするには、Springエディタ内での作業中に、「コンポーネント」ウィンドウからSpring 2.5 JEEを選択します。

3. 「OK」をクリックします。
SOAコンポジット・エディタにSpringアイコンが表示されます。

4. コンテンツが自動的に表示されない場合は、このアイコンをダブルクリックすると、SpringエディタにSpringコンテキストの内容が表示されます。

5. 「コンポーネント」ウィンドウで、ドロップダウン・リストから「WebLogic SCA」を選択します。
リストがリフレッシュされ、図55-3 に示すように、選択内容が表示されます。

図55-3 「WebLogic SCA」メニュー

6. 「サービス」アイコンをSpringエディタにドラッグします。
「サービスの挿入」ダイアログが表示されます。

7. 表55-1 に示すフィールドに入力して、ターゲットBeanおよびJavaインタフェースを定義します。

表55-1 「サービスの挿入」ダイアログ

フィールド

説明

名前

名前を入力します。

ターゲット

ターゲットBeanを入力します。このアクションにより、Beanをサービスとして公開できます。

注意: このターゲットが存在していることを確認してください。このターゲットの存在をチェックする検証機能はサポートされていません。

タイプ

Javaインタフェースを入力します。

完了すると、「サービスの挿入」ダイアログは図55-4 のようになります。

図55-4 「サービスの挿入」ダイアログ

8. 「OK」をクリックします。
ターゲットBeanは、Springコンテキストでサービス・インタフェースになります。

<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:util="http://www.springframework.org/schema/util"
xmlns:jee="http://www.springframework.org/schema/jee"
xmlns:lang="http://www.springframework.org/schema/lang"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:sca="http://xmlns.oracle.com/weblogic/weblogic-sca"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/tool
http://www.springframework.org/schema/tool/spring-tool.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop.xsd
http://www.springframework.org/schema/cache
http://www.springframework.org/schema/cache/spring-cache.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/task
http://www.springframework.org/schema/task/spring-task.xsd
http://www.springframework.org/schema/jee
http://www.springframework.org/schema/jee/spring-jee.xsd
http://www.springframework.org/schema/lang
http://www.springframework.org/schema/lang/spring-lang.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx.xsd
http://www.springframework.org/schema/jdbc
http://www.springframework.org/schema/jdbc/spring-jdbc.xsd
http://www.springframework.org/schema/jms
http://www.springframework.org/schema/jms/spring-jms.xsd
http://www.springframework.org/schema/oxm
http://www.springframework.org/schema/oxm/spring-oxm.xsd
http://www.springframework.org/schema/mvc
http://www.springframework.org/schema/mvc/spring-mvc.xsd
http://xmlns.oracle.com/weblogic/weblogic-sca META-INF/weblogic-sca.xsd">
<!--Spring Bean definitions go here-->
<sca:service name="scaserv1" target="cp"
type="oracle.mypackage.myinterface"/>
</beans>

Springエディタを閉じてSOAコンポジット・エディタに戻ると、図55-5 に示すように、Springサービス・コンポーネントの左側にハンドルが追加されています。

図55-5 サービス・ハンドル

9. Springエディタに戻ります。

10. 図55-3 に示すリストから、「参照」アイコンをSpringエディタにドラッグします。
「参照の挿入」ダイアログが表示されます。

11. 表55-2 に示すようにダイアログに入力して、「OK」をクリックします。

表55-2 「参照の挿入」ダイアログ

フィールド

説明

名前

名前を入力します。

タイプ

Javaインタフェースを入力します。

完了すると、Springエディタに、Springコンテキストのサービスおよび参照が表示されます。

<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:util="http://www.springframework.org/schema/util"
xmlns:jee="http://www.springframework.org/schema/jee"
xmlns:lang="http://www.springframework.org/schema/lang"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:sca="http://xmlns.oracle.com/weblogic/weblogic-sca"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/tool
http://www.springframework.org/schema/tool/spring-tool.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop.xsd
http://www.springframework.org/schema/cache
http://www.springframework.org/schema/cache/spring-cache.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/task
http://www.springframework.org/schema/task/spring-task.xsd
http://www.springframework.org/schema/jee
http://www.springframework.org/schema/jee/spring-jee.xsd
http://www.springframework.org/schema/lang
http://www.springframework.org/schema/lang/spring-lang.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx.xsd
http://www.springframework.org/schema/jdbc
http://www.springframework.org/schema/jdbc/spring-jdbc.xsd
http://www.springframework.org/schema/jms
http://www.springframework.org/schema/jms/spring-jms.xsd
http://www.springframework.org/schema/oxm
http://www.springframework.org/schema/oxm/spring-oxm.xsd
http://www.springframework.org/schema/mvc
http://www.springframework.org/schema/mvc/spring-mvc.xsd
http://xmlns.oracle.com/weblogic/weblogic-sca META-INF/weblogic-sca.xsd">
<!--Spring Bean definitions go here-->
<sca:service name="scaserv1" target="cp"
type="oracle.mypackage.myinterface"/>
<sca:reference name="scaref1" type="external.bean.myInterface"/>
</beans>

12. 図55-6 に示すように、Springコンテキスト・ファイルを閉じます。

図55-6 Springコンテキスト・ファイル

図55-7 に示すように、Springサービス・コンポーネントの右側にハンドルが追加されています。

図55-7 参照ハンドル

13. 図55-8 に示すように、左側のハンドルを「公開されたサービス」スイムレーンにドラッグして、サービス・バインディング・コンポーネントを作成します。

図55-8 サービス・バインディング・コンポーネント

図55-9 に示すように、サービスをWebサービスとして公開するか、またはEJBサービスとして公開するかを選択するように求めるプロンプトが表示されます。

図55-9 作成するサービス・タイプ

- EJB: EJBサービスをJavaインタフェースから公開します。このオプションを選択した場合、WSDLファイルを使用する必要はありません。

- Webサービス: WebサービスをSOAP WSDLインタフェースから公開します。このオプションを選択すると、Springサービス・コンポーネントとの互換性を維持するために、JavaインタフェースからWSDLが生成されます。

14. このサービスをEJBサービスとして公開するか、またはWebサービスとして公開するかを選択します。「公開されたサービス」スイムレーンにサービスが自動的に作成され、Springサービス・コンポーネントに接続されます(この例では「EJB」が選択されています)。図55-10に詳細を示します。

図55-10 Springサービス・コンポーネントに接続されたEJBサービス・バインディング・コンポーネント

15. EJBサービスをダブルクリックすると、図55-11 に示すように、自動的に設定された構成が表示されます。この構成詳細は、ステップ7で「サービスの挿入」ダイアログに入力した値から作成されています。

図55-11 「公開されたサービス」スイムレーンの「EJBサービス」ダイアログ

16. 自動的に生成されたデフォルトのJNDI名を、環境に適用可能な名前に置き換えます。

17. ダイアログを閉じます。

18. Springサービス・コンポーネントの右側のハンドルを「外部参照」スイムレーンにドラッグして、参照バインディング・コンポーネントを作成します。
ステップ13で説明した内容と同じSpringタイプ・オプションのメッセージが表示されます。

19. この参照を公開するオプションを選択します。「外部参照」スイムレーンに参照が自動的に作成され、Springサービス・コンポーネントに接続されます(この例では「EJB」が選択されています)。図55-12に詳細を示します。

図55-12 Springサービス・コンポーネントに接続されたEJB参照バインディング・コンポーネント

20. EJB参照をダブルクリックすると、図55-13 に示すように、自動的に設定された構成が表示されます。この構成詳細は、ステップ11で「参照の挿入」ダイアログに入力した値から作成されています。

図55-13 「外部参照」スイムレーンの「EJB参照」ダイアログ

21. ダイアログを閉じて、図55-14 に示すようにSOAコンポジット・エディタに戻ります。

図55-14 Javaインタフェース・ベースのEJBサービスおよびEJB参照バインディング・コンポーネント

22. サービスの右ハンドル(図55-15 を参照)とSpringサービス・コンポーネントの左ハンドルの両方にカーソルを合せます(図55-16 を参照)。Javaインタフェースが表示されます。

図55-15 サービスのJavaインタフェース

図55-16 Springサービス・コンポーネントのJavaインタフェース

23. Springサービス・コンポーネントの右ハンドル、および参照バインディング・コンポーネントの左ハンドルでも同様にカーソルを置いて、Javaインタフェースを表示します。

24. composite.xmlファイルの「ソース」ビューを選択して、同様の詳細を表示します。

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SOA Modeler version 12.1.3.0.0 at [5/16/14 3:05 AM].
-->
<composite name="Project1"
. . .
. . .
<service name="scaserv1">
<interface.java interface="oracle.mypackage.myinterface"/>
<binding.ejb uri="scaserv1_ejb_ep" ejb-version="EJB3"/>
</service>
<property name="productVersion" type="xs:string"
many="false">12.1.3.0.0</property>
<property name="compositeID" type="xs:string"
many="false">4c07dbf0-5c01-450e-bde6-8c3866f45edc</property>
<component name="MySpring">
<implementation.spring src="Spring/MySpring.xml"/>
<componentType>
<service name="scaserv1">
<interface.java interface="oracle.mypackage.myinterface"/>
</service>
<reference name="scaref1">
<interface.java interface="external.bean.myInterface"/>
</reference>
</componentType>
</component>
<reference name="scaref1">
<interface.java interface="external.bean.myInterface"/>
<binding.ejb uri="scaref1_ejb_ep" ejb-version="EJB3"/>
</reference>
<wire>
<source.uri>scaserv1</source.uri>
<target.uri>MySpring/scaserv1</target.uri>
</wire>
<wire>
<source.uri>MySpring/scaref1</source.uri>
<target.uri>scaref1</target.uri>
</wire>
</composite>

25. Springサービス・コンポーネントの右ハンドルを、Javaインタフェース・ベースのEJB参照ではなく、XMLベースのコンポーネント(Oracle Mediatorなど)に接続すると、Oracle Mediatorの既存のWSDLインタフェースからJavaインタフェースが生成されます。次の手順で詳細を説明します。

a. 図55-17 に示すように、Springサービス・コンポーネントの右ハンドルをOracle Mediatorにドラッグします。

図55-17 Springサービス・コンポーネントとOracle Mediatorの統合

b. Oracle MediatorのWSDLファイルから互換性のあるインタフェースが作成されたことを確認するプロンプトが表示された場合は、「OK」をクリックします。

図55-18 Oracle MediatorのWSDLファイルからのJavaファイル作成

JavaインタフェースとWSDLベース・コンポーネント間の接続をドラッグすると、(Javaインタフェース名に基づく)デフォルト名のWSDLファイルがすでに存在する場合、4つのオプションがプロンプトされます。接続の作成を取り消すには、「取消」をクリックします。図55-19に詳細を示します。

図55-19 既存のWSDLファイル

c. Springサービス・コンポーネントの右ハンドル(図55-20 を参照)とOracle Mediatorの左ハンドルの両方にカーソルを合せ(図55-21 を参照)、互換性のあるインタフェースを表示します。

図55-20 Springサービス・コンポーネントのインタフェース

図55-21 Oracle Mediatorのインタフェース

d. Springサービス・コンポーネントをダブルクリックすると、SpringエディタにSpringコンテキスト・ファイルの内容が表示されます。

<?xml version="1.0" encoding="windows-1252" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:util="http://www.springframework.org/schema/util"
xmlns:jee="http://www.springframework.org/schema/jee"
xmlns:lang="http://www.springframework.org/schema/lang"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:sca="http://xmlns.oracle.com/weblogic/weblogic-sca"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
http://www.springframework.org/schema/jee
http://www.springframework.org/schema/jee/spring-jee-2.5.xsd
http://www.springframework.org/schema/lang
http://www.springframework.org/schema/lang/spring-lang-2.5.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
http://www.springframework.org/schema/tool
http://www.springframework.org/schema/tool/spring-tool-2.5.xsd
http://xmlns.oracle.com/weblogic/weblogic-sca META-INF/weblogic-sca.xsd">
<!--Spring Bean defintions go here-->
<sca:service name="scaserv1" target="ep" type="oracle.mypackage.myinterface"/>
<sca:reference type="mediator1.project1.application4.com.oracle.xmlns.Execute_
ptt" name="Mediator1.Mediator1"/>
</beans>

注意:

- Javaインタフェースを使用するコンポーネントとWSDLファイルを使用するコンポーネントとをSOAコンポジット・エディタで統合する際に、特定のインタフェース・クラスがクラスパスになく(SCA-INF/libディレクトリにあるJARファイルを含む)、ソース・ファイルがSOAプロジェクトに存在する場合は、ソースを自動的にコンパイルするように要求されます。

- Javaインタフェースを使用するサービスとのBPELプロセスのパートナ・リンクを作成することもできます。パートナ・リンクの作成時に、「サービス・エクスプローラ」ダイアログでこのサービスのタイプを選択します。詳細は、「パートナ・リンクの概要」を参照してください。

55.3.2 JavaからWSDLへの変換時のJavaクラス・エラーに関する必知事項

JavaからWSDLへの変換が不正なJavaクラスにより失敗し、問題に対処するためJavaコードを変更した場合は、Oracle JDeveloperを再起動する必要があります。そうしないと、新規クラスが再ロードされないためにJavaからWSDLへの変換が失敗します。

55.4 グローバルSpringコンテキストを介したカスタムSpring Beanの定義

カスタムSpring Beanは、グローバルSpringコンテキスト定義を介して定義できます。この構成では、グローバル・レベルで1回のみ、これらのBeanを定義できます。

55.4.1 グローバルSpringコンテキストを介したカスタムSpring Beanの定義方法

グローバルSpringコンテキストを介してカスタムSpring Beanを定義する方法は、次のとおりです。

1. カスタムSpring Bean定義を次のファイルに追加します。

SOA_HOME/soa/modules/oracle.soa.ext_11.1.1/classes/
springse-extension-global-beans.xml

2. 対応するクラスをlibディレクトリ(JARファイルとして)またはクラス・ディレクトリ(JARファイルの抽出ファイルとして)に追加します。

SOA_HOME/soa/modules/oracle.soa.ext_11.1.1/lib | classes

詳細は、次のディレクトリにあるreadme.txtファイルを参照してください。

SOA_HOME/soa/modules/oracle.soa.ext_11.1.1

注意:

新しく追加されたSpring Beanを使用するにはサーバーを再起動する必要があります。

55.5 事前定義済のSpring Beanの使用

Oracle SOA Suiteには、次の事前定義済のSpring Beanがあります。

- headerHelperBean: ヘッダー・プロパティを取得および設定します。

- instanceHelperBean: 次の情報を取得および設定します。

- 現在実行中のフロー・インスタンスのインスタンスID。

- 現在実行中のコンポーネント・インスタンスのインスタンスID。

- コンポーネントが含まれているコンポジットの識別名(DN)。

- Springサービス・コンポーネントの名前。

- loggerBean: コンテキスト対応のロギング・メッセージの提供。

事前定義済のSpring Beanは、Springサービス・コンポーネントに自動的に挿入されます。ただし、Springコンテキスト・ファイル内にそのBeanへの参照を挿入することで事前定義済のSpring BeanをSOAコンポジット・アプリケーションに明示的に統合する必要があります。

Springコンテキスト・ファイル内のloggerBeanおよびheaderHelperBeanの参照方法の例は、「Springコンテキスト・ファイル内の事前定義済Spring Beanの参照方法」を参照してください。

55.5.1 headerHelperBeanのIHeaderHelperBean.javaインタフェース

次の例は、headerHelperBean BeanのIHeaderHelperBean.javaインタフェースを示しています。

package oracle.soa.platform.component.spring.beans;
/**
* Interface for getting and setting header properties.
* These properties will be set on the normalized message - and passed on
* to the respective reference that the local reference is wired to on
* composite level.
* <br/>
* To use this bean from within your context, declare property
* with ref="headerHelperBean". E.g.
* &lt;property name="headerHelper" ref="<b>headerHelperBean</b>"/>
*/
public interface IHeaderHelperBean
{
/**
* Get a property from the normalized message header. Note that these
* properties are defined, and are the same ones, one can get/set via
* mediator or bpel process
* @param pKey the property key, case sensitive
* @return the value, or null in case not found
*/
public String getHeaderProperty (String pKey);
/**
* Set a property on the normalized message header. Note that these
* properties are defined, and are the same ones, one can get/set via
* mediator or bpel process
* @param pKey the property key, case sensitive
* @param pValue the value to be set
*/
public void setHeaderProperty (String pKey, String pValue);
}

55.5.2 instancerHelperBeanのIInstanceHelperBean.javaインタフェース

次の例は、instanceHelperBean BeanのIInstanceHelperBean.javaインタフェースを示しています。

package oracle.soa.platform.component.spring.beans;

import oracle.integration.platform.instance.engine.ComponentInstanceContext;
/**
* Instancehelper Bean, gives access to composite / component + instance
information
* <br/>
* To use this bean from within your context, declare property
* with ref="instanceHelperBean". E.g.
* &lt;property name="instanceHelper" ref="<b>instanceHelperBean</b>"/>
*/
public interface IInstanceHelperBean
{
/**
* Returns the instance id of the composite instance currently running
* @return the composite instance id
*/
public String getCompositeInstanceId ();

/**
* Returns the instance id of the component instance currently running
* @return the component instance id
*/
public String getComponentInstanceId ();

/**
* Returns the composite dn containing this component
* @return the composite dn
*/
public String getCompositeDN ();

/**
* Returns the name of this spring component
* @return the component name
*/
public String getComponentName ();

}

55.5.3 loggerBeanのILoggerBean.javaインタフェース

次の例は、loggerBean BeanのILoggerBean.javaインタフェースを示しています。

package oracle.soa.platform.component.spring.beans;

import java.util.logging.Level;

/**
* Logger bean interface, messages will be logged as
* [&lt;composite instance id>/&lt;component instance id>] &lt;message>
* <br/>
* To use this bean from within your context, declare property
* with ref="loggerBean". E.g.
* &lt;property name="logger" ref="<b>loggerBean</b>"/>
*/
public interface ILoggerBean
{

/**
* Log a message, with Level.INFO
* @param message
*/
public void log (String message);

/**
* Log a message with desired level
* @param pLevel the log level
* @param message the message to log
*/
public void log (Level pLevel, String message);

/**
* Log a throwable with the desired level
* @param level the level to log with
* @param message the message
* @param th the exception (throwable) to log
*/
public void log (Level level, String message, Throwable th);

}

55.5.4 Springコンテキスト・ファイル内の事前定義済Spring Beanの参照方法

Springコンテキスト・ファイル内の事前定義済Beanへの参照を作成します。

Springコンテキスト・ファイル内の事前定義済Spring Beanを参照する方法は、次のとおりです。

1. Oracle JDeveloperの「ソース」ビューでSpringコンテキスト・ファイルを開きます。

2. 事前定義済BeanのloggerBeanおよびheaderHelperBeanへの参照を追加します。

<?xml version="1.0" encoding="windows-1252" ?>
. . .
. . .
<!--
The below sca:service(s) corresponds to the services exposed by the
component type file: SpringPartnerSupplierMediator.componentType
-->
<!-- expose the InternalPartnerSupplierMediator + EJB as service
<service name="IInternalPartnerSupplier">
<interface.java
interface="com.otn.sample.fod.soa.internalsupplier.IInternalPartnerSupplier"/>
</service>
-->
<sca:service name="IInternalPartnerSupplier"
target="InternalPartnerSupplierMediator"
type="com.otn.sample.fod.soa.internalsupplier.IInternalPartnerSupplier"/>
<!-- expose the InternalPartnerSupplierMediator + Mock as service
<service name="IInternalPartnerSupplierSimple">
<interface.java
interface="com.otn.sample.fod.soa.internalsupplier.IInternalPartnerSupplier"/>
</service>
-->
<sca:service name="IInternalPartnerSupplierSimple"
target="InternalPartnerSupplierMediatorSimple"
type="com.otn.sample.fod.soa.internalsupplier.IInternalPartnerSupplier"/>
<!-- the partner supplier mediator bean with the mock ep -->
<bean id="InternalPartnerSupplierMediatorSimple"
class="com.otn.sample.fod.soa.internalsupplier.InternalSupplierMediator"
scope="prototype">
<!-- inject the external partner supplier bean -->
<property name="externalPartnerSupplier"
ref="IExternalPartnerSupplierServiceMock"/>
<!-- inject the quoteWriter -->
<property name="quoteWriter" ref="WriteQuoteRequest"/>
<!-- context aware logger, globally available bean [ps3] -->
<property name="logger" ref="loggerBean"/>
<!-- headerHelper bean -->
<property name="headerHelper" ref="headerHelperBean"/>
</bean>
<!-- the partner supplier mediator bean with the ejb -->
<bean id="InternalPartnerSupplierMediator"
class="com.otn.sample.fod.soa.internalsupplier.InternalSupplierMediator"
scope="prototype">
<!-- inject the external partner supplier bean -->
<property name="externalPartnerSupplier"
ref="IExternalPartnerSupplierService"/>
<!-- inject the quoteWriter -->
<property name="quoteWriter" ref="WriteQuoteRequest"/>
<!-- context aware logger, globally available bean [ps3] -->
<property name="logger" ref="loggerBean"/>
<!-- headerHelper bean -->
<property name="headerHelper" ref="headerHelperBean"/>
</bean>
. . .
. . .

55.6 JAXBおよびOXMのサポート

Oracle Fusion Middlewareでは、JavaクラスをXMLデータにマップするために、JAXBおよびEclipseLink OXMの使用がサポートされています。これによって、データを任意のXML形式でメモリーに保存および取得できるため、プログラムのクラス構造に対する一連の固有なXMLルーチンの実装は不要です。このサポートによって、次の操作を実行できます。

- XMLデータへのJavaオブジェクトのマップ

- JavaオブジェクトへのXMLデータのマップ

JAXBマッピング用の外部メタデータの設計情報は、次のURLを参照してください。

http://wiki.eclipse.org/EclipseLink/DesignDocs/277920

JAXB OXMおよびOXMマッピング・ファイル(eclipselink-oxm.xsd)の詳細は、次のURLを参照してください。

http://wiki.eclipse.org/EclipseLink/FAQ/WhatIsMOXy

http://wiki.eclipse.org/EclipseLink/Examples/MOXy

http://wiki.eclipse.org/Category:XML

EJBをSOAコンポジット・アプリケーションに統合する場合は、JavaクラスをXMLデータにマップすることもできます。詳細は、「Enterprise JavaBeansとコンポジット・アプリケーションの統合」を参照してください。

55.6.1 拡張されたマッピング・ファイル

Oracle SOA Suiteでは、拡張されたマッピング(EXM)ファイルを使用することにより、JAXBおよびOXMファイルのサポートが拡張されています。EXMファイルが設計時プロジェクトのクラスパス内に存在する場合は、そのファイルをJavaからWSDLへの変換に使用できます。EXMファイルには、次の場合のデータ・バインディング・メタデータが用意されています。

- JAXB注釈をJavaソースに追加できず、個別に指定する必要がある場合

- シナリオがJAXBの対象外である場合(例: メソッドなど最上位レベル要素がタイプまたはパラメータ・タイプを戻す場合)

外部JAXB注釈は、EXMファイルに直接指定するか、またはEXMファイルから参照可能な個別のTopLink JAXBマッピングOXMファイルに含めることができます。

EXMファイル名はJavaクラス名と一致し、同じパッケージの場所に存在する必要があります。たとえば、Javaクラスの名前がpack1.pack2.myJavaInterface.classの場合、EXMファイルの名前はpack1/pack2/myJavaInterface.exmにする必要があります。

Oracle SOA Suiteでは、設計時に、EXMファイルをソース・パス(SCA-INF/src)またはクラスパス(SCA-INF/classes、またはSCA-INF/libのJAR)のいずれかに配置できます。

EXMファイルをソース・パス(SCA-INF/src)に配置すると、Oracle JDeveloperを使用してEXMを編集できます(クラスパス内のファイルはOracle JDeveloperの「アプリケーション」ウィンドウに表示されません)。プロジェクトのコンパイルが完了すると、EXMファイル(およびすべてのインポートされたXMLファイル)はデプロイメントのクラス・パス(SCA-INF/classes)にコピーされます。EXMファイルがソース・パスにある場合にも、対応する同じディレクトリ構造内にある必要があります。

EXM (およびOXM)ファイルをSCA-INF/srcに置く場合は、Oracle JDeveloperプロジェクトが、SCA-INF/srcがデフォルトのソース・ディレクトリになるように構成されていることを確認します(プロジェクト名を右クリックし、「プロジェクト・プロパティ」→「Javaソースパス」を選択します)。EXMファイルは、プロジェクトのクラス・パスにあるJARファイルにもあります。

Javaインタフェース(Enterprise JavaBeans)をBPELプロセスにドラッグ・アンド・ドロップすると、Oracle SOA SuiteではEXMファイルが存在するかどうかが確認されます。存在する場合は、Webサービスjava2wsdl APIに渡されます。

WSDLファイルが生成された後、情報メッセージが表示されます。EXMファイルが使用された場合、メッセージは次の書式で表示されます。

The WSDL file {0} was generated based on the JAVA class {1} using extended mapping file {2}

EXMファイルの例を次に示します。

<java-wsdl-mapping name="com.hello.sei.MyServiceEndpointInterface"
xmlns="http://xmlns.oracle.com/weblogic/weblogic-wsee-databinding"
xmlns:oxm="http://www.eclipse.org/eclipselink/xsds/persistence/oxm"
databinding="toplink.jaxb">
<xml-schema-mapping>
<toplink-oxm-file java-package="com.hello.foo"  file-path="./foo-oxm.xml"/>
<toplink-oxm      java-package="com.hello.coo">
<xml-bindings
xmlns="http://www.eclipse.org/eclipselink/xsds/persistence/oxm">
<xml-schema
element-form-default="QUALIFIED"
attribute-form-default="UNQUALIFIED"
namespace="urn:customer">
<xml-ns prefix="ns1" namespace-uri="urn:customer" />
</xml-schema>
<java-types>
<java-type name="Person" xml-transient="true">
<java-attributes>
<xml-transient java-attribute="id"/>
</java-attributes>
</java-type>
<java-type name="Customer">
<xml-see-also>org.example.employee.Employee</xml-see-also>
</java-type>
</java-types>
</xml-bindings>
</toplink-oxm>
</xml-schema-mapping>
. . .
</java-wsdl-mapping>

データ・バインディング・フレームワークに対する外部マッピング・メタデータのEXMスキーマ・ファイルは、次のURLから入手できます。

http://www.oracle.com/technology/weblogic/weblogic-wsee-databinding/1.1/weblogic-wsee-databinding.xsd

このデータによって、特定のJava Webサービス・エンドポイントの属性が定義されます。このスキーマでは、次の3タイプのXMLコンストラクトが定義されます。

- JAX-WSまたはJSR-181に類似したコンストラクト。このコンストラクトは、サービス・エンドポイント・インタフェース(SEI)の属性、およびSEIのインタフェースで使用される値タイプのJAXB注釈をオーバーライドまたは定義します。

- 標準のJAX-WSまたはJAXB通知を使用しては使用できず、主にjava.util.Collections API.とともに使用する追加のマッピング仕様。

- Toplink OXMファイルから外部JAXBマッピング・メタデータへの参照。

コンストラクトがJAX-WS、JSR-181またはJAXB注釈に非常に類似している場合、スキーマ内のコメントには、次のような注釈が表示されます。

Corresponding Java annotation: javax.jws.WebParam.Mode

55.7 Springサービス・コンポーネントによるGroovyおよびAspectjクラスの構成

Spring構成ファイルでGroovyまたはAspectjクラスを構成する場合は、次の規則に従う必要があります。

- classpathプロトコルを使用します。

script-source="classpath:"

SCAパッケージはクラス・ローダーの通常のJARファイルとして処理されないため、相対ファイル・パスは使用できません。たとえば、次のclasspathプロトコルはクラス・パスからGroovyファイルを検索することを示します。

script-source="classpath:service/GroovyGreeter.groovy"

- classpathプロトコルを使用する場合は、GroovyファイルとAspectjファイルを次のいずれかのディレクトリに追加します。他のディレクトリは使用できません。

- SCA-INF/classes

- SCA-INF/lib

- 共有SOA lib

ビルド・スクリプトがclassesディレクトリを削除するように構成されている場合は、GroovyファイルをSCA-INF/libディレクトリに格納するか、またはビルド・スクリプトを削除が行われないように設計します。

- GroovyまたはAspectjのSpring拡張JARファイル・ライブラリを管理対象サーバーのsetDomainENV.shまたはsetDomainENV.batファイルのクラス・パスに追加し、サーバーを再起動します。これにより、デプロイメントが正常に実行されることが保証されます。SpringではJavaリフレクションを使用してアスペクト指向プログラミング(AOP)がインスタンス化されるため、再起動が必要です。リフレクションの使用により、クラスの検索がシステム・クラス・ローダーに限定されます。システム・クラス・ローダーに変更を加えた場合は、サーバーの再起動が必要になります。

55.8 Springエラーのトラブルシューティング

この項では、Springサービス・コンポーネントのエラーをトラブルシューティングする方法を説明します。

55.8.1 起動するSpring Beanインタフェースが見つからない

SOAコンポジット・アプリケーションがあり、その中でBPELプロセスによってSpringコンテキストが起動されるとします。しかし、起動するためのSpring Beanインタフェースが見つかりません。管理サーバー診断ログ・ファイルに、次の例に示すエラーが表示されます。

[2012-04-09T10:30:07.499-07:00] [AdminServer] [NOTIFICATION] [SOA-31704]
[oracle.integration.platform.blocks.java] [tid: [ACTIVE].ExecuteThread: '2' for
queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid:
11d1def534ea1be0:2058db3f:1369787a1b8:-8000-0000000000002be6,0:2] [WEBSERVICE_
PORT.name: SOACohSpringBPELProcess_pt] [APP: soa-infra] [composite_name:
SOACohSpringProj] [component_name: SOACohSpringBPELProcess] [component_instance_
id: 270006] [J2EE_MODULE.name: fabric] [WEBSERVICE.name: soacohspringbpelprocess_
client_ep] [J2EE_APP.name: soa-infra] No mapping found for class
SOACohSpringProj.CohEJBInterface.

その1つのクラスを含むJARファイルをSCA-INF/libディレクトリにデプロイするか、複数のクラスをSARファイルのSCA-INF/classesディレクトリにデプロイします。

55.8.2 SOAコンポジット・エディタでSpringサービス・コンポーネントを追加できない

Oracle SOA Suiteのクイック・スタート・インストールによって、Springエディタを起動するためのSpring拡張ファイルが自動的に組み込まれます。これにより、SOAコンポジット・エディタにSpringサービス・コンポーネントを正常に追加し、「Oracle JDeveloperでのSpringサービス・コンポーネントの作成方法」で説明しているように、「Springの作成」ダイアログを起動できます。

Oracle SOA Suiteの外部でOracle JDeveloperの標準インストールを使用する場合、Springエディタをインストールする必要があります。このためには、Oracle JDeveloperの「ヘルプ」メイン・メニューで「更新の確認」を選択してから、更新センターでSpring拡張ファイルを選択します。これを行わなければ、Springサービス・コンポーネントをSOAコンポジット・エディタに追加し、「Springの作成」ダイアログを起動することが正常にできません。かわりに、図55-22 に示すエラーが出されます。

図55-22 Spring使用不可エラー

第X部 付録

この部では、Oracle SOA Suiteの付録について説明します。

この部は、次の付録で構成されています。

- BPELプロセスのアクティビティとサービス

- XPath拡張関数

- デプロイメント・ディスクリプタのプロパティ

- センサー・パブリック・ビューとセンサー・アクションXSDの理解

- メッセージ・ヘッダーを介した正規化メッセージ・プロパティの伝播

- ルール・ディクショナリ・エディタのタスク・フローによって実装されるインタフェース

- Oracle SOA Suite構成プロパティのロード・マップ

A BPELプロセスのアクティビティとサービス

この付録では、SOAコンポジット・アプリケーションでBPELプロセスを設計する際に使用するBPELプロセスのアクティビティとサービスについて説明します。

この付録の内容は次のとおりです。

- アクティビティおよびコンポーネントの概要

- BPEL 1.1および2.0アクティビティの概要

- BPELサービスの概要

A.1 アクティビティおよびコンポーネントの概要

Oracle BPELデザイナの「コンポーネント」ウィンドウで「SOAコンポーネント」を開くと、サービス・コンポーネントが表示されます。図A-1 は、BPEL 2.0または1.1プロセスに対して表示されるサービス・コンポーネントを示しています。

図A-1 SOAコンポーネント

サービス・コンポーネントの詳細は、次に示す項を参照してください。

- BPELプロセス
「BPELプロセス・サービス・コンポーネントの使用」を参照してください

- Oracle Mediator
「Oracle Mediatorサービス・コンポーネントの使用」を参照してください

- ビジネス・ルール
「ビジネス・ルール・サービス・コンポーネントの使用」を参照してください

- ヒューマン・タスク
ヒューマン・ワークフロー・サービス・コンポーネントの使用

- Spring
Spring Frameworkを使用したSOAコンポジット・アプリケーションへの統合

Oracle BPELデザイナの詳細は、「Oracle BPEL Process Managerのスタート・ガイド」を参照してください。

A.2 BPEL 1.1および2.0アクティビティの概要

この項では、BPELアクティビティの概要を紹介し、それらのアクティビティの使用方法が説明されているドキュメントを参照先として示します。

Oracle BPELデザイナには、BPELプロセスに追加できるBPEL 1.1およびBPEL 2.0アクティビティが含まれています。これらのアクティビティを使用すると、プロセス内で特定のタスクを実行できます。一部のアクティビティはBPEL 1.1とBPEL 2.0のどちらでも使用できます。その他はBPEL 1.1かBPEL 2.0の一方でのみ使用できます。

これらのアクティビティにアクセスするには、Oracle BPEL Designerの「コンポーネント」ウィンドウに進みます。アクティビティは次のカテゴリに分けて表示されます。

- BPELコンストラクト: BPEL 1.1および2.0の標準機能で提供されるコア・アクティビティ(コンストラクトとも言います)が表示されます。このカテゴリのアクティビティは、BPEL 1.1の場合は「Webサービス」、「アクティビティ」、「構造化アクティビティ」、BPEL 2.0の場合は「Webサービス」、「基本アクティビティ」、「構造化アクティビティ」という追加サブカテゴリの下にそれぞれ表示されます。

- サブプロセス: 作成されたサブプロセスを表示します。サブプロセスが作成されていない場合、このカテゴリは空です。サブプロセスの詳細は、「スタンドアロンおよびインラインBPELサブプロセスの起動の概要」を参照してください。

- Oracle Extensions: BPEL 1.1および2.0機能に価値と使いやすさを追加する拡張アクティビティが表示されます。

- SOAコンポーネント: BPELプロセスに追加できるビジネス・ルール、ヒューマン・タスクおよびOracle Mediatorサービス・コンポーネントが表示されます。

- BPELサービス: JCAアダプタ(AQ、ファイル、FTP、データベース、JMS、MQ、Oracle User Messaging Service、ソケット、JDE World、SAP、LDAPサーバー、Coherenceキャッシュおよびサード・パーティ)、Oracle BAM 11gバインディング・コンポーネント、Oracle Healthcareバインディング・コンポーネント、Oracle B2Bバインディング・コンポーネント、EJBバインディング・コンポーネント、ADF-BCバインディング・コンポーネント、Oracle E-Business Suiteアダプタ、直接バインディング・コンポーネント、HTTPバインディング・コンポーネント、Oracle Managed File Transfer (MFT)アダプタなどのBPELプロセスに追加可能なパートナ・リンクが表示されます。

- カスタム・アクティビティ・テンプレート: 作成されたすべてのカスタムscopeアクティビティのテンプレートが表示されます。テンプレートの詳細は、「テンプレートの概要」を参照してください。

表A-1 に、使用可能なアクティビティを示します。

表A-1 BPEL 1.1とBPEL 2.0のコンストラクトおよび拡張

アクティビティ

上位のカテゴリ

BPEL 1.1でサポートされているか

BPEL 2.0でサポートされているか

詳細

Assign

BPELコンストラクト

はい

はい

「Assignアクティビティ」

Assert

Oracle Extensions

はい

はい

「Assertアクティビティ」

Bind Entity

Oracle Extensions

はい

いいえ

「Bind Entityアクティビティ」

Call

Oracle Extensions

いいえ

はい

「Callアクティビティ」

Compensate

BPELコンストラクト

はい

はい

「Compensateアクティビティ」

CompensateScope

BPELコンストラクト

いいえ

はい

「CompensateScopeアクティビティ」

Create Entity

Oracle Extensions

はい

いいえ

「Create Entityアクティビティ」

Dehydrate

Oracle Extensions

はい

はい

「Dehydrateアクティビティ」

Dynamic Partner Link

BPELコンストラクト

はい

いいえ

「Dynamic Partner Linkアクティビティ」

Email

Oracle Extensions

はい

はい

「Emailアクティビティ」

Empty

BPELコンストラクト

はい

はい

「Emptyアクティビティ」

Exit

BPELコンストラクト

いいえ

はい

注意: BPEL 2.0ではterminateアクティビティから置き換わります。

「Exitアクティビティ」

Flow

BPELコンストラクト

はい

はい

「Flowアクティビティ」

FlowN

Oracle Extensions

はい

いいえ

注意: BPEL 2.0ではforEachアクティビティに置き換わります。

「FlowNアクティビティ」

forEach

BPELコンストラクト

いいえ

はい

注意: BPEL 2.0ではFlowNアクティビティから置き換わります。

「forEachアクティビティ」

If

BPELコンストラクト

いいえ

はい

注意: BPEL 2.0ではswitchアクティビティから置き換わります。

「Ifアクティビティ」

IM

Oracle Extensions

はい

はい

「IMアクティビティ」

Invoke

BPELコンストラクト

はい

はい

「Invokeアクティビティ」

Java Embedding

Oracle Extensions

はい

はい

「Java Embeddingアクティビティ」

Partner Link

BPELコンストラクト

はい

はい

「Partner Linkアクティビティ」

Phase

Oracle Extensions

はい

はい

「Phaseアクティビティ」

Pick

BPELコンストラクト

はい

はい

「Pickアクティビティ」

Receive

BPELコンストラクト

はい

はい

「Receiveアクティビティ」

Receive Signal

Oracle Extensions

はい

はい

「Receive Signalアクティビティ」

Remove Entity

Oracle Extensions

はい

いいえ

「Remove Entityアクティビティ」

RepeatUntil

BPELコンストラクト

いいえ

はい

「RepeatUntilアクティビティ」

Replay

Oracle Extensions

はい

はい

「Replayアクティビティ」

Reply

BPELコンストラクト

はい

はい

「Replyアクティビティ」

Rethrow

BPELコンストラクト

いいえ

はい

「Rethrowアクティビティ」

Schedule Job

Oracle Extensions

はい

はい

「Schedule Job」

Scope

BPELコンストラクト

はい

はい

「Scopeアクティビティ」

Sequence

BPELコンストラクト

はい

はい

「Sequenceアクティビティ」

Signal

Oracle Extensions

はい

はい

「Signalアクティビティ」

SMS

Oracle Extensions

はい

はい

「SMSアクティビティ」

Switch

BPELコンストラクト

はい

いいえ

注意: BPEL 2.0ではIfアクティビティに置き換わります。

「Switchアクティビティ」

Terminate

BPELコンストラクト

はい

いいえ

注意: BPEL 2.0ではExitアクティビティに置き換わります。

「Terminateアクティビティ」

Throw

BPELコンストラクト

はい

はい

「Throwアクティビティ」

Translate

Oracle Extensions

はい

はい

「Translateアクティビティ」

User Notification

Oracle Extensions

はい

はい

「User Notificationアクティビティ」

Validate

Oracle Extensions (BPEL 1.1)

BPELコンストラクト(BPEL 2.0)

はい

はい

「Validateアクティビティ」

Voice

Oracle Extensions

はい

はい

「Voiceアクティビティ」

Wait

BPELコンストラクト

はい

はい

「Waitアクティビティ」

While

BPELコンストラクト

はい

はい

「Whileアクティビティ」

XQuery Transform

Oracle Extensions

はい

はい

「XQuery Transformアクティビティ」

XSLT Transform

Oracle Extensions

はい

はい

「XSLT Transformアクティビティ」

アクティビティの詳細は、次のURLにアクセスして、またはを参照してください。

http://www.oasis-open.org

A.2.1 多くのアクティビティに共通のタブ

アクティビティはそれぞれ特定のタスクを実行しますが、同様のタスクを実行できるタブが多くのアクティビティに用意されています。この項では、これらの共通タブについて説明します。

A.2.1.1 「注釈」タブ

「注釈」タブはすべてのアクティビティで表示され、コードへのコメントや名前と値のペアの割当てという形でアクティビティを説明するために使用できます。

「注釈」タブには、注釈の順序を変更するための方法が用意されていません。解決策として、Oracle BPELデザイナでプロジェクトのBPELファイルの「ソース」ビューを使用して注釈の順序を変更します。

A.2.1.2 「アサーション」タブ

「アサーション」タブは、invoke、receive、replyの各アクティビティと、pickおよびscopeアクティビティのonMessageブランチで表示されます。これらのアクティビティでのリクエスト/レスポンス操作時にコールバック・メッセージを受信すると、一連のアサーションが実行されます。アサーションには、falseと評価された場合にアクティビティからBPELフォルトをスローするXPath式を指定します。この機能は、パートナ・コールバック後に多数のswitch、assignおよびthrowアクティビティを使用する可能性がある場合の代替手段として提供されています。

条件を実行するタイミングを次の中から選択できます。

- Preassert: この条件は、invokeアクティビティまたはreplyアクティビティがアウトバウンド・メッセージを送信する前に実行されます。

- Postassert: この条件は、invokeアクティビティ、receiveアクティビティまたはonMessageブランチがインバウンド・メッセージを受信した後に実行されます。

詳細は、このタブのオンライン・ヘルプおよび「アサーション条件によるフォルトのスロー」を参照してください。

A.2.1.3 「相関」タブ

「相関」タブは、invoke、receive、replyの各アクティビティ、pickアクティビティのonMessageブランチ、およびscopeアクティビティのonMessage変数で表示されます。相関セットを使用すると、サービス・インスタンスにおける操作の相関グループを明示的に指定できるため、プロセスとそのパートナ間の複雑な相互作用の処理が可能になります。一連の相関トークンは、一連のプロパティとして定義され、相関グループ内のすべてのメッセージで共有されます。

詳細は、このタブのオンライン・ヘルプおよび「非同期サービスでの相関セットの概要」を参照してください。

A.2.1.4 「ドキュメント」タブ

「ドキュメント」タブでは、BPELファイルのアクティビティにヒューマン・ドキュメントを埋め込むことができます。これらのコメントは、BPELファイルのソース・コードでのみ表示されます。次の例に詳細を示します。

<invoke>
. . .
<documentation>
Invokes the credit rating service partner link
</documentation>
. . .

注意:

このタブは、BPEL 2.0プロジェクトでのみ使用できます。

A.2.1.5 「ヘッダー」タブ

「ヘッダー」タブは、invoke、receive、replyの各アクティビティと、pickおよびscope (BPEL 1.1の場合)アクティビティのonMessageブランチで表示されます。アドバンスト・キューイング(AQ)、ファイル、FTP、MQ、Java Message Service (JMS)などのアダプタで使用するヘッダー変数を作成します。

詳細は、このタブのオンライン・ヘルプおよび『テクノロジ・アダプタの理解』を参照してください

A.2.1.6 「プロパティ」タブ

「プロパティ」タブは、invoke、receive、replyの各アクティビティと、pickおよびscopeアクティビティのonMessageブランチで表示されます。Oracle BPEL Process Manager、Oracle Mediator、Oracle JCAアダプタ、RESTアダプタ、Oracle B2Bなどのコンポーネントに対して正規化されたメッセージ・ヘッダー・プロパティを定義できます。

詳細は、このタブのオンライン・ヘルプおよび「メッセージ・ヘッダーを介した正規化メッセージ・プロパティの伝播」を参照してください。

A.2.1.7 「スキップ条件」タブ

「スキップ条件」タブは、ほとんどのアクティビティで表示され、指定したXPath式がtrueと評価された場合に、そのアクティビティがスキップされるようにできます。この拡張機能は、条件付きアクティビティの作成に使用するswitchアクティビティのcaseパターンの代替手段として提供されています。

詳細は、このタブのオンライン・ヘルプおよび「アクティビティの実行をバイパスするためのXPath式の指定」を参照してください。

A.2.1.8 「ソース」タブと「ターゲット」タブ

「ソース」タブと「ターゲット」タブでは、flowアクティビティで実行するソースとターゲットのアクティビティを定義できます。この機能を使用すると、flowアクティビティ内でアクティビティの実行を同期し、ターゲット・アクティビティがソース・アクティビティの完了後にのみ実行されるようにできます。

詳細は、このタブのオンライン・ヘルプおよび「flowアクティビティ内のアクティビティ実行の同期化」を参照してください。

A.2.1.9 「タイムアウト」タブ

「タイムアウト」タブは、receiveアクティビティで表示され、リクエスト/レスポンス操作に対するタイムアウト設定が提供されます。この機能は、パートナ・コールバックのタイムアウト期間を指定する場合に使用する必要があるpickアクティビティのonMessageブランチとonAlarmブランチの代替手段として提供されています。

詳細は、このタブのオンライン・ヘルプおよび「receiveアクティビティのリクエスト/リプライ操作および入力専用操作に対するタイムアウトの設定」を参照してください。

A.2.2 アダプタ構成時以外のネイティブ・フォーマット・ビルダー・ウィザードの使用

ネイティブ・フォーマット・ビルダー・ウィザードを使用して、ネイティブXSDスキーマ・ファイルを作成できます。アダプタ作成時でなくてもネイティブ・フォーマット・ビルダー・ウィザードを起動して、新規スキーマを作成したり、既存のスキーマを編集できるようになりました。

A.2.2.1 「アプリケーション」ウィンドウからネイティブ・フォーマット・スキーマを作成する手順:

1. Oracle JDeveloperメイン・メニューから、「ファイル」→「新規」を選択します。

2. 「カテゴリ」リストで、「SOA層」→「インタフェース」を選択します。

3. 「NXSDスキーマ」をクリックして、ネイティブ・フォーマット・ビルダー・ウィザードを起動します。

4. 「ようこそ」ページで、「次へ」をクリックします。

5. 「ファイル名とディレクトリ」ページで、スキーマのファイル名(たとえば、addresses_schema.xsd)とディレクトリ・パスを指定します。

6. ウィザードの残りのページを実行して、ネイティブ・フォーマット・スキーマを作成します。

ネイティブ・フォーマット・ビルダー・ウィザードの詳細は、『テクノロジ・アダプタの理解』のネイティブ・フォーマット・ビルダー・ウィザードに関する項を参照してください。

A.2.2.2 「アプリケーション」ウィンドウで既存のネイティブ・フォーマット・スキーマを編集する手順:

スキーマ編集のために、「アプリケーション」ウィンドウからネイティブ・フォーマット・ビルダー・ウィザードにアクセスできます。スキーマ・ファイルがネイティブ・フォーマット・スキーマ・ファイルであることが検出された場合は、コンテキスト・メニュー・オプション「NXSDの編集」が選択可能になります。

1. 「アプリケーション」ウィンドウで、ネイティブ・フォーマット・スキーマ・ファイル(たとえば、addresses.xsd)を右クリックします。

2. 「NXSDの編集」を選択します。

ネイティブ・フォーマット・ビルダー・ウィザードの詳細は、『テクノロジ・アダプタの理解』のネイティブ・フォーマット・ビルダー・ウィザードに関する項を参照してください。

A.2.3 Assignアクティビティ

このアクティビティには、変数の内容を別の変数にコピーする操作など、データ操作のメソッドが用意されています。コピー操作により、変数、式、エンドポイントおよびその他の要素の間で情報を転送できます。

図A-2 に、BPEL 1.1における「割当て」ダイアログの「コピー・ルール」タブを示します。次の方法のいずれかで、ツリー内のソース・ノードとターゲット・ノードの間のマッピングを作成します。

- ソース・ノードをターゲット・ノードにドラッグして、ソース・ノードからターゲット・ノードへのBPELコピー・ルールを作成します。このアクションで、ソースとターゲットのタイプを接続する線が作成されます。

- ソース・ノードを選択してから、ターゲット・ノードを選択し、ダイアログの下部にある表の上の「追加」アイコンをクリックします。その後、マッピングが表に追加され、それらのノード間の接続線がツリー内に描画されます。

コピー・ルールは、ダイアログの下部にある「開始」セクションと「終了」セクションに表示されます。

図A-2 割当ての編集ダイアログの「コピー・ルール」タブ

ソース・ノード・セクションの上にある「挿入モードの選択」リストを使用すると、作成する次のコピー・ルールを、ダイアログの下部で選択されているルールの前か後ろに挿入できます。

ターゲット・ノードの上に表示されるアイコンを使用すると、ターゲット・ノードに対して次のタスクを実行できます(左から右の順)。デフォルトでは、センター・キャンバスが開きます。それが閉じている場合は、開いているバーをドラッグし、センター・キャンパスを表示します。

- 「式」アイコン: このアイコンをターゲット・ノードにドラッグすると、そのノードにXPath式を割り当てるための「式ビルダー」ダイアログが開きます。このアイコンを、センター・キャンバスにドラッグしてこのダイアログを呼び出し、式を指定し、ダイアログを保存して閉じ、アイコンをターゲット・ノードにドラッグすることもできます。

- 「リテラル」(BPEL 2.0仕様)アイコンまたは「フラグメント」(BPEL 1.1仕様)アイコン: このアイコンをターゲット・ノードにドラッグすると、そのターゲット・ノードにリテラル(BPELプロジェクトがBPEL 2.0仕様をサポートしている場合)またはXMLフラグメント(BPELプロジェクトがBPEL 1.1仕様をサポートしている場合)を割り当てるためのダイアログが開きます。このアイコンを、センター・キャンバスにドラッグしてこのダイアログを呼び出し、値を指定し、ダイアログを保存して閉じ、アイコンをターゲット・ノードにドラッグすることもできます。

- 「削除」アイコン: このアイコンをターゲット・ノードにドラッグして、bpelx:remove拡張ルールを作成します。このアイコンを、センター・キャンバスにドラッグしてこのダイアログを呼び出し、ルールを指定し、ダイアログを保存して閉じ、アイコンをターゲット・ノードにドラッグすることもできます。

- 「名前の変更」アイコン: このアイコンをドラッグして、ターゲット・ノードの名前を変更します。こうすると、elementTo属性にbpelx:rename拡張ルールが追加されます。このアイコンを、センター・キャンバスにドラッグしてダイアログを呼び出し、ルールを指定し、ダイアログを保存して閉じ、アイコンをターゲット・ノードにドラッグすることもできます。

- 「再キャスト」アイコン: このアイコンをドラッグして、ターゲット・ノードを再キャストします。こうすると、typeCastTo属性にbpelx:rename拡張ルールが追加されます。XML出力で、xsi:type属性になります。このアイコンを、センター・キャンバスにドラッグしてダイアログを呼び出し、ルールを指定し、ダイアログを保存して閉じ、アイコンをターゲット・ノードにドラッグすることもできます。

選択したコピー・ルールをbpelx拡張タイプ(bpelx:copyList、bpelx:insertAfter、bpelx:insertBefore、bpelx:append)に変更することもできます。

選択の方法は、BPEL 1.1とBPEL 2.0で異なります。

図A-3 に、BPEL 1.1における拡張タイプの選択方法を示します。コピー・ルールを選択して「コピー」ドロップダウン・リストを選択し、適切な拡張を選択します。

図A-3 コピー・ルールをBPEL 1.1のbpelx拡張に変更

図A-4 に、BPEL 2.0における拡張タイプの選択方法を示します。コピー・ルールを右クリックしてルール・タイプの変更を選択し、適切な拡張を選択します。

図A-4 コピー・ルールをBPEL 2.0のbpelx拡張に変更

bpelx拡張によるXMLデータの操作の詳細は、「bpelx拡張要素を使用したXMLデータの操作」を参照してください。

「送信元XPath」と「送信先XPath」の各フィールドで、ソース・タイプの左にあるアイコンにカーソルを重ねて、実行する操作(コピー、追加など)を表示することもできます。それぞれの操作が、タイプごとに異なるアイコンで表されます。コピー・ルールを右クリックして、実行するアクションのリストを表示することも可能です。

- 「'From'式の編集」または「'To'式の編集」: 作成したコピー・ルールにソース・ノードまたはターゲット・ノードへの問合せが含まれるときにXPath式を編集するには、このオプションを選択します。これを選択すると、「式ビルダー」ダイアログが開きます。表示されるメニュー・オプションは、コピー・ルールの現在の選択内容によって異なります。

- ignoreMissingFromData: コピー・ルールのignoreMissingFromData属性の有効と無効を切り替える場合は、このオプションを選択します。有効にすると、bpel:selectionFailure標準フォルトが抑制されます。詳細は、「ignoreMissingFromData属性」を参照してください。

- insertMissingToData: コピー・ルールのinsertMissingToData属性の有効と無効を切り替える場合は、このオプションを選択します。詳細は、「insertMissingToData属性」を参照してください。

- keepSrcElementName (BPEL 2.0プロジェクトでのみ): コピー・ルールのkeepSrcElementName属性の有効と無効を切り替える場合は、このオプションを選択します。このオプションを使用すると、ターゲットの要素名(to-specで指定される)を、ソースの要素名で置き換えることができます。

- ルール・タイプの変更 (BPEL 2.0プロジェクトでのみ): 選択したルールのタイプを、BPEL拡張ルールであるbpelx:copyList、bpelx:insertAfter、bpelx:insertBefore、bpelx:appendのいずれかに変更する場合は、このオプションを選択します。

- 「ルールの削除」: 選択したルールを削除する場合は、このオプションを選択します。

ignoreMissingFromData、insertMissingToData、keepSrcElementNameの各属性の詳細は、「assign拡張要素の属性の使用方法」を参照してください。

「終了」セクションの上にあるアイコンを使用すると、選択したコピー・ルールの追加、削除および上下への移動が可能です。

assignアクティビティの詳細は、「コピー・ルール」ダイアログのオンライン・ヘルプおよび「BPELプロセスでのXMLデータの操作」を参照してください。

注意:

assignアクティビティに複数のbpelx:append設定が含まれる場合は、このアクティビティを2つのassignアクティビティに分割する必要があります。分割しないと、bpelx:appendがそれぞれリストの最後に移動し、問題が発生する可能性があります。解決策として、この設定を手動で移動します。

A.2.4 Assertアクティビティ

このアクティビティを使用すると、指定した式に対してアサーションを実行できます。

これは、アサーションを指定するスタンドアロンのアクティビティです。このアクティビティは、BPELプロセス・フロー内のすべての場所に配置できます。invokeアクティビティ、replyアクティビティ、receiveアクティビティおよびpickアクティビティとscopeアクティビティのonMessageブランチで、「アサーション」タブからメッセージ交換アクティビティのアサーションを指定することもできます。

図A-5 は、「アサート」ダイアログを示しています。

図A-5 「Assert」ダイアログ

スタンドアロンのassertアクティビティの詳細は、「スタンドアロンassertアクティビティでのアサーション条件」および「アサーション条件作成時の処理内容」を参照してください。

A.2.5 Bind Entityアクティビティ

このアクティビティを使用すると、エンティティ変数を選択できます。エンティティ変数は、様々なデータ・プロバイダ・サービス・テクノロジにアクセスし、プラグインするためのデータ・ハンドルとして機能します。

エンティティ変数は、サービス・データ・オブジェクト(SDO)ベースのデータを使用して、Oracle Application Development Framework (ADF) Business Componentデータ・プロバイダ・サービスと一緒に使用できます。エンティティ変数を使用すると、基礎となるデータ・プロバイダ・サービスがBPELデータ操作を実行するように指定できます。データ・プロバイダ・サービスはデータ・ストア内でデータ操作をバックグラウンドで実行しますが、Oracle BPEL Process Manager提供の他のデータ・ストア関連の機能(たとえば、データベース・アダプタ)を使用しません。この操作により、Oracle BPEL Process Managerの実行時パフォーマンスを高め、コンパイルおよび実行時に、基礎となるデータ・プロバイダ・サービスのネイティブの機能を組み込みます。

図A-6 は、「Bind Entity」ダイアログを示しています。

図A-6 「Bind Entity」ダイアログ

A.2.6 Callアクティビティ

このアクティビティにより、BPEL 2.0でスタンドアロン・サブプロセスおよびインライン・サブプロセス内の参照サブプロセス・コードを実行できます。サブプロセスは、別個のプロセスが特定のプロセッサ内で再利用できるBPELコードのフラグメントです。

図A-7 は、コールの編集ダイアログを示しています。

図A-7 コールの編集ダイアログ

callアクティビティの詳細は、「スタンドアロンおよびインラインBPELサブプロセスの起動の概要」および「BPELプロセスでのスタンドアロンおよびインラインBPELサブプロセスの作成」を参照してください。

A.2.7 Compensateアクティビティ

このアクティビティは、正常に完了している内側のscopeアクティビティでの補正を起動します。このアクティビティを起動できるのは、フォルト・ハンドラまたは別の補正ハンドラの中からのみです。補正は、プロセスでいくつかの操作を完了できず、その他の操作は完了している場合に行われます。プロセスは、以前に完了した操作に戻り、それらを元に戻す必要があります。たとえば、あるプロセスがレンタカー、ホテルおよび航空券を予約するように設計されているとします。レンタカーとホテルを予約しましたが、正しい日付の航空券を予約できません。この場合、レンタカーとホテルの予約を取り消すことで補正を実行します。compensateアクティビティ(補正ハンドラが起動されるスコープを指定)で補正ハンドラが起動されます。

図A-8 は、BPEL 1.1における「Compensate」ダイアログを示しています。次のタスクを実行できます。

- 「一般」タブをクリックし、アクティビティに意味のある名前を付けます。

- 補正ハンドラを起動するscopeアクティビティを選択します。

図A-8 「Compensate」ダイアログ

BPEL 2.0の場合、「Compensate」ダイアログには「ドキュメント」タブがあります。

compensateアクティビティの詳細は、「一連の操作を元に戻した後の補正の使用」を参照してください。

A.2.8 CompensateScopeアクティビティ

このアクティビティを使用すると、正常に完了している特定の内側のscopeに対して補正を開始できます。このアクティビティは、フォルト・ハンドラ、別の補正ハンドラまたは終了ハンドラ内からのみ使用します。

注意:

このアクティビティは、BPEL 2.0プロジェクトでのみサポートされます。

図A-9 は、「CompensateScope」ダイアログを示しています。

図A-9 「CompensateScope」ダイアログ

compensateScopeアクティビティの詳細は、「一連の操作を元に戻した後の補正の使用」を参照してください。

A.2.9 Create Entityアクティビティ

このアクティビティを使用すると、エンティティ変数を作成できます。エンティティ変数は、SDOベースのデータを使用して、Oracle ADF Business Componentデータ・プロバイダ・サービスと一緒に使用できます。

図A-10 は、「Create Entity」ダイアログを示しています。

図A-10 「Create Entity」ダイアログ

詳細は、「データ・プロバイダ・サービスへのXMLデータ操作の委任」を参照してください。

A.2.10 Dehydrateアクティビティ

デフォルトでは、receive、onMessage、onAlarm、waitなどのアクティビティにデハイドレーション・ポイントが設定されています。dehydrateアクティビティを使用すると、デハイドレーション・ポイントを明示的に指定できます。このアクティビティは、非同期コールバックの待機中、長期間にわたる非同期プロセスとその現在の状態の情報をデータベースに自動的に保持するためのデハイドレーション・ポイントとして機能します。データベースにプロセスを格納することにより、プロセスを維持し、システムの停止やネットワークの問題が発生した場合の状態や信頼性の低下を防ぎます。この機能により、BPELプロセスの信頼性とスケーラビリティの両方が向上します。

bpelx:dehydrate拡張は、デハイドレーションを実装します。BPELバージョン1.1をサポートするBPELの場合、構文は次のようになります。

<bpelx:dehydrate name="DehydrateInstance"/>

BPELバージョン2.0をサポートするBPELの場合、構文は次の例のようになります。

<extensionActivity>
<bpelx:dehydrate name="DehydrateInstance"/>
</extensionActivity>

図A-11 は、BPEL 2.0における「Dehydrate」ダイアログを示しています。

図A-11 「Dehydrate」ダイアログ

A.2.11 Dynamic Partner Linkアクティビティ

このアクティビティを使用して、BPELバージョン1.1で実行時に使用するパートナ・リンクへのエンドポイント参照を動的に割り当てることができます。

図A-12 は、BPEL 1.1の「動的パートナ・リンク」ダイアログを示しています。

図A-12 「動的パートナ・リンク」ダイアログ

詳細は、「実行時に使用するための動的パートナ・リンクの設計時の作成」を参照してください。

A.2.12 Emailアクティビティ

このアクティビティを使用すると、イベントに関する電子メール通知を送信できます。

たとえば、オンライン書店のオンライン・ショッピング・ビジネス・プロセスで、商品を出荷した後、ユーザーに儀礼的な電子メール・メッセージを送信するとします。ビジネス・プロセスは、ユーザーIDおよび通知メッセージを指定して通知サービスをコールします。通知サービスは、Oracle Internet Directoryから電子メール・アドレスを取得します。

図A-13 は、BPEL 2.0での「電子メール」ダイアログを示しています。

図A-13 「電子メール」ダイアログ

emailアクティビティの詳細は、「電子メール通知チャネルの構成方法」を参照してください。

A.2.13 Emptyアクティビティ

このアクティビティを使用すると、操作なしの命令をプロセスに挿入できます。このアクティビティは、何もしないアクティビティを使用する必要がある場合(フォルトを捕捉して抑止する必要がある場合など)に便利です。

図A-14 は、BPEL 2.0の「Empty」ダイアログを示しています。

図A-14 「Empty」ダイアログ

emptyアクティビティの詳細は、「emptyアクティビティによる操作なしの命令のビジネス・プロセスへの挿入方法」を参照してください。

A.2.14 Exitアクティビティ

このアクティビティを使用すると、終了ハンドラ、フォルト・ハンドラ、補正ハンドラのメカニズムを利用せずに、すべてのパラレル・ブランチで現在実行されているすべてのアクティビティを即時終了できます。

注意:

BPEL 2.0プロジェクトでは、このアクティビティのかわりにterminateアクティビティが使用されます。

図A-15 は、「終了」ダイアログを示しています。

図A-15 「終了」ダイアログ

exitアクティビティの詳細は、「BPEL 2.0のexitアクティビティによるビジネス・プロセス・インスタンスの即時終了」を参照してください。

A.2.15 Flowアクティビティ

このアクティビティを使用すると、1つ以上のアクティビティを同時に実行するように指定できます。flowアクティビティは、フロー内のすべてのアクティビティが処理を終了したときに完了します。flowアクティビティが完了しても、許可条件がfalseの場合はスキップされている可能性があります。

たとえば、flowアクティビティを使用して、2つの融資斡旋業者(United LoanサービスおよびStar Loanサービス)をパラレルで起動できるようにするとします。この場合、flowアクティビティには2つのパラレル・アクティビティ(United Loanサービスを起動するシーケンスとStar Loanサービスを起動するシーケンス)が含まれます。各サービスは、任意の時間をかけて融資プロセスを完了できます。

図A-16 に、パラレル処理用の2つのパネルを持つ初期flowアクティビティを示します。アクティビティを両方のパネルにドラッグしてパラレル処理を作成します。完了したflowアクティビティは図A-17 のようになります。

図A-16 「フロー」ダイアログ(作成時)

図A-17 「フロー」ダイアログ(設計完了後)

flowアクティビティ内で、アクティビティの実行を同期することもできます。こうすると、特定のアクティビティを他のアクティビティの完了後にのみ実行することができます。

注意:

OracleのBPEL実装では、個別のスレッドではなく、BPELプロセスの同一で単一の実行スレッドでフローが実行されます。

flowアクティビティの詳細は、「パラレル・フローの作成」を参照してください。

A.2.16 FlowNアクティビティ

このアクティビティを使用すると、Nの値に等しい複数のフローを作成できます。この値は、使用可能なデータおよびプロセス内のロジックに基づいて実行時に定義されます。索引変数は、Nの値に到達するまで、新しいブランチが作成されるたびに増分されます。

注意:

このアクティビティは、BPEL 2.0プロジェクトではforEachアクティビティに置き換えられます。

図A-18 は、FlowNダイアログを示しています。

図A-18 FlowNダイアログ

flowNアクティビティの詳細は、「BPEL 1.1のflowNアクティビティによるflowアクティビティ数のカスタマイズ」を参照してください。

A.2.17 forEachアクティビティ

このアクティビティを使用すると、アクティビティの複数のセットを順次、または並行して処理できます。forEachアクティビティは、それに含まれている(子)scopeアクティビティを正確にN+1回実行し、Nは、最終カウンタ値から、「For Each」ダイアログの「カウンタの値」タブで指定する開始カウンタ値を引いた値に等しくなります。flowアクティビティなど、他の構造化アクティビティは、含まれているアクティビティとして任意のタイプのアクティビティを使用できますが、forEachアクティビティにはscopeアクティビティのみ使用することができます。

注意:

BPEL 2.0プロジェクトでは、このアクティビティのかわりにflowNアクティビティが使用されます。

図A-19 に、内部のscopeを伴うforEachアクティビティを示します。

図A-19 forEachアクティビティ

forEachアクティビティの詳細は、「BPEL 2.0のforEachアクティビティによるアクティビティの複数のセットの処理」を参照してください。

A.2.18 Ifアクティビティ

このアクティビティを使用すると、特定のアクティビティが複数のブランチから処理を判定する条件処理を定義できます。ブランチのセットから、実行するアクティビティが1つだけ選択されます。

注意:

BPEL 2.0プロジェクトでは、このアクティビティのかわりにswitchアクティビティが使用されます。

図A-20 に、ifアクティビティと、後続のif、elseif、elseブランチが定義されている例を示します。

図A-20 ifアクティビティ

ifアクティビティの詳細は、「BPEL 2.0のifアクティビティの作成による条件分岐の定義」を参照してください。

A.2.19 IMアクティビティ

このアクティビティを使用すると、非同期のインスタント・メッセージ(IM)通知をユーザー、グループまたは宛先アドレスに自動的に送信できます。図A-21 は、「IM」ダイアログを示しています。

図A-21 「IM」ダイアログ

詳細は、「IM通知チャネルの構成方法」を参照してください。

A.2.20 Invokeアクティビティ

このアクティビティを使用すると、サービス(パートナ・リンクで識別)に対して起動する操作を指定できます。操作は、サービスによって指定されたポートでの一方向またはリクエスト/レスポンスです。invokeアクティビティで変数を自動的に作成することも可能です。invokeアクティビティは、同期Webサービスを起動するか、非同期Webサービスを開始します。

invokeアクティビティは、プロセス内でデータを送受信するためのポートをオープンします。このポートを使用して、必要なデータの送信およびレスポンスの受信を行います。同期コールバックの場合、関数の送受信に必要なポートは1つのみです。

図A-22 は、BPEL 2.0における「起動」ダイアログを示しています。次のタスクを実行できます。

- アクティビティに意味のある名前を付けます。

- 操作を指定するパートナ・リンクを選択します。

- 実行する操作を選択します。

- データ(ペイロード)をトランスポートするための変数を自動的に作成するか、既存の変数を選択します。

図A-22 「起動」ダイアログ

invokeアクティビティの詳細は、次を参照してください。

- BPELプロセスの相互作用パターンの概要

- BPEL 2.0でのWSDLメッセージ・パートのマップ

- リクエストを実行するためのinvokeアクティビティ

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

- 非同期相互作用でフォルトを返す方法

- アサーション条件によるフォルトのスロー

A.2.21 Java Embeddingアクティビティ

このアクティビティによって、Java BPELの拡張要素であるbpelx:execを使用してBPELプロセスにカスタムJavaコードを追加できます。この方法は、関数を実行できるJavaコードが存在していて、最初からコーディングしなおすのではなくこの既存のコードを使用する場合に役立ちます。BPEL 2.0プロジェクトでは、bpelx:exec拡張要素とJavaコードが<extensionActivity>要素でラップされます。

図A-23 は、BPEL 2.0でのJava Embeddingの編集ダイアログを示しています。

図A-23 Java Embeddingの編集ダイアログ

Java Embeddingアクティビティの詳細は、「BPELプロセスへのJavaおよびJava EEコードの組込み」を参照してください。

A.2.22 Partner Linkアクティビティ

このアクティビティでは、プロセスと連係する外部サービスを定義できます。パートナ・リンク・タイプは、対話において各サービスが果たす役割を定義すること、および対話の中でメッセージを受信するために各サービスが提供するポート・タイプを指定することで、2つのサービス間での対話関係の特性を決定します。たとえば、信用格付けサービスおよび2つの融資斡旋業者サービス(United LoanおよびStar Loan)と対話するプロセスを作成する場合、3つのサービスすべてにパートナ・リンクを作成します。

図A-24 は、BPEL 2.0における「パートナ・リンク」ダイアログを示しています。次の詳細を指定します。

- サービスの意味のある名前。

- 外部サービスのWeb Services Description Language (WSDL)ファイル。

- 実際のサービス・タイプ(パートナ・リンク・タイプとして定義)。

- サービスのロール(パートナ・ロールとして定義)。

- サービスをリクエストするプロセスのロール(マイ・ロールとして定義)。

図A-24 Partner Linkアクティビティ

パートナ・リンクの詳細は、「BPELプロセスからの非同期Webサービスの起動」を参照してください。

A.2.23 Phaseアクティビティ

このアクティビティは、BPELプロセスと統合するためのOracle Mediatorおよびビジネス・ルール・サービス・コンポーネントを作成します。メッセージ・リクエストの入力変数およびメッセージ・レスポンスの出力変数を作成し、BPELプロセスの変数のコンテンツを評価するビジネス・ルールを設計します。

これらのタスクを完了すると、次のアクティビティとサービス・コンポーネントが作成されます。

- assignアクティビティ: メッセージ・リクエストの入力変数およびメッセージ・レスポンスの出力変数が含まれます。

- invokeアクティビティ: BPELプロセスでOracle Mediatorパートナ・リンクを起動するように自動的に設計されます。

- Oracle Mediatorパートナ・リンク: メッセージ・リクエストの入力変数を、このBPELプロセスが含まれるSOAコンポジット・アプリケーションのビジネス・ルール・サービス・コンポーネントにルーティングするように自動的に設計されます。ビジネス・ルール・サービス・コンポーネントはに表示されます。Oracle Mediatorもサービス・コンポーネントとしてに表示されます。

- ビジネス・ルール・サービス・コンポーネント: メッセージ・リクエストの入力変数のコンテンツを評価し、メッセージ・レスポンスの出力変数の結果をOracle Mediatorに戻します。Oracle Mediatorはルーティングを決定し、メッセージを適切なターゲット宛先にルーティングします。

図A-25 は、BPEL 2.0での「フェーズ」ダイアログを示しています。

図A-25 「フェーズ」ダイアログ

詳細は、「動的ビジネス・プロセスの作成」を参照してください。

A.2.24 Pickアクティビティ

このアクティビティは、イベント・セット内の特定イベントの発生を待機し、そのイベントに関連するアクティビティを実行します。多くの場合、イベントの発生は相互に排他的です(プロセスは承認メッセージと却下メッセージの両方ではなくどちらかを受信します)。複数のイベントが発生した場合、実行するアクティビティは、どちらのイベントが先に発生したかに基づいて選択されます。イベントがほとんど同時に発生した場合は競争になり、実行するアクティビティはタイミングと実装の両方に基づいて選択されます。

pickアクティビティには、OnMessageブランチがあります。BPEL 2.0で「onMessage」アイコンをクリックすると、図A-26 に示すダイアログが表示されます。

図A-26 「onMessage」ダイアログ

pickアクティビティの2つのブランチは次のとおりです。

- OnMessage (pickアクティビティ・アイコンの下に自動的に表示されます)
(融資サービスなどから)リプライを受信するためのコードが含まれています。

- OnAlarm (自動的には表示されません。pickアクティビティ・アイコンを選択して「OnAlarmの追加」アイコンをクリックし、手動で追加する必要があります)
タイムアウト(1分後など)のコードが含まれています。

先に完了したブランチが実行されます。もう一方のブランチは実行されません。最初に条件が満たされたブランチが実行されます。

図A-27 は、BPEL 2.0でのpickアクティビティの「OnAlarm」ダイアログを示しています。

図A-27 PickアクティビティのOnAlarmブランチ・ダイアログ

注意:

BPEL 1.1のscopeアクティビティにおけるOnMessageブランチと、BPEL 1.1および2.0のscopeアクティビティにおけるOnAlarmブランチも作成できます。Oracle JDeveloperでscopeアクティビティを開き、左側でアイコンを参照して追加するブランチを検索します。

onMessageブランチに相関を追加する場合は、相関構文がassignアクティビティの構文の後ろに配置されます。相関構文をassignアクティビティの前に移動する必要があります。

A.2.24.1 assignアクティビティの前に相関構文を配置する手順:

1. Oracle JDeveloperで相関セットを作成します。

2. この相関セットをonMessageブランチに割り当てます。

3. 残りの設計タスクを完了します。

4. BPELソース・コード内で相関構文をassignアクティビティの前に移動してから、BPELプロセスを作成またはデプロイします。

pickアクティビティの詳細は、次を参照してください。

- BPELプロセスの相互作用パターンの概要

- BPEL 2.0でのWSDLメッセージ・パートのマップ

- アサーション条件によるフォルトのスロー

- 「pickアクティビティのプロセスの待機または継続の選択」

- 「永続同期プロセスに対するタイムアウトの設定」

A.2.25 Receiveアクティビティ

このアクティビティでは、情報の受信先となるパートナ・リンクと、起動するパートナ・リンクのポート・タイプおよび操作を指定します。このアクティビティは、サービス(融資申請の承認サービスなど)からの非同期コールバック・レスポンス・メッセージを待機します。待機中のBPELプロセスは、コールバック・メッセージが到着するまでデハイドレーション(圧縮して格納)されます。このレスポンスの内容は、プロセスのレスポンス変数に格納されます。

図A-28 は、BPEL 2.0における「Receive」ダイアログを示しています。次のタスクを実行できます。

- 意味のある名前を付けます。

- 操作を指定するパートナ・リンク・サービスを選択します。

- 実行する操作を選択します。

- コールバック・レスポンスをトランスポートするための変数を自動的に作成するか、既存の変数を選択します。

図A-28 「Receive」ダイアログ

receiveアクティビティの詳細は、次を参照してください。

- BPELプロセスの相互作用パターンの概要

- BPEL 2.0でのWSDLメッセージ・パートのマップ

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

- アサーション条件によるフォルトのスロー

- 「receiveアクティビティのリクエスト/リプライ操作および入力専用操作に対するタイムアウトの設定」

A.2.26 Receive Signalアクティビティ

このアクティビティは、詳細プロセスではマスター・プロセスからの処理開始の通知シグナルを待機するために使用し、マスター・プロセスではすべての詳細プロセスからの処理の完了を示す通知シグナルを待機するために使用します。

図A-29 は、シグナル受信の編集ダイアログを示しています。

図A-29 「シグナルの受信」ダイアログ

詳細は、「マスター・プロセスと詳細プロセスの調整」を参照してください。

A.2.27 Remove Entityアクティビティ

このアクティビティを使用すると、エンティティ変数を削除できます。このアクションによって行が削除されます。

図A-30 は、「Remove Entity」ダイアログを示しています。

図A-30 エンティティの削除ダイアログ

A.2.28 RepeatUntilアクティビティ

アクティビティの本体を1回以上実行する必要がある場合には、このアクティビティを使用します。repeatUntilアクティビティのXPath式の条件は、アクティビティの本文が完了した後に評価されます。条件は、指定したブール条件がtrueになるまで繰返し評価されます(アクティビティの本体も処理されます)。図A-31 は、「繰返し期限」ダイアログを示しています。

注意:

このアクティビティは、BPEL 2.0プロジェクトでのみサポートされます。

図A-31 「繰返し期限」ダイアログ

repeatUntilアクティビティの詳細は、「repeatUntilアクティビティによる条件分岐の定義」を参照してください。

A.2.29 Replayアクティビティ

このアクティビティを使用すると、選択した範囲内でアクティビティを再実行することができます。

図A-32 は、BPEL 2.0での「再実行」ダイアログを示しています。

図A-32 「再実行」ダイアログ

replayアクティビティの詳細は、「replayアクティビティによるscopeアクティビティ内でのアクティビティの再実行」を参照してください。

A.2.30 Replyアクティビティ

このアクティビティでは、receiveアクティビティで受信したメッセージに応答するメッセージを送信できます。receiveアクティビティとreplyアクティビティを組み合せると、プロセスのWSDLポート・タイプでのリクエスト/レスポンス操作が形成されます。

図A-33 は、BPEL 2.0での「Reply」ダイアログを示しています。

図A-33 「Reply」ダイアログ

replyアクティビティの詳細は、次を参照してください。

- BPELプロセスの相互作用パターンの概要

- BPEL 2.0でのWSDLメッセージ・パートのマップ

- 「同期相互作用でフォルトを返す方法」

A.2.31 Rethrowアクティビティ

このアクティビティを使用すると、直接囲んでいるフォルト・ハンドラによって当初取得されたフォルトを再スローできます。

注意:

このアクティビティは、BPEL 2.0プロジェクトでのみサポートされます。

図A-34 に、フォルト・ハンドラ(catchアクティビティ)内部のrethrowアクティビティを示します。

図A-34 Rethrowアクティビティ

フォルトの再スローの詳細は、「rethrowアクティビティによるフォルトの再スロー」を参照してください。

A.2.32 Schedule Job

このアクティビティを使用して、BPELプロセス内でOracle Enterprise Schedulerジョブをスケジュールできます。図A-35 は、「ジョブのスケジュール」ダイアログを示しています。

図A-35 「ジョブのスケジュール」ダイアログ

詳細は、「BPELプロセスにおけるOracle Enterprise Schedulerジョブの起動」を参照してください。

A.2.33 Scopeアクティビティ

このアクティビティは、独自のローカル変数、フォルト・ハンドラ、補正ハンドラなどを含めることができる、ネストされたアクティビティの集合で構成されます。scopeアクティビティは、プログラミング言語の{ }ブロックに似ています。

各スコープには、その動作を定義するプライマリ・アクティビティがあります。1次アクティビティは、その中に多数のアクティビティが任意の深さにネストされている複雑な構造化アクティビティでもかまいません。スコープは、すべてのネストされたアクティビティによって共有されます。

図A-36 は、BPEL 2.0での「Scope」ダイアログを示しています。scopeアクティビティ内に適切なアクティビティを定義します。

図A-36 「Scope」ダイアログ

フォルト処理はscopeアクティビティに関連付けられています。その目的は、フォルトが発生したscopeアクティビティの失敗した不完全な処理を元に戻すことです。scopeアクティビティでcatchアクティビティを定義すると、カスタム・フォルト処理アクティビティのセットを作成できます。各catchアクティビティは、特定のタイプのフォルトを捕捉するように定義します。

図A-37 に、scopeアクティビティ内の「Catchの追加」アイコンを示します。図A-38 は、「Catchの追加」アイコンをクリックすると表示されるcatchアクティビティ領域を示しています。「アクティビティをここにドロップ」という領域に、追加のアクティビティをドラッグし、例外の捕捉と管理を行うフォルト処理ロジックを作成します。

たとえば、顧客は融資の申請の際に信用格付けサービスに社会保障番号を提示します。この番号を使用して信用調査が行われます。信用履歴に問題があることが確認された場合や、社会保障番号が無効であると認識された場合は、catchアクティビティ内のassignアクティビティにより、融資提案が却下されたことが顧客に通知されます。融資申請プロセス全体がterminateアクティビティで終了します。

図A-37 Catchブランチの作成

図A-38 Catchアクティビティ・アイコン

scopeアクティビティおよびフォルト処理の詳細は、次を参照してください。

- BPELプロセスの相互作用パターンの概要

- BPEL 2.0でのWSDLメッセージ・パートのマップ

- 「scopeアクティビティによるアクティビティ・グループの管理」

A.2.34 Sequenceアクティビティ

このアクティビティを使用すると、順に実行するアクティビティの集合を定義できます。たとえば、次のアクティビティを特定の順序で実行できます。

- receiveアクティビティで顧客リクエストを受信します。

- 同時動作を可能にするflowアクティビティ内でリクエストを処理します。

- replyアクティビティで、リクエストの最終承認ステータスを含むリプライ・メッセージを顧客に戻します。

sequenceアクティビティでは、リクエストを妥当な時間内に処理できると想定しています。この想定により、インボーカが同期レスポンスを待機する必要性が正当化されます(このサービスがリクエスト/レスポンス操作として提供されるため)。

この想定ができない場合は、顧客との相互作用を非同期メッセージ交換のペアとして定義することをお薦めします。

「Sequence」アイコンをダブルクリックすると、図A-39 に示すアクティビティ領域が表示されます。sequenceアクティビティ内に適切なアクティビティをドラッグして定義します。

図A-39 sequenceアクティビティ

sequenceアクティビティの詳細は、次を参照してください。

- BPELプロセスの相互作用パターンの概要

- パラレル・フローの作成

A.2.35 Signalアクティビティ

このアクティビティは、マスター・プロセスでは実行時に処理を実行するように詳細プロセスに通知するために使用し、詳細プロセスでは処理が完了したことをマスター・プロセスに通知するために使用します。図A-40 は、シグナルの編集ダイアログを示しています。

図A-40 「シグナル」ダイアログ

詳細は、「マスター・プロセスと詳細プロセスの調整」を参照してください。

A.2.36 SMSアクティビティ

このアクティビティを使用すると、イベントに関するショート・メッセージ・システム(SMS)通知を送信できます。

図A-41 は、BPEL 2.0における「SMS」ダイアログを示しています。

図A-41 「SMS」ダイアログ

SMSアクティビティの詳細は、「SMS通知チャネルの構成方法」を参照してください。

A.2.37 Switchアクティビティ

このアクティビティは、caseブランチに定義された1つ以上の条件付きブランチ(オプションでotherwiseブランチが続く)の順序付きリストで構成されます。ブランチは、出現順に考慮されます。条件がtrueである最初のブランチが選択され、switchに対して実行されるアクティビティを提供します。条件付きブランチが選択されない場合は、otherwiseブランチが選択されます。otherwiseブランチが明示的に指定されていない場合は、emptyアクティビティがあるotherwiseブランチが使用可能とみなされます。選択されたブランチのアクティビティが完了すると、switchアクティビティは完了します。

switchアクティビティは、flowアクティビティとは機能的に異なります。たとえば、flowアクティビティを使用すると、1つのプロセスで2つの融資提案を同時に収集できますが、それぞれの値は比較されません。2つの提案の値を比較して決定を下すには、switchアクティビティを使用します。定義された条件(caseブランチ内)が満たされると、最初のブランチが実行されます。条件が満たされない場合はotherwiseブランチが実行されます。

注意:

このアクティビティは、BPEL 2.0プロジェクトではifアクティビティに置き換えられます。

図A-42 に、次のブランチが定義されたswitchアクティビティを示します。

図A-42 Switchアクティビティ

switchアクティビティの詳細は、次を参照してください。

- BPELプロセスの相互作用パターンの概要

- 「BPEL 1.1のswitchアクティビティの作成による条件分岐の定義」

A.2.38 Terminateアクティビティ

このアクティビティでは、アクティビティのタスク(たとえば、catchブランチのフォルト処理タスク)を終了できます。たとえば、顧客の信用履歴に問題があることが確認された場合や、社会保障番号が無効であると認識された場合は、融資申請プロセスが終了し、顧客の融資申請の申込書は融資サービス業者に提出されません。

注意:

- terminateアクティビティは、BPEL 2.0プロジェクトではexitアクティビティに置き換えられます。

- タイムアウトになる可能性があるため、同期BPELプロセスでterminateアクティビティを使用しないでください。

図A-43 に、switchアクティビティのotherwiseブランチにある複数のterminateアクティビティを示します。

図A-43 Terminateアクティビティ

terminateアクティビティの詳細は、「BPEL 1.1のterminateアクティビティによるビジネス・プロセス・インスタンスの停止」を参照してください。

A.2.39 Throwアクティビティ

このアクティビティは、ビジネス・プロセス内からフォルトを生成します。

図A-44 は、BPEL 2.0の「Throw」ダイアログを示しています。

図A-44 「Throw」ダイアログ

throwアクティビティの詳細は、「throwアクティビティによる内部フォルトのスロー」を参照してください。

A.2.40 Translateアクティビティ

このアクティビティを使用して、インバウンド変換(doTranslateFromNative関数を自動的に使用)、またはアウトバウンド変換(doTranslateToNative関数を自動的に使用)を構成できます。

- インバウンド変換には、ネイティブ・フォーマットからXMLへの変換、および不透明型からXMLへの変換があります。

- アウトバウンド変換には、XMLからネイティブ・フォーマットへの変換、および大きなXMLからディレクトリ内の添付ファイルへの変換があります。

このアクティビティは、BPEL 1.1と2.0の両方でサポートされます。図A-45 は、「変換」ダイアログを示しています。

図A-45 「変換」ダイアログ

詳細は、「ネイティブ・データとXMLとの間における変換」を参照してください。

A.2.41 User Notificationアクティビティ

このアクティビティを使用すると、設計時に通知チャネルを明示的に選択せずに、通知を送信する必要性のみを示すBPELプロセスを設計できます。通知の送信に使用するチャネルは、Oracle User Messaging Serviceのユーザー・メッセージング・プリファレンス・ユーザー・インタフェースでエンド・ユーザーが定義したプリファレンスに基づいて、実行時に決定されます。したがって、通知チャネルの選択権は、Oracle BPELデザイナからエンド・ユーザーに移動します。エンド・ユーザーが優先チャネルまたはルールを選択していない場合、そのユーザーへの通知の送信には、デフォルトで電子メールが使用されます。図A-46 に詳細を示します。

図A-46 「ユーザー通知」ダイアログ

ユーザー通知の詳細は、「エンド・ユーザーによる通知チャネル選択の許可」を参照してください。

Oracle User Messaging Serviceの詳細は、『Oracle User Messaging Serviceの管理』および『Oracle User Messaging Serviceによるアプリケーションの開発』を参照してください。

A.2.42 Validateアクティビティ

このアクティビティを使用すると、リストの変数を検証できます。変数は、XMLスキーマと照合して検証されます。

図A-47 は、BPEL 2.0での「検証」ダイアログを示しています。

図A-47 「検証」ダイアログ

validateアクティビティの詳細は、「XMLデータの検証」を参照してください。

A.2.43 Voiceアクティビティ

このアクティビティを使用すると、イベントに関する電話ボイス通知を送信できます。

図A-48 は、「ボイス」ダイアログを示しています。

図A-48 「ボイス」ダイアログ

voiceアクティビティの詳細は、「ボイス通知チャネルの構成方法」を参照してください。

A.2.44 Waitアクティビティ

このアクティビティでは、一定期間内、または特定の期限に達するまでの遅延を指定できます。このアクティビティの典型的な用途は、一定の時間に操作を起動することです。このアクティビティを使用すると、指定された期間、または指定された時刻まで待機できます。有効期限条件を1つのみ指定する必要があります。

図A-49 は、BPEL 2.0での「待機」ダイアログを示しています。

図A-49 「待機」ダイアログ

waitアクティビティの詳細は、「waitアクティビティによる有効期限の設定」を参照してください。

A.2.45 Whileアクティビティ

このアクティビティは、指定された反復アクティビティの繰返し実行をサポートします。反復アクティビティは、特定のwhile条件がtrueでなくなるまで繰り返されます。

図A-50 は、BPEL 2.0での「while」ダイアログを示しています。このダイアログで式を入力できます。

図A-50 「while」ダイアログ

whileアクティビティの詳細は、「whileアクティビティによる条件分岐の定義」を参照してください。

A.2.46 XQuery Transformアクティビティ

このアクティビティを使用すると、ソース要素をターゲット要素にマップ(たとえば、受信した注文書データを送信する注文確認書データにマップ)するXQueryトランスフォーメーションを作成できます。

図A-51 は、BPEL 2.0での「XQuery」ダイアログを示しています。このダイアログでは、次のタスクを実行できます。

- マップするソースおよびターゲットの変数とパートを定義します。

- XQueryマッパー・ファイルを指定します。

- 「マッパー・ファイル」フィールドの右側にある2番目のアイコン(「追加」アイコン)をクリックして、XQueryマッパーにアクセスします。XQueryマッパーで、新規のXQueryファイルを作成し、ソース要素とターゲット要素をグラフィカルにマッピングします。既存のXQueryファイルを編集する場合は、「編集」アイコン(3番目のアイコン)をクリックします。

図A-51 「XQuery」ダイアログ

詳細は、「XQueryマッパーを使用したトランスフォーメーションの作成」を参照してください。

A.2.47 XSLT Transformアクティビティ

このアクティビティを使用すると、ソース要素をターゲット要素にマップ(たとえば、受信した注文書データを送信する注文確認書データにマップ)するXSLトランスフォーメーションを作成できます。

図A-52 は、BPEL 2.0での「変換」ダイアログを示しています。このダイアログでは、次のタスクを実行できます。

- マップするソースおよびターゲットの変数とパートを定義します。

- トランスフォーメーション・マッパー・ファイルを指定します。

- 「マッパー・ファイル」フィールドの右側にある2番目のアイコン(「追加」アイコン)をクリックして、XSLTマップ・エディタにアクセスして、新規のXSLファイルを作成し、ソース要素とターゲット要素をグラフィカルにマッピングします。既存のXSLファイルを編集する場合は、「編集」アイコン(3番目のアイコン)をクリックします。

図A-52 「変換」ダイアログ

transformアクティビティの詳細は、「XSLTマップ・エディタを使用したトランスフォーメーションの作成」を参照してください。

A.3 BPELサービスの概要

BPELプロセスは、SOAP Webサービス、Oracle ADFのビジネス・コンポーネント(BC)サービス、JCAアダプタ、Oracle B2Bサービス、Oracle Healthcareサービス、Oracle Business Activity Monitoring 11g、HTTPバインディング、直接バインディング、EJBサービス、RESTアダプタ、Oracle E-Business Suite、JDE World、SAP、クラウド・アダプタおよびパートナ・リンクを介してWebベースのアプリケーションおよびクライアントと通信できます。

BPELサービスにアクセスする手順は、次のとおりです。

1. Oracle BPELデザイナの「コンポーネント」ウィンドウで、「BPELサービス」を展開してサービスを表示します。

2. サービスを適切なスイムレーンにドラッグ・アンド・ドロップします。表A-2 に使用可能なサービスをリストし、これらのサービスについて説明されているドキュメントを参照先として示します。

表A-2 BPELサービス

BPELサービス

詳細の参照先

ADF-BCサービス

「ADF-BCサービス」

AQアダプタ

- 「AQアダプタ」

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

Oracle B2B

- 「Oracle B2B」

- Oracle B2Bユーザーズ・ガイド

Oracle Business Activity Monitoring (BAM) 11g

- 「Oracle BAM 11gアダプタ」

- Oracle BAMを使用したビジネス・アクティビティのモニタリング

Coherenceキャッシュ

- 「コヒーレンス・アダプタ」

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

データベース・アダプタ

- 「データベース・アダプタ」

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

直接バインディング・サービス

- 「直接バインディング・アダプタ」

- コンポジット・サービスの起動に直接バインディングを使用

- インフラストラクチャ管理のためのJava APIリファレンス

Oracle E-Business Suiteアダプタ

- Oracle E-Business Suiteアダプタ

- Oracle E-Business Suite Adapterユーザーズ・ガイド

EJBサービス

- 「EJBアダプタ」

- Enterprise JavaBeansとコンポジット・アプリケーションの統合

ファイル・アダプタ

- 「ファイル・アダプタ」

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

FTPアダプタ

- 「FTPアダプタ」

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

Healthcareアダプタ

- 「Oracle Healthcare Adapter」

- olink:HFPUG1732『Oracle SOA Suiteヘルスケア統合ユーザーズ・ガイド』

HTTPバインディング

「HTTPバインディング・サービス」

JDE Worldアダプタ

http://www.oracle.com/technetwork/middleware/adapters/documentation/index.html

JMSアダプタ

- 「JMSアダプタ」

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

LDAP

- 「LDAPアダプタ」

- Oracle Managed File Transferの使用

Oracle MFT

- 「Oracle MFT」

- Oracle Managed File Transferの使用

MQアダプタ

- 「MQアダプタ」

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

RESTサービス

REST操作とSOAコンポジット・アプリケーションとの統合

クラウド・アダプタ

「クラウド・アダプタ」

SAPアダプタ

http://www.oracle.com/technetwork/middleware/adapters/documentation/index.html

SOAP

- 「サービス・バインディング・コンポーネントの追加」

- 「SOAP Webサービス」

ソケット・アダプタ

- 「ソケット・アダプタ」

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

サード・パーティ・アダプタ

- 「サード・パーティ・アダプタ」

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

Oracle User Messaging Service

- 「Oracle User Messaging Serviceアダプタ」

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

B XPath拡張関数

この付録では、Oracle JDeveloperの「式ビルダー」ダイアログに表示されるXPath拡張関数について説明します。また、式ビルダーでのXPath式の作成方法、およびユーザー定義XPath拡張関数の作成方法についても説明します。Oracleには、新しい関数を追加するためにOracle SOA SuiteおよびXPath標準に組み込まれた機能を使用する、XPath関数が用意されています。

この付録の内容は次のとおりです。

- 拡張関数

- BPEL拡張関数

- BPEL XPath拡張関数

- 変換関数

- DVM関数

- データベース関数

- 日付関数

- アイデンティティ・サービス関数

- 論理関数

- 数学関数

- ノード・セット関数

- 文字列関数

- ワークフロー・サービス関数

- XREF関数

- Oracle JDeveloperの式ビルダーでのXPath式の構築

- ユーザー定義XPath拡張関数の作成

XPath関数の詳細は、次のURLを参照してください。

http://www.w3.org

B.1 拡張関数

この項では、拡張関数について説明します。

B.1.1 batchProcessActive

この関数は、バッチ内のアクティブ・プロセス数を返します。

シグネチャ:

ora:batchProcessActive(String rootId, String processId)

引数:

- rootId: ルートのID。

- processId: プロセスのID。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.2 batchProcessCompleted

この関数は、バッチ内の完了プロセス数を返します。

シグネチャ:

ora:batchProcessCompleted(String rootId, String processId)

引数:

- rootId: ルートのID。

- processId: プロセスのID。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.3 copyList

注意:

copyList関数を引き続き使用することもできますが、ノード・リストまたはノードのコピーにはbpelx:copyList拡張を使用することをお薦めします。詳細は、「bpelx:copyListの使用方法」を参照してください。

この関数は、ノード・リストまたはノードをコピーします。NULLまたは空のノード・リストはコピー先にできません。

シグネチャ:

ora:copyList('variableName', 'partName'?, 'locationPath'?, Object)

引数:

- variableName: データのソース変数。

- partName: 変数から選択するパート(オプション)。

- locationPath: パートを表すドキュメント・フラグメント内のサブツリーのルートを明確にした絶対ロケーション・パスを指定します(/により、パート全体を表す、ドキュメント・フラグメントのルートを表します。オプションです)。

- Object: リストまたは単一のアイテムを指定できます。リストを指定した場合は、リスト内の各アイテムがコピーされます。コピーされる各アイテムは、要素、または作成されるノードの文字列値を持つ要素です。

プロパティID:

- deprecated
リストに追加するには、bpelx:copyList拡張アクティビティを使用してください。

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.4 create-nodeset-from-delimited-string

この関数は、デリミタ付き文字列を入力としてとり、nodeSetを返します。

シグネチャ:

oraext:create-nodeset-from-delimited-string(qname, delimited-string, delimiter)

引数:

- qname: 作成するノードセット内ノードのすべてに付ける修飾名。QNameは、次の2つの形式で表現できます。

- task:assignee

- {http://mytask/task}assignee

- delimited-string: デリミタで区切られた複数の要素からなる文字列。

- delimiter: 入力文字列内の項目を区切る文字(たとえば、カンマやセミコロン)。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.1.5 createDelimitedString

この関数は、渡された引数から区切り文字付き文字列を作成します。

シグネチャ:

ora:createDelimitedString(delimiter as string, nodeList)

引数:

- delimiter as string: 入力文字列内の項目を区切る文字(たとえば、カンマやセミコロン)。

- nodeList: ノードの順序付きコレクションを示します。

プロパティID:

- namespace-uri:

- namespace-prefix:ora

B.1.6 createEssParameter

この関数は、Oracle Enterprise Scheduler内のジョブ用のパラメータを作成します。

シグネチャ:

ess:createEssParameter(dataType,name,scope,value)

引数:

- dataType

- name

- scope

- value

プロパティID:

- namespace-uri:

- namespace-prefix:ess

Oracle Enterprise Schedulerの詳細は、『Oracle Enterprise Schedulerアプリケーションの開発』を参照してください。

B.1.7 doStreamingTranslate

この関数は、ストリーミングXPath APIを使用して変換します。変換エンジンが変換の結果をメモリーにマテリアライズしないように、バッチ処理が使用されます。この結果、ギガバイト単位の大規模なペイロードを任意に処理できるようになります。ただし、処理できるのは、for-eachなど、順方向のみのXSLコンストラクトのみです。targetTypeには、SDOMまたはATTACHMENTを指定できます。

シグネチャ:

med:doStreamingTranslate('input','streaming xpath context','targetType','attachment element'?)

引数:

- input: XPath関数の入力データ。これはSDOMまたはattachment elementになります。

- streaming xpath context

- targetType: XPath関数がネイティブ・データをXMLに変換する方法を指定します。

- attachment element: 返されるXMLの添付ファイルです。このパラメータはオプションです。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: med

例:

med.doStreamingTranslate($in.request/inp1:request/inp1:sourceAttachmentElement,$in.request/inp1:request/inp1:streamingcontext, 'ATTACHMENT', $in.request/inp1:request/inp1:targetAttachmentElement)

B.1.8 doTranslateFromNative

この関数は、入力データをXMLに変換します。入力データには、変換する文字列、ファイルまたはFTPアダプタ添付ファイル、添付ファイル、またはBase64エンコード・データを含む要素を指定できます。targetTypeには、DOM、ATTACHMENTまたはSDOMを指定できます。

シグネチャ:

med:doTranslateFromNative('input','nxsdTemplate','nxsdRoot','targetType','attachment element'?)

引数:

- input: XPath関数の入力データ。データは、カンマ区切り値(CSV)などのネイティブ・フォーマットです。

- nxsdTemplate: 入力データからXMLフォーマットへの変換に使用するNXSDスキーマ。

- nxsdRoot: NXSDスキーマのルート要素。

- targetType: XPath関数がネイティブ・データをXMLに変換する方法を指定します。

- attachment element: 返されるXMLの添付ファイルです。このパラメータはオプションです。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: med

例:

med:doTranslateFromNative(string($in.request/inp1:request/inp1:source),'xsd/address_csv.xsd','Root-Element','DOM')

B.1.9 doTranslateToNative

この関数は、入力のDOMを文字列または添付ファイルに変換します。targetTypeは、STRINGまたはATTACHMENTです。

シグネチャ:

med:doTranslateToNative('input','nxsdTemplate','nxsdRoot','targetType','attachment element'?)

引数:

- input: XPath関数の入力データ。このデータには、カンマ区切り値(CSV)などのネイティブ・フォーマットに変換する必要があるDOMまたはSDOMデータを使用できます。
入力ノードは通常、次の例に示すように、受信するDOMのルート要素です。

med:doTranslateToNative($in.request/inp1:Root-Element, 'xsd/address_csv.xsd',
@ 'Root-Element','STRING')"

ただし、次の例に示すように、入力ノードとして受信するDOMのルート要素ではなくサブ要素を使用することもできます。

med:doTranslateToNative($in.request/inp1:requestToNative/ns1:Root-Element,
'xsd/address_csv.xsd', 'Root-Element','ATTACHMENT',
$in.request/inp1:requestToNative/inp1:attachment)

この場合、次に示すように、NXSDのスキーマ・ノードでuseArrayIdenitiferプロパティをtrueに設定する必要があります。

nxsd:useArrayIdentifiers="true"

入力が大規模な場合は、この設定によってこの関数のパフォーマンスに悪影響を与える可能性があります。その場合は、dostreamingxlate関数を使用できます。

- nxsdTemplate: 入力データからXMLフォーマットへの変換に使用するNXSDスキーマ。

- nxsdRoot: NXSDスキーマのルート要素。

- targetType: XPath関数がネイティブ・データをXMLに変換する方法を指定します。

- attachment element: 返されるXMLの添付ファイルです。このパラメータはオプションです。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: med

例:

med:doTranslateToNative($in.request/inp1:Root-Element,'xsd/address_csv.xsd','Root-Element','STRING')

B.1.10 format

この関数は、Javaのメッセージ書式を使用してメッセージを書式設定します。

シグネチャ:

ora:format(formatStrings, args+)

引数:

- formatStrings: 書式設定するデータの文字列。

- args+: 書式文字列の書式指定子によって参照される引数。引数が書式指定子よりも多い場合、余分な引数は無視されます。引数の数は変数で、0(ゼロ)の場合があります。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.11 genEmptyElem

この関数は、指定されたQNameに対する空要素のリストを生成します。

シグネチャ:

ora:genEmptyElem('ElemQName',size?, 'TypeQName'?, xsiNil?)

引数:

- ElemQName: 最初の引数は、空要素のQNameです。

- size: 2番目の引数は整数型で、空要素の数を示します(オプション)。指定されていない場合、デフォルトのサイズは1です。

- TypeQName: 3番目の引数は、生成される空の名前のxsi:typeとなるQNameです(オプション)。このxsi:typeパターンは、SOAPENC:Arrayに相当します。指定されていないか、空の文字列である場合、xsi:type属性は生成されません。

- xsiNil: 4番目の引数はブール型で、生成される空の要素において、XSD-nillableである場合に、XSI - nilにするかどうかを指定します(オプション)。デフォルトは、falseです。指定されていないか、falseである場合、xsi:nilは生成されません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

この関数の詳細は、「空要素の配列と等価の機能の生成」を参照してください。

B.1.12 generate-guid

この関数は、一意のGUIDを生成します。

シグネチャ:

oraext:generate-guid()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.1.13 get-content-from-file-function

この関数は、指定されているネイティブ・フォーマットのファイルを解析します。この関数は、BPELプロセスのassignアクティビティを設計する場合に使用します。

シグネチャ:

oraext:get-content-from-file-function(fileName, nxsdTemplate?, nxsdRoot?)

例:

oraext:get-content-from-file-function("file:/c:/Ftab.txt",

"file:/c:/Ftab_1.xsd","root")

引数:

- fileName: ファイルの名前。

- nxsdTemplate: 出力のネイティブXSD (NXSD)テンプレート。

- nxsdRoot-: NXSDルート。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.1.14 getApplicationName

この関数は、アプリケーション名を返します。

シグネチャ:

ora:getApplicationName()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.15 getAttachmentContent

この関数は、href関数から添付ファイルのコンテンツを取得します。

シグネチャ:

ora:getAttachmentContent(varName[, partName[, query]])

引数:

- varName: データのソース変数を指定します。

- partName: 変数から選択するパートを指定します(オプション)。

- query: 絶対ロケーション・パスを指定して(/は、パート全体を表す文書フラグメントのルートを意味する)、パートを表す文書フラグメント内のサブツリーのルートを識別します(オプション)。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

詳細は、「SOAPアタッチメントのコンテンツの読取りおよびエンコード」を参照してください。

B.1.16 getAttachmentProperty

varName、partNameおよびqueryに格納されているhrefからSOAPアタッチメントのプロパティを取得します。

シグネチャ: ora:getAttachmentProperty(propertyName, varName[, partName[, query]])

引数:

- varName: データのソース変数を指定します。

- partName: 変数から選択するパートを指定します(オプション)。

- query: 絶対ロケーション・パスを指定して(/は、パート全体を表す文書フラグメントのルートを意味する)、パートを表す文書フラグメント内のサブツリーのルートを識別します(オプション)。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.17 getChildElement

この関数は、指定された要素の子要素を取得します。

シグネチャ:

ora:getChildElement(element, index)

引数:

- element: データのソース。

- index: 子要素の索引の整数値。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.18 getComponentInstanceID

この関数は、コンポーネント・インスタンスIDを返します。

シグネチャ:

ora:getComponentInstanceID()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.19 getComponentName

この関数は、コンポーネント名を返します。

シグネチャ:

mdhr:getComponentName()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri:http://schemas.oracle.com/xpath/extension

- namespace-prefix: mdhr

B.1.20 getCompositeInstanceID

注意:

この関数は、12cリリース1 (12.1.3)では非推奨になり、式ビルダーには表示されません。

この関数は、コンポジット・インスタンスIDを返します。

シグネチャ:

ora:getComponentInstanceId()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri:http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.21 getCompositeName

この関数は、コンポジット名を返します。

シグネチャ:

ora:getCompositeName()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.22 getCompositeURL

この関数は、コンポジットURLを返します。

シグネチャ:

ora:getCompositeURL()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri:http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.23 getECID

この関数は、実行コンテキストID (ECID)を返します。

シグネチャ:

ora:getECID()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.24 getFaultAsString

この関数は、フォルトを文字列値として返します。

シグネチャ:

ora:getFaultAsString()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

詳細は、「getFaultAsString XPath拡張関数によるフォルト詳細の取得」を参照してください。

B.1.25 getFaultAsXML

この関数は、XML要素としてフォルトを返します。

シグネチャ:

ora:getFaultAsXML()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix:ora

B.1.26 getFaultName

この関数は、フォルト名を返します。

シグネチャ:

ora:getFaultName()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.27 getMilestoneName

この関数は、マイルストーン名を返します。

シグネチャ:

ora:getMilestoneName

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.28 getOwnerDocument

この関数は、ノードに関連付けられているドキュメント・オブジェクトを返します。

シグネチャ:

ora:getOwnerDocument(node)

引数:

- node: XMLノードを指定します。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.29 getParentComponentInstanceID

この関数は、BPELプロセス・インスタンスの親コンポーネント・インスタンスIDを返します。

シグネチャ:

ora:getParentComponentInstanceID()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.30 getRevision

この関数は、引数を取らず、起動されたコンポジットから現行リビジョンを返します。

シグネチャ:

ora:getRevision

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.31 getTaskReminderDuration

この関数は、タスクに送信する次のリマインダを計算します。

シグネチャ:

ora:getTaskReminderDuration(taskId)

引数:

- taskId: タスクのタスクID。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.32 instanceOf

この関数は、BPEL変数から任意の値を抽出します。

シグネチャ:

ora:instanceOf(an_xpath_expression, 'typeQName')

引数:

- an_xpath_expression: 要素を返すXPath式。

- typeQName - グローバル宣言済XSDタイプのQName。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.1.33 lookup-xml

この関数は、XMLファイル(docURL)で、親XPath (parentXPath)、キーXPath (keyXPath)およびキー値(key)を指定されたlookupXPathで定義されている要素の文字列値を返します。

例:

oraext:lookup-xml('file:/d:/country_data.xml', '/Countries/Country', 'Abbreviation', 'FullName', 'UK')は、ファイルD:\country_data.xmlで、Abbreviation = 'UK'である/Countries/Countryの子要素FullNameの値を返します。

シグネチャ:

oraext:lookup-xml(docURL, parentXPath, keyXPath, lookupXPath, key)

引数:

- docURL: XMLファイル。

- parentXPath: 親XPath。

- keyXPath: キーXPath。

- lookupXPath: 参照XPath。

- key: キー値。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.1.34 parseEscapedXML

この関数は、文字列をDOMに解析します。

注意:

この関数は、「BPEL XPath拡張関数」オプションの下にも選択対象として表示されます。

シグネチャ:

oraext:parseEscapedXML(contentString)

引数:

- contentString: DOMに解析する文字列。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: oraext

この関数の詳細は、「文字列からXML要素への変換方法」を参照してください。

B.1.35 parseXML

この関数は、文字列をDOM要素に解析します。

シグネチャ:

oraext:parseXML(contentString)

引数:

- contentString: DOM要素に解析する文字列。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.1.36 processScalableDocumentToNative

この関数は、拡張可能なドキュメントを出力ストリームに直接変換します。

シグネチャ:

ora:processScalableDocumentToNative(template, input, outputFilePath, nxsd, root, batchsize, properties)

引数:

- template

- input

- outputFilePath

- nxsd

- root

- batchsize

- properties

B.1.37 processXSLTAttachmentFromNativeToNative

この関数は、インバウンド・ネイティブ・データを変換し(たとえば、カンマ区切り値からXMLへ)、変換されたコンテンツにユーザー提供のXSLを適用します。その後、XSL変換の結果はネイティブ・ファイル(たとえば、カンマ区切りの値)に変換されます。このXPath関数への入力は、添付ファイルまたはhrefのどちらかです。変換エンジンが変換の結果をメモリーに格納しないように、バッチ処理が使用されます。この結果、ギガバイト単位の大規模なペイロードを任意に処理できるようになります。XPath関数は、インバウンド・ネイティブ・データをXMLに変換し、XMLに対して変換を実行してから、変換済XMLをネイティブ・フォーマットに変換します。

シグネチャ:

ora:processXSLTAttachmentFromNativeToNative(template, input href, output href, input nxsd path, input root element name, output nxsd path, output root element name. batch size)

B.1.38 processXSLTAttachmentFromNativeToStream

この関数は、インバウンド・ネイティブ・データを変換し(たとえば、カンマ区切り値からXMLへ)、変換されたコンテンツにユーザー提供のXSLを適用します。変換の出力は、出力ファイルにストリーミングされます。このXPath関数への入力は、添付ファイルまたはhrefのどちらかです。変換エンジンが変換の結果をメモリーに格納しないように、バッチ処理が使用されます。この結果、ギガバイト単位の大規模なペイロードを任意に処理できるようになります。ただし、処理できるのは、for-eachなど、順方向のみのXSLコンストラクトのみです。

シグネチャ:

ora:processXSLTAttachmentFromNativeToStream(template,input href, output href, input nxsd path, nxsd root element name, batchsize,properties)

B.1.39 processXSLTAttachmentToNativeStream

この関数は、ユーザー提供のXSLを適用してインバウンドXMLを変換してから、変換済XMLをネイティブ・ファイル(たとえば、カンマ区切りの値)に変換します。このXPath関数への入力は、添付ファイルまたはhrefのどちらかです。変換エンジンが変換の結果をメモリーに格納しないように、バッチ処理が使用されます。この結果、ギガバイト単位の大規模なペイロードを任意に処理できるようになります。この関数は、まずXSLを適用して受信XMLデータを変換してから、変換済XMLをネイティブ・データに変換します。

シグネチャ:

ora:processXSLTAttachmentToNativeStream(template, input href, output href, nxsd schema, nxsd root element, batch size)

B.1.40 processXSLTAttachmentToStream

この関数は、XSLT変換の結果を出力ファイルに直接ストリーミングします。このXPath関数への入力は、添付ファイルまたはhrefのどちらかです。変換エンジンが変換の結果をメモリーに格納しないように、バッチ処理が使用されます。この結果、ギガバイト単位の大規模なペイロードを任意に処理できるようになります。ただし、処理できるのは、for-eachなど、順方向のみのXSLコンストラクトのみです。

シグネチャ:

ora:processXSLTAttachmentToStream(template, input href, output href, batchsize, properties)

B.1.41 processXSLTForScalableDocument

この関数は、XSLT変換後の拡張可能なドキュメントを返します。

シグネチャ:

ora:processXSLTForScalableDocument(template, input, batchsize, properties)

B.1.42 setCompositeInstanceTitle

この関数は、コンポジット・インスタンス・タイトルを設定し、そのタイトルを返します。

シグネチャ:

ora:setCompositeInstanceTitle(title)

引数:

- title: コンポジット・インスタンス・タイトル。

B.2 BPEL拡張関数

この項では、BPEL拡張関数について説明します。

B.2.1 BPEL 1.1とBPEL 2.0におけるBPEL拡張関数

この項では、BPEL拡張関数について説明します。

表B-1 に、BPEL仕様のバージョン1.1または2.0でサポートされているBPEL拡張関数をリストします。関数が特定のバージョンでサポートされている場合には、Oracle JDeveloperで「式ビルダー」ダイアログの「BPEL拡張関数」リストに選択対象として表示されます。それ以外の場合は表示されません。BPELバージョン1.1の関数は、ネームスペース接頭辞bpwsを使用します。BPELバージョン2.0の関数は、ネームスペース接頭辞bpelを使用します。

表B-1 BPEL 1.1またはBPEL 2.0でサポートされているBPEL拡張関数

関数

BPEL 1.1でサポートされているか

BPEL 2.0でサポートされているか

bpws:getLinkStatus

はい

いいえ

bpws:getVariableData

はい

いいえ

getVariableProperty

はい

いいえ

bpel:getVariableProperty

いいえ

はい

bpel:doXslTransform

いいえ

はい

B.2.1.1 getLinkStatus

この関数は、リンクのステータスを示すブール値を返します。リンクのステータスが正の場合、この値はtrueになります。そうでない場合はfalseです。この関数はjoin条件でのみ使用できます。

linkName引数は、join条件に関連付けられたアクティビティの着信リンクの名前を表します。

シグネチャ:

bpws:getLinkStatus ('linkName')

引数:

- variableName: データのソース変数。

- propertyName: プロパティのQName。

プロパティID:

- namespace-uri: http://schemas.xmlsoap.org/ws/2003/03/business-process/

- namespace-prefix: bpws

B.2.1.2 getVariableData

この関数は、BPEL変数から任意の値を抽出します。

第1引数のみが指定されている場合は、変数の値を抽出しますが、変数はXMLスキーマの単純型または要素を使用して定義されている必要があります。それ以外の場合、この関数の戻り値は、メッセージ・タイプのパート全体(第2引数が指定され、第3引数が指定されない場合)、またはlocationPathに基づく選択の結果(オプションの引数が両方とも指定されている場合)を表す単一ノードが含まれるノードセットです。

シグネチャ:

bpws:getVariableData ('variableName', 'partName'?, 'locationPath'?)

引数:

- variableName: データのソース変数。

- partName: 変数から選択するパート(オプション)。

- locationPath: パートを表すドキュメント・フラグメント内のサブツリーのルートを明確にした絶対ロケーション・パスを指定します(/により、パート全体を表す、ドキュメント・フラグメントのルートを表します。オプションです)。

プロパティID:

- namespace-uri: http://schemas.xmlsoap.org/ws/2003/03/business-process/

- namespace-prefix: bpws

B.2.1.2.1 結果ノードセットのサイズが実行時に選択されるノードセットのサイズと異なる場合にスローされるselectionFailureフォルト

に従って、locationPath引数によって選択されるノードセットのサイズが実行時に選択されるノードセットのサイズと異なる場合は、準拠実装により標準のフォルトbpws:selectionFailureがスローされる必要があります。

たとえば、次のコードに示すcount()関数は、StoreRequestの下にproduct要素のエントリが複数ある場合に機能せず、selectionFailureフォルトがスローされます。

count(bpws:getVariableData('inputVariable',
'payload','/ns2:StoreRequest/ns2:product'))

この関数を機能させるには、構文を次のように変更します。

"count($inputVariable.payload/ns2:product)"

B.2.1.3 getVariableProperty (BPEL 1.1)

この関数は、BPEL変数から任意の値を抽出します。第1引数ではデータのソース変数を指定し、第2引数ではその変数から選択するプロパティのQNameを指定します。特定のプロパティが、実行中に1以外のサイズのノードセットを選択する場合、標準フォルトbpws:selectionFailureがスローされます。

シグネチャ:

bpws:getVariableProperty ('variableName', 'propertyname')

引数:

- variableName: データのソース変数。

- propertyName: プロパティのQName。

プロパティID:

- namespace-uri: http://schemas.xmlsoap.org/ws/2003/03/business-process/

- namespace-prefix: bpws

B.2.1.4 getVariableProperty (BPEL 2.0)

この関数は、BPEL変数から任意の値を抽出します。第1引数ではデータのソース変数を指定し、第2引数ではその変数から選択するプロパティのQNameを指定します。特定のプロパティが、実行中に1以外のサイズのノードセットを選択する場合、標準フォルトbpws:selectionFailureがスローされます。

シグネチャ:

bpel:getVariableProperty ('variableName', 'propertyname')

引数:

- variableName: データのソース変数。

- propertyName: プロパティのQName。指定されたプロパティによって選択されるノードセットのサイズが実行時に選択されるノードセットのサイズと異なる場合は、標準のフォルトselectionFailureがスローされます。

プロパティID:

- namespace-uri: http://schemas.xmlsoap.org/ws/2003/03/business-process/

- namespace-prefix: bpel

B.2.1.5 doXslTransform (BPEL 2.0)

この関数は、複数のソースによるXSLT変換の結果を返します。

注意:

入力がXMLドキュメントである場合、ora:getOwnerDocumentをコールして入力をラップするか、この関数のかわりに関数ora:doXSLTransformForDocを使用します。

シグネチャ:

bpel:doXslTransform(template,input, [paramQName, paramValue]*)

B.3 BPEL XPath拡張関数

この項では、BPEL XPath拡張関数について説明します。

B.3.1 addQuotes

この関数は、stringの内容を一重引用符で囲んで返します。

シグネチャ:

ora:addQuotes(string)

引数:

- string: 引用符を追加する文字列。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.2 authenticate

この関数はLDAPユーザーを認証し、trueまたはfalseを返します。

authenticate、listUsers、lookupUser、searchのXPath関数は、LDAPサーバーからの情報(通常はLDAPユーザーの詳細)を取得する参照と検索の機能を提供します。

これらのXPath関数は、構成ファイルを使用してJNDIのサーバー・アクセス情報を取得します(たとえば、コンテキスト・ファクトリ、LDAPサーバーのプロバイダURL、認証タイプなど)。構成ファイルはdirectories.xmlという名前で、BPELプロジェクトの.bpelファイルと同じディレクトリに格納されている必要があります。これらのXPath関数をコールするには、このファイルを用意する必要があります。

次の例に、directories.xmlファイルの形式を示します。

<?xml version="1.0" ?>
<directories>
<directory name='people'>
<property name="java.naming.provider.url">ldap://servername:port</property>
<property
name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</property>
<property name="java.naming.security.principal">[username]</property>
<property name="java.naming.security.authentication">simple</property>

<property name="java.naming.security.credentials">[passord]</property>
<property name="entryDN">[entry dn]</property>

</directory>
</directories>

directories.xmlファイルの例を次に示します。

<?xml version="1.0" ?>
<directories>
<directory name='people'>
<property
name="java.naming.provider.url">ldap://myhost.us.example.com:7001</property>
<property
name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</property>
<property name="java.naming.security.principal">cn=admin</property>
<property name="java.naming.security.credentials">weblogic</property>
<property name="java.naming.security.authentication">simple</property>
<property name="entryDN">ou=people,ou=myrealm,dc=soainfra</property>
</directory>
</directories>

- シグネチャ:

ldap:authenticate('directoryName','userId','password')

- パラメータ:

- directoryName: directories.xmlファイルで指定されているディレクトリ名。

- userId: LDAPサーバー・ログインのユーザーID。

- password: LDAPサーバー・ログインのパスワード。

- 戻り値:
trueまたはfalse

例:

ldap:authenticate('people','weblogic','weblogic')

このXPath関数の場合、directories.xmlファイルで指定する必要があるプロパティは2つだけです。

- java.naming.provider.url

- java.naming.factory.initial

B.3.3 countNodes

注意:

countNodes関数を引き続き使用することもできますが、要素のサイズを整数として返すには、バージョン1.0のXPath count()関数を使用することをお薦めします。

この関数は、要素のサイズを整数として返します。

シグネチャ:

ora:countNodes('variableName', 'partName'?, 'locationPath'?)

引数:

- variableName: データのソース変数。

- partName: 変数から選択するパート(オプション)。

- locationPath: パートを表すドキュメント・フラグメント内のサブツリーのルートを明確にした絶対ロケーション・パスを指定します(/により、パート全体を表す、ドキュメント・フラグメントのルートを表します。オプションです)。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.4 doXSLTransform

この関数は、XSLTの複数パラメータをサポートするWS-BPEL 2.0のdoXSLTransform機能を実装します。この関数を使用する場合は、XSL template matchをルート(/)に設定しないでください。ルート要素に設定する必要があります。

シグネチャ:

ora:doXSLTransform('url_to_xslt',input,['paramQname',paramValue]*)

引数:

- url_to_xslt: XSLスタイルシートのURLを指定します。

- input: 入力変数名を指定します。

- paramQname: パラメータQNameを指定します。

- paramValue: パラメータ値を指定します。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.5 doXSLTransformForDoc

この関数は、doXSLTransform()の補完XPath関数です。目的は、XSLTテンプレートがドキュメントに一致したときにトランスフォーメーションを実行することです。

次にdoXSLTransformForDoc関数の例を示します。

<function name="ora:doXSLTransformForDoc">
<className>com.collaxa.cube.xml.xpath.functions.xml.DoXSLTransformForDocument
</className>
<return type="node-set"/>
<params>
<param name="template" type="string"/>
<param name="input" type="string"/>
<param name="properties" type="string" minOccurs="0" maxOccurs="unbounded"/>
</params>
<desc resourceKey="PI_FUNCTION_DESC_DOXSLTRANSFORM_FOR_DOC"></desc>
<detail resourceKey="PI_FUNCTION_DESC_LONG_DOXSLTRANSFORM_FOR_DOC">
This function is a complement xpath function to doXSLTransform(). It aims
to do the transformation when the xslt template matching the
document. The signature of this function is <i>ora:doXSLTransformForDoc('url_to_
xslt',input,['paramQname',paramValue]*)</i>.
</detail>
<group>BPEL XPath Extension Functions</group>
</function>

シグネチャ:

ora:doXSLTransformForDoc('url_to_xslt',input,['paramQname',paramValue]*)

引数:

- url_to_xslt: XSLスタイルシートのURLを指定します。

- input: 入力変数名を指定します。

- paramQname: パラメータQNameを指定します。

- paramValue: パラメータ値を指定します。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

ora:doXSLTransformForDoc関数を使用すると、大きいXSLT/XQuery操作の結果をシステム・ディレクトリの一時ファイルに書き込むことができます。その後、ドキュメントは必要なときに一時ファイルからロードされます。これにより、ドキュメント全体をバイナリXMLとしてメモリーにキャッシュする必要がなくなります。

詳細は、「XPath関数を使用し、大きいXSLT/XQuery出力をファイル・システムに書き込み」を参照してください。

B.3.6 doc

この関数は、XMLファイルのコンテンツを返します。

シグネチャ:

ora:doc('fileName','xpath'?)

引数:

- fileName: XMLファイルの名前。

- xpath: XMLファイルの一部(ノードセット、ノード・リスト、リーフ・ノードなど)。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.7 formatDate

この関数は、標準XSD日付書式を出力に適した文字に変換します。

シグネチャ:

ora:formatDate('dateTime', 'format')

引数:

- dateTime: XSD書式の日付関連値を指定します。引数が文字列でない場合、この関数は、string()関数が適用された場合と同じように動作します。引数が日付でない場合、出力は空の文字列になります。引数が有効なXSD日付で、フィールドの一部が空の場合は、未指定のフィールドの充填が試みられます。たとえば、2003-06-10T15:56:00のようになります。

- format: java.text.SimpleDateFormat書式に従って書式設定された文字列を指定します。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.8 generateGUID

一意のGUIDを生成します。

シグネチャ:

ora:generateGUID()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.9 getConfigProperty

この関数は、コンポーネントのプロパティ値を取得します。

シグネチャ:

ora:getConfigProperty(propertyName)

引数:

- propertyName: プロパティ名。

B.3.10 getContentAsString

この関数は、要素のコンテンツをXML文字列として返します。

シグネチャ:

ora:getContentAsString(element elementAsNodeList)

引数:

- element: 要素(データのソース)。

- elementAsNodeList: ノード・リストとしての要素。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.11 getConversationId

この関数は、対話IDを返します。

シグネチャ:

ora:getConversationId()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.12 getCreator

この関数は、インスタンスの作成者を返します。

シグネチャ:

ora:getCreator()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.13 getCurrentDate

この関数は、現在の日付を文字列として返します。

シグネチャ:

ora:getCurrentDate('format'?)

引数:

- format: java.text.SimpleDateFormat書式に従って書式設定された文字列を指定します(オプション)。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

詳細は、「日付または時間を割り当てる方法」を参照してください。

B.3.14 getCurrentDateTime

この関数は、現在の日時を文字列として返します。

シグネチャ:

ora:getCurrentDateTime('format'?)

引数:

- format: java.text.SimpleDateFormat書式に従って書式設定された文字列を指定します(オプション)。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.15 getCurrentTime

この関数は、現在の時間を文字列として返します。

シグネチャ:

ora:getCurrentTime('format'?)

引数:

- format: java.text.SimpleDateFormat書式に従って書式設定された文字列を指定します(オプション)。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.16 getElement

この関数は、要素の配列から、indexを使用して要素を返します。

シグネチャ:

ora:getElement('variableName', 'partName', 'locationPath', index)

引数:

- variableName: データのソース変数。

- partName: 変数から選択するパート(必須)。

- locationPath: パートを表すドキュメント・フラグメント内のサブツリーのルートを明確にした絶対ロケーション・パスを指定します(/により、パート全体を表す、ドキュメント・フラグメントのルートを表します。必須です)。

- index: 動的索引値。最初のノードの索引は1です。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.17 getInstanceId

この関数は、インスタンスIDを返します。

シグネチャ:

ora:getInstanceId()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.18 getNodeValue

この関数は、DOMノードの値を文字列として返します。

シグネチャ:

ora:getNodeValue(node)

引数:

- node: DOMノード。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.19 getNodes

この関数は、ノード・リストを取得します。これは、ノード・リストを返さないbpws:getVariableDataの代用として実装されます。

シグネチャ:

ora:getNodes('variableName', 'partName'?, 'locationPath'?)

引数:

- variableName: データのソース変数。

- partName: 変数から選択するパート(オプション)。

- locationPath: パートを表すドキュメント・フラグメント内のサブツリーのルートを明確にした絶対ロケーション・パスを指定します(/により、パート全体を表す、ドキュメント・フラグメントのルートを表します。オプションです)。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.20 getPreference

この関数は、BPELスーツケース・ディスクリプタのpreferencesセクションで指定されているプロパティの値を返します。

シグネチャ:

ora:getPreference(preferenceName)

引数:

- preferenceName: BPELスーツケース・ディスクリプタで指定されているプリファレンスの名前。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.21 getProcessId

この関数は、現在のBPELプロセスのIDを返します。

シグネチャ:

ora:getProcessId()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.22 getProcessOwnerId

この関数は、プロセスの所有者であるユーザーがBPELスーツケース・ディスクリプタのTaskServiceAliasesセクションで指定されている場合に、そのユーザーのIDを返します。

シグネチャ:

ora:getProcessOwnerId()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.23 getProcessURL

この関数は、現在のBPELプロセスのルートURLを返します。

シグネチャ:

ora:getProcessURL()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.24 getProcessVersion

この関数は、現在のプロセス・バージョンを返します。

シグネチャ:

ora:getProcessVersion()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.25 integer

この関数は、ノードのコンテンツを整数として返します。

シグネチャ:

ora:integer(node)

引数:

- node: 入力ノード。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.26 listUsers

この関数はLDAPユーザーのリストを返します。

シグネチャ:

ldap:listUsers('directoryName',filter')

引数:

- directoryName: directories.xmlファイルで指定されているディレクトリ名。directories.xmlファイルの詳細は、「authenticate」を参照してください。

- filter: 検索に使用するフィルタ式で、この値をnullにすることはできません。

戻り値:

ユーザーのリストを含むXML要素。このXPath関数の場合は、すべてのプロパティをdirectories.xmlファイルで指定する必要があります。

例:

ldap:listUsers('people','ou=people');

次に、出力の例を示します。

<users xmlns="http://schemas.oracle.com/bpel/ldap">
<user dn="uid=weblogic">
<uid>weblogic</uid>
<userpassword>
Unknown macro: {ssha}

bHDVJRfWVt/Uwlzb4TKU+QTOLB4FLySO</userpassword>

<objectclass>inetOrgPerson</objectclass>
<objectclass>organizationalPerson</objectclass>
<objectclass>person</objectclass>
<objectclass>top</objectclass>
<objectclass>wlsUser</objectclass>
<description>This user is the default administrator.</description>
<wlsMemberOf>cn=Administrators,ou=groups,ou=myrealm,dc=soainfra</wlsMember
Of>
<orclguid>8AC1B6206FDD11DEBF9A7F3D47003274</orclguid>
<sn>weblogic</sn>
<cn>weblogic</cn>
</user>
</users>

B.3.27 lookupUser

この関数はLDAPユーザー情報を返します。

シグネチャ:

ldap:lookupUser('directoryName','userId')

引数:

- directoryName: directories.xmlファイルで指定されているディレクトリ名。directories.xmlファイルの詳細は、「authenticate」を参照してください。

- userId: 検索するユーザーID。

戻り値:

ユーザー情報を含むXML要素です。

このXPath関数の場合は、すべてのプロパティをdirectories.xmlファイルで指定する必要があります。

例:

ldap:lookupUser('people','ou=people');

次に、出力の例を示します。

<user dn="" xmlns="http://schemas.oracle.com/bpel/ldap">
<ou>people</ou>
<objectclass>organizationalUnit</objectclass>
<objectclass>top</objectclass>
<orclguid>8ABB9BA06FDD11DEBF9A7F3D47003274</orclguid>
</user>

B.3.28 parseEscapedXML

この関数は、XML文字列をXML要素に解析します。

注意:

この関数は、「拡張関数」オプションの下にも選択対象として表示されます。

シグネチャ:

ora:parseEscapedXML(xmlString)

引数:

- xmlString: この関数がDOMに解析する文字列。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

この関数の詳細は、「文字列からXML要素への変換方法」を参照してください。

B.3.29 processXQuery

この関数は、XQueryトランスフォーメーションの結果を返します。

シグネチャ:

ora:processXQuery('template','context'?)

引数:

- template: XSLTテンプレート。

- input: 変換する入力データ。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.30 processXQuery10

この関数は、XQuery 1.0トランスフォーメーションの結果を返します。

シグネチャ: ora:processXQuery10(<path to xquery> [, <xquery external variable name>, <value>]*)

B.3.31 processXQuery2004

この関数は、XQuery 2004トランスフォーメーションの結果を返します。

シグネチャ: ora:processXQuery2004(template,context?)

B.3.32 processXSLT

この関数は、Oracle XDK XSLTプロセッサを使用してXSLTトランスフォーメーションの結果を返します。

次の例は、12cバージョンのprocessXSLTを示しています。

<function name="ora:processXSLT">
<className>com.collaxa.cube.xml.xpath.functions.xml.GetElementFromXDKXSLTFunction
</className>
<return type="node-set"/>
<params>
<param name="template" type="string"/>
<param name="input" type="string"/>
<param name="properties" type="string" minOccurs="0" maxOccurs="unbounded"/>
</params>
<desc resourceKey="PI_FUNCTION_DESC_PROCESSXSLT"></desc>
<detail resourceKey="PI_FUNCTION_DESC_LONG_PROCESSXSLT">
This function returns result of XSLT transformation by using Oracle XDK
XSLT processor.
</detail>
<group>BPEL XPath Extension Functions</group>
</function>

シグネチャ:

- 12cバージョンのシグネチャ:
ora:processXSLT('template','input','properties'?)

引数:

- template: XSLTテンプレート。HTTP URLとファイルURLの両方がサポートされています。

- input: 変換する入力データ。

- properties: コンストラクト<xsl:param name="paramName"/>を使用してXSLマップ内でアクセスできるXSLパラメータに変換されるプロパティ。プロパティは次のように定義されます。

1. params.xsdファイルを作成し、名前/値ペアを定義します(どのプロパティも名前と値のペアです)。次に例を示します。

<?xml version="1.0" encoding="windows-1252" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.oracle.com/service/bpel/common"
targetNamespace="http://schemas.oracle.com/service/bpel/common"
elementFormDefault="qualified">
<!-- Root Element for Parameters -->
<xsd:element name="parameters">
<xsd:complexType>
<xsd:sequence>
<!-- Each Parameter is represented by an "item" node that contains
one unique name and a string value
-->
<xsd:element name="item" minOccurs="1" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="value" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

2. SetParams.xslファイルを作成してプロパティを移入します。XSLT内では、パラメータにはその名前を通じてアクセスできます。この例では、パラメータ名がuserNameとlocationで、それぞれの値がjsmithとCAです。

<?xml version="1.0" encoding="UTF-8" ?>
<?oracle-xsl-mapper
<mapSources>
<source type="XSD">
<schema location="TestXSLParams.xsd"/>
<rootElement name="TestXSLParamsProcessRequest"
namespace="http://xmlns.oracle.com/TestXSLParams"/>
</source>
</mapSources>
<mapTargets>
<target type="XSD">
<schema location="params.xsd"/>
<rootElement name="ArrayOfNameAnyTypePairType"
namespace="http://schemas.oracle.com/service/bpel/common"/>
</target>
</mapTargets>
<!-- GENERATED BY ORACLE XSL MAPPER 10.1.3.1.0(build 061009.0802) AT [WED
APR 18 14:35:04 PDT 2007]. -->
?>
<xsl:stylesheet version="1.0"
xmlns:ns2="http://schemas.oracle.com/service/bpel/common"
xmlns:xp20="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services
.functions.Xpath20"

xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:ora="http://schemas.oracle.com/xpath/extension"
xmlns:ehdr="http://www.oracle.com/XSL/Transform/java/oracle.tip.esb.server.
headers.ESBHeaderFunctions"
xmlns:ns0="http://www.w3.org/2001/XMLSchema"
xmlns:orcl="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services
.functions.ExtFunc"
xmlns:ids="http://xmlns.oracle.com/bpel/services/IdentityService/xpath"
xmlns:hwf="http://xmlns.oracle.com/bpel/workflow/xpath"
xmlns:ns1="http://xmlns.oracle.com/TestXSLParams"
exclude-result-prefixes="xsl ns0 ns1 ns2 xp20 bpws ora ehdr
orcl ids hwf">
<xsl:template match="/">
<ns2:parameters>
<ns2:item>
<ns2:name>
<xsl:value-of select="'userName'"/>
</ns2:name>
<ns2:value>
<xsl:value-of select="'jsmith'"/>
</ns2:value>
</ns2:item>
<ns2:item>
<ns2:name>
<xsl:value-of select="'location'"/>
</ns2:name>
<ns2:value>
<xsl:value-of select="'CA'"/>
</ns2:value>
</ns2:item>
</ns2:parameters>
</xsl:template>
</xsl:stylesheet>

3. .bpelファイルからSetParams.xslを呼び出します。次に例を示します。

- assignアクティビティinitializeXSLParameters内で、XSLT内からアクセス対象の情報を持つ特定のBPEL変数から、パラメータ変数を初期化します。

- assignアクティビティexecuteXSLT内で、パラメータを関数processXSLTのproperties (3番目)引数として、XSLTを呼び出します。

次に例を示します。

<process name="TestXSLParams"
. . .
. . .
<sequence name="main">
<receive name="receiveInput" partnerLink="client"
portType="client:TestXSLParams" operation="initiate"
variable="inputVariable" createInstance="yes"/>
<assign name="initializeXSLParameters">
<bpelx:annotation>
<bpelx:pattern>transformation</bpelx:pattern>
</bpelx:annotation>
<copy>
<from expression="ora:processXSLT ('SetParams.xsl',
bpws:getVariableData('inputVariable','payload'))"/>
<to variable="propertiesXMLVar"/>
</copy>
</assign>
<assign name="executeXSLT">
<bpelx:annotation>
<bpelx:pattern>transformation</bpelx:pattern>
</bpelx:annotation>

<copy>
<from expression="ora:processXSLT('TestXSLParams.xsl',
bpws:getVariableData('inputVariable','payload'),
bpws:getVariableData('propertiesXMLVar'))"/>
<to variable="outputVariable" part="payload"/>
</copy>
</assign>
<invoke name="callbackClient" partnerLink="client"
portType="client:TestXSLParamsCallback"
operation="onResult"
inputVariable="outputVariable"/>
</sequence>
</process>

4. BPELプロセスでは、これらのプロパティを使用してXSLT関数にアクセスします。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora (12cの場合)

ora:processXSLT関数を使用すると、大きいXSLT/XQuery操作の結果をシステム・ディレクトリの一時ファイルに書き込むことができます。その後、ドキュメントは必要なときに一時ファイルからロードされます。これにより、ドキュメント全体をバイナリXMLとしてメモリーにキャッシュする必要がなくなります。

詳細は、「XPath関数を使用し、大きいXSLT/XQuery出力をファイル・システムに書き込み」を参照してください。

B.3.33 readBinaryFromFile

この関数は、ファイルからデータを読み取ります。

シグネチャ:

ora:readBinaryFromFile(fileName)

引数:

- fileName: データの読取り元のファイル名。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

詳細は、「アタッチメント・ストリームの送信」を参照してください。

B.3.34 readBinaryFromFileWithMimeHeaders

この関数は、MIMEヘッダーを含むバイナリ・ファイルの内容を返します。

シグネチャ:

ora:readBinaryFromFileWithMimeHeaders(fileName, contentId, contentType, contentDisposition, contentTransferEncoding, contentDescription, contentLanguage)

B.3.35 readFile

この関数は、ファイルのコンテンツを返します。

シグネチャ:

ora:readFile('fileName','nxsdTemplate'?,'nxsdRoot'?)

引数:

- fileName: ファイルの名前。または、HTTP URLも指定できます。
この関数では、デフォルトで、プロセス用のスーツケースJARファイルからの相対パスでファイルが読み取られます。読み取るファイルが別のディレクトリ・パスにある場合は、絶対パスであることを示す追加のディレクトリのスラッシュ(/)を指定する必要があります。次に例を示します。

ora:readFile('file:///c:/temp/test.doc')

ディレクトリのスラッシュの指定が2つのみ(//)の場合は、次の例に示すようなエラーを受け取ります。

XPath expression failed to execute.
Error while processing xpath expression,
the expression is "ora:readFile("file://c:/temp/test.doc")",
the reason is c. Verify the xpath query.

- nxsdTemplate: 出力用のNXSDテンプレート。

- nxsdRoot - NXSDルート。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

注意:

現在、readFile関数では、認可が必要なWebサーバーのファイルにアクセスする機能がサポートされていません。そのようなファイルへのアクセスを試行すると、次のエラーを受け取ります。

java.io.IOException: Server returned HTTP response code: 401 for URL

B.3.36 search

この関数はLDAPエントリのリストを返します。

シグネチャ:

ldap:search('directoryName','filter','scope')

パラメータ:

- directoryName: directories.xmlファイルで指定されているディレクトリ名。directories.xmlファイルの詳細は、「authenticate」を参照してください。

- filter: 検索に使用するフィルタ式で、この値をnullにすることはできません。

- scope: 検索範囲。値は次のいずれかです。1: 1レベル、2: サブツリー、0: 指定したオブジェクト。このパラメータはオプションです。デフォルトでは、値は2です。

戻り値:

エントリのリストを含むXML要素。このXPath関数の場合は、すべてのプロパティをdirectories.xmlファイルで指定する必要があります。

例

ldap:search('people','cn=weblogic');

次に、出力の例を示します。

<searchResult xmlns="http://schemas.oracle.com/bpel/ldap">
<searchResultEntry dn="uid=weblogic" xmlns="urn:oasis:names:tc:DSML:2:0:core">
<attr name="uid">
<value>weblogic</value>
</attr>
<attr name="userpassword">
<value>
Unknown macro: {ssha}

bHDVJRfWVt/Uwlzb4TKU+QTOLB4FLySO</value>

</attr>

<attr name="objectclass">
<value>inetOrgPerson</value>
<value>organizationalPerson</value>
<value>person</value>
<value>top</value>
<value>wlsUser</value>
</attr>
<attr name="description">
<value>This user is the default administrator.</value>
</attr>
<attr name="wlsMemberOf">
<value>cn=Administrators,ou=groups,ou=myrealm,dc=soainfra</value>
</attr>
<attr name="orclguid">
<value>8AC1B6206FDD11DEBF9A7F3D47003274</value>
</attr>
<attr name="sn">
<value>weblogic</value>
</attr>
<attr name="cn">
<value>weblogic</value>
</attr>
</searchResultEntry>
<searchResultEntry xmlns="urn:oasis:names:tc:DSML:2:0:core"/>
</searchResult>

B.3.37 toCDATA

この関数は、CDATAセクションとしてDOMノードを返します。

シグネチャ:

ora:toCDATA(node)

B.3.38 tryToCastToBoolean

この関数は、入力がtrue、false、1、または0の文字列である場合に、ブール値を返します。

シグネチャ:

ora:tryToCastToBoolean(string)

引数:

- string: ブール値への変換を試みる文字列値。

B.3.39 writeBinaryToFile

この関数は、変数(または変数のパート)のバイナリ・バイトを指定のファイル名のファイルに書き込みます。

シグネチャ:

ora:writeBinaryToFile(varName[, partName[, query]])

引数:

- varName: 変数の名前。

- partName: messageType変数のパートの名前。

- query: ルート要素の子に対する問合せ文字列。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.40 getGroupIdsFromGroupAlias

この関数は、BPELスーツケース・ディスクリプタのTaskServiceAliasesセクションで指定されているグループ・エイリアスのユーザーIDのリストを返します。

シグネチャ:

ora:getGroupIdsFromGroupAlias(String aliasName)

引数:

- aliasName: ユーザーまたはグループのリストのエイリアス。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.3.41 getUserIdsFromGroupAlias

この関数は、BPELスーツケース・ディスクリプタのTaskServiceAliasesセクションで指定されているグループ・エイリアスのユーザーIDのリストを返します。

シグネチャ:

ora:getUserIdsFromGroupAlias(String aliasName)

引数:

- aliasName - グループのエイリアス名。

プロパティID:

- namespace-uri: http://schemas.oracle.com/xpath/extension

- namespace-prefix: ora

B.4 変換関数

この項では、変換関数について説明します。

B.4.1 boolean

この関数は、入力をブールに変換します。数値は、正または負のゼロでもNaNでもない場合にのみtrueになります。ノード・セットは、空でない場合のみtrueになります。文字列は、長さがゼロでない場合のみtrueになります。

シグネチャ:

boolean(input as any)

引数

- input as any: 任意の値。

次に例を示します。

boolean('false')はtrueを返します。

プロパティID:

- namespace-uri:

B.4.2 number

この関数は、入力を数値に変換します。オプションの空白、オプションの負符号、数値、および空白をこの順序どおり含む文字列が、文字列によって表される数学的な値に最も近い(IEEE 754の数値丸め規則に従って) IEEE 754数値に変換されます。その他の文字列はすべてNaNに変換されます。ブールのtrueは1に変換されます。ブールのfalseは0に変換されます。ノード・セットはまず、string関数のコールによって変換した場合と同様にして文字列に変換され、次に文字列パラメータと同じ方法で変換されます。

シグネチャ:

number(input as string or boolean or node-set)

引数

- input as string or boolean or node-set: 変換する値。

次に例を示します。

number('12.3')は12.3を返します。

B.4.3 string

この関数は、オブジェクトを文字列に変換します。

シグネチャ:

string(input as any)

引数

- input as any: 変換するオブジェクト。

次に例を示します。

string(12.3)は'12.3'を返します。

プロパティID:

- namespace-uri:

- namespace-prefix:

B.5 DVM関数

この項では、ドメイン値マップ(DVM)関数について説明します。

B.5.1 lookupValue

この関数は、ソース列に指定のソース値を含むドメイン値マップのターゲット列の値をルックアップして文字列を戻します。

シグネチャ:

dvm:lookupValue(dvmLocation,sourceColumnName,sourceValue,targetColumnName,defaultValue)

引数:

- dvmLocation: ドメイン値マップのURI。

- sourceColumnName: ソース列名。

- sourceValue: ソース値(XSLTトランスフォーメーションのソース文書にバインドされるXPath式)。

- targetColumnName: ターゲット列名。

- defaultValue: 値が見つからない場合は、デフォルト値が返されます。

- QualifierSourceColumn: 修飾子列の名前。

- QualifierSourceValue: 修飾子の値。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.dvm.LookupValue

- namespace-prefix: dvm

詳細は、「dvm:lookupValue」を参照してください。

B.5.2 lookupValue1M

この関数は、ソース列の値がソース値と等しいドメイン値マップの複数のターゲット列の値を格納する、XML文書フラグメントを返します。

シグネチャ:

dvm:lookupValue1M(dvmLocation,sourceColumnName,sourceValue,targetColumnName1,targetColumnName2...)

引数:

- dvmMetadataURI: ドメイン値マップのURI。

- SourceColumnName: ソース列名。

- SourceValue: ソース値(XSLTトランスフォーメーションのソース文書にバインドされるXPath式)。

- TargetColumnName: ターゲット列名。1つ以上の列名を指定する必要があります。疑問符記号(?)は複数のターゲット列名を指定できることを示します。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.dvm.LookupValue

- namespace-prefix:dvm

詳細は、「dvm:lookupValue1M」を参照してください。

B.6 データベース関数

この項では、データベース関数について説明します。

B.6.1 lookup-table

この関数は、パラメータから生成されたSQL問合せに基づいて文字列を返します。

この文字列は、次を実行することによって取得されます。

SELECT outputColumn FROM table WHERE inputColumn = key

それを、JDBC接続文字列(jdbc:oracle:thin:username/password@host:port:sid)、またはデータソースJNDI識別子のいずれかのデータソースに対して実行します。JDBC接続文字列を使用する場合は、Oracle Thinドライバのみがサポートされます。

例:

oraext:lookup-table('employee','id','1234','last_name','jdbc:oracle:thin:xyz/xyz@localhost:1521:ORCL')

シグネチャ:

oraext:lookup-table(table, inputColumn, key, outputColumn, data source)

引数:

- table: - データの抽出元の表。

- inputColumn: 表内の列。

- key: 入力列のキーの値。

- outputColumn: データを出力する列。

- data source: データのソース。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.6.2 query-database

この関数は、指定されたデータベースに対してSQL問合せを実行して、ノードセットを返します。

シグネチャ:

oraext:query-database(sqlquery as string, rowset as boolean, row as boolean, data source as string)

引数:

- sqlquery: 実行するSQL問合せ。

- rowset: 行を要素で囲むかどうかを指定します。

- row: 各行を要素で囲むかどうかを指定します。

- data source: データベースのJDBC接続文字列(jdbc:oracle:thin:username/password@host:port:sid)またはJNDI名。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.6.3 sequence-next-val

この関数は、Oracleの順序の次の値を返します。

次の値は、次の問合せを実行することによって取得されます。

SELECT sequence.nextval FROM dual

それを、JDBC接続文字列(jdbc:oracle:thin:username/password@host:port:sid)、またはデータソースJNDI識別子のいずれかのデータソースに対して実行します。JDBC接続文字列を使用する場合は、Oracle Thinドライバのみがサポートされます。

例:

oraext:sequence-next-val('employee_id_sequence','jdbc:oracle:thin:xyz/xyz@localhost:1521:ORCL')

シグネチャ:

oraext:sequence-next-val(sequence as string, data source as string)

引数:

- sequence: データベース内の順序番号。

- data source: JDBC接続文字列またはデータソースJNDI識別子。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.7 日付関数

この項では、日付関数について説明します。

B.7.1 add-dayTimeDuration-to-dateTime

この関数は、指定された期間にdateTimeを加算した新しい日時の値を返します。

期間の値が負の場合、返される値はdateTimeより前の日時になります。

シグネチャ:

xpath20:add-dayTimeDuration-from-dateTime(dateTime as string, duration as string)

引数:

- dateTime as string: 期間を加算するdateTime(文字列書式)。

- duration as string: dateTimeに加算する期間、または期間が負の場合は減算する期間(文字列書式)。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.7.2 current-date

この関数は、現在の日付をISO書式YYYY-MM-DDで返します。

シグネチャ:

xpath20:current-date(object)

引数:

- Object: 標準書式の時間。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.7.3 current-dateTime

この関数は、現在の日時の値をCCYY-MM-DDThh:mm:ss.sTZDのISO書式(sはミリ秒単位の時間を示す)で返します。

たとえば、時間が、タイムゾーンzの2004年5月12日の午後(PM)の6時17分15秒125ミリ秒である場合、current-dateTimeは次の値を返します。

2004-05-12T18:17:15.125Z

setDomainEnvファイルでcom.oracle.soa.xpath.datetimeWithoutMillisがtrueに設定されている場合、この関数によって次の書式で現在の日時の値が返されます(ssは秒単位の時間を示します)。

CCYY-MM-DDThh:mm:ss.TZD

シグネチャ:

xpath20:current-dateTime(object)

引数:

- object: 標準書式の時間。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.7.3.1 秒単位で日時の値を表示する手順:

1. 次のファイルを開きます。

- UNIXオペレーティング・システムでは、$MIDDLEWARE_HOME/user_projects/domains/domain_name/bin/setDomainEnv.shを開きます。

- Windowsオペレーティング・システムでは、MIDDLEWARE_HOME\user_projects\domains\domain_name\bin\setDomainEnv.batを開きます。

2. JAVA_OPTIONSセクションにcom.oracle.soa.xpath.datetimeWithoutMillisを追加して、値をtrueに設定します。たとえば、JAVA_OPTIONSは、現在、次のように設定されています。

JAVA_OPTIONS="${JAVA_OPTIONS} ${JAVA_PROPERTIES}
-Dwlw.iterativeDev=${iterativeDevFlag} -Dwlw.testConsole=${testConsoleFlag}
-Dwlw.logErrorsToConsole=${logErrorsToConsoleFlag} "

変更後、JAVA_OPTIONSは次のようになります。

JAVA_OPTIONS="${JAVA_OPTIONS} ${JAVA_PROPERTIES}
-Dwlw.iterativeDev=${iterativeDevFlag} -Dwlw.testConsole=${testConsoleFlag}
-Dwlw.logErrorsToConsole=${logErrorsToConsoleFlag}
-Dcom.oracle.soa.xpath.datetimeWithoutMillis=true"

3. サーバーを再起動します。

B.7.4 current-time

この関数は、現在の時間をISO書式で返します。書式はhh:mm:ssTZDです。

シグネチャ:

xpath20:current-time(object)

引数:

- object: 標準書式の時間。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.7.5 day-from-dateTime

この関数は、dateTimeから日を返します。デフォルトの日は1です。

シグネチャ:

xpath20:day-from-dateTime(object)

引数:

- object: 文字列としての標準書式の時間。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.7.6 format-dateTime

この関数は、指定された書式を使用して書式設定したdateTimeの文字列を返します。日時書式文字列の例は、W3C XSL Transformationsドキュメントを参照してください。たとえば、[Y0001]-[M01]-[D01]です。

シグネチャ:

xpath20:format-dateTime(dateTime as string, format as string)

引数:

- dateTime: 書式設定の対象となるdateTime。

- format: 出力の書式。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.7.7 hours-from-dateTime

この関数は、dateTimeから時間を返します。デフォルトの時間は0です。

シグネチャ:

xpath20:hours-from-dateTime(dateTime as string)

引数:

- dateTime: 日時の文字列。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.7.8 minutes-from-dateTime

この関数は、dateTimeから分を返します。デフォルトの分は0です。

シグネチャ:

xpath20:minutes-from-dateTime(dateTime as string)

引数:

- dateTime as string: 日時。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.7.9 month-from-dateTime

この関数は、dateTimeから月を返します。デフォルトの月は1 (1月)です。

シグネチャ:

xpath20:month-from-dateTime(dateTime as string)

引数:

- dateTime as string: 書式設定の対象となるdateTime。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.7.10 seconds-from-dateTime

この関数は、dateTimeから秒を返します。デフォルトの秒は0です。

シグネチャ:

xpath20:seconds-from-dateTime(dateTime as string)

引数:

- dateTime as a string: 文字列としてのdateTime。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.7.11 subtract-dayTimeDuration-from-dateTime

この関数は、dateTimeから期間を減算して、新規のdateTimeを返します。

期間の値が負の場合、返されるdateTime値は指定したinput-dateTimeより後の日時になります。

シグネチャ:

xpath20:subtract-dayTimeDuration-from-dateTime(dateTime as string, duration as string)

引数:

- dateTime as string: 期間を減算するdateTime(文字列書式)。

- duration as string: dateTimeから減算する期間、または期間が負の場合は加算する期間(文字列書式)。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xp20

B.7.12 timezone-from-dateTime

この関数は、dateTimeからタイムゾーンを返します。デフォルトのタイムゾーンはGMT+00:00です。

シグネチャ:

xpath20:timezone-from-dateTime(dateTime as string)

引数:

- dateTime as string: タイムゾーンを返す対象となるdateTime。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.7.13 year-from-dateTime

この関数は、dateTimeから年を返します。

シグネチャ:

xpath20:year-from-dateTime(dateTime as string)

引数:

- dateTime: 文字列としてのdateTime。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.8 アイデンティティ・サービス関数

この項では、アイデンティティ・サービス関数について説明します。

B.8.1 getDefaultRealmName

この関数は、デフォルトのレルム名を返します。

シグネチャ:

ids:getDefaultRealmName()

引数:

この関数には引数がありません。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/services/IdentityService/xpath

- namespace-prefix: ids

B.8.2 getGroupProperty

この関数は、指定したグループのプロパティ値を返します。グループまたは属性が存在しない場合は、nullを返します。

シグネチャ:

ids:getGroupProperty(groupName, attributeName, realmName)

引数:

- groupName: 属性を取得するグループを含む文字列または要素。

- attributeName: グループ属性の名前を含む文字列または要素。
アイデンティティ・サービスでLDAP providerTypeまたはJAZN LDAPベースのプロバイダが使用される場合は、これらの属性で検索できるようにLDAPサーバーを構成します。

- realmName: レルム名。これはオプションです。指定しない場合は、デフォルトのレルムが使用されます。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/services/IdentityService/xpath

- namespace-prefix: ids

B.8.3 getManager

この関数は、指定したユーザーのマネージャを取得します。ユーザーが存在しない、またはこのユーザーにマネージャが存在しない場合は、nullを返します。

シグネチャ:

ids:getManager(userName, realmName)

引数:

- userName: ユーザー名。

- realmName: レルム名。これはオプションです。指定しない場合は、デフォルトのレルムが使用されます。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/services/IdentityService/xpath

- namespace-prefix: ids

B.8.4 getManagerFromManagementChain

この関数は、upToUserName、upToTitleおよびupToLevelに基づいて、指定されたユーザーに対する管理チェーンを取得します。ユーザーが存在しない、またはこのユーザーにマネージャが存在しない場合は、nullを返します。正規表現はupToTitleパラメータおよびupToUserパラメータで使用できます。

シグネチャ:

ids:getManagerFromManagementChain()

B.8.5 getReportees

この関数は、ユーザーの報告先を取得します。ユーザーが存在しない場合は、nullを返します。この関数はノードのリストを返します。リストの各ノードはuserです。

シグネチャ:

ids:getReportees(userName, upToLevel, realmName)

引数:

- userName: ユーザー名。

- upToLevel: 結果に含める間接報告先のレベル数を定義します。値が1の場合は、直接報告先のみが返されます。値が-1の場合は、全レベルの報告先が返されます。値xsd:numberを含む要素、または文字列(例: '1')のいずれかを指定できます。

- realmName: レルム名。これはオプションであり、指定しない場合はデフォルトのレルムが使用されます。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/services/IdentityService/xpath

- namespace-prefix: ids

B.8.6 getSupportedRealmNames

この関数は、サポートされるレルム名を返します。

シグネチャ:

ids:getSupportedRealms()

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/services/IdentityService/xpath

- namespace-prefix: ids

B.8.7 getUserProperty

この関数は、ユーザーのプロパティを返します。ユーザーが存在しない場合は、nullを返します。適切な属性が存在しない場合は、カスタム属性を使用します。

シグネチャ:

ids:getUserProperty(userName, attributeName, realmName)

引数:

- userName: 属性を取得するユーザーを含む文字列または要素。

- attributeName: user属性の名前。
アイデンティティ・サービスでLDAP providerTypeまたはJAZN LDAPベースのプロバイダが使用される場合は、これらの属性で検索できるようにLDAPサーバーを構成します。

- realmName: レルム名。これはオプションです。指定しない場合は、デフォルトのレルム名が使用されます。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/services/IdentityService/xpath

- namespace-prefix: ids

詳細は、「電子メール・アドレスと電話番号を動的に選択する方法」を参照してください。

B.8.8 getUserRoles

この関数は、ユーザー・ロールを取得します。roleTypeに応じて、アプリケーション・ロールまたはグループのいずれかのオブジェクト・リストを返します。ユーザーまたはロールが存在しない場合は、nullを返します。

シグネチャ:

ids:getUserRoles(userName, roleType, direct)

引数:

- userName: ロールを取得するユーザーを含む文字列または要素。

- roleType: ロール・タイプ。3つの値ApplicationRole、EnterpriseRoleまたはAnyRoleのいずれかです。

- direct: 直接ロールをフェッチするか間接ロールをフェッチするかを示す文字列または要素。これはオプションです。指定しない場合は、直接ロールのみがフェッチされます。xsd:booleanまたは文字列true/falseを指定します。

プロパティID:

- namespace-uri:http://xmlns.oracle.com/bpel/services/IdentityService

- namespace-prefix: ids

B.8.9 getUsersInAppRole

この関数は、このアプリケーション・ロールを付与されているユーザーのリストを返します。入力として指定されたアプリケーション・ロール名またはアプリケーション名がNULLの場合は、NULLを戻します。

シグネチャ: ids:getUsersInAppRole(appRoleName, appName, direct, realmName)

引数:

- appRoleName: 取得するメンバーが属しているアプリケーション・ロールを含む文字列または要素。

- appName: アプリケーション・ロールを作成するアプリケーション名。

- direct: 直接の権限受領者のみを取得するか、すべてのユーザーを取得するかを示す文字列または要素。

- realmName: レルム名を含む文字列または要素。これはオプションであり、指定しなければデフォルト・レルムが使用されます。

B.8.10 getUsersInGroup

この関数は、グループ内のユーザーを取得します。グループが存在しない場合は、nullを返します。この関数はノードのリストを返します。リストの各ノードはuserです。

シグネチャ:

ids:getUsersInGroup(groupName, direct, realmName)

引数:

- groupName: グループ名。

- direct: ブール・フラグ。trueの場合は、直接ユーザー権限受領者が返され、それ以外の場合はすべてのユーザー権限受領者が返されます。値xsd:booleanを含む要素、または文字列'true'/'false'のいずれかを指定できます。

- realmName: レルム名。これはオプションです。指定しない場合は、デフォルトのレルム名が使用されます。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/services/IdentityService/xpath

- namespace-prefix: ids

B.8.11 isUserInAppRole

この関数は、ユーザーに特定のアプリケーション・ロールがあるかどうかを検証します。

シグネチャ:

ids:isUserInAppRole(userName, appRoleName, appName, realmName)

引数:

- userName: ロールへの関与を検証する必要があるユーザーを含む文字列または要素。

- appRoleName: アプリケーション・ロール名。

- appName: アプリケーション名(たとえば、OracleBPMProcessRolesApp、OracleBPMComposerRolesAppなど)。

- realmName: レルム名。これはオプションです。指定しない場合は、デフォルトのレルムが使用されます。この関数はブール値trueまたはfalseを返します。

B.8.12 isUserInRole

この関数は、ユーザーに特定のロールがあるかどうかを検証します。

シグネチャ:

ids:isUserInRole(userID, roleName, realmName)

引数:

- userID: ロールの付与を検証するユーザーを含む文字列または要素。

- roleName: ロール名。

- realmName: レルム名。これはオプションです。指定しない場合は、デフォルトのレルム名が使用されます。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/services/IdentityService/xpath

- namespace-prefix: ids

B.8.13 lookupGroup

この関数は、グループを取得します。グループが存在しない場合は、nullを返します。

シグネチャ:

ids:lookupGroup(groupName, realmName)

引数:

- groupName: グループ名。

- realmName: レルム名。これはオプションです。指定しない場合は、デフォルトのレルム名が使用されます。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/services/IdentityService/xpath

- namespace-prefix: ids

B.8.14 lookupUser

この関数は、ユーザー・オブジェクトを取得します。ユーザーが存在しない場合は、nullを返します。

シグネチャ:

ids:lookupUser(userName, realmName)

引数:

- userName: ユーザー名。

- realmName: レルム名。これはオプションです。指定しない場合は、デフォルトのレルム名が使用されます。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/services/IdentityService/xpath

- namespace-prefix: ids

B.9 論理関数

この項では、論理関数について説明します。

B.9.1 and

この関数は、両方のパラメータがtrueと評価される場合にtrueを返します。それ以外の場合、falseを戻します。

シグネチャ:

a-boolean and another-boolean

引数:

- a-boolean: 評価する一方のブール値。

- another-boolean: 評価する他方のブール値。

B.9.2 equals

この関数は、2つのパラメータが等しい場合にtrueを返します。それ以外の場合、falseを戻します。

シグネチャ:

parameter1 = parameter2

引数:

- parameter1: 評価する一方のパラメータ。

- parameter2: 評価する他方のパラメータ。

B.9.3 false

この関数は、ブール値falseを返します。

シグネチャ:

false()

B.9.4 greater

この関数は、第1パラメータが第2パラメータより大きい場合にtrueを返します。それ以外の場合、falseを戻します。

シグネチャ:

parameter1 > parameter2

引数:

- parameter1: 評価する第1パラメータ。

- parameter2: 評価する第2パラメータ。

B.9.5 greater equals

この関数は、第1パラメータが第2パラメータより大きいか等しい場合にtrueを返します。それ以外の場合、falseを戻します。

シグネチャ:

parameter1 >= parameter2

B.9.6 less

この関数は、第1パラメータが第2パラメータより小さい場合にtrueを返します。それ以外の場合、falseを戻します。

シグネチャ:

parameter1 < parameter2

引数:

- parameter1: 評価する第1パラメータ。

- parameter2: 評価する第2パラメータ。

B.9.7 less equals

この関数は、第1パラメータが第2パラメータより小さいか等しい場合にtrueを返します。それ以外の場合、falseを戻します。

シグネチャ:

parameter1 <= parameter2

引数:

- parameter1: 評価する第1パラメータ。

- parameter2: 評価する第2パラメータ。

B.9.8 not

この関数は、パラメータの否定を返します。

シグネチャ:

unobtainable as boolean)

引数:

- input as boolean: 評価する値。

B.9.9 not equals

この関数は、2つのパラメータが等しくない場合にtrueを返します。それ以外の場合、falseを戻します。

シグネチャ:

parameter1!= parameter2

引数:

- parameter1: 評価する第1パラメータ。

- parameter2: 評価する第2パラメータ。

B.9.10 or

この関数は、どちらかのパラメータがtrueに評価される場合にtrueを返します。それ以外の場合、falseを戻します。

シグネチャ:

a-boolean or another-boolean

引数:

- a-boolean: 評価する第1パラメータ。

- another-boolean: 評価する第2パラメータ。

B.9.11 true

この関数は、ブール値trueを返します。

シグネチャ:

true()

プロパティID:

- namespace-uri:

- namespace-prefix:

B.10 数学関数

この項では、数学関数について説明します。

B.10.1 abs

この関数は、inputNumberの絶対値を返します。inputNumberが負でない場合は、inputNumberを返します。inputNumberが負の場合は、inputNumberからマイナス符号をとった値を返します。

例:

abs(-1)は、1を返します。

シグネチャ:

xpath20:abs(inputNumber as number)

引数:

- inputNumber as number: 絶対値を返す対象となる数値。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.10.2 add

この関数は、2つの数値を加算します。

例:

2 + 2 = 4

B.10.3 ceiling

この関数は、入力数値より小さくない、最小の(負の無限大に最も近い)整数値を返します。

例:

ceiling(1.6)は、2.0を返します。

B.10.4 count

この関数は、入力ノード・セットに含まれるノードの数を返します。

例:

count(inputNodeSet as node-set)

引数:

- inputNodeSet: 入力ノード・セット。

B.10.5 divide

この関数は、第1の数値を第2の数値で除算した結果を返します。

例:

2 div 2 = 1

B.10.6 floor

この関数は、入力数値より大きくない、最大の(正の無限大に最も近い)整数値を返します。

シグネチャ:

floor(1.6)は、1.0を返します。

B.10.7 max-value-among-nodeset

この関数は、入力数値のリストであるノードセットinputNumberから最大値を返します。ノードセットinputNumberには、テキスト・ノードの集合、またはテキスト・ノードが含まれる要素の集合を指定できます。要素の場合、最初のテキスト・ノードの値が対象になります。

シグネチャ:

oraext:max-value-among-nodeset(inputNumber as node-set)

引数:

- inputNumber: 入力数値のノードセット。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.10.8 min-value-among-nodeset

この関数は、入力数値のリストであるノードセットinputNumbersから最小値を返します。ノードセットには、テキスト・ノードの集合、またはテキスト・ノードが含まれる要素の集合を指定できます。要素の場合、最初のテキスト・ノードの値が対象になります。

シグネチャ:

oraext:min-value-among-nodeset(inputNumbers as node-set)

引数:

- inputNumber: 入力数値のノードセット。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.10.9 mod

この関数は、切捨て除算の剰余を返します。

例:

5 mod 2は、1を返します

B.10.10 multiply

この関数は、2つの数値を乗算します。

例:

2 * 2 = 4

B.10.11 round

この関数は、入力数値に最も近い整数値を返します。2つの数値が存在する場合は、正の無限大に最も近い数値が返されます。

例:

round(1.5)は、2.0を返します。

B.10.12 square-root

この関数は、inputNumberの平方根を返します。

例:

oraext:square-root(25)は、5を返します

シグネチャ:

oraext:square-root(inputNumber as number)

引数:

- inputNumber: 平方根を計算する入力数値。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.10.13 subtract

この関数は、第1の数値から第2の数値を減算します。

例:

2 - 2 = 0

B.10.14 sum

この関数は、すべてのノードの合計を数値として返します。

シグネチャ:

sum(numbers as node-set-set)

引数:

- numbers as node-set-set: ノード・セットの合計数。

プロパティID:

- namespace-uri:

- namespace-prefix:

B.10.15 unary

この関数は、数値に-1を乗算します。

シグネチャ:

-(-1) = 1

B.11 ノード・セット関数

この項では、ノード・セット関数について説明します。

B.11.1 last

この関数は、コンテキスト・サイズを返します。

シグネチャ:

last()

B.11.2 local-name

この関数は、ノード名のローカル部分を返します。

シグネチャ:

local-name([inputNodeSet as node-set])

引数:

- inputNodeSet as node-set: ノード・セットの名前。

B.11.3 name

この関数は、ノードのQNameを返します。

シグネチャ:

name([inputNodeSet as node-set])

引数:

- inputNodeSet as node-set: ノード・セットの名前。

B.11.4 namespace-uri

この関数は、ノードのURIネームスペースを返します。

シグネチャ:

namespace-uri([inputNodeSet as node])

引数:

- inputNodeSet as node-set: ノード・セットの名前。

B.11.5 position

この関数は、コンテキスト位置を返します。

シグネチャ:

position()

B.11.6 union

この関数は、オペランドの結合を計算します。オペランドはノードセットであることが必要です。

シグネチャ:

node-set | node-set

B.12 文字列関数

この項では、文字列関数について説明します。

B.12.1 compare

この関数は、inputStringとcompareStringの各文字のUnicode値を比較して、これらの文字列間の辞書的な差異を返します。

inputStringがcompareStringより辞書的に前にある場合は、-1を返します。

inputStringとcompareStringが等しい場合は、0を返します。

inputStringがcompareStringより辞書的に後にある場合は、1を返します。

例:

xpath20:compare('Audi', 'BMW')は、-1を返します。

シグネチャ:

xpath20:compare(inputString as string, compareString as string)

引数:

- variableName: データのソース変数。

- propertyName: プロパティの修飾名(QName)。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.12.2 compare-ignore-case

この関数は、大/小文字を無視してinputStringとcompareStringの各文字のUnicode値を比較して、これらの文字列間の辞書的な差異を返します。表B-2 に詳細を示します。

表B-2 戻り値

この関数からの戻り値

条件

-1

inputStringがcompareStringより辞書的に前にあります。

0

inputStringとcompareStringの両方が同等です。

1

inputStringがcompareStringより辞書的に後にあります。

例:

oraext:compare-ignore-case('Audi','bmw')は、-1を返します。

シグネチャ:

xp:compare-ignore-case(inputString as string, compareString as string)

引数:

- inputString: 検索されるデータの文字列

- CompareString: 入力文字列と比較される文字列。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: oraext

B.12.3 concat

この関数は、文字列パラメータの連結を返します。

シグネチャ:

concat(string1 as string, string2 as string, ...)

引数:

- string1: 連結する文字列値。

- string2: 連結する文字列値。

B.12.4 contains

この関数は、inputStringがsearchStringを含む場合にはtrueを返します。それ以外の場合、falseを戻します。

シグネチャ:

contains(inputString as string,searchString as string)

次に例を示します。

contains('Michael Kay','Michael')は、trueを返します。

B.12.5 create-delimited-string

この関数は、nodeSetから作成され、デリミタで区切られた文字列を返します。

シグネチャ:

oraext:create-delimited-string(nodeSet as node-set, delimiter as string)

引数:

- nodeSet: デリミタ付き文字列に変換するノードセット。

- delimiter: 出力文字列の項目を区切る文字(たとえば、カンマやセミコロン)。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.12.6 ends-with

この関数は、inputStringがsearchStringで終わる場合にtrueを返します。

例:

xpath20:ends-with('XSL Map','Map')は、trueを返します。

シグネチャ:

xpath20:ends-with(inputString as string, searchString as string)

引数:

- inputString: 検索されるデータの文字列

- searchString: 検索する文字列。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.12.7 format-string

この関数は、渡された引数で書式設定されたメッセージを返します。引数は、少なくとも1つが必須で最大10個までサポートされます。

例:

oraext:format-string('{0} + {1} = {2}','2','2','4')は、'2 + 2 = 4'を返します

シグネチャ:

oraext:format-string(string,string,string...)

引数:

- string: 書式設定された出力に使用する文字列の1つ。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.12.8 get-content-as-string

この関数は、入力要素のXML表現を返します。

シグネチャ:

oraext:get-content-as-string(element as node-set)

引数:

- element as node-set: XML表現として返される入力要素。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.12.9 get-localized-string

この関数は、キーに対しロケール固有の文字列を返します。この関数は言語、国、変数およびリソースのバンドルを使用して正しいリソース・バンドルを識別します。すべてのパラメータは文字列書式である必要があります。パラメータ値を、get-localized-stringに送信する前に文字列に変換するには、string()関数を使用します。

リソース・バンドルは、resourceLocationに対してresourceBaseURLを解決することによって取得されます。URLは、/で終わる場合にかぎりディレクトリとみなされます。

使用方法: oraext:get-localized-string(resourceBaseURL as string, resourceLocation as string, resource bundle as string, language as string, country as string, variant as string, key as string)

例: oraext:get-localized-string('file:/c:/','','MyResourceBundle','en','US','','MSG_KEY')は、C:\ディレクトリにあるリソース・バンドル'MyResourceBundle'からロケール固有の文字列を返します。

シグネチャ:

oraext:get-localized-string(resourceURL,resourceLocation,resourceBundleName,language,country,variant,messageKey)

引数:

- resourceURL: リソースのURL。

- resourceLocation: リソースのサブディレクトリの場所。

- resourceBundleName: リソース・バンドルが含まれるZIPファイルの名前。

- language: ローカライズされる出力の言語。

- country: ローカライズされる出力の国。

- variant: ローカライズされる出力の言語変数。

- messageKey: リソース・バンドルのメッセージ・キー。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.12.10 index-within-string

この関数は、inputString内で最初に出現するsearchStringのゼロから始まる索引を返します。

searchStringが見つからない場合は-1を返します。

例:

oraext:index-within-string('ABCABC, 'B')は、1を返します。

シグネチャ:

oraext:index-within-string(inputString as string, searchString as string)

引数:

- inputString: 検索されるデータの文字列

- searchString: inputString内で検索する文字列。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.12.11 last-index-within-string

この関数は、inputString内で最後に出現するsearchStringのゼロから始まる索引を返します。

searchStringが見つからない場合は-1を返します。

例:

oraext:last-index-within-string('ABCABC', 'B')は、4を返します。

シグネチャ:

oraext:last-index-within-string(inputString as string, searchString as string)

引数:

- inputString: 検索されるデータの文字列

- searchString: inputString内で検索する文字列。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.12.12 left-trim

この関数は、inputStringから先頭の空白文字をすべて削除した値を返します。

例:

oraext:left-trim(' account ')は、'account 'を返します。

シグネチャ:

oraext:left-trim(inputString)

引数:

- inputString: 先頭の空白を削除する文字列。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.12.13 lower-case

この関数は、inputStringのすべての文字を対応する小文字に変換した値を返します。

例:

xpath20:lower-case('ABc!D')は、'abc!d'を返します。

シグネチャ:

xpath20:lower-case(inputString)

引数:

- inputString: 小文字にするデータの文字列。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.12.14 matches

この関数は、intputStringが正規表現パターンregexPatternに一致する場合にtrueを返します。

例:

xpath20:matches('abracadabra', '^a.*a$')は、trueを返します。

シグネチャ:

xpath20:matches(intputString, regexPattern)

引数:

- inputString: 一致する必要のあるデータの文字列。

- regexPattern: 正規表現パターン。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.12.15 normalize-space

この関数は、先頭および末尾の空白を除去し、連続した空白文字を単一のスペースに置き換えることによって、スペースを正規化した入力文字列を返します。

シグネチャ:

normalize-space([inputString as string])

引数:

- inputString: 入力文字列。

次に例を示します。

normalize-space(' book title ')は、'book title'を返します。

B.12.16 right-trim

この関数は、inputStringから末尾の空白文字をすべて削除した値を返します。

例:

oraext:right-trim(' account ')は、' account'を返します。

シグネチャ:

oraext:right-trim(inputString as string)

引数:

- inputString: 末尾の空白を削除する入力文字列。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc

- namespace-prefix: oraext

B.12.17 starts-with

この関数は、入力文字列が検索文字列から始まる場合にtrueを返します。それ以外の場合、falseを戻します。

シグネチャ:

starts-with(inputString as string,searchString as string)

引数:

- inputString: 入力文字列。

- searchString: 検索文字列。

次に例を示します。

starts-with('data type','data')は、trueを返します。

B.12.18 string-length

この関数は、入力文字列の文字数を返します。

シグネチャ:

string-length([inputString as string])

引数:

- inputString: 入力文字列。

次に例を示します。

string-length('xml')は、3を返します。

プロパティID:

- namespace-uri:

- namespace-prefix:

B.12.19 substring

この関数は、開始位置に指定された位置から始まり、lengthに指定された長さを持つ、入力文字列の部分文字列を返します。

シグネチャ:

substring(inputString as string,startingLoc as number,[length as number])

引数:

- inputString: 入力文字列。

- startingLoc: 開始位置。

- length as number: 数値として指定する長さ

次に例を示します。

substring('12345',2)は、'2345'を返します。

B.12.20 substring-after

この関数は、入力文字列のうち検索文字列が最初に一致した箇所より後の部分文字列を返します。また、入力文字列に検索文字列が含まれない場合は空の文字列を返します。

シグネチャ:

substring-after(inputString as string,searchString as string)

引数:

- inputString: 入力文字列。

- searchString: 検索する文字列。

次に例を示します。

substring-after('1999/04/01','/')は、'04/01を返します。

B.12.21 substring-before

この関数は、入力文字列のうち検索文字列が最初に一致した箇所より前の部分文字列を返します。また、入力文字列に検索文字列が含まれない場合は空の文字列を返します。

シグネチャ:

substring-before(inputString as string,searchString as string)

引数:

- inputString: 入力文字列。

- searchString: 検索する文字列。

次に例を示します。

substring-before('1999/04/01','/')は、'1999'を返します。

B.12.22 translate

シグネチャ:

translate(inputString as string,fromString as string,toString as string)

引数:

- inputString: 入力文字列。

- fromString: 変換元文字列。

- toString: 変換先文字列。

次に例を示します。

translate('--aaa--','abc-','ABC')は、'AAA'を返します。

B.12.23 upper-case

この関数は、inputStringのすべての文字を対応する大文字に変換した値を返します。

例:

xpath20:upper-case('abCd0')は、'ABCD0'を返します。

シグネチャ:

xpath20:upper-case(inputString as string)

引数:

- inputString: 大文字にするデータの文字列。

プロパティID:

- namespace-uri: http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20

- namespace-prefix: xpath20

B.13 ワークフロー・サービス関数

この項では、ワークフロー・サービス関数について説明します。

B.13.1 clearTaskAssignees

この関数は、現在のタスク割当て先を消去します。

シグネチャ:

hwf:clearTaskAssignees(taskID)

引数:

- task: タスクのタスクID。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/workflow/xpath

- namespace-prefix: hwf

B.13.2 createWordMLDocument

この関数は、Microsoft Word ML文書をBase 64でエンコードされた文字列として作成します。

シグネチャ:

hwf:createWordMLDocument(node, xsltURI)

引数:

- node: このノードは、トランスフォーメーションへの入力であるXMLノードです。

- xsltURI: ノード(第1引数)からMicrosoft Word MLへの変換に使用されるXSLT。

プロパティID:

- namespace-uri:http://xmlns.oracle.com/bpel/workflow/xpath

- namespace-prefix: hwf

B.13.3 dynamicTaskAssign

この関数は、現行タスクのコンテキスト内で、指定されたパターンを使用して、入力から指定されたタイプの割当て先を選択します。

この関数は、ヒューマン・タスクのコンテキストでのみ使用できます。

シグネチャ:

hwf:dynamicTaskAssign(patternName, participants, inputParticipantType, targetAssigneeType, isGlobal, invocationContext, parameter1, parameter2, ..., parameterN)

引数:

- patternName: 使用するパターンの名前(必須)。パターンROUND_ROBIN、LEAST_BUSY、およびMOST_PRODUCTIVEは、自動的に提供されます。カスタム・パターンを使用してSOAサーバーを構成することが可能です。

- participants: 割当て先として選択される参加者(必須)。これは、参加者名や参加者名のカンマ区切りリストを含む文字列または要素、あるいは参加者名や参加者名のカンマ区切りリストを含む要素のセットです。参加者のタイプはすべて同じである必要があります。

- inputParticipantType: 入力する参加者のタイプ(user、groupまたはapplication_role) (必須)。

- targetAssigneeType: 選択する割当て先のタイプ(user、groupまたはapplication_role) (必須)。この値は、関数が使用されているコンテキストと一致する必要があります(たとえば、所有者ユーザーを動的に選択する場合にはuserである必要があります)。inputParticipantTypeがuserである場合、ここで有効な値はuserのみです。

- isGlobal: パターンへのアクセスに、すべてのタイプのタスクを使用するか、同じタイプのタスクを現在のタスクとして使用するかを示すブール値。これはオプションです。デフォルトはfalseです。

- invocationContext: この関数が使用されている場所を一意に識別する文字列。指定しない場合は、デフォルトのコンテキストが割り当てられます。

- parameterN : 一部の動的割当てパターンではパラメータを指定できます。パラメータ値は、?=?文字をデリミタとして使用し、名前と値のペアとして指定できます(たとえば、?TIME_PERIOD=7?)。

例:

hwf:dynamicTaskAssign(?LEAST_BUSY?,?jcooper,jstein,mtwain?,?user?,?user?,?true?,?ErrorAssignee?)

hwf:dynamicTaskAssign(?ROUND_ROBIN?,?LoanAgentGroup?,?group?,?user?,?false?,?OwnerUser?)

hwf:dynamicTaskAssign(?MOST_PRODUCTIVE?,task:task/task:payload/task:users,?user?,?user?,?false?,?OwnerUser?,?TIME_PERIOD=7?)

hwf:dynamicTaskAssign(?LEAST_BUSY?,?DeveloperRole?,?application_role?,?group?)

B.13.4 getNotificationProperty

この関数は、通知プロパティを取得します。通知ごとに対応する値に評価されます。この関数は、通知コンテンツのXPath式でのみ使用してください。他の場所で使用すると、nullが返されます。

シグネチャ:

hwf:getNotificationProperty(propertyName)

引数:

- propertyName: 通知プロパティの名前。次のいずれかの値です。

- recipient: 通知の受信者。

- recipientDisplay: 受信者の表示名。

- taskAssignees: タスクの割当て先。

- taskAssigneesDisplay: タスク割当て先の表示名。

- locale: 受信者のロケール。

- taskId: 通知対象となるタスクのタスクID。

- taskNumber: 通知対象となるタスクのタスク番号。

- appLink: Oracle BPM Worklistのタスク詳細ページへのHTMLリンク。

プロパティID:

- namespace-uri:http://xmlns.oracle.com/bpel/workflow/xpath

- namespace-prefix: hwf

B.13.5 getNumberOfTaskApprovals

この関数は、タスクが承認された回数を計算します。

シグネチャ:

hwf:getNumberOfTaskApprovals(taskId)

引数:

- taskId: タスクのID

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/workflow/xpath

- namespace-prefix: hwf

B.13.6 getPreviousTaskApprover

この関数は、前のタスク承認者を取得します。

シグネチャ:

hwf:getPreviousTaskApprover(taskId)

引数:

- taskId: タスクのID

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/workflow/xpath

- namespace-prefix: hwf

B.13.7 getTaskAttachmentByIndex

この関数は、指定された索引にあるタスクの添付ファイルを取得します。

シグネチャ:

hwf:getTaskAttachmentByIndex(taskId, attachmentIndex)

引数:

- taskId: タスクのタスクID。

- attachmentIndex: 添付ファイルの索引。索引は1から始まります。attachmentIndex引数には、値が索引番号の文字列として評価されるノードを指定できます(すべてのノード値は文字列です)。静的に指定する場合は、'1'として指定できます。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/workflow/xpath

- namespace-prefix: hwf

B.13.8 getTaskAttachmentByName

この関数は、添付ファイル名でタスクの添付ファイルを取得します。

シグネチャ:

hwf:getTaskAttachmentByName(taskId, attachmentName)

引数:

- taskId: タスクのタスクID。

- attachmentName: 添付ファイルの名前。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/workflow/xpath

- namespace-prefix: hwf

B.13.9 getTaskAttachmentContents

この関数は、添付ファイル名でタスクの添付ファイルのコンテンツを取得します。

シグネチャ:

hwf:getTaskAttachmentContents(taskId, attachmentName)

引数:

- taskId: タスクのタスクID。

- attachmentName: 添付ファイルの名前。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/workflow/xpath

- namespace-prefix: hwf

B.13.10 getTaskAttachmentsCount

この関数は、タスクの添付ファイル数を取得します。

シグネチャ:

hwf:getTaskAttachmentsCount(taskId)

引数:

- taskId: タスクのタスクID。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/workflow/xpath

- namespace-prefix: hwf

B.13.11 getTaskResourceBundleString

この関数は、タスク定義に関連付けられているリソース・バンドルから国際化されたリソース値を返します。

シグネチャ:

hwf:getTaskResourceBundleString(taskId, key, locale?)

引数:

- taskId: タスクのタスクID。

- key: リソースへのキー。

- locale: ロケール(オプション)。この値は、デフォルトでシステム・ロケールに設定されます。この場合、ネームスペースhttp://xmlns.oracle.com/bpel/services/taskServiceのresourceString XML要素が返されます。これにはリソース・バンドルからの文字列が含まれます。

プロパティID:

- namespace-uri: http://xmlns.oracle.com/bpel/workflow/xpath

- namespace-prefix: hwf

B.14 XREF関数

この項では、相互参照(XREF)関数について説明します。

B.14.1 lookupPopulatedColumns

この関数は、参照列の値に対応する単一または複数の値を相互参照列で参照します。

シグネチャ:

xref:lookupPopulatedColumns(tableName,columnName,value,needAnException)

引数:

- xrefTableName: 参照表の名前。

- xrefColumnName: 参照列の名前。

- xrefValue: 参照列名に対応する値。

- needAnException: 値がtrueに設定されると、参照列に値が見つからない場合に例外がスローされます。そうでない場合は、空のノードセットが返されます。

プロパティID:

- namespace-uri:http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRefXPathFunctions

- namespace-prefix: xref

B.14.2 lookupXRef

この関数は、参照列の値に対応する値を相互参照列で参照します。

シグネチャ:

xref:lookupXRef(tableName,referenceColumnName,referenceValue,columnName,needAnException)

引数:

- xrefLocation: 相互参照URI。

- xrefReferenceColumnName: 参照列の名前。

- xrefReferenceValue: 参照列名に対応する値。

- xrefColumnName: 値が参照される列の名前。

- needAnException: 値がtrueに設定されると、値が見つからない場合に例外がスローされます。そうでない場合は、空の値が返されます。

プロパティID:

- namespace-uri:http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRefXPathFunctions

- namespace-prefix: xref

詳細は、「xref:lookupXRef関数」を参照してください。

B.14.3 lookupXRef1M

この関数は、参照列の値に対応する複数の値を相互参照列で参照します。

シグネチャ:

xref:lookupXRef1M(tableName,referenceColumnName,referenceValue,columnName,needAnException)

引数:

- xrefLocation: 相互参照URI。

- xrefReferenceColumnName: 参照列の名前。

- xrefReferenceValue: 参照列名に対応する値。

- xrefColumnName: 値が参照される列の名前。

- needAnException: この値がtrueに設定される場合は、参照される値が見つからないときに例外がスローされます。そうでない場合は、空のノードセットが返されます。

プロパティID:

- namespace-uri:http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRefXPathFunctions

- namespace-prefix: xref

詳細は、「xref:lookupXRef1M関数」を参照してください。

B.14.4 markForDelete

この関数は、相互参照表の値を削除します。関数に渡された列値を含む行は、XREF_DATA表から削除され、XREF_DELETED_DATA表に移動されます。削除に成功すると、trueを返します。それ以外は、falseを返します。

シグネチャ:

xref:markForDelete(tableName,columnName,value)

引数:

- xrefTableName: 相互参照表の名前

- xrefColumnName: 削除対象の値を含む列の名前。

- xrefValueToDelete: 削除する値。

プロパティID:

- namespace-uri:http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRefXPathFunctions

- namespace-prefix: xref

詳細は、「相互参照表の値の削除方法」を参照してください。

B.14.5 populateLookupXRefRow

この関数は、参照列に参照値がある相互参照表(XREF)に列値を移入します。モードに応じて、参照値も移入される場合があります。xref:populateXRefRow関数とは異なり、xref:populateLookupXRefRow関数では、同じIDのレコードが同時に追加されたときに一意制約の違反エラーはスローされません。かわりに、ルックアップとして動作してエラーの原因となった既存のソース値を返し、処理フローを停止しません。この関数を使用して、xref:populateXRefRow関数の使用時に発生する可能性がある同時実行性の問題を解決します。

シグネチャ:

xref:populateLookupXRefRow(xrefLocation as string, referenceColumnName as string, referenceValue as string, columnName as string, value as string, mode as string)

次に例を示します。

xref:populateLookupXRefRow("C:\xrefs\customer-id.xref", "Oracle System" , "ORCL_100", "SAP System", "SAP_001", "ADD")

B.14.6 populateXRefRow

この関数は、参照列に参照値がある相互参照表(XREF)に列名を移入します。

シグネチャ:

xref:populateXRefRow(tableName,referenceColumnName,referenceValue,columnName,value,mode)

引数:

- xrefLocation: 相互参照URI。

- xrefReferenceColumnName: 参照列の名前。

- xrefReferenceValue: 参照列名に対応する値。

- xrefColumnName: 値が参照される列の名前。

- xrefvalue: 参照列名に対応する値。

- xrefmode: XREFの移入モードの名前

プロパティID:

- namespace-uri:http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRefXPathFunctions

- namespace-prefix: xref

詳細は、「xref:populateXRefRow関数」を参照してください。

B.14.7 populateXRefRow1M

この関数は、参照列に参照値がある相互参照表(XREF)の列に複数の値を移入します。

シグネチャ:

xref:populateXRefRow1M(tableName,referenceColumnName,referenceValue,columnName,value,mode)

引数:

- xrefLocation: 相互参照URI。

- xrefReferenceColumnName: 参照列の名前。

- xrefReferenceValue: 参照列名に対応する値。

- xrefColumnName: 値が参照される列の名前。

- xrefvalue: 参照列名に対応する値。

- xrefmode: XREFの移入モードの名前

プロパティID:

- namespace-uri:http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRefXPathFunctions

- namespace-prefix: xref

詳細は、「xref:populateXRefRow1M関数」を参照してください。

B.15 Oracle JDeveloperの式ビルダーでのXPath式の構築

「式ビルダー」ダイアログとXPathビルディング・アシスタントを使用して、XPath式を作成できます。「式ビルダー」ダイアログで、BPELプロセスのXPath式、ヒューマン・ワークフロー、またはOracle Mediatorサービス・コンポーネントをビジュアルに設計できます。

B.15.1 式ビルダーの使用方法

式ビルダーの使用手順:

1. 「関数」リストで、使用する関数のカテゴリ(たとえば、「アイデンティティ・サービス関数」)を選択します。

2. 関数(たとえばgetManager)を選択します。

3. 図B-1 に示すように、「式に挿入」をクリックします。

図B-1 「式ビルダー」ダイアログ

上部の「式」フィールドに関数を挿入します。

4. 図B-2 のように、「式」フィールドで、関数のカッコの間にカーソルを置きます。

図B-2 カーソルを置く位置

5. 図B-3 のように、「スキーマ」セクションでスキーマ・パスを拡張して選択を行います。

図B-3 スキーマの選択

6. 「式に挿入」をクリックします。

図B-4 のように、式が関数に挿入されます。

図B-4 XPath式の作成

B.15.2 XPathビルディング・アシスタントの概要

次のダイアログなど、いくつかのダイアログでは、XPathビルディング・アシスタントを使用してXPath式を指定できます。

- 「式ビルダー」ダイアログの「式」フィールド

- BPEL 2.0における「変数の作成」ダイアログの「初期化」タブの「式」フィールド

- XSLTマップ・エディタの「XPath式の編集」ダイアログおよび「関数の編集」ダイアログ

長い式および複雑な式を手動で指定できますが、非効率的で間違いやすいプロセスになる可能性があります。XPathビルディング・アシスタントには、このプロセスを簡素化する一連の機能が用意されています。

- 次の項目に関する自動完了機能

- 要素および属性

- 関数

- BPEL変数およびパート

- 関数パラメータのツールのヒント

- XPathの構文検証およびセマンティク検証

B.15.3 XPathビルディング・アシスタントの使用方法

この項では、XPathビルディング・アシスタントを使用して、「式ビルダー」ダイアログの「式」フィールドで式を作成する方法の例を示します。

XPathビルディング・アシスタントを使用する手順は、次のとおりです。

1. 「式」フィールドの中をクリックし、[Ctrl]キーを押しながら[Space]キーを押します。使用可能なオプションのメニューが表示されます。

2. 次のいずれかの方法で、リストから選択します。

- リストを下へスクロールして、関数をダブルクリックします。

- 最初の1文字(たとえばc)を入力してその文字で始まる項目のみを表示し、適切な関数をダブルクリックします。

図B-5 に詳細を示します。

図B-5 式を作成するための値リスト

この値が「式」フィールドに追加されます。別のオプションのリストが再度自動的に表示され、XPath式の次の部分を入力するように求められます。

3. 次の部分を選択してダブルクリックします。図B-6 に詳細を示します。

図B-6 関数の次の部分の起動

この値が「式」フィールドに追加されます。リストが再度自動的に表示され、XPath式の次の部分を入力するように求められます。

4. このプロセスを続けて実行して、XPath式の残りの部分を作成します。

5. 必要に応じて手動でテキストを追加します。図B-7 に詳細を示します。

図B-7 手動によるテキストの追加

注意:

XPathビルディング・アシスタントのポップアップで選択対象をダブルクリックするかわりに、[Enter]キーを使用して選択することもできます。式が完成しても情報の入力を求められる場合には、[Esc]を押してください。リストが閉じます。

B.15.4 XSLTマッパーでのXPathビルディング・アシスタントの使用

この項では、XPathビルディング・アシスタントを使用して、XSLTマッパーの「XPath式の編集」ダイアログで式を作成する方法の例を示します。

XSLTマッパーでXPathビルディング・アシスタントを使用する手順は、次のとおりです。

1. XSLTマップ・エディタに移動します。

2. 「コンポーネント・パレット」 リストから、「拡張関数」を選択します。

3. リストを下へスクロールして「xpath-expression」関数を見つけます。

4. 図B-8 に示すように、「xpath-expression」関数をXSLTマップ・エディタにドラッグ・アンド・ドロップします。

図B-8 xpath-expression

5. 関数をダブルクリックして、「XPath式の編集」ダイアログを表示します。

6. 「XPath式」フィールド内でカーソルをクリックします。

7. 図B-9 に示すように、[Ctrl]キーを押しながら[Space]キーを押して、式を作成するための値リストを表示します。

図B-9 式を作成するための値リスト

8. 次のいずれかの方法でリストから値を選択します(この例では、「concat(String) as String」を選択)。

- リストを下へスクロールして、「concat(String) as String」をダブルクリックします。

- cを入力して、その文字で始まる項目のみを表示し、「concat(String) as String」を選択してダブルクリックします。

図B-10 に詳細を示します。

図B-10 式リストの選択

この選択値が「XPath式」フィールドに追加されます。別のオプションのリストが再度自動的に表示され、XPath式の次の部分を入力するように求められます。

9. このプロセスを続けて実行して、XPath式の残りの部分を作成します。

10. 完了後、「OK」をクリックして「XPath式の編集」ダイアログを閉じます。

B.15.5 関数パラメータのツールのヒント

関数パラメータのツールのヒントでは、選択したXPath関数の適切な引数が表示されます。たとえば、関数concatを手動で入力し、次に(を入力すると、パラメータのツールのヒントが表示され、concat関数の適切な引数が表示されます。関数の現在の引数名が太字でハイライト表示されます。図B-11 に詳細を示します。

図B-11 関数の現在の引数名

1つの引数の指定が終わり、カンマを入力して次の引数に進むと、ツールのヒントが更新されて2番目の引数名が太字でハイライト表示されます。以降も同様に処理されます。関数が含まれている既存のXPathの編集中に、パラメータのツールのヒントを再起動するには、関数内にカーソルを置き、[Ctrl] キーと [Shift] キーを押しながら [Space] キーを押します。

B.15.6 構文検証およびセマンティック検証

Oracle JDeveloper内では、XPath式は、XPath 1.0仕様に準拠している場合は構文的に有効であるとみなされます。XPathビルディング・アシスタントでは、構文的に誤りのあるXPath関数(例: カッコやアポストロフィの欠落)については、誤りのある部分に赤い下線が付けられて警告されます。この部分にマウス・ポインタを移動します。これにより、エラー・メッセージがツールのヒントとして表示されます。エラーを修正すると、赤い下線付きのエラー表示は表示されなくなります。図B-12 に詳細を示します。

図B-12 構文的に誤りのあるXPath

構文的に有効なXPath関数がセマンティック上は無効な場合があります。この場合は、実行時に予期しないエラーが発生する可能性があります。たとえば、要素、変数、関数またはパートの名前の綴りが間違っていることがあります。XPathビルディング・アシスタントでは、セマンティク・エラーについては、誤りのある部分に青い下線が付けられて警告されます。この部分にマウス・ポインタを移動します。これにより、エラー・メッセージがツールのヒントとして表示されます。エラーを修正すると、青い下線付きのエラー表示は表示されなくなります。図B-13 に詳細を示します。

図B-13 セマンティク的に誤りのあるXPath

B.15.7 フリー・フォーム・テキストおよびXPath式を使用した式の作成

一部のダイアログでは、フリー・フォーム・テキストとXPath式を組み合せて使用できます。

1. フィールドにカーソルを置くと、この機能を説明するポップアップ・メッセージが表示されます。図B-14 に詳細を示します。

図B-14 機能説明のメニュー

2. フリー・フォーム・テキストを入力します(この例では、'Hello, your telephone number')。図B-15 に詳細を示します。

図B-15 フリー・フォーム・テキスト

3. XPathビルディング・アシスタントを起動する準備が整ったところで<%と入力します。図B-16 に詳細を示します。

図B-16 XPathビルディング・アシスタントの起動準備

赤い下線が表示されます。これは、追加情報の入力を求められていることを示します。

4. [Ctrl]キーを押しながら[Space]キーを押して、XPathビルディング・アシスタントを起動します。図B-17 に詳細を示します。

図B-17 XPathビルディング・アシスタントの起動

5. リストを下へスクロールして、選択する値をダブルクリックします。

6. このプロセスを続けて実行して、式の残りの部分を作成します。

B.15.8 Windows上でXPath関数でディレクトリ・パスにダブル・スラッシュを使用するとエラーが発生する可能性がある

Windowsオペレーティング・システム上では、XPath拡張関数でディレクトリ・パスを表すためにスラッシュを使用すると、次の2通りに解釈されます。

- ダブル・スラッシュの場合。例: file://c:/Ftab.txt

- シングル・スラッシュの場合。例: file:/c:/Ftab.txt

ダブル・スラッシュを指定してエラー・メッセージが表示される場合は、シングル・スラッシュを指定してみてください。

たとえば、次のようにダブル・スラッシュを使用しても機能しません。

oraext:get-content-from-file-function("file://c:/Ftab.txt","file:
//c:/Ftab_1.xsd","root")

しかし、次のようにシングル・スラッシュを使用すると適切に機能します。

oraext:get-content-from-file-function("file:/c:/Ftab.txt","file:
/c:/Ftab_1.xsd","root")

B.16 ユーザー定義XPath拡張関数の作成

Oracle SOA Suiteで使用するためのユーザー定義(カスタム)XPath拡張関数を作成できます。これらの関数は、次のコンポーネントに対して作成できます。

- Oracle BPEL Process Manager

- Oracle Mediator

- XSLTマッパー

- ヒューマン・ワークフロー

- これらのすべてのコンポーネントで共有

Oracle SOA SuiteのXPath拡張関数は、次の標準に従います。

- 単一のスキーマで、システム関数とユーザー定義関数の両方の構成構文を定義します。

- XPath関数は、使用方法(Oracle BPEL Process Manager、Oracle Mediator、ヒューマン・ワークフロー、XSLTマッパーおよびすべてで共通使用)に基づいて分類されます。

- システム関数は、ユーザー定義関数と区別されます。

- リポジトリで、システム関数の構成ファイルとユーザー定義関数の構成ファイルの両方をホストします。

- リポジトリで、ユーザー定義関数の実装JARファイルをホストし、自動的にJava仮想マシン(JVM)(クラス・ローダー)で使用できるようにします。

関数の作成に関する次の規則に従うことをお薦めします。

- 可能な場合は、すべてのコンポーネントで共有できる関数を作成します。すべてのコンポーネントで共有される関数は、ext-soa-xpath-functions-config.xmlという構成ファイルに作成できます。XSLTマッパーの関数は、Oracle BPEL Process Manager、Oracle Mediatorおよびヒューマン・ワークフローの関数と異なる方法で実装する必要があります。
これらの実装の相違点の詳細は、「ユーザー定義XPath拡張関数の実装方法」を参照してください。

- あるコンポーネント用で他のコンポーネントでは使用できない関数(例: Oracle Mediatorまたはヒューマン・ワークフローで使用できないOracle BPEL Process Manager用の関数)を作成する場合は、その関数をそのコンポーネントに固有の構成ファイルに作成します。この例では、Oracle BPEL Process Managerの関数をext-bpel-xpath-functions-config.xmlという構成ファイルに作成する必要があります。

次の例は、システム関数およびユーザー定義関数で使用される関数スキーマを示しています。

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://xmlns.oracle.com/soa/config/xpath"
targetNamespace="http://xmlns.oracle.com/soa/config/xpath"
elementFormDefault="qualified">
<element name="soa-xpath-functions" type="tns:XpathFunctionsConfig"/>
<element name="function" type="tns:XpathFunction"/>
<complexType name="XpathFunctionsConfig">
<sequence>
<element ref="tns:function" minOccurs="1" maxOccurs="unbounded"/>
</sequence>
<attribute name="resourceBundle" type="string"/>
<attribute name="version" type="string"/>
</complexType>

<complexType name="XpathFunction">
<sequence>
<element name="className" type="string"/>
<element name="return">
<complexType>
<attribute name="type" type="tns:XpathType"
use="required"/>
</complexType>
</element>
<element name="params" type="tns:Params" minOccurs="0"
maxOccurs="1"/>
<element name="desc">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="resourceKey"
type="string"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="detail" minOccurs="0">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="resourceKey"
type="string"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="icon" minOccurs="0">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="resourceKey"
type="string"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="helpURL" minOccurs="0">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="resourceKey"
type="string"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="group" minOccurs="0">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="resourceKey" type="string"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="wizardClass" type="string" minOccurs="0"/>
</sequence>
<attribute name="name" type="string" use="required"/>
<attribute name="deprecated" type="boolean" use="optional"/>
</complexType>

<complexType name="Params">
<sequence>
<element name="param" minOccurs="1" maxOccurs="unbounded">
<complexType>
<attribute name="name" type="string" use="required"/>
<attribute name="type" type="tns:XpathType"
use="required"/>
<attribute name="minOccurs" type="string"
default="1"/>
<attribute name="maxOccurs" type="string"
default="1"/>
<attribute name="wizardEnabled" type="boolean"
default="false"/>
</complexType>
</element>
</sequence>
</complexType>
<simpleType name="XpathType">
<restriction base="string">
<enumeration value="string"/>
<enumeration value="boolean"/>
<enumeration value="number"/>
<enumeration value="node-set"/>
<enumeration value="tree"/>
</restriction>
</simpleType>
</schema>

B.16.1 ユーザー定義XPath拡張関数の実装方法

この項では、Oracle SOA Suiteコンポーネントのユーザー定義XPath拡張関数を実装する方法を説明します。

B.16.1.1 XSLTマッパーに対する関数の実装方法

XSLTマップ・エディタのユーザー定義XPath拡張関数の実装は、他のコンポーネントと次の点で異なります。

- 各XSLTマップ・エディタ関数に、public staticクラスの対応するpublic staticメソッドが必要です。関数名とメソッド名が一致する必要があります。

- XSLTマップ・エディタ関数のネームスペースの形式はhttp://www.oracle.com/XSL/Transform/java/mypackage.MyFunctionClassである必要があり、mypackage.MyFunctionClassは、関数のpublic staticメソッドが含まれているpublic staticクラスの完全修飾クラス名です。

B.16.1.2 他のすべてのコンポーネントに対する関数の実装方法

Oracle BPEL Process Manager、Oracle Mediatorおよびヒューマン・ワークフローの関数では、oracle.fabric.common.xml.xpath.IXPathFunctionインタフェース(fabric-runtime.jarファイルで定義)またはjavax.xml.xpath.XPathFunctionを実装する必要があります。

他のすべてのコンポーネントに対する関数を実装する手順は、次のとおりです。

1. XPath関数用のoracle.fabric.common.xml.xpath.IXPathFunctionインタフェースを実装します。IXPathFunctionインタフェースには、call(context, args)という1つのメソッドがあります。次の例は、このメソッドのシグネチャを示しています。

package oracle.fabric.common.xml.xpath;
public interface IXPathFunction
{
/** Call this function.
*
*  @param context The context at the point in the
*         expression when the function is called.
*  @param args List of arguments provided during
*         the call of the function.
*/
public Object call(IXPathContext context, List args) throws
XPathFunctionException;
}

説明:

- context: 関数をコールした時点の式内のコンテキスト。

- args: 関数のコール時に指定する引数のリスト。

次の例では、getNodeValue(arg1)という関数が実装され、値w3c nodeを取得します。

package com.collaxa.cube.xml.xpath.dom.functions;
import oracle.fabric.common.xml.xpath.IXPathFunction;
import oracle.fabric.common.xml.xpath.IXPathFunction
. . .

public class GetNodeValue implements IXPathFunction {
Object call(IXPathContext context, List args) throws XPathFunctionException
{
org.w3c.dom.Node node = (org.w3c.dom.Node) args.get(0);
return node.getNodeValue()
}
}

B.16.2 ユーザー定義XPath拡張関数の構成方法

この項では、ユーザー定義XPath拡張関数の構成方法について説明します。

ユーザー定義XPath拡張関数を構成する手順は、次のとおりです。

1. 関数を定義するXPath拡張構成ファイルを作成します。次の例は、「ユーザー定義XPath拡張関数の作成」で示した関数スキーマに基づくサンプル構成ファイルを示しています。この例では、mf:myFunction1とmf:myFunction2の2つの関数が作成されます。

<?xml version="1.0" encoding="UTF-8"?>
<soa-xpath-functions resourceBundle="myPackage.myResourceBundle"
xmlns="http://xmlns.oracle.com/soa/config/xpath"
xmlns:mf="http://www.my-functions.com">
<function name="mf:myFunction1">
<className>myPackage.myFunctionClass1</className>
<return type="node-set"/>
<params>
<param name="p1" type="node-set" wizardEnabled="true"/>
<param name="p2" type="string"/>
<param name="p3" type="number" minOccurs="0"/>
<param name="p4" type="boolean" minOccurs="0"  maxOccurs="3"/>
</params>
<desc resourceKey="func1-desc-key">this is my first function</desc>
<detail resourceKey="func2-long-desc-key">my first function does ... </detail>
<icon>myPackage/resource/image/myFunction1.png</icon>
<group resourceKey="func-group-key">My Function Group</group>
<wizardClass>myPackage.myWizardClass1</wizardClass>
</function>
<function name="mf:myFunction2">
<className>myPackage.myFunctionClass2</className>
<return type="string"/>
<params>
<param name="p1" type="node-set" wizardEnabled="true"/>
<param name="p2" type="string"/>
<param name="p3" type="number" minOccurs="0"/>
<param name="p4" type="boolean" minOccurs="0"  maxOccurs="unbounded"/>
</params>
<desc resourceKey="func2-desc-key">this is my second function</desc>
<detail resourceKey="func2-long-desc-key">my second function does ...</detail>
<icon>myPackage/resource/image/myFunction2.png</icon>
<group resourceKey="func-group-key">My Function Group</group>
<wizardClass>myPackage.myWizardClass2</wizardClass>
</function>
</soa-xpath-functions>

表B-3 に、構成ファイルの要素を示します。各関数の構成ファイルで、そのルート要素としてsoa-xpath-functionsが使用されます。ルート要素にはオプションのresourceBundle属性があります。resourceBundleの値は、すべての関数構成に対するNational Language Support (NLS)を提供するリソース・バンドル・クラスの完全修飾クラス名です。

表B-3 関数スキーマの要素

要素

説明

className

関数実装クラスの完全修飾クラス名。

return

関数の戻り型。XPathおよびXSLTでサポートされているstring、number、boolean、ノードセットおよびtreeのいずれかを指定できます。

params

関数のパラメータ。関数にはパラメータがない場合があります。パラメータには次の属性があります。

- name: パラメータの名前。

- type: パラメータのタイプ。XPathおよびXSLTでサポートされているstring、number、boolean、ノードセットおよびtreeのいずれかを指定できます。

- minOccurs: パラメータの最少繰返し数。0に設定した場合、パラメータはオプションです。1に設定した場合は必須です。現在の制限では、この属性に指定できる値は0または1のみで、オプションのパラメータは必須パラメータの後に定義する必要があります。この属性を指定しない場合、デフォルト値は1です。

- maxOccurs: パラメータの最大繰返し数。unboundedに設定した場合、パラメータの繰返し数に制限はありません。このパラメータにより、無制限のパラメータを使用する可能性がある、XPath 1.0関数のconcat()などの関数をサポートできます。現在の制限では、関数の最終パラメータ以外のパラメータには、maxOccursに1より大きい値またはunboundedを指定できません。この属性を指定しない場合、デフォルト値は1です。

- wizardEnabled: パラメータ値の入力にウィザードを使用可能にするかどうかを示します。この指定によって、パラメータ値を入力する必要があるユーザー・インタフェースがサポートされます。trueに設定すると、パラメータ値のフィールドの横にウィザード起動ボタンが表示されます。ウィザード起動ボタンを押すと、ユーザーがパラメータ値を簡単に入力できるポップアップ・ウィザードが起動されます。ウィザード・クラスを後で指定する必要があります。この属性を指定しない場合のデフォルト値はfalseで、デフォルトでは、パラメータに関するウィザードのサポートはありません。

desc

関数の説明(オプション)。resourceKeyを指定した場合、説明はルート要素で前に指定したリソース・バンドルから取得されます。

detail

関数の長い(詳細な)説明(オプション)。resourceKeyを指定した場合、説明はルート要素で前に指定したリソース・バンドルから取得されます。

icon

関数のアイコンのURL(オプション)。resourceKeyを指定した場合、アイコンのURLはルート要素で前に指定したリソース・バンドルから取得されます。関数を表示する必要があるユーザー・インタフェースをサポートするための要素です。

helpURL

関数のヘルプHTMLのURL(オプション)。resourceKeyを指定した場合、ヘルプのURLはルート要素で前に指定したリソース・バンドルから取得されます。関数のヘルプ・リンクを表示する必要があるユーザー・インタフェースをサポートするための要素です。

group

関数のグループ名(オプション)。resourceKeyを指定した場合、グループ名はルート要素で前に指定したリソース・バンドルから取得されます。関数をグループ化する必要があるユーザー・インタフェースをサポートするための要素です。グループ名を指定しない場合、関数は、ユーザー・インタフェースでグループ化される際に組込みの拡張関数に分類されます。

wizardClass

ウィザードを使用可能にしたすべてのパラメータに対するウィザード・クラスの完全修飾クラス名。パラメータ値を入力する必要があるユーザー・インタフェースをサポートするための要素です。このウィザード・クラスは、ウィザード起動ボタンを押すと起動され、ユーザーがパラメータ値を簡単に入力できるようにします。ウィザードを使用可能にするパラメータを指定していない場合、この要素は指定しないでください。

注意: この要素は、ユーザー定義関数ではサポートされていません。この機能を現在サポートしているのはシステム関数のみです。

2. 関数を使用するコンポーネント・タイプに基づいて、ユーザー定義のXPath拡張構成ファイルの名前を指定します。表B-4 に、ユーザー定義構成ファイルに使用する命名規則を示します。

表B-4 ユーザー定義構成ファイル

関数を使用するコンポーネント

使用する構成ファイル名

Oracle BPEL Process Manager

ext-bpel-xpath-functions-config.xml

Oracle Mediator

ext-mediator-xpath-functions-config.xml

XSLTマッパー

ext-mapper-xpath-functions-config.xml

ヒューマン・ワークフロー

ext-wf-xpath-functions-config.xml

すべてのコンポーネント

ext-soa-xpath-functions-config.xml

3. 構成ファイルをコンパイル済クラスとともにJARファイル内に配置します。JARファイル内で、構成ファイルはMETA-INFディレクトリに格納される必要があります。JARファイルは特定のディレクトリに存在する必要はありません。

注意:

customXpathFunction JARは、SOAコンポジットの一部ではないため、明示的に追加する必要があります。

4. Oracle JDeveloperで、「ツール」→「プリファレンス」→「SOA」の順に選択します。

5. 「追加」ボタンをクリックし、JARファイルを選択します。

6. 変更を有効にするためにOracle JDeveloperを再起動します。

JARファイルがJVMのクラスパスに自動的に追加され、使用可能になります。

B.16.3 ユーザー定義関数のランタイムへのデプロイ方法

カスタムのJARファイルとクラスを追加するために、soa/modules/oracle.soa.ext_11.1.1ディレクトリが用意されています。詳細は、「カスタム・クラスとJARファイルの追加」を参照してください。

C デプロイメント・ディスクリプタのプロパティ

この付録では、Oracle WebLogic Server、Oracle Enterprise Manager Fusion Middleware Controlまたはその両方で実行時に使用されるBPELプロセス・サービス・コンポーネントのデプロイメント・ディスクリプタ構成およびパートナ・リンク・プロパティを定義する方法について説明します。

この付録の内容は次のとおりです。

- デプロイメント・ディスクリプタのプロパティの概要

デプロイメント・ディスクリプタのプロパティの詳細は、『パフォーマンスのチューニング』の「Oracle BPEL Process Managerのパフォーマンス・チューニング」を参照してください。

C.1 デプロイメント・ディスクリプタのプロパティの概要

デプロイメント・ディスクリプタは、Oracle WebLogic ServerまたはOracle Enterprise Manager Fusion Middleware Control、あるいはその両方によって実行時に使用されるBPELプロセス・サービス・コンポーネントのプロパティです。プロパティには、次の2種類があります。

- 構成

- パートナ・リンク・バインディング

表C-1 は、構成のデプロイメント・ディスクリプタのプロパティを示しています。

構成プロパティを定義する場合は、プロパティ名にbpel.configの接頭辞を追加する必要があります。たとえば、inMemoryOptimizationプロパティは、bpel.config.inMemoryOptimizationとして定義する必要があります。Oracle JDeveloperのプロパティ・インスペクタでプロパティを定義する方法の詳細は、「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。

表C-1 configurationsデプロイメント・ディスクリプタのプロパティ

プロパティ名

説明

completionPersistPolicy

このプロパティは、インスタンス・データの保存方法を構成します。BPELサービス・コンポーネント・レベルでのみ設定できます。使用可能な値は、次のとおりです。

- on(デフォルト): 終了したインスタンスは通常どおり保存されます。

- deferred: 終了したインスタンスは保存されますが、異なるスレッドを使用して別のトランザクションで保存されます。

- faulted: 失敗したインスタンスのみ保存されます。
注意: 未処理のフォルトが発生した場合は、これらのフラグに関係なく、インスタンスの監査情報がCUBE_INSTANCE表に保持されます。

- off: このプロセスのインスタンスは保存されません。

disableAsserts

このプロパティをtrueに設定すると、BPELプロジェクトでアサーションが無効になります。

globalTxMaxRetry

非同期BPELプロセスでアウトバウンド・アダプタを使用している場合は、リモート・フォルトに対する最大再試行回数を指定します。

globalTxRetryInterval

非同期BPELプロセスでアウトバウンド・アダプタを使用している場合は、リモート・フォルトに対する再試行間隔(ミリ秒単位)を指定します。

inMemoryOptimization

デフォルト値はfalseです。このプロパティをtrueに設定できるのは、デハイドレーション・ポイントがない場合のみです。wait、receive、onMessage、onAlarmなどのアクティビティでは、プロセス内にデハイドレーション・ポイントが作成されます。このプロパティをtrueに設定すると、to-spec問合せ時にこのプロセスのインスタンスに対するインメモリー最適化が試行されます。

keepGlobalVariables

インスタンスの完了後に、サーバーがグローバル変数値をインスタンス・ストアに保持できるかどうかを指定します。

- false (デフォルト): インスタンスが完了すると、グローバル変数値は削除されます。

- true: グローバル変数値は削除されません。

oneWayDeliveryPolicy

このプロパティは、プロセスの永続ポリシーを配信レイヤーに設定します。有効な値は、次のとおりです。

- async.persist: メッセージはデータベースに保存されます。この設定の場合、信頼性は確保されますが、データベースのパフォーマンスに多少の影響が出ます。システムの全体的なパフォーマンスに影響が出ることもあります。

- async.cache: 受信した配信メッセージはインメモリー・キャッシュにのみ保存されます。信頼性よりパフォーマンスを優先する場合は、この設定を検討してください。async.cacheに設定すると、一方向メッセージの到着頻度が配信の頻度よりかなり高い場合や、サーバー障害が発生した場合には、メッセージが失われる可能性があります。また、システムが過負荷の状態になり(メッセージがスケジュール済キューにたまり)、メモリー不足エラーが発生することもあります。各自のユースケース・シナリオを検討し、この設定が適切かどうかを判断してください。
高可用性環境でoneWayDeliveryPolicyをasync.cacheに設定すると、サーバー・クラッシュ発生時に実行途中の起動メッセージおよびコールバック・メッセージが失われたり、重複したりすることがあります。async.cacheに対しては、サーバーのフェイルオーバーはサポートされていません。詳細は、『高可用性ガイド』のOracle BPEL Process Managerの高可用性アーキテクチャとフェイルオーバーに関する考慮事項に関する項を参照してください。

- sync: 同じスレッドで直接起動が発生します。呼出しキューのメッセージのスケジューリングはバイパスされ、BPELインスタンスが同期的に呼び出されます。この設定は、データベースのパフォーマンスに影響を与えることがあります。

BPELプロセスを作成するときのこのプロパティの設定の詳細は、「BPELプロセス・サービス・コンポーネントの追加方法」を参照してください。

詳細は、『パフォーマンスのチューニング』のBPELに対するデータベース永続性のチューニングに関する項を参照してください。

reenableAggregationOnComplete

このプロパティは、メッセージをルーティングするために作成して使用するインスタンス数を制御します。有効な値は、次のとおりです。

- true: 同じ相関のメッセージを処理する新規インスタンスが作成されます。

- false: メッセージを処理するインスタンスが1つのみ作成されます。

詳細は、「同じインスタンスへのメッセージのルーティング」を参照してください。

sensorActionLocation

センサー・アクションXMLファイルの場所。センサー・アクションXMLファイルには、イベントに対するアクション・ルールが構成されています。

sensorLocation

センサーXMLファイルの場所。センサーXMLファイルは、イベントが記録されるセンサーのリストを定義したものです。

transaction

このプロパティは、コールを開始するBPELインスタンスのトランザクション動作を構成します。

- requiresNew: 新規トランザクションが実行のために作成され、既存のトランザクションがある場合はそのトランザクションが一時停止されます。この動作は、リクエスト/レスポンス(開始)環境、およびbpel.config.oneWayDeliveryPolicyがsyncに設定されている一方向開始環境の両方に適用されます。

- required: リクエスト/レスポンス(開始)環境では、この設定によって、トランザクションがある場合はコール元トランザクションが結合され、トランザクションがない場合は新規トランザクションが作成されます。bpel.config.oneWayDeliveryPolicyがsyncに設定されている一方向開始環境では、起動メッセージは、同じトランザクションの同一スレッドを使用して処理されます。

- notSupported: トランザクションを必要とせずにビジネス・プロセスを実行します。詳細は、「トランザクションなしのビジネス・プロセスの実行」を参照してください。

注意: このプロパティは、中間プロセスのreceiveアクティビティには適用されません。この場合は、別のトランザクションの別のスレッドを使用してメッセージが処理されます。これは、相関が必要であり、常に非同期で処理されるためです。

BPELプロセスを作成するときのこのプロパティの設定の詳細は、「BPELプロセス・サービス・コンポーネントの追加方法」を参照してください。

表C-2 は、パートナ・リンク・バインディングのデプロイメント・ディスクリプタのプロパティを示しています。

パートナ・リンク・バインディング・プロパティを定義する場合は、プロパティ名にbpel.partnerLink.partner_link_nameの接頭辞を追加する必要があります。たとえば、nonBlockingInvokeプロパティは、bpel.partnerLink.partner_link_name.nonBlockingInvokeとして定義する必要があります。Oracle JDeveloperのプロパティ・インスペクタでプロパティを定義する方法の詳細は、「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。

表C-2 partnerLinkBindingデプロイメント・ディスクリプタのプロパティ

プロパティ名

説明

idempotent

idempotentアクティビティとは、再試行可能なアクティビティ(assignアクティビティやinvokeアクティビティなど)です。非冪等アクティビティの後にインスタンスが保存されます。このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

- true (デフォルト): サーバーに障害が発生した場合、再起動後にアクティビティが再度実行されます。これは、アクティビティの呼出し直後にサーバーがデハイドレーションされず、アクティビティの実行が記録されていないためです。

- false: アクティビティは実行直後にデハイドレーションされ、デハイドレーション・ストアに記録されます。idempotentをfalseに設定すると、フェイルオーバーによる保護は強化されますが、BPELプロセスがデハイドレーション・ストアに頻繁にアクセスする場合はパフォーマンスに影響が出ることがあります。
idempotentプロパティをfalseに設定した場合のフォルト処理の使用方法の詳細は、「idempotentプロパティとフォルト処理に関する必知事項」を参照してください。

idempotentプロパティの詳細は、「パートナ・リンク操作レベルでの冪等性の管理」を参照してください。

nonBlockingInvoke

デフォルト値はfalseです。trueに設定されている場合は、独立したスレッドを生成して起動を行うため、invokeアクティビティによってインスタンスがブロックされることはありません。

詳細は、「シングル・スレッドでのフローのブランチのパラレル実行に関する必知事項」を参照してください。

validateXML

メッセージの境界の検証を有効化します。trueに設定すると、このパートナ・リンクに対するreceiveアクティビティおよびinvokeアクティビティ中に、XMLメッセージがXMLスキーマと照合して検証されます。XMLメッセージが無効な場合は、bpelx:invalidVariables実行時フォルトがスローされます。これによって、ドメイン・レベルのvalidateXMLプロパティがオーバーライドされます。

C.1.1 プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法

構成およびパートナ・リンク・バインディングのデプロイメント・ディスクリプタのプロパティと値は、Oracle JDeveloperのプロパティ・インスペクタで定義します。完了すると、composite.xmlファイルのBPELプロセス・サービス・コンポーネント・セクションにプロパティが表示されます。

1. SOAコンポジット・エディタで、図C-1 に示すように、BPELプロセス・サービス・コンポーネントを選択します。

図C-1 選択されたBPELプロセス・サービス・コンポーネント

2. Oracle JDeveloperの右下の隅にある「プロパティ・インスペクタ」に移動します。

3. 図C-2 に示すように、「プロパティ」セクションで「追加」アイコンをクリックします。

この例では、BPELプロセスの作成時に「BPELプロセスの作成」ダイアログで「配信」オプションが選択されていたため、oneWayDeliveryPolicyプロパティがすでに定義されています。BPELプロセスを作成するときのこのプロパティの設定の詳細は、「BPELプロセス・サービス・コンポーネントの追加方法」を参照してください。

図C-2 プロパティ・インスペクタ

「プロパティの作成」ダイアログが表示されます。

4. 「名前」フィールドに、デプロイメント・ディスクリプタのプロパティを入力します。この例では、構成のデプロイメント・ディスクリプタのプロパティoneWayDeliveryPolicyが定義されています。そのため、bpel.configの接頭辞が必要です。構成のデプロイメント・ディスクリプタのプロパティの詳細は、表C-1 を参照してください。

そのかわりにパートナ・リンク・バインディング・プロパティを追加する場合は、bpel.partnerLink.partner_link_nameの接頭辞が必要です(partner_link_nameはパートナ・リンクの名前です。例: LoanService)。パートナ・リンク・バインディングのデプロイメント・ディスクリプタのプロパティの詳細は、表C-2 を参照してください。

5. 「値」フィールドに、このプロパティに適用可能な値(たとえばasync.persist)を入力します。

6. 「OK」をクリックします。

プロパティ・インスペクタに、追加されたデプロイメント・ディスクリプタのプロパティが表示されます。

7. SOAコンポジット・エディタで「ソース」をクリックします。

次の例に示すように、composite.xmlファイル内にbpel.config接頭辞が付いたoneWayDeliveryPolicy構成プロパティが表示されます。

<component name="LoanApproval" version="2.0">
. . .
<componentType>
. . .
. . .
</componentType>
<property name="bpel.config.oneWayDeliveryPolicy" type="xs:string"
many="false">async.persist</property>
</component>

プロパティ・インスペクタで、かわりにパートナ・リンク・バインディングのデプロイメント・ディスクリプタのプロパティ(たとえば、nonBlockingInvokeパートナ・リンク・バインディング・プロパティ)を定義した場合は、次の例に示すように、composite.xmlファイル内に表示されます。接頭辞が、このタイプのプロパティに必要なbpel.partnerLink.partner_link_nameであることに注目してください。

<component name="myBPELServiceComponent" version="2.0">
. . .
<componentType>
. . .
. . .
</componentType>
<property name="bpel.partnerLink.partner_link_name.nonBlockingInvoke">
false</property>
</component>

C.1.2 BPELプロセス内でのプリファレンス値の取得方法

プロパティの値は、XPath拡張関数ora:getPreference(myPref)を使用してBPELプロセスで読み取ることができます。これによって、bpel.preference.myPrefの値を取得します。

この関数は、単純なassign文の一部として、または条件式の中で、あるいはより複雑なXPath式の一部として使用できます。

D センサー・パブリック・ビューとセンサー・アクションXSDの理解

この付録では、利用可能なセンサー・パブリック・ビュー、およびOracle BPEL Designerにインポート可能なセンサー・アクションXSDファイルについて説明します。

この付録の内容は次のとおりです。

- センサー・パブリック・ビューとセンサー・アクションXSDファイルの概要

- センサー・パブリック・ビュー

- センサー・アクションXSDファイル

詳細は、「Oracle BPEL Process Managerセンサーと分析の使用」を参照してください。

D.1 センサー・パブリック・ビューとセンサー・アクションXSDファイルの概要

データを使用する任意のアプリケーションからセンサー値へのSQLアクセスを実行できるように、一連のパブリック・ビューが公開されています。また、Oracle BPELデザイナへのインポート用に、サンプルのセンサー・アクション・スキーマが用意されています。

D.2 センサー・パブリック・ビュー

Oracle BPEL Process Managerのセンサー・フレームワークには、BPELインスタンスの処理によって生成されたセンサー値を、Oracle BPEL Process Managerのデハイドレーション・ストアに保存されたリレーショナル・スキーマに保持する機能があります。データは、Oracle Enterprise Manager Fusion Middleware Controlでプロセス・インスタンスのセンサー値を表示するために使用されます。

D.2.1 スキーマ

データベース・パブリッシャは、データベースで事前定義されたリレーショナル・スキーマにセンサー・データを保持します。次のパブリック・ビューをクライアント(Oracle Warehouse、ポータルなど)から使用して、センサー値をSQLで問い合せることができます。

注意:

表D-1 から表D-4 で、「索引付きまたは一意」列には、一意の索引名と属性の順序が表示されます。たとえば「U1,2」は、その属性が「U1」という名前の一意の索引の2番目であることを示します。「PK」は主キーであることを表します。

D.2.1.1 BPEL_PROCESS_INSTANCES

表D-1 には、のすべてのプロセス・インスタンスの概要が含まれます。

表D-1 BPEL_PROCESS_INSTANCESビュー

属性名

SQLタイプ

属性サイズ

索引付きまたは一意

NULL可

コメント

INSTANCE_KEY

NUMBER

--

PK

不可

一意のインスタンスID

APPLICATION_NAME

VARCHAR2

500

--

不可

ユーザー定義のアプリケーション名

COMPOSITE_NAME

VARCHAR2

500

--

不可

ユーザー定義のコンポジット名

REVISION

VARCHAR2

50

--

不可

ユーザー定義のリビジョン番号

LABEL

VARCHAR2

500

--

不可

ユーザー定義のラベル

COMPONENT_NAME

VARCHAR2

500

--

不可

ユーザー定義のコンポーネント名

TITLE

NVARCHAR2

200

--

可

BPELプロセスのユーザー定義タイトル

STATE

NUMBER

--

--

可

BPELプロセス・インスタンスの状態

STATE_TEXT

VARCHAR2

21

--

可

状態属性のテキスト表現

PRIORITY

NUMBER

--

--

可

BPELプロセス・インスタンスのユーザー定義の優先度

STATUS

NVARCHAR2

200

--

可

BPELプロセスのユーザー定義のステータス

STAGE

VARCHAR2

100

--

可

BPELプロセスのユーザー定義のステージ・プロパティ

CONVERSATION_ID

VARCHAR2

256

--

可

BPELプロセスのユーザー定義の対話ID

CREATION_DATE

TIMESTAMP

6

--

不可

プロセス・インスタンス作成のタイムスタンプ

MODIFY_DATE

TIMESTAMP

6

--

可

プロセス・インスタンス変更のタイムスタンプ

TS_DATE

DATE

--

--

可

modify_dateの日付部分

TS_HOUR

NUMBER

--

--

可

modify_dateの時間部分

EVAL_TIME

NUMBER

--

--

可

プロセス・インスタンスの評価時間(ミリ秒)

D.2.1.2 BPEL_ACTIVITY_SENSOR_VALUES

表D-2 には、監視しているBPELプロセスのすべてのアクティビティ・センサー値が含まれます。

表D-2 BPEL_ACTIVITY_SENSOR_VALUESビュー

属性名

SQLタイプ

属性サイズ

索引付きまたは一意

NULL可

コメント

SENSOR_NAME

NVARCHAR2

200

U1,2

不可

起動されたセンサーの名前

SENSOR_TARGET

NVARCHAR2

512

--

不可

起動されたセンサーのターゲット

ACTION_NAME

NVARCHAR2

200

U1,3

不可

センサー・アクションの名前

ACTION_FILTER

NVARCHAR2

512

--

可

アクションのフィルタ

CREATION_DATE

TIMESTAMP

6

--

不可

アクティビティ・センサー値の作成日時

MODIFY_DATE

TIMESTAMP

6

--

可

最終変更のタイムスタンプ

TS_DATE

DATE

--

--

可

modify_dateの日付部分

TS_HOUR

NUMBER

--

--

可

modify_dateの時間部分

CRITERIA_SATISFIED

VARCHAR2

1

--

可

NULL、YまたはN

ACTIVITY_NAME

NVARCHAR2

200

--

不可

BPELアクティビティの名前

ACTIVITY_TYPE

VARCHAR2

30

--

不可

BPELアクティビティのタイプ

ACTIVITY_STATE

VARCHAR2

30

--

可

BPELアクティビティの状態

EVAL_POINT

VARCHAR2

30

--

不可

アクティビティ・センサーの評価ポイント

ERROR_MESSAGE

NCLOB

--

--

可

エラー・メッセージ

RETRY_COUNT

NUMBER

--

--

可

アクティビティの再試行回数

EVAL_TIME

NUMBER

--

--

可

アクティビティの評価時間(ミリ秒)

ID

NUMBER

--

PK

不可

一意のID

INSTANCE_KEY

NUMBER

--

U1,1

不可

BPELプロセスID

APPLICATION_NAME

VARCHAR2

500

--

不可

ユーザー定義のアプリケーション名

COMPOSITE_NAME

VARCHAR2

500

--

不可

ユーザー定義のコンポジット名

REVISION

VARCHAR2

50

--

不可

ユーザー定義のリビジョン番号

LABEL

VARCHAR2

500

--

不可

ユーザー定義のラベル

COMPONENT_NAME

VARCHAR2

500

--

不可

ユーザー定義のコンポーネント名

D.2.1.3 BPEL_FAULT_SENSOR_VALUES

表D-3 には、すべてのフォルト・センサー値が含まれます。

表D-3 BPEL_FAULT_SENSOR_VALUESビュー

属性名

SQLタイプ

属性サイズ

索引付きまたは一意

NULL可

コメント

ID

NUMBER

--

PK

不可

一意のID

INSTANCE_KEY

NUMBER

--

U1,1

不可

BPELプロセスID

APPLICATION_NAME

VARCHAR2

500

--

不可

ユーザー定義のアプリケーション名

COMPOSITE_NAME

VARCHAR2

500

--

不可

ユーザー定義のコンポジット名

REVISION

VARCHAR2

50

--

不可

ユーザー定義のリビジョン番号

LABEL

VARCHAR2

500

--

不可

ユーザー定義のラベル

COMPONENT_NAME

VARCHAR2

500

--

不可

ユーザー定義のコンポーネント名

SENSOR_NAME

NVARCHAR2

200

U1,2

不可

起動されたセンサーの名前

SENSOR_TARGET

NVARCHAR2

512

--

不可

起動されたセンサーのターゲット

ACTION_NAME

NVARCHAR2

200

U1,3

不可

センサー・アクションの名前

ACTION_FILTER

NVARCHAR2

512

--

可

アクションのフィルタ

CREATION_DATE

TIMESTAMP

6

--

不可

アクティビティ・センサー値の作成日時

MODIFY_DATE

TIMESTAMP

6

--

可

最終変更のタイムスタンプ

TS_DATE

DATE

--

--

可

modify_dateの日付部分

TS_HOUR

NUMBER

--

--

可

modify_dateの時間部分

CRITERIA_SATISFIED

VARCHAR2

1

--

可

NULL(アクション・フィルタの指定なし)、Y(アクション・フィルタが指定されており、評価がtrue)、N(それ以外)

ACTIVITY_NAME

NVARCHAR2

200

--

不可

BPELアクティビティの名前

ACTIVITY_TYPE

VARCHAR2

30

--

不可

BPELアクティビティのタイプ

MESSAGE

CLOB

--

--

可

フォルト・メッセージ

D.2.1.4 BPEL_VARIABLE_SENSOR_VALUES

表D-4 には、すべての変数センサー値が含まれます。

表D-4 BPEL_VARIABLE_SENSOR_VALUESビュー

属性名

SQLタイプ

属性サイズ

索引付きまたは一意

NULL可

コメント

ID

NUMBER

--

PK

不可

一意のID

INSTANCE_KEY

NUMBER

--

U1,1

不可

BPELプロセスID

APPLICATION_NAME

VARCHAR2

500

--

不可

ユーザー定義のアプリケーション名

COMPOSITE_NAME

VARCHAR2

500

--

不可

ユーザー定義のコンポジット名

REVISION

VARCHAR2

50

--

不可

ユーザー定義のリビジョン番号

LABEL

VARCHAR2

500

--

不可

ユーザー定義のラベル

COMPONENT_NAME

VARCHAR2

500

--

不可

ユーザー定義のコンポーネント名

SENSOR_NAME

NVARCHAR2

200

U1,2

不可

起動されたセンサーの名前

SENSOR_TARGET

NVARCHAR2

512

--

不可

センサーのターゲット

ACTION_NAME

NVARCHAR2

200

U1,3

不可

アクションの名前

ACTION_FILTER

NVARCHAR2

512

--

可

アクションのフィルタ

ACTIVITY_SENSOR

NUMBER

--

--

可

対応するアクティビティ・センサー値のID

CREATION_DATE

TIMESTAMP

6

--

不可

作成日時

TS_DATE

DATE

--

--

不可

creation_dateの日付部分

TS_HOUR

NUMBER

--

--

不可

creation_dateの時間部分

VARIABLE_NAME

NVARCHAR2

512

--

不可

BPEL変数の名前

EVAL_POINT

VARCHAR2

30

--

可

対応するアクティビティ・センサーの評価ポイント

CRITERIA_SATISFIED

VARCHAR2

1

--

可

NULL、YまたはN

TARGET

NVARCHAR2

512

--

--

--

UPDATER_NAME

NVARCHAR2

200

--

不可

変数を更新したアクティビティまたはイベントの名前

UPDATER_TYPE

NVARCHAR2

200

--

不可

BPELアクティビティまたはイベントのタイプ

SCHEMA_NAMESPACE

NVARCHAR2

512

--

可

変数センサー値のネームスペース

SCHEMA_DATATYPE

NVARCHAR2

512

--

可

変数センサー値のデータ型

VALUE_TYPE

NUMBER

--

--

不可

変数の値の型(java.sql.Typesの値に対応)

VARCHAR2_VALUE

NVARCHAR2

4000

--

可

文字列形式の変数の値

NUMBER_VALUE

NUMBER

--

--

可

DATE_VALUE

TIMESTAMP

6

--

可

ユーザー定義の日付

DATE_VALUE_TZ

VARCHAR2

10

--

可

ユーザー定義のタイムゾーン

BLOB_VALUE

BLOB

--

--

可

CLOB_VALUE

CLOB

--

--

可

D.3 センサー・アクションXSDファイル

次の例は、Oracle BPELデザイナにインポート可能なセンサー・アクション・スキーマのサンプルを示しています。このスキーマは、カスタム・データ・パブリッシャにも関連します。

<?xml version="1.0" encoding="utf-8"?>
<!--
This schema contains the sensor definition. Sensors monitor data
and execute callbacks appropriately.

BPEL designer uses this file as a template to generate to generate
SensorActionData.xsd. It does this by replacing special tags.
Do not modify these special tags. For details, see comments in the file.
The replacement is done using a simple text replacement, so the white
spaces too should be preserved as indicated in comments.
-->
<xsd:schema blockDefault="#all" elementFormDefault="qualified"
targetNamespace="http://xmlns.oracle.com/bpel/sensor"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:sensor="http://xmlns.oracle.com/bpel/sensorDataPlaceHolder"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://xmlns.oracle.com/bpel/sensor"
nxsd:encoding="UTF-8">

<!-- *** The following line is a place holder. Do not remove it. It must remain as
is, including any whitespace.  If you change this, please let BAM sensor action
developer know. -->
<!-- $importSensorVar -->

<xsd:simpleType name="tSensorActionPublishType">
<xsd:annotation>
<xsd:documentation>
This enumeration lists the possibe publishing types for probes.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="BpelReportsSchema"/>
<xsd:enumeration value="JMSQueue"/>
<xsd:enumeration value="JMSTopic"/>
<xsd:enumeration value="BAM"/>
<xsd:enumeration value="LogFile"/>
<xsd:enumeration value="Custom"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="tSensorActionProperty">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="name" use="required" type="xsd:string"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>

<!--
Attributes of a sensor action
-->
<xsd:attributeGroup name="tSensorActionAttributes">
<xsd:attribute name="name" type="xsd:string" use="optional"/>
<xsd:attribute name="enabled" type="xsd:boolean" use="optional"
default="true"/>
<xsd:attribute name="filter" type="xsd:string"/>
<xsd:attribute name="publishName" type="xsd:string" use="required"/>
<xsd:attribute name="publishType" type="tns:tSensorActionPublishType"
use="required"/>
<!--
the name of the JMS Queue/Topic or custom java API, ignored for other
publishTypes
-->
<xsd:attribute name="publishTarget" type="xsd:string" use="optional"/>
</xsd:attributeGroup>

<!--
The sensor action type. A sensor action consists:
+ unique name
+ effective date
+ expiration date - Optional. If not defined, the probe is active
indefinitely.
+ filter (to potentially suppress data publishing even if a sensor marks
it as interesting). - Optional. If not defined, no filter is
used.
+ publishName A name of a publisher
+ publishType What to do with the sensor data?
+ publishTarget Name of a JMS Queue/Topic or custom publisher.
+ potentially many sensors.
-->
<xsd:complexType name="tSensorAction">
<xsd:sequence>
<xsd:element name="sensorName" type="xsd:string" minOccurs="1"
maxOccurs="unbounded"/>
<xsd:element name="property" minOccurs="0" maxOccurs="unbounded"
type="tns:tSensorActionProperty"/>
</xsd:sequence>
<xsd:attributeGroup ref="tns:tSensorActionAttributes"/>
</xsd:complexType>

<!--
define a listing of sensor actions in a single document. It might be a good
idea  to
have one sensor action list per business process.
-->
<xsd:complexType name="tSensorActionList">
<xsd:sequence>
<xsd:element name="action" type="tns:tSensorAction" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:simpleType name="tSensorKind">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="fault"/>
<xsd:enumeration value="variable"/>
<xsd:enumeration value="activity"/>
<xsd:enumeration value="service"/>
<xsd:enumeration value="reference"/>
<xsd:enumeration value="event"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="tActivityConfig">
<xsd:annotation>
<xsd:documentation>
The configuration part of an activity sensor comprises of a mandatory
'evalTime' attribute
and an optional list of variable configurations
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:tSensorConfig">
<xsd:sequence>
<xsd:element name="variable" type="tns:tActivityVariableConfig"
maxOccurs="unbounded" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="evalTime" type="xsd:string" use="required"/>
</xsd:extension>
</xsd:complexContent>      </xsd:complexType>

<xsd:complexType name="tVariableConfig">
<xsd:complexContent>
<xsd:extension base="tns:tSensorConfig">
<xsd:attribute name="outputDataType" use="required" type="xsd:string"/>
<xsd:attribute name="outputNamespace" use="required" type="xsd:string"/>
<xsd:attribute name="queryName" use="optional" type="xsd:string"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="tActivityVariableConfig">
<xsd:complexContent>
<xsd:extension base="tns:tVariableConfig">
<xsd:attribute name="target" type="xsd:string" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="tFaultConfig">
<xsd:complexContent>
<xsd:extension base="tns:tSensorConfig"/>
</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="tSensorConfig"/>

<xsd:complexType name="tExpressionConfig">
<xsd:complexContent>
<xsd:extension base="tns:tVariableConfig">
<xsd:attribute name="expression" use="required" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
expresion="$in/$payload/$partName/xpathExpression |
$in/$header/xpathExpression |
$in/$property/name |
$out/$payload/$partName/xpathExpression |
$out/$header/xpathExpression |
$out/$property/name |
$fault/$payload/$partName/xpathExpression |
$fault/$header/xpathExpression |
$fault/$property/name"

Where
$in - The input/request message to the operation/event
$out - The output/Response message from the operation
$fault - The fault message from the operation
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>          </xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="tOperationConfig">
<xsd:complexContent>
<xsd:extension base="tns:tExpressionConfig">
<xsd:attribute name="operation" use="required" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
The name of the operation in the service/reference on which the
sensor is defined.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="tServiceConfig">
<xsd:complexContent>
<xsd:extension base="tns:tOperationConfig">
<xsd:attribute name="service" use="required" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
The name of the service on which the sensor is defined.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="tReferenceConfig">
<xsd:complexContent>
<xsd:extension base="tns:tOperationConfig">
<xsd:attribute name="reference" use="required" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
The name of the reference on which the sensor is defined.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="tEventConfig">
<xsd:complexContent>
<xsd:extension base="tns:tExpressionConfig">               <xsd:attribute name="component" type="xsd:string" use="required">
<xsd:annotation>
<xsd:documentation>
The name of the component which raises or receives the event.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="event" use="required" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
The name of the event that the component raises or receives.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="actionType" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Publish"/>
<xsd:enumeration value="Subscribe"/>                       </xsd:restriction>
</xsd:simpleType>
</xsd:attribute>             </xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="tSensor">
<xsd:sequence>
<xsd:element name="activityConfig" type="tns:tActivityConfig"
minOccurs="0"/>
<xsd:element name="faultConfig" type="tns:tFaultConfig" minOccurs="0"/>
<xsd:element name="variableConfig" type="tns:tVariableConfig"
minOccurs="0"/>
<xsd:element name="serviceConfig" type="tns:tServiceConfig" minOccurs="0"/>
<xsd:element name="referenceConfig" type="tns:tReferenceConfig"
minOccurs="0"/>
<xsd:element name="eventConfig" type="tns:tEventConfig" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="sensorName" use="required" type="xsd:string"/>
<xsd:attribute name="kind" use="required" type="tns:tSensorKind"/>
<xsd:attribute name="target" use="required" type="xsd:string"/>
<xsd:attribute name="filter" type="xsd:string"/>
</xsd:complexType>

<xsd:complexType name="tSensorList">
<xsd:sequence>
<xsd:element name="sensor" type="tns:tSensor" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="tProperty">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="name" use="required" type="xsd:string"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>

<xsd:complexType name="tHeaderInfo">
<xsd:sequence>
<xsd:element name="applicationName" type="xsd:string"/>
<xsd:element name="compositeName" type="xsd:string"/>
<xsd:element name="compositeInstanceId" type="xsd:string"/>
<xsd:element name="compositeRevision" type="xsd:string"/>
<xsd:element name="compositeLabel" type="xsd:string"/>
<xsd:element name="componentName" type="xsd:string"/>
<xsd:element name="processName" type="xsd:string"/>
<xsd:element name="processRevision" type="xsd:string"/>
<xsd:element name="domain" type="xsd:string"/>
<xsd:element name="instanceId" type="xsd:integer"/>
<xsd:element name="midTierInstance" type="xsd:string"/>
<xsd:element name="timestamp" type="xsd:dateTime"/>
<xsd:element name="sensor" type="tns:tSensor"/>
<xsd:element name="property" minOccurs="0" maxOccurs="unbounded"
type="tns:tProperty"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="tSensorData">
<xsd:sequence>
<xsd:element name="activityData" type="tns:tActivityData" minOccurs="0"/>
<xsd:element name="faultData" type="tns:tFaultData" minOccurs="0"/>
<xsd:element name="variableData" type="tns:tVariableData" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="serviceData" type="tns:tServiceData" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="referenceData" type="tns:tReferenceData" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="eventData" type="tns:tEventData" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="tFaultData">
<xsd:sequence>
<xsd:element name="activityName" type="xsd:string"/>
<xsd:element name="activityType" type="xsd:string"/>
<xsd:element name="faultName" type="xsd:QName"/>
<!-- *** The following line is a place holder. Do not remove it. It must
remain as is, including any whitespace.  If you change this, please let BAM
sensor action developer know. -->
<xsd:element name="data" type="xsd:anyType" minOccurs="0"/> <!-- DO NOT
MODIFY: fault data type -->
</xsd:sequence>
</xsd:complexType>

<!--
xml type that will be provided to sensors for variable Datas. Note the
any element represents variable data.
-->
<xsd:complexType name="tVariableData">
<xsd:sequence>
<xsd:element name="dataType" type="xsd:integer"/>
<!-- *** The following line is a place holder. Do not remove it. It must
remain as is, including any whitespace.  If you change this, please let BAM
sensor action developer know. -->
<xsd:element name="data" type="xsd:anyType"/> <!-- DO NOT MODIFY: sensor
variable data type -->
<xsd:element name="queryName" type="xsd:string"/>
<xsd:element name="target" type="xsd:string"/>
<xsd:element name="updaterName" type="xsd:string" minOccurs="1"/>
<xsd:element name="updaterType" type="xsd:string" minOccurs="1"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="tServiceData">
<xsd:sequence>
<xsd:element name="sensorName" type="xsd:string"/>
<xsd:element name="data" type="xsd:anyType"/>
<xsd:element name="dataType" type="xsd:integer"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="tReferenceData">
<xsd:sequence>
<xsd:element name="sensorName" type="xsd:string"/>
<xsd:element name="data" type="xsd:anyType"/>
<xsd:element name="dataType" type="xsd:integer"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="tEventData">
<xsd:sequence>
<xsd:element name="sensorName" type="xsd:string"/>
<xsd:element name="data" type="xsd:anyType"/>
<xsd:element name="dataType" type="xsd:integer"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="tActivityData">
<xsd:sequence>
<xsd:element name="activityType" type="xsd:string"/>
<xsd:element name="evalPoint" type="xsd:string"/>
<xsd:element name="durationInSeconds" minOccurs="0" type="xsd:double"/>
<xsd:element name="duration" type="xsd:duration" minOccurs="0"/>
<xsd:element name="errorMessage" nillable="true" minOccurs="0"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>

<!--
The header of the document contains some metadata.
-->
<!--
Sensor Action data is presented in the form of a header and potentially many
data
elements depending on how many sensors associated to the sensor action marked
the
data as interesting.
-->
<xsd:complexType name="tSensorActionData">
<xsd:sequence>
<xsd:element name="header" type="tns:tHeaderInfo"/>
<xsd:element name="payload" type="tns:tSensorData" minOccurs="1"
maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>

<!--
<xsd:simpleType name="tActivityEvalPoint">
<xsd:restriction>
<xsd:enumeration value="start"/>
<xsd:enumeration value="complete"/>
<xsd:enumeration value="fault"/>
<xsd:enumeration value="compensate"/>
<xsd:enumeration value="retry"/>
</xsd:restriction>
</xsd:simpleType>

-->

<!--
The process sensor value header comprises of a timestamp
where the sensor was triggered and the sensor metadata
-->
<xsd:complexType name="tProcessSensorValueHeader">
<xsd:sequence>
<xsd:element name="timestamp" type="xsd:dateTime"/>
<xsd:element ref="tns:sensor"/>
</xsd:sequence>
</xsd:complexType>
<!--
Extend tActivityData to include more elements
-->
<xsd:complexType name="tProcessActivityData">
<xsd:complexContent>
<xsd:extension base="tns:tActivityData">
<xsd:sequence>
<xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="evalTime" type="xsd:long" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="retryCount" type="xsd:int" minOccurs="0"
maxOccurs="1"/>
</xsd:sequence>            </xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<!--
Extend tVariableData to include more elements
-->
<xsd:complexType name="tProcessVariableData">
<xsd:complexContent>
<xsd:extension base="tns:tVariableData">
<xsd:sequence>
<xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
</xsd:sequence>            </xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<!--
Extend tFaultData to include more elements
-->
<xsd:complexType name="tProcessFaultData">
<xsd:complexContent>
<xsd:extension base="tns:tFaultData">
<xsd:sequence>
<xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
</xsd:sequence>            </xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<!--
Copy of tSensorData type with some modified types.
-->
<xsd:complexType name="tProcessSensorData">
<xsd:sequence>
<xsd:element name="activityData" type="tns:tProcessActivityData"
minOccurs="0"/>
<xsd:element name="faultData" type="tns:tProcessFaultData" minOccurs="0"/>
<xsd:element name="variableData" type="tns:tProcessVariableData"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<!--
A single process sensor value comprises of the sensor value metadata
(sensor and timestamp) and the payload (the value) of the sensor
-->
<xsd:complexType name="tProcessSensorValue">
<xsd:sequence>
<xsd:element name="header" type="tns:tProcessSensorValueHeader"/>
<xsd:element name="payload" type="tns:tProcessSensorData"/>
</xsd:sequence>
</xsd:complexType>

<!--
Process instance header.
-->
<xsd:complexType name="tProcessInstanceInfo">
<xsd:sequence>
<xsd:element name="processName" type="xsd:string"/>
<xsd:element name="processRevision" type="xsd:string"/>
<xsd:element name="domain" type="xsd:string"/>
<xsd:element name="instanceId" type="xsd:integer"/>
</xsd:sequence>
</xsd:complexType>

<!--
The list of sensor values comprises of a process header describing the
BPEL process with name, cube instance id etc. and a list of sensor values
comprising of sensor metadata information and sensor values.
-->
<xsd:complexType name="tProcessSensorValueList">
<xsd:sequence>
<xsd:element name="process" type="tns:tProcessInstanceInfo" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="sensorValue" type="tns:tProcessSensorValue" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<!-- The sensor list is the root element of the sensor.xml document in the
bpel process suitcase and is used to define sensors. -->
<xsd:element name="sensors" type="tns:tSensorList"/>

<!-- A sensor is used to monitor a particular aspect of a bpel process -->
<xsd:element name="sensor" type="tns:tSensor"/>

<!-- The actions element is the root element of the sensorAction.xml document
in the bpel process suitcase and is used to define sensor actions.
Sensor actions define how to publish data captured by sensors -->
<xsd:element name="actions" type="tns:tSensorActionList"/>

<!-- actionData elements are produced by the sensor framework and sent to the
appropriate data publishers when sensors 'fire' -->
<xsd:element name="actionData" type="tns:tSensorActionData"/>

<!-- This element is used when the client API is used to query sensor values
stored in the default reports schema -->
<xsd:element name="sensorValues" type="tns:tProcessSensorValueList"/>
</xsd:schema>

E メッセージ・ヘッダーを介した正規化メッセージ・プロパティの伝播

この付録では、正規化されたメッセージのプロパティをメッセージ・ヘッダーを介して伝播できるように設定する方法について説明します。

この付録の内容は次のとおりです。

- 正規化されたメッセージの概要

- bpelx拡張による正規化されたメッセージのプロパティの操作

E.1 正規化されたメッセージの概要

ヘッダーの操作と伝播は、重要なビジネス統合メッセージング要件です。Oracle BPEL Process Manager、Oracle Mediator、Oracle JCAアダプタ、RESTアダプタ、Oracle B2Bなどのコンポーネントは、顧客の統合ニーズを解決するためにヘッダー・サポートに大きく依存しています。たとえば、メッセージ・ヘッダーを介してファイル名を伝播することで、そのファイル名をソース・ディレクトリからターゲット・ディレクトリに保存できます。Oracle BPEL Process ManagerとOracle Mediatorでは、様々なユーザー・インタフェース・サポート・レベルでヘッダーにアクセスし、操作して設定できます。

正規化されたメッセージは、プロパティとペイロードという2つの部分のみを持つように簡素化されています。

通常、プロパティはスカラー型の名前-値のペアです。既存の複雑なヘッダーをプロパティに合せるために、プロパティはスカラー型にフラット化されています。

複雑なプロパティは事前に決定されているため、設計時にヘッダーを操作する際のユーザー操作は合理化されています。メディエータ・エディタまたはOracle BPELデザイナでは、なんらかの予約済キーワードを使用してヘッダーを操作できます。

ただし、この方法はユーザー入力に基づいて動的に生成されるプロパティに対処していません。選択内容に基づいてヘッダーが定義されます。これらの定義は事前に決定されていないため、事前決定済のプロパティ定義のリストでは考慮できません。動的プロパティが定義される前に、動的プロパティのヘッダー操作を設計することはできません。この制限に対応するには、必要なすべてのサービス(コンポジット・エントリ・ポイント)と参照を生成する必要があります。この制約は、動的プロパティを生成することが想定されるサービスに適用されます。動的プロパティが生成された後、コンポジットごとに格納される必要があります。その後にのみ、メディエータ・エディタまたはOracle BPELデザイナで動的プロパティを操作できます。

JCAアダプタおよびOracle B2Bの正規化メッセージ・プロパティの詳細は、『テクノロジ・アダプタの理解』および『Oracle B2Bユーザーズ・ガイド』を参照してください。

E.1.1 Oracle Web Services Addressingのプロパティ

表E-1 に、Web Services Addressing (WS-Addressing)の正規化メッセージに対して事前に決定されているプロパティを示します。受信SOAPリクエストのWS-Addressingヘッダーは、正規化メッセージ・プロパティを使用してOracle SOA Suite内に伝播されます。ただし、アウトバウンドSOAPメッセージでは、これらの正規化メッセージ・プロパティを使用したWS-Addressingヘッダーのオーバーライドはサポートされていません。

表E-1 Oracle Web Services Addressingのプロパティ

プロパティ名

伝播可能(はい/いいえ)

方向(インバウンド/アウトバウンド)

データ型

有効な値の範囲

説明

wsa.messageId

いいえ

インバウンド

文字列

URI形式

このプロパティは、メッセージの識別子と、そのメッセージに対する応答の送信先であるエンドポイントをエンドポイント参照として指定します。

wsa.relatesTo

いいえ

インバウンド

文字列

URI形式

このオプションの(繰返し)要素情報アイテムは、1つの抽象リレーションシップ・プロパティ値を(IRI, IRI)ペアの形式で提供します。この要素のコンテンツ(xs:anyURIタイプ)は、関連メッセージのメッセージIDを伝達します。

wsa.replyToAddress

いいえ

インバウンド

文字列

URI形式

非同期で通信する2つのコンポーネント間の規約を表します。

wsa.replyToPortType

いいえ

インバウンド

QName

任意のQName

この値は、サービスのコールバックのportTypeを構成するためにWebサービスに渡されます。WS-Addressingコールバックのエンドポイント参照のPortType要素に変換されます。

wsa.replyToService

いいえ

インバウンド

QName

任意のQName

この値は、サービスのコールバックのサービスを構成するためにWebサービスに渡されます。WS-Addressingコールバックのエンドポイント参照のServiceName要素に変換されます。

wsa.action

いいえ

インバウンド

文字列

URI形式

この必須要素(コンテンツがxs:anyURIタイプ)は、アクション・プロパティの値を伝達します。

wsa.to

いいえ

インバウンド

文字列

URI形式

このオプション要素(コンテンツがxs:anyURIタイプ)は、宛先プロパティの値を提供します。この要素が指定されない場合、宛先プロパティの値はhttp://www.w3.org/2005/08/addressing/anonymousになります。

E.1.2 メッセージ・ヘッダー内で正規化メッセージ・プロパティを設定する方法

メッセージ・ヘッダー内で正規化メッセージ・プロパティを設定する手順は、次のとおりです。

1. 選択したアクティビティのダイアログ内で、「プロパティ」タブをクリックします。

2. BPEL 2.0プロジェクトの場合は、次の作業を実行します。

a. 「追加」アイコンをクリックします。

b. 「名前」リストから、プロパティを選択します。図E-1 に詳細を示します。

図E-1 正規化されたメッセージ・ヘッダー・プロパティの「プロパティ」タブ

c. プロパティの値を選択します。

選択

実行する手順

式

i. 「検索」をクリックして「XPath式ビルダー」ダイアログを起動します。

ii. XPath式を作成して、「OK」をクリックします。

iii. 「OK」をクリックします。

変数

i. 「検索」をクリックして「変数XPathビルダー」ダイアログを起動します。

ii. 変数を選択して、「OK」をクリックします。

iii. 「OK」をクリックします。

定義されたプロパティが表示されます。

3. BPEL 1.1プロジェクトの場合は、次の作業を実行します。

a. 下にスクロールしてプロパティを選択します。

b. 「値」列で、ダブルクリックして省略記号を表示します。

c. 省略記号をクリックします。
「アダプタ・プロパティ値」ダイアログが表示されます。

d. 値として変数名を入力し、「OK」をクリックします。

e. 「タイプ」列があるアクティビティ(たとえば、invokeアクティビティ)の場合は、プロパティの行をクリックします。

f. 表示されるリストから、メッセージの方向として「入力」または「出力」を選択します。

g. 「適用」をクリックし、「OK」をクリックします。

E.2 bpelx拡張による正規化されたメッセージのプロパティの操作

Oracle BPEL Process Managerはbpelx拡張を使用して、メッセージ交換処理で、正規化されたメッセージのプロパティを操作します。構文は、BPELプロジェクトでBPELバージョン1.1と2.0のどちらがサポートされているかによって異なります。

E.2.1 BPEL 2.0のbpelx拡張構文

次の例は、BPEL 2.0におけるbpelx拡張構文を示しています。

<invoke ...>
<bpelx:fromProperties>?
<bpelx:fromProperty name="NCName" .../>+
</bpelx:fromProperties>
<bpelx:toProperties>?
<bpelx:toProperty name="NCName" .../>+
</bpelx:toProperties>
</invoke>

<receive ...>
<bpelx:fromProperties>?
<bpelx:fromProperty name="NCName" .../>+
</bpelx:toProperties>
</receive>

<onEvent ...>
<bpelx:fromProperties>?
<bpelx:fromProperty name="NCName" .../>+
</bpelx:fromProperties>
</onEvent>

<reply...>
<bpelx:toProperties>?
<bpelx:toProperty name="NCName" .../>+
</bpelx:toProperties>
</reply>

<reply ...>
<bpelx:toProperties>
<bpelx:toProperty name="NCName" .../>
</bpelx:toProperties>
</reply>

次の詳細に注意してください。

- toPropertyはfrom-specです。from-specから、指定した名前のプロパティに値をコピーします。

- fromPropertyはto-specです。プロパティからto-specに値をコピーします。

E.2.2 BPEL 1.1のbpelx拡張構文

次の例は、BPEL 1.1におけるbpelx拡張構文を示しています。

<invoke ...>
<bpelx:inputProperty name="NCName" expression="string" variable="NCName"
part="NCName" query="string"/>*
<bpelx:outputProperty name="NCName" expression="string" variable="NCName"
part="NCName" query="string"/>*
</invoke>

<receive ...>
<bpelx:property name="NCName" expression="string" variable="NCName"
part="NCName" query="string"/>*
</receive>

<onMessage...>
<bpelx:property name="NCName" expression="string" variable="NCName"
part="NCName" query="string"/>*
</onMessage>

<reply ...>
<bpelx:property name="NCName" expression="string" variable="NCName"
part="NCName" query="string"/>*
</reply>

F ルール・ディクショナリ・エディタのタスク・フローによって実装されるインタフェース

この付録では、ADFベースのWebアプリケーションを作成する際にMetadataDetailsおよびNLSPrefrencesのインタフェースを実装する、Oracle Business Rulesディクショナリ・エディタのタスク・フローについて説明します。これらのインタフェースはsoaComposerTemplates.jarファイルで定義されます。

この付録の内容は次のとおりです。

- MetadataDetailsインタフェース

- NLSPreferencesインタフェース

F.1 MetadataDetailsインタフェース

MetadataDetailsインタフェースはoracle.integration.console.metadata.model.shareパッケージの一部であり、soaComposerTemplates.jarファイルで定義されます。

次に示すように、MetadataDetailsインタフェースは3つのメソッドを定義します。

public interface MetadataDetails {
/**
* Retrieve the details of the metadata document
* @return document in string format.
*/
String getDocument();

/**
* Get related document.
*/
String getRelatedDocument(final RelatedMetadataPath relatedPath);

/**
* Update the metadata document.
* @param doc represents the updated document.
*/
void setDocument(String doc) throws Exception;
}

F.1.1 getDocumentメソッド

このメソッドは、ルール・ファイルを文字列書式で取得するために使用します。このアクションを実行するには、Oracle Metadata Repository (MDS)またはファイル・システムに接続して、ルール・ファイルを文字列書式で返す必要があります。

次のコード・サンプルに、ローカル・ファイル・システムからファイルを取得する方法を示します。

private static final String RULES_FILE1 =
"file:///C:/scratch/<username>/system/mywork/linkedD/AutoAppProj/oracle/rules/credit/CreditRatingRules.rules";

public String getDocument() {
URL url = null;
try {
url = new URL(RULES_FILE1);
return readFile(url);
} catch (IOException e) {
System.err.println(e);
}
return "";
}

private String readFile(URL dictURL) {
InputStream is;
try {
is = dictURL.openStream();
} catch (IOException e) {
System.err.println(e);
return "";
}
BufferedReader reader;
try {
reader = new BufferedReader(new InputStreamReader(is, "UTF-8"));
} catch (UnsupportedEncodingException e) {
System.err.println(e);
return "";
}
String line = null;
StringBuilder stringBuilder = new StringBuilder();
String ls = System.getProperty("line.separator");
try {
while ((line = reader.readLine()) != null) {
stringBuilder.append(line);
stringBuilder.append(ls);
}
} catch (IOException e) {
System.err.println(e);
return "";
} finally {
try {
reader.close();
} catch (IOException e) {
System.err.println(e);
}
}
return stringBuilder.toString();
}

F.1.2 getRelatedDocumentメソッド

リンク・ディクショナリを使用する場合、このメソッドは必須です。MDSに接続して関連するディクショナリ・ファイルを検出し、そのファイルを文字列書式で返す必要があります。次のコード・サンプルに、ローカル・ファイル・システムの../oracle/rulesディレクトリ内に格納されているリンク・ディクショナリへのパスを検出する方法を示します。

public String getRelatedDocument(RelatedMetadataPath relatedMetadataPath) {
String currPath = RULES_FILE1.substring(0, RULES_FILE1.indexOf("oracle/rules"));
String relatedDoc = currPath + "oracle/rules/" + relatedMetadataPath.getValue();

URL url = null;
try {
url = new URL(relatedDoc);
return readFile(url);
} catch (IOException e) {
System.err.println(e);
}
return "";
}

F.1.3 setDocumentメソッド

このメソッドは、ルール・ファイルを格納するために使用します。このメソッドは、文字列のdoc値を返します。この値は、ルール・ディクショナリ・エディタのタスク・フローを使用して実行されたユーザーの編集を基に更新されたディクショナリの名前です。ルール・ファイルはMDSまたはファイル・システムに格納する必要があります。次のコード・サンプルに、ローカル・ファイル・システムにドキュメントを保存する方法を示します。

public void setDocument(String string) {
URL url = null;

try {
url = new URL(RULES_FILE1);
} catch (MalformedURLException e) {
System.err.println(e);
return;
}
Writer writer = null;
try {
//os = new FileWriter(url.getPath());
writer =
new OutputStreamWriter(new FileOutputStream(url.getPath()),
"UTF-8");
} catch (FileNotFoundException e) {
System.err.println(e);
return;
} catch (IOException e) {
System.err.println(e);
return;
}
try {
writer.write(string);
} catch (IOException e) {
System.err.println(e);
} finally {
if (writer != null) {
try {
writer.close();
} catch (IOException ioe) {
System.err.println(ioe);
}
}
}
}

F.2 NLSPreferencesインタフェース

次に示すように、NLSPrefrencesインタフェースは4つのメソッドを定義します。

public interface NLSPreferences
{
/**
* Returns the locale to be used.
**/
Locale getLocale();

/**
* Return the timezone to be used.
**/
TimeZone getTimeZone();

/**
* Return the dateformat to be used.
*/
String getDateFormat();

/**
* Return the time format to be used.
*/
String getTimeFormat();

/**
* Returns the grouping seperator.
*/
char getGroupingSeparator();

/**
* Returns the grouping seperator.
*/
char getDecimalSeparator();
}

次のコード・サンプルに、NLSPreferencesインタフェースのサンプル実装を示します。

public class MyNLSPreferences implements NLSPreferences {
private static final String DATE_STYLE = "yyyy-MM-dd";
private static final String TIME_STYLE = "HH-mm-ss";
private static final char G_SEP = ',';
private static final char D_SEP = '.';

public Locale getLocale() {
return Locale.FRENCH;
}

public TimeZone getTimeZone() {
return TimeZone.getTimeZone("America/Los_Angeles");
}

public String getDateFormat() {
return DATE_STYLE;
}

public String getTimeFormat() {
return TIME_STYLE;
}

public char getGroupingSeparator() {
return G_SEP;
}

public char getDecimalSeparator() {
return D_SEP;
}
}

G Oracle SOA Suite構成プロパティのロード・マップ

この付録では、Oracle SOA Suiteの設計時および実行時の構成プロパティを設定する場所を説明し、これらのプロパティの構成方法が説明されているドキュメントを参照先として示します。

この付録の内容は次のとおりです。

- デプロイメント・ディスクリプタのプロパティ

- 正規化されたメッセージ・ヘッダー・プロパティ

- SOAコンポジット・アプリケーションのプロパティ

- フォルト・ポリシーとアダプタ拒否メッセージのプロパティ

- Oracle B2Bのシステム・プロパティ

- Oracle Healthcareのプロパティ

- Oracle Business Activity Monitoringのプロパティ

- プロパティ・ページ

- システムMBeanブラウザの拡張プロパティ

G.1 Oracle BPEL Process Managerデプロイメント・ディスクリプタのプロパティ

デプロイメント・ディスクリプタは、Oracle WebLogic ServerまたはOracle Enterprise Manager Fusion Middleware Control、あるいはその両方によって実行時に使用されるBPELプロセス・サービス・コンポーネントのプロパティです。これらのプロパティは、設計時にSOAコンポジット・アプリケーションのcomposite.xmlファイルで設定します。デプロイメント・ディスクリプタ・プロパティの例には、completionPersistPolicy、inMemoryOptimization、oneWayDeliveryPolicy、transaction、nonBlockingInvokeなどがあります。

使用可能なデプロイメント・ディスクリプタのプロパティの詳細は、「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」および「BPELプロセスでのトランザクションおよびフォルト伝播のセマンティクス」を参照してください。

G.2 正規化されたメッセージ・ヘッダー・プロパティ

ヘッダーの操作および伝播は、重要なビジネス統合メッセージング要件です。正規化されたメッセージ・ヘッダー・プロパティは、設計時に、receiveアクティビティ、invokeアクティビティ、pickアクティビティおよび(BPEL 1.1の場合)scopeアクティビティのonMessageブランチ、およびreplyアクティビティの「プロパティ」タブで設定できます。次のコンポーネントのプロパティを設定できます。

- Oracle JCAアダプタ

- Oracle BPEL Process Manager

- Oracle Web Services Addressing

- Oracle B2B

- RESTアダプタ

詳細は、「メッセージ・ヘッダーを介した正規化メッセージ・プロパティの伝播」を参照してください。

G.2.1 Oracle JCAアダプタのメッセージ・ヘッダー・プロパティ

Oracle JCAアダプタは基礎となるバック・エンド操作固有のプロパティをヘッダー要素として公開するため、これらの要素をビジネス・プロセス内で操作できます。

使用可能なOracle JCAアダプタのメッセージ・ヘッダー・プロパティの詳細は、次のガイドを参照してください。

- JCAアダプタのプロパティについては、『テクノロジ・アダプタの理解』の付録A「Oracle JCAアダプタのプロパティ」

- Oracle Applicationsアダプタのプロパティについては、『Oracle E-Business Suite Adapterユーザーズ・ガイド』

G.2.2 Oracle BPEL Process ManagerおよびOracle Web Services Addressingのメッセージ・ヘッダー・プロパティ

Oracle BPEL Process ManagerおよびOracle Web Services Addressingは、顧客の統合ニーズを解決する上でヘッダー・サポートに大きく依存しています。

使用可能なOracle BPEL Process ManagerおよびOracle Web Services Addressingのメッセージ・ヘッダー・プロパティの詳細は、「メッセージ・ヘッダーを介した正規化メッセージ・プロパティの伝播」を参照してください。

G.2.3 Oracle B2Bのメッセージ・ヘッダー・プロパティ

Oracle B2Bでは、予約済キーワードを使用してヘッダーを操作できます。

使用可能なOracle B2Bメッセージ・ヘッダーのプロパティの詳細は、『Oracle B2Bユーザーズ・ガイド』の付録「バックエンド・アプリケーション・インタフェース」を参照してください。

G.3 SOAコンポジット・アプリケーションのプロパティ

composite.xmlファイルに対するほとんどの更新は、設計時にSOAコンポジット・エディタのダイアログ内から実行されますが、一部のプロパティは、「ソース」ビュー内からこのファイルに手動で追加する必要があります。表G-1 では、これらのプロパティをリストし、これらのプロパティの構成方法が説明されているドキュメントを参照先として示します。

表G-1 Oracle SOA Suiteのプロパティ

プロパティ

説明

参照先

endpointURI

パートナ・リンクの複数のエンドポイント・ロケーションを指定します。この機能は、最初のエンドポイントが停止した場合に、フェイルオーバーするのに便利です。

複数のランタイム・エンドポイント・ロケーション

oracle.composite.faultPolicyFile

フォルト・ポリシー・ファイルの場所を指定します(デフォルトの場所と異なる場合)。このオプションは、1つのフォルト・ポリシーを複数のSOAコンポジット・アプリケーションで使用する必要がある場合に便利です。

フォルト管理フレームワークによるフォルト処理

oracle.composite.faultBindingFile

フォルト・バインディング・ファイルの場所を指定します(デフォルトの場所と異なる場合)。このオプションは、1つのフォルト・ポリシーを複数のSOAコンポジット・アプリケーションで使用する必要がある場合に便利です。

フォルト管理フレームワークによるフォルト処理

passThroughHeader

デフォルトでは、SOAPヘッダーはOracle Mediatorを介して渡されません。SOAPヘッダーを渡すには、このプロパティを対応するOracle Mediatorルーティング・サービスに追加します。

値の割当て方法

フィルタおよび割当てのためのヘッダー・アクセス方法

rolesAllowed

Java EEアプリケーションからSOAコンポジット・アプリケーションを起動するために必要なロール名を指定します。

Enterprise JavaBeansロールの指定

streamIncomingAttachments

および

streamOutgoingAttachments

これらのプロパティは、SOAPでアタッチメントをストリームするために指定します。

添付ファイル付きSOAP

oracle.webservices.local.optimization

ポリシーのローカル最適化設定をオーバーライドする場合に指定します。

添付ファイル付きSOAP

および

Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

oracle.soa.local.optimization.force

oracle.webservices.local.optimizationプロパティをオーバーライドし、最適化を強制できます。

Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

one.way.returns.fault

一方向インタフェースのSOAPコールについて、フォルトおよび一方向メッセージの処理方法を制御します。

一方向メッセージ交換パターン

mtomThreshold

添付ファイルのサイズをバイト単位で指定します。

SOAコンポジット・アプリケーションとのMTOM最適化メッセージの送受信

G.4 フォルト・ポリシーとアダプタ拒否メッセージのプロパティ

フォルト・ポリシー・ファイルには、フォルト条件および対応するフォルト・リカバリ・アクションを定義します。それぞれのフォルト条件で、処理を試みる特定のフォルトまたは一連のフォルトを指定し、それに対応するアクションを指定します。

フォルト・ポリシーのプロパティは、フォルト・ポリシー・エディタを使用して自動的に入力することも、フォルト・ポリシー・フレームワーク・ファイルに手動で入力することもできます。表G-2 では、これらのプロパティをリストし、これらのプロパティの構成方法が説明されているドキュメントを参照先として示します。

表G-2 Oracle SOA Suiteのフォルト・ポリシーのプロパティ

プロパティ

説明

参照先

retryInterval

アクティビティの再試行から次の再試行までの遅延(秒単位)を指定します。

自動フォルト・リカバリに対するフォルト・ポリシー・ファイルの手動作成

retryCount

アクティビティを指定された回数だけ再試行します。

「自動フォルト・リカバリのフォルト・ポリシーをフォルト・ポリシー・ウィザードで設計する方法」または「自動フォルト・リカバリに対するフォルト・ポリシー・ファイルの手動作成」

org.quartz.scheduler.idleWaitTime

スケジューラが再試行前に待機する時間(秒単位)を指定します。

「自動フォルト・リカバリのフォルト・ポリシーをフォルト・ポリシー・ウィザードで設計する方法」または「アクション」

設計時に、フォルト・ポリシーのフレームワーク・ファイルにアダプタ拒否メッセージのプロパティを入力することもできます。

詳細は、『テクノロジ・アダプタの理解』のエラー処理に関する項を参照してください。

G.5 Oracle B2Bのシステム・プロパティ

Oracle B2Bのほとんどのプロパティは、Oracle B2Bインタフェースの「構成」タブで設定できます。これらの設定は、Oracle Enterprise Manager Fusion Middleware Controlで実行されたプロパティ設定よりも優先されます。

使用可能なOracle B2Bのプロパティの詳細は、『Oracle B2Bユーザーズ・ガイド』の「B2Bシステム・パラメータの構成」を参照してください。

G.6 Oracle Healthcareのプロパティ

Oracle Healthcareのランタイムおよびユーザー・インタフェース、ワークフロー通知、および正規化メッセージ・ヘッダーのプロパティを構成できます。

使用可能なOracle Healthcareのプロパティの詳細は、『Oracle SOA Suite Healthcare Integrationユーザーズ・ガイド』を参照してください。

G.7 Oracle Business Activity Monitoringのプロパティ

Oracle Business Activity Monitoring (BAM)ビジネス・ビューのプロパティを構成できます。

Oracle BAMのプロパティの詳細は、『Oracle BAMでのビジネス・アクティビティのモニタリング』を参照してください。

G.8 Oracle Enterprise Manager Fusion Middleware Controlのプロパティ・ページ

次のコンポーネントのプロパティは、実行時にOracle Enterprise Manager Fusion Middleware Controlのプロパティ・ページで構成できます。

- SOAインフラストラクチャ

- Oracle BPEL Process Manager

- ヒューマン・ワークフロー通知とタスク・サービス

- Oracle Mediator

- 相互参照

- Oracle B2B

- サービス・バインディング・コンポーネントと参照バインディング・コンポーネント(JCAアダプタ、Webサービス、RESTアダプタおよびOracle Service Registry)

- グローバル・トークン変数と自動データベース・パージ

G.8.1 SOAインフラストラクチャのプロパティ

「SOAインフラストラクチャの共通プロパティ」ページで、SOAインフラストラクチャのプロパティを構成できます。これらのプロパティ設定は、SOAインフラストラクチャで実行されているすべてのSOAコンポジット・アプリケーションに適用できます。次のタイプのプロパティを設定できます。

- 監査レベル

- ペイロードの検証

- インスタンスとフォルトのデータを取得する継続期間

- Universal Description, Discovery, and Integration (UDDI)レジストリ

- コールバック・サーバーとサーバーURL

- BPM分析、BPELセンサーおよびコンポジット・センサー

- Java Naming and Directory Interface (JNDI)データソース

- Webサービス・バインディング・プロパティ

- 拡張構成プロパティ

使用可能なSOAインフラストラクチャのプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「SOAインフラストラクチャの構成」を参照してください。

G.8.2 Oracle BPEL Process Managerのプロパティ

「BPELサービス・エンジン・プロパティ」ページで、BPELプロセス・サービス・エンジンのプロパティを構成できます。これらのプロパティは、BPELサービス・コンポーネントの処理時にBPELプロセス・サービス・エンジンによって使用されます。次のタイプのプロパティを設定できます。

- 監査証跡レベル

- 監査証跡と大規模ドキュメントのしきい値

- ペイロード・スキーマ検証

- BPELモニターおよびセンサーの有効化

- 拡張構成プロパティ

使用可能なOracle BPEL Process Managerのプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「BPELプロセス・サービス・コンポーネントおよびエンジンの構成」を参照してください。

G.8.3 ヒューマン・ワークフロー通知とタスク・サービスのプロパティ

「ワークフロー通知プロパティ」ページの「メーラー」タブと「タスク」タブで、ヒューマン・ワークフロー通知とタスク・サービスのプロパティを構成できます。これらのプロパティは、ヒューマン・ワークフロー・サービス・コンポーネントの処理時にヒューマン・ワークフロー・サービス・エンジンによって使用されます。次のタイプのプロパティを設定できます。

- メッセージの通知モード

- アクション可能なアドレス

- アクション可能な電子メールのアカウント名

- ワークフロー・セッションのタイムアウトとカスタム・クラス・パスのURL値

- 割当てサービスの動的割当てとタスク・エスカレーション関数

- 拡張構成プロパティ

使用可能なヒューマン・ワークフロー通知とタスク・サービスのプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「ヒューマン・ワークフローのサービス・コンポーネントとエンジンの構成」を参照してください。

G.8.4 Oracle Mediatorのプロパティ

Oracle Mediatorのプロパティを構成できます。これらのプロパティは、Oracle Mediatorサービス・コンポーネントの処理時にOracle Mediatorサービス・エンジンによって使用されます。次のタイプのプロパティを設定できます。

- 監査レベルとメトリック・レベル

- パラレルが取得する最大行数

- パラレル・ロッカー・スレッド・スリープ

- カスタム構成パラメータ

- コンテナIDリフレッシュ時間とコンテナIDリース・タイムアウト

- 再シーケンサ・ロッカー・スレッド・スリープとロックする最大グループ数

- 拡張構成プロパティ

使用可能なOracle Mediatorのプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「Oracle Mediatorのサービス・コンポーネントとエンジンの構成」を参照してください。

G.8.5 相互参照プロパティ

相互参照を構成すると、別のアプリケーションで作成された同等のエンティティの値を動的にマップできます。

使用可能な相互参照プロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「相互参照の管理」を参照してください。

G.8.6 Oracle B2Bのプロパティ

Oracle B2Bダイナミック・モニタリング・サービス(DMS)メトリックを有効にして、拡張プロパティを構成できます。

使用可能なOracle B2Bのプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「Oracle B2Bの構成」を参照してください。

G.8.7 サービス・バインディング・コンポーネントと参照バインディング・コンポーネントのプロパティ

次のサービス・バインディング・コンポーネントと参照バインディング・コンポーネントのプロパティを構成できます。

- JCAアダプタのアクティブ化仕様(サービス用)、相互作用仕様(参照用)およびエンドポイント・プロパティ(タイムアウト、しきい値、最大間隔など)。

- Webサービスのプロパティ(RESTの有効化など)。WSDL、メタデータ交換、Webサービスのエンドポイントなどを有効化します。

使用可能なサービスおよび参照バインディング・コンポーネントのプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「サービスおよび参照バインディング・コンポーネントの構成」を参照してください。

G.8.8 グローバル・トークン変数と自動データベース・パージのプロパティ

Oracle Enterprise Manager Fusion Middleware Control内で、次のように追加プロパティを構成できます。

- SOAコンポジット・アプリケーションの特定のURIに対してグローバル・トークン変数を定義する。

- 多数のインスタンスをデータベースから自動的にパージする処理を有効にする。

トークン構成の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の複数のSOAコンポジット・アプリケーションのグローバル・トークン変数の管理に関する項を参照してください。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle Enterprise Manager Fusion Middleware Controlによる大量のインスタンスの削除に関する項を参照してください。

G.9 システムMBeanブラウザの拡張プロパティ

Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザでは、「プロパティ・ページ」で説明されているプロパティ・ページには表示されない拡張プロパティを変更できます。これらの拡張プロパティは、次のコンポーネントのプロパティ・ページの下部にあるリンクの下に表示されます。

- SOAインフラストラクチャ

- Oracle BPEL Process Manager

- Oracle Mediator

- ヒューマン・ワークフロー通知とタスク・サービス

- Oracle B2B

注意:

システムMBeanブラウザには、拡張プロパティに加えて、「プロパティ・ページ」で説明されているプロパティ・ページに表示されるプロパティと同じプロパティが表示され、これらのプロパティを変更できます。

G.9.1 SOAインフラストラクチャの拡張プロパティ

「SOAインフラストラクチャの共通プロパティ」ページの下部にある「詳細SOAインフラ拡張構成プロパティ」リンクを使用すると、SOAインフラストラクチャのシステムMBeanブラウザの拡張プロパティを表示できます。表示される変更可能なプロパティの一部を次に示します。

- 起動例外で再試行可能な最大回数

- 起動例外の再試行から次の再試行までの秒数

- HTTPプロキシ認証レルム

- HTTPプロキシ認証タイプ

- HTTPプロキシ・ホスト

- 認証が必要なHTTPプロキシのパスワード

- HTTPプロキシのポート番号

- 認証が必要なHTTPプロキシのユーザー名

- WSDLファイルでプロセスのSOAPアドレスの一部として公開されるHTTPプロトコルURL

- WSDLファイルでプロセスのSOAPアドレスの一部として公開されるHTTPSプロトコルURL

- Oracle SOA Suiteキーストアへのパス

使用可能なSOAインフラストラクチャ・システムMBeanブラウザのプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「SOAインフラストラクチャの構成」を参照してください。

G.9.2 Oracle BPEL Process Managerの拡張プロパティ

「BPELサービス・エンジン・プロパティ」ページの下部にある「詳細BPEL構成プロパティ」リンクを使用すると、BPELプロセスのシステムMBeanブラウザのプロパティを表示できます。表示される変更可能なプロパティの一部を次に示します。

- BPEL生成Javaソースをコンパイルする際に含める追加のBPELクラスパス

- 失敗した期限切れコール(wait/onAlarm)が失敗する前に再試行される最大回数

- 期限切れ再試行から次の期限切れ再試行までの遅延

- 各フェッチ時にデハイドレーション・ストアから割り当てられるインスタンスIDのブロック・サイズ

- インメモリー・キャッシュに格納される起動メッセージ数

- 一方向起動メッセージを配信するかどうか

使用可能なOracle BPEL Process ManagerシステムMBeanブラウザのプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「BPELプロセス・サービス・コンポーネントおよびエンジンの構成」を参照してください。

G.9.3 Oracle Mediatorの拡張プロパティ

「メディエータ・サービス・エンジン・プロパティ」ページの下部にある「詳細メディエータ構成プロパティ」リンクを使用すると、Oracle MediatorのシステムMBeanブラウザのプロパティを表示できます。Oracle Mediatorに表示されるシステムMBeanブラウザのほとんどのプロパティは、「メディエータ・サービス・エンジン・プロパティ」ページでも変更できます。

使用可能なOracle MediatorシステムMBeanブラウザのプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「Oracle Mediatorのサービス・コンポーネントとエンジンの構成」を参照してください。

G.9.4 ヒューマン・ワークフロー通知とタスク・サービスの拡張プロパティ

「ワークフロー通知プロパティ」ページの下部にある「詳細ワークフロー通知構成プロパティ」リンク、および「ワークフロー・タスク・サービス・プロパティ」ページの下部にある「詳細ワークフロー・タスクサービス構成プロパティ」リンクを使用すると、ヒューマン・ワークフローのシステムMBeanブラウザのプロパティを表示できます。表示される変更可能なプロパティの一部を次に示します。

- 受信インスタント・メッセージ(IM)を受信するアドレス

- カスタム通知サービスのプロパティ名を返すかどうか

使用可能なヒューマン・ワークフロー通知とタスク・サービス・システムMBeanブラウザのプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「ヒューマン・ワークフローのサービス・コンポーネントとエンジンの構成」を参照してください。

G.9.5 Oracle B2Bの拡張プロパティ

「B2Bサーバー・プロパティ」ページの下部にある「詳細B2B構成プロパティ」リンクを使用すると、Oracle B2BのシステムMBeanブラウザのプロパティを表示できます。変更対象として表示されるプロパティには、Oracle B2Bペイロードの不明瞭化などがあります。

使用可能なOracle B2Bのプロパティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「Oracle B2Bの構成」を参照してください。

H XSLTエディタでの大規模なスキーマの操作

XSLTエディタには、編集中のXSLTマップの入力ドキュメントおよび出力ドキュメントをXML表現で示したソース・ツリーおよびターゲット・ツリーが表示されます。ルート要素定義を選択すると、エディタによってXSDスキーマ・ドキュメントからこれらのツリーが作成されます。
これらのスキーマ・ツリーは大規模になり、XSLTエディタなどのグラフィカルなマッピング・ツールでの操作が難しくなることがあります。スキーマ・ドキュメントの中には、親ノードごとに数百の子ノードを定義しているものもあります。このような親ノードのいくつかをツリーで展開した場合、XSLTマップを作成する際スクロール・スルーすることになるツリー・ノードが数千個生成される可能性があります。

スキーマは非常に大きくても、マッピングがスパースな場合、つまりマッピングされているターゲット・ノードが非常に少ない場合、ユーザーはマッピングする必要のないノードを絶えずスクロール・スルーする必要があります。これに対し、マッピングがスパースでなく、多数のマッピングが存在する場合、多数の線が交差し、マッピングがわかりにくくなります。

この付録では、スパースなマップとスパースでないマップの両方に対するストラテジおよび見にくさを低減する方法について説明します。

H.1 スパース・マッピング

スキーマは多くの場合、多様な可能性に対応するよう作成されます。このようなスキーマがソースおよびターゲットのツリーの生成に使用されると、ツリーに非常に多くの(場合によっては数百万の)ノードが含まれる可能性があります。ただし、多くの場合、ユーザーが使用または移入する必要があるのは、スキーマに定義されているノードのうちごく一部のみです。

スパース・マッピングの処理には様々な方法があります。

サンプルXMLを使用したスキーマの生成

12c XSLTエディタにはXMLドキュメントからスキーマを作成する機能があり、これをソースまたはターゲットのツリーのスキーマ・ドキュメントとして使用できます。ソースまたはターゲット(あるいはその両方)用にサンプルXMLドキュメントがある場合、このドキュメントを使用してマップに必要なノードのみを含む小さなスキーマ・ドキュメントを作成できます。

サンプル・ソースおよびターゲットXMLドキュメントを使用してXSLTマップを作成するには、新規XSLマップのソースまたはターゲットのスキーマを選択する際、「XMLから生成」オプションを選択します。

スキーマが生成され、Schemasフォルダに配置されます。このスキーマを使用してマッピングのソースおよびターゲットのツリーを作成すると、元のサンプルXMLドキュメントに存在するノードのみが含まれます。

小さなサンプル・スキーマと大規模なスキーマの間で切り替える必要がある場合、キャンバスのコンテキスト・メニューから「ソースまたはターゲット・スキーマの置換/追加」を選択します。Schemasフォルダの小さなサンプル・スキーマまたは大規模なスキーマを選択します。

XSLTビューの使用

12cのエディタには、設計ビュー・タブ内で使用可能な新規ビューが含まれています。これが、XSLTビューです。XSLTエディタ・ツールバーの右上の「XSLT」ボタンをクリックして使用します。

XSLTビューには、XSLTファイル内に存在する文が表示されます。以前にソースXMLエディタでXSLTを編集したことのあるユーザーには、このビューの良さがわかるでしょう。XSLTソースでの文の出現と同じように編成されています。このビューを使用すると、作成中のマッピングの簡約版が表示されます。たとえば、大規模ターゲット・スキーマのマップのマップ・ビューでの表示を次に示します。スキーマでツリーの後半に出現するノードへのマップの線が表示の下端で切れていることに注意してください。

同じマッピングのXSLTビューでの表示を次に示します。

この場合、使用されていないターゲット・ノードがスペースを取ることがなく、すべてのマッピングが明確にわかります。新規ターゲット要素をスキーマから追加する必要がある場合、コンテキスト・メニューで「スキーマからの子の追加」オプションを使用します。

親ノードのコンテキスト・メニューから「スキーマからの子の追加」オプションを選択すると、選択および追加可能な子ノードのリストが表示されます。親ノードのこのメニューから「すべての属性」/「すべての要素」/「すべての必須」を選択することもできます。

さらに付け加えると、ノードがこのようにして追加された場合、挿入したノードのすべての必要な子が自動的に追加されます。前述の例では、ns2:records要素を追加するよう選択した場合、ツリー内の正しい位置に挿入され、これに必要なns1:idノードが自動的に追加されます。

ソース・ビューでの編集に慣れている場合、ソース・ビューと設計ビューの間を簡単に移動できるオプションが12.2.1.0.0で追加されました。XSLTパネルで任意のノードを右クリックし、「ソース・ビュー内の検索」を選択します。

ソース・ビューが開き、ノードが選択されています。

設計ビューのノードに戻るには、ソース・ビューで「設計ビュー内の検索」オプションを選択します。

XSLTビューを使用して任意のXSLT文を挿入することもでき、XSLTビューで名前付きテンプレートおよび一致するテンプレート(テンプレート・ルール)を使用できます。XSLTビューの詳細は、「XSLTビューでのXSLTマップの編集」を参照してください。

H.1.1 XSLTビューのクイック・スタート

プリファレンスを設定してXSLTエディタを常にXSLTビューで起動できます。この設定では、開始するためのターゲット・ノードの自動作成も制御されます。XSLTビュー用のプリファレンスを設定するには、「ツール」→「プリファレンス」を選択して「プリファレンス」ダイアログを起動します。「XSLマップ」→「XSLエディタ」を選択します。

XSLTビューで起動するには、XSLTビュー初期化オプションを選択し、希望のオプションを選択します。大規模なスキーマの操作の場合、生成する子のレベル数の限度を設定することをお薦めします。

XSLTマップを作成する際、これらのオプションが使用されます。また、これらのオプションは、キャンバスのコンテキスト・メニューから「XSLTマップのクリア」オプションを選択した場合に使用されます。

特定のマップについてプリファレンス設定が適していない場合、プリファレンスに変更を加え、「XSLTマップのクリア」を選択して初期マップを再生成します。

H.2 非スパース・マッピング

時として、大量のターゲット要素を含む、つまり大量のマッピングを含むマップを作成したり、変更する必要がある場合があります。このようなマップを編集する場合、編集内容を追跡することが困難なことがあります。そのような場合のために12c XSLTエディタには、ユーザーがマッピングのスコープを設定し、選択したターゲット・ノードより下のマッピングのみを表示できる新しい機能があります。

たとえば、次のような非スパース・マッピングがあるとします。

ターゲット・ツリー内の操作対象部分にマッピングのスコープを設定できます。ターゲット・ノードを右クリックして、「表示スコープの設定」を選択します。

表示は、選択したターゲット・ノードにスコープが設定されています。この部分以外のマッピングを示す線はすべて描かれません。ソース・ツリーは簡約化されてマップされているノードのみ表示されます。

スコープ内の部分で作業を続けることができます。

ソース・ツリー内の非表示の部分を展開して、追加のマッピングに必要なノードを表示できます。ソース・ツリーで任意の非表示のアイテムを右クリックし、ツリー内の検索および表示するノードの選択のためのオプションを含むポップアップ・メニューを表示します。

このポップアップから行う検索は、現在選択している非表示の部分以外にも及ぶため、検索するノードを含む正しい非表示部分を選択する必要はありません。

メイン・コンテキスト・メニューには、ソース・ツリーの一部を非表示にしたり、展開するオプションもあります。ツリー内の非表示でないノードを右クリックすると、選択したノードの兄弟および子を表示したり、非表示にするオプションがあります。

ターゲット・ツリーで、「スキーマからの子の追加」オプションを使用してスキーマからノードを追加できます。

スコープ付きの表示を終了するには、スコープ外のターゲット・ノードをクリックするか、ターゲット・ツリーのコンテキスト・メニューから「表示スコープの終了」を選択します。

H.3 テキストの見にくさの低減

12cのXSLTエディタには、ソースおよびターゲット・ツリーでノード名および他の情報を略記する機能があります。キャンバスのコンテキスト・メニューから「テキスト短縮」オプションを選択すると、接頭辞が非表示になり、特定のタイプのノードのテキストが略記されます。

略記の前:

略記の後:

ノード名のテキストの略記を定義できるカスタム表示オプション構成ファイルを作成することもできます。たとえば、前述の例では、CustomerPartyListという語句が多くのノード名に出現します。カスタム表示オプション構成ファイルを使用して、これをCPLと略記できます。そうすると、$EscapedSyncCustomerPartyListEBMなどのノード名は、ツリーで$EscapedSyncCPLEBMと表示されます。

これによって、XSLTや生成されたXPath文内のノード名は変更されません。ツリー・ノードに出現する名前にのみ適用され、スキーマ・ノード定義で使用されている名前が冗長な場合の全体的な見にくさの低減に役立ちます。

カスタム表示オプション構成ファイルは、XSLエディタのプリファレンス下でロードできます。詳細は、「カスタマイズ・ファイルをインポートしてXSLTマップ・エディタの表示プリファレンスを指定する方法」を参照してください。

H.4 ツリーの検索

大規模なスキーマで要素名を検索すると、検索に時間がかかることがあります。12.1.3では、検索に取消しオプションはありません。これが12.2.1で追加されました。

検索に時間がかかる場合、プリファレンスでツリーの「展開の深さ」を減らすことで、ツリー・サイズを小さくすることができます。「ツール」→「プリファレンス」に移動します。ナビゲータから「XSLマップ」を選択します。「拡張オプションの表示」ボタンをクリックし、「XMLスキーマ最大展開の深さ」オプションの「展開の深さ」を小さな値に変更します。単一レベルに数百個の子があるツリーの場合、この値を10レベル前後にする必要があります。これは、ここで設定したレベルより下は検索されないということですが、ツリーに数百万個のノードが含まれる場合もあり、その場合は検索に時間がかかります。

H.5 大規模な入力ドキュメントのコピーと変更

ユーザーの中には、XSLTエディタの自動マップ機能を使用して入力XMLドキュメントをコピーしようとするユーザーがいるかもしれません。ただし、自動マップではスキーマ内のノードごとに特定のXSLT文が生成されます。大規模なスキーマでは、これは入力ドキュメントの効率的なコピー方法ではありません。これによって非常に大きなサイズのXSLTファイルが生成される可能性があります。これらのファイルはロードに時間がかかり、編集が困難です。さらに、ユーザーのマッピングがスパースの場合、スキーマには定義されているが、実行時には存在しないノードに対して実行するXSLTが数千行生成され、非効率です。

12cのXSLTエディタでは、一致するテンプレート(テンプレート・ルール)の作成がサポートされるようになりました。特に、ソース・ツリー内のすべてのノードをコピーできるアイデンティティ・テンプレートを追加できるようになりました。次の手順を実行します。

1. XSLTビューに切り替えます。

2. 「コンポーネント」ウィンドウから「XSLTテンプレート」を選択します。

3. アイデンティティ・テンプレートを「その他のテンプレート」セクションからxsl:stylesheetノードの左側にドラッグ・アンド・ドロップします。正しい位置にドロップすると、テンプレートがスタイルシート・ノードの子として追加されることを示す緑色のハイライトが表示されます。

4. 元のルートのmatch="/"テンプレートをXSLTから削除します。

表示は次のようになります。

入力ドキュメント内の各ノードが、アイデンティティ・テンプレートによって処理されます。これは、ソース・ツリーの各ノードのバブルがハイライト表示されることで示されます。このハイライト表示は、選択したテンプレートのコンテキスト・ノードを示すものです。各ノードが処理される際、xsl:copy文が実行され、ノードが出力にコピーされます。apply-templates文は、現在処理されているコンテキスト・ノードの子ノードを続けて処理するようプロセッサに指示します。これで入力ドキュメント全体がコピーされます。

追加テンプレートを追加し、コピーの際、ツリーに変更を加えることができます。たとえば、単に入力ツリーからノードを削除する必要があるとします。これは、出力から削除するノードに対する空のテンプレートを追加することで行うことができます。つまり、このノードを処理すると何も出力されず、実質的にはツリーからノードが削除されることになります。

ノードに対する空のテンプレートを追加するには、ソース・ノードを右クリックし、「新規テンプレート・ルール」を選択します。

表示された新規テンプレート・ダイアログで「OK」をクリックします。テンプレートが追加されます。アイデンティティ・テンプレートが選択されている場合のノードの表示との違いに注意してください。バブルはハイライト表示されておらず、アイデンティティ・テンプレートで処理されていないことを示しています。

新しい空のテンプレートを選択すると、このノードがハイライト表示され、このテンプレートがノードを処理し、処理時に何も出力しないことを示します。

ここで、別のノードのテキストを大文字にする必要もあるとします。明示的にそのノードを処理して大文字にする別のテンプレートを作成します。ソース・ツリーでBrokenPlaceノードから「新規テンプレート・ルール」オプションを選択してテンプレートを作成します。「新規テンプレート・ルール」ダイアログが表示されたら、テンプレートで作成するノードを選択します。

「OK」をクリックすると、テンプレートとノードが作成されます。大文字関数をノードに割り当てます。

このノードが出力に作成されるとき、そのテキストは大文字になります。

このようにすると、大規模な入力XMLを非常に少ないXSLT文でコピーおよび変更できます。

H.6 要素置換およびタイプ置換を使用したテスト・ファイルの生成

XSLTエディタでは、導出されたタイプおよびXSDに定義された置換グループに基づいて要素およびタイプの置換を行うことができます。多くのスキーマには、置換グループの要素またはxsi:typeを使用して導出されたタイプの要素でオーバーロードできる抽象要素またはタイプが含まれます。

XSLTエディタのテスト・ツールでは、置換された要素を含む入力XMLドキュメントの生成は現在サポートされません。そのため、ソース・ツリーで置換が行われたXSLTマップを起動すると、次の警告が表示されます。

ユーザーは、生成された入力ドキュメントを変更するか、独自のテスト入力ファイルを提供する必要があります。xsi:type定義または必要な要素の置換に正しい構文を使用してユーザー自身が入力ドキュメントで置換を行う必要がありますが、これは簡単ではありません。複数の置換が行われた大規模なスキーマの場合、より難しくなります。

XSLTエディタを使用すると、要素が正しく置換され、適切なネームスペース/接頭辞がすべて定義された入力ドキュメントを生成できます。これを入力テスト・ドキュメントのテンプレートにします。

前述のマッピングでは、ソース・ツリーで2つの置換が行われています。1つ目は、スキーマ・ドキュメントで定義された置換グループの置換された要素CommentListです。2つ目は、スキーマ・ドキュメントで定義された、導出されたアイテム・タイプのItemタイプ置換です。

このマップをテストするためのテスト入力ファイルとして使用できるドキュメントを生成する小さなXSLTマップを作成します。これには、正しいxsi:typeおよびソース・ドキュメントに定義された要素置換情報が含まれる必要があります。

既存のマップのPurchaseOrderソースのテスト入力として使用できるPurchaseOrderドキュメントを出力する必要があるため、ソースにはスキーマ・ドキュメントを選択せず、ターゲットにはPurchaseOrderスキーマを選択して新しいマップを作成します。

スキーマからの子の追加を使用し、PurchaseOrderソースで行ったのと同じ置換をPurchaseOrderターゲットに行い、次のようなマップを作成します。

このXSLTをテスト・ツールで実行し、PurchaseOrderテンプレート・ドキュメントを作成します。

これによって、テスト用の正しい置換を含む、テスト入力ドキュメントのテンプレートが生成されます。

定義されたフィールドに適切なテスト・データを入力できます。あるいは、テスト・ファイルを生成するXSLTにデータ値を定義し、テスト・ファイルに事前移入できます。

オラクルの法律上の注意点について

コピーライトについて

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を参照してください。