Oracle® Fusion Middleware

Oracle Enterprise Scheduler用アプリケーションの開発

12c (12.2.1.2.0)

E82775-01(原本部品番号:E67983-01)

2016年11月

エンタープライズ・アプリケーション作業のスケジューリングおよび負荷軽減を目的にOracle Enterprise Schedulerを使用してJava、PL/SQL、EJB、Webサービスおよびバイナリ・プロセス・コードを実行するジョブを開発するための、開発者向けドキュメントです。

Oracle Fusion Middleware Oracle Enterprise Schedulerアプリケーションの開発 12c (12.2.1.2.0)

E82775-01

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

原本著者: Oracle Corporation

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

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

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

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

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

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

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

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

目次

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

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

1 Oracle Enterprise Schedulerの概要

- 1.1 Oracle Enterprise Schedulerについて

- 1.2 アプリケーション開発者を対象としたOracle Enterprise Schedulerの概要

- 1.2.1 設計時におけるOracle Enterprise Schedulerの使用の概要

- 1.2.2 実行時におけるOracle Enterprise Schedulerの使用の概要

- 1.2.3 Oracle Enterprise Schedulerのジョブ・リクエスト

- 1.2.4 統合ステップの概要

- 1.3 Oracle Enterprise Schedulerを使用した定率スケジューリング

2 ジョブ開発の計画

- 2.1 ジョブ開発フロー

- 2.2 ホスティング・アプリケーション

- 2.3 クライアント・アプリケーション

- 2.4 ジョブ実装の作成

- 2.5 ジョブ・メタデータの作成

- 2.5.1 発行後の自動メタデータ・リフレッシュ

3 Oracle Enterprise Schedulerのインストールおよびインストールの確認

- 3.1 Oracle Enterprise Schedulerのインストール

- 3.1.1 ドメイン作成時のOracle Enterprise Schedulerのターゲット設定

- 3.1.2 Oracle Enterprise SchedulerでのOWSM-PMのターゲット設定

- 3.1.2.1 OWSM-PMの手動ターゲット設定

- 3.2 Oracle Enterprise Schedulerのインストールの検証の概要

- 3.3 Oracle Enterprise Schedulerのインストールのブラウザを使用した検証方法

- 3.4 Oracle Enterprise Schedulerのインストールのプログラムによる検証方法

- 3.5 実行時に行われる処理: Oracle Enterprise Schedulerのインストールの検証方法

4 事前デプロイ済のネイティブ・ホスティング・アプリケーションの使用

- 4.1 概要

- 4.2 プロパティ

- 4.3 メタデータ

- 4.4 セキュリティ権限

- 4.4.1 ポリシー・ストライプの構成

- 4.4.2 複数のアプリケーション・ストライプのサポート

5 ホスティング・アプリケーションを生成するためのAntの使用

- 5.1 Antを使用したホスティング・アプリケーションの生成の概要

- 5.1.1 Antビルド・ファイルを使用するための前提条件

- 5.2 ホスティング・アプリケーションの作成およびデプロイ用のAntターゲット

- 5.3 Antを使用したホスティング・アプリケーションおよびプロジェクト・ワークスペースの作成

- 5.4 Antを使用した共有ライブラリとしてのJavaジョブの作成

- 5.5 Antを使用したJavaジョブの共有ライブラリとしてのパッケージ化

- 5.6 Antを使用した共有ライブラリのデプロイ

- 5.7 Antを使用したホスティング・アプリケーションのパッケージ化

- 5.8 Antを使用したホスティング・アプリケーションのデプロイ

- 5.9 生成されたAntターゲットの構成

6 シン・クライアント・アプリケーションの作成

- 6.1 概要

- 6.2 実装

- 6.2.1 保護された起動

- 6.2.1.1 転送起動

- 6.2.1.2 コールバック起動

- 6.2.2 RemoteConnector APIおよびサーバー・アフィニティ・プロパティ

- 6.2.3 例

- 6.2.3.1 RemoteConnectorを使用するJava EEアプリケーション

- 6.2.3.2 実装

- 6.2.3.3 サブジェクトの伝播

- 6.3 JDeveloperを使用したMARデプロイメント用のシン・クライアント・アプリケーションのビルド

- 6.3.1 スタンドアロン環境用のシン・クライアント・アプリケーションの作成およびデプロイ

- 6.4 JDeveloperを使用したEJBおよびそのジョブ定義メタデータの作成および構成

7 Oracle JDeveloperを使用したOracle Enterprise Schedulerアプリケーションの生成

- 7.1 JDeveloperを起動してOracle Enterprise Schedulerアプリケーションのビルドをサポートする方法

- 7.2 Oracle JDeveloperによって作成されたOracle Enterprise Schedulerアプリケーション・サポートの理解

- 7.3 組み合されたOracle Enterprise Schedulerアプリケーションのビルド

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

- 7.3.1.1 EssDemoAppアプリケーションおよびホスト・プロジェクトの作成方法

- 7.3.1.2 クライアント・プロジェクトの作成方法

- 7.3.2 EssDemoAppアプリケーションのメタデータおよび実装クラスの作成

- 7.3.2.1 EssDemoAppアプリケーションのメタデータの作成方法

- 7.3.3 ジョブ・リクエストを発行するアプリケーション・コードの追加

- 7.3.3.1 ジョブ・リクエストを発行するアプリケーション・コードの追加方法

- 7.3.4 Oracle Enterprise Schedulerプロパティの設定

- 7.3.4.1 アプリケーションのOracle Enterprise Schedulerプロパティを設定する方法

- 7.3.5 EssDemoAppアプリケーションのアセンブル

- 7.3.5.1 EssDemoAppのEJB-JARデプロイメント・プロファイルの作成方法

- 7.3.5.2 WARアーカイブ・オプションの更新方法

- 7.3.5.3 アプリケーションMARファイルの作成

- 7.3.5.4 EARオプションの更新方法

- 7.3.5.5 アプリケーションのセキュリティの構成

- 7.3.5.6 ジョブ定義でのESSアプリケーション・ロールに対するリソース権限の追加

- 7.3.5.7 weblogic-application.xmlファイルの構成

- 7.3.5.8 EssHost MANIFESTファイルの更新

- 7.3.5.9 「レルム」フィールドの変更

- 7.3.5.10 EssDemoAppアプリケーションのadf-config.xmlファイルの編集

- 7.3.6 EssDemoAppアプリケーションのデプロイおよび実行

- 7.3.6.1 EssDemoAppアプリケーションのデプロイ方法

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

- 7.3.6.3 EssDemoAppサンプル・アプリケーションでのジョブのパージ方法

- 7.4 分割された発行者アプリケーションおよびホスティング・アプリケーションのビルド

- 7.4.1 EssDemoAppのバックエンドのホスティング・アプリケーションを作成する方法

- 7.4.1.1 バックエンドのホスティング・アプリケーションの作成

- 7.4.1.2 バックエンドのホスティング・アプリケーションのセキュリティの構成

- 7.4.1.3 バックエンドのホスティング・アプリケーションのメタデータの定義

- 7.4.1.4 バックエンドのホスティング・アプリケーションでのJava実装クラスの作成

- 7.4.1.5 Oracle Enterprise Schedulerプロパティの設定

- 7.4.1.6 Oracle Enterprise Schedulerのバックエンドのホスティング・アプリケーションのアセンブル

- 7.4.1.6.1 バックエンドのホスティング・アプリケーションのEJB JARファイルをアセンブルする方法

- 7.4.1.6.2 バックエンドのホスティング・アプリケーションのMARおよびEARファイルをアセンブルする方法

- 7.4.1.7 SuperEss MANIFESTファイルの更新

- 7.4.1.8 weblogic-application.xmlファイルの構成

- 7.4.1.9 バックエンドのホスティング・アプリケーションのデプロイ

- 7.4.1.10 EssDemoAppアプリケーションのadf-config.xmlファイルの編集

- 7.4.2 Oracle Enterprise Schedulerのフロントエンドの発行者アプリケーションを作成する方法

- 7.4.2.1 フロントエンドの発行者アプリケーションの作成

- 7.4.2.2 SuperWebプロジェクトの作成

- 7.4.2.3 フロントエンドの発行者アプリケーションのセキュリティの構成

- 7.4.2.4 フロントエンドの発行者アプリケーションのHTTPサーブレットの作成

- 7.4.2.5 フロントエンドの発行者アプリケーションのweb.xmlファイルの編集

- 7.4.2.6 フロントエンドの発行者アプリケーションのweblogic-application.xmlファイルの編集

- 7.4.2.7 フロントエンドの発行者アプリケーションのadf-configファイルの編集

- 7.4.2.8 Oracle Enterprise Schedulerのフロントエンドの発行者アプリケーションのアセンブル

- 7.4.2.8.1 フロントエンドの発行者アプリケーションのEJB JARファイルをアセンブルする方法

- 7.4.2.8.2 フロントエンドの発行者アプリケーションのWARファイルをアセンブルする方法

- 7.4.2.8.3 フロントエンドのホスティング・アプリケーションのMARおよびEARファイルをアセンブルする方法

- 7.4.2.8.4 ADFライブラリの追加

- 7.4.2.8.5 アプリケーションのOracle Enterprise Schedulerプロパティの設定

- 7.4.2.9 weblogic-application.xmlファイルの構成

- 7.4.2.10 フロントエンドの発行者アプリケーションのデプロイ

- 7.4.2.11 EssHost MANIFESTファイルの更新

- 7.4.2.12 分割されたアプリケーションの実行

8 メタデータ・サービスの使用

- 8.1 メタデータ・サービスの使用の概要

- 8.1.1 メタデータ・サービス・ネームスペースの概要

- 8.1.2 メタデータ・サービス操作の概要

- 8.1.3 メタデータ・サービス・トランザクションの概要

- 8.2 メタデータ・サービスへのアクセス

- 8.2.1 ステートレス・セッションEJBを使用してメタデータ・サービスにアクセスする方法

- 8.3 Oracle JDeveloperを使用したメタデータ・サービスへのアクセス

- 8.4 メタデータ・サービスを使用したメタデータの問合せ

- 8.4.1 フィルタの作成方法

- 8.4.2 メタデータ・オブジェクトの問合せ方法

9 パラメータとシステム・プロパティの使用

- 9.1 パラメータとシステム・プロパティの使用の概要

- 9.1.1 アプリケーション定義のプロパティおよびシステム・プロパティのネーミングに関する必知事項

- 9.1.2 パラメータの競合解決方法およびパラメータのマテリアライズに関する必知事項

- 9.1.2.1 ジョブ定義パラメータのマテリアライズに関する必知事項

- 9.1.2.2 ジョブ・セット・レベル・パラメータのマテリアライズに関する必知事項

- 9.2 メタデータ・サービスでのパラメータの使用

- 9.2.1 メタデータ・オブジェクトでのパラメータとシステム・プロパティの使用方法

- 9.3 ランタイム・サービスでのパラメータの使用

- 9.3.1 ランタイム・サービスでのパラメータの使用方法

- 9.3.2 ジョブ・セット・ステップのステップIDを含むパラメータの使用方法

- 9.4 システム・プロパティの使用

10 トークンおよび論理クラスタの使用

- 10.1 トークン置換の使用

- 10.1.1 ネストされている置換

- 10.1.2 自動置換

- 10.2 論理クラスタの使用

11 PL/SQLジョブの作成と使用

- 11.1 PL/SQLストアド・プロシージャ・ジョブ定義の使用の概要

- 11.2 Oracle Enterprise Scheduler用PL/SQLストアド・プロシージャの作成

- 11.2.1 正しいシグネチャを持つPL/SQLストアド・プロシージャの定義方法

- 11.2.2 Oracle Enterprise Scheduler PL/SQLストアド・プロシージャでのランタイム例外の処理

- 11.2.3 PL/SQLストアド・プロシージャでのジョブ・リクエスト情報へのアクセス方法

- 11.2.4 PL/SQLストアド・プロシージャの定義に関する必知事項

- 11.3 PL/SQLストアド・プロシージャ用のOracle Databaseタスクの実行

- 11.3.1 PL/SQLストアド・プロシージャ権限の付与方法

- 11.3.2 PL/SQLストアド・プロシージャ権限の付与に関する必知事項

- 11.4 PL/SQLジョブ・タイプのジョブ定義の作成および格納

- 11.4.1 PL/SQLジョブ・タイプの作成方法

- 11.4.2 PL/SQLジョブ・タイプのジョブ定義の作成および格納方法

- 11.4.3 Oracle Enterprise SchedulerアプリケーションでのPL/SQLストアド・プロシージャの使用

12 EJBジョブの作成と使用

- 12.1 EJBジョブの作成の概要

- 12.2 ジョブ開発の計画

- 12.3 EJBジョブ・タイプのジョブ定義の作成および格納

- 12.4 保護された起動

- 12.4.1 転送起動

- 12.4.2 コールバック起動

- 12.4.3 RemoteConnector APIおよびサーバー・アフィニティ・プロパティ

- 12.4.4 リモート・サーバーからのCSF参照

- 12.5 同期Bean

- 12.5.1 メタデータ

- 12.5.2 EJBジョブ・サンプル・コード

- 12.6 非同期Bean

- 12.6.1 メタデータ

- 12.6.2 EJBジョブ・サンプル・コード

- 12.6.2.1 メッセージドリブンBeanを使用した非同期性の実装サンプル

- 12.6.2.2 注釈を使用した非同期性の実装サンプル

13 Webサービス・ジョブの作成と使用

- 13.1 概要

- 13.2 事前定義済Webサービス・ジョブ・タイプ

- 13.3 取消しおよびフォルトのサポート

- 13.4 Webサービス・ジョブの構成プロパティ

- 13.5 Oracle Web Services Managerポリシー構成

- 13.6 Webサービス・ジョブ定義の作成

- 13.6.1 Oracle JDeveloperを使用したジョブ定義の作成

- 13.6.2 Oracle Enterprise Manager Fusion Middleware Controlを使用したジョブ定義の作成

14 プロセス・ジョブの作成と使用

- 14.1 プロセス・ジョブ定義の作成の概要

- 14.2 プロセス・ジョブ・タイプのジョブ定義の作成および格納

- 14.2.1 プロセス・ジョブ・タイプを作成および格納する方法

- 14.2.2 プロセス・タイプのジョブ定義を作成および格納する方法

- 14.3 プロセス・ジョブに対するエージェント・ハンドラの使用

- 14.3.1 エージェント・ハンドラの選択

- 14.4 プロセス・ジョブのロケール

15 スケジュールの定義および使用

- 15.1 スケジュールの概要

- 15.2 繰返しの定義

- 15.2.1 繰返しフィールド・ヘルパーによる繰返しの定義方法

- 15.2.2 iCalendar RFC 2445仕様による繰返しの定義方法

- 15.2.3 繰返しフィールド・ヘルパーの使用に関する必知事項

- 15.2.4 iCalendar式の使用に関する必知事項

- 15.3 明示的な日付の定義

- 15.3.1 明示的な日付の定義方法

- 15.3.2 明示的な日付に関する必知事項

- 15.4 除外の定義および格納

- 15.4.1 除外の定義方法

- 15.4.2 除外定義の作成方法

- 15.5 スケジュールの定義および格納

- 15.5.1 スケジュールの定義および格納方法

- 15.5.2 スケジュールの定義および格納時の処理内容

- 15.5.3 スケジュールでのタイムゾーンの処理に関する必知事項

- 15.6 特定のスケジュールを使用するジョブ・リクエストの識別

- 15.7 スケジュールの更新および削除

16 Oracle Enterprise Scheduler Webサービスの使用

- 16.1 Oracle Enterprise Scheduler Webサービスの概要

- 16.2 ESSWebserviceアプリケーションの開発および使用

- 16.2.1 ESSWebservice Java EEアプリケーションの開発および使用方法

- 16.2.2 BPELによるESSWebservice SOAアプリケーションの開発および使用方法

- 16.2.3 getCompletionStatus()操作のWebサービスAddressingヘッダーの設定

- 16.2.4 ESSWebserviceの使用上の制限

- 16.2.5 ESSWebserviceの実装

- 16.3 ESSWebservice WSDLファイル

- 16.4 ユースケース: BPELプロセスでのOracle Enterprise Scheduler ESSWebserviceの使用

17 ジョブ・セットの定義および使用

- 17.1 ジョブ・セットの定義および使用の概要

- 17.2 ジョブ・セットの定義

- 17.2.1 ジョブ・セットの定義方法

- 17.2.2 シリアル・ジョブ・セット・ステップの定義方法

- 17.2.3 パラレル・ジョブ・セット・ステップの定義方法

- 17.2.4 ジョブ・セットの定義時の処理内容

- 17.2.5 シリアル・ジョブ・セットに関する必知事項

- 17.2.6 ジョブ・セットのアプリケーション定義プロパティおよびシステム・プロパティに関する必知事項

- 17.2.7 ジョブ・セットの状態の優先度および状態遷移に関して実行時に行われる処理

- 17.3 アプリケーション間ジョブ・セット

- 17.3.1 アプリケーション間ジョブ・セットの概要

- 17.3.2 アプリケーション間ジョブ・セットの要件

- 17.4 ジョブ・セットでの入力および出力転送のサポート

18 ジョブ非互換性の定義および使用

- 18.1 ジョブ非互換性の使用の概要

- 18.1.1 ジョブの自己非互換性

- 18.2 Oracle JDeveloperとの非互換性の定義

- 18.2.1 グローバルな非互換性の定義方法

- 18.2.2 ドメインの非互換性の定義方法

- 18.3 ジョブ非互換性を処理するために実行時に行われる処理

- 18.3.1 互換性のない親リクエストを含むサブリクエストについての処理

19 ランタイム・サービスの使用

- 19.1 ランタイム・サービスの概要

- 19.2 ランタイム・サービスへのアクセス

- 19.2.1 ランタイム・サービスにアクセスしてランタイム・サービス・ハンドルを取得する方法

- 19.3 ジョブ・リクエストの発行

- 19.3.1 ランタイム・サービスへのリクエストの発行方法

- 19.3.2 リクエスト発行時のデフォルト・システム・プロパティに関する注意事項

- 19.3.3 リクエスト発行時のメタデータに関する注意事項

- 19.3.4 DMS ECIDおよびFlowIdのサポート

- 19.3.4.1 子リクエストのECIDおよびFlowID

- 19.3.4.2 DMS FlowIdおよびSOA CorrelationFlowId

- 19.4 ジョブ・リクエストの管理

- 19.4.1 getRequestDetailによるジョブ・リクエスト情報の取得方法

- 19.4.2 ジョブ・リクエスト状態の変更方法

- 19.4.3 ジョブ・リクエストの優先度とジョブ・リクエスト・パラメータの更新方法

- 19.5 ジョブ・リクエストの問合せ

- 19.6 非定型ジョブ・リクエストの発行

- 19.6.1 非定型リクエストの作成方法

- 19.6.2 非定型リクエストの作成時の処理内容

- 19.6.3 非定型リクエストに関する必知事項

- 19.7 前処理および後処理ハンドラの実装

- 19.7.1 前処理ハンドラの実装

- 19.7.1.1 PreProcessHandlerインタフェースの実装

- 19.7.2 後処理ハンドラの実装

- 19.7.2.1 PostProcessHandlerインタフェースの実装

20 サブリクエストの使用

- 20.1 サブリクエストの使用の概要

- 20.2 サブリクエストの作成と管理

- 20.2.1 サブリクエストの発行方法

- 20.2.2 サブリクエストの取消し方法

- 20.2.3 サブリクエストの保留方法

- 20.2.4 複数のサブリクエストの発行方法

- 20.2.5 一時停止されたサブリクエストの管理方法

- 20.2.5.1 一時停止ステータスの指定

- 20.2.5.2 親リクエストの一時停止状態の格納

- 20.2.6 サブリクエストの処理方法

- 20.2.7 サブリクエストの識別方法

- 20.2.8 サブリクエストと非互換性の管理方法

- 20.3 サブリクエストを発行するJavaプロシージャの作成

- 20.4 サブリクエストを発行するPL/SQLプロシージャの作成

21 非同期Javaジョブの使用

- 21.1 非同期Javaジョブの使用の概要

- 21.2 非同期Javaジョブの作成

- 21.2.1 非同期Javaジョブの非同期インタフェースの実装

- 21.2.2 非同期Javaジョブのexecute()メソッド

- 21.2.3 非同期Javaジョブからのリモート・ジョブの起動

- 21.2.4 ステータス更新を伴うOracle Enterprise Schedulerへのコールバック

- 21.2.5 非同期Javaジョブの更新

- 21.2.6 非同期ジョブ完了時のOracle Enterprise Schedulerへの通知

- 21.2.6.1 非同期ジョブ完了時のWebサービスを使用した通知

- 21.2.6.2 非同期ジョブ完了時のEJBを使用した通知

- 21.2.7 非同期JavaジョブのAsyncCancellableインタフェース

- 21.2.8 イベント配信ネットワークを介してBPELプロセスを起動する非同期Javaジョブのサンプル

- 21.2.8.1 Oracle Enterprise Schedulerを使用したBPELプロセスのデザインタイムのサンプル

- 21.3 非同期ジョブとしてのBPELプロセスの実装を示すユースケース

- 21.3.1 推奨されるデザイン・パターンの概要

- 21.3.2 考えられるアプローチ

- 21.3.3 ユースケース・サマリー

- 21.4 非同期ジョブを使用したBPELの実装方法

- 21.4.1 ユースケース: Oracle JDeveloperライブラリの追加

- 21.4.2 ユースケース: 非同期ジョブ定義の作成

- 21.4.3 ユースケース: イベント・ペイロード・スキーマ・ファイルおよびイベント定義ファイルの設計

- 21.4.4 非同期ジョブのメソッドからのビジネス・イベントのプログラムによる呼出し

- 21.4.5 メディエータおよびBPELを使用したSOAコンポジットの設計

- 21.4.6 エラーに対するフォルト処理と相関onMessageブランチの追加およびジョブの取消し

- 21.4.6.1 相関セットの作成および開始アクティビティの定義

- 21.4.6.2 相関セットを使用したonMessageブランチの作成

- 21.4.6.3 フォルト・ブランチの作成

- 21.4.6.4 onMessageおよびフォルト・ブランチへの移入

- 21.4.7 デプロイメントの検証

- 21.4.8 ユースケースのトラブルシューティング

- 21.5 非同期ジョブのタイムアウトおよびリカバリの処理

- 21.5.1 非同期リクエストのタイムアウト

- 21.5.1.1 タイムアウト値の設定

- 21.5.1.2 タイムアウトした非同期ジョブ・リクエストの検出

- 21.5.1.3 タイムアウトがない非同期リクエストの完了

- 21.5.1.4 非同期ジョブ・リクエストのタイムアウト時の処理内容

- 21.5.2 手動リカバリ対象としてマークされた非同期ジョブの処理

- 21.5.3 ジョブ・リクエストの手動リカバリに対するRecoverRequestの使用

- 21.6 Oracle Enterprise Schedulerのインタフェースとクラス

22 ジョブ・リクエスト・ログと出力

- 22.1 リクエスト・ログ

- 22.1.1 システム・プロパティ

- 22.1.2 ログ・ヘッダー

- 22.1.3 Javaジョブからのリクエスト・ロギング

- 22.1.3.1 Javaジョブ・ログ出力用API

- 22.1.3.2 Javaリクエスト・ロギングの例

- 22.1.4 PL/SQLジョブからのリクエスト・ロギング

- 22.1.4.1 ログを作成するためのESS_JOBパッケージ・サポート

- 22.1.4.2 PL/SQLのリクエスト・ロギングの例

- 22.1.5 プロセス・ジョブからのリクエスト・ロギング

- 22.1.6 EJBジョブからのリクエスト・ロギングおよび出力

- 22.1.7 Webサービス・ジョブからのリクエスト・ロギング

- 22.1.8 リクエスト・ログを処理するためのAPI

- 22.2 リクエスト出力

- 22.2.1 リクエスト・ファイル・ディレクトリの使用

- 22.2.1.1 リクエスト・ファイル・ディレクトリの共通動作

- 22.2.1.2 共有リクエスト・ファイル・ディレクトリの動作

- 22.2.1.2.1 共有リクエスト・ファイル・ディレクトリを使用する場合のエラー処理

- 22.2.1.3 ローカル・リクエスト・ファイル・ディレクトリの動作

- 22.2.1.3.1 ローカル・リクエスト・ファイル・ディレクトリを使用する場合のエラー処理

- 22.2.2 システム・プロパティ

- 22.2.3 Javaジョブからのリクエスト出力の作成

- 22.2.3.1 Javaジョブからのリクエスト出力を処理するためのAPI

- 22.2.3.2 Javaリクエスト出力の例

- 22.2.4 PL/SQLジョブからのリクエスト出力の作成

- 22.2.4.1 出力を作成するためのPL/SQLパッケージ・サポート

- 22.2.4.2 PL/SQL出力作成の例

- 22.2.5 プロセス・ジョブからのリクエスト出力の作成

- 22.2.6 EJBジョブからのリクエスト出力の作成

- 22.2.7 Webサービス・ジョブからのリクエスト出力の作成

- 22.2.8 リクエスト出力を処理するためのAPI

23 Oracle Enterprise Schedulerセキュリティ

- 23.1 Oracle Enterprise Schedulerセキュリティの概要

- 23.1.1 Oracle Enterprise Schedulerのメタデータ・アクセス制御

- 23.1.2 Oracle Enterprise Schedulerのジョブ実行のセキュリティ

- 23.2 Oracle Enterprise Schedulerのメタデータのセキュリティの構成

- 23.2.1 Oracle ADF Securityウィザードを使用してアプリケーション・セキュリティを有効にする方法

- 23.2.2 EARファイルへのセキュリティ・ファイルの包含

- 23.2.3 セキュリティのプリンシパルの定義方法

- 23.2.4 エンタープライズ・ロールの作成

- 23.2.5 Oracle Enterprise Schedulerのメタデータ・ページを使用した権限の作成方法

- 23.2.6 MetadataPermission APIについて

- 23.2.7 メタデータのセキュリティの構成時の処理内容

- 23.3 Oracle Enterprise Schedulerのデータのセキュリティの構成

- 23.3.1 データ・セキュリティ権限の変更方法

- 23.3.1.1 条件

- 23.3.1.1.1 条件の例

- 23.3.1.2 アクション

- 23.3.2 例

- 23.4 Oracle Enterprise SchedulerのWebサービス・セキュリティの構成

- 23.5 Oracle Enterprise SchedulerのPL/SQLジョブのセキュリティの構成

- 23.6 Oracle Enterprise Schedulerジョブに対する権限の昇格

- 23.7 Oracle Enterprise Schedulerの単一のポリシー・ストライプの構成

- 23.7.1 Oracle Enterprise Schedulerの単一のポリシー・ストライプの構成方法

- 23.7.2 単一のポリシー・ストライプの構成時の処理内容

- 23.7.3 実行時に行われる処理

表一覧

- 3-1 HTTPレスポンス・コード

- 4-1 事前デプロイ済ネイティブ・ホスティング・アプリケーションのプロパティ

- 5-1 組込みビルド・ファイル内のAntターゲット

- 5-2 生成されたビルド・ファイル内のAntターゲット

- 5-3 Antターゲットで必要な情報

- 5-4 Antターゲットで必要な情報

- 5-5 Antビルドをカスタマイズするためのビルド・プロパティ

- 7-1 フロントエンドの発行者アプリケーションのEJBリソース

- 8-1 フィルタ比較演算子

- 8-2 MetadataService問合せフィールド

- 9-1 パラメータの優先順位レベル

- 9-2 ParameterInfoパラメータ・プロパティ

- 9-3 システム・プロパティ

- 10-1 ジョブの場所に関連付けられているプロパティ

- 11-1 PL/SQLストアド・プロシージャの結果の終了状態

- 11-2 PL/SQLストアド・プロシージャ・ジョブ・タイプ用のOracle Enterprise Schedulerシステム・プロパティ

- 12-1 EJBジョブ・タイプのプロパティ

- 12-2 追加プロパティ

- 13-1 事前定義済Webサービス・ジョブ・タイプ

- 13-2 SOAP Webサービス操作ステータス

- 13-3 Oracle SOA Suiteステータス操作

- 13-4 Webサービス・ジョブの構成プロパティ

- 14-1 プロセス・タイプのジョブのためのシステム・プロパティ

- 15-1 繰返しフィールド・ヘルパー・パターン

- 16-1 ESSWebserviceで使用可能な操作の要約

- 17-1 ジョブ・セット・ステップのプロパティ

- 17-2 ジョブ・セットのシリアル実行ステップの終了状態

- 17-3 ジョブ・セットの終了状態の遷移

- 17-4 可能なジョブ・セットの実行時の状態

- 19-1 ランタイム・サービスのデフォルト値フィールドと対応するシステム・プロパティ

- 19-2 ランタイム・サービスのGetリクエスト・メソッド

- 19-3 ランタイム・サービスのジョブ・リクエスト状態メソッド

- 19-4 ランタイム・サービスの更新メソッド

- 19-5 ランタイムの問合せ用の問合せフィルタ・フィールド(列挙RuntimeService.QueryFieldで定義)

- 19-6 ランタイム・サービスの問合せメソッド

- 19-7 ジョブ・タイプに対する非定型リクエスト・ジョブ定義のシステム・プロパティ

- 22-1 リクエスト・ログを作成するためのContentFactoryメソッド

- 22-2 リクエスト・ログを作成するためのRequestLoggerメソッド

- 22-3 リクエスト・ロギング用のESS_JOBファンクションおよびプロシージャ

- 22-4 リクエスト・ログを処理するためのRuntimeServiceメソッド

- 22-5 リクエスト出力を作成するためのシステム・プロパティ

- 22-6 Javaリクエスト出力用のContentFactoryメソッド

- 22-7 Javaリクエスト出力用のRequestOutputメソッド

- 22-8 Javaリクエスト出力用のOutputContentHelperメソッド

- 22-9 コミット・セマンティクスを表すCommitSemantics列挙メンバー

- 22-10 リクエスト出力用のESS_JOBプロシージャおよびファンクション

- 22-11 リクエスト出力を処理するためのRuntimeServiceメソッド

- 23-1 メタデータのセキュリティに対する付与アクション

- 23-2 条件問合せフィールドと、対応するリクエスト履歴ビューの列エントリ

はじめに

このドキュメントでは、Oracle Enterprise Schedulerのジョブおよびその他の拡張機能を開発する方法について説明します。

Oracle Enterprise Schedulerでは、Oracle WebLogic Server clusterクラスタのノード全体に分散された様々なジョブ・タイプ(Java、PL/SQL、バイナリ・スクリプトなど)を実行する機能が提供されています。Oracle Enterprise Schedulerは、これらのジョブを安全に実行すると同時に、高可用性とスケーラビリティを実現してロード・バランシングを行い、Oracle Enterprise Manager Fusion Middleware Controlを使用したモニタリングと管理を提供します。

対象読者

このドキュメントは、JavaおよびSQLを理解しているOracleアプリケーションの開発者を対象としています。

ドキュメントのアクセシビリティ

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

関連ドキュメント

詳細は、Oracle 12c Fusion Middlewareのドキュメント・セットにある次のドキュメントを参照してください。

- SOA Suite用WLSTコマンド・リファレンス

- Oracle SOA SuiteおよびBusiness Process Managementのインストールおよび構成

- Oracle Fusion Middleware Oracle Application Development FrameworkのためのFusion開発者ガイド

- Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド

- 『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』

- Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド

- Oracle Fusion Middleware Oracle Enterprise Schedulerの管理
このガイドの次の章では、Oracle Enterprise Schedulerの管理機能について説明します。

- 「Oracle Enterprise Scheduler Serviceおよびジョブの管理」

- 「Oracle Enterprise Schedulerのトラブルシューティング」

- 「Oracle Enterprise Schedulerの高可用性」

表記規則

このマニュアルでは次の表記規則を使用します。

表記規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

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

この12.2.1.2.0リリースでは、このガイドに対する更新はありません。

既知の問題のリスト(リリース・ノート)については、http://www.oracle.com/technetwork/middleware/docs/soa-aiafp-knownissuesindex-364630.htmlの「Known Issues for Oracle SOA Products and Oracle AIA Foundation Pack」を参照してください。

1 Oracle Enterprise Schedulerの概要

この章では、作業(Java、PL/SQLおよびバイナリ・プロセス・コードの実行など)の負荷を軽減するジョブを開発するためのサービスとして、Oracle Enterprise Schedulerの概要について説明します。

この章の内容は次のとおりです。

- Oracle Enterprise Schedulerについて

- アプリケーション開発者を対象としたOracle Enterprise Schedulerの概要

- Oracle Enterprise Schedulerを使用した定率スケジューリング

1.1 Oracle Enterprise Schedulerについて

Oracle Enterprise Schedulerを使用すると、Oracle WebLogic Serverクラスタのノード全体に分散された、Java、PL/SQL、バイナリ・スクリプト、Webサービス、EJBなどの、様々なジョブ・タイプを実行できます。

Oracle Enterprise Schedulerは、これらのジョブを安全に実行すると同時に、高可用性とスケーラビリティを実現し、ロード・バランシングを行い、Fusion Middleware Controlを使用したモニタリングと管理を提供します。

Fusion Middleware Controlによって、Oracle Enterprise Schedulerアプリケーションをモニターおよび管理するページにアクセシビリティ・オプションが提供されます。Fusion Middleware Controlは、スクリーン・リーダーをサポートしており、キーボード・ナビゲーションをサポートするための標準のショートカット・キーを提供しています。読みやすくするために、コンソール・ページを高コントラストで表示したり、大きなフォントで表示したりすることもできます。Fusion Middleware Controlにおけるアクセシビリティの構成の詳細と手順は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middlewareのアクセシビリティ・オプションの使用に関する項を参照してください。

Oracle Enterprise Schedulerでは、次の目的のためにスケジューリング・サービスが提供されています。

- アプリケーション・サーバーのグリッド全体にジョブ・リクエストの処理を分散するため

- Java、PL/SQL、バイナリ・プロセス・ジョブ、WebサービスおよびEJBを実行するため

- ジョブ・リクエストをジョブ・セットにグループ化するため

- 繰返し式に基づいたジョブ・リクエストをスケジュールするため

- Fusion Middleware Controlを使用してジョブ・リクエストを管理するため

Oracle Enterprise Schedulerでは、スケジュールに基づいて繰り返す必要があるプロセスを自動化したり、負荷の大きい処理を特定の時間ウィンドウに遅延させるための、サービス指向環境における重要な要件が提供されています。Oracle Enterprise Schedulerを使用すると、次を実行できます。

- 高度なスケジュールおよびワークロード管理のサポート

- 管理ジョブの実行の自動化

- レポートの作成および配布のスケジュール

- ビジネス・プロセス管理のためのビジネス・フローにおける手順の将来のスケジュール

Oracle Enterprise Schedulerでは、ジョブ定義の完全なライフ・サイクル(開発、分散、スケジュールおよびモニタリング)を管理する機能が提供されています。Oracle JDeveloperを使用すると、アプリケーション開発者は、開発環境でジョブ・リクエストを簡単に作成できます。アプリケーション管理者および他のユーザーは、ジョブ・リクエストの実行時間および実行場所を指定できます。ユーザーおよび管理者はジョブがどのように実行されたかをモニターして、これらのジョブの終了結果にアクセスできます。

大規模なシステムを実装するカスタマは、通常、多数の様々なマシンを管理して、それらのユーザーのワークロードを処理する必要があります。Oracle Enterprise Schedulerでは、個別のマシンやマシンのグループへの作業の分散方法を制御する機能が提供されています。

1.2 アプリケーション開発者を対象としたOracle Enterprise Schedulerの概要

Oracle Enterprise Schedulerは、主としてJava EEアプリケーションであり、このアプリケーションでは、ジョブを実行するための時間ベースおよびスケジュールベースのコールバックを他のアプリケーションに対して使用できます。

Oracle Enterprise Schedulerは、電話やOracle Calendarで使用することがあるCalendarアプリケーションと似ています。Calendarアプリケーションでは、ユーザーがイベントや会議を作成して時間と繰返しの詳細を設定し、特定のイベントにとって適切な時間に、アプリケーションによって警告または通知が送信されます。同様に、Oracle Enterprise Schedulerアプリケーションではジョブが定義され、これらのジョブを実行する必要がある時間が指定されて、指定した時間または特定のイベントを受信したときに、Oracle Enterprise Schedulerによってこれらのアプリケーションに対するコールバックが行われます。これは、特定のアプリケーションがOracle Enterprise Schedulerのインスタンスと相互作用できる方法を簡略化したモデルです。Oracle Enterprise Schedulerではジョブそのものを実行するのではなく、アプリケーションに対してコールバックを行い、これにより、アプリケーションでジョブ・リクエストが実際に実行されます。これは、Oracle Enterprise Schedulerではジョブ・リクエストの詳細が認識されず、すべてのジョブ・リクエストの詳細はアプリケーションによって所有および使用されることを意味します。ジョブを実行するリクエストを発行するアプリケーションは、クライアント・アプリケーションを呼ばれます。

開発目的のために、Oracle Enterprise SchedulerとOracle Enterprise Schedulerクライアント・アプリケーションは両方とも、同じOracle WebLogic Server上にデプロイされます。Fusion Middleware Controlでは、Oracle Enterprise Schedulerと相互作用するためのインタフェースを提供できます。ただし、通常は、クライアント・アプリケーションでエンド・ユーザーがジョブ・リクエストを設定したり、ジョブ・リクエストを実行する時間のスケジュールを指定できるようにし、その後、指定した時間になるか、またはイベントを受信したときにOracle Enterprise Schedulerからコールバックされるようにします。

1.2.1 設計時におけるOracle Enterprise Schedulerの使用の概要

アプリケーション開発者は、設計時にOracle JDeveloperを使用して、Oracle Enterprise Schedulerの実行可能クラスと、この実行可能クラスのためのOracle Enterprise Scheduler固有のメタデータを含むJava EEアプリケーションを作成します。Oracle Enterprise Schedulerのメタデータは、ジョブ定義で構成されており、ここには実行可能クラスとパラメータ、スケジュールが含まれています。スケジュールでは、ジョブ・リクエストを実行するために送信できる時間を取得します。スケジュールはジョブ・リクエストとは無関係に定義され、実行時、ジョブ・リクエストが実行のために発行されるときにジョブ・リクエストに関連付けられます。図1-1に、Oracle Enterprise Schedulerアプリケーションの設計時の概念を示します。

図1-1 Oracle Enterprise Schedulerのデザインタイム統合

図1-1では、Oracle Enterprise Scheduler APIを使用してメタデータがMDSストアに書き込まれていますが、クライアント・アプリケーションがメタデータを所有しており、メタデータはOracle Enterprise Schedulerアプリケーションに属していません。このメタデータはジョブ実装とともにOAR(アプリケーション用のEARやメタデータを含むMARなど)にパッケージ化されており、これがランタイム環境にデプロイされます。

設計時に、次のタイプのメタデータを作成できます。

- ジョブ・タイプ: ジョブの構成要素の基本的な定義であり、次のことを定義します。

1. Java、PL/SQL、バイナリ・スクリプトなどの実行されるジョブのタイプ

2. ジョブのタイプがJavaの場合にはJavaの実行可能クラス、ジョブのタイプがPL/SQLの場合にはPL/SQL機能、またはジョブのタイプがスクリプトの場合にはスクリプト

3. ジョブとそのデータ・タイプに対するパラメータ定義、およびデフォルト値

- ジョブ定義: ジョブ定義(またはジョブ)は、クライアント・アプリケーションのコンテキストで実行される作業の最小単位です。これは基礎となるジョブ・タイプ、およびジョブ・タイプで定義されたパラメータへの追加となる任意のパラメータによって定義されます。

- ジョブ・セット: ジョブ・セットは連続またはパラレルのジョブ・ステップのセットであり、ジョブ・ステップは単一ジョブまたは別のジョブ・セットにすることができます。ジョブ・セットおよびその各ジョブ・セット・ステップには追加パラメータを設定でき、その値は、ジョブまたはジョブ・セットがジョブ・リクエストとして発行されるときに指定されます。

- スケジュール: ジョブ・スケジュールは事前定義された時間や期間の繰返しであるか、または無期限です。スケジュールはジョブとは無関係に定義されますが、ジョブ・リクエストが発行されて実行されるとき、1つ以上のジョブと関連付けられます。

- 非互換性: 非互換性を使用すると、同時に実行できないジョブ定義およびジョブ・セットを指定できます。

1.2.2 実行時におけるOracle Enterprise Schedulerの使用の概要

実行時には、アプリケーション・ユーザーはスケジュールと発行されるジョブを関連付け、ジョブ・パラメータの値を指定します。次に、この情報はジョブ・リクエストとして発行されます。Oracle Enterprise Schedulerでジョブ・リクエストが受信されると、ジョブ・リクエストを実行する適切な時間が決定され、その時間になると、所有するクライアント・アプリケーションにメッセージが送信されます。その後、クライアント・アプリケーションにより、ジョブ・メタデータおよびパラメータのランタイム値に基づいてジョブが実行されます。

図1-2 Oracle Enterprise Schedulerのランタイム統合

図1-2に、Oracle Enterprise Schedulerを使用したアプリケーションの実行に関する順序、および次の手順を示します。

1. ユーザーがクライアント・アプリケーションを使用してリクエストを発行します。

2. クライアント・アプリケーションにより、リクエストがOracle Enterprise Schedulerに送信されます。

3. Oracle Enterprise Schedulerによって、リクエストのメタデータが読み取られます。

4. Oracle Enterprise Schedulerによって、リクエストがメタデータとともにOracle Enterprise Schedulerデータ・ストアの待機キューに置かれます。

5. リクエストの仕様に基づく適切なタイミングで、Oracle Enterprise Schedulerによって、クライアント・アプリケーションにメッセージ、すべてのリクエスト・パラメータおよび発行時に取得されたメタデータが送信されます。

6. クライアント・アプリケーションによってジョブが実行され、ステータスが返されます。

7. Oracle Enterprise Schedulerによって、ジョブ・リクエストのステータスで履歴が更新されます。

1.2.3 Oracle Enterprise Schedulerのジョブ・リクエスト

図1-3に、次を含む重要なOracle Enterprise Schedulerコンポーネントを示します。

- スケジューラ・コンポーネント自体(ランタイム・モジュール、リクエスト・ディスパッチャ、リクエスト・プロセッサなど)

- クライアント・アプリケーション(ランタイムEJB、コールするエンド・ポイントMessage-Driven-Bean (MDB)、実行がリクエストされるジョブなど)

- Oracle Metadata Storeおよびクライアント・アプリケーション・メタデータ

- Oracle Enterprise Schedulerスキーマ(待機キュー、準備完了キュー、ジョブ履歴など)

図1-3 Oracle Enterprise Schedulerのランタイム詳細

図1-3に示すように、クライアント・アプリケーションは次のように構成されて実行されます。

1. ユーザーがクライアント・アプリケーションを操作して、ジョブ・リクエストを発行します。

2. クライアント・アプリケーションでは、そのejb-jar.xmlに2つのEJBとエンドポイントMDBを指定します。次に、これらのBeanはクライアント・アプリケーション・コンテキストでインスタンス化されます。

3. アプリケーション・コンテキストのBeanが、基礎となるOracle Enterprise Schedulerモジュールに接続します。ランタイムEJBによって、Oracle Enterprise Schedulerの基礎となるランタイム・モジュールにジョブ・リクエストが送信されます。

4. ランタイム・モジュールがOracle MDSのクライアント・アプリケーション・メタデータにアクセスします。

5. ランタイム・モジュールでは、Oracle Enterprise Schedulerスキーマ内の待機キューに、リクエストとそのメタデータおよびスケジュールを維持します。

6. Oracle Enterprise Schedulerのリクエスト・ディスパッチャにより、ジョブ・リクエストを実行する適正な時間が、その対応するスケジュールに基づいて決定されます。このとき、リクエスト・ディスパッチャにより、リクエストがOracle Enterprise Schedulerスキーマの準備完了キューに移動されます。

7. Oracle Enterprise Schedulerリクエスト・プロセッサにより、処理されるジョブ・リクエストが準備完了キューから取得されます。

8. リクエスト・プロセッサにより、メッセージがエンドポイントMDBを使用したアプリケーションに送信されます。

9. Oracle Enterprise Schedulerにより、スケジュールされたジョブが実行されます。

ほとんどの場合、または少なくとも簡略化されたケースでは、このアプリケーションはリクエストを発行したアプリケーションと同じです。

1.2.4 統合ステップの概要

基本的なOracle WebLogic Serverインスタンスをインストールした後、次の手順を実行して、Oracle Enterprise Schedulerを設定します。

1. Oracle Enterprise Schedulerを構成します。

2. ジョブ定義および他の必要なメタデータを含むクライアント・アプリケーションを開発します。

3. クライアント・アプリケーションをデプロイします。

4. クライアント・アプリケーションを起動してジョブ・リクエストを発行します。これにより、Oracle Enterprise Schedulerがコールされます。

5. クライアント・アプリケーションを起動してジョブ・リクエストのステータスまたは他の履歴を確認します。これにより、Oracle Enterprise Schedulerがコールされます。または、Fusion Middleware Controlを使用して、指定されたジョブ・リクエストのステータスを確認します。

1.3 Oracle Enterprise Schedulerを使用した定率スケジューリング

Oracle Enterprise Schedulerでは、繰返しジョブ・リクエストのインスタンスが、スケジュールされた最初の実行時間から開始して、定率で実行される定率スケジューリングがサポートされています。

各ジョブ・リクエストは、スケジュールの絶対時間にできるかぎり近くなるよう実行されます。Oracle Enterprise Schedulerでは、繰返しリクエストの実行中のジョブ・リクエストは、どの時点においても必ず1つのみとなります。ジョブ・リクエストが、次のジョブ・リクエストのスケジュールされた実行時間を超過して実行されると、次のジョブ・リクエストは遅延し、前のジョブ・リクエストが完了するとすぐにディスパッチされます。

ジョブ・リクエストがディスパッチされると、次のリクエストは待機キューに置かれます。次のジョブ・リクエストの実行時間は、スケジュール内の現在の時間以降の次の時間となります。Oracle Enterprise Schedulerは、過去の時間帯をスキップします。

実行される時間およびリクエストされた日付や繰返し終了日付に関係なく、繰返しリクエストのすべてのインスタンスを実行することが望ましい場合、リクエストによって、システム・プロパティEXECUTE_PASTを設定する必要があります。

Oracle Enterprise Schedulerでは、固定遅延スケジューリングはサポートされていません。固定遅延スケジューリングを使用すると、各リクエストは、前のリクエストが完了した後で、固定の遅延期間に実行されます。これは、1つのリクエストが遅延すると、すべての後続リクエストが同様に遅れることを意味します。それに対して、定率スケジューリングでは、リクエストが遅れた後、正しいスケジュールに戻るよう試みます。

2 ジョブ開発の計画

Oracle Enterprise Schedulerは柔軟であり、実装およびデプロイメント・オプションが用意されています。より簡単に実装でき、すぐに利用できるコンポーネントを使用するオプションや、より複雑であるものの多くの部分をカスタマイズできるオプションもあります。この章では、Oracle Enterprise Schedulerデプロイメントの計画時に考慮する必要がある様々なオプションについて説明します。

この章の内容は次のとおりです。

- ジョブ開発フロー

- ホスティング・アプリケーション

- クライアント・アプリケーション

- ジョブ実装の作成

- ジョブ・メタデータの作成

2.1 ジョブ開発フロー

この項では、ジョブ開発プロセスのステップ、および各ステップで使用できるオプションについて説明します。

図2-1に、Oracle Enterprise Schedulerコンポーネントを表す図を示します。

1. ホスティング・アプリケーションを作成しデプロイします。次のオプションがあります。

- ホスティング・アプリケーションを作成するのではなく、事前デプロイ済のネイティブ・ホスティング・アプリケーションを使用します。

- Antスクリプトからホスティング・アプリケーションを生成しデプロイします。

- JDeveloperを使用して最初から作成しデプロイします。

2. UIまたはクライアント・アプリケーションを作成しデプロイします。次のオプションがあります。

- クライアント・アプリケーションでは、シン・クライアント共有ライブラリが使用されます。

- クライアント・アプリケーションでは、クライアント・ライブラリが使用されます。

- UIまたはクライアント・アプリケーションを作成するのではなく、Oracle Enterprise Manager Fusion Middleware Controlをクライアント・アプリケーションとして使用します。

3. ジョブ実装を作成しデプロイします。次のオプションがあります。

- Javaベースではないジョブの場合、Oracle Enterprise Schedulerとは無関係なジョブを実装しデプロイできます。

- Javaベースのジョブの場合、Javaクラスはカスタム・ホスティング・アプリケーションの一部である必要があります。

4. ジョブ・メタデータを作成します。次のオプションがあります。

- Oracle Enterprise Manager Fusion Middleware Controlでメタデータを定義します。

- Oracle JDeveloperを使用して、ホスティング・アプリケーションの一部としてデプロイメントの事前定義済/シード済のジョブ・メタデータを作成します。

- メタデータ・サービスAPIを使用して、ジョブ・メタデータをプログラムにより作成します。

5. 発行およびメタデータ権限をデプロイ済のジョブに指定します。次のオプションがあります。

- Oracle Enterprise Manager Fusion Middleware Controlを使用して権限を指定します。

- ホスティング・アプリケーションまたはクライアント・アプリケーションのEARデプロイメントの一部として権限をプロビジョニングします。

詳細は、「Oracle Enterprise Schedulerのセキュリティ」の章を参照してください。

図2-1 Oracle Enterprise Schedulerコンポーネント

2.2 ホスティング・アプリケーション

ジョブは、ホスティング・アプリケーションのコンテキストで実行されます。ジョブがリモートの場合(EJBなど)、ジョブはホスティング・アプリケーションで起動されます。事前デプロイ済ネイティブ・アプリケーションは使用するのに便利ですが、カスタムJavaジョブを実行できません。

事前デプロイ済ネイティブ・ホスティング・アプリケーションは、EJBやWebサービス・ジョブなどのカスタム・リモート・ジョブに適しています。事前デプロイ済ネイティブ・ホスティング・アプリケーションの詳細は、「事前デプロイ済ネイティブ・ホスティング・アプリケーションの使用」を参照してください。

JDeveloperを使用したカスタム・ホスティング・アプリケーションの開発の詳細は、「Oracle JDeveloperを使用したOracle Enterprise Schedulerアプリケーションの生成」を参照してください。

Oracle Enterprise Scheduler Antスクリプトを使用したカスタム・ホスティング・アプリケーションの開発の詳細は、「ホスティング・アプリケーションを生成するためのAntの使用」を参照してください。

2.3 クライアント・アプリケーション

クライアント・アプリケーションは、シン・クライアント共有ライブラリまたはクライアント共有ライブラリを使用するJ2EEアプリケーションです。

クライアント・アプリケーションは、次の目的で通常使用されるJ2EEアプリケーションです。

- ジョブの発行

- ステータスのリクエスト

- ジョブ出力およびログの読取り

- 場合によっては、Oracle Enterprise Schedulerがリモートで起動できるEJBジョブ実装のホスト

クライアント・アプリケーションは、ホスティング・アプリケーションと組み合せることができますが、こればベスト・プラクティスではありません。

Oracle Enterprise Schedulerサーバー以外のサーバーへのクライアント・アプリケーションのデプロイは拡張ユース・ケースであり、他のOracle埋込み製品でのみ使用可能なOracle Enterprise Scheduler内部テンプレートの使用を必要とします。

クライアント・アプリケーションでは、シン・クライアント共有ライブラリまたはクライアント共有ライブラリが使用されます。2つのライブラリの主な違いは次のとおりです。

- シン・クライアント共有ライブラリは、Oracle Enterprise Schedulerサーバーまたはデプロイ中のいずれのOracle Enterprise Schedulerデータ・ソースにも依存せず、Oracle Enterprise Schedulerデプロイメントがオプションの場合に最良です。シン・クライアント共有ライブラリは、ホスティング・アプリケーションに接続され、Oracle Enterprise Schedulerメタデータおよびランタイム・ストアにアクセスして処理を行います。

- クライアント共有ライブラリには利点があります。ライブラリにより、Oracle Enterprise Schedulerメタデータおよびランタイム・ストアへの直接アクセスが可能なため、Oracle Enterprise Schedulerサーバーは、ジョブの発行およびステータスの問合せを行うために実行中である必要がありません。クライアント・アプリケーションがOracle Enterprise Schedulerと同じWebLogic Server上に配置されている場合に使用することをお薦めします。

- シン・クライアント共有ライブラリを使用したクライアント・アプリケーションの開発は、クライアント・アプリケーションがMDSとの対話にadf-config.xmlファイルを必要とせず、クライアント共有ライブラリに必要なOracle Enterprise Scheduler EJBデプロイメント・ディスクリプタを持っているため、より簡単です。

メタデータがクライアント・アプリケーションによってデプロイメント時に自動的にプロビジョニングされない場合、シン・クライアント・アプリケーションは、Oracle Enterprise Scheduler MDSデータ・ソースに依存しません。

クライアント・アプリケーションの作成の詳細は、「シン・クライアント・アプリケーションの作成」を参照してください。

2.4 ジョブ実装の作成

非Javaベース・ジョブ、Javaベース・ジョブおよびEJBジョブに対しては、異なるジョブ実装を使用します。

Javaベースではないジョブの場合(PL/SQLおよびバイナリ・プロセス・ジョブ)、Oracle Enterprise Schedulerとは無関係なプロセス・バイナリまたはPL/SQLプロシージャを実装、設定およびデプロイできます。

Javaベースのジョブの場合、Java実装はOracle Enterprise Scheduler定義済インタフェースに準拠している必要があり、カスタム・ホスティング・アプリケーションの一部として含まれている必要があります。

EJBジョブの場合、EJBインタフェースは、Oracle Enterprise Scheduler定義済インタフェースに準拠している必要があります。インタフェースは、Oracle Enterprise Scheduler共有ライブラリ内にあります。EJBジョブ実装を作成する方法の詳細は、「EJBジョブの作成と使用」を参照してください。

SOAコンポジットのWebサービス・ジョブ実装としての使用方法の詳細は、「Webサービス・ジョブの作成と使用」を参照してください。

2.5 ジョブ・メタデータの作成

ジョブ・メタデータを作成する最も簡単な方法は、Oracle Enterprise Manager Fusion Middleware Controlを介して定義する方法です。

また、JDeveloperを使用してメタデータを作成し、これをクライアントまたはホスティング・アプリケーションの一部であるMARアーカイブに配置し、アプリケーションのデプロイ時にメタデータをMDSにデプロイすることもできます。SOA Suiteでは、メタデータが、メタデータAPIを使用して最初の使用時にプログラムにより作成されます。

メタデータAPIの詳細は、「メタデータ・サービスの使用」を参照してください。

2.5.1 発行後の自動メタデータ・リフレッシュ

Oracle Enterprise Schedulerでは、ジョブ・リクエストおよびそのすべての子によって、発行からリクエストが最終状態に到達するまで一貫したメタデータ・スナップショットが使用されることが保証されます。これは、ジョブ・リクエストの発行時に、リクエストによって使用されることが認識されているすべてのメタデータをキャッシュすることで実現されます。ただし、このキャッシュにより、長時間実行される反復リクエストが重要なメタデータ変更を使用できなくなります。非互換性が予期したとおりに機能するようにするには、新規および更新された非互換性を、以前に発行されたか新たに発行されたかにかかわらず、関連するすべてのリクエストに適用する必要があります。ジョブ・メタデータの場合、カスタマイズ可能なパラメータは変更される可能性があり、以前に発行されたリクエストに適用する必要があります。たとえば、ジョブ定義のリクエスト・カテゴリが変更された場合、作業割当てが予期したとおりに機能するように、変更を前から存在するリクエストに適用する必要があります。

これらの問題に対処するために、Oracle Enterprise Schedulerは、以前に発行された次のリクエストに対してメタデータを自動的にリフレッシュします。

- まだ実行されていないシングルトン・リクエスト

- より多くの繰返しの実行がある反復リクエスト

キャッシュされたメタデータは、ジョブ・セット・ステップやサブリクエストなど、インスタンスの親およびそのすべての子リクエストで構成されるインスタンス・リクエスト・ツリーの実行中に一貫性が維持されます。シングルトン・リクエストの場合、インスタンス・リクエスト・ツリーには、発行されたリクエストおよびすべての子リクエストが含まれます。反復リクエストの場合、各繰返しは、インスタンスの親およびそのすべての子リクエストを含むインスタンス・リクエスト・ツリーです。

3 Oracle Enterprise Schedulerのインストールおよびインストールの確認

この章では、Oracle Enterprise Schedulerが正しくインストールされたことを確認する方法について説明します。

この章の内容は次のとおりです。

- Oracle Enterprise Schedulerのインストール

- Oracle Enterprise Schedulerのインストールの検証の概要

- Oracle Enterprise Schedulerのインストールのブラウザを使用した検証方法

- Oracle Enterprise Schedulerのインストールのプログラムによる検証方法

- 実行時に行われる処理: Oracle Enterprise Schedulerのインストールの検証方法

3.1 Oracle Enterprise Schedulerのインストール

Oracle Enterprise Schedulerには独自のインストーラはありませんが、Oracle SOA Suiteなどのそれを組み込む製品のインストーラによりインストールされます。

詳細は、組込み製品のインストール・ドキュメントを参照してください。

IDEは、Oracle SOA SuiteおよびBusiness Process Management for Developersのインストールで説明されているOracle SOA Quick Start for Developersによってインストールされます。このインストーラによりIDEがインストールされ、自動的にOracle JDeveloperのために構成されます。JDeveloperを実行する前に、必ず変数MW_HOMEをIDEが必要とするミドルウェア・ホームの場所に設定します。

Oracle Enterprise Scheduler実行時コンポーネントは、埋込み製品(たとえば、インストールが「Oracle SOA SuiteおよびBusiness Process Managementのインストールおよび構成」に説明されているOracle SOA Suiteなど)のデザインタイムまたは本番インストーラによってインストールされます。埋込み製品によってOracle Enterprise Schedulerが自動的にデプロイされる場合がありますが、デプロイされない場合、Oracle Enterprise Scheduler Service Basicテンプレートを使用して、サーバーまたはクラスタにデプロイできます。次に、Oracle Enterprise Manager Plugin for ESSテンプレートをOracle Enterprise Manager Fusion Middleware Control機能用にデプロイできます。

3.1.1 ドメイン作成中のOracle Enterprise Schedulerのターゲット設定

Oracle Enterprise Schedulerを含むSOAを展開すると、ess-server1が作成され、デフォルトでESS-MGD-SVRSサーバー・グループのターゲットがess_server1に設定されます。FMW構成ウィザードの次の手順を使用すると、Oracle Enterprise Schedulerをsoa_server1に再度ターゲット設定できます。

1. soa_server1のESS-MGD-SVRSをチェックします。

2. ess_server1のESS-MGD-SVRSのチェックを解除します。

3. ess_server1を削除します

ウィザードの詳細は、構成ウィザードによるWebLogicドメインの作成を参照してください。

3.1.2 Oracle Enterprise SchedulerでのOWSM-PMのターゲット設定

OWSM-PMは、ドメイン内の1つのサーバーのターゲットとなることを想定しています。この要件を簡易にするため、Oracle Enterprise SchedulerのテンプレートはOWSM-PMをターゲットにしません。ドメイン内の他の製品が自動的にOWSM-PMをターゲットにしている場合は、何もすることはありません。しかし、そのドメインにOracle Enterprise Scheduler以外の管理対象サーバーが存在しない場合、またはいずれのサーバーにもOWSM-PMがない場合は、OWSM-PMを手動でターゲットにする必要があります。

3.1.2.1 OWSM-PMの手動ターゲット設定

図3-1に示すように、Fusion Middleware構成ウィザードで、管理対象サーバー、クラスタおよびコヒーレンス・チェック・ボックスを選択します。

図3-1 Fusion Middleware構成ウィザード

「管理対象サーバー」画面で、ess_server1用に「WSMPM-MAN-SVR」サーバー・グループを選択します。「ESS-MGD-SVRS」がすでに選択されているはずです。

3.2 Oracle Enterprise Schedulerのインストールの検証の概要

Oracle Enterprise Schedulerのヘルス・チェックを使用すると、Webブラウザを使用してOracle Enterprise Schedulerのインストールを検証できます。

ヘルス・チェックWebページにより、Oracle Enterprise Schedulerが想定どおり機能することを検証するためにスケジュールされた単純なジョブが発行されます。

3.3 Oracle Enterprise Schedulerのインストールのブラウザを使用した検証方法

ブラウザを使用して、Oracle Enterprise Schedulerのインストールを検証できます。

Webブラウザで、Javaヘルス・チェック・サーブレットにアクセスします。ヘルス・チェック・ページにアクセスできるのは、管理者権限のあるユーザーのみです。

Oracle Enterprise Schedulerのインストールを検証する手順は、次のとおりです。

1. Webブラウザで次のURLを入力します。

http://<hostName>:<port>/EssHealthCheck/checkHealth.jsp

ここで、hostNameはOracle Enterprise Schedulerがインストールされているサーバーであり、portはポート番号です。

Oracle Enterprise Schedulerクラスタを検証するには、次のURLを使用します。

http://<hostName>:<port>/EssHealthCheck/diagnoseHealth.jsp

図3-2に示すように、Oracle Enterprise Schedulerの診断ヘルス・チェック・ページが表示されます。

図3-2 診断ヘルス・チェック・ページ

2. Oracle WebLogic Serverの管理者ユーザー名およびパスワードを使用して、診断サーブレットにログインします。

3. ヘルス・チェック・ボタンをクリックして、インストールを検証します。

3.4 Oracle Enterprise Schedulerのインストールのプログラムによる検証方法

アプリケーションからプログラムによりヘルス・チェック・サーブレットにアクセスして、Oracle Enterprise Schedulerのインストールを検証できます。

ヘルス・チェック・ページにアクセスできるのは、管理者権限のあるユーザーのみです。

Oracle Enterprise Schedulerのインストールをプログラムにより検証する手順は、次のとおりです。

1. 次のURLにアクセスします。

http://<hostName>:<port>/EssHealthCheck/checkHealth

ここで、hostNameはOracle Enterprise Schedulerがインストールされているサーバーであり、portはポート番号です。

2. 表3-1に示すように、HTTPレスポンス・コードを使用して、Oracle Enterprise Schedulerのインストールのヘルスを測定します。

表3-1 HTTPレスポンス・コード

レスポンス・コード

Oracle Enterprise Schedulerステータス・コード

備考

200(OK)

Oracle Enterprise Schedulerは起動され実行中です。

テスト・ジョブが発行され、デフォルトの期間内に成功しました。

202(ACCEPTED)

Oracle Enterprise Schedulerは起動され実行中ですが、処理の遅延が発生しました。

202 (SC_ACCEPTED)の値は、リクエストに対する操作が行われているが、処理がまだ完了していないことをクライアントに示しています。

テスト・ジョブは発行されましたが、デフォルトの期間内に完了できませんでした。

500 (INTERNAL_SERVER_ERROR)

Oracle Enterprise Schedulerのインストールにエラーがあります。

ジョブの発行または実行中にエラーが発生しました。

3.5 実行時に行われる処理: Oracle Enterprise Schedulerのインストールの検証方法

ヘルス・チェック・サーブレットにより、HTTPリクエストの一部としてOracle Enterprise Schedulerを使用したジョブがスケジュールされ、終了状態になるまで、または10秒間実行されるまでジョブを待機します

ヘルス・チェック・サーブレットにより、HTTPリクエストの一部としてOracle Enterprise Schedulerを使用した単純なジョブがスケジュールされます。数秒後、サーブレットによりRuntimeServiceBean.getRequestState()がコールされ、ジョブのステータスが確認されてサーブレット・コード内でレスポンス・メッセージが作成されます。その後、サーブレットはジョブの成功または失敗を示すレスポンスを返します。

サーブレットは、ジョブが終了状態に到達するか、または10秒間実行されるか、そのいずれか最初に発生した状況を待機します。

- ジョブが10秒未満で終了状態に到達した場合、ジョブの状態は成功となります。

- ジョブの終了状態が10秒以内に変更しない場合、ジョブの状態は成功となります。ただし、ジョブは実行されていないジョブとしてリストされます。これは、ジョブの実行にいくらか時間がかかることがあり、システムがオーバーロードされている場合があるためです。

- ジョブの発行または実行で問題が発生すると、ジョブの状態は失敗となります。

4 事前デプロイ済のネイティブ・ホスティング・アプリケーションの使用

事前デプロイ済ネイティブ・ホスティング・アプリケーションは、Oracle Enterprise Schedulerの一部として含まれます。独自のカスタム・ホスティング・アプリケーションを作成する必要がないため、Oracle Enterprise Schedulerの起動および実行のプロセスが大幅に簡略化されます。

Oracle Enterprise Schedulerは柔軟であり、実装およびデプロイメント・オプションが用意されています。「ジョブ開発の計画」は、ジョブ開発およびデプロイメント・プロセスの計画方法の概要を説明しています

この章の内容は次のとおりです。

- 概要

- プロパティ

- メタデータ

- セキュリティ権限

4.1 概要

事前デプロイ済ネイティブ・ホスティング・アプリケーションは、独自のカスタム・ホスティング・アプリケーションの開発に代わる便利な手段で、Javaベースのジョブ以外のすべてのジョブを実行するのに使用できます。

事前デプロイ済ネイティブ・ホスティング・アプリケーションは、Oracle Enterprise Schedulerサーバー上のOracle Enterprise Schedulerコアとともに配置されます。事前デプロイ済ネイティブ・アプリケーションは、ドメイン内の1つのクラスタにのみデプロイできます。Enterprise Scheduler Basicテンプレートでは、事前デプロイ済ネイティブ・ホスティング・アプリケーションが、スケジューラ・サーバー・コンポーネントとともにデプロイされるため、ドメイン内の1つのクラスタにのみターゲット設定できます。

事前デプロイ済ネイティブ・ホスティング・アプリケーションでは、次のJNDI名にマップされているOracle Enterprise Scheduler Beanのリモート・インタフェースを公開しています。

- ランタイム・サービスBean: java:comp/env/essnative/runtimeservice

- メタデータ・サービスBean: java:comp/env/essnative/metadataservice

- 非同期リクエストBean: java:comp/env/essnative/asyncrequest

ユーザーが他のホスティング・アプリケーションを使用している場合、weblogicのejb-jar.xmlで宣言することによりBeanは前述の方法で公開されます。

4.2 プロパティ

事前デプロイ済のネイティブ・ホスティング・アプリケーション・プロパティには、プロパティとそのデフォルト設定が示されます。

表4-1 事前デプロイ済ネイティブ・ホスティング・アプリケーションのプロパティ

プロパティ名

値

PolicyStripe

EssNativeHostingApp

LogicalAppName

EssNativeHostingApp

J2ee App Name

EssNativeHostingApp

RuntimeService EJB JNDI name

essnative/runtimeservice

MetadataService EJB JNDI name

essnative/metadataservice

AsyncRequestBean JNDI name

essnative/asyncrequest

MDS Partition

essUserMetadata

MDS namespace

/oracle/apps/ess

4.3 メタデータ

通常、ホスティング・アプリケーションには、MDSにロードされるMARメタデータが含まれますが、MARアーカイブを事前デプロイ済ネイティブ・ホスティング・アプリケーションに直接追加できません。

事前デプロイ済ネイティブ・ホスティング・アプリケーションにデプロイするMARアーカイブがある場合、クライアント・アプリケーションを介するかメタデータAPIを使用してデプロイする必要があります(「メタデータ・サービスの使用」を参照)。

Oracle Enterprise Schedulerでは、ネイティブ・ホスティング・アプリケーションのストライプをOPSSに登録することにより、これをプロモートします。次に、Oracle Enterprise Manager Fusion Middleware Controlおよびその他のMBeanから表示可能な状態でストライプが公開されます。アプリケーション・ロールおよびポリシーは、ネイティブ・ホスティング・アプリケーション内のメタデータに対して実行時に構成できます。

4.4 セキュリティ権限

権限を、事前デプロイ済ネイティブ・ホスティング・アプリケーションによって実行されるすべてのジョブに対して付与する必要があります。

デフォルトで、EssNativeHostingAppは、SOAおよびService Busで定義されている権限のサポートを拡張します。これは、値EssNativeHostingApp、soa-infra、Service_Bus_Consoleで指定されたプロパティHostingAppPolicyStripeを使用してess-config.xml内で構成されます。

別の製品(SOAまたはService Bus以外)でOracle Enterprise Schedulerをインストールした場合、Oracle Enterprise SchedulerまたはWLSTスクリプトを使用して、ストライプのこのプロパティ・リストを拡張する必要があります。

4.4.1 ポリシー・ストライプの構成

EssNativeHostingAppセキュリティ・ポリシー・ストライプは、ess-config.xmlファイルをカスタマイズして構成します。Oracle Enterprise Schedulerプロパティ名は、HostingAppPolicyStripeです。次の例は、WLSTコマンドを使用して、ポリシー・ストライプ値を確認し変更する方法を示しています。

現在のポリシー・ストライプの値を確認します。

oracle_common/bin/essManageRuntimeConfig.sh \
-u weblogic -p welcome1 -P 7001 -H localhost -s ess_server1 \
-A EssNativeHostingApp -n HostingAppPolicyStripe -t ESS

ポリシー・ストライプの値を変更します。

oracle_common/bin/essManageRuntimeConfig.sh \
-u weblogic -p welcome1 -P 7001 -H localhost -s ess_server1 \
-m -A EssNativeHostingApp -n HostingAppPolicyStripe -t ESS
-v MyPolicyStripe

WLSTコマンドの詳細は、Oracle Fusion Middleware SOA Suite WLSTコマンド・リファレンスを参照してください。

4.4.2 複数のアプリケーション・ストライプのサポート

事前デプロイ済ネイティブ・ホスティング・アプリケーションは、複数のストライプをサポートしています。事前デプロイ済ネイティブ・ホスティング・アプリケーションのポリシー・ストライプは、SOAおよびService Busアプリケーション用に事前構成されています。

<EssProperty key="HostingAppPolicyStripe"
value="EssNativeHostingApp,soa-infra,Services_Bus_Console"/>

Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTを使用して、ポリシー・ストライプをHostingAppPolicyStripeプロパティの値に付加し、このストライプ・リストを拡張できます。また、Oracle Enterprise Manager Fusion Middleware Controlの「アプリケーション・プロパティ」ページを使用して、事前デプロイ済ネイティブ・ホスティング・アプリケーションのHostingAppPolicyStripeプロパティを変更することもできます。

このプロパティは、事前デプロイ済ネイティブ・ホスティング・アプリケーションの構成ファイルにのみ適用できます。事前デプロイ済ネイティブ・ホスティング・アプリケーションのejb-jar.xmlファイル内にはポリシー・ストライプの静的定義がないため、HostingAppPolicyStripeプロパティで指定されている既存のポリシー・ストライプを保持する必要があることに注意してください。

5 ホスティング・アプリケーションを生成するためのAntの使用

この章では、Oracle Enterprise Schedulerに含まれているbuild.xmlファイルのAntターゲットを使用して、Javaジョブで使用するホスティング・アプリケーションを作成する方法について説明します。

これらのターゲットを使用して、Oracle JDeveloperワークスペースでアプリケーション・アーティファクトを作成したり、Javaジョブ実装用のテンプレートを作成したり、アプリケーションとJavaジョブの両方を(共有ライブラリとして)パッケージ化およびデプロイできます。

ここで説明するAntターゲットでは、ユーザーがジョブを操作できるクライアント・ユーザー・インタフェースを作成しません。クライアント・タスクを実行する場合は、Fusion Middleware Controlを使用するか、またはOracle JDeveloperでクライアント・ユーザー・インタフェースを開発できます。また、一般的にカスタム・ホスティング・アプリケーションには、アプリケーションのデプロイ時にパッケージ化されメタデータ・リポジトリにデプロイされるメタデータがシードされています。カスタム・ホスティング・アプリケーションを生成するAntベースのスクリプトは、メタデータ・アーティファクトを作成する手段を提供しません。このため、ホスティング・アプリケーションを生成した後、このアプリケーションをサーバーにデプロイする前にOracle JDeveloperでワークスペース(.jws)を開き、必要なメタデータを追加する必要があります。

アプリケーションおよび共有ライブラリを作成およびデプロイすると、JDeveloperまたはEnterprise Managerを使用して、デプロイされた出力にメタデータを関連付けることができます。

この章の内容は次のとおりです。

- Antを使用したホスティング・アプリケーションの生成の概要

- ホスティング・アプリケーションの作成およびデプロイ用のAntターゲット

- Antを使用したホスティング・アプリケーションおよびプロジェクト・ワークスペースの作成

- Antを使用した共有ライブラリとしてのJavaジョブの作成

- Antを使用したJavaジョブの共有ライブラリとしてのパッケージ化

- Antを使用した共有ライブラリのデプロイ

- Antを使用したホスティング・アプリケーションのパッケージ化

- Antを使用したホスティング・アプリケーションのデプロイ

- 生成されたAntターゲットの構成

5.1 Antを使用したホスティング・アプリケーションの生成の概要

Oracle Enterprise Schedulerには、ホスティング・アプリケーションの実行に必要な基本アーティファクトの生成に使用できるAntビルド・ファイル、およびデプロイしてアプリケーションで実行できるJavaジョブが含まれています。

組込みAntビルド・ファイルを使用して、ホスティング・アプリケーションを生成します。実行時に、Javaジョブ用のアーティファクトの生成や、生成したコンポーネントのビルドおよびデプロイに使用できるターゲットが含まれた、別のAntビルド・ファイルも生成します。

アプリケーションおよび共有ライブラリを作成およびデプロイすると、JDeveloperまたはEnterprise Managerを使用して、デプロイされた出力にメタデータを関連付けることができます。

また、生成されたbuild.propertiesファイルを使用すると、ターゲットが実行時に使用する変数の値を設定してAntが行う作業をカスタマイズすることもできます。

この章で説明している手順には、Antで実行できる次のことが含まれています。

1. ジョブを実行できるホスティング・アプリケーションを作成します。組込みbuild.xmlファイル内のcreate-user-homeを使用します。

2. IDEでのアプリケーション・アーティファクトの編集に使用できるJDeveloperプロジェクト・ワークスペースを作成します。これは、ホスティング・アプリケーションの作成時に行われます。

3. アプリケーションの一部をビルドおよびデプロイするためのターゲットが含まれたAntビルド・ファイルを作成します。

4. ビジネス・ロジックを追加できるJavaジョブ・テンプレートを作成します。生成されたbuild.xmlファイル内のcreate-new-job-defターゲットを使用します。

5. 実装されたJavaジョブを共有ライブラリとしてパッケージ化します。生成されたbuild.xmlファイル内のpackage_essjob_libraryターゲットを使用します。

6. 共有ライブラリをホスティング・アプリケーションにデプロイします。生成されたbuild.xmlファイル内のdeploy_essjob_libraryターゲットを使用します。

7. ホスティング・アプリケーションをパッケージ化します。生成されたbuild.xmlファイル内のpackage_hosting_appターゲットを使用します。

8. ホスティング・アプリケーションをデプロイします。生成されたbuild.xmlファイル内のdeploy_hosting_appターゲットを使用します。

5.1.1 Antビルド・ファイルを使用するための前提条件

提供されたビルド・ファイルまたは生成されたビルド・ファイルを使用する前に、次の前提条件を満たしていることを確認してください。

- Antがインストール済であり、ANT_HOME変数が適切に設定されており、PATHがantのbinディレクトリを指すように設定してある必要があります。

- Oracle JDeveloperをインストールおよび設定する必要があります。PATH変数には、jdevコマンドをコマンド・プロンプトから実行できるようにOracle JDeveloper binディレクトリが含まれている必要があります。

5.2 ホスティング・アプリケーションの作成およびデプロイ用のAntターゲット

Oracle Enterprise Schedulerには、ジョブを実行できるホスティング・アプリケーションをデプロイするのに役立つ、Antビルド・ファイルが含まれています。

ただし、実際にはこのジョブを完了するには、2つのビルド・ファイルを使用します。その1つはOracle Enterprise Schedulerに含まれており、もう1つは組込みビルド・ファイル内のターゲットにより生成されます。次の表では、これら2つのファイルにデフォルトで含まれているターゲットをリストして説明します。

デフォルトでは、組込みbuild.xmlファイルはOracle Enterprise Schedulerのextensibility_scriptsディレクトリにあります。たとえば、Oracle JDeveloperインストールでは、MW_HOME/oracle_common/ess/extensibility_scripts/build.xmlにあり、Oracle Enterprise Schedulerなどの製品のインストールでは、ORACLE_HOME/extensibility_scriptsディレクトリにあります。

表5-1 組込みビルド・ファイル内のAntターゲット

Antターゲット

説明

create-user-home

ユーザー・ホームを作成するためのデフォルト・ターゲットです。

help-create-user-home

ユーザー・ホームの作成に関するヘルプです。

組込みbuild.xmlファイルのcreate-user-homeターゲットを実行した場合、ターゲットのアクションの1つとして、別のbuild.xmlファイルが作成されます。そのファイルには、アプリケーション用のアーティファクトを作成、ビルドおよびデプロイするために使用できる次のターゲットが含まれています。

表5-2 生成されたビルド・ファイル内のAntターゲット

Antターゲット

説明

build_ears

ジョブ共有ライブラリおよびホスティング・アプリケーションをパッケージ化します。

create-new-job-def

Javaジョブを共有ライブラリとして作成します。

deploy

ジョブ・ライブラリおよびホスティング・アプリケーションをパッケージ化およびデプロイします。

deploy_essjob_library

Javaジョブ共有ライブラリをデプロイします。

deploy_hosting_app

ホスティング・アプリケーションをデプロイします。

deploy_job_logic

ジョブ共有ライブラリをパッケージ化およびデプロイします。

package_essjob_library

Javaジョブを共有ライブラリとしてパッケージ化します。

package_hosting_app

ホスティング・アプリケーションをパッケージ化します。

5.3 Antを使用したホスティング・アプリケーションおよびプロジェクト・ワークスペースの作成

Oracle Enterprise Schedulerに含まれているbuild.xmlファイル内のcreate-user-home Antターゲットを実行して、ホスティング・アプリケーションを作成できます。

スクリプトが正常に完了すると、パッケージ化およびデプロイ可能なホスティング・アプリケーション用アーティファクトが作成されます。これらのアーティファクトは、指定したターゲット・ディレクトリのJDeveloper互換ワークスペース内に生成されます。作成されたワークスペースにはbuild.xmlが含まれており、これを使用して、ホスティング・アプリケーションおよび生成されたJavaジョブを共有ライブラリとしてビルド、パッケージ化およびデプロイできます。

ターゲットが実行されるとき、ターゲットの作業のガイドとなる詳細を入力することを要求されます。これらの詳細には、ターゲットの作業について意図されている環境(特定のアプリケーションで実行するなど)、新しいアプリケーションの名前、ターゲット・ディレクトリなどが含まれます。

開始する前に、Antターゲットによって要求される次の情報を用意しておきます。

表5-3 Antターゲットで必要な情報

入力プロンプト

説明

使用するテンプレート

可能な値はFusionおよびStandaloneです。Oracle Fusion Applicationsで使用するために開発している場合は、ここでFusionと入力します。

Oracle Fusion Applicationsで使用するための開発でない場合は、Standaloneと入力します。

Oracle Fusion Applicationsコンテキストとスタンドアロン・コンテキストとの間には重要な相違があります。たとえば、Oracle Fusion Applicationsコンテキストでは、ターゲットはわずかに異なるホスティング・アプリケーションおよびクライアント・アプリケーションを生成します。

ミドルウェア・ホーム・ディレクトリ・パス

Oracle Enterprise Schedulerが(多くの場合、埋め込まれている別の製品により)インストールされたときに作成されたミドルウェア・ホーム・ディレクトリです。サポート・ライブラリの場所は、このディレクトリに対して相対的な場所にあります。

この機能は、ojdeployユーティリティを使用してアーティファクトを作成およびパッケージ化し、サーバーにデプロイします。binディレクトリにojdeployを含むOracle JDeveloperディレクトリがミドルウェア・ホーム・パスに含まれない場合、Oracle JDeveloperがインストールされるディレクトリを指定します。

ホスティング・アプリケーション名

新しいホスティング・アプリケーションに付ける名前です。

ホスティング・アプリケーションJPSストライプID

ストライプは、アプリケーションで使用するポリシー・ストア内の値のサブセットを定義するセキュリティ構成です。実行時に、アプリケーションに適用可能なポリシーのセットを決定します。多くの場合、アプリケーション名が使用されます。

ジョブ・ビジネス・ロジックの共有ライブラリ名

生成されたJavaジョブ・ソース・コードを配置する共有ライブラリの名前です。

アプリケーションが作成される空のディレクトリ

生成されたファイルの移動先となるディレクトリです。これは、後で使用するアーティファクト(build.xmlファイルなど)が作成されるJDeveloperワークスペースの場所となります。

Antを使用したホスティング・アプリケーションの作成手順

1. 開始するには、コンソール・ウィンドウを開き、組込みbuild.xmlがある場所にディレクトリを変更します。デフォルトでは、これはOracle Enterprise Schedulerのextensibility_scriptsディレクトリです。たとえば、MW_HOME/oracle_common/ess/extensibility_scripts/build.xmlです。

次のようなコマンドでターゲットを実行します。このターゲット名は、ビルド・ファイルのデフォルト・ターゲットであるため、省略できます。

ant

ターゲット名を使用する場合は、次のようなコマンドになります。

ant create-user-home

Antコンソール出力の次の例では、プロンプトが[input]という語で始まることに注意してください。各プロンプトで、使用する値を入力し、[Enter]を押します。

必要な情報を入力すると、ターゲットは要求したディレクトリおよびファイルを作成し、必要なファイルを新しいワークスペースにコピーし、新しいホスティング・アプリケーション用の一部の構成を設定します。

[extensibility_scripts]$ ant

Buildfile: build.xml

-init:

create-user-home:
[input] Enter which template should be used (source_template)
(default=Fusion)
[input]      ([Fusion], Standalone)
Standalone
[input] Enter Middleware Home Directory path (fmw_home_dir) (default=) []
/scratch/fmwtools/mw_home
[input] Enter hosting application name (hosting_application_name)
(default=MyAppEss) [MyAppEss]
NewDemoApp
[input] Enter hosting application JPS stripe id
(hosting_application_stripe_id) (default=MyAppEss) [MyAppEss]
NewDemoApp
[input] Do you want to add shared library for the (java) job business
logic? (use_jobdef_library) (default=yes)
[input]      ([yes], no)
no
[input] Enter an empty directory where the applications will be created
(user_home)
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[echo]
[echo]
[mkdir] Created dir:
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[propertyfile] Creating new property file:
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/template.properties
[copy] Copying 9 files to
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[copy] Copied 15 empty directories to 4 empty directories under
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[copy] Copying 1 file to
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/ant/config
[copy] Copying 1 file to
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[copy] Copying 15 files to
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[move] Moving 1 file to
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/Template_Hosting
[echo]
[echo] ========================================
[echo]
[echo] A new workspace has been created at:
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[echo] This workspace can be opened and modified using JDeveloper
[echo] To deploy the applications, run the following command:
[echo]     ant -f
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/ant/build-ess.xml
deploy
[echo] To create new jobs from predefined templates, run the following
command:
[echo]     ant -f
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/build.xml
create-new-job-def

BUILD SUCCESSFUL
Total time: 49 seconds

[extensibility_scripts]$ ant

Buildfile: build.xml

-init:

create-user-home:
[input] Enter which template should be used (source_template)
(default=Fusion)
[input]      ([Fusion], Standalone)
Standalone
[input] Enter Middleware Home Directory path (fmw_home_dir) (default=) []
/scratch/fmwtools/mw_home
[input] Enter hosting application name (hosting_application_name)
(default=MyAppEss) [MyAppEss]
NewDemoApp
[input] Enter hosting application JPS stripe id
(hosting_application_stripe_id) (default=MyAppEss) [MyAppEss]
NewDemoApp
[input] Do you want to add shared library for the (java) job business
logic? (use_jobdef_library) (default=yes)
[input]      ([yes], no)
yes
[input] Enter the shared library name for the job business logic
(jobdef_library_name) (default=MyJobsLibrary) [MyJobsLibrary]
NewDemoAppJobsLib
[input] Enter an empty directory where the applications will be created
(user_home)
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[echo]
[echo]
[mkdir] Created dir:
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[propertyfile] Creating new property file:
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/template.properties
[copy] Copying 11 files to
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[copy] Copied 25 empty directories to 9 empty directories under
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[copy] Copying 1 file to
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/ant/config
[copy] Copying 1 file to
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[copy] Copying 15 files to
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[move] Moving 1 file to
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/Template_Hosting
[echo]
[echo] ========================================
[echo]
[echo] A new workspace has been created at:
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp
[echo] This workspace can be opened and modified using JDeveloper
[echo] To deploy the applications, run the following command:
[echo]     ant -f
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/ant/build-ess.xml
deploy
[echo] To create new jobs from predefined templates, run the following
command:
[echo]     ant -f
/scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/build.xml
create-new-job-def

BUILD SUCCESSFUL
Total time: 1 minute 32 seconds

5.4 Antを使用した共有ライブラリとしてのJavaジョブの作成

新しいホスティング・アプリケーションを作成したときに生成されたビルド・ファイル内のcreate-new-job-def Antターゲットを実行して、Javaジョブ・クラス・テンプレートを作成できます。

詳細は、「Antを使用したホスティング・アプリケーションおよびプロジェクト・ワークスペースの作成」を参照してください。

ここで作成するJavaクラスは、Javaジョブを実装するロジックを追加できるテンプレートとなります。JavaジョブではJavaコードを実行します。実装されるJavaジョブに対しては、そのジョブの仕様の一部から構成されるメタデータを追加できます。

注意:

現在、このAntターゲットでは同期Javaジョブ・テンプレートのみを作成できます。

ターゲットが実行されるとき、ターゲットの作業のガイドとなる詳細を入力することを要求されます。開始する前に、Antターゲットによって要求される次の情報を用意しておきます。

表5-4 Antターゲットで必要な情報

入力プロンプト

説明

作成するジョブ定義テンプレートの数

作成するJavaジョブ実装のタイプに対応する数です。現在、この方法で作成できるのは同期Javaジョブのみであるため、サポートされている値は1のみとなります。

ジョブ定義のJavaパッケージ名

作成するJavaジョブのパッケージ名です。

ジョブ定義のJavaクラス名

作成するJavaジョブのクラス名です。

Antを使用してJavaジョブ・クラス・テンプレートを作成する手順は、次のとおりです。

1. 開始するには、コンソール・ウィンドウで、ディレクトリを、アプリケーションを作成する場所として指定したディレクトリに変更します。build.xmlファイルがそこに存在する必要があります。次のコマンドを使用して、ターゲットを実行します。

ant create-new-job-def

Antコンソール出力の次の例で、プロンプトがどこで発生するかを確認できます。情報を入力すると、ターゲットは要求されたファイルを作成し、必要なファイルを新しいワークスペースにコピーし、新しいホスティング・アプリケーション用の一部の構成を設定します。

[extensibility_scripts]$ ant -f /scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/build.xml create-new-job-def

Buildfile: /scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/build.xml

-init:

create-new-job-def:
[echo] Available Job Definition Templates:
[echo]     1) Simple Synchronous Java Job
[input] Enter number of job definition template to create (job_template_to_create)
1
[echo] Calling default target on /scratch/miscFiles/ExtnDemo/extensibility_scripts/Standalone/Template_JobLibrary/simple_synchronous_job/build.xml

-init:

create-job-definition:
[input] Enter Java package name for Job Definition (jobdef_package_name) (default=oracle.apps.ess.custom) [oracle.apps.ess.custom]
oracle.apps.ess.custom
[input] Enter Java class name for Job Definition (jobdef_class_name) (default=MySynchronousJavaJob) [MySynchronousJavaJob]
NewDemoHelloWorld
[copy] Copying 1 file to /scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/NewDemoApp/EssSharedLibrary/src
[copy] Copying 1 file to /scratch/WLServers/MW_HOME/standalone_apps/NewDemoApp/NewDemoApp/EssSharedLibrary/src/oracle/apps/ess/custom

BUILD SUCCESSFUL
Total time: 34 seconds

2. Javaジョブ用のクラス・テンプレートを作成すると、ジョブのロジックを実装するコードを追加できます。このテンプレートは、「Antを使用したホスティング・アプリケーションおよびプロジェクト・ワークスペースの作成」で、ホスティング・アプリケーションを作成したときに作成した、JDeveloperワークスペース内のプロジェクトにあります。ファイルのディレクトリ・パスは、Antコンソール出力に示されます。Javaコードを編集する場合、JDeveloperや単純なテキスト・エディタなど、希望のエディタを使用できます。

Javaファイルを開き、コードを追加して、execute()メソッドを実装します。例5-1は、どのようなコードが生成されるかを示しています。oracle.as.scheduler.Executableインタフェースのexecute()メソッドの単純な実装を、Javaジョブの作業を実行するコードに置き換えます。

例5-1 Oracle Enterprise SchedulerのHelloWorld Javaクラス

package oracle.apps.ess.custom;

import java.io.StringWriter;
import java.security.AccessControlContext;
import java.security.AccessController;
import javax.security.auth.Subject;

import oracle.as.scheduler.RequestParameters;
import oracle.as.scheduler.job.BaseSynchronousJavaJob;
import oracle.as.scheduler.request.ContentType;
import oracle.security.jps.util.SubjectUtil;

public class NewDemoHelloWorld extends BaseSynchronousJavaJob {

public NewDemoHelloWorld() {
super();
}

protected void execute() throws Exception
{
long requestId = getRequestExecutionContext().getRequestId();
RequestParameters params = getRequestParameters();
AccessControlContext accContext = AccessController.getContext();
Subject subject = Subject.getSubject(accContext);
String username = SubjectUtil.getUserName(subject);
/*
* Write contents to request log
*/
StringWriter strWriter = new StringWriter();
strWriter.write("Simple ESS Java job execution LOG");
strWriter.write("ESS Job requestID: " + requestId);
strWriter.write("Username: " + username);
writeToRequestLog(requestId, strWriter.toString());

/*
* Write Text contents to request output
*/
strWriter = new StringWriter();
strWriter.write("Simple ESS Java job execution Text Out");
strWriter.write("ESS Job requestID: " + requestId);
strWriter.write("Username: " + username);
writeToRequestOutput(requestId, strWriter.toString(), ContentType.Text);
}
}

5.5 Antを使用したJavaジョブの共有ライブラリとしてのパッケージ化

package_essjob_library Antターゲットを実行して、Javaジョブ実装をパッケージ化できます。

注意:

新しいホスティング・アプリケーションを作成すると、このターゲットが含まれたビルド・ファイルが生成されます。(詳細は、「Antを使用したホスティング・アプリケーションおよびプロジェクト・ワークスペースの作成」を参照。)

package_essjob_libraryターゲットによって、ジョブ・コードのコンパイルおよびJARが実行されます。このターゲットは、ユーザーによる入力は必要なく、単に実行されて完了します。

Antを使用してJavaジョブ・クラス実装をパッケージ化する手順は、次のとおりです。

- コンソール・ウィンドウで、ディレクトリを、ホスティング・アプリケーションを作成する場所として指定したディレクトリに変更します。次のコマンドを使用して、ターゲットを実行します。

ant package_essjob_library

5.6 Antを使用した共有ライブラリのデプロイ

deploy_essjob_library Antターゲットを実行して、Javaジョブ共有ライブラリをデプロイできます。

注意:

新しいホスティング・アプリケーションを作成すると、このターゲットが含まれたビルド・ファイルが生成されます。(詳細は、「Antを使用したホスティング・アプリケーションおよびプロジェクト・ワークスペースの作成」を参照。)

deploy_essjob_libraryターゲットは、ジョブ・ライブラリをデプロイします。このターゲットは、ユーザーによる入力は必要なく、単に実行されて完了します。

Antを使用してJavaジョブ共有ライブラリをデプロイする手順は、次のとおりです。

- コンソール・ウィンドウで、ディレクトリを、ホスティング・アプリケーションを作成する場所として指定したディレクトリに変更します。次のコマンドを使用して、ターゲットを実行します。

ant deploy_essjob_library

5.7 Antを使用したホスティング・アプリケーションのパッケージ化

package_hosting_app Antターゲットを実行して、ホスティング・アプリケーションをパッケージ化できます。

注意:

新しいホスティング・アプリケーションを作成すると、このターゲットが含まれたビルド・ファイルが生成されます。(詳細は、「Antを使用したホスティング・アプリケーションおよびプロジェクト・ワークスペースの作成」を参照。)

package_hosting_appターゲットは、create-user-homeターゲットで作成されたホスティング・アプリケーションをパッケージ化します(詳細は、「Antを使用したホスティング・アプリケーションおよびプロジェクト・ワークスペースの作成」を参照)。このターゲットは、ユーザーによる入力は必要なく、単に実行されて完了します。

Antを使用してホスティング・アプリケーションをパッケージ化する手順は、次のとおりです。

- コンソール・ウィンドウで、ディレクトリを、ホスティング・アプリケーションを作成する場所として指定したディレクトリに変更します。次のコマンドを使用して、ターゲットを実行します。

ant package_hosting_app

5.8 Antを使用したホスティング・アプリケーションのデプロイ

deploy_hosting_app Antターゲットを実行して、ホスティング・アプリケーションをデプロイできます。

注意:

新しいホスティング・アプリケーションを作成すると、このターゲットが含まれたビルド・ファイルが生成されます。(詳細は、「Antを使用したホスティング・アプリケーションおよびプロジェクト・ワークスペースの作成」を参照。)

deploy_hosting_appターゲットは、create-user-homeターゲットで作成されたホスティング・アプリケーションをデプロイします(詳細は、「Antを使用したホスティング・アプリケーションおよびプロジェクト・ワークスペースの作成」を参照)。このターゲットは、ユーザーによる入力は必要なく、単に実行されて完了します。

Antを使用してホスティング・アプリケーションをデプロイする手順は、次のとおりです。

- コンソール・ウィンドウで、ディレクトリを、ホスティング・アプリケーションを作成する場所として指定したディレクトリに変更します。次のコマンドを使用して、ターゲットを実行します。

ant deploy_hosting_app

5.9 生成されたAntターゲットの構成

ファイルuser_home/ant/config/ess-build.propertiesには、ビルド、パッケージ化およびデプロイメント時にAntスクリプトによって使用される情報を指定するための様々なパラメータが含まれています。user_homeは、アプリケーション・ワークスペースを格納するよう指定したディレクトリです。

アーカイブのデプロイメントの前に、WebLogic Serverに基づく詳細をユーザーの環境に合わせて変更する必要があります。

表5-5で説明しているビルド・プロパティを使用して、Antターゲットを独自の構成値でカスタマイズします。

表5-5 Antビルドをカスタマイズするためのビルド・プロパティ

ビルド・プロパティ

説明

customEss.hostapp.earprofile

-

customEss.hostapp.jarfile

-

customEss.hostapp.jarprofile

-

customEss.hostapp.jprproject

-

customEss.hostapp.jwsfile

-

customEss.hostapp.mds.jdbc

-

customEss.hostapp.mds.partition

-

customEss.hostapp.name

生成されたホスティング・アプリケーションに使用する名前です。

customEss.hostapp.workspace

-

customEss.project.dir

生成されたJDeveloperプロジェクトのディレクトリの場所です。

customEss.shared.library.name

生成された共有ライブラリに付けられた名前です。

ess.script.base.dir

-

fmw.home

-

jdev.home

-

oracle.common

-

ess.server.name

Oracle Enterprise Schedulerジョブ・ライブラリおよびホスティング・アプリケーションがデプロイされるOracle Enterprise Schedulerの管理/管理対象サーバーのカンマで区切られた名前。

weblogic.admin.user

WebLogic Serverの管理ユーザー名。

weblogic.server.host

-

weblogic.server.port

-

weblogic.server.ssl.port

-

weblogic.t3.url

-

# ESS build properties
ess.script.base.dir=${user_home}

fmw.home=${fmw_home}
jdev.home=${fmw.home}/jdeveloper
oracle.common=${fmw.home}/oracle_common

# ========== ESS JDev project details ===============
customEss.project.dir=${ess.script.base.dir}

customEss.hostapp.workspace=${hosting_application_name}
customEss.hostapp.jwsfile=${hosting_application_name}
customEss.hostapp.earprofile=${hosting_application_name}
customEss.hostapp.jprproject=EssSharedLibrary
customEss.hostapp.jarprofile=EssSharedLibrary
customEss.hostapp.jarfile=${jobdef_library_name}

customEss.shared.library.name=${jobdef_library_name}

customEss.hostapp.mds.partition=${hosting_application_name}
customEss.hostapp.mds.jdbc=mds-ESS_MDS_DS
customEss.hostapp.name=${hosting_application_name}

# ========== Weblogic Server details ===============
MW_HOME=${fmw.home}
ORACLE_HOME=${jdev.home}
MW_ORA_HOME=${jdev.home}
COMMON_COMPONENTS_HOME=${oracle.common}
WEBLOGIC_HOME=${fmw.home}/wlserver_10.3
weblogic.server.host=adc2170657.example.com
WEBLOGIC_HOME=${fmw.home}/wlserver_10.3
weblogic.server.host=adc2170657.example.com
weblogic.server.port=7001
weblogic.server.ssl.port=7002
weblogic.admin.user=weblogic
weblogic.t3.url=t3://${weblogic.server.host}:${weblogic.server.port}
# Comma separated names of ess admin/managed servers to which essjob library and    hosting app is deployed
ess.server.name=AdminServer

6 シン・クライアント・アプリケーションの作成

通常、シン・クライアント・アプリケーションは、ジョブの発行、ステータスの問合せに使用され、オプションでEJBジョブ実装のホストに使用されます。シン・クライアント・アプリケーションでは、Oracle Enterprise Scheduler APIにOracle Enterprise Schedulerシン・クライアント・ライブラリが使用されます。この章では、シン・クライアント・ライブラリおよびOracle JDeveloperを使用したシン・クライアント・アプリケーションの開発方法について説明します。

この章の構成は、次のとおりです。

- 概要

- 実装

- JDeveloperを使用したMARデプロイメント用のシン・クライアント・アプリケーションのビルド

- JDeveloperを使用したEJBおよびそのジョブ定義メタデータの作成および構成

6.1 概要

クライアント・アプリケーションは、Oracle Enterprise Schedulerと同じWebLogicドメインで実行されるJ2EEアプリケーションです。

クライアント・アプリケーションは、Oracle Enterprise Scheduler APIを使用して次の処理を実行できます。

- ジョブの発行

- ジョブ・ステータスの問合せ

- ジョブ出力およびログの参照

- オプションで、Oracle Enterprise Schedulerメタデータの更新の実行

- Oracle Enterprise Schedulerがリモートで起動するEJBジョブ実装のホスト

Oracle Enterprise Schedulerシン・クライアント・ライブラリは、Oracle Enterprise Scheduler API(メタデータ・サービスAPIまたはランタイム・サービスAPIなど)にアクセスするためにクライアント・アプリケーションによって使用されます。シン・クライアント・ライブラリは、リモートでOracle Enterprise Schedulerホスティング・アプリケーションを起動し、すべての操作を実行するシン・レイヤーです。オプションで、シン・クライアント・アプリケーションには、Oracle JDeveloperを使用して開発されたOracle Enterprise Schedulerメタデータを含むOracle Enterprise SchedulerメタデータMARアーカイブが含まれる場合があります。このメタデータは、アプリケーションのデプロイ時、Oracle Enterprise Scheduler MDSに自動的にロードされます。または、アプリケーションは、APIを使用してメタデータを動的に作成できます。

シン・クライアント共有ライブラリは、クライアント共有ライブラリと次の点で異なります。

- クライアント共有ライブラリには、MDSおよびランタイム・データベースに直接アクセスすることで、すべてのOracle Enterprise Schedulerの作業を実行するローカルEJBが含まれます。シン・クライアント・ライブラリには、データ・ソースおよびEJBは含まれませんが、EJBをホストしデータベースにアクセスするホスティング・アプリケーションにリモートでアクセスします。

- シン・クライアント・ライブラリは、Oracle Enterprise Schedulerの内部機能をアプリケーションに対してより巧みに非表示にします。

- データベースに直接アクセスするため、Oracle Enterprise Schedulerサーバーまたはクラスタが停止している場合でもクライアント共有ライブラリは機能します。

- シン・クライアント・ライブラリは、Oracle Enterprise Schedulerのデプロイメントが埋込み製品のオプションの場合も便利です。

- クライアント共有ライブラリによって公開されているすべてのドキュメント化済APIは、シン・クライアント・ライブラリで使用可能です。したがって、シン・クライアント・アプリケーションは次の処理を行えます。

- ランタイム・サービスAPIを使用したリクエストの発行

- ランタイム・サービスAPIを使用したリクエストの操作

- メタデータ・サービスAPIを使用したメタデータ・アーティファクトの更新

- 非同期リクエストのリモートでの完了

- シン・クライアント・ライブラリは、リモートでOracle Enterprise Schedulerホスティング・アプリケーションを起動し、すべての操作を実行するため、ローカルBeanではなく、リモートOracle Enterprise Scheduler Beanを参照する必要があります。リモートOracle Enterprise SchedulerサーバーのInitialContextの取得にはオーバーヘッドがあります。RemoteConnector APIは、Oracle Enterprise Scheduler Beanのコールバックに対して次のような支援を提供します。

- ヘルパー・クラスは、RemoteConnectorsを使用してOracle Enterprise Scheduler Bean (RuntimeService、MetadataServiceなど)に簡単に接続し返します。

- ログおよび出力は、リモート実装から処理できます。

- 非同期リクエストを簡単に完了できます。

- 起動およびコールバックを保護できます。

6.2 実装

このトピックでは、シン・クライアント・ライブラリを使用してリモートEJBジョブを実装する際に考慮する点をいくつか示します。

シン・クライアント・ライブラリを使用してリモートEJBジョブを実装する際は、次のことを考慮します。

- Beanが、実行のみのRemoteExecutableインタフェース、または実行と取消しの両方の操作のRemoteCancellableExecutableインタフェースを実装していることを確認します。

- SOA_BEAN_NAMEなどの固有のプロパティを定義するのではなく、EJB_OPERATION_NAMEなどの事前定義済システム・プロパティを使用します。

- ejb-jar.xmlファイルは、oracle.security.jps.ee.ejb.JpsInterceptorインターセプタを定義する必要があります。インターセプタを使用して、Oracle Enterprise Schedulerレイヤーから伝播されたサブジェクトを取得し、他の操作で使用します。

- ジョブ・ロジックが変更されたときにEJBが再デプロイされないようにするために、ジョブ実装をejb-jar.xmlファイルから移動させておくことが最善の方法です。

ヒント:

JNDIコンテキストが渡された値で作成できない場合、アプリケーションはjavax.naming.NamingException例外をスローします。または、資格証明キーストアを含む参照で問題が発生した場合、ScehdulerException例外がスローされる場合もあります。

6.2.1 保護された起動

リモートEJBの保護された起動は、そのサーバーのJNDIツリーが認証されている場合に必須です。これは、リモートEJBが保護された参照を使用してOracle Enterprise Scheduler EJBをコールバックする場合も同様です。次の各項で、ガイドラインを示します。

6.2.1.1 転送起動

次の内容が転送起動に適用されます。

- Oracle Enterprise SchedulerがリモートEJBを起動する場合、実行ジョブのサブジェクトは常に伝播されます。

- Oracle Enterprise Schedulerがジョブを実行する際、現在のOracle Enterprise Scheduler ServerのJndiProviderUrlはRequestParametersを介してリモートEJBに常に提供されます。

- リモート・サーバーのJNDIツリーが認証されている場合、JNDI_CSF_KEYプロパティをリクエスト・パラメータまたはホスティング・アプリケーションのEssConfigurationで指定する必要があります。

- Oracle Enterprise Schedulerは、CsfKeyのキーストアを参照してPasswordCredentialを取得し、リモート・サーバーに接続します。

6.2.1.2 コールバック起動

次の内容がコールバック起動に適用されます。

- リモートEJBがOracle Enterprise SchedulerのBeanにコールバックする必要がある場合、次のプロパティを指定できます。

- HostingAppで公開されているOracle Enterprise SchedulerのRuntime、MetadataおよびAsyncRequest BeanのJNDI名は、リクエスト・パラメータまたはホスティング・アプリケーションのEssConfigurationで指定する必要があります。EssNativeHostingAppが使用されている場合、これらのエントリは必要がありません。

- Oracle Enterprise SchedulerサーバーのJNDIツリーが認証されている場合、ESS_JNDI_CSF_KEY_NAMEプロパティをリクエスト・パラメータまたはホスティング・アプリケーションのEssConfigurationで指定する必要があります。Oracle Enterprise Schedulerにより、このプロパティがRequestParametersを介してリモートEJBで使用可能になります。

- リモートEJBは、RemoteConnector APIを使用して、 Oracle Enterprise Scheduler Beanのリモート・インスタンスを取得できます。これは、次を渡すことで実行できます。

- RequestParameters

- BeanのRequestParametersおよびJndiMappedName (ネイティブ・ホスティング・アプリケーション以外のホスティング・アプリケーション用)

- RequestParameters、ユーザー名およびパスワード(Oracle Enterprise Schedulerサーバーが認証されている場合)

- InitialContext (主にEssNativeHostingAppを伴うJava SEクライアント用)

- InitialContextおよびjndiMappedName (主にその他のホスティング・アプリケーションを伴うJava SEクライアント用)

6.2.2 RemoteConnector APIおよびサーバー・アフィニティ・プロパティ

コードの実装がOracle Enterprise Scheduler EJBへのアクセスに依存している場合、RemoteConnector APIクラスで公開されているメソッドを使用します。Oracle Enterprise Schedulerでは、JNDIルックアップを実行する前にサーバー・アフィニティ・プロパティをInitialContext環境で設定する必要があり、RemoteConnector APIクラスがこのプロパティを設定します。これは、マルチノード・クラスタ・シナリオで特に重要です。RemoteConnectorクラスは、Oracle Enterprise Schedulerクライアント・ライブラリでパッケージ化されています。

何らかの理由でRemoteConectorクラスを使用できない場合、次の例に示すように、Oracle Enterprise Scheduler EJBの参照を実行する前に環境マップ・プロパティをInitialContextに設定できます。

if(PlatformUtils.isWebLogic())
envProps.put("weblogic.jndi.enableServerAffinity", "true");

マルチノード・クラスタ環境では、クラスタ・アルゴリズムをラウンドロビン・アフィニティに設定するのが最適です。

6.2.3 例

この項では、シン・クライアント・ライブラリの使用方法を表す例を示します。

6.2.3.1 RemoteConnectorを使用するJava EEアプリケーション

次のコードの例は、事前デプロイ済のネイティブ・ホスティング・アプリケーションを介してRemoteConnectorを使用するJava EEアプリケーションからのスニペットを示しています。

RemoteConnector essConnector = newRemoteConnector();
//RequestParameters contains the JndiProviderURL of Oracle Enterprise Scheduler
//Server which is auto-populated from the Oracle Enterprise Scheduler end while
//invoking an EJB. The CSF key is auto-populated in RequestParameters from the
//Oracle Enterprise Scheduler end if configured for the
//Oracle Enterprise Scheduler Server and specified in the EssConfig of HostingApp.
//If CSF key is present, the CSF lookup is done from RemoteConnector to resolve
//authentication.

RuntimeService rts = essConnector.getRuntimeServiceEJB(requestParameters);

//Sample invocation using RuntimeServiceBean.
RuntimeServiceHandle handle = rts.open();
RequestDetail reqDetail = rts.getRequestDetail(handle,
requestExecutionContext.getRequestId());

6.2.3.2 実装

次の例は、シン・クライアント・ライブラリを使用するEJBジョブのスケルトン実装を示しています。EJBジョブ実装の詳細は、「EJBジョブの作成と使用」を参照してください。

@Stateless(name = "JMXAdapter")
public class JMXAdapterBean implements RemoteCancellableExecutable
{
@Resource
private SessionContext sctx;
public JMXAdapterBean() {
}

public void execute(RequestExecutionContext requestExecutionContext,
RequestParameters requestParameters) throws
ExecutionErrorException,
ExecutionWarningException,
ExecutionPausedException,
ExecutionCancelledException
{
//"ESS RequestId:" + requestExecutionContext.getRequestId();
//"EJB Operation:" + requestParameters.getValue(SystemProperty.EJB_OPERATION_NAME);
//"Invoke Message:" + requestParameters.getValue(SystemProperty.INVOKE_MESSAGE);
}
public void cancel(RequestExecutionContext requestExecutionContext,
RequestParameters requestParameters)
{
//"ESS RequestId:" + requestExecutionContext.getRequestId();
//"EJB Operation:" + requestParameters.getValue(SystemProperty.EJB_OPERATION_NAME);
//"Invoke Message:" + requestParameters.getValue(SystemProperty.INVOKE_MESSAGE);
}
}

6.2.3.3 サブジェクトの伝播

Oracle Enterprise SchedulerがEJBジョブを起動する場合、ホスティング・アプリケーションに関連付けられているサブジェクトはジョブに常に伝播されます。これにより、ジョブを実行するサブジェクトがBeanのビジネス操作で使用可能になります。次のコードをejb-jar.xmlファイルに追加して、Bean内からサブジェクトを取得します。

<interceptors>
<interceptor>
<interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
<env-entry>
<env-entry-name>application.name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>NAME_OF_ENTERPRISE_APPLICATION</env-entry-value>
<injection-target>
<injection-target-class>oracle.security.jps.ee.ejb.JpsInterceptor</injection-target-class>
<injection-target-name>application_name</injection-target-name>
</injection-target>
</env-entry>
</interceptor>
</interceptors>
<assembly-descriptor>
<interceptor-binding>
<ejb-name>*</ejb-name>
<interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
</interceptor-binding>
</assembly-descriptor>

次のコードを使用すると、現在のサブジェクトの権限のあるコンテキスト内のEJB操作からMBeanを起動できます。

AccessControlContext accContext = AccessController.getContext();
Subject currentSubject = Subject.getSubject(accContext);
String currentUsername = SubjectUtil.getUserName(currentSubject);
Subject.doAs(currentSubject, new PrivilegedExceptionAction() {
public Object run() {
//logic to invoke MBean
}
});

6.3 JDeveloperを使用したMARデプロイメント用のシン・クライアント・アプリケーションのビルド

ジョブがOracle Enterprise Schedulerの事前デプロイ済ネイティブ・ホスティング・アプリケーションを使用している場合、メタデータの作成を支援し、事前デプロイ済ネイティブ・ホスティング・アプリケーションMDSパーティション(essUserMetadata)にこれをデプロイするクライアント・アプリケーションをビルドすることでカスタム・ジョブ・メタデータの作成を簡易化できます。

次の手順は、Oracle JDeveloperを使用して、次の処理を実行するシン・クライアント・アプリケーションを作成する方法を示しています。

- ジョブ・メタデータの追加

- エンタープライズ・アーカイブ(EAR)の作成

- EAR内のメタデータ・アーカイブ(MAR)のパッケージ化

- 事前デプロイ済のネイティブ・ホスティング・アプリケーションへのメタデータのデプロイ

「JDeveloperを使用したEJBおよびそのジョブ定義メタデータの作成および構成」の手順で、事前デプロイ済ネイティブ・ホスティング・アプリケーションに追加されるEJBジョブ定義によって起動できるEJBの作成方法を説明します。

アプリケーションのデプロイ時、ADFインフラストラクチャが使用されメタデータが特定のパーティションにデプロイされます。事前デプロイ済ネイティブ・ホスティング・アプリケーションのMDSパーティションは、essUserMetadataです。

JDeveloperには、スクリーン・リーダー、スクリーン拡大鏡、キーボード移動用の標準のショートカット・キーなどのアクセシビリティ・オプションが用意されています。さらに読みやすくするため、フォントのサイズや色、オブジェクトの色や形など、JDeveloperをカスタマイズすることもできます。JDeveloperでのアクセシビリティについて、およびこれを構成する手順は、『Oracle JDeveloperによるアプリケーションの開発』のOracle JDeveloperのアクセシビリティ情報に関する項を参照してください。

注意:

JDeveloperを開始する前にMW_HOME環境変数を必ず設定してください。例: export MW_HOME=/scratch/prh/12c/jdevこの変数が設定されていない場合、ジョブ・タイプ・ドロップダウン・メニューには移入されません。

6.3.1 スタンドアロン環境用のシン・クライアント・アプリケーションの作成およびデプロイ

次の手順は、JDeveloperを使用してシン・クライアント・アプリケーションを作成およびデプロイする方法を説明しています。

1. 「新規ギャラリ」ダイアログで、カスタム・アプリケーションおよびプロジェクトを作成します(図6-1を参照)。

図6-1 「新規ギャラリ」ダイアログ

2. カスタム・アプリケーションの作成ダイアログで、アプリケーション名およびアプリケーション・パッケージ接頭辞を入力します(図6-2を参照)。

図6-2 カスタム・アプリケーションの作成ダイアログ - ステップ1/3

3. プロジェクト名を入力し、プロジェクト機能に、「ESSジョブ・サポート」、「ESSクライアント・サポート」および「EJB」を追加します(図6-3を参照)。

図6-3 カスタム・アプリケーションの作成ダイアログ - ステップ2/5

4. EJB設定を構成します(図6-4を参照)。

図6-4 カスタム・アプリケーションの作成ダイアログ - ステップ4/5

5. アプリケーションIDの値を構成します(図6-5を参照)

図6-5 ESSジョブ・サポート設定の構成

6. 「次へ」をクリックします。

7. 「終了」をクリックして、新しいアプリケーションを作成するステップを完了します。

8. 前のステップで生成されたMANIFEST.MFファイルを編集し、次の行を削除します。

essclientapi-Specification-Version: 12
Extension-List: essruntime, essclientapi
Weblogic-Application-Version: 3.0
essclientapi-Extension-Name: oracle.ess.client.api
essruntime-Extension-Name: oracle.ess.runtime
essruntime-Specification-Version: 12

9. 左側のツリー・パネルでプロジェクト・ノードを右クリックし、プロジェクト・プロパティを選択して、「ライブラリとクラスパス」をクリックします(図6-6を参照)。「クラスパス・エントリ」ペインで「Java EE」および「エンタープライズ・スケジューラ」のみが選択されていることを確認します。

図6-6 「プロジェクト・プロパティ」ダイアログ

10. 「新規ギャラリ」ダイアログで、「エンタープライズ・スケジューラ・メタデータ」および「ジョブ定義」を選択します(図6-7を参照)。

図6-7 「新規ギャラリ」ダイアログ

11. 「ジョブ定義の作成」ダイアログで「ジョブ・タイプ」ドロップダウンから/oracle/as/ess/core/ProcessJobTypeを選択して、単純な生成済ジョブ定義メタデータを追加します(図6-8を参照)。

図6-8 「ジョブ定義の作成」ダイアログ

12. 生成済ジョブ定義メタデータの追加を完了するには、「オーバーライド」チェック・ボックスを選択して「コマンド行」に値を入力します。SYS_effectiveApplicationという名前のシステム・プロパティに値EssNativeHostingAppを指定して追加します。

図6-9 SimpleSpawnedJobDefn.xmlのタブ

13. EJBジョブ定義メタデータを追加します。「JDeveloperを使用したEJBおよびそのジョブ定義メタデータの作成および構成」の手順に従います。

14. MARプロファイルを構成します。

a. 「アプリケーションのプロパティ」を選択して、「デプロイメント・ノード」をクリックします。

b. 右側のパネルで「MARモジュール」を選択し、「編集」をクリックします。

c. MARデプロイメント・プロパティの編集ダイアログで「ユーザー・メタデータ」を選択します(図6-10を参照)。

d. (前に作成済のプロジェクトのパスの下にある)essmetaディレクトリが使用可能であることを確認します。使用不可の場合、essmetaディレクトリに手動で移動してディレクトリを追加します。

図6-10 「MARデプロイメント・プロファイルのプロパティの編集」ダイアログ

15. 適切なメタデータを選択して、MARでパッケージ化します。「ユーザー・メタデータ」の下にある「ディレクトリ」ノードをクリックして、新規追加されたジョブ定義が選択されていることを確認します(図6-11を参照)。

図6-11 「MARデプロイメント・プロファイルのプロパティの編集」ダイアログ

16. エンタープライズ・アーカイブ(EAR)のデプロイメント・プロファイルを作成します。

a. 「アプリケーションのプロパティ」を選択して、デプロイメント・ノードをクリックします。

b. 右パネルで「新規」をクリックして、「デプロイメント・プロファイルの作成」ダイアログを起動します。「プロファイル・タイプ」ドロップダウンから「EARファイル」を選択します(図6-12を参照)。

図6-12 「デプロイメント・プロファイルの作成」ダイアログ

17. EARのアプリケーション・アセンブリを構成します。ダイアログで、次の2つのプロファイルが選択されていることを確認します。

- 以前に作成したMARプロファイル

- EJBプロファイル。このプロファイルは自動的に作成されます。自動的に作成されない場合、ステップ2の最初で前に説明したように、プロジェクトの新規EJB JARデプロイメント・プロファイルを作成します。

EJB-JARデプロイメント・プロファイルを作成する手順は、次のとおりです。

a. 「アプリケーション・ナビゲータ」の「プロジェクト」パネルで、Applicationプロジェクトを右クリックし、「プロジェクト・プロパティ」をクリックします。

b. 「プロジェクト・プロパティ」ウィンドウのナビゲータで、「デプロイメント」をクリックします。

c. 「デプロイメント・プロファイル」で、ウィンドウに表示されているすべてのプロファイルを削除し、「新規」をクリックします。

d. 「デプロイメント・プロファイルの作成」ダイアログで、「プロファイル・タイプ」ドロップダウン・リストから「EJB JARファイル」を選択します。

e. 「名前」フィールドに、EJBの名前を入力します。この例では、MySampleThinClientEjbと入力します。

f. 「OK」をクリックします。

図6-13 EJB-JARデプロイメント・プロファイルの作成

g. 左側にある「EJB JARデプロイメント・プロファイルのプロパティの編集」ダイアログ・ナビゲータで、「一般」をクリックします。

h. 「一般」ウィンドウで、「エンタープライズ・アプリケーション名」フィールドにMySampleThinClientAppと入力します。

i. ナビゲータで、「ファイル・グループ」→「プロジェクトの出力」→「コントリビュータ」の順に開きます。

j. 「コントリビュータ」ウィンドウで、次のチェック・ボックスを選択します。

- プロジェクトの出力ディレクトリ

- プロジェクトのソースパス

- プロジェクトの依存性

k. ナビゲータで、「ファイル・グループ」→「プロジェクトの出力」→「フィルタ」の順に開きます。

図6-14 「EARデプロイメント・プロファイルのプロパティの編集」ダイアログ

l. 「フィルタ」ウィンドウの「フィルタ」タブで、次のフォルダが選択されていることを確認します。

- META-INF(およびそのコンテンツ)

- oracle (およびそのコンテンツ)

m. 「JARオプション」ウィンドウで、「Manifestファイルを含める」項目を選択解除します。

n. 「OK」をクリックします。

o. 「プロジェクト・プロパティ」ダイアログで、「OK」をクリックします。

18. EARのライブラリ依存性を構成します。「デプロイ用に選択されたライブラリ」ペインで選択されている項目がないことを確認してください。

図6-15 「EARデプロイメント・プロファイルのプロパティの編集」ダイアログ

19. adf-config.xmlファイルを構成します。ADFベースのアプリケーションをJDeveloperからデプロイする際、メタデータがデプロイされるMDSパーティションを選択するよう求めるダイアログがあります。このアプリケーションから生成されるEARファイルがWLSコンソールからデプロイされる場合、特定のMDSパーティション・エントリをadf-config.xmlファイルで指定する必要があります。この場合、adf-config.xmlファイルに、例6-1に示されるエントリが含まれていることを確認します。adf-config.xmlファイルは、「アプリケーション・リソース」→「ディスクリプタ」→左パネルの下部の「ADF META-INF」セクションにあります。

20. weblogic-application.xmlファイルを構成します。weblogic-application.xmlファイルのコンテンツが例6-2に示されているとおりであることを確認します。

21. アプリケーションをデプロイします。EARのデプロイメントを完了するには、「デプロイメント構成」ダイアログの「パーティション名」ドロップダウンでessUserMetadataを選択し、「デプロイ」をクリックします。

図6-16 「Oracleデプロイメント構成」ダイアログ

例6-1 adf-config.xmlファイルのコンテンツ

<?xml version="1.0" encoding="UTF-8" ?>
<adf-config xmlns="http://xmlns.oracle.com/adf/config">
<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
<mds-config xmlns="http://xmlns.oracle.com/mds/config"           version="11.1.1.000">
<persistence-config>
<metadata-namespaces>
<namespace path="/oracle/apps/ess/custom"                       metadata-store-usage="ess_custom_metadata"/>
</metadata-namespaces>
<metadata-store-usages>
<metadata-store-usage id="ess_custom_metadata"                       deploy-target="true" default-cust-store="true">
<ns3:metadata-store                      class-name="oracle.mds.persistence.stores.db.DBMetadataStore"                     xmlns:ns3="http://xmlns.oracle.com/mds/config">
<ns3:property name="repository-name"                               value="mds-ESS_MDS_DS" />
<ns3:property name="partition-name"                               value="essUserMetadata" />
<ns3:property name="jndi-datasource"                               value="jdbc/mds-ESS_MDS_DS" />
</ns3:metadata-store>
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>
</mds-config>
</adf-mds-config>
</adf-config>

例6-2 weblogic-application.xmlファイルのコンテンツ

<?xml version = '1.0' encoding = 'UTF-8' ?>
<weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"                                                                                                                               xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-application               http://xmlns.oracle.com"                                 xmlns="http://xmlns.oracle.com/weblogic/weblogic-application">
<listener>
<listener-class>oracle.mds.lcm.weblogic.WLLifecycleListener</listener-class>
</listener>
<library-ref>
<library-name>oracle.ess.thin.client</library-name>
</library-ref>
</weblogic-application>

6.4 JDeveloperを使用したEJBおよびそのジョブ定義メタデータの作成および構成

EJBおよびそのジョブ定義メタデータの作成および構成には、JDeveloperを使用します。

次の手順は、各方法について説明しています。

- Oracle Enterprise Schedulerのジョブ実装要件に準拠する単純な同期EJBの作成

- EJBジョブ定義メタデータの作成およびエンタープライズ・アプリケーションの一部としてのデプロイ

1. セッションBeanを作成します。「新規ギャラリ」ダイアログで、「セッションBean」を選択し新規EJBを作成します(図6-17を参照)。

図6-17 「新規ギャラリ」ダイアログ

2. セッションBeanを構成します。「EJB名」フィールドにEJB名を入力し、「マップされた名前」フィールドにマップされた名前を入力します(図6-18を参照)「次へ」をクリックして続行します。

図6-18 「セッションBean作成」ダイアログ - ステップ2/5

3. セッションBeanビジネス・インタフェースを構成します。「リモート・インタフェースの実装」チェック・ボックスが選択されていること、およびoracle.as.scheduler.RemoteExecutableが「リモート・インタフェース」フィールドのクラスとして設定されていることを確認します(図6-19を参照)。「次へ」をクリックして、「終了」ステップに進みます。

図6-19 「セッションBean作成」ダイアログ - ステップ4/5

4. 生成されたセッションBeanを構成します。生成されたセッションBeanが、RemoteExecutableインタフェースで定義されるexecuteメソッドを実装していることを確認します。

図6-20 生成されたセッションBeanの構成

5. セッションBeanの実装を完了します。executeメソッドを実装することで、Beanが完了していることを確認します。

図6-21 セッションBeanの実装の完了

6. ejb-jar.xmlファイルに宣言が含まれていることを確認します(例6-3を参照)。

7. weblogic-ejb-jar.xmlファイルに宣言が含まれていることを確認します(例6-4を参照)。

これにより、EJBジョブ・タイプを使用してOracle Enterprise Schedulerによって起動できるEJBの作成に使用される手順が完了します。

次の2つの手順は、JDeveloperを使用してEJBジョブ定義を作成する方法を説明しています。

8. EJBジョブ定義メタデータを作成します。「新規ギャラリ」ダイアログで、「エンタープライズ・スケジューラ・メタデータ」の下の「ジョブ定義」を選択し、入力します(図6-22を参照)。

図6-22 「ジョブ定義の作成」ダイアログ

9. ジョブ定義のシステム・プロパティを構成します。システム・プロパティの追加ダイアログの「初期値」フィールドでEssNativeHostingAppを指定し、「名前」ドロップダウンからシステム・プロパティSYS_effectiveApplicationを選択します(図6-23を参照)。

図6-23 「システム・プロパティの追加」ダイアログ

処理を繰り返し、SYS_EXT_jndiMappedNameプロパティがjndiNameの初期値で構成されていることを確認します。また、アプリケーションがESSAPP以外のサーバーにデプロイされている場合、SYS_EXT_jndiProviderUrlのようなプロパティを追加します。

図6-24 「ジョブ定義」タブ

例6-3 ejb-jar.xmlファイルのコンテンツ

<?xml version = '1.0' encoding = 'UTF-8' ?>
<ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee           http://java.sun.com/xml/ns/javaee/ejb-jar_3_0."
version="3.0" xmlns="http://java.sun.com/xml/ns/javaee">
<enterprise-beans>
<session>
<description>Simple Session Bean</description>
<ejb-name>SimpleSession</ejb-name>                    <ejb-class>oracle.com.samples.ess.thinclient.SimpleSessionBean
</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<security-identity>
<use-caller-identity/>
</security-identity>
</session>
</enterprise-beans>
</ejb-jar>

例6-4 weblogic-ejb-jar.xmlファイルのコンテンツ

<?xml version = "1.0" encoding = 'UTF-8' ?>
<weblogic-ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"                                xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar               http://xmlns.oracle.com"
xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar">
<weblogic-enterprise-bean>
<ejb-name>SimpleSession</ejb-name>
<stateless-session-descriptor>
<business-interface-jndi-name-map>
<business-remote>oracle.as.scheduler.RemoteExecutable</business-remote>
<jndi-name>ejb/simpleSessionBean</jndi-name>
</business-interface-jndi-name-map>
</stateless-session-descriptor>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>

7 Oracle JDeveloperを使用したOracle Enterprise Schedulerアプリケーションの生成

この章は、Oracle Enterprise Schedulerを使用してジョブ・リクエストを実行するアプリケーションを作成および実行する方法について説明し、Oracle Enterprise Schedulerを使用するアプリケーションをOracle JDeveloperで作成する方法を示すチュートリアルです。

次に、この章では2つの分割されたアプリケーションである、ジョブ発行アプリケーション(発行者)およびジョブ実行アプリケーション(ホスティング・アプリケーション)を使用する、サンプル・アプリケーションのバリエーションを示します。

注意:

Oracle Enterprise Schedulerのサンプル・コードについては、サンプル・サイト(https://java.net/projects/oraclesoasuite12c)を参照してください。

この章の内容は次のとおりです。

- JDeveloperを起動してOracle Enterprise Schedulerアプリケーションのビルドをサポートする方法

- Oracle JDeveloperによって作成されたOracle Enterprise Schedulerアプリケーション・サポートの理解

- 組み合されたOracle Enterprise Schedulerアプリケーションのビルド

- 分割された発行者アプリケーションおよびホスティング・アプリケーションのビルド

7.1 JDeveloperを起動してOracle Enterprise Schedulerアプリケーションのビルドをサポートする方法

Oracle JDeveloperを使用してOracle Enterprise Schedulerアプリケーションを開発する場合は、ミドルウェア・ホームの環境変数をOracle JDeveloper自体のインストール場所に設定する必要があります。Oracle JDeveloperを使用してOracle Enterprise Schedulerアプリケーションの開発を始める前に、必ずこの変数を設定してください。

JDeveloperには、スクリーン・リーダー、スクリーン拡大鏡、キーボード移動用の標準のショートカット・キーなどのアクセシビリティ・オプションが用意されています。さらに読みやすくするため、フォントのサイズや色、オブジェクトの色や形など、JDeveloperをカスタマイズすることもできます。JDeveloperでのアクセシビリティについて、およびこれを構成する手順は、『Oracle JDeveloperによるアプリケーションの開発』のOracle JDeveloperのアクセシビリティ情報に関する項を参照してください。

Oracle Enterprise Schedulerアプリケーションをビルドするための環境を設定する手順は、次のとおりです。

1. コマンド・プロンプトを開きます。

2. ディレクトリをOracle JDeveloperのインストール場所に変更します。たとえば、Windowsでは次を実行します:

>cd c:\Oracle\Middleware\jdeveloper

3. MW_HOMEをOracle JDeveloperの場所に設定します。次に例を示します。

>set MW_HOME=c:\Oracle\Middleware

4. Oracle JDeveloperを起動します。

>jdeveloper

7.2 Oracle JDeveloperによって作成されたOracle Enterprise Schedulerアプリケーション・サポートの理解

Oracle Enterprise Schedulerアプリケーションを開発するためにOracle JDeveloperでプロジェクトを作成すると、特定のプロジェクト・テクノロジのサポートを指定することで、アプリケーション機能に対する基礎となるサポートが追加されます。

Oracle Enterprise Schedulerアプリケーションの作成の詳細は、「組み合されたOracle Enterprise Schedulerアプリケーションのビルド」および「分割された発行者アプリケーションおよびホスティング・アプリケーションのビルド」を参照してください。

Oracle JDeveloperを使用してアプリケーションを作成する場合は、アプリケーションの要件に応じて、次のテクノロジから選択します。

- ホスティング・アプリケーションを開発するためのESSホスト・サポート。これには次のものが含まれます。

- アプリケーション・サポートのためのweblogic-application.xmlの更新。

- プロジェクト・サポートのためのEJBデプロイメント・プロファイルの更新。

- アプリケーション・サポートのためのEARデプロイメント・プロファイルの更新。

- Oracle Enterprise Schedulerライブラリの追加。

- プロジェクトへのコンテキスト・メニューの追加(プロジェクトを右クリックして「エンタープライズ・スケジューラ・プロパティ」を選択することでアクセスします)。これにより、ejb-jar.xmlプロパティ(論理アプリケーション名、アプリケーション・ポリシー・ストライプ、JPSインターセプタ・アプリケーション名)を変更することが可能になります。

- クライアント・アプリケーションを開発するためのESSクライアント・サポートであり、次のものが含まれます。

- アプリケーション・サポートのためのweblogic-application.xmlの更新。

- プロジェクト・サポートのためのEJBデプロイメント・プロファイルの更新。

- Oracle Enterprise Schedulerライブラリの追加。

- プロジェクトへのコンテキスト・メニューの追加(プロジェクトを右クリックして「エンタープライズ・スケジューラ・プロパティ」を選択することでアクセスします)。これにより、ejb-jar.xmlプロパティ(JPSインターセプタ・アプリケーション名)を変更することが可能になります。

- スケジューラ・アプリケーションを開発するためのESSジョブ・サポート。これには次のものが含まれます。

- MARプロファイルの作成と更新。

- プロジェクト・サポートのためのJARデプロイメント・プロファイルの作成。

- Oracle Enterprise Schedulerライブラリの追加。

7.3 組み合されたOracle Enterprise Schedulerアプリケーションのビルド

このチュートリアルでビルドするEssDemoAppサンプル・アプリケーションには、Oracle Enterprise Scheduler APIを使用してOracle JDeveloperでビルドする完全なアプリケーションが含まれます。

この例では、ホスティング・アプリケーションおよび簡単なJavaジョブ実装を作成します。ここでの例は簡単ですが、そのジョブ・クラスによってExecutableインタフェースが実装され、このインタフェースから、より複雑なJavaジョブがその作業の一部として他のコードを呼び出すことができます。

ジョブ・リクエストをスケジュールするアプリケーションを作成するには、次を実行します:

- Oracle Enterprise Schedulerでスケジュールして実行するロジックを指定するJavaクラスを作成します。

- Oracle Enterprise Schedulerメタデータおよびジョブ・リクエストの特性を指定します。

- Oracle Enterprise Scheduler APIを使用してジョブ・リクエストを指定および発行するJavaアプリケーションを定義します。アプリケーションは、2つのプロジェクトで構成されます。1つはジョブをホストするため、もう1つはジョブを発行するためのものです。

- Oracle Enterprise Scheduler APIを使用するJavaアプリケーションをアセンブルおよびデプロイします。

- Oracle Enterprise Scheduler APIを使用するJavaアプリケーションを実行します。

注意:

この章の説明は、以前に保存したプロジェクトやその他の保存されたOracle JDeveloperがない状態でインストールした、新しいOracle JDeveloperを使用していることを前提としています。Oracle JDeveloperが以前に使用したものである場合、一部の手順がこの章で示す手順と正確には一致しなかったり、手順を短縮し、同じアクションをより少ないステップで実行できることがあります。場合によっては、Oracle JDeveloperの過去の使用に基づき、Oracle JDeveloperで一部のダイアログが表示されません。

Oracle Enterprise Schedulerを使用する場合、アプリケーション・メタデータはMDSを使用して格納されます。MDSを使用するには、MDSユーザーおよびスキーマが構成されたデータベースにアクセスできる必要があります。

Oracle Enterprise Schedulerがスタンドアロン・モードでデプロイされるWebLogic Serverインスタンスも必要です。Oracle Enterprise Schedulerスキーマがインストールされたデータベースにアクセスできる必要があります。

この項では、次の内容について説明します。

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

- EssDemoAppアプリケーションのメタデータおよび実装クラスの作成

- ジョブ・リクエストを発行するアプリケーション・コードの追加

- Oracle Enterprise Schedulerプロパティの設定

- EssDemoAppアプリケーションのアセンブル

- EssDemoAppアプリケーションのデプロイおよび実行

7.3.1 EssDemoAppアプリケーションのアプリケーションおよびプロジェクトの作成

Oracle JDeveloperを使用して、アプリケーションおよびそのアプリケーション内のプロジェクト(アプリケーション用のコードとサポート・ファイルが含まれている)を作成します。サンプル・アプリケーションを作成するには、次を実行する必要があります:

- Oracle JDeveloperでアプリケーションを作成します。

- Oracle JDeveloperでプロジェクトを作成します。2つのプロジェクトを作成します。1つはHello WorldスタイルのJavaジョブを開発するための、もう1つはジョブによってリクエストを発行するクライアントを開発するためのプロジェクトです。

7.3.1.1 EssDemoAppアプリケーションおよびホスト・プロジェクトの作成方法

Oracle Enterprise Schedulerを使用するには、最初にOracle JDeveloperでアプリケーションを作成する必要があります。ジョブの実行をサポートするホスティング・アプリケーションも作成します。

EssDemoAppアプリケーションおよびホスト・プロジェクトを作成する手順は、次のとおりです。

1. 「JDeveloperを起動してOracle Enterprise Schedulerアプリケーションのビルドをサポートする方法」の説明に従い、Oracle JDeveloperを起動します。

2. 「ロールの選択」ダイアログで「デフォルトのロール」を選択し、「OK」をクリックします。

3. 「アプリケーション」メニューをクリックし、次に「新規」をクリックして「ギャラリから」オプションを選択します。

4. 「アプリケーションの名前付け」ウィンドウで、新規アプリケーションの名前と場所を入力します。

a. 「新規ギャラリ」ウィンドウで、一般カテゴリ・アプリケーション項目の下にリストされた「カスタム・アプリケーション」を選択し、「OK」をクリックします。

b. 「アプリケーション名」フィールドで、アプリケーション名を入力します。このサンプル・アプリケーションの場合は、EssDemoAppと入力します。

c. 「ディレクトリ」フィールドで、デフォルトを使用します。

d. アプリケーション・パッケージ接頭辞を入力するか、またはデフォルトである接頭辞なしを受け入れます。
接頭辞に続いてピリオドが、アプリケーションの初期プロジェクト内に作成されたオブジェクトに付加されます。

e. 「次へ」をクリックします。

5. 「プロジェクトの名前付け」ウィンドウで、作成するホスト・プロジェクトの名前を入力し、サポートするテクノロジを選択します。図7-1を参照してください。

a. 「プロジェクト名」フィールドに、ホストするプロジェクトの名前を入力します。このサンプル・アプリケーションの場合は、EssHostと入力します。

b. 「プロジェクトの機能」タブの「選択可能」の下で、「ESSホスト・サポート」および「ESSジョブ・サポート」をダブルクリックし、これらがダイアログ・ボックスの右側にある「選択済」の下に表示されるようにします。
これらの詳細は、「Oracle JDeveloperによって作成されたOracle Enterprise Schedulerアプリケーション・サポートの理解」を参照してください。

c. 「次へ」をクリックします。

図7-1 カスタム・アプリケーションの作成

6. 「Java設定の構成」ウィンドウの「デフォルト・パッケージ」フィールドに、oracle.esshostと入力します。
「次へ」をクリックします。

7. 「EJB設定の構成」ウィンドウで、次のものを選択します。

- 「EJBバージョン」の下で、「Enterprise JavaBeans 3.0」オプション・ボタンを選択します。

- 「EJBバージョン3.x」の下で、「ejb-jar.xmlをこのプロジェクトで生成します」チェック・ボックスを選択します。

「次へ」をクリックします。

8. 「ESSホスト・サポート設定の構成」ウィンドウの「アプリケーションID」フィールドに、EssDemoAppと入力します。
「終了」をクリックします。

「EssDemoApp概要」ページが表示されます。このページのセクションを使用して、作成しているアプリケーションの状況に関する情報を取得し、開発の進捗状況を管理できます。次に、ジョブの作成をサポートするプロジェクトのアーティファクトの作成に進みます。

7.3.1.2 クライアント・プロジェクトの作成方法

前の手順で、ジョブをホストするアプリケーションを開発するプロジェクトを作成しました。この項では、Oracle JDeveloperを使用して、EssDemoAppアプリケーションに別のプロジェクトを作成します。この2番目のプロジェクトでは、クライアントとホスティング・アプリケーションの対話をサポートします。

クライアント・プロジェクトを作成する手順は、次のとおりです。

1. 「ファイル」メニューをクリックし、「新規」→「プロジェクト」をクリックします。

2. 「新規ギャラリ」の「カテゴリ」で、「一般」を開き、「プロジェクト」をクリックします。

3. 「アイテム」で「カスタム・プロジェクト」をクリックし、「OK」をクリックします。

4. 「プロジェクトの名前付け」ウィンドウで、作成するクライアント・プロジェクトの名前を入力し、サポートするテクノロジを選択します。図7-2を参照してください。

a. 「プロジェクト名」フィールドに、クライアント・プロジェクトの名前を入力します。このサンプル・アプリケーションの場合は、EssClientと入力します。

b. 「プロジェクトの機能」タブの「選択可能」の下で、次の項目をダブルクリックし、ダイアログ・ボックスの右側にある「選択済」の下に表示されるようにします。
ESSクライアント・サポート

HTMLおよびCSS

JSF

JSPおよびサーブレット

XML

この詳細は、「Oracle JDeveloperによって作成されたOracle Enterprise Schedulerアプリケーション・サポートの理解」を参照してください。

c. 「次へ」をクリックします。

図7-2 カスタム・プロジェクトの作成

5. 「Java設定の構成」ウィンドウの「デフォルト・パッケージ」フィールドに、oracle.essclientと入力します。
「次へ」をクリックします。

6. 「EJB設定の構成」ウィンドウで、次のものを選択します。

- 「EJBバージョン」の下で、「Enterprise JavaBeans 3.0」オプション・ボタンを選択します。

「次へ」をクリックします。

7. 「ESSクライアント・サポート設定の構成」ウィンドウの「アプリケーションID」フィールドで、EssDemoAppが表示されていることを確認します。
「終了」をクリックします。

7.3.2 EssDemoAppアプリケーションのメタデータおよび実装クラスの作成

ここで追加するJavaジョブの場合は、実装クラスによって、ジョブのロジック、つまり、ジョブの実際の作業を実行するコードが実装されます。クラスによってoracle.as.scheduler.Executableインタフェースが実装されます。インタフェースのexecuteメソッドによって、ジョブのロジックを追加できる場所が提供されます。この例のコードは非常に簡単ですが、executeメソッドは、Javaジョブがアクセスできるコードへ続く処理の開始点としても使用できます。

PL/SQLやプロセス・ジョブなどの他のジョブ・タイプと同様に、メタデータがJavaジョブの作業のガイドとなります。このメタデータによって、Oracle Enterprise Scheduler定義のシステム・プロパティ、ユーザーが作成するプロパティ、およびメタデータにアクセスできるユーザーの制御を含めることができる、ジョブ固有のコンテキストが形成されます。たとえば、メタデータを使用して、インスタンス・データを収集してダウンストリームのコードに渡すことができます。

EssDemoAppサンプル・アプリケーションを使用してジョブ・リクエストを発行するには、次のものを作成する必要があります。

- Oracle Enterprise Schedulerでジョブ・リクエストを定義する基本作業単位となる、ジョブ定義の形式のメタデータ

- Javaジョブ実装クラス

7.3.2.1 EssDemoAppアプリケーションのメタデータの作成方法

この項では、Oracle JDeveloperを使用してジョブ定義メタデータおよびJavaジョブの簡単な実装クラスを作成します。

アプリケーションのメタデータを作成する手順は、次のとおりです。

1. アプリケーション・ナビゲータで、EssHostプロジェクトを選択します。

2. [Ctrl]キーを押しながら[N]キーを押します。「新規ギャラリ」が表示されます。

3. 「カテゴリ」領域で「ビジネス層」を開き、「エンタープライズ・スケジューラ・メタデータ」を選択します。

4. 図7-3に示すように、「アイテム」領域で「ジョブ定義」を選択します。

図7-3 サンプル・アプリケーションへのジョブ・タイプ・メタデータの追加

5. 「OK」をクリックします。「ジョブ定義の作成」ダイアログが表示されます。

6. 「ジョブ定義の作成」ダイアログで、次を指定します。

a. 「名前」フィールドに、ジョブ定義の名前を入力します。この例では、名前HelloWorldJobDefinitionを入力します。

b. 「パッケージ」フィールドに、パッケージ名を入力します。この例では、/oracle/esshost/metadataと入力します。
メタデータ・パッケージ名で名前を区切るには、ドットではなくスラッシュを使用する必要があります。「.metadata」で終わるメタデータ・パッケージは、Oracle JDeveloperでは表示されません。

c. 「ジョブ・タイプ」フィールドで、ドロップダウン・リストから/oracle/as/ess/core/JavaJobTypeを選択します。
ドロップダウンにジョブ・タイプが表示されない場合は、「JDeveloperを起動してOracle Enterprise Schedulerアプリケーションのビルドをサポートする方法」の説明に従い、Oracle JDeveloperを起動したことを確認します。

d. 「Javaクラスの作成」チェック・ボックスおよび「同期」オプション・ボタンが選択されていることを確認します。
「Javaクラスの作成」チェック・ボックスを選択することにより、JavaジョブのJavaクラスの作成を要求し、後で作成する手間を省くことができます。「同期」オプションを選択することによって、そのジョブが同期Javaジョブになることを指定します。

e. 「Javaクラス」で、作成するJavaクラスの詳細を指定します。「Javaパッケージ」フィールドに、パッケージ名(ここでは、oracle.esshost.impl)を入力します。図7-4に示すように、「クラス名」フィールドに、クラスの名前(ここでは、HelloWorldImpl)を入力します。

図7-4 ジョブ定義作成ウィザードによるジョブ定義の作成

f. 「OK」をクリックします。
要求したJavaクラスがHelloWorldJobDefinition.xmlファイルとともに作成されます。Oracle JDeveloperでXMLファイルのコンテンツが「ジョブ定義」ページに表示されます。

「ジョブ定義」ページで、ジョブのパラメータ、メタデータへのアクセスおよびローカライズに使用するリソース・バンドルを指定するプロパティを含むジョブ定義メタデータを編集できます。

7. 「ジョブ定義」ページの「説明」フィールドに、ジョブ・タイプの説明を入力します。この例では、Sample Java Job Definitionと入力します。
残りのメタデータは変更しません。

8. 「アプリケーション・ナビゲータ」で、プロジェクト・パネルの項目を「EssHost」→「アプリケーション・ソース」→「oracle.esshost.impl」→「HelloWorldImpl.java」の順に開き、作成したクラスを検索します。

9. ソース・エディタでHelloWorldImpl.javaを開きます。

10. ソース・エディタで、簡単なコードを追加してexecuteメソッドを実装します。executeメソッドは、Javaジョブの実行が開始される場所です。HelloWorldImplクラスは、例7-1のように表示されます。

11. HelloWorldImpl.javaを保存して閉じます。

例7-1 Executeメソッドが実装されたHelloWorldImpl

public class HelloWorldImpl implements Executable, Cancellable
{
public void execute(RequestExecutionContext ctx, RequestParameters params)
throws ExecutionErrorException, ExecutionWarningException,
ExecutionCancelledException, ExecutionPausedException
{
System.out.println("**** Sample Job Running, Request ID: " +
ctx.getRequestId());
}

public void cancel()
{
}
}

7.3.3 ジョブ・リクエストを発行するアプリケーション・コードの追加

Oracle Enterprise Schedulerアプリケーションでは、アプリケーションのいずれかのコンポーネントからジョブ・リクエストを発行するために、Oracle Enterprise Scheduler APIを使用します。EssDemoAppサンプル・アプリケーションには、(Oracle Enterprise Schedulerを使用して)ジョブ・リクエストを発行するための、サーブレット・ベースのユーザー・インタフェース用のJavaサーブレットが用意されています。

7.3.3.1 ジョブ・リクエストを発行するアプリケーション・コードの追加方法

この項では、ジョブ発行リクエストを受信するためのサーブレットを作成します。

ジョブ・リクエストの発行をサポートするサーブレットを追加する手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」で、EssClientプロジェクトを選択します。

2. [Ctrl]キーを押しながら[N]キーを押します。「新規ギャラリ」が表示されます。

3. 「新規ギャラリ」の「カテゴリ」領域で、「Web層」を開いて「サーブレット」を選択します。

4. 図7-5に示すように、「アイテム」領域で「HTTPサーブレット」を選択します。

図7-5 サンプル・アプリケーションへのジョブ・タイプ・メタデータの追加

5. 「OK」をクリックします。「HTTPサーブレット作成」ウィザードが表示されます。

6. 「ようこそ」ページで「次へ」をクリックします。

7. 「HTTPサーブレット作成 - ステップ2/4: サーブレット情報」ページで、次のように指定します。

a. 「クラス」フィールドに、サーブレット・クラスの名前を入力します。この例では、名前EssDemoを入力します。

b. 「パッケージ」フィールドに、パッケージ名を入力します。この例では、oracle.essclient.servletと入力します。

c. 「作成するコンテンツ・タイプ」フィールドのドロップダウン・リストで、「HTML」が選択されていることを確認します。

d. 図7-6に示すように、「実装するメソッド」領域で、「doGet()」および「doPost()」チェック・ボックスを選択します。

図7-6 サーブレットの作成 -- ステップ2/4

e. 「登録」領域で、「構成ファイル(web.xml)」ラジオ・ボタンを選択します。

f. 「次へ」をクリックします。

8. 「HTTPサーブレット作成 - ステップ3 / 4: マッピング情報」ページで、次のように指定します。

a. 「名前」フィールドに、サーブレットの名前を入力します。この例では、名前EssDemoを入力します。

b. 「URLパターン」フィールドに、サーブレットのマッピングのURLを入力します。この例では、/essdemo/*と入力します。

c. 「終了」をクリックします。

提供されたEssDemoアプリケーションには、完了したサーブレットが含まれています。ソース・コードをプロジェクトにコピーする必要があります。これを行うには、Oracle JDeveloperで、サーブレットのコンテンツをサンプル・アプリケーションに用意されているファイルEssDemo.javaのコンテンツで置き換えます。

7.3.4 Oracle Enterprise Schedulerプロパティの設定

Oracle Enterprise Schedulerプロパティでは、アプリケーションに関連付けられているejb-jar.xmlファイルで使用される設定の値を設定します。それらのプロパティは、次のとおりです。

- 論理アプリケーション名
アプリケーションを識別するために使用される論理名を指定します。アプリケーションをコンテナにデプロイするときに使用されるアプリケーション名とは区別します。この値を使用すると、論理アプリケーション名をソース・コードに安全にハードコードできます。

- アプリケーション・ポリシー・ストライプ
セキュリティ・チェックを実行するために使用されるJPSセキュリティ・ストライプ(またはセキュリティ・コンテキスト)を指定します。

- JPSインターセプタ・アプリケーション名
適用可能なセキュリティ・ポリシーのセットを判別するために実行時に使用される、アプリケーション・ストライプ名を指定します。

7.3.4.1 アプリケーションのOracle Enterprise Schedulerプロパティを設定する方法

この項では、Oracle Enterprise Schedulerプロパティのデフォルト値を設定します。

Oracle Enterprise Schedulerプロパティの値を設定する手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」でEssHostプロジェクトを右クリックし、「エンタープライズ・スケジューラ・プロパティ」をクリックします。

2. 「エンタープライズ・スケジューラ・プロパティ」ダイアログで、表示される3つのフィールド「論理アプリケーション名」、「アプリケーション・ポリシー・ストライプ」および「JPSインターセプタ・アプリケーション名」すべてにEssDemoAppと入力します。

3. 「OK」をクリックします。

図7-7 Oracle Enterprise Schedulerプロパティの値の設定

7.3.5 EssDemoAppアプリケーションのアセンブル

サンプル・アプリケーションを作成した後、Oracle JDeveloperを使用してアプリケーションをアセンブルします。

アプリケーションをアセンブルするには、次を実行します:

- EJB JARファイルを作成します。

- アプリケーションMARファイルを作成します。

- アプリケーションEARファイルを作成します。

- WARファイル・オプションを更新します。

7.3.5.1 EssDemoAppのEJB-JARデプロイメント・プロファイルの作成方法

サンプル・アプリケーションには、必要なEJBディスクリプタが含まれている必要があります。ejb-jar.xmlおよびweblogic-ejb-jar.xmlファイルを作成し、これらのファイルを、作成したJava実装クラスとともに含める必要があります。

Oracle Enterprise Schedulerがアプリケーションのかわりにジョブ・リクエストを実行している間にアプリケーションのエントリ・ポイントを検出できるように、Oracle Enterprise Schedulerには、EJB JARをアセンブルおよび提供するアプリケーションが必要です。このEJB jarでは、ejb-jar.xmlおよびweblogic-ejb-jarに必要なEJBディスクリプタがあること、およびOracle Enterprise Schedulerに対して発行されるすべてのJavaクラス実装が必要です。ディスクリプタ・ファイルejb-jar.xmlおよびweblogic-ejb-jarには、Oracle Enterprise Scheduler EJBについての記述が含まれている必要があり、これらのファイルは変更できません。

EJB-JARデプロイメント・プロファイルを作成する手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」の「プロジェクト」パネルで、EssHostプロジェクトを右クリックし、「プロジェクト・プロパティ」をクリックします。

2. 「プロジェクト・プロパティ」ウィンドウのナビゲータで、「デプロイメント」をクリックします。

3. 「デプロイメント・プロファイル」で、ウィンドウに表示されているすべてのプロファイルを削除し、「新規」をクリックします。

4. 「デプロイメント・プロファイルの作成」ダイアログで、「プロファイル・タイプ」ドロップダウンから「EJB JARファイル」を選択します。

5. 「名前」フィールドに、EJBの名前を入力します。この例では、ess-ejbと入力します。

6. 「OK」をクリックします。

図7-8 EJB-JARデプロイメント・プロファイルの作成

7. 「EJB JARデプロイメント・プロファイルのプロパティの編集」ダイアログの左側にあるナビゲータで、「一般」をクリックします。

8. 「一般」ウィンドウで、「エンタープライズ・アプリケーション名」フィールドにEssDemoAppと入力します。

9. ナビゲータで、「ファイル・グループ」→「プロジェクトの出力」→「コントリビュータ」の順に開きます。

10. 「コントリビュータ」ウィンドウで、次のチェック・ボックスを選択します。

- プロジェクトの出力ディレクトリ

- プロジェクトのソースパス

- プロジェクトの依存性

11. ナビゲータで、「ファイル・グループ」→「プロジェクトの出力」→「フィルタ」の順に開きます。

12. 「フィルタ」ウィンドウの「フィルタ」タブで、次のフォルダが選択されていることを確認します。

- META-INF(およびそのコンテンツ)

- oracle (およびそのコンテンツ)

13. 「JARオプション」ウィンドウで、「Manifestファイルを含める」項目を選択解除します。

14. 「OK」をクリックします。

15. 「プロジェクト・プロパティ」ダイアログで、「OK」をクリックします。

7.3.5.2 WARアーカイブ・オプションの更新方法

この項では、Oracle JDeveloperでWARファイルの生成に使用できる情報を指定します。

WARアーカイブ・オプションを更新する手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」の「プロジェクト」パネルで、EssClientプロジェクトを右クリックし、「プロジェクト・プロパティ」をクリックします。

2. 「プロジェクト・プロパティ」ウィンドウのナビゲータで、「デプロイメント」をクリックします。

3. 「デプロイメント・プロファイル」で、ウィンドウに表示されているすべてのプロファイルを削除し、「新規」をクリックします。

4. 「デプロイメント・プロファイルの作成」ダイアログで、「アーカイブ・タイプ」ドロップダウンから「WARファイル」を選択します。

5. 「名前」フィールドにWAR_EssDemoAppと入力します。

6. 「OK」をクリックします。

7. 「WARデプロイメント・プロファイルのプロパティの編集」ダイアログの左側にあるナビゲータで、「一般」をクリックします。

8. 「WARオプション」ウィンドウで、「manifestファイルを含める(META-INF/MANIFEST.MF)」を選択解除します。

9. 「一般」ウィンドウで、「Java EE Webコンテキスト・ルートを指定」オプションを選択します。オプションの下のフィールドに、EssDemoAppと入力します。

10. ナビゲータで、「ファイル・グループ」→「Webファイル」→「コントリビュータ」の順に開きます。

11. 「コントリビュータ」ウィンドウで、次のチェック・ボックスを選択します(図7-9を参照)。

- プロジェクトの出力ディレクトリ

- プロジェクトのHTMLルート・ディレクトリ

- プロジェクトのソースパス

図7-9 WARアーカイブ・オプションの更新

12. ナビゲータで、「ファイル・グループ」→「Webファイル」→「フィルタ」の順に開きます。

13. 「フィルタ」ウィンドウの「フィルタ」タブで、次のフォルダが選択されていることを確認します。

- oracle (およびそのコンテンツ)

- WEB-INF (およびそのコンテンツ)

「OK」をクリックします。

14. 「プロジェクト・プロパティ」→「ライブラリとクラスパス」ウィンドウに移動します。「ライブラリの追加」ボタンを使用して、次のライブラリを追加します。

- ADF共通ランタイム

- ADF Facesランタイム11

- ADF共通Webランタイム

- ADFページ・フロー・ランタイム

- ADFコントローラ・スキーマ

- ADFコントローラ・ランタイム

7.3.5.3 アプリケーションMARファイルの作成

MARオプションを作成する手順は、次のとおりです。

1. 「アプリケーション」メニューをクリックし、「アプリケーションのプロパティ」をクリックします。

2. 「アプリケーションのプロパティ」ダイアログのナビゲーション・ペインで、「デプロイメント」をクリックします。

3. 「デプロイメント・プロファイル」ウィンドウで、ウィンドウに表示されているすべてのプロファイルを削除し、「新規」をクリックします。

4. ドロップダウン・メニューからMARファイル・オプションを選択し、デプロイメント・プロファイルの名前としてMAR_EssDemoAppを入力します。

5. 「OK」をクリックします。

6. 「MARデプロイメント・プロファイルのプロパティの編集」ダイアログのナビゲーション・ペインで、「メタデータ・ファイル・グループ」→「ユーザー・メタデータ」に移動します。

7. EssDemoApp/EssHost/essmetaディレクトリを追加します。

これにより、アプリケーションについて適切なOracle Enterprise Schedulerユーザー・メタデータが選択されます。

8. 「OK」をクリックします。

9. 「MARデプロイメント・プロファイルのプロパティの編集」ウィンドウで「編集」をクリックします。

10. 「メタデータ・ファイル・グループ」→「ユーザー・メタデータ」→「ディレクトリ」に移動し、「ディレクトリ」を選択します。ツリーの最下部のディレクトリを選択します。デフォルト値を選択します。

これは、ネームスペースの作成元のディレクトリです。たとえば、oracleを選択すると、ネームスペースはoracleになります。productディレクトリを選択すると、ネームスペースはoracle/apps/productになります。ネームスペース/oracle/esshost/metadataを作成するには、metadataディレクトリをクリックします。このダイアログで選択するフォルダによって、adf-config.xmlファイルの最上位レベルのネームスペースが決定されます。

11. 「OK」をクリックします。

7.3.5.4 EARオプションの更新方法

この項では、EssDemoAppサンプル・アプリケーションをアセンブルするEARファイルを準備します。EARアーカイブは次のもので構成されます。

- Oracle Enterprise Scheduler Javaジョブ実装を含むEJB JAR。

- EssDemoサーブレットを含むWARアーカイブ。

EARオプションを更新する手順は、次のとおりです。

1. 「アプリケーション」メニューをクリックし、「アプリケーションのプロパティ」をクリックします。

2. 「アプリケーションのプロパティ」ダイアログのナビゲーション・ペインで、「デプロイメント」をクリックします。

3. 「デプロイメント」ウィンドウで、「新規」をクリックします。

4. 「デプロイメント・プロファイルの作成」ダイアログで、ドロップダウン・メニューから「EARファイル」を選択します。「名前」フィールドで、デプロイメント・プロファイルの名前としてEAR_EssDemoAppと入力します。

「OK」をクリックします。

5. 「EARデプロイメント・プロファイルのプロパティの編集」ダイアログの左側にあるナビゲーション・ペインで、「アプリケーション・アセンブリ」をクリックします。

6. 「アプリケーション・アセンブリ」ウィンドウの「Java EEモジュール」で、すべての項目のチェック・ボックスが選択されていることを確認します。

7. 「EARオプション」ウィンドウで、「manifestファイルを含める」を選択し、EssHost/src/META-INF/MANIFEST.MFを追加します。

8. 「OK」をクリックします。

9. 「アプリケーションのプロパティ」ダイアログで、「OK」をクリックします。

図7-10 EARアーカイブ・オプションの更新

7.3.5.5 アプリケーションのセキュリティの構成

EssApplicationRoleロールに割り当てられるユーザーを作成する必要があります。次の手順は、バックエンド・ホスティング・アプリケーションのセキュリティを構成する方法を示しています。

1. メイン・メニューから、「アプリケーション」→「保護」→「ADFセキュリティの構成」の順に選択します。

2. 「ADFセキュリティの構成」ウィザードの「ADFセキュリティ」ページで、「ADF認証」を選択し、「次へ」をクリックします。

3. 「認証タイプ」ページで、「Webプロジェクト」ドロップダウンから「EssClient.jpr」を選択します。

4. 「HTTP Basic認証」を選択します。

5. 「終了」をクリックします。

jps-config.xmlという名前のファイルが生成されます。このファイルは、「アプリケーション・リソース」パネルで、「ディスクリプタ」および「META-INF」を開いて確認できます。このファイルには、アプリケーションに基づいて名前が付けられたセキュリティ・コンテキストまたはセキュリティ・ストライプが含まれています。

6. メイン・メニューから、「アプリケーション」→「保護」→「テスト・ユーザーとロール」の順に選択します。

jazn-data.xmlという名前のファイルが生成されます。

7. jazn-data.xmlファイルの概要エディタで、「ユーザー」リストの「追加」ボタンをクリックします。

名前をEssUserに設定し、パスワードをwelcome1に設定します。

8. 「アプリケーション・ロール」ナビゲーション・タブをクリックして、「アプリケーション・ロール」ウィンドウを開きます(図7-11を参照)。

図7-11 「アプリケーション・ロール」ウィンドウ

9. 「ロール」リスト内の「追加」ボタンをクリックして、「新しいロールの追加」を選択します。

10. 名前をEssApplicationRoleに設定します。

11. 「マッピング」タブ内の「追加」ボタンをクリックして、「ユーザーの追加」を選択します。

12. 「EssUser」を選択して「OK」をクリックします。

7.3.5.6 ジョブ定義でのESSアプリケーション・ロールに対するリソース権限の追加

次の手順は、ESSアプリケーション・ロールに対するリソース権限を追加してジョブ定義を更新する方法を示しています。

1. HelloWorldJobDefinition.xmlの「ジョブ定義」ページの「説明」フィールドに、HelloWorld Exampleと入力します。

2. 「システム・プロパティ」セクションで、「追加」ボタンをクリックします。

3. 「システム・プロパティの追加」ダイアログで、「名前」ドロップダウン・メニューからSYS_effectiveApplicationを選択します。

4. 「初期値」フィールドに、EssDemoAppと入力します。

5. 「OK」をクリックします。

6. 「アクセス制御」セクションで、「追加」ボタンをクリックします。

7. 「アクセス制御の追加」ダイアログで、「ロール」ドロップダウン・メニューのEssApplicationRoleを選択します。これは、「アプリケーションのセキュリティの構成」で作成したロールです。

8. 「読取り」および「実行」アクションを選択します。

9. 「OK」をクリックします。

10. 生成されたファイルのコンテンツが例7-2と同じであることを確認します。

例7-2 jazn-data.xml

<?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>
<jazn-data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/jazn-data.xsd">
<jazn-realm default="jazn.com">
<realm>
<name>>Username / password is: EssUser / welcome1</name>
<users>
<user>
<name>EssUser</name>
<credentials>{903}LmqEdVs3zO0/QmP90tihXv4nRq5YqYSL</credentials>
</user>
</users>
</realm>
</jazn-realm>
<policy-store>
<applications>
<application>
<name>EssDemoApp</name>
<app-roles>
<app-role>
<name>EssApplicationRole</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>oracle.security.jps.internal.core.principals.JpsXmlUserImpl</class>
<name>EssUser</name>
</member>
</members>
</app-role>
</app-roles>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>EssApplicationRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.as.scheduler.security.MetadataPermission</class>
<name>oracle.esshost.metadata.JobDefinition.HelloWorldJobDefinition</name>
<actions>Read,Update,Delete,Execute</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>
<system-policy/>
</jazn-data>

7.3.5.7 weblogic-application.xmlファイルの構成

ソース・エディタを使用して、weblogic-application.xmlから次の行を削除します。

<library-ref>
<library-name>oracle.applcp.runtime</library-name>
</library-ref>
<library-ref>
<library-name>oracle.xdo.runtime</library-name>
</library-ref>

7.3.5.8 EssHost MANIFESTファイルの更新

EssHost META-INF/MANIFEST.INFファイルのコンテンツを次の行と置き換えます。

Manifest-Version: 1.0
Weblogic-Application-Version: 3.0
Extension-List: essruntime
essruntime-Extension-Name: oracle.ess.runtime
essruntime-Specification-Version: 12

7.3.5.9 「レルム」フィールドの変更

「EssClient」→「Webコンテンツ」→「WEB-INF」→「web.xml」の順に移動します(図7-12を参照)。「セキュリティ」ウィンドウの「レルム」フィールドの次の値を変更します。

- jazn.com

変更後:

- Username / password is: EssUser / welcome1

図7-12 「レルム」フィールドの変更

7.3.5.10 EssDemoAppアプリケーションのadf-config.xmlファイルの編集

1. 「アプリケーション・リソース」パネルで、「ディスクリプタ」→「ADF META-INF」を開き、adf-config.xmlをダブルクリックします。

2. ソース・エディタで、adf-config.xmlファイルのコンテンツを例7-3に示すXMLコードで置き換えます。

例7-3 EssDemoAppアプリケーションのadf-config.xmlファイル

<?xml version="1.0" encoding="UTF-8" ?>
<adf-config xmlns="http://xmlns.oracle.com/adf/config" xmlns:sec="http://xmlns.oracle.com/adf/security/config">
<sec:adf-security-child xmlns="http://xmlns.oracle.com/adf/security/config">
<CredentialStoreContext credentialStoreClass="oracle.adf.share.security.providers.jps.CSFCredentialStore"                         credentialStoreLocation="../../src/META-INF/jps-config.xml"/>
<sec:JaasSecurityContext initialContextFactoryClass="oracle.adf.share.security.JAASInitialContextFactory"                            jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurityContext"
authorizationEnforce="false" authenticationRequire="true"/>
</sec:adf-security-child>
<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
<mds-config version="11.1.1.000" xmlns="http://xmlns.oracle.com/mds/config">
<persistence-config>
<metadata-namespaces>
<namespace path="/oracle/as/ess/core" metadata-store-usage="ess-core"/>
</metadata-namespaces>
<metadata-store-usages>
<metadata-store-usage id="ess-core" deploy-target="false"                 default-cust-store="false">
<metadata-store                class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
<property name="jndi-datasource" value="jdbc/mds-ESS_MDS_DS"/>
<property name="repository-name" value="mds-ESS_MDS_DS"/>
<property name="partition-name" value="essapp-internal-partition"/>
</metadata-store>
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>
</mds-config>
</adf-mds-config>
</adf-config>

7.3.6 EssDemoAppアプリケーションのデプロイおよび実行

EssDemoAppアプリケーションをビルドおよびアセンブルする手順を完了した後、Oracle WebLogic Serverにアプリケーションをデプロイする必要があります。アプリケーションを正常にデプロイした後、アプリケーションを実行できます。EssDemoAppサンプル・アプリケーションでは、ブラウザを使用してEssDemoサーブレットを実行し、Oracle WebLogic Serverで実行中のOracle Enterprise Schedulerにジョブ・リクエストを発行します。

7.3.6.1 EssDemoAppアプリケーションのデプロイ方法

EssDemoAppアプリケーションをデプロイするには、正しく構成され実行されているOracle WebLogic Server、およびアクティブなメタデータ・サーバーが必要です。アプリケーションをデプロイすると、Oracle JDeveloperで「デプロイメント構成」ページが表示されます。ドロップダウン・リストからリポジトリを選択し、パーティション名を入力します(パーティション名はデフォルトでアプリケーション名に設定されます)。

EssDemoAppアプリケーションをデプロイする手順は、次のとおりです。

1. Oracle WebLogic Serverが起動され、実行中であることを確認します。Oracle WebLogic Serverが実行中でない場合は、サーバーを起動します。Oracle JDeveloperにサーバーへの接続があることを確認します(例: MyConnection)。

2. 「アプリケーション・ナビゲータ」で、EssDemoAppアプリケーションを選択します。

3. 「アプリケーション・ナビゲータ」で、「アプリケーション・メニュー」から「デプロイ」→「EAR_EssDemoApp」→「デプロイ先」→「MyConnection」の順に選択します。

4. Oracle JDeveloperで「デプロイメント構成」ページが表示されます。「メタデータ・リポジトリ」で適切なオプションを選択します。

5. デプロイメント時に要求された場合次の選択をします。「メタデータ・リポジトリ」セクションで、次および図7-13に示すようにリポジトリおよびパーティション名を選択します。

a. リポジトリ名: mds-ESS_MDS_DS

b. パーティション名: essUserMetadata

図7-13 「Oracleデプロイメント構成」ウィンドウ

6. 「デプロイ」をクリックします。

7. デプロイメント・ログを使用してデプロイメントを確認します。

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

EssDemoAppサンプル・アプリケーションを実行するには、ブラウザでEssDemoサーブレットにアクセスします。

EssDemoサーブレットにアクセスする手順は、次のとおりです。

1. ブラウザに次のURLを入力します。

http://host:http-port/context-root/essdemo

次に例を示します。

http://myserver.example.com:7101/EssDemoApp/essdemo

図7-14に示すように、EssDemoサーブレットが表示されます。

図7-14 Oracle Enterprise Schedulerサンプル・アプリケーションのEssDemoサーブレットの実行

2. 「ジョブ」ドロップダウン・メニューからジョブ定義を選択します。

3. 「スケジュール」ドロップダウン・メニューから値を選択します。

4. 「送信」をクリックします。

5. ブラウザをリフレッシュして、図7-15に示すように、「リクエスト・ステータス」領域でジョブの進捗状況を確認します。

図7-15 発行されたリクエストのリクエスト・ステータスが示された、実行中のEssDemoサーブレット

7.3.6.3 EssDemoAppサンプル・アプリケーションでのジョブのパージ方法

EssDemoAppサンプル・アプリケーションおよびEssDemoサーブレットを使用して、完了したジョブを「リクエスト・ステータス」リストから削除できます。

完了したジョブを削除する手順は、次のとおりです。

1. リクエストをパージするには、「パージ」をクリックします。

2. RUNNINGまたはWAITINGのリクエストを取り消すには、「取消」をクリックします。

7.4 分割された発行者アプリケーションおよびホスティング・アプリケーションのビルド

Oracle Enterprise Schedulerアプリケーションをビルドおよびデプロイする場合、ジョブ発行アプリケーション(発行者)およびジョブ実行アプリケーション(ホスティング・アプリケーション)の2つの分割されたアプリケーションを使用できます。この設計を使用する場合、各アプリケーションは、このような分割構成をサポートするオプションを使用して構成およびデプロイする必要があります。

さらに、一部のOracle Enterprise Schedulerデプロイメントでは、ホスティング・アプリケーションと発行元アプリケーションに別のOracle WebLogic Serverを使用します。このデプロイメント・オプションでは、発行元アプリケーションとホスティング・アプリケーションが別のOracle WebLogic Serverにデプロイされます。Oracle Enterprise Schedulerの発行者アプリケーションとホスティング・アプリケーションが別のOracle WebLogic Serversで実行される場合は、発行元アプリケーションがホスティング・アプリケーションを検出できるようにホスティング・アプリケーションのOracle WebLogic Serverを構成する必要があります。

注意:

この項では、新しいアプリケーションを作成します。「EssDemoAppアプリケーションのアプリケーションおよびプロジェクトの作成」で開始する項でEssDemoAppを作成した場合、この項で同じ名前のプロジェクトを作成することに注意してください。この項でEssDemoAppのアプリケーション名を使用するには、アプリケーションに対して異なる場所を選択するか、または前のアプリケーションを削除する必要があります。

サンプルの分割されたアプリケーションをビルドするには、次を実行します:

1. スケジュールおよび実行されるコードを含むバックエンドのホスティング・アプリケーションをビルドします。

2. ジョブ・リクエストを開始するフロントエンドの発行者アプリケーションをビルドします。

この項では、次の内容について説明します。

- EssDemoAppのバックエンドのホスティング・アプリケーションを作成する方法

- Oracle Enterprise Schedulerのフロントエンドの発行者アプリケーションを作成する方法

7.4.1 EssDemoAppのバックエンドのホスティング・アプリケーションを作成する方法

Oracle JDeveloperを使用して、バックエンドのアプリケーションを作成します。EssDemoAppのバックエンドのサンプル・アプリケーションを作成するには、次を実行します:

- バックエンドのアプリケーションおよびプロジェクトを作成します。

- セキュリティを構成します。

- デプロイメント・ディスクリプタを定義します。

- Oracle Enterprise Schedulerのexecutableインタフェースを実装するJavaクラスを作成します。

- ジョブを記述するOracle Enterprise Schedulerメタデータを作成します。

- アプリケーションをアセンブルします。

- アプリケーションをデプロイします。

7.4.1.1 バックエンドのホスティング・アプリケーションの作成

分割されたアプリケーションでOracle Enterprise Schedulerを使用するには、Oracle JDeveloperを使用してバックエンドのアプリケーションおよびプロジェクトを作成し、Oracle Enterprise Schedulerの拡張機能をプロジェクトに追加します。

バックエンドのホスティング・アプリケーションを作成する手順は、次のとおりです。

1. JDeveloperのメイン・メニューから、「ファイル」→「新規」を選択します。

2. 「新規ギャラリ」で「一般」を開き、「アプリケーション」→「カスタム・アプリケーション」を選択し、「OK」をクリックします。

3. 汎用アプリケーションの作成ウィザードの「アプリケーションの名前付け」ページで、「アプリケーション名」フィールドをEssDemoAppに設定します。

4. 「次へ」をクリックします。

5. 「プロジェクトの名前付け」ウィンドウで、作成するホスト・プロジェクトの名前を入力し、サポートするテクノロジを選択します。このプロジェクトは、Oracle Enterprise Schedulerメタデータの作成および保存先です。

a. 「プロジェクト名」フィールドに、ホストするプロジェクトの名前を入力します。このサンプル・アプリケーションの場合は、SuperEssと入力します。

b. 「プロジェクトの機能」タブの「選択可能」で、「ESSホスト・サポート」および「ESSジョブ・サポート」をダブルクリックして、これらがダイアログ・ボックスの右側にある「選択済」に表示されるようにします。
これらの詳細は、「Oracle JDeveloperによって作成されたOracle Enterprise Schedulerアプリケーション・サポートの理解」を参照してください。

c. 「次へ」をクリックします。

図7-16 バックエンドのホスティング・アプリケーションの作成

6. 「Java設定の構成」ページで、デフォルト・パッケージをoracle.apps.ess.howtoに変更し、「次へ」をクリックします。

7. 「EJB設定の構成」ページで、「ejb-jar.xmlをこのプロジェクトで生成します」を選択し、「次へ」をクリックします。

8. 「ESSホスト・サポート設定の構成」ページで、「アプリケーションID」フィールドにEssDemoAppと入力します。

9. 「終了」をクリックします。

7.4.1.2 バックエンドのホスティング・アプリケーションのセキュリティの構成

EssDempAppRoleロールに割り当てられたユーザーを作成する必要があります。

バックエンドのホスティング・アプリケーションのセキュリティを構成する手順は、次のとおりです。

1. メイン・メニューから、「アプリケーション」→「保護」→「ADFセキュリティの構成」の順に選択します。

2. 「ADFセキュリティの構成」ウィザードの「ADFセキュリティ」ページで、「ADF認証」を選択し、「次へ」をクリックします。

3. このアプリケーションには保護するWebモジュールがないため、「認証タイプ」ページでデフォルト値をそのまま使用します。

4. 「終了」をクリックします。

jps-config.xmlという名前のファイルが生成されます。このファイルは、「アプリケーション・リソース」パネルで、「ディスクリプタ」→「META-INF」を開いて確認できます。このファイルには、アプリケーションに基づいて名前が付けられたセキュリティ・コンテキストまたはセキュリティ・ストライプが含まれています。

5. メイン・メニューから、「アプリケーション」→「保護」→「テスト・ユーザーとロール」の順に選択します。

jazn-data.xmlという名前のファイルが生成されます。

6. jazn-data.xmlファイルの概要エディタで、「ユーザー」リストの「追加」ボタンをクリックします。

7. 名前をEssDemoAppUserに設定し、パスワードをwelcome1に設定します。

8. 「アプリケーション・ロール」ナビゲーション・タブをクリックします。

9. 「ロール」リスト内の「追加」ボタンをクリックして、「新しいロールの追加」を選択します。

10. 名前をEssDemoAppRoleに設定します。

11. 「マッピング」タブ内の「追加」ボタンをクリックして、「ユーザーの追加」を選択します。

12. EssDemoAppUserを選択し、「OK」をクリックします。

図7-17 セキュリティの構成

7.4.1.3 バックエンドのホスティング・アプリケーションのメタデータの定義

Oracle Enterprise Schedulerの分割されたアプリケーションを使用してジョブ・リクエストを発行するには、次を含むジョブ・リクエストを定義するメタデータを作成する必要があります。

- ジョブ・タイプ: 実行タイプを指定し、ジョブ・リクエストのパラメータの共通セットを定義します。

- ジョブ定義: Oracle Enterprise Schedulerでジョブ・リクエストを定義する基本作業単位です。

バックエンドのホスティング・アプリケーションのメタデータを作成する手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」で、SuperEssプロジェクトを選択します。

2. [Ctrl]キーを押しながら[N]キーを押します。「新規ギャラリ」が表示されます。

3. 「カテゴリ」領域で「ビジネス層」を開き、「エンタープライズ・スケジューラ・メタデータ」を選択します。

4. 図7-18に示すように、「アイテム」領域で「ジョブ定義」を選択します。

図7-18 サンプル・アプリケーションへのジョブ定義の追加

5. 「OK」をクリックします。「ジョブ定義の作成」ダイアログが表示されます。

6. 「ジョブ定義の作成」ダイアログで、次を指定します(図7-19を参照)。

a. 「名前」フィールドに、ジョブ定義の名前を入力します。この例では、名前HelloWorldJobDefを入力します。

b. 「パッケージ」フィールドに、パッケージ名を入力します。この例では、oracle/apps/ess/howto/metadataと入力します。

c. 「ジョブ・タイプ」フィールドで、ドロップダウン・リストから/oracle/as/ess/core/JavaJobTypeを選択します。
ドロップダウンにジョブ・タイプが表示されない場合は、「JDeveloperを起動してOracle Enterprise Schedulerアプリケーションのビルドをサポートする方法」の説明に従い、Oracle JDeveloperを起動したことを確認します。

d. 「Javaクラスの作成」チェック・ボックスおよび「同期」オプション・ボタンが選択されていることを確認します。
「Javaクラスの作成」チェック・ボックスを選択することにより、JavaジョブのJavaクラスの作成を要求し、後で作成する手間を省くことができます。「同期」オプションを選択することによって、そのジョブが同期Javaジョブになることを指定します。

e. 「Javaクラス」で、作成するJavaクラスの詳細を指定します。「Javaパッケージ」フィールドに、パッケージ名(ここでは、oracle.apps.ess.howto)を入力します。「クラス名」フィールドに、クラスの名前(ここでは、HelloWorldJob)を入力します。

f. 「OK」をクリックします。
要求したJavaクラスがHelloWorldJobDefinition.xmlファイルとともに作成されます。Oracle JDeveloperでXMLファイルのコンテンツが「ジョブ定義」ページに表示されます。

「ジョブ定義」ページで、ジョブのパラメータ、メタデータへのアクセスおよびローカライズに使用するリソース・バンドルを指定するプロパティを含むジョブ定義メタデータを編集できます。

図7-19 ジョブ定義の作成

7. HelloWorldJobDef.xmlの「ジョブ定義」ページの「説明」フィールドに、HelloWorld Exampleと入力します。

8. 「システム・プロパティ」セクションで、「追加」ボタンをクリックします。

9. 「システム・プロパティの追加」ダイアログで、「名前」ドロップダウンからSYS_effectiveApplicationを選択します。

10. 「初期値」フィールドに、EssDemoAppと入力します。

11. 「OK」をクリックします。

12. 「アクセス制御」セクションで、「追加」ボタンをクリックします。

13. 「アクセス制御の追加」ダイアログで、「ロール」ドロップダウンのEssDemoAppRoleが選択されていることを確認します。これは、「バックエンドのホスティング・アプリケーションのセキュリティの構成」で作成したロールです。

14. 図7-20に示すように、「読取り」および「実行」を選択します。

図7-20 「アクセス制御の追加」ダイアログ

15. 「OK」をクリックします。

7.4.1.4 バックエンドのホスティング・アプリケーションでのJava実装クラスの作成

Oracle Enterprise Schedulerの制御の下でJavaクラスを実行するアプリケーションを定義するには、Oracle Enterprise Scheduler Executableインタフェースを実装するJavaクラスを作成する必要があります。Executableインタフェースでは、Oracle Enterprise Schedulerを使用したJavaクラスの呼出しを可能にする規定を指定します。

executeメソッドを実装する手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」で、プロジェクト・パネルの項目を「SuperEss」→「アプリケーション・ソース」→「oracle.apps.ess」→「howto」→「HelloWorldJob.java」の順に開き、作成したクラスを検索します。

2. ソース・エディタでHelloWorldJob.javaを開きます。

3. ソース・エディタで、次のコードを追加してexecuteメソッドを実装します。executeメソッドは、Javaジョブの実行が開始される場所です。メソッド内のコードは、例7-4のように表示されます。

例7-4 HelloWorldJob Executeメソッドのコード

StringBuilder sb = new StringBuilder(1000);
sb.append("\n==================================");
sb.append("\n= EssDemoApp request is now running");
long myRequestId = ctx.getRequestId();
sb.append("\n= Request Id = " + myRequestId);
sb.append("\n= Request Properties:");
for (String paramKey : params.getNames()) {
Object paramValue = params.getValue(paramKey);
sb.append("\n=\t(" + paramKey + ", " + paramValue + ")");
}
sb.append("\n=");
sb.append("\n==================================");
Logger logger = Logger.getLogger("oracle.apps.ess.howto");
logger.info(sb.toString());

7.4.1.5 Oracle Enterprise Schedulerプロパティの設定

Oracle Enterprise Schedulerプロパティでは、アプリケーションに関連付けられているejb-jar.xmlファイルで使用される設定の値を設定します。それらのプロパティは、次のとおりです。

- 論理アプリケーション名
アプリケーションを識別するために使用される論理名を指定します。アプリケーションをコンテナにデプロイするときに使用されるアプリケーション名とは区別します。この値を使用すると、論理アプリケーション名をソース・コードに安全にハードコードできます。

- アプリケーション・ポリシー・ストライプ
セキュリティ・チェックを実行するために使用されるJPSセキュリティ・ストライプ(またはセキュリティ・コンテキスト)を指定します。

- JPSインターセプタ・アプリケーション名
適用可能なセキュリティ・ポリシーのセットを判別するために実行時に使用される、アプリケーション・ストライプ名を指定します。

Oracle Enterprise Schedulerプロパティの値を設定する手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」でSuperEssプロジェクトを右クリックし、「エンタープライズ・スケジューラ・プロパティ」をクリックします。

2. 「エンタープライズ・スケジューラ・プロパティ」ダイアログで、表示される3つのフィールド「論理アプリケーション名」、「アプリケーション・ポリシー・ストライプ」および「JPSインターセプタ・アプリケーション名」すべてにEssDemoAppと入力します。

3. 「OK」をクリックします。

7.4.1.6 Oracle Enterprise Schedulerのバックエンドのホスティング・アプリケーションのアセンブル

バックエンドのサンプル・アプリケーションを作成した後、Oracle JDeveloperを使用してアプリケーションをアセンブルします。

バックエンドのアプリケーションをアセンブルするには、次を実行します:

- EJB Javaアーカイブの作成

- アプリケーションMARおよびEARファイルの作成

7.4.1.6.1 バックエンドのホスティング・アプリケーションのEJB JARファイルをアセンブルする方法

EJB Javaアーカイブ・ファイルには、Javaジョブ実装のディスクリプタが含まれています。

EJB-JARデプロイメント・プロファイルを作成する手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」の「プロジェクト」パネルで、SuperEssプロジェクトを右クリックし、「プロジェクト・プロパティ」をクリックします。

2. 「プロジェクト・プロパティ」ウィンドウのナビゲータで、「デプロイメント」をクリックします。

3. 「デプロイメント・プロファイル」で、ウィンドウに表示されているすべてのプロファイルを削除し、「新規」をクリックします。

4. 「デプロイメント・プロファイルの作成」ダイアログで、「プロファイル・タイプ」ドロップダウンから「EJB JARファイル」を選択します。

5. 「名前」フィールドに、EJBの名前を入力します。この例では、JAR_SuperEssEjbJarと入力します。

6. 「OK」をクリックします。

7. 「EJB JARデプロイメント・プロファイルのプロパティの編集」ダイアログのナビゲータで、「ファイル・グループ」→「プロジェクトの出力」→「コントリビュータ」の順に開きます。

8. 「コントリビュータ」ウィンドウで、次のチェック・ボックスを選択します。

- プロジェクトの出力ディレクトリ

- プロジェクトのソースパス

- プロジェクトの依存性

9. ナビゲータで、「ファイル・グループ」→「プロジェクトの出力」→「フィルタ」の順に開きます。

10. 「フィルタ」ウィンドウの「フィルタ」タブで、次のフォルダが選択されていることを確認します。

- META-INF(およびそのコンテンツ)

- oracle (およびそのコンテンツ)

11. 「JARオプション」ウィンドウで、「Manifestファイルを含める」項目を選択解除します。

12. 「OK」をクリックします。

13. 「プロジェクト・プロパティ」ダイアログで、「OK」をクリックします。

7.4.1.6.2 バックエンドのホスティング・アプリケーションのMARおよびEARファイルをアセンブルする方法

この項では、EssDemoAppサンプル・アプリケーションをアセンブルするEARファイルを準備します。EARアーカイブは、Oracle Enterprise Scheduler Javaジョブ実装を含むEJB JARで構成されます。

EARオプションを更新する手順は、次のとおりです。

1. 「アプリケーション」メニューをクリックし、「アプリケーションのプロパティ」をクリックします。

2. 「アプリケーションのプロパティ」ダイアログのナビゲーション・ペインで、「デプロイメント」をクリックします。

3. デフォルトのMARファイルのプロファイルを選択し、「編集」をクリックします。

4. 「MARデプロイメント・プロファイルのプロパティの編集」ダイアログでのナビゲーション・ペインで、「メタデータ・ファイル・グループ」→「ユーザー・メタデータ」を展開し、「追加」ボタンをクリックしてコントリビュータを追加し、ディレクトリEssDemoApp/SuperEss/essmetaを追加します。

5. 「OK」をクリックします。

6. 「MARデプロイメント・プロファイルのプロパティの編集」ウィンドウで「編集」をクリックします。

7. 「ディレクトリ」ウィンドウで「oracle.apps.ess.howto」チェック・ボックスを選択し、「OK」をクリックします。

8. 「デプロイメント・プロファイル」ウィンドウにリストされているすべてのプロファイルを削除し、「新規」をクリックします。

9. EssDemoApp/EssHost/essmetaディレクトリを追加します。
これにより、アプリケーションについて適切なOracle Enterprise Schedulerユーザー・メタデータが選択されます。

10. 「OK」をクリックします。

11. 「MARデプロイメント・プロファイルのプロパティの編集」ウィンドウで「編集」をクリックします。

12. 「デプロイメント・プロファイルの作成」ダイアログで、「プロファイル・タイプ」ドロップダウンから「EARファイル」を選択します。

13. 「名前」フィールドに、EAR_EssDemoAppEarと入力します。

「OK」をクリックします。

14. 「EARデプロイメント・プロファイルのプロパティの編集」ダイアログのナビゲーション・ペインで、「一般」をクリックします。

15. 「一般」ウィンドウで、「アプリケーション名」フィールドにEssDemoAppと入力します。

16. ナビゲーション・ペインで「アプリケーション・アセンブリ」を選択します。

17. 「アプリケーション・アセンブリ」ウィンドウで、すべての項目のチェック・ボックスが選択されていることを確認します(図7-21を参照)。

図7-21 EARデプロイメント・プロファイル・プロパティの編集

18. 「EARオプション」ウィンドウで、「manifestファイルを含める」を選択し、EssDemoApp/SuperEss/src/META-INF/MANIFEST.MFを追加します。

19. 「OK」をクリックします。

20. 「アプリケーションのプロパティ」ダイアログで、「OK」をクリックします。

7.4.1.7 SuperEss MANIFESTファイルの更新

SuperEss META-INF/MANIFEST.INFファイルのコンテンツを次の行と置き換えます。

Manifest-Version: 1.0
Weblogic-Application-Version: 3.0
Extension-List: essruntime
essruntime-Extension-Name: oracle.ess.runtime
essruntime-Specification-Version: 12

7.4.1.8 weblogic-application.xmlファイルの構成

ソース・エディタを使用して、weblogic-application.xmlから次の行を削除します。

WebLogicアプリケーションのパス:

EssDemoApp/src/META-INF/weblogic-application.xml

<library-ref>
<library-name>oracle.applcp.runtime</library-name>
</library-ref>
<library-ref>
<library-name>oracle.xdo.runtime</library-name>
</library-ref>

7.4.1.9 バックエンドのホスティング・アプリケーションのデプロイ

アプリケーションをアセンブルした後、サーバーにデプロイできます。

バックエンドのホスティング・アプリケーションをデプロイする手順は、次のとおりです。

1. メイン・メニューから、「アプリケーション」→「デプロイ」→「EAR_EssDemoAppEar...」の順に選択します。

2. アプリケーションをコンテナに設定し、デプロイします。

3. 「デプロイメント構成」ダイアログが表示されたら、デフォルト値をメモしますが、デフォルト値は変更しないでください。

7.4.1.10 EssDemoAppアプリケーションのadf-config.xmlファイルの編集

「アプリケーション・リソース」パネルで、次を行います。

1. 「ディスクリプタ」を開きます。

2. 「ADF META-INF」を開きます。

3. 「adf-config.xml」をダブルクリックします。

4. ソース・エディタで、adf-config.xmlファイルのコンテンツを例7-5に示すXMLで置き換えます。

例7-5 adf-config.xmlファイル

<?xml version="1.0" encoding="UTF-8" ?>
<adf-config xmlns="http://xmlns.oracle.com/adf/config" xmlns:config="http://xmlns.oracle.com/bc4j/configuration">
<adf-security-child xmlns="http://xmlns.oracle.com/adf/security/config">
<JaasSecurityContext initialContextFactoryClass="oracle.adf.share.security.JAASInitialContextFactory"           jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurityContext"
authorizationEnforce="false" authenticationRequire="true"/>
</adf-security-child>
<adf-adfm-config xmlns="http://xmlns.oracle.com/adfm/config">
<defaults changeEventPolicy="ppr" useBindVarsForViewCriteriaLiterals="true"            useBindValuesInFindByKey="true"/>
<startup>
<amconfig-overrides>
<config:Database jbo.locking.mode="optimistic"/>
</amconfig-overrides>
</startup>
</adf-adfm-config>
<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
<mds-config version="11.1.1.000" xmlns="http://xmlns.oracle.com/mds/config">
<persistence-config>
<metadata-namespaces>
<namespace path="/oracle/as/ess/core" metadata-store-usage="ess-core"/>
</metadata-namespaces>
<metadata-store-usages>
<metadata-store-usage id="ess-core" deploy-target="false"             default-cust-store="false">
<metadata-store                     class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
<property name="jndi-datasource" value="jdbc/mds-ESS_MDS_DS"/>
<property name="repository-name" value="mds-ESS_MDS_DS"/>
<property name="partition-name" value="essapp-internal-partition"/>
</metadata-store>
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>
</mds-config>
</adf-mds-config>
</adf-config>

7.4.2 Oracle Enterprise Schedulerのフロントエンドの発行者アプリケーションを作成する方法

Oracle Enterprise Schedulerの分割されたアプリケーションでは、フロントエンドのアプリケーションからジョブ・リクエストを発行するために、Oracle Enterprise Scheduler APIを使用します。EssDemoAppUIアプリケーションには、(Oracle Enterprise Schedulerを使用して)ジョブ・リクエストを発行するための、サーブレット・ベースのユーザー・インタフェース用のJavaサーブレットが用意されています。

フロントエンドの発行者サンプル・アプリケーションを作成するには、次を実行します:

- フロントエンドのアプリケーションおよびプロジェクトを作成します。

- ejb-jar.xmlファイルを構成します。

- Webプロジェクトを作成します。

- セキュリティを構成します。

- HTTPサーブレットを作成します。

- web.xmlファイルを編集します。

- weblogic-application.xmlファイルを編集します。

- adf-configファイルを編集します。

- アプリケーションをアセンブルします。

- アプリケーションをデプロイします。

7.4.2.1 フロントエンドの発行者アプリケーションの作成

フロントエンドの発行者アプリケーションをビルドするには、JDeveloperでバックエンドのホスティング・アプリケーションの場合に使用したのと同様の手順を使用します。

フロントエンドの発行者アプリケーションを作成する手順は、次のとおりです。

1. 「バックエンドのホスティング・アプリケーションの作成」の手順を完了しますが、ここではアプリケーションの名前としてESSDemoAppUIを使用します。ESSホスト・サポートの設定を構成する場合は、「アプリケーションID」フィールドに、必ずEssDemoAppと入力してください。

7.4.2.2 SuperWebプロジェクトの作成

サーブレットのWebプロジェクトを作成する必要があります。

SuperWebプロジェクトを作成する手順は、次のとおりです。

1. SuperEssプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で「一般」を開き、「プロジェクト」→「カスタム・プロジェクト」を選択して、「OK」をクリックします。

3. 「プロジェクトの名前付け」ウィンドウで、作成するホスト・プロジェクトの名前を入力し、サポートするテクノロジを選択します。このプロジェクトは、Oracle Enterprise Schedulerメタデータの作成および保存先です。

a. 「プロジェクト名」フィールドに、ホストするプロジェクトの名前を入力します。このサンプル・アプリケーションの場合は、SuperWebと入力します。

b. 「プロジェクトの機能」タブの「選択可能」で、ESSクライアント・サポート、「JSPおよびサーブレット」をダブルクリックして、これらがダイアログ・ボックスの右側にある「選択済」に表示されるようにします。
ESSクライアント・サポートの詳細は、「Oracle JDeveloperによって作成されたOracle Enterprise Schedulerアプリケーション・サポートの理解」を参照してください。

「次へ」をクリックします。

4. Java設定の構成ウィンドウの「デフォルト・パッケージ」フィールドで、oracle.apps.ess.howtoを入力します。「次へ」をクリックします。

5. EJB設定の構成ウィンドウの「EJBのバージョン」で、「Enterprise JavaBeans 3.0」オプション・ボタンを選択します。

6. EJB設定の構成ウィンドウの「EJBのバージョン」で、「ejb-jar.xmlをこのプロジェクトで生成します」チェック・ボックスを選択します。

7. 「終了」をクリックします。

7.4.2.3 フロントエンドの発行者アプリケーションのセキュリティの構成

アプリケーションのセキュリティを構成する必要があります。EssDemoAppUIアプリケーションはEssDemoAppアプリケーションによって作成されたユーザーおよびロールを共有するため、ユーザーやロールを作成する必要はありません。

フロントエンドの発行者アプリケーションのセキュリティを構成する手順は、次のとおりです。

1. メイン・メニューから、「アプリケーション」→「保護」→「ADFセキュリティの構成」の順に選択します。

2. 「ADFセキュリティの構成」ウィザードの「ADFセキュリティ」ページで、「ADF認証」を選択します。

3. 「認証タイプ」ページで、「Webプロジェクト」ドロップダウン・リストから「SuperWeb.jpr」を選択します。

4. 「HTTP Basic認証」を選択します。

図7-22 ADFセキュリティの構成

5. 「終了」をクリックします。

jps-config.xmlという名前のファイルが生成されます。このファイルは、「アプリケーション・リソース」パネルで、「ディスクリプタ」→「META-INF」を開いて確認できます。

7.4.2.4 フロントエンドの発行者アプリケーションのHTTPサーブレットの作成

通常は、Oracle Application Development Frameworkなどの重量フレームワーク上に作成されるより複雑なユーザー・インタフェースが使用されますが、簡単にするために、発行者アプリケーションには基本のHTTPサーブレットを使用します。

フロントエンドの発行者アプリケーションのHTTPサーブレットを作成する手順は、次のとおりです。

1. SuperWebプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で「Web層」を開き、「サーブレット」→「HTTPサーブレット」を選択して、「OK」をクリックします。

3. 「HTTPサーブレット作成 - ステップ1/3: サーブレット情報」ページで、「クラス」フィールドにEssDemoAppServletと入力します。

4. 選択を「注釈」から「構成ファイル(web.xml)」に変更します。

5. 「パッケージ」フィールドにoracle.apps.ess.howtoと入力し、「次へ」をクリックします。

6. 「終了」をクリックします。

7. ソース・エディタで、ESSDemoAppServlet.javaのコンテンツを例7-6に示すコードで置き換えます。

例7-6 フロントエンドの発行者アプリケーションのHTTPサーブレット・コード

package oracle.apps.ess.howto;

import java.io.IOException;
import java.io.PrintWriter;
import java.io.StringWriter;

import java.util.ArrayList;
import java.util.Calendar;
import java.util.Enumeration;
import java.util.HashSet;
import java.util.Iterator;
import java.util.List;
import java.util.ListIterator;
import java.util.Map;
import java.util.Set;
import java.util.SortedSet;
import java.util.TreeSet;
import java.util.logging.Level;
import java.util.logging.Logger;
import java.util.regex.Pattern;

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

import oracle.as.scheduler.MetadataObjectId;
import oracle.as.scheduler.MetadataObjectId.MetadataObjectType;
import oracle.as.scheduler.MetadataService;
import oracle.as.scheduler.MetadataService.QueryField;
import oracle.as.scheduler.MetadataServiceHandle;
import oracle.as.scheduler.RequestDetail;
import oracle.as.scheduler.RequestParameters;
import oracle.as.scheduler.RuntimeService;
import oracle.as.scheduler.RuntimeServiceHandle;
import oracle.as.scheduler.State;
import oracle.as.scheduler.core.JndiUtil;

public class EssDemoAppServlet extends HttpServlet {
@SuppressWarnings("compatibility:4685800289380934682")
private static final long serialVersionUID = 1L;

private static final String CONTENT_TYPE = "text/html; charset=UTF-8";
private static final String MESSAGE_KEY = "Message";
private static final String PATH_SUBMIT = "/submitRequest";
private static final String PATH_ALTER = "/alterRequest";
private static final String MDO_SEP = ";";
private static final String ACTION_CANCEL = "Cancel";
private static final String ESS_UNAVAIL_MSG =
"<p>Enterprise Scheduler Service is currently unavailable. Cause: %s</p>";

private enum PseudoScheduleChoices {
Immediately(0),
InTenSeconds(10),
InTenMinutes(10 * 60);

@SuppressWarnings("compatibility:-5637079380819677366")
private static final long serialVersionUID = 1L;

private int m_seconds;

private PseudoScheduleChoices(int seconds) {
m_seconds = seconds;
}

public int getSeconds() {
return m_seconds;
}
}

public EssDemoAppServlet() throws ServletException {
super();
}

@Override
public void init(ServletConfig config) throws ServletException {
super.init(config);
}

@Override
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
response.setContentType(CONTENT_TYPE);

HttpSession session = request.getSession(true);
String lastMessage = String.valueOf(session.getAttribute(MESSAGE_KEY));

if ("null".equals(lastMessage)) {
lastMessage = "";
}

try {
RuntimeLists runtimeLists = getRuntimeLists();
MetadataLists metadataLists = getMetadataLists();
renderResponse(metadataLists, runtimeLists,
request, response, lastMessage);
} catch (ServletException se) {
throw se;
} catch (Exception e) {
throw new ServletException(e);
}
}

@Override
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
response.setContentType(CONTENT_TYPE);
request.setCharacterEncoding("UTF-8");

HttpSession session = request.getSession(true);
String pathInfo = request.getPathInfo();

// Clear the message on every post request
StringBuilder message = new StringBuilder("");

try {
// Select each handler based on the form action
if ("".equals(pathInfo)) {
// No processing
} else if (PATH_SUBMIT.equals(pathInfo)) {
postSubmitRequest(request, message);
} else if (PATH_ALTER.equals(pathInfo)) {
postAlterRequest(request, message);
} else {
message.append(String.format("<p>No handler for pathInfo=%s</p>",
pathInfo));
}
}
catch (ServletException se) {
Throwable t = se.getCause();
String cause = (t == null) ? se.toString() : t.toString();
message.append (String.format(ESS_UNAVAIL_MSG, cause));
}

// Storing the messages in the session allows them to persist
// through the redirect and across refreshes.
session.setAttribute(MESSAGE_KEY, message.toString());

// render the page by redirecting to doGet(); this intentionally
// strips the actions and post data from the request.
response.sendRedirect(request.getContextPath() +
request.getServletPath());
}

/**
* Handle the job submission form.
* @param request
* @param message
* @throws ServletException
*/
private void postSubmitRequest(HttpServletRequest request,
StringBuilder message)
throws ServletException
{
String jobDefName = request.getParameter("job");
String scheduleDefName = request.getParameter("schedule");

// Various required args for submission
Calendar start = Calendar.getInstance();
start.add(Calendar.SECOND, 2);

// Launch the job based on form contents
if (jobDefName == null || scheduleDefName == null) {
message.append("Both a job name and a schedule name must be specified\n");
} else {
PseudoScheduleChoices pseudoSchedule = null;

// See if schedule given is actually a pseudo schedule
try {
pseudoSchedule = PseudoScheduleChoices.valueOf(scheduleDefName);
} catch (IllegalArgumentException e) {
// The string is not a valid member of the enum
pseudoSchedule = null;
}

MetadataObjectId scheduleDefId = null;
String scheduleDefNamePart = null;
MetadataObjectId jobDefId = stringToMetadataObjectId(jobDefName);

// Don't look up schedules that aren't real
if (pseudoSchedule != null) {
scheduleDefNamePart = scheduleDefName;
start.add(Calendar.SECOND, pseudoSchedule.getSeconds());
} else {
scheduleDefId = stringToMetadataObjectId(scheduleDefName);
scheduleDefNamePart = scheduleDefId.getNamePart();
}

String jobDefNamePart = jobDefId.getNamePart();
String requestDesc = jobDefNamePart + "@" + scheduleDefNamePart;

Logger logger = getLogger();
long requestId = submitRequest(pseudoSchedule, requestDesc,
jobDefId, scheduleDefId, start, logger);

// Populate the message block based on results
message.append(String.format("<p>New request %d launched using %s</p>",
requestId, requestDesc));
}
}

private Long submitRequest(final PseudoScheduleChoices pseudoSchedule,
final String requestDesc,
final MetadataObjectId jobDefId,
final MetadataObjectId scheduleDefId,
final Calendar start,
final Logger logger)
throws ServletException
{
RuntimeServicePayload<Long> myPayload = new RuntimeServicePayload<Long>() {
@Override
Long execute(RuntimeService service,
RuntimeServiceHandle handle,
Logger logger)
throws Exception
{
RequestParameters params = new RequestParameters();
return (null != pseudoSchedule)
? service.submitRequest(handle, requestDesc, jobDefId,
start, params)
: service.submitRequest(handle, requestDesc, jobDefId,
scheduleDefId, null,
start, null, params);
}
};
try {
return performOperation(myPayload, logger);
} catch (Exception e) {
throw new ServletException("Error submitting request using job: " +
jobDefId + " and schedule: " +
scheduleDefId, e);
}
}

/**
* Handle the "Cancel" and "Purge" actions from the form enclosing
* the Request Status table.
* @param request
* @param message
* @throws ServletException
*/
private void postAlterRequest(HttpServletRequest request,
StringBuilder message)
throws ServletException
{
String cancelID = null;

/*
* there are a few assumptions going on here...
* the HTTP button being used to transmit the action and
* request is backwards from its normal usage (eg. the name
* should be invariable, and the value variable).  Because we
* want to display either "Purge" or "Cancel" on the button, and
* transmit the reqId with it, we are reversing the map entry
* to get the key (which in this case is the reqID), and
* match it to the value (Purge or Cancel).
* Assumptions are that there is only one entry in the map
* per request (one purge or cancel).  Also, that the datatypes
* for the key and value are those documented for
* ServletRequest (<K,V> = <String, String[]>).
*/
Map requestMap = request.getParameterMap();
Iterator mapIter = requestMap.entrySet().iterator();
while (mapIter.hasNext()) {
Map.Entry entry = (Map.Entry)mapIter.next();
String key = (String)entry.getKey();
String[] values = (String[])entry.getValue();
if (ACTION_CANCEL.equals(values[0])) {
cancelID = key;
}
}

if (cancelID != null) {
try {
final String cancelId2 = cancelID;
RuntimeServicePayload<Void> myPayload = new RuntimeServicePayload<Void>() {
@Override
Void execute(RuntimeService service,
RuntimeServiceHandle handle,
Logger logger)
throws Exception
{
service.cancelRequest(handle, Long.valueOf(cancelId2));
return null;
}
};

Logger logger = getLogger();
performOperation(myPayload, logger);
message.append
(String.format("<p>Cancelled request %s</p>", cancelID));
} catch (Exception e) {
throw new ServletException
("Error canceling or purging request", e);
}
} else {
message.append("<p>No purge or cancel action specified</p>");
}
}

private String metadataObjectIdToString(MetadataObjectId mdoID)
throws ServletException {

String mdoString =
mdoID.getType().value() + MDO_SEP + mdoID.getPackagePart() +
MDO_SEP + mdoID.getNamePart();

return mdoString;
}

private MetadataObjectId stringToMetadataObjectId(String mdoString)
throws ServletException {
String[] mdoStringParts = mdoString.split(Pattern.quote(MDO_SEP));
if (mdoStringParts.length != 3) {
throw new ServletException(String.format("Unexpected number of components %d found " +
"when converting %s to MetadataObjectID",
mdoStringParts.length,
mdoString));
}

MetadataObjectType mdType =
MetadataObjectType.getMOType(mdoStringParts[0]);
String mdPackage = mdoStringParts[1];
String mdName = mdoStringParts[2];

MetadataObjectId mdoID =
MetadataObjectId.createMetadataObjectId(mdType, mdPackage, mdName);
return mdoID;
}

/**
* this changes the format used in this class for job definitions to the one
* which is used in the runtime query.
* @param strMetadataObject
* @return string representing object in runtime store
* @throws ServletException
*/
private String fixMetadataString(String strMetadataObject)
throws ServletException {
String fslash = "/";
String[] mdoStringParts =
strMetadataObject.split(Pattern.quote(MDO_SEP));
if (mdoStringParts.length != 3) {
throw new ServletException(String.format("Unexpected number of components %d found " +
"when converting %s to MetadataObjectID",
mdoStringParts.length,
strMetadataObject));
}
String[] trimStringParts = new String[mdoStringParts.length];
for (int i = 0; i < mdoStringParts.length; i++) {
String mdoStringPart = mdoStringParts[i];
trimStringParts[i] = mdoStringPart.replaceAll(fslash, " ").trim();
}

MetadataObjectType mdType =
MetadataObjectType.getMOType(trimStringParts[0]);
String mdPackage = fslash + trimStringParts[1];
String mdName = trimStringParts[2];
MetadataObjectId metadataObjId =
MetadataObjectId.createMetadataObjectId(mdType, mdPackage, mdName);
return metadataObjId.toString();
}

private Set<String> getSetFromMetadataEnum(Enumeration<MetadataObjectId> enumMetadata)
throws ServletException {
Set<String> stringSet = new HashSet<String>();

while (enumMetadata.hasMoreElements()) {
MetadataObjectId objId = enumMetadata.nextElement();
String strNamePart = objId.getNamePart();
stringSet.add(strNamePart);
}
return stringSet;
}

//****************************************************************************
//
//   HTML Rendering Methods
//
//****************************************************************************

/**
* Rendering code for the page displayed.
* In a real application this would be done using JSP, but this approach
* keeps everything in one file to make the example easier to follow.
* @param response The response object from the main request.
* @param message Text that appears in the message panel, may contain HTML
* @throws IOException
*/
private void renderResponse(MetadataLists ml,
RuntimeLists rl,
HttpServletRequest request,
HttpServletResponse response,
String message)
throws IOException, ServletException
{
response.setContentType(CONTENT_TYPE);
PrintWriter out = response.getWriter();

String urlBase = request.getContextPath() + request.getServletPath();

// Indents maintained for clarity
out.println("<html>");
out.println("<head><title>EssDemo</title></head>");
out.println("<body>");
out.println("<table align=\"center\"><tbody>");
out.println("  <tr><td align=\"center\"><h1>Oracle Enterprise Scheduler Tutorial</h1></td></tr>");
out.println("  <tr><td align=\"center\"><table cellspacing=6><tr>");

// Job launch form
out.println("    <td align=\"center\">");
out.println("      <h2>Launch Job</h2>");
renderLaunchJobForm(ml, out, urlBase);
out.println("    </td>");

out.println("    <td align=\"center\" bgcolor=\"blue\" width=\"2\"/>");

out.println("  </tr></table></td></tr>");

out.println("  <tr><td bgcolor=\"red\"/></tr>");

// Message panel
out.println("      <tr><td align=\"center\"><h3>Messages</h3></td></tr>");
out.println("      <tr><td>");
out.println(message);
out.println("    </td></tr>");

out.println("  <tr><td bgcolor=\"red\"/></tr>");

// Request status
out.println("  <tr><td align=\"center\">");
out.println("    <form name=\"attrs\" action=\"" + urlBase +
PATH_ALTER + "\" method=\"post\">");
out.println("    <h2>Request Status</h2>");
out.println("    <table border=2><tbody>");
out.println("          <th>reqID</th>");
out.println("          <th>Description</th>");
out.println("          <th>Scheduled time</th>");
out.println("          <th>State</th>");
out.println("          <th>Action</th>");

renderStatusTable(out, rl.requestDetails);

out.println("    </tbody></table>");
out.println("    </form>");
out.println("  </td></tr>");
out.println("</tbody></table>");
out.println("</body></html>");
out.close();
}

private void renderLaunchJobForm(MetadataLists ml, PrintWriter out, String urlBase)
throws ServletException {
out.println("      <form name=\"attrs\" action=\"" + urlBase +
PATH_SUBMIT + "\" method=\"post\">");
out.println("        <table><tbody>");
out.println("          <tr><td align=\"right\">");
out.println("            <b>Job:</b>");
out.println("            <select name=\"job\">");

renderMetadataChoices(out, ml.jobDefList, false);
renderMetadataChoices(out, ml.jobSetList, false);

out.println("            </select>");
out.println("          </td></tr>");
out.println("          <tr><td align=\"right\">");
out.println("            <b>Schedule:</b>");
out.println("            <select name=\"schedule\">");

renderPseudoScheduleChoices(out);
renderMetadataChoices(out, ml.scheduleList, false);

out.println("            </select>");
out.println("          </td></tr>");
out.println("          <tr><td align=\"center\">");
out.println("            <input name=\"submit\" value=\"Submit\" type=\"submit\">");
out.println("          </td></tr>");
out.println("        </tbody></table>");
out.println("      </form>");
}

/**
*
* @param out - printwriter
* @param jobChoices --  metadata to be displayed
* @param bBlankFirst -- blank first (so that this param is not required)
* @throws ServletException
*/
private void renderMetadataChoices(PrintWriter out,
Enumeration<MetadataObjectId> jobChoices,
boolean bBlankFirst)
throws ServletException
{
if (jobChoices == null)
return;

boolean bFirst = true;
while (jobChoices.hasMoreElements()) {
MetadataObjectId job = jobChoices.nextElement();
String strJob = metadataObjectIdToString(job);
String strNamePart = job.getNamePart();
if (strNamePart.compareTo("BatchPurgeJob") == 0) {
continue;
} else {
if (bFirst && bBlankFirst) {
out.printf("<option value=\"%s\">%s</option>", "", "");
bFirst = false;
}
out.printf("<option value=\"%s\">%s</option>", strJob,
strNamePart);
}
}
}

/**
* helper method for rendering choices based on strings, adding an empty
* string to the beginning of the list
* @param out
* @param choices
*/
private void renderStringChoices(PrintWriter out, Set<String> choices) {
if (choices == null)
return;

choices.add("");
SortedSet<String> sorted = new TreeSet<String>(choices);
Iterator choiceIter = sorted.iterator();
while (choiceIter.hasNext()) {
String choice = (String)choiceIter.next();

out.printf("<option value=\"%s\">%s</option>", choice, choice);
}
}

private void renderPseudoScheduleChoices(PrintWriter out) {
for (PseudoScheduleChoices c : PseudoScheduleChoices.values()) {
out.printf("<option value=\"%s\">%s</option>", c, c);
}
}

private void renderStatusTable
(PrintWriter out, List<RequestDetail> reqDetails)
{
if (reqDetails == null) {
return;
}

for (RequestDetail reqDetail : reqDetails) {
State state = reqDetail.getState();

Calendar scheduledTime = reqDetail.getScheduledTime();
String scheduledTimeString = null;

if (scheduledTime == null) {
scheduledTimeString = "null scheduled time";
} else {
scheduledTimeString = String.valueOf(scheduledTime.getTime());
}

final String actionButton;
if (!state.isTerminal()) {
String action = ACTION_CANCEL;
String reqId = String.valueOf(reqDetail.getRequestId());
actionButton = String.format
("<button type=submit value=%s name=\"%s\">%s</button>",
action, reqId, action);
} else {
actionButton = "&nbsp;";
}

out.printf("<tr><td>%d</td><td>%s</td><td>%s</td><td>%s</td><td>%s</td></tr>\n",
reqDetail.getRequestId(), reqDetail.getDescription(),
scheduledTimeString, state, actionButton);
}
}

private MetadataService getMetadataService() throws Exception {
return JndiUtil.getMetadataServiceEJB();
}

private RuntimeService getRuntimeService() throws Exception {
return JndiUtil.getRuntimeServiceEJB();
}

private abstract class Payload<SERVICE, HANDLE, RETURN> {
abstract SERVICE getService() throws Exception;
abstract HANDLE getHandle(SERVICE service) throws Exception;
abstract void closeHandle(SERVICE service,
HANDLE handle,
boolean abort)
throws Exception;
abstract RETURN execute(SERVICE service, HANDLE handle, Logger logger)
throws Exception;
}

private abstract class MetadataServicePayload<T>
extends Payload<MetadataService, MetadataServiceHandle, T>
{
@Override
MetadataService getService() throws Exception {
return getMetadataService();
}

@Override
MetadataServiceHandle getHandle(MetadataService service)
throws Exception
{
return service.open();
}

@Override
void closeHandle(MetadataService service,
MetadataServiceHandle handle,
boolean abort)
throws Exception
{
service.close(handle, abort);
}
}

private abstract class RuntimeServicePayload<T>
extends Payload<RuntimeService, RuntimeServiceHandle, T>
{
@Override
RuntimeService getService() throws Exception {
return getRuntimeService();
}

@Override
RuntimeServiceHandle getHandle(RuntimeService service)
throws Exception
{
return service.open();
}

@Override
void closeHandle(RuntimeService service,
RuntimeServiceHandle handle,
boolean abort)
throws Exception
{
service.close(handle, abort);
}
}

private <S, H, R> R performOperation
(Payload<S, H, R> payload, Logger logger)
throws Exception
{
S service = payload.getService();
H handle = payload.getHandle(service);

Exception origException = null;
try {
return payload.execute(service, handle, logger);
} catch (Exception e2) {
origException = e2;
throw e2;
} finally {
if (null != handle) {
try {
boolean abort = (null != origException);
payload.closeHandle(service, handle, abort);
} catch (Exception e2) {
if (null != origException) {
logger.log(Level.WARNING, "An error occurred while " +
"closing handle, however, a previous failure was " +
"detected.  The following error will be logged " +
"but not reported: " + stackTraceToString(e2));
}
}
}
}
}

private final String stackTraceToString(Exception e) {
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter(sw);
e.printStackTrace(pw);
pw.flush();
pw.close();
return sw.toString();
}

private Logger getLogger() {
return Logger.getLogger(this.getClass().getName());
}

private class MetadataLists {
private final Enumeration<MetadataObjectId> jobDefList;
private final Enumeration<MetadataObjectId> jobSetList;
private final Enumeration<MetadataObjectId> scheduleList;
private final Enumeration<MetadataObjectId> jobTypeList;

private MetadataLists(Enumeration<MetadataObjectId> jobDefList,
Enumeration<MetadataObjectId> jobSetList,
Enumeration<MetadataObjectId> scheduleList,
Enumeration<MetadataObjectId> jobTypeList)
{
this.jobDefList   = jobDefList;
this.jobSetList   = jobSetList;
this.scheduleList = scheduleList;
this.jobTypeList  = jobTypeList;
}
}

private class RuntimeLists {
private final List<RequestDetail> requestDetails;
private final Set<String> applicationChoices;
private final Set<String> stateChoices;
private final Set<MetadataObjectId> jobDefMDOChoices;

private RuntimeLists(List<RequestDetail> requestDetails,
Set<String> applicationChoices,
Set<String> stateChoices,
Set<MetadataObjectId> jobDefMDOChoices)
{
super();
this.requestDetails = requestDetails;
this.applicationChoices = applicationChoices;
this.stateChoices = stateChoices;
this.jobDefMDOChoices = jobDefMDOChoices;
}
}

/**
* Retrieve lists of jobs, schedules, and status for use by the renderer
* @throws ServletException
*/
private MetadataLists getMetadataLists() throws Exception {
Logger logger = getLogger();

MetadataServicePayload<MetadataLists> myPayload =
new MetadataServicePayload<MetadataLists>()
{
@Override
MetadataLists execute(MetadataService service,
MetadataServiceHandle handle,
Logger logger)
throws Exception
{
Enumeration<MetadataObjectId> jobDefs =
service.queryJobDefinitions(handle, null, QueryField.NAME, true);
Enumeration<MetadataObjectId> jobSets =
service.queryJobSets(handle, null, QueryField.NAME, true);
Enumeration<MetadataObjectId> schedules =
service.querySchedules(handle, null, QueryField.NAME, true);
Enumeration<MetadataObjectId> jobTypes =
service.queryJobTypes(handle, null, QueryField.NAME, true);

return new MetadataLists(jobDefs, jobSets, schedules, jobTypes);
}
};
MetadataLists ml = performOperation(myPayload, logger);
return ml;
}

private RuntimeLists getRuntimeLists() throws Exception {
Logger logger = getLogger();

RuntimeServicePayload<List<RequestDetail>> myPayload2 =
new RuntimeServicePayload<List<RequestDetail>>()
{
@Override
List<RequestDetail> execute(RuntimeService service,
RuntimeServiceHandle handle,
Logger logger)
throws Exception
{
List<RequestDetail> reqDetails =
new ArrayList<RequestDetail>(10);
Enumeration requestIds = service.queryRequests
(handle, null, RuntimeService.QueryField.REQUESTID, true);

while (requestIds.hasMoreElements()) {
Long reqId = (Long)requestIds.nextElement();
RequestDetail detail = service.getRequestDetail(handle, reqId);
reqDetails.add(detail);
}

return reqDetails;
}
};
List<RequestDetail> reqDetails = performOperation(myPayload2, logger);
RuntimeLists rl = getRuntimeLists(reqDetails);
return rl;
}

private RuntimeLists getRuntimeLists(List<RequestDetail> reqDetails) {
Set<String> applicationSet = new HashSet<String>(10);
Set<String> stateSet = new HashSet<String>(10);
Set<MetadataObjectId> jobDefMOSet = new HashSet<MetadataObjectId>(10);

if (reqDetails != null) {
ListIterator detailIter = reqDetails.listIterator();
while (detailIter.hasNext()) {
RequestDetail detail = (RequestDetail)detailIter.next();
applicationSet.add(detail.getDeployedApplication());
State state = detail.getState();
if (state.isTerminal())
stateSet.add(state.name());
jobDefMOSet.add(detail.getJobDefn());
}
}

RuntimeLists rl = new RuntimeLists
(reqDetails, applicationSet, stateSet, jobDefMOSet);
return rl;
}

}

7.4.2.5 フロントエンドの発行者アプリケーションのweb.xmlファイルの編集

Oracle Enterprise SchedulerメタデータおよびランタイムEJB参照を追加するには、web.xmlファイルを編集する必要があります。

フロントエンドの発行者アプリケーションのweb.xmlファイルを編集する手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」で「SuperWeb」→「Webコンテンツ」→「WEB-INF」の順に開き、「web.xml」をダブルクリックします。

2. 概要エディタで「参照」ナビゲーション・タブをクリックし、「EJB参照」セクションを開きます。

3. 表7-1に示す情報を含む2つのEJBリソースを追加します。

表7-1 フロントエンドの発行者アプリケーションのEJBリソース

EJB名

インタフェース・タイプ

EJBタイプ

ローカル/リモート・インタフェース

ess/metadata

ローカル

セッション

oracle.as.scheduler.MetadataServiceLocal

ess/runtime

ローカル

セッション

oracle.as.scheduler.RuntimeServiceLocal

4. 「サーブレット」ナビゲーション・タブをクリックし、「サーブレット・マッピング」タブをクリックします。

5. /essdemoappservlet URLパターンを/essdemoappservlet/*に変更します。

7.4.2.6 フロントエンドの発行者アプリケーションのweblogic-application.xmlファイルの編集

weblogic-application.xmlファイルを作成し、編集する必要があります。

フロントエンドの発行者アプリケーションのweblogic-application.xmlファイルを編集する手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」で、SuperEssプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で「一般」を開き、「デプロイメント・ディスクリプタ」→「Weblogicデプロイメント・ディスクリプタ」を選択し、「OK」をクリックします。

3. 「ディスクリプタの選択」ページでweblogic-application.xmlを選択します。

4. 「次へ」をクリックし、再度「次へ」をクリックして「終了」をクリックします。

5. ソース・エディタで、作成したweblogic-application.xmlファイルのコンテンツを例7-7に示すXMLで置き換えます。

例7-7 フロントエンドの発行者アプリケーションのweblogic-application.xmlにコピーするコンテンツ

<?xml version = '1.0' encoding = 'UTF-8'?>
<weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application

http://www.bea.com/ns/weblogic/weblogic-application/1.0/weblogic-application.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-application">

<!-- The following application parameter tells JPS which stripe it should
- use to upload the jazn-data.xml policy.  If this parameter is not
- specified, it uses the Java EE deployment name plus the version
- number (e.g. EssDemoApp#V2.0).
-->
<application-param>
<param-name>jps.policystore.applicationid</param-name>
<param-value>EssDemoAppUI</param-value>
</application-param>

<!-- This listener allows JPS to configure itself and upload the
- jazn-data.xml policy to the appropriate stripe
-->
<listener>
<listener-class>oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener</listener-class>
</listener>

<!-- This listener allows MDS to configure itself and upload any metadata
- as defined by the MAR profile and adf-config.xml
-->
<listener>
<listener-class>oracle.mds.lcm.weblogic.WLLifecycleListener</listener-class>
</listener>

<!-- This listener allows Oracle Enterprise Scheduler to configure itself
-->
<listener>
<listener-class>oracle.as.scheduler.platform.wls.deploy.ESSApplicationLifecycleListener</listener-class>
</listener>

<!-- This shared library contains all the Oracle Enterprise Scheduler classes
-->
<library-ref>
<library-name>oracle.ess.client</library-name>
</library-ref>
<library-ref>
<library-name>adf.oracle.domain</library-name>
</library-ref>
</weblogic-application>

7.4.2.7 フロントエンドの発行者アプリケーションのadf-configファイルの編集

ホスティング・アプリケーションで作成されたメタデータを共有するようにアプリケーションに通知するには、adf-config.xmlファイルを編集する必要があります。

フロントエンドの発行者アプリケーションのadf-config.xmlファイルを編集する手順は、次のとおりです。

1. 「アプリケーション・リソース」パネルで、「ディスクリプタ」→「ADF META-INF」を開き、adf-config.xmlをダブルクリックします。

2. ソース・エディタで、adf-config.xmlファイルのコンテンツを例7-8に示すXMLで置き換えます。

例7-8 フロントエンドの発行者アプリケーションのadf-config.xmlにコピーするコンテンツ

<?xml version="1.0" encoding="UTF-8" ? >
<adf-config xmlns="http://xmlns.oracle.com/adf/config"
xmlns:sec="http://xmlns.oracle.com/adf/security/config">
<sec:adf-security-child xmlns="http://xmlns.oracle.com/adf/security/config">  <CredentialStoreContext
credentialStoreClass="oracle.adf.share.security.providers.jps.CSFCredentialSto
re"

credentialStoreLocation="../../src/META-INF/jps-config.xml"/>
sec:JaasSecurityContext
initialContextFactoryClass="oracle.adf.share.security.JAASInitialContextFactor
y"

jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurityContext"
.
authorizationEnforce="false"
authenticationRequire="true"/
</sec:adf-security-child>
<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
<mds-config version="11.1.1.000"
xmlns="http://xmlns.oracle.com/mds/config">
<type-config>
<type-definitions>
<classpathschema/Exclusion.xsd/classpath>
<classpathschema/Incompatibility.xsd/classpath>
<classpathschema/JobDefinition.xsd/classpath>
<classpathschema/JobSet.xsd/classpath>
<classpathschema/JobType.xsd/classpath>
<classpathschema/Schedule.xsd/classpath>
<classpathschema/Specialization.xsd/classpath>
<classpathschema/Trigger.xsd/classpath>
<classpathschema/TriggerExpression.xsd/classpath>
<classpathschema/WorkAssignment.xsd/classpath>
<classpathschema/Workshift.xsd/classpath>
</type-definitions>
</type-config>
<persistence-config>
<metadata-namespaces>
<namespace path="/oracle/as/ess/core"
metadata-store-usage="ess-core"/>
namespace path="/oracle/apps/ess"
metadata-store-usage="demo-app"/>
</metadata-namespaces>
<metadata-store-usages>
<metadata-store-usage id="ess-core" deploy-target="false"
default-cust-store="false">
<metadata-store
class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
<property name="jndi-datasource" value="jdbc/mds-ESS_MDS_DS"/>
<property name="repository-name" value="mds-ESS_MDS_DS"/>
<property name="partition-name"
value="essapp-internal-partition"/>
</metadata-store>
</metadata-store-usage>
metadata-store-usage id="demo-app" deploy-target="true"
default-cust-store="false">
<metadata-store
class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
<property name="jndi-datasource" value="jdbc/mds-ESS_MDS_DS"/>
<property name="repository-name" value="mds-ESS_MDS_DS"/>
<property name="partition-name" value="essUserMetadata"/>
</metadata-store>
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>
</mds-config>
</adf-mds-config>
</adf-config>

7.4.2.8 Oracle Enterprise Schedulerのフロントエンドの発行者アプリケーションのアセンブル

フロントエンドのサンプル・アプリケーションを作成した後、Oracle JDeveloperを使用してアプリケーションをアセンブルします。

フロントエンドのアプリケーションをアセンブルするには、次を実行します:

- EJB Javaアーカイブの作成

- WARファイルの作成

- アプリケーションMARおよびEARファイルの作成

7.4.2.8.1 フロントエンドの発行者アプリケーションのEJB JARファイルをアセンブルする方法

EJB Javaアーカイブ・ファイルには、Javaジョブ実装のディスクリプタが含まれています。

フロントエンドの発行者アプリケーションのEJB JARファイルをアセンブルする手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」で、SuperEssプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「EJB JARファイル」を選択して、「OK」をクリックします。

3. 「デプロイメント・プロファイルの作成」ダイアログで、「デプロイメント・プロファイル名」をJAR_SuperEssEjbJarに設定します。

4. 「EJB JARデプロイメント・プロファイルのプロパティの編集」ダイアログで、「OK」をクリックします。

5. デフォルトで作成されるJARプロファイルを削除します。EJBとWARのみを含めます。

6. 「プロジェクト・プロパティ」ダイアログで、「OK」をクリックします。

7.4.2.8.2 フロントエンドの発行者アプリケーションのWARファイルをアセンブルする方法

WebアプリケーションのWebアーカイブ・ファイルを作成する必要があります。

フロントエンドの発行者アプリケーションのWARファイルをアセンブルする手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」で、SuperWebプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「WARファイル」を選択して、「OK」をクリックします。

3. 「デプロイメント・プロファイルの作成」ダイアログで、「デプロイメント・プロファイル名」をWAR_SuperWebWarに設定します。

4. 「WARデプロイメント・プロファイルのプロパティの編集」ダイアログで「一般」ナビゲーション・タブをクリックし、「Java EE Webコンテキスト・ルートを指定」を選択してESSDemoAppUIと入力します。

5. 「OK」をクリックします。

6. 「プロジェクト・プロパティ」ダイアログで、「OK」をクリックします。

7.4.2.8.3 フロントエンドのホスティング・アプリケーションのMARおよびEARファイルをアセンブルする方法

サンプル・アプリケーションには、EssDemoAppのバックエンドのアプリケーションをアセンブルするMARプロファイルおよびEARファイルが含まれている必要があります。

フロントエンドの発行者アプリケーションのMARおよびEARファイルを作成する手順は、次のとおりです。

1. メイン・メニューから、「アプリケーション・メニュー」→「アプリケーションのプロパティ」を選択します。

2. 「アプリケーションのプロパティ」ダイアログで、「デプロイメント・プロファイル」にリストされているプロファイルを削除して「新規」をクリックします。

3. 「デプロイメント・プロファイルの作成」ダイアログで「プロファイル・タイプ」ドロップダウン・リストから「MARファイル」を選択します。

4. 「名前」フィールドにMAR_EssDemoAppUIMarと入力し、「OK」をクリックします。

5. 「OK」をクリックします。

6. 「アプリケーションのプロパティ」ダイアログの「デプロイメント」ページで、「新規」をクリックします。

7. 「デプロイメント・プロファイルの作成」ダイアログで「プロファイル・タイプ」ドロップダウン・リストから「EARファイル」を選択します。

8. 「名前」フィールドにEAR_EssDemoAppUIEarと入力し、「OK」をクリックします。

9. 「EARデプロイメント・プロファイルのプロパティの編集」ダイアログで「一般」ナビゲーション・タブをクリックし、「アプリケーション名」フィールドにEssDemoAppUIと入力します。

10. WAR_SuperWebWarを選択します。

11. 「アプリケーション・アセンブリ」ナビゲーション・タブをクリックし、「MAR_ESSDemoAppUIMar」を選択して「JAR_SuperEssEjbJar」を選択します。

12. 「OK」をクリックします。

13. 「アプリケーションのプロパティ」ダイアログで、「OK」をクリックします。

7.4.2.8.4 ADFライブラリの追加

「プロジェクト・プロパティ」→「SuperWeb」→「ライブラリとクラスパス」ウィンドウに移動します。「ライブラリの追加」ボタンを使用して、次のライブラリを追加します。

- ADF共通ランタイム

- ADF Facesランタイム11

- ADF共通Webランタイム

- ADFページ・フロー・ランタイム

- ADFコントローラ・スキーマ

- ADFコントローラ・ランタイム

7.4.2.8.5 アプリケーションのOracle Enterprise Schedulerプロパティの設定

次の手順は、Oracle Enterprise Schedulerプロパティの値を設定する方法を示しています。

1. 「アプリケーション・ナビゲータ」でSuperEssプロジェクトを右クリックし、「エンタープライズ・スケジューラ・プロパティ」をクリックします。

2. 「Enterprise Schedulerのプロパティ」ダイアログで、次の3つのフィールドすべての値としてEssDemoAppUIを入力します。

- 論理アプリケーション名

- アプリケーション・ポリシー・ストライプ

- JPSインターセプタ・アプリケーション名

3. 「OK」をクリックします。

7.4.2.9 weblogic-application.xmlファイルの構成

ソース・エディタを使用して、weblogic-application.xmlから次の行を削除します。

<library-ref
<library-name>oracle.xdo.runtime</library-name>
</library-ref>
<library-ref>
<library-name>oracle.applcp.runtime</library-name>
</library-ref>

7.4.2.10 フロントエンドの発行者アプリケーションのデプロイ

アプリケーションをアセンブルした後、サーバーにデプロイできます。

フロントエンドの発行者アプリケーションをデプロイする手順は、次のとおりです。

1. メイン・メニューから、「アプリケーション」→「デプロイ」→「EAR_EssDemoUIEar...」の順に選択します。

2. アプリケーションをコンテナに設定し、デプロイします。

3. 「デプロイメント構成」ダイアログで、「共有メタデータ・リポジトリ」パネルに2つのエントリがあります。/oracle/apps/ess/howtoネームスペースにマップされた共有リポジトリを見つけます。そのパーティションを、EssDemoAppのデプロイ時に使用したパーティションに変更します。デフォルト値を使用した場合、これはEssDemoApp_V2.0になります。

図7-23 「Oracleデプロイメント構成」ウィンドウ

4. 「OK」をクリックします。

7.4.2.11 EssHost MANIFESTファイルの更新

EssHost META-INF/MANIFEST.INFファイルのコンテンツを次の行と置き換えます。

Manifest-Version:1.0 Weblogic-Application-Version: 3.0
Extension-List: essruntime
essruntime-Extension-Name: oracle.ess.runtime
essruntime-Specification-Version: 12

7.4.2.12 分割されたアプリケーションの実行

分割されたアプリケーションを実行する手順は、次のとおりです。

1. ブラウザに次のURLを入力します。

http://host:http-port:/ESSDemoAppUI/essdemoappservlet

次に例を示します。

http://myserver.example.com:7101/EssDemoAppUI/essdemoappservlet

2. パスワードwelcome1を使用してEssDemoAppUserとしてログインします。

3. 組み合されたアプリケーションと同じ手順に従います。

8 メタデータ・サービスの使用

この章では、Oracle Enterprise Schedulerメタデータ・サービスを使用して、スケジュール、ジョブ定義およびその他のOracle Enterprise Schedulerメタデータをメタデータ・ストアに作成し、更新および管理する方法について説明します。メタデータ・サービス問合せメソッドを使用して、メタデータ・リポジトリ内に格納されているオブジェクトをリストすることもできます。

この章の内容は次のとおりです。

- メタデータ・サービスの使用の概要

- メタデータ・サービスへのアクセス

- Oracle JDeveloperを使用したメタデータ・サービスへのアクセス

- メタデータ・サービスを使用したメタデータの問合せ

ジョブ定義の作成方法の詳細は、「PL/SQLジョブの作成と使用」および「プロセス・ジョブの作成と使用」の章を参照してください。

8.1 メタデータ・サービスの使用の概要

Oracle Enterprise Schedulerでは、メタデータ・サービスを提供し、使用するアプリケーション・プログラムに対して、ステートレス・セッションEnterprise Java Bean (EJB)として公開します。メタデータ・サービスを使用すると、アプリケーション・レベルのメタデータ・オブジェクトを作成、更新および管理できます。

メタデータ・サービスでは、Oracle Metadata Services (MDS)を使用してメタデータ・オブジェクトをリポジトリに保存します(データベース・ベースまたはファイル・ベースのいずれかのリポジトリを使用できます)。メタデータ・サービスを使用すると、複数のジョブ・リクエストの発行をまたいで、アプリケーション・レベルのメタデータを再使用できます。

Oracle Enterprise Schedulerのメタデータ・オブジェクトには、次のものがあります。

- アプリケーション・レベル・メタデータ: メタデータ・サービスを使用して、ジョブ・リクエストに対するジョブ・タイプ、ジョブ定義、ジョブ・セットおよびその他のアプリケーション・レベルのメタデータ・オブジェクト定義を格納します。

- デフォルト(グローバル) Oracle Enterprise Schedulerメタデータ: グローバルOracle Enterprise Schedulerメタデータには、スケジュール、作業シフト、作業割当てなどの管理オブジェクトが含まれます。Oracle Enterprise Schedulerには、デフォルトの管理オブジェクトにアクセスして格納するために、MetadataServiceMXBeanおよびMetadataServiceMXBeanProxyが備えられています。

注意:

Oracle Enterprise Schedulerメタデータ・オブジェクトは、アプリケーション・レベルのメタデータとグローバル・メタデータの両方で使用されます。

アプリケーション・レベル・メタデータ・オブジェクトへのアクセスは、MetadataServiceインタフェースでのみ公開されます。MetadataServiceはステートレス・セッションEJBとして公開されます。外部クライアントは、対応するEJBを使用してサービスにアクセスする必要があります。クライアントは内部API層と直接相互作用できません。アプリケーション・クライアントが、ステートレス・セッションEJB経由でメタデータ・サービスを使用する場合、複数のメソッドが1つのユーザー・トランザクション内でコールされるときなどに、複数のコールをまたいで状態を格納するMetadataServiceHandle引数への参照が、このインタフェース内のすべてのメソッドによって受け取られます。MBeanProxyインタフェースでは、ハンドルは必要ありません。

Oracle Enterprise Schedulerアプリケーションでは、MetadataServiceHandleにアクセスしたり操作する必要はありません。アプリケーションで行う必要があるのは、openメソッドによって作成される参照を保持し、コールされるメソッドにそれを渡すことです。最後に、closeメソッドをコールしてハンドルを明示的にクローズする必要があります。特定のハンドルを使用して加えられたすべての変更は、closeメソッドをコールすることによってのみコミット(または中断)されます。

メタデータ・オブジェクト名は、特定のパッケージまたはネームスペースのスコープ内で一意である必要があります。特定のパッケージ内に、同じ名前を持つ、同じタイプの2つのメタデータ・オブジェクトを作成することはできません。

8.1.1 メタデータ・サービス・ネームスペースの概要

各Oracle WebLogic Serverドメインには通常、1つのメタデータ・リポジトリが含まれます。メタデータ・リポジトリは複数のパーティションに分割され、各パーティションはリポジトリ内の他のパーティションから独立し、分離しています。

アプリケーションごとに、使用するパーティションを選択できます。2つのアプリケーションで1つのパーティションを共有することもできます。

パーティション内では、データを任意の方法で編成できます。通常、データはオペレーティング・システムのファイル・システムのように階層的に編成されます。ファイル・システムで使用されるフォルダやディレクトリのかわりに、メタデータ・サービスでは、ファイルを見つけるために使用される一意の名前を形成するネームスペースまたはパッケージ名を使用します。

その他すべてのOracle Enterprise Schedulerアプリケーションでは、アプリケーション・レベルのメタデータを含むアプリケーション名およびオプションのパッケージ名がネームスペース/oracle/apps/essの下に表示されます。たとえば、application1という名前のアプリケーションのメタデータ・リポジトリをdev、testおよびproductionという名前のパッケージに分割できます。

このアプリケーションのメタデータ・リポジトリの構造は、次のようになります。

/oracle/apps/ess/application1/dev/metadata
/oracle/apps/ess/application1/test/metadata
/oracle/apps/ess/application1/production/metadata

メタデータ・オブジェクトを作成する各メタデータ・サービス・メソッドでは、ディレクトリ構造のパッケージ部分を指定する必須のpackageName引数を使用します。

8.1.2 メタデータ・サービス操作の概要

Oracle Enterprise Schedulerメタデータ・リポジトリにアクセスすると、次を含む、様々なタイプのメタデータ・サービス操作を実行できるようになります。

- 追加、更新、削除: これらの操作はトランザクション特性を持ちます。

- コピー: これらの操作はトランザクション特性を持ちます。

- 問合せ: これらの操作は読取り専用特性を持ち、メタデータ・リポジトリ内のメタデータ・オブジェクトをリストできます。

- 取得: これらの操作は、forUpdateフラグの値に応じて、読取り専用特性またはトランザクション特性のいずれかを持ちます。

8.1.3 メタデータ・サービス・トランザクションの概要

クライアントはステートレス・セッションEJB経由でメタデータ・サービスにアクセスするため、各メソッドでMetadataServiceHandle引数への参照が使用されます。この引数には、メタデータ・サービス操作の状態が格納されます。メタデータ・サービスのopen()メソッドにより、各メタデータ・リポジトリのユーザー・トランザクションが開始されます。Oracle Enterprise Schedulerアプリケーション・クライアントでは、open()メソッドによりMetadataServiceHandle参照を取得し、後続のメタデータ・サービス・メソッドにこの参照を渡します。MetadataServiceHandle参照によって、コール側アプリケーションのメタデータ・リポジトリへの接続が提供されます。

メタデータ・サービスを使用するクライアント・アプリケーションでは、close()をコールして、メタデータ・サービス・トランザクションを明示的に閉じる必要があります。これによりトランザクションが終了し、トランザクションがコミットまたはロールバック(取消し)されます。close()はメタデータ・サービス内のトランザクション動作を制御するだけでなく、Oracle Enterprise Schedulerにより特定のリソースを解放できるようにします。このため、close()はメタデータ・サービスの読取り専用query()およびget()操作でも必須となります。

注意:

メタデータ・サービスではJTAグローバル・トランザクションはサポートされませんが、トランザクションの境界でメタデータ・サービス・コールを行うことはできます。Beanまたはコンテナ管理のトランザクションでメタデータ・サービス・コールを行うことはできますが、このコールはトランザクションの一部ではありません。

8.2 メタデータ・サービスへのアクセス

メタデータ・サービスにアクセスするには、いくつかの方法があります。

メタデータ・サービスにアクセスする手順は次のとおりです。

- ステートレス・セッションEJBアクセス: Oracle Enterprise Schedulerユーザー・アプリケーションではこのタイプのアクセスを使用します。

- MBeanアクセス: このアクセスは、oracle.as.scheduler.management APIを使用して管理機能を実行するアプリケーションで使用されます。

- MBeanプロキシ・アクセス: このアクセスは、oracle.as.scheduler.management APIを使用して管理機能を実行するアプリケーションで使用されます。管理クライアントがOracle Enterprise Schedulerに対してリモートにある場合は、MBeanプロキシを使用します。

8.2.1 ステートレス・セッションEJBを使用してメタデータ・サービスにアクセスする方法

ユーザー・アプリケーションでは、アプリケーション・レベルのメタデータ操作を行うために、ステートレス・セッションEJBを使用してメタデータ・サービスにアクセスします。ユーザーは、JNDIを使用してOracle Enterprise Schedulerアプリケーションに関連付けられているメタデータ・サービスを参照できます。

例8-1に、アプリケーション・レベルのメタデータを使用できるようにする、Oracle Enterprise Schedulerメタデータ・サービスのJNDIルックアップを示します。getMetadataServiceEJB()メソッドでは、名前"ess/metadata"を使用してメタデータ・サービスを参照することに注意してください。通常、Oracle Enterprise Schedulerアプリケーションでは、MetadataServiceBeanへのEJB参照に"ess/metadata"を使用します。

例8-1 メタデータ・サービスへのステートレス・セッションEJBアクセスのためのJNDIルックアップ

// Demonstration on how to lookup metadata service from a Java EE application
// JNDI lookup on the metadata service EJB

import oracle.as.scheduler.core.JndiUtil;

MetadataService ms = JndiUtil.getMetadataServiceEJB();

8.3 Oracle JDeveloperを使用したメタデータ・サービスへのアクセス

設計時に、Oracle JDeveloperを使用して、アプリケーション・レベルのメタデータ・オブジェクトを作成、表示および更新できます。

8.4 メタデータ・サービスを使用したメタデータの問合せ

メタデータ・サービスの問合せメソッドを使用すると、メタデータ・リポジトリ内のオブジェクトを表示できます。

queryJobTypes()メソッドを使用してジョブ・タイプの問合せを、queryJobDefinitions()メソッドを使用してジョブ定義の問合せを実行でき、その他のメタデータ・オブジェクトについても同様に対応するMetadataService問合せメソッドを使用して問合せを実行できます。

問合せと組み合せてフィルタを使用し、必要な項目のみを取得するように出力を制限できます(SQL WHERE句を使用する場合と同様の方法で)。

8.4.1 フィルタの作成方法

フィルタにより、問合せの比較または条件を指定します。フィルタは、field引数(String)、comparatorおよび関連するvalue(Object)を含む比較を作成することにより作成します。フィルタでは、フィルタ・メソッドを使用して比較を組み合せてフィルタ式を作成できます。

表8-1に比較演算子(comparator引数)をリストします。

表8-1 フィルタ比較演算子

比較演算子

説明

CONTAINS

フィールドに指定された値が含まれる

ENDS_WITH

フィールドが指定された値で終了する

EQUALS

フィールドが指定された値に等しい

GREATER_THAN

フィールドが指定された値より大きい

GREATER_THAN_EQUALS

フィールドが指定された値以上

LESS_THAN

フィールドが指定された値未満

LESS_THAN_EQUALS

フィールドが指定された値以下

NOT_CONTAINS

フィールドに指定された値が含まれない

NOT_EQUALS

フィールドが指定された値と等しくない

STARTS_WITH

フィールドが指定された値で始まる

例8-2に、新しいフィルタを作成するコードを示します。

表8-2 MetadataService問合せフィールド

問合せフィールド

説明

MetadataService.QueryField.PACKAGE

パッケージの名前。

MetadataService.QueryField.NAME

ジョブ定義名。

MetadataService.QueryField.JOBTYPE

ジョブ定義に関連付けられているジョブ・タイプ。

MetadataService.QueryField.EXECUTIONTYPE

ジョブ実行タイプ(同期または非同期)。

MetadataService.QueryField.REQUEST_CATEGORY

リクエスト・カテゴリの名前。

MetadataService.QueryField.EXECUTIONMODE

ジョブ・セット実行モード(パラレルまたはシリアル)。

MetadataService.QueryField.FIRSTSTEP

ジョブ・セットの最初のステップ。

MetadataService.QueryField.ACTIVE

作業割当てがアクティブかどうかを示します。

MetadataService.QueryField.PRODUCT

ジョブが関連付けられている製品の名前を示します。

MetadataService.QueryField.EFFECTIVEAPPLICATION

このジョブが実行されるホスティング・アプリケーションの名前。

MetadataService.QueryField.LOGICAL_CLUSTER_NAME

ジョブに関連付けられる論理クラスタ。

例8-2 問合せに対するフィルタ・コンパレータを使用したフィルタの作成

Filter filter =
new Filter(MetadataService.QueryField.PACKAGE.fieldName(),
Filter.Comparator.NOT_EQUALS, null);

8.4.2 メタデータ・オブジェクトの問合せ方法

MetadataService問合せにより、MetadataObjectIDsの列挙リストが次の形式で返されます。

java.util.Enumeration<MetadataObjectId>

例8-3に、メタデータ内のジョブ・タイプのリストを問い合せるサンプル・ルーチンを示します。

例8-3には、queryJobTypes()メソッドを使用するための次の重要なステップが示されています。

- MetadataServiceHandleのインスタンスを取得して、メタデータ・リポジトリへの参照を提供する必要があります。

- 問合せのフィルタを作成する必要があります。フィルタには、フィールド、コンパレータおよび検索対象の値が含まれます。

- 問合せでのソート基準として使用するフィールドをorderBy引数を使用して決定するか、orderBy引数をNULLに設定して特定の順序付けが適用されないことを示します。

- 問合せにascending引数を設定します。結果リストに順序付けが適用される場合、ascending引数をtrueに設定して昇順を指定するか、falseに設定して降順を指定します。

例8-3 メタデータ・サービスの問合せメソッドの使用

Enumeration<MetadataObjectId> qryResults
= m_service.queryJobTypes(handle, filter, null, false);

9 パラメータとシステム・プロパティの使用

この章では、Oracle Enterprise Schedulerメタデータおよびジョブ・リクエストで発行するランタイム・サービスで、パラメータと値を定義する方法について説明します。特定のパラメータが、Oracle Enterprise Schedulerシステム・プロパティの値またはアプリケーション定義のプロパティの値を表すことがあります。

この章の内容は次のとおりです。

- パラメータとシステム・プロパティの使用の概要

- メタデータ・サービスでのパラメータの使用

- ランタイム・サービスでのパラメータの使用

- システム・プロパティの使用

9.1 パラメータとシステム・プロパティの使用の概要

Oracle Enterprise Schedulerシステム・プロパティは、Oracle Enterprise Schedulerによって予約された名前を持つパラメータです。一部のシステム・プロパティについては、ユーザーが値を指定しなかった場合の値が定義されているか、デフォルト値が提供されます。

Oracle Enterprise Schedulerパラメータは次のように定義できます。

- ジョブ定義、ジョブ・タイプまたはジョブ・セットに関連付けられているメタデータで。

- ジョブ・リクエストの発行時に、リクエスト・パラメータで。リクエスト・パラメータでは、メタデータで指定されているパラメータをオーバーライドしたり、ジョブ・リクエストに関連付けられているメタデータで事前に定義されていないパラメータの値を指定できます(一定の制約が適用されます)。また、ジョブ・リクエストが発行された後に、新しいパラメータを追加したり、パラメータ値を更新することもできます(一定の制約が適用されます)。

Oracle Enterprise Schedulerシステム・プロパティの詳細は、「システム・プロパティの使用」を参照してください。

9.1.1 アプリケーション定義のプロパティおよびシステム・プロパティのネーミングに関する必知事項

Oracle Enterprise Schedulerアプリケーション定義のプロパティおよびシステム・プロパティでは、大文字と小文字が区別されます。たとえば、アプリケーション定義のプロパティ名USER_PARAおよびuser_paraは、Oracle Enterprise Schedulerでは異なるパラメータを表します。

アプリケーション定義のプロパティを使用する場合、Oracle Enterprise Schedulerでは、Oracle Enterprise Scheduler定義のシステム・プロパティ用に、"SYS_"で始まる名前(大文字と小文字を区別しません)が予約されていることに注意してください。このため、"SYS_"で始まる名前(大文字と小文字を区別しません)を持つアプリケーション定義のプロパティは使用できません。

9.1.2 パラメータの競合解決方法およびパラメータのマテリアライズに関する必知事項

Oracle Enterprise Schedulerでは、ジョブ・リクエストを発行するときに、ジョブ・メタデータで指定されたパラメータとすべての発行パラメータを組み合せて、ランタイム・リクエスト・パラメータを作成します。ランタイム・パラメータはデータベース・ランタイム・ストアに保存され、リクエストの後続処理で使用されます。メタデータ・パラメータは、発行時におけるメタデータ・リポジトリでの定義に従い、ジョブ定義、ジョブ・タイプ、および該当する場合はジョブ・セットから取得されます。その後、リクエストが処理されるときに、メタデータに変更が加えられたり、使用されることは通常ありません。Oracle Enterprise Schedulerにより、ジョブ・メタデータまたは発行パラメータに関連付けられている名前と同じ名前を持つパラメータの競合が解決されます。

パラメータの競合は、次の場合に発生することがあります。

- パラメータが異なる値で繰り返し定義される場合。たとえば、リクエストに関連付けられているジョブ・タイプとジョブ定義とで、SystemProperty.PRIORITYプロパティが異なる値で設定される場合です。

- パラメータが繰り返し定義され、少なくとも1つの定義でParameterInfo readonlyフラグがtrueに設定されて読取り専用として指定されている場合。

パラメータの競合を解決するために、Oracle Enterprise Schedulerでは次のいずれかの競合解決モデルおよび表9-1に示されているパラメータ値継承階層を使用します。

- 最後の定義優先: 同じパラメータが、すべてのケースでreadonlyフラグがfalseに設定されて繰り返し定義されている場合に使用されます。最後の定義優先モデルでは、最上位レベル(最後の定義)が優先されるという優先順位ルールに従って競合が解決されます。たとえば、ジョブ・リクエスト・レベルで指定されたプロパティは、ジョブ定義レベルで指定された同じプロパティより優先されます。

- 最初の読取り専用定義優先: 同じパラメータが繰り返し定義され、少なくとも1つの定義が読取り専用である(ParameterInfo readonlyフラグがtrueに設定されている)場合に使用されます。最初の読取り専用定義優先モデルでは、表9-1に示されている優先順位ルールに従ってパラメータの競合が解決され、最下位レベルが優先されます。たとえば、ジョブ・タイプ定義レベルで指定された読取り専用パラメータは、ジョブ定義レベルで指定された同じプロパティよりも、それが読取り専用かどうかに関係なく優先されます。

表9-1 パラメータの優先順位レベル

オブジェクト

レベル

JobType

1 - 最下位レベル

JobDefinition

2

Job set step

3

job set

4

ジョブ・リクエスト(submitRequest()に渡されるRequestParametersを使用)

5 - 最上位レベル

9.1.2.1 ジョブ定義パラメータのマテリアライズに関する必知事項

図9-1に、様々なコンポーネントで定義されるパラメータによって採用される、優先順位の順序を示します。

図9-1 パラメータの優先順位

ジョブ・リクエストの場合は、ジョブ・タイプによって定義されるパラメータの優先順位が最も高く、その次がジョブ定義で定義されるパラメータとなります。ジョブ・リクエストとともに発行されるパラメータが最も低い優先順位を取ります。ジョブ・セット・リクエストの場合は、ジョブ・セットによって定義されるパラメータの優先順位が最も高く、その次がジョブ・セットの子として実行されるジョブ・リクエストによって定義されるパラメータとなります。

9.1.2.2 ジョブ・セット・レベル・パラメータのマテリアライズに関する必知事項

ジョブ・セット・ステップ・パラメータがマテリアライズされるとき、ジョブ・セットで次のいずれかのシステム・プロパティが読取り専用として定義されており、かつ、それらのプロパティが最上位のジョブ・セット、つまり絶対親のジョブ・セットの定義内で定義されている場合は、ジョブ・セット・ステップ・レベルで設定された値が、ジョブ・セット値によってオーバーライドされます。これにより、特定のジョブ・セットのコンテキスト内で実行されるすべての定義、ジョブ定義またはジョブ・セット定義が、同じ値を使用して実行されるようになります。

PRIORITY

REQUEST_EXPIRATION

RETRIES。ステップ定義値が0より大きい場合のみ。

0の値はジョブを再起動できないことを意味する場合があるため、RETRIESには例外があります。つまり、ステップがRETRIES = 0と定義されている場合、これはオーバーライドされず、ステップがRETRIES > 0と定義される場合には、ジョブ・セット値によってオーバーライドされます。

ジョブ・セット・ステップ・リクエストのプロパティのマテリアライズは、ジョブ・セットの処理中に、そのステップに到達したときに実行されます。ジョブ・ステップ・リクエストのプロパティは、次の順序でマテリアライズされます。

1. ジョブ・タイプおよびジョブ定義(ステップがジョブ定義の場合)またはジョブ・セット(ステップがジョブ・セットの場合)

2. ジョブ・セット・ステップ。

3. 親リクエスト・プロパティおよびシステム・プロパティ(親はステップの親ジョブ・セット)

4. 有効範囲のあるリクエスト・プロパティ。

例9-2に、ジョブ・セット・ステップのパラメータの優先順位を示します。

図9-2 ジョブ・セット・ステップのパラメータの優先順位

ジョブ・セットにジョブ・セットであるステップが含まれる場合、これはネストされたジョブ・セットです。ネストされたジョブ・セットには、表9-1に示されている優先順位が適用されます。ネストされたジョブ・セットに到達すると、Oracle Enterprise Schedulerにより親リクエストのパラメータが適用され、親リクエストのパラメータは同じ優先順位に従います。これにより、親リクエスト、ジョブ・セットおよびジョブ・セット・ステップのパラメータが、ネストされたジョブ・セットによって継承されます。

9.2 メタデータ・サービスでのパラメータの使用

Oracle Enterprise Schedulerメタデータには、メタデータ・オブジェクトに関連付けることができるパラメータが含まれます。パラメータには、アプリケーション定義のプロパティと特定の定義(メタデータ・オブジェクト)のシステム・プロパティの両方を含めることができます。

ParameterListクラスのインスタンスによって、特定のジョブ定義、ジョブ・タイプまたはジョブ・セットのパラメータが宣言されます。特定のジョブ定義、ジョブ・タイプまたはジョブ・セット定義のパラメータを設定するには、ParameterListオブジェクトをメタデータ・オブジェクトのsetParameters()メソッドとともに使用するか、コンストラクタを使用してParameterListを提供します。パラメータ・リストにパラメータ情報を提供するために、各ParameterListオブジェクトには、パラメータを表すParameterInfoオブジェクトが含まれています。各パラメータは、表9-2に示されているプロパティを使用して定義されます。

表9-2 ParameterInfoパラメータ・プロパティ

パラメータ・プロパティ

説明

名前

パラメータ名を指定します。

値

パラメータ値を指定します。

Readonly

このブール・フラグは各パラメータに設定できます。このフラグは、パラメータが読取り専用であるかどうかを示します。

trueの場合、パラメータの優先順位階層内にある後続オブジェクト(リクエスト発行パラメータなど)で、パラメータ値を変更できません。通常、読取り専用パラメータには、後続オブジェクトで変更できないデフォルト値が設定されます。

読取り専用パラメータの値は、このパラメータが定義されているオブジェクト自体では変更できます。たとえば、このパラメータがジョブ・タイプ内で読取り専用パラメータとして定義されている場合、その値はジョブ・タイプ定義自体では変更できますが、そのジョブ・タイプを使用するジョブ定義やリクエスト発行パラメータで値をオーバーライドすることはできず、パラメータ値に指定された競合解決ルールが適用されます。詳細は、「パラメータの競合解決方法およびパラメータのマテリアライズに関する必知事項」を参照してください。

Legacy

GUIで使用される場合にパラメータを表示するかどうかを指定するブール値。

DataType

値には、サポートされているいずれかの型(Boolean、Integer、Long、Stringおよび日付をjava.util.Calendarオブジェクトとして表すDATETIME)のみを指定できます。

ジョブ・リクエストのパラメータの優先順位に適した異なるレベルでパラメータを設定できます。たとえば、ジョブ・タイプ、ジョブ定義、ジョブ・セット、ジョブ・セット・ステップまたはリクエスト発行パラメータに適用されるパラメータを設定できます。優先順位ルールの詳細は、「パラメータの競合解決方法およびパラメータのマテリアライズに関する必知事項」を参照してください。

9.2.1 メタデータ・オブジェクトでのパラメータとシステム・プロパティの使用方法

例9-1に、ParameterListを使用して、メタデータ・オブジェクトでパラメータとシステム・プロパティの値を設定するコードを示します。

例9-1には、メタデータ・オブジェクトでパラメータを使用するための次の重要なステップが示されています。

- パラメータを追加するメタデータ・オブジェクトを作成するには、メタデータ・サービス・ハンドルへの参照が必要です。

- パラメータ情報を追加するには、ParameterList add()メソッドを使用する必要があります。

- SystemPropertyをパラメータの名前として使用して、システム・プロパティの値を指定できます。

- ParameterListのパラメータ情報で定義した名前を使用して、アプリケーション定義のプロパティを指定できます。

- ParameterListで指定されたパラメータをメタデータ・オブジェクトに適用するには、メタデータ・オブジェクトのsetParameters()メソッドを使用する必要があります。この場合、ジョブ定義のsetParameters()メソッドを使用します。

例9-1 メタデータ・オブジェクトでのパラメータおよびシステム・プロパティの追加

String name = "JobDescription_name";
MetadataObjectId jobtype;
.
.
.
JobDefinition jd = new JobDefinition(name, jobtype);
ParameterList parlist = new ParameterList();
parlist.add(SystemProperty.APPLICATION, "METADATA_UNITTEST_APP", false);
parlist.add(SystemProperty.PRODUCT, "METADATA_UNITTEST_PROD", false);
parlist.add(SystemProperty.CLASS_NAME, "oracle.as.scheduler.myself", false);
parlist.add(SystemProperty.RETRIES, "2", false);
parlist.add(SystemProperty.REQUEST_EXPIRATION, "60", false);
parlist.add("MyProp", "Value", false);
parlist.add("MyReadOnlyProp", "readyOnlyValue", true);
jd.setParameters(parlist);

9.3 ランタイム・サービスでのパラメータの使用

RequestParametersオブジェクトをsubmitRequest()とともに指定して、ジョブ・リクエストを発行するときのパラメータを指定できます。リクエスト・パラメータでは、メタデータで指定されているパラメータをオーバーライドしたり、ジョブ・リクエストに関連付けられているメタデータで事前に定義されていないパラメータの値を指定できます(一定の制約が適用されます)。

ランタイム・サービスのsetRequestParameter()メソッドを使用して、リクエストが発行された後にリクエスト・パラメータを設定または変更することもできます(一定の制約が適用されます)。

submitRequest()メソッドでは、メタデータ内にリクエスト・パラメータの定義が存在する場合に、各リクエスト・パラメータをその定義に対して検証します。このような検証には、メタデータで指定されたデータ型に対するパラメータのデータ型の検証、パラメータの読取り専用制約の検証などがあります。指定されたリクエスト・パラメータが対応するメタデータ内に存在しない場合、そのパラメータのデータ型は、パラメータ値にinstanceofを適用することによって決定されます。リクエスト・パラメータ値のデータ型は、ParameterInfo.DataTypeで指定されている、サポートされているいずれかの型である必要があります。

リクエスト・パラメータの値がNULLであり、メタデータ内でプロパティが割り当てられていない場合は、submitRequest()のコール時にデフォルトでSTRINGデータ型に設定されます。Oracle Enterprise Schedulerにより、パラメータにnull値が割り当てられます。そのため、メタデータ内でパラメータを割り当てる必要はありません。

RuntimeService setRequestParameter()メソッドは、事前に定義されていないリクエスト・パラメータをジョブにより実行中に設定できるようにします。

9.3.1 ランタイム・サービスでのパラメータの使用方法

ジョブ・リクエストを発行するとき、RequestParametersオブジェクトでパラメータを設定します。このパラメータは、Oracle Enterprise Schedulerシステム・プロパティまたはアプリケーション定義のプロパティを表すことがあります。RequestParametersパラメータ値を使用して、メタデータで指定されているパラメータをオーバーライドするか、ジョブ・リクエストに関連付けられているメタデータで事前に定義されていないパラメータの値を指定できます。

例9-2に、RequestParametersオブジェクトをadd()メソッドとともに使用して、システム・プロパティ値を設定するコードを示します。

この例では、rs_handleという名前でユーザーが作成したruntimeServiceHandleがあることを前提としています。

例9-2 PRIORITYシステム・プロパティとリクエスト・パラメータの使用

import oracle.as.scheduler.RequestParameters;
import oracle.as.scheduler.MetadataObjectId;
import oracle.as.scheduler.RuntimeService;
import oracle.as.scheduler.RuntimeServiceHandle;
import oracle.as.scheduler.SystemProperty;

RuntimeService runtime;
RuntimeServiceHandle rs_handle;
MetadataObjectId jobSetId;
int startsIn;
long requestID = 0L;

RequestParameters req_par = new RequestParameters();

req_par.add(SystemProperty.PRIORITY, new Integer(7));

Calendar start = Calendar.getInstance();
start.add(Calendar.SECOND, startsIn);

requestID =
runtime.submitRequest(rs_handle,"My job set", jobSetId, start, req_par);
.
.
.

9.3.2 ジョブ・セット・ステップのステップIDを含むパラメータの使用方法

RequestParametersオブジェクトは、リクエストのすべてのパラメータのコンテナです。一部のRequestParametersメソッドでは、引数としてステップIDを使用します。このようなメソッドを使用すると、リクエストを発行するときにジョブ・セットのパラメータを指定でき、パラメータは、ジョブ・セット・リクエストに関連付けられている個別のステップに指定またはスコープできます。このようなメソッドでは、ステップID引数によって、特定のパラメータが適用される、ジョブ・セット内のステップが識別されます。ジョブ・セット以外のリクエストでは、ステップIDは適用されませんが、アプリケーションの要件に応じてパラメータを使用できます。

add()などのRequestParametersメソッド内でステップIDを指定する場合は、次の形式でステップIDを指定する必要があります。

id1.id2.id3...

ここでは、完全修飾ステップIDによって、ジョブ・セット階層(ツリー)内の一意のステップ(ノード)が示されます。

ジョブ・セット・リクエスト内のステップIDを持たないパラメータはグローバル・パラメータとして処理され、ジョブ・セット・リクエストのそれぞれのステップに適用されます。RequestParametersのステップID引数により、共有パラメータがサポートされます。このパラメータは、ジョブ・セットと、ジョブ定義またはジョブ・タイプのいずれかの両方に適用できます。

Oracle Enterprise Schedulerにより、セパレータとしてコロンが使用されたstepId:nameという形式でステップIDが名前の前に付加され、一意の識別子が生成されます。

例9-3に、RequestParametersオブジェクトをadd()メソッドで指定されるステップIDとともに使用して、ジョブ・セット内のステップにシステム・プロパティ値を設定するコードを示します。

この例では、rs_handleという名前でユーザーが作成したruntimeServiceHandleがあることを前提としています。

例9-3 CLASS_NAMEシステム・プロパティとジョブ・セット・リクエスト・パラメータの使用

import oracle.as.scheduler.RequestParameters;
import oracle.as.scheduler.MetadataObjectId;
import oracle.as.scheduler.RuntimeService;
import oracle.as.scheduler.RuntimeServiceHandle;
import oracle.as.scheduler.SystemProperty;

RuntimeService runtime;
RuntimeServiceHandle rs_handle;
MetadataObjectId jobSetId;
int startsIn;
long requestID = 0L;

RequestParameters req_par = new RequestParameters();

req_par.add(SystemProperty.PRIORITY, "stepId-1", new Integer(8));
req_par.add(SystemProperty.PRIORITY, "stepId-2.stepId-1", new Integer(6));

Calendar start = Calendar.getInstance();
start.add(Calendar.SECOND, startsIn);

requestID =
runtime.submitRequest(rs_handle,"My job set", jobSetId, start, req_par);
.
.
.

9.4 システム・プロパティの使用

Oracle Enterprise Schedulerでは、SystemPropertyクラスで、システムによって認識され使用されるパラメータ名を表します。システム・プロパティは、アプリケーション・メタデータ内でパラメータ名として指定したり、リクエストを発行するときにリクエスト・パラメータを使用して指定できます。Oracle Enterprise Schedulerでは、リクエストが発行されたとき、またはリクエストのライフ・サイクルにおけるいずれかの時点で、特定のシステム・プロパティを設定します。

表9-3に、oracle.as.scheduler.SystemPropertyで定義される、使用可能なシステム・プロパティのリストを示します。ほとんどのシステム・プロパティはすべてのジョブ・タイプで共通ですが、表9-3の説明に示されているように、特定のジョブ・タイプに固有のシステム・プロパティもあります。

パラメータを使用する場合、Oracle Enterprise Schedulerでは、Oracle Enterprise Scheduler定義のプロパティ用に、"SYS_"で始まるパラメータ名(大文字と小文字を区別しません)が予約されていることに注意してください。

表9-3 システム・プロパティ

名前

説明

ALLOW_MULT_PENDING

同じジョブ定義の複数のリクエストの保留を許可するかどうかを指定します。このプロパティはジョブ・セット・ステップには影響しません。

型: BOOLEAN

APPLICATION

リクエストの処理に使用されるJava EEアプリケーションの論理名を指定します。このプロパティは、リクエスト送信時にOracle Enterprise Schedulerによって自動的に設定されます。

型: STRING

ASYNC_REQUEST_TIMEOUT

プロセッサが実行を開始した後に、非同期リクエストを待機する時間を分数で指定します。この期間が経過すると、リクエストはタイムアウトしたとみなされます。

型: LONG

BIZ_ERROR_EXIT_CODE

実行ビジネス・エラーを表す、プロセス・ジョブ・リクエストのプロセス終了コードを指定します。このプロパティが指定されていない場合、プロセス終了コード4は実行ビジネス・エラーとして処理されます。

このプロパティはプロセス・ジョブ・タイプではオプションです。他のジョブ・タイプでは使用されません。

型: STRING

CLASS_NAME

Javaジョブ・リクエストのJava実行可能ファイルを指定します。これは、oracle.as.scheduler.Executableインタフェースを実装するJavaクラスの名前である必要があります。このプロパティはJavaジョブ・タイプで必須です。他のジョブ・タイプでは使用されません。

型: STRING

CMDLINE

プロセス・ジョブ・リクエストに対して外部プログラムを起動するために使用されるコマンド行を指定します。

このプロパティはプロセス・ジョブ・タイプの必須プロパティです。他のジョブ・タイプでは使用されません。

型: STRING

CMDLINE_UNIX

UNIXまたはUNIXに類似したオペレーティング・システムでプロセス・タイプ・リクエスト実行可能ファイルを実行するための完全なコマンド行を指定します。一般的に、このプロパティはジョブ・タイプ内で指定され、実行可能ファイルの名前、パスおよび引数により、実行時に置換される値が指定されます。

次のプロパティEXECUTABLE_NAME、EXECUTABLE_DIR_UNIX、EXECUTABLE_SUFFIX_UNIX、PROCESS_ARGUMENTSを参照してください。

型: STRING

CMDLINE_WINDOWS

Windowsオペレーティング・システムでプロセス・タイプ・リクエスト実行可能ファイルを実行するための完全なコマンド行を指定します。一般的に、このプロパティはジョブ・タイプ内で指定され、実行可能ファイルの名前、パスおよび引数により、実行時に置換される値が指定されます。

プロパティEXECUTABLE_NAME、EXECUTABLE_DIR_WINDOWS、EXECUTABLE_SUFFIX_WINDOWS、PROCESS_ARGUMENTSを参照してください。

型: STRING

EFFECTIVE_APPLICATION

リクエストを処理するために使用される有効なアプリケーションであるJava EEアプリケーションの論理名を指定します。EFFECTIVE_APPLICATIONシステム・プロパティを定義することで、ジョブ定義、ジョブ・タイプまたはジョブ・セット・ステップを他のアプリケーションに関連付けることができます。このプロパティはメタデータでのみ指定できます。送信パラメータでは指定できません。

型: STRING

EJB_OPERATION_NAME

EJBの操作名を指定します。これは、適切なビジネス・メソッドに分岐するBean実装によって使用可能です。このプロパティは、EJBジョブ・タイプに使用されます。

型: STRING

ENVIRONMENT_VARIABLES

プロセス・ジョブ・リクエストの生成されたプロセスに対して設定する環境変数を指定します。プロパティ値は、設定される環境変数を表す名前/値ペア(name=value)のカンマ区切りリストである必要があります。

このプロパティはプロセス・ジョブ・タイプではオプションです。他のジョブ・タイプでは使用されません。

型: STRING

ESS_ASYNC_REQUEST_JNDI_MAPPED_NAME

Oracle Enterprise SchedulerサーバーのJNDIにバインドされる、Oracle Enterprise SchedulerのAsyncRequest EJBのマップされた名前を指定します。

型: STRING

ESS_JNDI_CSF_KEY_NAME

基礎となるOracle Enterprise SchedulerサーバーのJNDIプロバイダのCSF KEY名を示す名前を指定します。このプロパティは、ホスティング・アプリケーションのEssConfig内で設定できます。

型: STRING

ESS_RUNTIME_JNDI_MAPPED_NAME

Oracle Enterprise SchedulerサーバーのJNDIにバインドされる、Oracle Enterprise SchedulerのRuntimeService EJBのマップされた名前を指定します。このプロパティは、EJBジョブ・タイプに使用されます。

型: STRING

ESS_METADATA_JNDI_MAPPED_NAME

Oracle Enterprise SchedulerサーバーのJNDIにバインドされる、Oracle Enterprise SchedulerのMetadataService EJBのマップされた名前を指定します。

型: STRING

EXECUTABLE_NAME

プロセス・タイプ・リクエストの実行可能ファイルの名前を指定します。値には、実行可能ファイルのパスを含めないでください。

プロパティEXECUTABLE_DIR_UNIX、EXECUTABLE_DIR_WINDOWSを参照してください。

型: STRING

EXECUTABLE_DIR_UNIX

UNIXまたはUNIXに類似したオペレーティング・システムでのプロセス・タイプ・リクエスト用の実行可能ファイルが存在するディレクトリを指定します。

型: STRING

EXECUTABLE_DIR_WINDOWS

Windowsオペレーティング・システムでのプロセス・タイプ・リクエスト用の実行可能ファイルが存在するディレクトリを指定します。

型: STRING

EXECUTABLE_SUFFIX_UNIX

プロセス・タイプ・リクエスト用の実行可能ファイルのファイル拡張子を指定します(汎用のUNIXまたはUNIXに類似したオペレーティング・システムで実行される場合)。デフォルトは拡張子なしです。

型: STRING

EXECUTABLE_SUFFIX_WINDOWS

プロセス・タイプ・リクエスト用の実行可能ファイルのファイル拡張子を指定します(Windowsオペレーティング・システムで実行される場合)。デフォルトは拡張子なしです。

型: STRING

EXECUTE_AUTO_EXPORT

ジョブの実行ステージの実行前に、以前にインポート済のリクエストの出力コンテンツをリクエストの出力ディレクトリに自動的にエクスポートするかどうかを指定します。このプロパティは、プロセス、同期Javaおよび非同期Javaジョブ・タイプの実行ステージに適用できます。非同期Javaジョブ・タイプまたはPL/SQLジョブ・タイプの更新ステージには適用されません。

有効な値は次のとおりです。

- true: ジョブの実行ステージの前に、以前にインポート済のすべての出力コンテンツがリクエストの出力ディレクトリ内のファイルにエクスポートされます。

- false: 出力コンテンツは自動的にエクスポートされません。ジョブによって、出力コンテンツを手動でエクスポートすることが選択される場合があります。

このプロパティが指定されていない場合、システムのデフォルトであるfalseが使用されます。

型: BOOLEAN

EXECUTE_PAST

実行時間が過去である繰返しリクエストのインスタンスを生成するかどうかを指定します。インスタンスは、リクエスト開始時間の前およびリクエスト終了時間の後には生成されません。過去のインスタンスが生成されるようにするには、このプロパティをTRUEに設定し、リクエスト開始時間をインスタンス生成を開始する最初の時間として指定する必要があります。リクエスト開始時間がnullである場合、現在の時間にデフォルト設定されます。

このプロパティの有効な値は次のとおりです。

- TRUE: 生成時間に関係なく、スケジュールで指定されるすべてのインスタンスが生成されます。

- FALSE: スケジュールされた実行時間が過去の時間(つまり、生成時間より前)であるインスタンスは生成されません。

このプロパティが指定されていない場合、TRUEにデフォルト設定されます。

型: BOOLEAN

EXTERNAL_ID

非同期Javaジョブの外部部分の識別子を指定します。たとえば、非同期Javaジョブでは通常リモート・プロセスを起動してから、Oracle Enterprise Schedulerに制御を戻します。このプロパティはリモート・プロセスの識別に使用されます。このプロパティは、識別子の判明時に非同期Javaジョブのジョブ実装によって設定されます。Oracle Enterprise Schedulerによっては設定されません。

型: STRING

EXTERNAL_JOB_TYPE

ジョブのリモート・コンポーネントのタイプのインジケータを指定します。非同期Javaジョブ、WebServiceジョブまたはEJBジョブなどのリモート・コンポーネントを含むリクエストの場合、このプロパティはリモート・ジョブの性質を指定します。現在サポートされている外部ジョブ・タイプは、SystemProperty.ExternalJobTypeプロパティ内の要素の名前です。

サポートされている値はSOA、OSB、ADFBCです。

このプロパティは省略可能です。指定されていない場合、ジョブの実装方法にかかわらず、Oracle Enterprise Schedulerによってリクエストが外部ジョブ・タイプに関連付けられません。

型: STRING

GROUP_NAME

このリクエストがバインドされるOracle Enterprise Scheduler分離グループの名前を指定します。このプロパティは、リクエスト送信時にOracle Enterprise Schedulerによって自動的に設定されます。

型: STRING

INPUT_LIST

リクエストに対する入力を指定します。シリアル・ジョブ・セットへの入力は、最初のステップのみへの入力として転送されます。パラレル・ジョブ・セットへの入力は、すべてのパラレル・ステップへの入力として転送されます。

Oracle Enterprise Schedulerによって、このプロパティの値に指定される形式はありません。

型: STRING

INVOKE_MESSAGE

リモートWebサービスを起動するための入力として使用されるXMLメッセージ・ペイロードを指定します。このプロパティは、EJBジョブ・タイプおよびWebServiceジョブ・タイプに使用されます。このプロパティは、EJBジョブ・タイプのパススルー・パラメータです。

型: STRING

JNDI_CSF_KEY

キーストア内のユーザー名およびパスワードにマップされるCSF別名を指定します。この特定のユーザー名/パスワードは、JndiMappedName参照で保護されたJNDIにアクセスするために必要な資格証明です。このプロパティは、JNDIツリーが保護されている場合のみ必須です。このプロパティは、EJBジョブ・タイプに使用されます。

型: STRING

JNDI_MAPPED_NAME

ローカル/リモート・サーバーのJNDIにバインドされるEJBのマップされた名前を指定します。このプロパティは、EJBジョブ・タイプに使用されます。

型: STRING

JNDI_PROVIDER_URL

リモート・サーバーに関連するJNDIプロバイダのURLを指定します。このプロパティはオプションであり、EJBおよびOracle Enterprise Schedulerがリモートに配置されている場合のみ必要です。このプロパティが指定されていない場合、ジョブはローカル・サーバーで実行されます。このプロパティは、EJBジョブ・タイプに使用されます。

型: STRING

LISTENER

リクエストに関連付けられるイベント・リスナー・クラスを指定します。これは、oracle.as.scheduler.EventListenerインタフェースを実装するJavaクラスの名前である必要があります。

型: STRING

LOCALE

リクエストに関連付けられるロケールを指定します。

型: STRING

LOGICAL_CLUSTER_NAME

論理クラスタの名前を指定します。論理クラスタは物理クラスタに関連する情報で構成され、通常、ホスティング・アプリケーションの構成内に格納されます。論理クラスタ名は、アプリケーションの構成内の物理クラスタ情報セットへの参照です。プロパティが指定されていない場合、論理クラスタはリクエストに関連付けられません。

型: STRING

OUTPUT_LIST

リクエストからの出力を指定します。

シリアル・ジョブ・セットの出力は、最後のステップのOUTPUT_LISTです。パラレル・ジョブ・セットの出力は、すべてのステップのOUTPUT_LISTを連結したもので、順番は保証されず、セパレータとしてoracle.as.scheduler.SystemProperty.OUTPUT_LIST_DELIMITERが使用されます。

型: STRING

POST_PROCESS

後処理コールアウト・ハンドラ・クラスを指定します。これは、oracle.as.scheduler.PostProcessHandlerインタフェースを実装するJavaクラスの名前である必要があります。

型: STRING

PRE_PROCESS

前処理コールアウト・ハンドラ・クラスを指定します。これは、oracle.as.scheduler.PreProcessHandlerインタフェースを実装するJavaクラスの名前である必要があります。

型: STRING

PRIORITY

リクエスト処理の優先度を指定します。優先度の範囲は[0..9]であり、0が最下位の優先度を、9が最上位の優先度を示します。

デフォルト: このプロパティが指定されていない場合、システムのデフォルト値は4です。

型: INTEGER

PROCEDURE_NAME

SQLジョブ・リクエストでコールされるPL/SQLストアド・プロシージャの名前を指定します。ストアド・プロシージャは、schema.nameの形式で指定する必要があります。

このプロパティはSQLジョブ・タイプの必須プロパティです。他のジョブ・タイプでは使用されません。

型: STRING

PRODUCT

リクエストを送信したアプリケーション内の製品を指定します。

型: STRING

PROCESS_ARGUMENTS

プロセス・タイプ生成プロセスの実行可能ファイルに渡される引数を指定します。

型: STRING

REDIRECTED_OUTPUT_FILE

プロセス・ジョブ・リクエストに対して標準出力およびエラー・ストリームがリダイレクトされるファイルを指定します。これは、リクエストが実行されたときに、生成されたプロセスに対して標準出力およびエラー・ストリームがリダイレクトされるログ・ファイルのフルパスを表します。

このプロパティはプロセス・ジョブ・タイプではオプションです。他のジョブ・タイプでは使用されません。

型: STRING

REPROCESS_DELAY

コールアウト・ハンドラの処理遅延時間を指定します。コールバック・ハンドラによって遅延がリクエストされたときに、リクエスト処理を遅延させる時間を分単位で示します。

デフォルト: このプロパティが指定されていない場合、使用されるシステムのデフォルトは5です。

型: INTEGER

REQUEST_CATEGORY

リクエストのアプリケーション固有ラベルを指定します。アプリケーションまたはシステムの管理者が定義したラベルを指定することで、管理者は独自の要件に応じてジョブ・リクエストをグループ化できます。

型: STRING

REQUEST_EFFECTIVE_ENCODING

プロセス・ジョブ・リクエストに関連付けられている有効なエンコーディングを指定します。

SpawnLauncherにより、次の優先順序で、生成されたジョブ・リクエストのロケール設定が決定されます。

1. リクエストの環境プロパティ(SystemProperty.ENVIRONMENT_VARIABLES)で指定されるLC_ALL/LANG

2. ホスティング・アプリケーションess-config.xmlファイルで指定されているLC_ALL/LANG

3. Weblogic Server LC_ALL/LANG

有効なエンコーディングは、プロセスが生成される前に計算され、このプロパティに格納されます。これは、リクエストのログおよび出力に使用するエンコーディングの決定に後で使用されます。

型: STRING

REQUEST_EXPIRATION

リクエストの有効期限を指定します。これは、リクエストの有効期限が切れる時間を、スケジュールされた実行時間からの分数で表します。有効期限値のゼロ(0)は、リクエストが有効期限切れにならないことを意味します。このプロパティが指定されていない場合、システムのデフォルト値は0です。

リクエストの有効期限は実行待機中のリクエストにのみ適用されます。指定された有効期限よりも待機時間が長いリクエストは実行されません。リクエストの実行が開始された後は、リクエストの有効期限は適用されません。

型: INTEGER

REQUEST_LOG_LEVEL

リクエスト・ロギングのログ・レベルを指定します。ログ・レベルの有効値は、java.util.loggingで定義されているレベルの文字表現です。レベルは、Level.getName()を使用して取得します。デフォルトのログ・レベルはINFOです。

型: STRING

REQUESTED_PROCESSOR

リクエストを処理するリクエスト・プロセッサ・ノードを指定します。これにより、リクエストにプロセッサ・アフィニティを指定できるようになります。このプロパティが指定されていない場合、使用可能な任意のリクエスト・プロセッサ・ノードでリクエストを実行できます。通常、このプロパティは指定しません。

このプロパティをリクエストに指定した場合、リクエスト・プロセッサの作業割当てoracle.as.scheduler.WorkAssignment(特殊化)でこのようなリクエストの実行を許可する必要があります。許可しなかった場合、そのリクエストは実行されません。指定されたノードが実行されていない場合、リクエストはREADY状態のままとなり、ノードが再起動されるまで実行されません。

型: STRING

RESOLVED_CMDLINE

プロセス・タイプ・ジョブ・リクエストに使用されるコマンド行を指定します。このプロパティは、Oracle Enterprise Schedulerによってのみ設定されます。これは、診断のみを目的としています。

型: STRING

RETRIES

失敗したリクエストの再試行上限を指定します。リクエストの実行が失敗した場合、リクエストが成功するまで、このプロパティにより指定された回数までリクエストが再試行されます。再試行制限がゼロ(0)の場合、失敗したリクエストは再試行されません。

デフォルト: このプロパティが指定されない場合に使用されるシステムのデフォルトは0です。

型: INTEGER

RUNAS_APPLICATIONID

リクエストを実行するために使用する必要があるrunAs識別子を指定します。通常、リクエストは発行元ユーザーとして実行されます。ただし、このプロパティがリクエストに関連付けられているジョブのメタデータで設定されている場合、リクエストはこのプロパティで指定されるユーザーとして実行されます。このプロパティはメタデータでのみ指定できます。送信パラメータでは指定できません。

型: STRING

SELECT_STATE

ジョブ・セット・ステップの結果状態がその親ジョブ・セットの最終的な状態に影響するかどうかを指定します。ジョブ・セットの状態を決定するときに、ジョブ・セット・ステップの状態が考慮されるようにするには、SELECT_STATEをtrueに設定する必要があります。ジョブ・セット・ステップにSELECT_STATEが指定されていない場合、ステップの状態はジョブ・セットの状態を決定するときに考慮されます。

型: BOOLEAN

SQL_JOB_CLASS

SQLジョブ・リクエストの実行に使用されるOracle Enterprise Schedulerジョブに割り当てる、Oracle Enterprise Schedulerジョブ・クラスを指定します。ジョブ・リクエストに使用されるジョブが特定のOracle Databaseリソース・コンシューマ・グループに関連付けられている、またはデータベース・サービスへの親和性があるという場合は、このプロパティは指定する必要がありません。

このプロパティが指定されていない場合、SQLリクエストを実行するジョブにデフォルトのOracle Enterprise Schedulerジョブ・クラスが使用されます。そのジョブ・クラスはデフォルトのリソース・コンシューマ・グループに関連付けられます。これはデフォルト・サービスに属し、サービス・アフィニティがなく、Oracle RAC環境内で、クラスタ内のデータベース・インスタンスのいずれかがジョブを実行します。Oracle Enterprise Scheduler SQLジョブ・リクエストがそのデフォルト・ジョブ・クラスを使用するのに、追加の権限は要求されません。

このプロパティはSQLジョブ・タイプのオプションのプロパティです。他のジョブ・タイプでは使用されません。

型: STRING

SUBMITTING_APPLICATION

発行された(絶対親)リクエストに対してJava EEアプリケーションの論理名を指定します。このプロパティは、リクエスト送信時にOracle Enterprise Schedulerによって自動的に設定されます。

型: STRING

SUCCESS_EXIT_CODE

実行の成功を示すプロセス・ジョブ・リクエストのプロセス終了コードを指定します。このプロパティが指定されていない場合、システムは、プロセス終了コード0を実行の成功と見なして処理します。

このプロパティはプロセス・ジョブ・タイプではオプションです。他のジョブ・タイプでは使用されません。

型: STRING

SUPPORT_OUTPUT_FILES

リクエストで一時ファイルまたは出力ファイルを作成するかどうかを指定します。このプロパティは、前処理、実行、非同期更新および後処理の各ステージで適用されます。リクエストでは、APIを使用してコンテンツ・ストア内に出力コンテンツを常に直接作成できます。

プロパティ値によって、実行するアクションが指定されます。このプロパティが指定されていない場合、ディレクトリは作成されません。有効ではない値は、プロパティが指定されていない場合と同じように処理されます。

有効な値は次のとおりです。

- SystemProperty.SUPPORT_OUTPUT_FILES_NONE

- SystemProperty.SUPPORT_OUTPUT_FILES_WORK

- SystemProperty.SUPPORT_OUTPUT_FILES_OUTPUT

型: STRING

UPLOAD_CONTENT_TO_REPOSITORY

リクエストの実行が完了したときに、リクエスト・ログおよび出力ファイルを、内部リポジトリからUniversal Content Management (UCM)などの個別のリポジトリにアップロードするかどうかを指定します。

プロパティ値によって、実行するアクションが指定されます。このプロパティが指定されていない場合、コンテンツはアップロードされません。有効ではない値は、プロパティが指定されなかった場合と同じように処理されます。

有効な値は次のとおりです。

SystemProperty.UPLOAD_CONTENT_TO_REPOSITORY_COPY

型: STRING

USE_ALTERNATE_ENV

通常のアプリケーション環境ではなくコールアウトから代替環境を使用するかどうかを指定します。このプロパティが指定されていない場合、通常のアプリケーション環境が使用されます。

型: BOOLEAN

USE_EXTENDED_SETUP

ジョブの起動関連のコード(ジョブの実行可能ファイルまたは前処理ハンドラ、後処理ハンドラなど)の前にApplSessionsなどの機能を開始するかどうかを指定します。拡張機能は、それが使用可能な環境内でのみ起動されます。このプロパティが指定されていない場合、ジョブの実行前に拡張機能は設定されません。

型: BOOLEAN

USER_FILE_DIR

入力ファイルや出力ファイルなどリクエストの実行可能ファイルで使用されるファイルが保存される、ファイル・システム上のベース・ディレクトリを指定します。

Oracle Enterprise Schedulerでは、リクエストによりファイルを保存できるファイル・ディレクトリを指定する構成パラメータがサポートされます。構成パラメータが現在設定されていて、USER_FILE_DIRがリクエストに指定されていなかった場合、リクエストの送信時にUSER_FILE_DIRプロパティがリクエストに自動的に追加されます。追加されたプロパティは、構成パラメータの値に初期化されます。リクエスト送信時に構成パラメータが設定されていなかった場合、このプロパティは追加されません。

型: STRING

USER_FILE_DIR_SHARED

リクエストのUSER_FILE_DIR (構成済RequestFileDir)ディレクトリが共有されているかどうかを指定します。このプロパティは、RequestFileDirSharedの値を表します。このプロパティは、標準または拡張リクエスト・モードでのリクエストに有効です。

有効な値は次のとおりです。

- true: USER_FILE_DIRは共有ディレクトリです。

- false: USER_FILE_DIRは、ローカル・ディレクトリです。

このプロパティが指定されていない場合、システムのデフォルトであるfalseが使用されます。

型: BOOLEAN

USER_NAME

リクエストを実行するために使用されるユーザーの名前を指定します。ジョブ・メタデータでRUNAS_APPLICATIONIDプロパティが設定されている場合を除き、通常、これは発行元ユーザーとなります。このプロパティは、リクエスト送信時にOracle Enterprise Schedulerによって自動的に設定されます。

型: STRING

WARNING_EXIT_CODE

実行に関する警告を示すプロセス・ジョブ・リクエストのプロセス終了コードを指定します。このプロパティが指定されていない場合、システムは、プロセス終了コード3を実行の警告と見なして処理します。

このプロパティはプロセス・ジョブ・タイプではオプションです。他のジョブ・タイプでは使用されません。

型: STRING

WORK_DIR_ROOT

プロセス・ジョブ・リクエストの、生成されたプロセスのための作業ディレクトリを指定します。

このプロパティはプロセス・ジョブ・タイプではオプションです。他のジョブ・タイプでは使用されません。

型: STRING

WS_WSDL_URL

WebサービスWSDLの相対URLを指定します。ベースURLは、WS_WSDL_BASE_URLシステム・プロパティによって指定されます。このプロパティは、WebServiceジョブ・タイプに使用されます。

型: STRING

WS_WSDL_BASE_URL

WebサービスWSDLの完全URLを提供するためにWS_WSDL_URLシステム・プロパティを組み合せて使用できるベースURLを指定します。通常、このプロパティは、LOGICAL_CLUSTER_NAMEシステム・プロパティと組み合せて使用されます。これは、クラスタ内のすべてのWebサービスWSDLに共通する汎用ベースURLとなるものです。このプロパティは、WebServiceジョブ・タイプに使用されます。

このプロパティは省略可能です。指定されていない場合、リクエストのLOGICAL_CLUSTER_NAMEシステム・プロパティがホスティング・アプリケーションの構成内で構成されていれば、これに関連付けられている情報から同等の情報を取得できます。

型: STRING

WS_TARGET_NS

Webサービスに対してターゲットのネームスペースを指定します。このプロパティは、WebServiceジョブ・タイプに使用されます。

型: STRING

WS_ENDPOINT_URL

Webサービス・エンドポイントの相対URLを指定します。ベースURLは、WS_ENDPOINT_BASE_URLシステム・プロパティによって指定されます。このプロパティは、WebServiceジョブ・タイプに使用されます。

型: STRING

WS_ENDPOINT_BASE_URL

Webサービス・エンドポイントの完全URLを提供するためにWS_ENDPOINT_URLシステム・プロパティを組み合せて使用できるベースURLを指定します。通常、このプロパティは、LOGICAL_CLUSTER_NAMEシステム・プロパティと組み合せて使用されます。これは、クラスタ内のすべてのWebサービスのエンドポイントに共通する汎用ベースURLとなるものです。このプロパティは、WebServiceジョブ・タイプに使用されます。

このプロパティは省略可能です。指定されていない場合、リクエストのLOGICAL_CLUSTER_NAMEシステム・プロパティがホスティング・アプリケーションの構成内で構成されていれば、これに関連付けられている情報から同等の情報を取得できます。

型: STRING

WS_SERVICE_NAME

Webサービス操作のWSDLサービス名を指定します。このプロパティは、WebServiceジョブ・タイプに使用されます。

型: STRING

WS_PORT_NAME

Webサービス操作のWSDLポート名を指定します。このプロパティは、WebServiceジョブ・タイプに使用されます。

型: STRING

WS_OPERATION_NAME

Webサービス操作のWSDL操作名を指定します。このプロパティは、WebServiceジョブ・タイプに使用されます。

型: STRING

WS_CANCEL_OPERATION_NAME

Webサービスの取消し操作のWSDL操作名を指定します。このプロパティは、WebServiceジョブ・タイプに使用されます。

型: STRING

WS_CANCEL_MESSAGE

リモートWebサービスで取消しを起動するための入力として使用されるXMLメッセージ・ペイロードを指定します。このプロパティは、WebServiceジョブ・タイプに使用されます。

型: STRING

10 トークンおよび論理クラスタの使用

ジョブ定義をテスト環境から本番環境に簡単に移植できるようにするには、ジョブ定義にホスト名やポート番号など環境固有の情報を含めないようにするのが最善の方法です。Oracle Enterprise Schedulerのトークン置換および論理クラスタ機能では、T2Pプロセス中にターゲット・デプロイメントに正しく適合するよう簡単に変更できるようにメタデータを抽象化できます。

この章の構成は、次のとおりです。

- トークン置換の使用

- 論理クラスタの使用

10.1 トークン置換の使用

構成の柔軟性を高め、プロビジョニングの必要性を削減するために、Oracle Enterprise Schedulerでは、置換可能トークンをリクエスト・パラメータおよび環境プロパティに含めることができます。

トークンの形式は、${TokenPrefix:token}となります。

ここでのtokenはトークンの名前で、TokenPrefixには置換値が指定されます。サポートされているトークンの接頭辞は、APP_ENV、ESS_ENVおよびESS_REQです。次に示す例は単純ですが、Oracle Enterprise Schedulerの置換機能を表しています。

- APP_ENV
置換値は、アプリケーション環境プロパティから取得されます。

たとえば、次の環境変数は、Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTを使用して、ホスティング・アプリケーションの構成プロパティで指定されます。

AppEnvVar1=foo

リクエスト・パラメータはジョブ定義で指定されます。

MyParam=${APP_ENV:appEnvVar1}

置換後、MyParamの値はfooです。

- ESS_ENV
置換値は、Oracle Enterprise Schedulerサーバー環境から取得されます。これには、次の3つの可能なソースがあります。

- JVMシステム・プロパティ: トークン値は、システム・プロパティの名前です。

- JVM環境変数: トークン値は、環境変数の名前です。

- JRF: トークン値は、jrfServerLogPath、jrfServerConfigDirectoryおよびjrfDomainConfigDirectoryです。

次の例は、ホスティング・アプリケーション構成プロパティ内の環境変数の仕様におけるESS_ENVトークン接頭辞の使用方法を示しています。

wlstLocation = ${ESS_ENV:common.components.home}/common/bin/wlst.sh

置換の実行時、Oracle Enterprise Schedulerプロセス・ジョブ環境には、値が完全パスであるwlstLocationという名前の環境変数が含まれます。次に例を示します。

/myInstallHome/mw_home/oracle_common/common/bin/wlst.sh

- ESS_REQ
ESS_REQ置換は、対象のOracle Enterprise Schedulerリクエスト固有の情報から取得されます。サポートされているトークンは次のとおりです。

- REQUEST_ID

- REQUEST_HANDLE

- IS_RESUMED

- PAUSED_STATE

- リクエストのリクエスト・パラメータ名

10.1.1 ネストされている置換

最上位レベルの置換の実行時に、ネストされている置換は自動的に解決されます。たとえば、次のリクエスト・パラメータはプロセス・ジョブのジョブ定義で指定されます。

MyParam1=${ESS_REQ:MyParam2}
MyParam2=${APP_ENV:MyEnvProp1}

アプリケーションの環境プロパティには次が含まれます。

MyEnvProp1=${ESS_ENV:weblogic.Name}

JVMシステム・プロパティweblogic.Nameの値は、ess_server1と類似したものです。MyParam1で置換が実行されると、MyParam2の値に解決され、次にMyEnvProp1の値に解決されます。ネストされている置換の結果として、MyParam1の値はess_server1となります。

10.1.2 自動置換

Oracle Enterprise Schedulerの自動置換は、プロセス・ジョブ・コマンド行および環境プロパティの他、EJBおよびWebサービス・ジョブによって使用されるリクエスト・プロパティで使用可能です。

以下のセクションには、EJBジョブ、Webサービス・ジョブおよびプロセス・ジョブに対して自動的に置換されるリクエスト・パラメータがリストされています。

これらのプロパティの詳細は、次の章を参照してください。

- EJBジョブの作成と使用

- Webサービス・ジョブの作成と使用

- プロセス・ジョブの作成と使用。

EJBジョブ・タイプの自動置換プロパティ

EJBジョブ・タイプに対して自動的に置換されるプロパティは次のとおりです。

- SYS_EXT_jndiProviderUrl

- SYS_EXT_essRuntimeJndiMappedName

- SYS_EXT_essMetadataJndiMappedName

- SYS_EXT_essAsyncRequestJndiMappedName

- SYS_EXT_essJndiCsfKey

- SYS_EXT_invokeMessage

Webサービス・ジョブ・タイプ: 自動置換プロパティ

Webサービス・ジョブ・タイプに対して自動的に置換されるプロパティは次のとおりです。

- SYS_EXT_wsEndpointBaseUrl

- SYS_EXT_wsEndpointUrl

- SYS_EXT_wsWsdlBaseUrl

- SYS_EXT_wsWsdlUrl

- SYS_EXT_invokeMessage

- SYS_EXT_wsCancelMessage

プロセス・ジョブ・タイプ: 自動置換プロパティ

プロセス・ジョブ・タイプに対して自動的に置換されるプロパティは次のとおりです。

- SYS_cmdLine

- SYS_EXT_cmdLine.Unix

- SYS_EXT_cmdLine.Windows

- SYS_environmentVariables

10.2 論理クラスタの使用

Oracle Enterprise Schedulerでは、EJBおよびWebサービスのジョブに抽象的なジョブの場所を定義できる手段が提供されています。ジョブの場所は、Oracle Enterprise SchedulerのSYS_logicalClusterNameシステム・プロパティで指定し、論理クラスタ名(LCN)を指定します。

EJBまたはWebサービス・ジョブのジョブ定義によりLCNの値が指定される場合、特定の環境固有のプロパティは、Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドを使用して、ジョブ定義ではなくホスティング・アプリケーション・レベルで指定されます。同じLCNを持つすべてのジョブ定義は、Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドを使用してホスティング・アプリケーション構成プロパティに入力されたプロパティ値を共有します。

注意:

Oracle Enterprise Manager Fusion Middleware Controlは、論理クラスタ機能を「ジョブの場所」と呼びます。「論理クラスタ」および「ジョブの場所」という用語は同じ意味で使用できます。

ジョブ定義によりSYS_logicalClusterNameプロパティの値が指定されている場合、値は、論理クラスタの属性を定義するアプリケーション構成プロパティのセットに対する接頭辞として使用されます。表10-1は、ジョブの場所に関連付けられているプロパティをリストしており、ここでのprefixは論理クラスタ名を表します。これらのプロパティがホスティング・アプリケーションで構成されている場合、指定する必要があることに注意してください。

表10-1 ジョブの場所に関連付けられているプロパティ

プロパティ名

対応するシステム・プロパティ

説明

LCN.prefix.JndiProviderUrl

SYS_EXT_jndiProviderUrl

クラスタのJNDIプロバイダEJBジョブ・タイプで使用します。対応するシステム・プロパティであるSYS_EXT_jndiProviderUrlは、ジョブ内で指定しないようにする必要があります。

LCN.prefix.WsEndpointBaseUrl

SYS_EXT_wsEndpointBaseUrl

ホストとポート。たとえば、http://host:port/のようになります。EJBジョブ・タイプで使用します。対応するシステム・プロパティであるSYS_EXT_wsEndpointBaseUrlは、ジョブ内で指定しないようにする必要があります。

LCN.prefix.WsWsdlBaseUrl

SYS_EXT_wsWsdlBaseUrl

WSDLのホストとポート。たとえば、http://host:port/のようになります。EJBジョブ・タイプで使用します。対応するシステム・プロパティであるSYS_EXT_wsWsdlBaseUrlは、ジョブ内で指定しないようにする必要があります。

たとえば、ジョブによりSYS_logicalClusterNameプロパティがSOA_Cluster1として定義されている場合、アプリケーション構成には、次のプロパティが含まれている場合があります。

LCN.SOA_Cluster1.WsEndpointBaseURL=http://host:port/
LCN.SOA_Cluster1.WsWsdlBaseURL=http://host:port/
LCN.SOA_Cluster1.JndiProviderURL=t3://host1;port1;host2:port2/

注意:

SYS_logicalClusterNameプロパティの値には、「.」文字を含められません。

11 PL/SQLジョブの作成と使用

この章では、Oracle Enterprise Schedulerで使用するPL/SQLストアド・プロシージャを作成する方法と、Oracle Enterprise SchedulerでPL/SQLストアド・プロシージャを使用するために実行する必要があるOracle Databaseタスクについて説明します。

PL/SQLプロシージャを作成してジョブ定義を定義すると、Oracle Enterprise Schedulerランタイム・サービスを使用して、PL/SQLプロシージャに対するジョブ・リクエストを発行できるようになります。

この章の内容は次のとおりです。

- PL/SQLストアド・プロシージャ・ジョブ定義の使用の概要

- Oracle Enterprise Scheduler用PL/SQLストアド・プロシージャの作成

- PL/SQLストアド・プロシージャ用のOracle Databaseタスクの実行

- PL/SQLジョブ・タイプのジョブ定義の作成および格納

ランタイム・サービスの使用方法の詳細は、「ランタイム・サービスの使用」を参照してください。

11.1 PL/SQLストアド・プロシージャ・ジョブ定義の使用の概要

Oracle Enterprise Schedulerを使用すると、Javaクラス、PL/SQLストアド・プロシージャ、分岐プロセスとして実行されるプロセス・リクエストなど、様々なタイプのジョブ・リクエストを実行できます。

Oracle Enterprise SchedulerでPL/SQLストアド・プロシージャを使用するには、次を実行する必要があります:

- Oracle Enterprise Schedulerで使用するPL/SQLストアド・プロシージャを作成または取得します。

- PL/SQLストアド・プロシージャをOracle Databaseにロードして必要な権限を付与し、その他の必要なDBAタスクを実行します。

- Oracle JDeveloperを使用してジョブ・タイプおよびジョブ定義オブジェクトを作成し、それらのオブジェクトをOracle Enterprise Schedulerアプリケーション・メタデータとともに格納します。

- Oracle JDeveloperを使用して、PL/SQLストアド・プロシージャを実行および発行するOracle Enterprise Scheduler APIを持つアプリケーションを作成します。

最後に、Oracle Enterprise Scheduler APIを使用するアプリケーションを作成したら、Oracle JDeveloperを使用してアプリケーションをデプロイして実行します。

実行時に、ジョブ・リクエストを発行した後、ジョブ・リクエストをモニターおよび管理できるようになります。詳細は、「ランタイム・サービスの使用」を参照してください。

Oracle Enterprise Schedulerでは、PL/SQLストアド・プロシージャ・ジョブ・リクエストに非同期実行モデルを使用します。つまり、Oracle Enterprise Schedulerでは、PL/SQLストアド・プロシージャを直接コールするのではなく、Oracle Database Schedule (Oracle Database機能)を使用します。PL/SQLストアド・プロシージャ・ジョブ・リクエストを実行する準備が整うと、Oracle Enterprise Schedulerにより、即時に1回のみ実行されるOracle Database Schedulerジョブが作成されます。このOracle Database Schedulerジョブは、PL/SQLリクエストを実行するコンテナ・インスタンスに関連付けられているOracle Enterprise Schedulerランタイム・スキーマ・ユーザーによって作成され、アプリケーション・プロシージャ所有者によって所有されます。Oracle Database Schedulerジョブ・プロシージャは、Oracle Enterprise Schedulerランタイム・スキーマ・ユーザーによって所有されるPL/SQLラッパー・プロシージャです。最後に、Oracle Database Schedulerジョブの実行時、ラッパー・プロシージャは動的SQLを使用してアプリケーション・ストアド・プロシージャをコールします。PL/SQLストアド・プロシージャが(正常な戻り値または例外の発生によって)完了すると、Oracle Database Schedulerジョブが終了し、リモート実行が終了したOracle Enterprise Schedulerに通知するイベントを作成します。

11.2 Oracle Enterprise Scheduler用PL/SQLストアド・プロシージャの作成

Oracle Enterprise SchedulerでPL/SQLストアド・プロシージャを使用するには、PL/SQLプロシージャに、Oracle Enterprise Schedulerアプリケーションで動作するための特定の特性がある必要があり、かつ、特定のOracle Database権限がPL/SQLストアド・プロシージャに割り当てられていることをDBAが確認する必要があります。

PL/SQLストアド・プロシージャの作成には、次のステップが含まれます。

- Oracle Enterprise Schedulerで使用するための正しいシグネチャを持つPL/SQLストアド・プロシージャを定義します。

- PL/SQLストアド・プロシージャをOracle Enterprise Schedulerで使用できるようにするために必要なDBAタスクを実行します。

11.2.1 正しいシグネチャを持つPL/SQLストアド・プロシージャの定義方法

Oracle Enterprise SchedulerからコールするPL/SQLストアド・プロシージャは、特定のシグネチャを持ち、次のような特定のプロシージャ・パラメータを含む必要があります。

PROCEDURE my_proc(request_handle IN VARCHAR2);

request_handleパラメータは、実行されるOracle Enterprise Schedulerリクエストの実行コンテキストを表す不透明な値です。

例11-1に、Oracle Enterprise Schedulerで使用するサンプルのHELLO_WORLDストアド・プロシージャを示します。

例11-1 HELLO_WORLD PL/SQLストアド・プロシージャ

create or replace procedure HELLO_WORLD( request_handle in varchar2 )
as
v_request_id  number := null;
v_prop_name  varchar2(500) := null;
v_prop_int  integer := null;
begin
-- Get the Oracle Enterprise Scheduler request ID being executed.
begin
v_request_id := ess_runtime.get_request_id(request_handle);
exception
when others then
raise_application_error(-20000,
'Failed to get request id for request handle ' ||
request_handle || '. [' || SQLERRM || ']');
end;

-- Retrieve value of an existing request property.
begin
v_prop_name := 'mytestIntProp';
v_prop_int := ess_runtime.get_reqprop_int(v_request_id, v_prop_name);
exception
when others then
rollback;
raise_application_error(-20001,
'Failed to get request property ' || v_prop_name ||
' for Oracle Enterprise Scheduler request ID ' || v_request_id ||
'. [' || SQLERRM || ']' );
end;

-- Update an existing request property with a new value.
-- This procedure is responsible for commit/rollback of the update operation.
begin
v_prop_name := 'myJobdefProp';
ess_runtime.update_reqprop_varchar2(v_request_id, v_prop_name,
'myUpdateValue');
commit;
exception
when others then
rollback;
raise_application_error(-20002,
'Failed to update request property ' || v_prop_name ||
' for Oracle Enterprise Scheduler request ID ' || v_request_id ||
'. [' || SQLERRM || ']' );
end;
end helloworld;
/

11.2.2 Oracle Enterprise Scheduler PL/SQLストアド・プロシージャでのランタイム例外の処理

PL/SQLストアド・プロシージャでは、RAISE_APPLICATION_ERROR例外を発生させることによって、例外およびその他の問題を処理できます。RAISE_APPLICATION_ERRORでは、PL/SQLストアド・プロシージャのエラー・コードが-20000から-20999の範囲である必要があります。PL/SQLストアド・プロシージャで例外を発生させる必要がある場合は、RAISE_APPLICATION_ERRORを使用できます。RAISE_APPLICATION_ERRORには、-20000から-20999の範囲のエラー・コードが必要です。

表11-1に、PL/SQLストアド・プロシージャの結果に基づくOracle Enterprise Schedulerの状態を示します。

表11-1 PL/SQLストアド・プロシージャの結果の終了状態

最終状態

説明

SUCCEEDED

PL/SQLストアド・プロシージャが例外を発生させることなく正常な結果を返すと、その後のリクエスト完了時のエラーにかかわらず、リクエストの状態はSUCCEEDED状態に遷移します。

WARNING

PL/SQLストアド・プロシージャが例外とともに結果を返すと、リクエストの状態はその例外のSQLエラー・コードに基づいて決まります。

SQLエラー・コードが-20900から-20919の範囲の場合、リクエストはWARNING終了状態に遷移します。

ERROR

PL/SQLストアド・プロシージャが例外とともに結果を返すと、リクエストの状態はその例外のSQLエラー・コードに基づいて決まります。

-20900から-20919の範囲外のエラー・コードの場合は、リクエストはERROR終了状態に遷移します(この範囲内のエラー・コードはWARNINGを示します)。

-20920から-20929の範囲内の戻りコードの場合は、BUSINESSエラー・タイプを持つERROR状態になります。この場合、リクエストは自動再試行には左右されません。

11.2.3 PL/SQLストアド・プロシージャでのジョブ・リクエスト情報へのアクセス方法

Oracle Enterprise Schedulerでは、PL/SQLストアド・プロシージャの操作で必要となる可能性のある特定の操作を実行するためのPL/SQLパッケージESS_RUNTIMEが提供されています。これらのプロシージャを使用してジョブ・リクエスト操作を実行し、Oracle Enterprise Schedulerランタイム・スキーマのジョブ・リクエスト情報を取得できます。たとえば、これらのランタイム・プロシージャを使用してリクエストを発行し、Oracle Enterprise Schedulerジョブ・リクエストに関連付けられているリクエスト情報を取得および更新できます。

次のサンプル・コードは、ESS_RUNTIMEプロシージャの使用方法を示します。

v_request_id := ess_runtime.get_request_id(request_handle);

このリクエストにより、ジョブ・リクエストに関連付けられているリクエストIDが取得されます。

ESS_RUNTIMEパッケージ内の特定のプロシージャでは、リクエスト・ハンドル・パラメータが必要であり、実行されるリクエストに関する情報を提供します(これらのプロシージャは、PL/SQLストアド・プロシージャ・リクエストを実行するPL/SQLストアド・プロシージャからのみコールする必要があります)。ESS_RUNTIMEパッケージ内の一部のプロシージャは、実行するリクエストのコンテキスト外からコールできます。これらのプロシージャには、リクエストIDパラメータを含めることができます。

11.2.4 PL/SQLストアド・プロシージャの定義に関する必知事項

Oracle Enterprise SchedulerでPL/SQLストアド・プロシージャを作成して使用する場合は、次のことに注意する必要があります。

- Oracle Enterprise Schedulerリクエストが発行されるときにPL/SQLストアド・プロシージャが存在する必要はありませんが、リクエストを実行する準備が整ったときには、PL/SQLストアド・プロシージャが存在し、コールできる必要があります。

- PL/SQLストアド・プロシージャは、Oracle Enterprise Schedulerランタイム・スキーマと同じデータベース上に存在する必要があります。

11.3 PL/SQLストアド・プロシージャ用のOracle Databaseタスクの実行

Oracle Enterprise Schedulerで使用するPL/SQLストアド・プロシージャを作成したら、DBAがPL/SQLストアド・プロシージャをOracle Databaseにロードして、必要な権限を付与する必要があります。

11.3.1 PL/SQLストアド・プロシージャ権限の付与方法

DBAは権限を付与する前に、Oracle Databaseと、Oracle Enterprise Scheduler PL/SQLストアド・プロシージャ・リクエストを発行する、デプロイされたJava EEアプリケーションに関連付けられているOracle Enterprise Schedulerランタイム・スキーマを決定する必要があります。

PL/SQLストアド・プロシージャ権限を付与する場合は、次の定義を使用します。

ess_schema: Java EEアプリケーションに関連付けられているOracle Enterprise Schedulerランタイム・スキーマを指定します。

user_schema: アプリケーション・ユーザー・スキーマの名前を指定します。

PROC_NAME: Oracle Enterprise Schedulerジョブ・リクエストに関連付けられているPL/SQLストアド・プロシージャの名前を指定します。

Oracle Database権限を付与する手順は、次のとおりです。

1. Oracle Databaseで、アプリケーション・ユーザー・スキーマにESS_RUNTIMEパッケージの実行権限を付与します。次に例を示します。

GRANT EXECUTE ON ess_schema.ESS_RUNTIME to user_schema;

2. Oracle Databaseで、ESS_RUNTIMEパッケージにプライベート・シノニムを作成します。これは、PL/SQLストアド・プロシージャで完全なschema_name.ESS_RUNIMEを使用するかわりに、単にESS_RUNTIMEとしてESS_RUNTIMEを参照できる便利なステップです。次に例を示します。

CREATE OR REPLACE SYNOMYM user_schema.ESS_RUNTIME for ess_schema.ESS_RUNTIME;

3. Oracle Databaseで、アプリケーション・ユーザー・スキーマにESS_JOBパッケージの実行権限を付与します。ESS_JOBが使用されていない場合、このステップはスキップできます。次に例を示します。

GRANT EXECUTE ON ess_schema.ESS_JOB to user_schema;

4. Oracle Databaseで、ESS_JOBパッケージにプライベート・シノニムを作成します。これは、PL/SQLストアド・プロシージャで完全なschema_name.ESS_JOBを使用するかわりに、単にESS_JOBとしてESS_JOBを参照できる便利なステップです。ESS_JOBが使用されていない場合、このステップはスキップできます。次に例を示します。

CREATE OR REPLACE SYNONYM user_schema.ESS_JOB for ess_schema.ESS_JOB;

5. Oracle Databaseで、Oracle Enterprise Schedulerランタイム・スキーマ・ユーザーが所有する、Oracle Enterprise Schedulerジョブ・プロシージャとして機能するPL/SQLストアド・プロシージャの実行権限を付与します。次に例を示します。

GRANT EXECUTE ON ess_schema.ESS_SCHJOB_PROC to user_schema;

例として、Oracle Enterprise Schedulerランタイム・スキーマがTEST_ESSで、アプリケーション・ユーザー・スキーマがHOWTOであり、PL/SQLプロシージャの名前がHELLO_WORLDである場合は、次のようなDBA操作は次のようになります。

GRANT EXECUTE ON test_ess.ess_runtime to howto;
CREATE OR REPLACE SYNONYM howto.ess_runtime for test_ess.ess_runtime;
GRANT EXECUTE ON test_ess.ess_job to howto;
CREATE OR REPLACE SYNONYM howto.ess_job for test_ess.ess_job;
GRANT EXECUTE ON test_ess.ESS_SCHJOB_PROC to howto;

11.3.2 PL/SQLストアド・プロシージャ権限の付与に関する必知事項

ESS_RUNTIMEパッケージの権限を付与するDBAタスクについて示されている2つのステップは、ESS_RUNTIMEパッケージがPL/SQLプロシージャにより参照される場合にのみ必要です。ESS_JOBパッケージの権限の付与に使用されるDBAタスクについて示されている2つのステップは、ESS_JOBパッケージがPL/SQLプロシージャにより参照される場合にのみ必要です。ESS_SCHJOB_PROCプロシージャに示されているステップは、Oracle Enterprise Schedulerラッパー・プロシージャのコールを可能にするため、常に必要です。

Oracle Enterprise Scheduler PL/SQLストアド・プロシージャ・ジョブで使用される、特定のアプリケーション・ユーザー・スキーマ内のすべてのPL/SQLストアド・プロシージャは、常に同じ(単一の)Oracle Enterprise Schedulerランタイム・スキーマに関連付けられている必要があります。これは技術的に必要ありませんが、DBAのセットアップが大幅に簡略化され、PL/SQLストアド・プロシージャでESS_RUNTIMEを参照する場合に、プロシージャでOracle Enterprise Schedulerランタイム・スキーマを明示的に指定する必要がなくなります。

11.4 PL/SQLジョブ・タイプのジョブ定義の作成および格納

Oracle Enterprise SchedulerでPL/SQLストアド・プロシージャを使用するには、メタデータ・サービスを見つけて、ジョブ定義を作成する必要があります。ジョブ定義は、名前とジョブ・タイプを指定して作成します。ジョブ定義を作成するときには、特定のシステム・プロパティも設定する必要があります。これにより、メタデータ・サービスを使用してジョブ定義とその他の関連オブジェクトを格納できるようになります。

メタデータ・サービスの使用方法の詳細は、「メタデータ・サービスの使用」を参照してください。

Oracle Enterprise Schedulerでは、Oracle Database Schedulerジョブを使用して、SQLジョブ・リクエストに対してPL/SQLストアド・プロシージャを実行します。Oracle Database Schedulerジョブ・クラスは、データベース・サービスに対するアフィニティを持つ必要があるジョブ、またはOracle Databaseリソース・コンシューマ・グループに関連付けられるジョブに関連付けることができます。Oracle Database Schedulerジョブ所有者は、ジョブ・クラスを使用してジョブを正常に作成するために、Oracle Database Schedulerジョブ・クラスについてEXECUTE権限を持っている必要があります。

Oracle Enterprise Schedulerシステム・プロパティを使用して、PL/SQLストアド・プロシージャをコールするOracle Enterprise Schedulerジョブに特定の属性を指定できます。

これらのSystemPropertyプロパティは、SQLジョブ・タイプのPROCEDURE_NAMEとSQL_JOB_CLASSにのみ適用されます。

PROCEDURE_NAMEシステム・プロパティは、実行されるPL/SQLストアド・プロシージャの名前を指定します。ストアド・プロシージャ名は、owner.nameの形式である必要があり、この場合のownerはジョブ・プロシージャのスキーマ所有者であり、nameはプロシージャ名です。このプロパティは、ジョブ・タイプまたはジョブ定義のいずれかに対して指定する必要があります。

SQL_JOB_CLASSシステム・プロパティは、SQLジョブ・リクエストの実行に使用されるOracle Database Schedulerジョブに割り当てられるOracle Database Schedulerジョブ・クラスを指定します。このプロパティは、リクエストに使用されるOracle Database Schedulerジョブが、特定のOracle Databaseリソース・コンシューマ・グループに関連付けられる必要があるか、データベース・サービスへのアフィニティを持つ必要がある場合を除き、指定する必要はありません。

SQL_JOB_CLASSシステム・プロパティが指定されていない場合、Oracle Enterprise Schedulerによって作成されるデフォルトのOracle Database Schedulerジョブ・クラスが、Oracle Database Schedulerジョブに使用されます。デフォルトのジョブ・クラスは、デフォルトのリソース・コンシューマ・グループに関連付けられます。これはデフォルト・サービスに属し、このことは、サービス・アフィニティがなく、Oracle RAC環境内で、クラスタ内のデータベース・インスタンスのいずれかがジョブを実行する可能性があることを意味します。Oracle Enterprise Scheduler SQLリクエストでこのデフォルト・ジョブ・クラスを使用するために必要な追加の権限付与はありません。

11.4.1 PL/SQLジョブ・タイプの作成方法

Oracle Enterprise SchedulerのJobTypeオブジェクトでは、実行タイプを指定し、ジョブ・リクエストの共通プロパティ・セットを定義します。1つのジョブ・タイプを定義して、1つ以上のジョブ定義で共有できます。Oracle Enterprise Schedulerでは、次の3つの実行タイプがサポートされています。

- JAVA_TYPE: Javaで実装され、コンテナ内で実行されるジョブ定義に使用します。

- SQL_TYPE: データベース・サーバーでPL/SQLストアド・プロシージャとして実行されるジョブ定義に使用します。

- PROCESS_TYPE: 個別のプロセスとして実行される、バイナリおよびスクリプトのジョブ定義に使用します。

JobTypeを指定する場合、JobTypeに関連付けられる特性を定義するプロパティも指定できます。表11-2に、PL/SQLストアド・プロシージャ・ジョブ・タイプに適したSystemPropertiesを示します。

表11-2 PL/SQLストアド・プロシージャ・ジョブ・タイプ用のOracle Enterprise Schedulerシステム・プロパティ

システム・プロパティ

説明

PROCEDURE_NAME

PL/SQLジョブ実行の一部として実行するストアド・プロシージャの名前を指定します。

SQL_TYPEアプリケーションでは、これは必須のプロパティです。

SQL_JOB_CLASS

SQLジョブ・リクエストの実行に使用されるOracle Database Schedulerジョブに割り当てられるOracle Database Schedulerジョブ・クラスを指定します。

これは、SQL_TYPEジョブ・タイプのオプションのプロパティです。

PL/SQLジョブ・タイプを作成および格納するには、次を実行します:

- JobTypeコンストラクタを使用して、String名とJobType.ExecutionType.SQL_TYPE引数を指定します。

- 新しいJobTypeに適切なプロパティを設定します。

- 「メタデータ・サービスへのアクセス」に示されているように、メタデータ・ポインタを取得します。メタデータ・サービスのaddJobType()メソッドを使用して、JobTypeをメタデータに格納します。

- メタデータ・リポジトリ内でメタデータ・オブジェクトを一意に識別するMetadataObjectIdを使用します。MetadataObjectIDには、一意の識別子を使用したメタデータ・オブジェクトの完全修飾名が含まれます。

サンプル・コードは、「Oracle Enterprise SchedulerアプリケーションでのPL/SQLストアド・プロシージャの使用」を参照してください。

11.4.2 PL/SQLジョブ・タイプのジョブ定義の作成および格納方法

PL/SQLをOracle Enterprise Schedulerで使用するには、ジョブ定義を作成および格納する必要があります。ジョブ定義は、Oracle Enterprise Schedulerでジョブ・リクエストを定義する基本作業単位です。各ジョブ定義は、1つのジョブ・タイプにのみ属します。

注意:

ジョブ・タイプを指定してジョブ定義を作成した後で、タイプやジョブ定義名を変更することはできません。タイプまたはジョブ定義名を変更するには、新しいジョブ定義を作成する必要があります。

「Oracle Enterprise SchedulerアプリケーションでのPL/SQLストアド・プロシージャの使用」には、ジョブ定義コンストラクタとジョブ・タイプを使用してジョブ定義を作成する方法が示されています。

11.4.3 Oracle Enterprise SchedulerアプリケーションでのPL/SQLストアド・プロシージャの使用

この項では、SQLジョブ・タイプに対してジョブ・タイプとジョブ定義アプリケーション・メタデータを作成するサンプル・コードを示します。

import oracle.as.scheduler.JobType;
import oracle.as.scheduler.JobDefinition;
import oracle.as.scheduler.MetadataService;
import oracle.as.scheduler.MetadataServiceHandle;
import oracle.as.scheduler.MetadataObjectId;
import oracle.as.scheduler.ParameterInfo;
import oracle.as.scheduler.ParameterInfo.DataType;
import oracle.as.scheduler.ParameterList;

void createDefinition( )
{
MetadataService metadata = ...
MetadataServiceHandle mshandle = null;

try
{
ParameterInfo pinfo;
ParameterList plist;

mshandle = metadata.open();

// Define and add a PL/SQL job type for the application metadata.
String jobTypeName = "PLSQLJobDefType";
JobType jobType = null;
MetadataObjectId jobTypeId = null;

jobType = new JobType(jobTypeName, JobType.ExecutionType.SQL_TYPE);

plist = new ParameterList();
pinfo = SystemProperty.getSysPropInfo(SystemProperty.PROCEDURE_NAME);
plist.add(info.getName(), pinfo.getDataType(), "HOWTO.HELLO_WORLD", false);
pinfo = SystemProperty.getSysPropInfo(SystemProperty.PRODUCT);
plist.add(pinfo.getName(), pinfo.getDataType(), "HOW_TO_PROD", false);
jobType.setParameters(plist);

jobTypeId = metadata.addJobType(mshandle, jobType, "HOW_TO_PROD");

// Define and add a job definition for the application metadata.
String jobDefName = "PLSQLJobDef";
JobDefinition jobDef = null;
MetadataObjectId jobDefId = null;

jobDef = new JobDefinition(jobDefName, jobTypeId);
jobDef.setDescription("Demo PLSQL Job Definition " + jobDefName);

plist = new ParameterList();
plist.add("myJobdefProp", DataType.STRING, "myJobdefVal", false);
jobDef.setParameters(plist);

jobDefId = metadata.addJobDefinition(mshandle, jobDef, "HOW_TO_PROD");
}
catch (Exception e)
{
[...]
}
finally
{
// always close metadata service handle in finally block
if (null != mshandle)
{
metadata.close(mshandle);
mshandle = null;
}
}
}

12 EJBジョブの作成と使用

この章では、Oracle Enterprise Schedulerを使用してEnterprise Java Bean (EJB)ジョブを作成する方法について説明します。

この章の構成は、次のとおりです。

- EJBジョブの作成の概要

- ジョブ開発の計画

- EJBジョブ・タイプのジョブ定義の作成および格納

- 保護された起動

- 同期Bean

- 非同期Bean

12.1 EJBジョブの作成の概要

EJBジョブ・タイプを使用するとJavaベースのジョブを作成でき、事前デプロイ済のホスティング・アプリケーションの利便性を利用できます。さらに、EJBは別のサーバー上にリモートで配置できます。

Java SEベースのジョブと異なり、EJBジョブはホスティング・アプリケーションの内部に埋め込む必要がありません。このため、リモートで配置でき、事前デプロイ済のホスティング・アプリケーションで使用できます。EJBジョブは、事前デプロイ済のホスティング・アプリケーションを含むどのホスティング・アプリケーションからも起動できます。EJBの実装は、スケジューラ・サーバーと同じWebLogicドメイン内にある必要があることに注意してください。

EJBは、Oracle Enterprise Scheduler (共有ライブラリ内で定義)で定義されているインタフェースに準拠しています。EJBは非トランザクションです。同期および非同期の両方のEJBジョブがサポートされます。非同期で実行するとEJBは即座に戻り、Oracle Enterprise Scheduler EJBは後でジョブの完了時に起動されます。EJB実装は、3つの共有ライブラリ・サーバー(oracle.ess)、クライアント(oracle.ess.client)およびシン・クライアント(oracle.ess.thin.client)のいずれとも動作可能です。シン・クライアント共有ライブラリは、Oracle Enterprise Schedulerデータ・ソースに依存しません。シン・クライアント・ライブラリの使用の詳細は、「シン・クライアント・アプリケーションの作成」を参照してください。

EJBはサブリクエストを発行でき、出力およびログに書き込むことができます。EJBインタフェースは、Javaジョブに類似しているか同じであり、類似の処理を実行できます。パフォーマンスを向上させるために、単一の共有EJBで複数のジョブ実装を統合できます。

EJBジョブは、EJBリモート・ビジネス・インタフェースを使用してリモートで実行されるJavaジョブです。実行タイプはJAVA_TYPEです。リモート・ジョブとは、リモート・サーバーにデプロイされているEJBです。このBeanのリモート・ビジネス・インタフェースは、oracle.as.scheduler.RemoteExecutableインタフェースを拡張し、executeメソッドを定義します。Oracle Enterprise Schedulerとサービス・コンポーネント間の契約は、executeメソッドで定義されます。図12-1は、標準的なEJBジョブ・デプロイメント内のコンポーネントを示しています。

EJBは、ホスティング・アプリケーションと同じドメインに配置する必要があり、SubjectオブジェクトはEJBに伝播されます。JNDIルックアップ操作で、オプションの資格証明を指定できます。デフォルト・アイデンティティは、anonymousです。

図12-1 EJBジョブ環境

12.2 ジョブ開発の計画

Oracle Enterprise Schedulerは柔軟であり、実装およびデプロイメント・オプションが用意されています。「ジョブ開発の計画」は、ジョブ開発およびデプロイメント・プロセスの計画方法の概要を説明しています。

12.3 EJBジョブ・タイプのジョブ定義の作成および格納

Oracle Enterprise SchedulerでEJBタイプのジョブを使用するには、メタデータ・サービスを特定してジョブ定義を作成する必要があります。ジョブ定義は、名前とジョブ・タイプを指定して作成します。ジョブ定義を作成するときには、特定のシステム・プロパティも設定する必要があります。

ジョブ定義は、メタデータ・サービスを使用してメタデータ・リポジトリに格納できます。サンプル・メタデータ・ファイルは、この章の後半で説明します。

メタデータ・サービスの使用方法の詳細は、「メタデータ・サービスの使用」を参照してください。

ジョブ定義のJobTypeを指定する場合、JobTypeに関連付けられる特性を定義するSystemPropertiesを指定することもできます。表12-1および表12-2に、リクエストの処理方法を指定するプロパティを示します。

表12-1 EJBジョブ・タイプのプロパティ

プロパティ名[SystemPropertyクラスのフィールド]

説明

SYS_EXT_jndiProviderUrl[JNDI_PROVIDER_URL]

オプションです。リモート・サーバーのURLを指定します。EJBがリモートに配置されている場合にのみ必須です。

JndiProviderUrlは、実行時に解決されるトークンを含むように指定できます。

次に2つの例を示します。

- ${WIRING:urn:oracle:fmw:soa:t3}
このURNは実行時に解決され、実際のURL値がフェッチされます。

- t3://localhost:19283
この場合、localhostはEJBがデプロイされるホストであり、19283はサーバー・ポート番号です。

SYS_EXT_jndiMappedName[JNDI_MAPPED_NAME]

必須です。リモートEJB実装のJNDIルックアップ名を指定します。

例: ejb/fileAdapter

SYS_EXT_ejbOperationName[EJB_OPERATION_NAME]

オプションです。適切なビジネス・メソッドに分岐するEJBの実装で使用されるパス・スルー・パラメータを指定します。

例: manageFileAdapter

SYS_EXT_jndiCSFKey[JNDI_CSF_KEY]

EJBサーバーのJNDIツリーが保護されている場合のみ必須です。キーストア内のユーザー名とパスワードにマップされ、CSFの別名を指します。この特定のユーザー名/パスワードのペアは、JndiMappedName参照で保護されたJNDIにアクセスするために必要な資格証明です。

このプロパティは、RequestParametersオブジェクト、またはホスティング・アプリケーションのOracle Enterprise Scheduler構成のいずれかに追加できます。

注意:

Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTスクリプトを使用して、CSFキー別名をインストール後の手順として構成できます。インストール後の手順の前に、キーストアのCSFマップをoracle.ess.securityのデフォルト値に設定できます。

表12-2に、RequestParametersオブジェクト、またはホスティング・アプリケーションのOracle Enterprise Scheduler構成のいずれかに追加できるプロパティを示します。テスト環境から本番環境に移行する際ジョブ定義はレプリケートされるため、本番環境で環境固有のデータをジョブ定義に入力しないでください。かわりに、このデータは、構成データとしてホスティング・アプリケーションで個別に入力する必要があります。Oracle Enterprise Schedulerのトークン置換および論理クラスタ機能では、T2Pプロセス中にターゲット・デプロイメントに正しく適合するよう簡単に変更できるようにメタデータを抽象化できます。これらの機能の使用の詳細は、「トークンおよび論理クラスタの使用」を参照してください。

表12-2 追加プロパティ

プロパティ名[SystemPropertyクラスのフィールド]

説明

SYS_EXT_essJndiCsfKey[ESS_JNDI_CSF_KEY_NAME]

オプションです。認証済Oracle Enterprise SchedulerサーバーのCSFキーの別名を指定します。このプロパティは、Oracle Enterprise SchedulerのJNDIツリーが認証済の場合にのみ必須です。

例: ess-jndi-csf-key

SYS_EXT_essRuntimeJndiMappedName{ESS_RUNTIME_JNDI_MAPPED_NAME]

ホスティング・アプリケーションで定義され、Oracle Enterprise SchedulerサーバーのJNDIツリーにバインドされる、Oracle Enterprise Scheduler RuntimeService BeanのJNDIのマップされた名前を指定します。

このプロパティは、EssNativeHostingApp以外のホスティング・アプリケーションを使用し、そのリモートBeanがOracle Enterprise SchedulerのランタイムBeanの呼出し(たとえば、出力の書込みまたは情報の記録、リクエストの発行またはリクエストの操作)を必要とする場合にのみ必須です。

SYS_EXT_essMetadataJndiMappedName[ESS_METADATA_JNDI_MAPPED_NAME]

ホスティング・アプリケーションで定義され、Oracle Enterprise SchedulerサーバーのJNDIツリーにバインドされる、Oracle Enterprise Scheduler MetadataService BeanのJNDIのマップされた名前を指定します。

EssNativeHostingApp以外のホスティング・アプリケーションを使用していて、リモートBeanがOracle Enterprise SchedulerのメタデータBeanにアクセスする必要がある場合のみ、このプロパティは必須です。

SYS_EXT_essAsyncRequestJndiMappedName[ESS_ASYNC_REQUEST_JNDI_MAPPED_NAME]

ホスティング・アプリケーションで定義され、Oracle Enterprise SchedulerサーバーのJNDIツリーにバインドされる、Oracle Enterprise Scheduler AsyncRequest BeanのJNDIのマップされた名前を指定します。

このプロパティは、次の場合にのみ必須です。

- EJB呼出しが非同期

- EssNativeHostingApp以外のホスティング・アプリケーションを使用している場合

- リモートBeanがOracle Enterprise SchedulerのBeanにコールバックする必要がある(たとえば、非同期コールバック)

システム・プロパティの詳細は、「パラメータとシステム・プロパティの使用」を参照してください。

12.4 保護された起動

リモートEJBの保護された起動は、そのサーバーのJNDIツリーが認証されている場合に必須です。これは、保護された参照を使用してリモートEJBがOracle Enterprise Scheduler EJBをコールバックする場合も同様です。次の各項で、ガイドラインを示します。

12.4.1 転送起動

次の内容が転送起動に適用されます。

- Oracle Enterprise SchedulerがリモートEJBを起動する場合、実行ジョブのサブジェクトは常に伝播されます。

- Oracle Enterprise Schedulerがジョブを実行する際、現在のOracle Enterprise Scheduler ServerのJndiProviderUrlはRequestParametersを介してリモートEJBに常に提供されます。

- リモート・サーバーのJNDIツリーが認証されている場合、JNDI_CSF_KEYプロパティをリクエスト・パラメータまたはホスティング・アプリケーションのEssConfigurationで指定する必要があります。

- Oracle Enterprise Schedulerは、CsfKeyのキーストアを参照してPasswordCredentialを取得し、リモート・サーバーに接続します。

12.4.2 コールバック起動

次の内容がコールバック起動に適用されます。

- リモートEJBがOracle Enterprise SchedulerのBeanにコールバックする必要がある場合、次のプロパティを指定できます。

- HostingAppで公開されているOracle Enterprise SchedulerのRuntime、MetadataおよびAsyncRequest BeanのJNDI名は、リクエスト・パラメータまたはホスティング・アプリケーションのEssConfigurationで指定する必要があります。EssNativeHostingAppが使用されている場合、これらのエントリは必要がありません。

- Oracle Enterprise SchedulerサーバーのJNDIツリーが認証されている場合、ESS_JNDI_CSF_KEY_NAMEプロパティをリクエスト・パラメータまたはホスティング・アプリケーションのEssConfigurationで指定する必要があります。Oracle Enterprise Schedulerにより、このプロパティがRequestParametersを介してリモートEJBで使用可能になります。

- リモートEJBは、RemoteConnector APIを使用して、 Oracle Enterprise Scheduler Beanのリモート・インスタンスを取得できます。これは、次を渡すことで実行できます。

- RequestParameters

- BeanのRequestParametersおよびJndiMappedName (ネイティブ・ホスティング・アプリケーション以外のホスティング・アプリケーション用)

- RequestParameters、ユーザー名およびパスワード(Oracle Enterprise Schedulerサーバーが認証されている場合)

- InitialContext (主にEssNativeHostingAppを伴うJava SEクライアント用)

- InitialContextおよびjndiMappedName (主にその他のホスティング・アプリケーションを伴うJava SEクライアント用)

12.4.3 RemoteConnector APIおよびサーバー・アフィニティ・プロパティ

コードの実装がOracle Enterprise Scheduler EJBへのアクセスに依存している場合、RemoteConnector APIクラスで公開されているメソッドを使用します。Oracle Enterprise Schedulerでは、JNDIルックアップを実行する前にサーバー・アフィニティ・プロパティをInitialContext環境で設定する必要があり、RemoteConnector APIクラスがこのプロパティを設定します。これは、マルチノード・クラスタ・シナリオで特に重要です。RemoteConnectorクラスは、Oracle Enterprise Schedulerクライアント・ライブラリでパッケージ化されています。

何らかの理由でRemoteConectorクラスを使用できない場合、次の例に示すように、Oracle Enterprise Scheduler EJBの参照を実行する前に環境マップ・プロパティをInitialContextに設定できます。

if(PlatformUtils.isWebLogic())
envProps.put("weblogic.jndi.enableServerAffinity", "true");

マルチノード・クラスタ環境では、クラスタ・アルゴリズムをラウンドロビン・アフィニティに設定するのが最適です。

12.4.4 リモート・サーバーからのCSF参照

Oracle Enterprise SchedulerサービスのBeanが認証されている場合、リモート・アプリケーションは、保護された参照を使用してOracle Enterprise Schedulerにコールバックする必要があります。リクエスト・パラメータで使用可能なESS_JNDI_CSF_KEY_NAMEプロパティを使用するOracle Enterprise SchedulerのRemoteConnector APIを使用して、参照を実行できます。ただし、このCSF参照を支援するために、RemoteConnectorを起動するコードは資格証明ストア・アクセスの権限を付与する必要があります。次のXMLの一部分を、リモート・アプリケーションのjazn-data.xmlファイルに追加できます。

<jazn-policy>
<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/${weblogic.Name}/tmp/                    _WL_user/<AppName>/-</url>
</codesource>
</grantee>
<permissions>
<permission>           <class>oracle.security.jps.service.credstore.CredentialAccessPermission
</class>
<name>context=SYSTEM,mapName=oracle.ess.security,keyName=*</name>
<actions>READ</actions>
</permission>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>IdentityAssertion</name>
<actions>execute</actions>
</permission>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>AppSecurityContext.setApplicationID.*</name>
</permission>
</permissions>
</grant>
</jazn-policy>

12.5 同期Bean

この項では、同期Beanの作成方法を表す例を示します。

12.5.1 メタデータ

この項では、同期Beanに適用されるメタデータを示します。

次の例で、ファイルoracle/apps/ess/custom/Jobs/EssGatewayJobDefn.xmlにあるEJBジョブのジョブ定義のサンプルを示します

<?xml version = '1.0'?>
<job-definition xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"                  xmlns="http://xmlns.oracle.com/scheduler"
name="SoaEjbJobDefn"
job-type="/oracle/as/ess/core/JobType/SyncEjbJobType.xml">
<description/>
<display-name>EssGatewayBean</display-name>
<parameter-list>
<parameter name="SYS_EXT_jndiKeyName" data-type="string" read-only="true">
ejb/essGatewayBean</parameter>
<parameter name="SYS_EXT_jndiProviderUrl" data-type="string"        read-only="true">URL</parameter>
<parameter name="SYS_EXT_ejbOperationName" data-type="string"
read-only="true">activateFileAdapter</parameter>
<parameter name="SYS_effectiveApplication" data-type="string">
ESS_NATIVE_HOSTING_APP_LOGICAL_NAME</parameter>
</parameter-list>
</job-definition>

12.5.2 EJBジョブ・サンプル・コード

この項では、Oracle Enterprise Schedulerで予期される同期EJBジョブのサンプル実装を示します。

次のコード・スニペットは、このBeanを定義するejb-jar.xml ファイルの一部を示しています。

<session>
<description>ESS Gateway Bean</description>
<ejb-name>EssGateway</ejb-name>
<ejb-class>com.soa.beans.EssGatewayBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<security-identity>
<use-caller-identity/>
</security-identity>
</session>

次のコード・スニペットは、このBeanを定義するweblogic-ejb-jar.xml ファイルの一部を示しています。

<weblogic-enterprise-bean>
<ejb-name>FileAdapterBean</ejb-name>
<stateless-session-descriptor>
<business-interface-jndi-name-map>
<business-remote>oracle.as.scheduler.RemoteCancellableExecutable
</business-remote>
<jndi-name>ejb/essGatewayBean</jndi-name>
</business-interface-jndi-name-map>
</stateless-session-descriptor>
</weblogic-enterprise-bean>

import javax.ejb.Stateless;
import oracle.as.scheduler.SystemProperty;
import oracle.as.scheduler.ExecutionCancelledException;
import oracle.as.scheduler.ExecutionErrorException;
import oracle.as.scheduler.ExecutionPausedException;
import oracle.as.scheduler.ExecutionWarningException;
import oracle.as.scheduler.RemoteCancellableExecutable;
import oracle.as.scheduler.RequestExecutionContext;
import oracle.as.scheduler.RequestParameters;

@Stateless(name = "EssGateway", mappedName = "ejb/essGatewayBean")
public class EssGatewayBean implements RemoteCancellableExecutable
{
public EssGatewayBean()
{
}

public void execute(RequestExecutionContext context,
RequestParameters parameters) throws ExecutionErrorException,
ExecutionWarningException, ExecutionCancelledException,
ExecutionPausedException
{
//Get the value of 'SYS_EXT_ejbOperationName' property
String opName = (String)parameters.getValue(SystemProperty.EJB_OPERATION_NAME);

if("manageFileAdapter".equals(opName))
{
//
//Call business method of this bean or some other bean
//
//Hint: User defined properties can be set in RequestParameters while
//submitting the job and can be retrieved here for further processing.
}
}

public void cancel(RequestExecutionContext context,
RequestParameters parameters)
{
//
//Logic to cancel the execution of a business method.
//
// Execute the actual logic of cancellation, notifies back to ESS
// by throwing ExecutionCancelledException through execute method.
}
}

12.6 非同期Bean

Oracle Enterprise SchedulerがBeanを非同期に起動する際、実行メソッドの終了を待機しません。このため、Beanの実装は処理が終了した後にOracle Enterprise Schedulerに通知する必要があります。この目的のためにRemoteAsyncHelperクラスを使用できます。または、RemoteConnectorから取得されるAsyncRequestBeanを使用して、ステータスの更新をOracle Enterprise Schedulerに通知できます。

通常、非同期EJBは次の用途に使用されます。

- 長時間実行されている操作

- プロセッサを大量に消費するタスク

- バックグラウンド・タスク

- アプリケーション・スループットを向上させる場合

- メソッドの起動結果が即座に必要ではないときにアプリケーション・レスポンス時間を改善する場合

同期EJBジョブは、実行時間が短いユーザー・ビジネス・メソッドにより適しています。

Oracle Enterprise SchedulerがBeanを非同期で実行するにはいくつかの方法があります。

- 明示的非同期性: 同期ステートレスBeanを使用して、メッセージドリブンBeanを非同期で起動します。(Java Message Serviceメッセージを、メッセージドリブンBeanによってリスニングされているトピック/キューに追加します)

- 暗黙的非同期性: 非同期で動作するように、EJB非同期注釈を使用してビジネス・メソッド(実行、取消しメソッド以外)を宣言します。

注意:

Oracle Enterprise Schedulerは、同期Beanを非同期で起動できます。ただし、このメソッドを使用する場合、長時間実行メソッドが非同期性のためにマークされる方法でBeanをモデル化する必要があります。

注意:

EJB標準で定義されているように、executeメソッドは許可されていないカスタム例外をスローするため、executeメソッドの@Asynchronous注釈またはクラス全体を使用できません。Oracle Enterprise Schedulerでは、カスタム例外をスローするためにexecuteメソッドが必要です。

12.6.1 メタデータ

この項では、非同期Beanに適用されるメタデータを示します。

この例では、ファイルoracle/apps/ess/custom/Jobs/AsyncJobDefn.xmlにあるEJBジョブのジョブ定義のサンプルを示します

<?xml version = '1.0'?>
<job-definition xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/scheduler" name="EssAsyncJobDefn"
job-type="/oracle/as/ess/core/JobType/AsyncEjbJobType.xml">
<display-name>EssGatewayBean</display-name>
<parameter-list>
<parameter name="SYS_EXT_jndiKeyName" data-type="string"
read-only="true">ejb/essAsyncGatewayBean</parameter>
<parameter name="SYS_EXT_jndiProviderUrl" data-type="string"
read-only="true">t3://localhost:10801</parameter>
<parameter name="SYS_EXT_ejbOperationName"
data-type="string"read-only="true">activateFileAdapter</parameter>
<parameter name="SYS_effectiveApplication" data-type="string">
ESS_NATIVE_HOSTING_APP_LOGICAL_NAME</parameter>
</parameter-list>
</job-definition>

12.6.2 EJBジョブ・サンプル・コード

この項では、「非同期Bean」で説明している明示的および暗黙的メソッドの両方を使用して非同期性を実装する方法を表すサンプル・コードを示します。

12.6.2.1 メッセージドリブンBeanを使用した非同期性の実装サンプル

次のコード・サンプルでは、メッセージドリブンBeanを非同期で起動するために使用される同期ステートレスBeanを示します。

package com.soa.test;

import java.io.Serializable;
import java.util.ArrayList;
import javax.ejb.Stateless;
import javax.jms.ObjectMessage;
import javax.jms.Queue;
import javax.jms.QueueConnection;
import javax.jms.QueueConnectionFactory;
import javax.jms.QueueSender;
import javax.jms.QueueSession;
import javax.jms.Session;

import javax.naming.InitialContext;

import oracle.as.scheduler.AsyncRequestBeanRemote;
import oracle.as.scheduler.ExecutionCancelledException;
import oracle.as.scheduler.ExecutionErrorException;
import oracle.as.scheduler.ExecutionPausedException;
import oracle.as.scheduler.ExecutionWarningException;
import oracle.as.scheduler.RemoteCancellableExecutable;
import oracle.as.scheduler.RequestExecutionContext;
import oracle.as.scheduler.RequestParameters;
import oracle.as.scheduler.request.RemoteConnector;

@Stateless(name = "EssAsyncPilot")
public class EssAsyncPilotBean implements RemoteCancellableExecutable
{
public EssAsyncPilotBean() {
}

public void execute(RequestExecutionContext requestExecutionContext,
RequestParameters requestParameters)
throws ExecutionErrorException, ExecutionWarningException,
ExecutionPausedException, ExecutionCancelledException {
// Delegate the job request cancellation to message driven bean
postToQueue("execute", requestExecutionContext, requestParameters);
}

public void cancel(RequestExecutionContext requestExecutionContext,
RequestParameters requestParameters) {
RemoteConnector connector = new RemoteConnector();
AsyncRequestBeanRemote asyncRequest;

// Delegate the job request cancellation to message driven bean
try {
postToQueue("cancel", requestExecutionContext, requestParameters);
} catch (Exception e) {
//Mark this request as ERRORed
}
/*
* Other ways to cancel the job request.
* asyncRequest = connector.getAsyncRequestEJB(requestParameters);
* asyncRequest.onCancel(requestExecutionContext);
*
* (or)
*
* asyncRequest = connector.getAsyncRequestEJB(requestParameters);
* asyncRequest.setRequestStatus(
*      requestExecutionContext, AsyncStatus.CANCEL, "Cancelling the job");
*
* (or simply)
*
* RemoteAsyncHelper asyncHelper = new RemoteAsyncHelper(
*      requestExecutionContext, requestParameters);
* asyncHelper.onCancel();
*
*/
}

private void postToQueue(String instruction,
RequestExecutionContext context, RequestParameters params) {
try {
QueueConnectionFactory qconFactory;
QueueConnection qcon;
QueueSession qsession;
QueueSender qsender;
Queue queue;
ObjectMessage msg;
InitialContext ic = new InitialContext();

qconFactory = (QueueConnectionFactory) ic
.lookup("EssAsyncJmsConnFactory");
qcon = qconFactory.createQueueConnection();
qsession = qcon.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);

queue = (Queue) ic.lookup("EssAsyncJmsQueue");

qsender = qsession.createSender(queue);
msg = qsession.createObjectMessage();
qcon.start();

ArrayList<Serializable> objsList = new ArrayList<Serializable>(2);
objsList.add(context);
objsList.add(params);
objsList.add(instruction);
msg.setObject(objsList);
qsender.send(msg);

System.out.println("The message, " + instruction
+ ", has been sent to the EssAsyncJmsQueue.");
qsender.close();
qsession.close();
qcon.close();
} catch (Exception e) {
System.out.print("error " + e);
}
}
}

import java.util.List;
import java.io.Serializable;
import javax.ejb.MessageDriven;

import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.ObjectMessage;

import oracle.as.scheduler.RequestExecutionContext;
import oracle.as.scheduler.RequestParameters;
import oracle.as.scheduler.async.RemoteAsyncHelper;

/**
* This message driven bean sample relies on execute/cancel instructions.
* Upon completion of execution or cancellation, this bean notifies
* ESS about its status so that the job request is marked for completion.
*/
@MessageDriven(mappedName = "ejb/essAsyncJms")
public class EssAsyncJmsBean implements MessageListener {
public void onMessage(Message message) {
if (message instanceof ObjectMessage) {
ObjectMessage objMessage = (ObjectMessage)message;
try {
List<Serializable> objsList = (List<Serializable>)objMessage.getObject();
RequestExecutionContext ctx = (RequestExecutionContext)objsList.get(0);
RequestParameters params = (RequestParameters)objsList.get(1);
String instruction = (String)objsList.get(2);
RemoteAsyncHelper asyncHelper = new RemoteAsyncHelper(ctx, params);
if ("cancel".equalsIgnoreCase(instruction)) {
//EssAsyncJmsBean.cancel: Cancelling the Execution
try {
//Do the actual cancellation
Thread.sleep(1000);
} catch (InterruptedException e) {
}
asyncHelper.onCancel();
//EssAsyncJmsBean.cancel: Completed cancellation
} else {
//EssAsyncJmsBean.execute: Started the Execution ");
try {
//Do the actual execution
Thread.sleep(5000);
} catch (InterruptedException e) {
}
asyncHelper.onSuccess();
//EssAsyncJmsBean.execute: Completed the Execution ");
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
}

12.6.2.2 注釈を使用した非同期性の実装サンプル

次のコード・スニペットでは、EJB Asynchronousを使用して、Beanまたはそのメソッドが非同期に動作するように宣言します。

package com.soa.test;

import java.util.concurrent.Future;

import javax.annotation.Resource;

import javax.ejb.AsyncResult;
import javax.ejb.Asynchronous;
import javax.ejb.SessionContext;
import javax.ejb.Stateless;

import javax.xml.transform.Result;

import oracle.as.scheduler.ExecutionCancelledException;
import oracle.as.scheduler.ExecutionErrorException;
import oracle.as.scheduler.ExecutionPausedException;
import oracle.as.scheduler.ExecutionWarningException;
import oracle.as.scheduler.RemoteExecutable;
import oracle.as.scheduler.RequestExecutionContext;
import oracle.as.scheduler.RequestNotFoundException;
import oracle.as.scheduler.RequestParameters;
import oracle.as.scheduler.RuntimeServiceException;
import oracle.as.scheduler.SchedulerException;
import oracle.as.scheduler.async.RemoteAsyncHelper;

@Stateless(name = "EssAsyncAnnotatedBean", mappedName = "ejb/essAsyncAnnBean")
public class EssAsyncAnnotatedBean implements RemoteExecutable {
@Resource
SessionContext sessionContext;

public void execute(RequestExecutionContext requestExecutionContext,
RequestParameters requestParameters) throws
ExecutionErrorException, ExecutionWarningException,
ExecutionPausedException,ExecutionCancelledException
{
RemoteAsyncHelper asyncHelper = null;

try {
asyncHelper = new RemoteAsyncHelper(requestExecutionContext, requestParameters);

//Initiate processing
initiateProcessing(requestExecutionContext, requestParameters);

//Get processed results
Future<Result[]> results = getProcessedResults(requestExecutionContext, requestParameters);

//do further processing

//Finally, complete the request
asyncHelper.onSuccess();
}
catch (Exception e)
{
try
{
asyncHelper.onBizError(e.getMessage());
}
catch (Exception f)
{
}
}
}

@Asynchronous
public void initiateProcessing(RequestExecutionContext requestExecutionContext,
RequestParameters requestParameters)
{
//startProcessing
}

@Asynchronous
public Future<Result[]> getProcessedResults(RequestExecutionContext requestExecutionContext,
RequestParameters requestParameters)
{
Result[] resultsArr = null;
//do processing
return new AsyncResult<Result[]>(resultsArr);
}

}

window.name='GUID-8936D0FC-7599-4944-9ECB-D11A5FE58890' function footdisplay(footnum,footnote) { var msg = window.open('', 'NewWindow' + footnum, 'directories=no,height=120,location=no,menubar=no,resizable=yes,' + 'scrollbars=yes,status=no,toolbar=no,width=598'); msg.document.open('text/html'); }
13 Webサービス・ジョブの作成と使用

この章では、Oracle Enterprise Schedulerを使用してWebサービス・ジョブを作成する方法および次の項について説明します。

- 概要

- 事前定義済Webサービス・ジョブ・タイプ

- 取消しおよびフォルトのサポート

- Webサービス・ジョブの構成プロパティ

- Oracle Web Services Managerポリシー構成

- Webサービス・ジョブ定義の作成

13.1 概要

Webサービスは、Web上でサービスを公開するスタンドアロンの手段を提供します。WebサービスはURLからアクセス可能であり、SOAPおよびXMLをペイロードとして使用します。Webサービスは、WebサービスのインタフェースおよびURLを定義するWSDL標準によって説明されています。

Webサービスの例は次のとおりです。

- SOA Suiteコンポジット

- Oracle Service Busプロキシ・サービス

- ADFビジネス・コンポーネントWebサービス

Webサービスは、一方向、同期または非同期操作を公開できます。一方向のWebサービス操作は、Webサービスによりレスポンスが返されないファイア・アンド・フォーゲット操作です。同期Webサービス・操作は、同じWebサービスの起動の一部としてレスポンスを返します。通常、Webサービス・クライアントは、同期操作レスポンスが受信されるまでブロックされます。非同期Webサービス操作には2つの一方向メッセージが含まれますが、1つはWebサービス操作リクエスト用、もう1つはレスポンス用です。通常、非同期Web操作は長時間実行される操作を表します。Webサービス・クライアントは非同期Webサービス操作を起動しますが、レスポンスを待機しません。かわりに、クライアントはWebサービスからレスポンスを受信するコールバックURLを指定します。Webサービスは、リクエストをバックグラウンドで処理し、コールバック操作を使用してレスポンスをクライアント指定のコールバックURLに返します。

Oracle Enterprise Schedulerは、同期インタフェース、一方向インタフェースおよび非同期インタフェースを使用するWebサービス・ジョブをサポートします。Webサービス・ジョブ定義は(ホスティング・アプリケーションまたはクライアント・アプリケーションの一部として)JDeveloperを使用して、またはOracle Enterprise Manager Fusion Middleware Controlを使用して定義できます。Webサービス・ジョブ・タイプを選択する場合、ユーザーは、ウィザードで誘導される簡単な一連のステップを進みWebサービス・ジョブを定義します(「Oracle Enterprise Manager Fusion Middleware Controlを使用したジョブ定義の作成」の例を参照)。このウィザードは、WSDL URLを取得し、WSDLサービス、ポート・タイプおよび操作の選択をユーザーに要求します。次に、WSDLに基づいてペイロードのサンプルXMLを作成し、ユーザーにその更新を許可します。非同期および同期Webサービスは、オプションで、取消し用に指定された操作を実行できます。取消し操作があった場合、この操作が選択され、取消し操作用のサンプルXMLコードが変更されます。このウィザードは、ウィザードでユーザーが入力した値または入力した値から導かれた値をジョブ定義の事前定義済のシステム・プロパティのセットに入力します。

注意:

Webサービス・ジョブ・タイプのWSDL URLは、具体的なWSDL URLである必要があります。抽象的なWSDL URLにはできません。

ジョブ定義には、ユーザー定義パラメータを設定できます。起動またはcancelペイロードXMLコード内の要素または属性は、トークン置換手順を指定することで、プラグインされるこれらのパラメータのいずれかを要素値として指定できます。たとえば、トークン置換コマンド${ESS_REQ:customerID}でパラメータcustomerIDをプラグインします。これにより、ジョブの発行者はパラメータ値のみを入力して、それらからXMLペイロードを構築できます。トークン置換は、WSDLベースURLおよびWSDL相対URLシステム・プロパティにも指定できます。トークンの置換の詳細は、「トークンおよび論理クラスタの使用」を参照してください。

Webサービス・ジョブは、Oracle Web Services Manager (OWSM)ポリシーによって保護されます。Oracle Enterprise Manager Fusion Middleware ControlまたはJDeveloperでは、OWSMの直接アタッチされるポリシーを起動(クライアント・ポリシー)およびコールバック(サービス・ポリシー)アクションのジョブ定義にアタッチできます。グローバルにアタッチされたポリシーを使用してポリシーをグローバルに定義したり、直接アタッチされたポリシーを使用して個別のジョブ定義を保護したりできます。

注意:

Oracle Web Services Manager (OWSM)ポリシーの使用の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の次の各項を参照してください。

- 「Fusion Middleware Controlを使用したポリシーをグローバルにアタッチする」

- 「WLSTを使用したポリシーをグローバルにアタッチする」

- 「WLSTを使用したポリシーを直接アタッチする」

進捗状況メッセージは、非同期Webサービス・ジョブに対してサポートされています。これらのメッセージは、ジョブ・ログに書き込まれます。コールバック操作で、ジョブが成功したか失敗したかをジョブは示すことができます。コールバック・メッセージは、ジョブの出力で構成されます。

13.2 事前定義済Webサービス・ジョブ・タイプ

Oracle Enterprise Schedulerでは、事前定義済Webサービス・ジョブ・タイプがサポートされています。Webサービス・ジョブ定義で指定するジョブ・タイプにより、構成済Webサービス操作が非同期、同期または一方向(ファイア・アンド・フォーゲット)のいずれで起動されているかどうかが暗黙的に判別されます。

「概要」で説明したように、Oracle Enterprise Schedulerでは、3つの事前定義されたWebサービス・ジョブ・タイプがサポートされています。Webサービスの事前定義済ジョブ・タイプを表13-1に示します。

表13-1 事前定義済Webサービス・ジョブ・タイプ

事前定義済ジョブ・タイプ

説明

/oracle/as/ess/core/JobType/AsyncWebserviceJobType

(非同期)コール元がWebサービスを起動すると、Webサービスがバックグラウンドで非同期に実行され、WebサービスはコールバックURLのコール元にコールバックします

/oracle/as/ess/core/JobType/SyncWebserviceJobType

(同期)コール元は、レスポンスが返されるまでブロックされます(リクエスト/レスポンス)

/oracle/as/ess/core/JobType/OnewayWebserviceJobType

(一方向)コール元はレスポンスを想定しません。Webサービスはバックグラウンドで実行されます(ファイア・アンド・フォーゲット)。

13.3 取消しおよびフォルトのサポート

Webサービス・ジョブの取消し操作のサポートはオプションです。Webサービスは、実行中のWebサービスの起動を取り消す取消し操作をサポートできます。

取消し操作は中断操作ではありません。中断操作ではコンポジットが終了し、元の操作を完了するためのコールバックが行われません。Webサービス・プロバイダにより正常に動作する取消しを実装することで、元のWebサービス操作により、SOAPレスポンス・ヘッダーで事前定義済のwsa:Actionコードを使用して「操作取消しレスポンス」が返されます(表13-2を参照)。取消しWebサービス操作は、同期Webサービス操作である必要があります。

同期と非同期のWebサービス・ジョブのいずれも、wsa:Action SOAPレスポンス・メッセージ・ヘッダーで適切な値を指定して、Webサービス操作が取り消されたかフォルト(エラー)になったかを示すことができます。コールバック・レスポンスSOAPメッセージが「取消済」または「フォルト」レスポンスに一致しない場合(後述するメカニズムのいずれかを使用)、ジョブの状態は「成功」となります。

表13-2に、SOAP wsa:Actionヘッダーを使用して指定できる様々なWebサービス操作ステータスを示します。

表13-2 SOAP Webサービス操作ステータス

アクション・コード名

アクションURI

取消済

"http://xmlns.oracle.com/schedulercallback/wsOperationCancelled"

フォルト

- 標準Webサービス・アドレス指定: "http://schemas.xmlsoap.org/ws/2004/08/addressing/fault"

- Oracle Application Server: "http://xmlns.oracle.com/oracleas/schema/oracle-fault-11_0/Fault"

Oracle SOA Suiteは、wsa:Actionメッセージ・ヘッダーの設定をサポートします。かわりに、表13-3にリストされている文字列の1つを、コールバック・メッセージのSOAP body要素に追加できます。

表13-3 Oracle SOA Suiteステータス操作

操作

文字列

取消済

"wsOperationCancelled"

フォルト

"wsOperationFault"

13.4 Webサービス・ジョブの構成プロパティ

Oracle Enterprise Schedulerでは、Webサービス・ジョブの特定の構成プロパティを使用します。

表13-4に、Webサービス・ジョブ・タイプに関連付けられているプロパティをリストします。

表13-4 Webサービス・ジョブの構成プロパティ

プロパティ名

説明

SYS_EXT_wsWsdlBaseUrl脚注 1

WSDL URLのベースURLの一部。

SYS_EXT_wsWsdlUrl^1

WebサービスのWSDL URLの相対的な部分(具体的なWSDL URLである必要があります)。SYS_EXT_wsEndpointUrlプロパティまたはSYS_EXT_wsWsdlUrlプロパティのいずれかを、完全に指定する必要があります。たとえば、SYS_EXT_wsWsdlBaseUrlとSYS_EXT_wsWsdlUrlの両方が構成されているか、SYS_EXT_wsEndpointBaseUrlとSYS_EXT_wsEndpointUrlの両方が構成されています。

SYS_EXT_wsEndpointBaseUrl^1

エンドポイントURLのベースURLの一部。

SYS_EXT_wsEndpointUrl^1

Webサービス・エンドポイントURLの相対部分(具体的なWSDL URLである必要があります)。SYS_EXT_wsEndpointUrlプロパティまたはSYS_EXT_wsWsdlUrlプロパティのいずれかを、完全に指定する必要があります。たとえば、SYS_EXT_wsWsdlBaseUrlとSYS_EXT_wsWsdlUrlの両方が構成されているか、SYS_EXT_wsEndpointBaseUrlとSYS_EXT_wsEndpointUrlの両方が構成されています。

SYS_EXT_wsTargetNamespace

ターゲットのネームスペース。

SYS_EXT_wsServiceName

サービス名。

SYS_EXT_wsPortName

ポート名。

SYS_EXT_wsOperationName

操作名。

SYS_EXT_invokeMessage^1

Webサービスの呼出しに使用されるXMLの発行メッセージ

SYS_EXT_wsCancelOperationName

オプションです。取消操作名。

SYS_EXT_wsCancelMessage^1

オプションです。Webサービスの取消操作のためのXMLメッセージ。

SYS_externalJobType

オプションです。サポートされている値は、「ADFBC」、「OSB」または「SOA」です。その他の値は無効です。

脚注 1

このプロパティは、トークン置換を使用して指定できます。詳細は、「トークンおよび論理クラスタの使用」を参照してください。

SYS_EXT_wsEndpointBaseUrlプロパティおよびSYS_EXT_wsEndpointUrlプロパティがジョブ定義で指定されている場合、Oracle Enterprise SchedulerにはWebサービスを起動するための十分な情報があります。SYS_EXT_wsEndpointBaseUrlとSYS_EXT_wsEndpointUrlプロパティがジョブ定義で指定されておらず、SYS_EXT_wsWsdlBaseUrlとSYS_EXT_wsWsdlUrlプロパティが指定されている場合、Oracle Enterprise Schedulerは実行時に(ジョブを起動する前)WSDLを取得し、WSDLからEndpointUrlとTargetNamespaceプロパティ値を取得し、Webサービスを起動します。

SYS_EXT_wsServiceName、SYS_EXT_wsPortNameおよびSYS_EXT_wsOperationNameプロパティを指定して、起動する特定のWebサービス操作を識別する必要があります。

SYS_EXT_invokeMessageプロパティには、起動するためのXMLメッセージ(SOAP bodyペイロード)が含まれます。これは、XMLテンプレートまたは完全なXMLのいずれかです。

XMLテンプレートには、実行時に置換されるトークンが含まれます。ジョブ発行者は、テンプレートのトークンと置換されるパラメータ値を指定します。完全なXMLがトークンなしで使用される場合、置換は必要なく、ジョブ定義内で指定されたXMLはジョブ起動でそのまま使用されます。

注意:

XML文内の山カッコ(<および>)はエスケープする必要があります。

起動後、リモートWebサービスは、進捗状況メッセージをログに記録してそのステータスを更新できます。これらのメッセージは、Webサービス・ジョブによってログに記録され、リクエスト・ログで使用できます。Webサービス・レスポンスXMLは、ジョブ出力として取得されます。

SYS_EXT_wsCancelMessageおよびSYS_EXT_wsCancelOperationNameプロパティが取消しメッセージで構成されている場合、メッセージは取消し操作が実行中のWebサービス・ジョブで開始されたときに起動されます。取消し操作は、同期Webサービス操作として常に起動されます。

取消しメッセージSOAPヘッダーには、起動Webサービス操作に関連付けられているwsa:messageIdに設定されているWS-Addressing relatesToIdプロパティが自動的に移入されます。取消し操作では、起動操作と同じOWSMポリシーが使用されます。SYS_EXT_wsCancelMessageプロパティが構成されていない場合、Webサービスでは取消しがサポートされないため取消しできません。

SYS_externalJobTypeプロパティでは、Webサービス・ジョブ定義によりWebサービス・タイプ(ADFBC、Service BusまたはSOA)を指定できます将来カスタマイズされるWebサービス・ジョブ実装用のものです。

13.5 Oracle Web Services Managerポリシー構成

Webサービス・ジョブ・タイプでは、分離されたOracle Web Services Manager (OWSM)ポリシー・サブジェクト(Job-Invoke、Job-Callback)、およびWebサービス起動とコールバック操作に対して関連付けられているグローバルにアタッチされたポリシーおよび直接アタッチされたポリシーが使用されます。

Job-Invokeポリシー・サブジェクトは、すべてのWebサービス・ジョブ・タイプ(一方向、同期および非同期)に関連付けられていますが、一方Job-Callbackポリシー・サブジェクトは同期Webサービス・ジョブ・タイプにのみ使用できます。Job-InvokeおよびJob-Callbackのグローバルにアタッチされたポリシーはドメイン・レベルで指定でき、EMまたはWLSTを使用して構成できます。

Job-Invokeのグローバルにアタッチされたポリシーまたは直接アタッチされたポリシーがWebサービス・ジョブ定義に指定されていない場合、Webサービスは非同期で起動されます。匿名コールバックは非同期Webサービス・ジョブ・タイプにサポートされていないため、これは一方向および同期ジョブ・タイプにのみ機能します。

Job-InvokeおよびJob-Callbackの直接アタッチされたポリシーは個別のWebサービス・ジョブ定義に固有であり、Webサービス・ジョブ定義に関連付けられているポリシー・アセンブリ・ディスクリプタで取得されます。これらの直接アタッチされたポリシーは、JDeveloperを使用して設計時に指定するか、実行時にOracle Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドを使用して指定できます。

Webサービス・ジョブ・ポリシー・サブジェクトに対するグローバルにアタッチされたポリシーは、Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTスクリプトを使用して、Webサービス・ジョブ・ポリシー・サブジェクトに対するドメイン・レベルのグローバルにアタッチされたポリシーを構成できます。例13-1に、このようなスクリプトの例を示します。

例13-1 グローバルにアタッチされたポリシーを構成するWLSTスクリプト

connect(adminuser, adminpassword, adminurl)

beginRepositorySession()
deletePolicySet('domain-default-job-invoke-client-policies')
describeRepositorySession()
commitRepositorySession()

beginRepositorySession()
deletePolicySet('domain-default-job-callback-service-policies')
describeRepositorySession()
commitRepositorySession()

print "-- create domain-default-job-invoke-client-policies --"
beginRepositorySession()
describeRepositorySession()
createPolicySet('domain-default-job-invoke-client-policies', 'job-invoke',  'Domain("*")')
attachPolicySetPolicy("oracle/wss11_saml_token_with_message_protection_client_policy")
describeRepositorySession()
commitRepositorySession()

print "-- create domain-default-job-callback-service-policies --"
beginRepositorySession()
describeRepositorySession()
createPolicySet('domain-default-job-callback-service-policies', 'job-callback',  'Domain("*")')
attachPolicySetPolicy("oracle/wss11_saml_or_username_token_with_message_protection_service_policy")
describeRepositorySession()
commitRepositorySession()

13.6 Webサービス・ジョブ定義の作成

Oracle JDeveloperとOracle Enterprise Manager Fusion Middleware Controlの両方に便利なグラフィカル・ユーザー・インタフェースが用意されていて、Webサービスのジョブ定義の作成に役立ちます。

「Oracle JDeveloperを使用したジョブ定義の作成」では、Oracle JDeveloperを使用してジョブ定義を作成する方法を説明し、「Oracle Enterprise Manager Fusion Middleware Controlを使用したジョブ定義の作成」では、Oracle Enterprise Manager Fusion Middleware Controlを使用して同様の作業を行う方法を説明します。

13.6.1 Oracle JDeveloperを使用したジョブ定義の作成

アプリケーションの作成時にOracle JDeveloperを使用してWebサービス・ジョブ定義を使用できます。Oracle JDeveloperを使用してOracle Enterprise Schedulerで動作するアプリケーションを作成する方法については、「Oracle JDeveloperを使用したOracle Enterprise Schedulerアプリケーションの生成」の一般情報を参照してください。

JDeveloperには、スクリーン・リーダー、スクリーン拡大鏡、キーボード移動用の標準のショートカット・キーなどのアクセシビリティ・オプションが用意されています。さらに読みやすくするため、フォントのサイズや色、オブジェクトの色や形など、JDeveloperをカスタマイズすることもできます。JDeveloperでのアクセシビリティについて、およびこれを構成する手順は、『Oracle JDeveloperによるアプリケーションの開発』のOracle JDeveloperのアクセシビリティ情報に関する項を参照してください。

次の手順は、非同期Webサービス・ジョブ・タイプのジョブ定義を作成する方法を示しています。

1. 「ジョブ定義」タブに移動します。「名前」、「表示名」および「説明」フィールドに入力し、図13-1の例に示すように適切なWebサービス・ジョブ・タイプを選択します。ターゲットWebサービスのWSDL URLを使用可能にします。

図13-1 Oracle JDeveloper: 「ジョブ定義」タブ

2. Webサービス・エクスプローラ・ボタンをクリックして、「Web Service」構成ウィザードを起動します(図13-2を参照)。WSDL URL、サービス、ポート、操作を入力し、例に示すようにペイロードXMLを構成し、「OK」をクリックします。

注意:

図13-2に示す例は、値が発行リクエスト時に指定される置換トークンSubmitArgument1を含む起動XMLペイロードを示しています。トークン置換については、「トークンおよび論理クラスタの使用」で説明しています。

図13-2 Oracle JDeveloper: 「Web Service」ポップアップ

3. セキュリティ・ポリシーの指定ボタンをクリックします(図13-3を参照)。「リクエスト用」を選択して、Job-Invokeポリシー・サブジェクトの直接アタッチされるポリシーを構成します。

図13-3 Oracle JDeveloper: 「ジョブ定義」タブ

4. Job-Invokeポリシー・サブジェクトは、すべてのWebサービス・ジョブ定義タイプ(一方向、同期および非同期)に使用できます。Job-Invokeの直接アタッチされるポリシーに必須のOWSMクライアント・ポリシーを選択しアタッチします。図13-4に示すような画面が表示されます。

図13-4 Oracle JDeveloper: ESS Webサービス・ポリシー・ポップアップ

5. これで、同期または一方向のWebサービス・ジョブ定義の直接アタッチされるポリシー構成が完了します。非同期ジョブ定義の場合、Job-Callbackポリシー・サブジェクトに対して直接アタッチされるポリシーを構成することもできます。

非同期ジョブ定義に対してJob-Callbackの直接アタッチされるポリシーを構成するには、この手順のステップ3を繰り返し、「リクエスト用」のかわりに「コールバック用」を選択します。Job-Callbackの直接アタッチされるポリシーに対して必須のOWSMサービス・ポリシーを選択およびアタッチします(図13-4を参照)。

注意:

デプロイメント後、Oracle Enterprise Manager Fusion Middleware Controlを使用して、Webサービス・ジョブ定義に関連付けられているジョブ・ポリシーを変更できます。

図13-5 Oracle JDeveloper: ESS Webサービス・ポリシー・ポップアップ

13.6.2 Oracle Enterprise Manager Fusion Middleware Controlを使用したジョブ定義の作成

この手順では、Oracle Enterprise Mangerを使用してWebサービス・ジョブ定義を作成および構成する方法を説明します。

1. Oracle Enterprise Manager Fusion Middleware Controlを起動しログインします。

2. ナビゲーション・ペインで、「スケジューリング・サービス」フォルダを展開し、Oracle Enterprise Schedulerアプリケーションを選択します。

3. 「スケジューリング・サービス」メニューから、「ジョブ・メタデータ」→「ジョブ定義」を選択し、「作成」ボタンをクリックします。

4. 「名前」、「表示名」および「説明」フィールドに入力し、「ジョブ・タイプ」ドロップダウンから図13-6の例に示すように適切なWebサービス・ジョブ・タイプを選択します。

図13-6 Fusion Middleware Controlコンソール: 「ジョブ定義の作成」ページ

5. 「Webサービスの選択」ボタンをクリックして、「Webサービスの選択」ポップアップ・ウィンドウでWSDL URLを入力します。URLを入力した後、サービス、ポート・タイプ、操作を選択し、起動操作XMLペイロードを構成します。

図13-7に示す例は、値が発行リクエスト時に指定される置換トークンSubmitArgument1を含む起動XMLペイロードを示しています。

注意:

トークン置換については、「トークンおよび論理クラスタの使用」で説明しています。

図13-7 Fusion Middleware Controlコンソール: 「Webサービスの選択」ポップアップ

6. ジョブ定義を作成した後、「ジョブ定義」ページに戻り、「結果」表のジョブ定義名(この例ではAsyncWSJob1)を選択します。「ポリシーのアタッチ/デタッチ」ボタンをクリックして、「起動」を選択し(図13-8を参照)、Job-Invokeポリシー・サブジェクトの直接アタッチされるポリシーを構成します。Job-Invokeポリシー・サブジェクトは、すべてのWebサービス・ジョブ・タイプ定義に使用できます。

図13-8 Fusion Middleware Controlコンソール: 「ジョブ定義」ページ

7. 「Webサービス・ポリシー」ページで、ポリシーを選択して「アタッチ/デタッチ」ボタンをクリックし、Job-Invokeの直接アタッチされるポリシーの必須のOWSMクライアント・ポリシーをアタッチします。これは、図13-9に示されています。「ポリシーのアタッチ/デタッチ」ポップアップが表示されます。

図13-9 Fusion Middleware Controlコンソール: 「Webサービス・ポリシー」ページ

8. ポリシーを選択し、「OK」をクリックしてアタッチを完了します。

図13-10 Fusion Middleware Controlコンソール: ポリシーのアタッチ・ポップアップ

9. これで、同期または一方向のWebサービス・ジョブ定義の直接アタッチされるポリシー構成が完了します。非同期ジョブ定義の場合、Job-Callbackポリシー・サブジェクの直接アタッチされるポリシーを構成することもできます。

非同期ジョブ定義に対してJob-Callbackの直接アタッチされるポリシーを構成するには、この手順のステップ6を繰り返し、「起動」のかわりに「コールバック」を選択します。Job-Callbackの直接アタッチされるポリシーに必須のOWSMサービス・ポリシーを選択しアタッチします。

14 プロセス・ジョブの作成と使用

この章では、Oracle Enterprise Schedulerを使用して、スクリプトまたはバイナリ・コマンドを分岐プロセスで実行するプロセス・ジョブを作成する方法について説明します。

この章の内容は次のとおりです。

- プロセス・ジョブ定義の作成の概要

- プロセス・ジョブ・タイプのジョブ定義の作成および格納

- プロセス・ジョブに対するエージェント・ハンドラの使用

- プロセス・ジョブのロケール

ランタイム・サービスの使用方法の詳細は、「ランタイム・サービスの使用」を参照してください。

14.1 プロセス・ジョブ定義の作成の概要

Oracle Enterprise Schedulerを使用すると、Javaクラス、PL/SQLストアド・プロシージャ、生成されたジョブとして実行されるプロセス・ジョブなど、様々なタイプのジョブ・リクエストを実行できます。

Oracle Enterprise Schedulerを使用してプロセス・タイプのジョブを実行するには、特定のメタデータを指定して、実行するプロセス・タイプのジョブの特性を定義する必要があります。また、実行時間のスケジュールなどの、ジョブ・リクエストのプロパティを指定する場合もあります。

Oracle Enterprise Schedulerを使用してプロセス・タイプのジョブ・リクエストを指定するには、次の3つのステップ・プロセスを実行します。

1. Oracle Enterprise Schedulerを使用して実行するスクリプトまたはバイナリ・コマンドを、作成または取得します。生成されたプロセスのためのスクリプトまたはコマンドは以前に作成済であると想定しているため、このステップについては説明しません。

2. Oracle Enterprise Scheduler APIをアプリケーションで使用して、ジョブ・タイプとジョブ定義のオブジェクトを作成し、これらのオブジェクトをメタデータ・リポジトリに格納します。

3. Oracle Enterprise Scheduler APIを使用して、ジョブ・リクエストを発行します。リクエストの発行方法の詳細は、「ランタイム・サービスの使用」を参照してください。

Oracle Enterprise Scheduler APIを使用したアプリケーションを作成した後、このアプリケーションをパッケージ化してデプロイする必要があります。

実行時に、ジョブ・リクエストを発行した後、ジョブ・リクエストをモニターおよび管理できるようになります。ジョブ・リクエストの監視および管理の詳細は、「ランタイム・サービスの使用」を参照してください。

14.2 プロセス・ジョブ・タイプのジョブ定義の作成および格納

Oracle Enterprise Schedulerでプロセス・タイプのジョブを使用するには、メタデータ・サービスを特定してジョブ定義を作成する必要があります。

ジョブ定義は、名前とジョブ・タイプを指定して作成します。ジョブ定義を作成するときには、特定のシステム・プロパティも設定する必要があります。ジョブ定義は、メタデータ・サービスを使用してメタデータ・リポジトリに格納できます。

メタデータ・サービスの使用方法の詳細は、「メタデータ・サービスの使用」を参照してください。

14.2.1 プロセス・ジョブ・タイプを作成および格納する方法

Oracle Enterprise SchedulerのJobTypeオブジェクトでは、実行タイプを指定し、ジョブ・リクエストの共通プロパティ・セットを定義します。1つのジョブ・タイプを定義して、1つ以上のジョブ定義で共有できます。Oracle Enterprise Schedulerでは、次の3つの実行タイプがサポートされています。

- JAVA_TYPE: Javaで実装され、コンテナ内で実行されるジョブ定義に使用します。

- SQL_TYPE: データベース・サーバーでPL/SQLストアド・プロシージャとして実行されるジョブ定義に使用します。

- PROCESS_TYPE: ホスト・オペレーティング・システムの制御下で個別のプロセスとして実行される、バイナリおよびスクリプトのジョブ定義に使用します。

JobTypeを指定する場合、JobTypeに関連付けられる特性を定義するSystemPropertiesを指定することもできます。表14-1に、リクエストによってプロセス・ジョブ・タイプに対するプロセスが生成された場合の、リクエストの処理方法を指定するプロパティを示します。

表14-1 プロセス・タイプのジョブのためのシステム・プロパティ

システム・プロパティ

説明

BIZ_ERROR_EXIT_CODE

実行ビジネス・エラーを示すプロセス・ジョブ・リクエストのプロセス終了コードを指定します。このプロパティが指定されていない場合、プロセス終了コード4は実行ビジネス・エラーとして処理されます。

CMDLINE

外部プログラムを起動するために必要なコマンド行。

ENVIRONMENT_VARIABLES

生成されたプロセスに対して設定される環境編集を表す名前/値ペア(name=value)のカンマ区切りリスト。

REDIRECTED_OUTPUT_FILE

プロセス・ジョブ・リクエストに対して標準出力およびエラー・ストリームがリダイレクトされるファイルを指定します。

REQUESTED_PROCESSOR

生成されたジョブが実行されるOracle WebLogic Serverノード。

SUCCESS_EXIT_CODE

プロセス・ジョブ・リクエストの正常実行を示すプロセス終了コード。このプロパティが指定されていない場合、プロセス終了コード0は正常完了として処理されます。

WARNING_EXIT_CODE

生成されたジョブの正常実行を示すプロセス終了コード。このプロパティが指定されていない場合、プロセス終了コード3は警告終了として処理されます。

WORK_DIR_ROOT

生成されたプロセスの作業ディレクトリ。

システム・プロパティの詳細は、「パラメータとシステム・プロパティの使用」を参照してください。

例14-1に、PROCESS_TYPEを使用したジョブ定義のサンプルを示します。

例14-1に示すように、プロセス・ジョブ・タイプを作成して格納する場合は、次を実行します。

- JobTypeコンストラクタを使用して、String名とJobType.ExecutionType.PROCESS_TYPE引数を指定します。

- 「メタデータ・サービスへのアクセス」に示されているように、メタデータ・ポインタを取得します。メタデータ・サービスのaddJobType()メソッドを使用して、JobTypeをメタデータに格納します。

- addJobType()によって返されるMedatdataObjectIdでは、一意の識別子を使用して、メタデータ・リポジトリ内のメタデータ・オブジェクトを一意に識別します。

例14-1 Oracle Enterprise Schedulerジョブ定義の作成およびジョブ定義プロパティの設定

import oracle.as.scheduler.ConcurrentUpdateException;
import oracle.as.scheduler.JobType;
import oracle.as.scheduler.JobDefinition;
import oracle.as.scheduler.MetadataService;
import oracle.as.scheduler.MetadataServiceHandle;
import oracle.as.scheduler.MetadataObjectId;
import oracle.as.scheduler.MetadataServiceException;
import oracle.as.scheduler.ParameterInfo;
import oracle.as.scheduler.ParameterInfo.DataType;
import oracle.as.scheduler.ParameterList;
import oracle.as.scheduler.SystemProperty;
import oracle.as.scheduler.ValidationException;

void createDefinition( )
throws MetadataServiceException,ConcurrentUpdateException,
ValidationException
{
MetadataService metadata = ...
MetadataServiceHandle mshandle = null;

try
{
ParameterInfo pinfo;
ParameterList plist;

mshandle = metadata.open();

// Define and add a PL/SQL job type for the application metadata.
String jobTypeName = "ProcessJobDefType";
JobType jobType = null;
MetadataObjectId jobTypeId = null;

jobType = new JobType(jobTypeName, JobType.ExecutionType.
PROCESS_TYPE);

plist = new ParameterList();
pinfo = SystemProperty.getSysPropInfo(SystemProperty.CMDLINE);
plist.add(pinfo.getName(), pinfo.getDataType(), "/bin/myprogram
arg1 arg2", false);
pinfo = SystemProperty.getSysPropInfo(SystemProperty.
ENVIRONMENT_VARIABLES);
plist.add(pinfo.getName(), pinfo.getDataType(),
"LD_LIBRARY_PATH=/usr/lib", false);
pinfo = SystemProperty.getSysPropInfo(SystemProperty.PRODUCT);
plist.add(pinfo.getName(), pinfo.getDataType(), "HOW_TO_PROD", false);
jobType.setParameters(plist);

jobTypeId = metadata.addJobType(mshandle, jobType, "HOW_TO_PROD");

// Define and add a job definition for the application metadata.
String jobDefName = "ProcessJobDef";
JobDefinition jobDef = null;
MetadataObjectId jobDefId = null;

jobDef = new JobDefinition(jobDefName, jobTypeId);
jobDef.setDescription("Demo Process Type Job Definition " +
jobDefName);

plist = new ParameterList();
plist.add("myJobdefProp", DataType.STRING, "myJobdefVal", false);

pinfo = SystemProperty.getSysPropInfo(SystemProperty.
REDIRECTED_OUTPUT_FILE);
plist.add(pinfo.getName(), pinfo.getDataType(), "/tmp/" + jobDefName
+ ".out", false);

jobDef.setParameters(plist);

jobDefId = metadata.addJobDefinition(mshandle, jobDef, "HOW_TO_PROD");
}
catch (Exception e)
{
[...]
}
finally
{
// Close metadata service handle in finally block.
if (null != mshandle)
{
metadata.close(mshandle);
mshandle = null;
}
}
}

14.2.2 プロセス・タイプのジョブ定義を作成および格納する方法

プロセス・タイプのジョブを使用するには、ジョブ定義を作成して格納する必要があります。

注意:

ジョブ・タイプを指定してジョブ定義を作成した後で、タイプやジョブ定義名を変更することはできません。ジョブ・タイプやジョブ定義名を変更するには、新しいジョブ定義を作成する必要があります。

例14-1に、ジョブ定義コンストラクタおよびジョブ・タイプを使用してジョブ定義を作成する方法を示します。表14-1に、ジョブ定義に関連付けられる一部のシステム・プロパティを示します。

例14-1に示すように、ジョブ定義を作成して格納する場合は、次を実行します。

- JobDefinitionコンストラクタを使用して、String名およびメタデータに格納されているジョブ・タイプを指すMetadataObjectIDを指定します。

- 新しいジョブ定義に対して適切なプロパティを設定します。

- 「メタデータ・サービスへのアクセス」に示されているように、メタデータ・ポインタを取得します。次に、メタデータ・サービスaddJobDefinition()メソッドを使用して、ジョブ定義をメタデータ・リポジトリに格納し、MetadataObjectIDを返します。

14.3 プロセス・ジョブに対するエージェント・ハンドラの使用

Oracle Enterprise Schedulerで個別のプロセス・ジョブを管理するには、エージェント・ハンドラが必要です。エージェント・ハンドラは、プロセス・ジョブの実行を検証、生成、モニターおよび制御し、またプロセス・ジョブの終了ステータスをOracle Enterprise Schedulerに返します。

エージェント・ハンドラにより、Oracle Enterprise Schedulerの可用性のモニターやジョブ取消しリクエストの処理も行われます。ジョブが異常終了した(またはジョブの取消しリクエストが発行された)場合、エージェント・ハンドラは生成されたプロセスを(その子とともに)終了し、エージェント・ハンドラも終了します。これにより、オペレーティング・システム・タイプが検出され、適切なシステム・コールを使用して、プロセス・ジョブが起動、管理および終了されます。

Oracle Enterprise Schedulerのエージェント・ハンドラを使用して、そのログを/tmpフォルダに生成できます。ログの生成は、Oracle Enterprise Schedulerのログ・レベルをFINE、FINERまたはFINESTに設定して、/tmpフォルダへの読取り権限および書込み権限を確保することによって有効化する必要があります。プロセス・ジョブの起動ごとにログ・ファイルが1つ生成されます。ログ・ファイルには、プロセス・ジョブの起動ログがリストされ、ここには、環境変数のリスト、プロセス・ジョブに対して指定されたコマンド行とリダイレクトされた出力ファイル、プロセス・ジョブのプロセスIDと終了コード、プロセスの生成中に検出されたエラーなどが含まれます。

14.3.1 エージェント・ハンドラの選択

Oracle Enterprise Schedulerでは、2つの異なるエージェント・ハンドラ、つまりJavaエージェント・ハンドラとPerlエージェント・ハンドラが提供されます。両方のエージェント・ハンドラの機能は同等ですが、Javaエージェント・ハンドラではWindowsでのterminate-spawned-process-on-restart動作がサポートされていないという点が異なります。

デフォルトで、Oracle Enterprise Schedulerでは、標準および拡張モードのリクエストにJavaエージェント・ハンドラが使用されます。Fusionモードでのリクエストには、常時、Perlのエージェント・ハンドラを使用します。標準および拡張リクエスト・モードでPerlのエージェント・ハンドラを使用するには、プロセスのジョブを実行しているホスティング・アプリケーションに関連付けられたess-config.xmlファイルに、次の例に示すようにPerlCommandプロパティを追加する必要があります。

<EssProperties>
<EssProperty key="RequestFileDirectory" value="/tmp/ess/requestFileDirectory"/>
<EssProperty key="RequestFileDirectoryShared" value="false"/>
...
<EssProperty key="PerlCommand" value="/usr/bin/perl"/>
</EssProperties>

ディレクトリ名などの環境に依存する値を指定するため、トークンの置換を使用できます。詳細は、「トークンおよび論理クラスタの使用」を参照してください。

Oracle Enterprise SchedulerのPerlエージェントには、Oracle Perlバージョン5.10以上が必要です。プロセス・ジョブをサポートするPerlをインストールする手順は、『Oracle Fusion Middleware Oracle Enterprise Schedulerの管理』の「プロセス・ジョブをサポートするPerlの構成」に記載されています。

注意:

Fusion Applications環境でOracle Enterprise Schedulerを実行する場合、Perlエージェント・ハンドラを使用する必要があります。

14.4 プロセス・ジョブのロケール

個々のプロセス・ジョブは、実行時にプロセス・ジョブに適用されるロケール環境変数設定によって決定される様々なロケールおよびエンコーディングを使用できます。プロセス・ジョブでは、リクエストの完了後にOracle Enterprise Schedulerにより、リクエスト・ログおよび出力ファイルがコンテンツ・ストアにインポートされます。

プロセス・ジョブのロケール環境変数は、プロセス・ジョブ定義やホスティング・アプリケーションのess-config.xmlファイルなど、複数の場所で指定できます。プロセス・ジョブのロケール解決ロジックは、次の優先順位でリクエストに有効なLC_ALLおよびLANG環境変数を決定します。

1. リクエストに関連付けられているSYS_environment(最も高い優先順位)

2. ホスティング・アプリケーションのess-config.xmlファイル

3. WebLogic Serverのロケール(最も低い優先順位)

すべてのプロセス・ジョブで、有効なロケールおよびエンコーディングは、前述の優先順位に基づいて決定されます(有効なLC_ALL値は有効なLANG値をオーバーライドします)このエンコーディングは、ログにのみ適用され、出力には適用されません。

15 スケジュールの定義および使用

この章では、Oracle Enterprise Schedulerジョブ定義に関連付けることができるスケジュールを定義して、ジョブ・リクエストが実行されるタイミングを指定したり、Oracle Enterprise Schedulerでの処理用に、時間ベースの制御を指定する作業シフトなどの管理アクションを含める方法について説明します。

この章の内容は次のとおりです。

- スケジュールの概要

- 繰返しの定義

- 明示的な日付の定義

- 除外の定義および格納

- スケジュールの定義および格納

- 特定のスケジュールを使用するジョブ・リクエストの識別

- スケジュールの更新および削除

15.1 スケジュールの概要

Oracle Enterprise Schedulerを使用してスケジュールを作成し、ジョブ・リクエストが実行されるタイミングを決定したり、作業割当てがアクティブになるタイミングを決定するなど、他の目的にもスケジュールを使用できます。スケジュールには、2012年7月14日などの、明示的な日付のリストを含めることができます。スケジュールには、繰り返される日付(または時間と日付)のセットを表す式を含めることもできます。

Oracle Enterprise Schedulerを使用して、次の1つ以上を含むスケジュールを作成します。

- 明示的な日付: スケジュールまたは除外で使用する日付を定義します。

- 繰返し: 繰り返される日付と時間のパターンを表す式を含めます。たとえば、毎週月曜日の10:00AMなど、定期的な時間を表す繰返しを指定できます。

- 除外: スケジュールから除外する日付または日付と時間のリストを含めます。たとえば、除外を作成して、スケジュールから除外する休日のリストを含めることができます。

15.2 繰返しの定義

繰返しは、繰り返される日付と時間を表す式です。繰返しは、Oracle Enterprise SchedulerのRecurrenceオブジェクトを使用して指定します。Recurrenceオブジェクトは、スケジュールを作成するときに、または日付のリストを指定する除外で使用します。

Recurrenceコンストラクタを使用して、次のように繰返しを作成できます。

- RecurrenceFieldsクラスで定義されているフィールド(DAY_OF_MONTHなど)を使用します。

- iCalendar (RFC 2445)仕様に準拠する繰返し式を使用します。iCalendar RFC 2245式の使用の詳細は、次を参照してください。
http://www.ietf.org/rfc/rfc2445.txt

注意:

繰返しを作成するとき、各繰返しインスタンスについて、これらの2つのメカニズムのいずれか1つのみを使用できます。

繰返しには、次のものも含まれます(これらは必須ではありません)。

- 開始日: 繰返しパターンの開始時間および日付。

- 終了日: 繰返しパターンの終了時間および日付。

- カウント: 繰返しパターンのカウント。カウントは、オブジェクトによって最大何回生成されるかを示します。たとえば、毎週月曜日の10:00AMのような定期的な時間を表す繰返しを指定し、カウントに4を指定すると、この繰返しには月曜日が4回のみ含まれます。

開始日、終了日およびカウント属性は、繰返しのRecurrenceFieldsヘルパー・ベースのインスタンスまたはiCalendarベースのインスタンスのいずれかに対してのみ有効です。

Recurrenceオブジェクトのインスタンスが正しく定義された完全な繰返しパターンを表しているかどうかをチェックする繰返しのvalidate()メソッドを使用して、繰返しを検証できます。Recurrenceインスタンスは、日付または日付と時間の出現を生成するために最小限必要なフィールドを持っている場合に、完全とみなされます。

15.2.1 繰返しフィールド・ヘルパーによる繰返しの定義方法

繰返しフィールド・ヘルパーを使用して、繰返しを作成できます。RecurrenceFieldsヘルパー・クラスによって、繰返しパターンを指定するためのわかりやすい方法が提供されます。表15-1に、繰返しパターンを指定するために使用できる繰返しフィールド・ヘルパー・クラスを示します。

表15-1 繰返しフィールド・ヘルパー・パターン

繰返しフィールド

説明

DAY_OF_MONTH

日付を定義します。

DAY_OF_WEEK

曜日の列挙。

FREQUENCY

繰返しの繰返し頻度を定義します。選択肢は次のとおりです。

- DAILY: 毎日の繰返しを示します。

- HOURLY: 毎時の繰返しを示します。

- MINUTELY: 毎分の繰返しを示します。

- MONTHLY: 毎月の繰返しを示します。

- SECONDLY: 毎秒の繰返しを示します。

- WEEKLY: 毎週の繰返しを示します。

- YEARLY: 毎年の繰返しを示します。

MONTH_OF_YEAR

月を定義します。

TIME_OF_DAY

時間を定義します。

WEEK_OF_MONTH

月の週の列挙。

YEAR

年の値をカプセル化します。

例15-1は、RecurrenceFieldsヘルパー・クラスを使用して作成された繰返しのサンプルを示しており、ここでは、開始日および終了日を使用せずに、週単位の頻度(毎週月曜日の10:00 a.m.)を指定しています。

例15-1では、次のことに注意してください。

- スケジュールは、そのスケジュールを使用するジョブ・リクエストの発行時に、Oracle Enterprise Schedulerによって実行時に提供される開始時間で指定された時間にアクティブになります。

- 間隔パラメータ1は、この繰返しにより出現が毎週生成されることを示します。この値は、頻度と間隔を乗算することによって算出します。

例15-2に、開始日および終了日のない、4時間ごとの繰返しのサンプルを示します。この繰返しは、RecurrenceFieldsヘルパー・クラスを使用して作成されており、時間単位の頻度、間隔の乗数の4、NULLの開始日およびNULLの終了日が指定されています。

例15-2では、次のことに注意してください。

- スケジュールは、そのスケジュールを使用するジョブ・リクエストの発行時に、Oracle Enterprise Schedulerによって実行時に提供される開始時間で指定された時間にアクティブになります。

- 間隔パラメータ4は、この繰返しにより出現が4時間ごとに生成されることを示します。この値は、頻度と間隔を乗算することによって算出します。

例15-3に、RecurrenceFieldsヘルパー・クラスを使用して作成され、月単位の頻度が指定された繰返しのサンプルを示します。

例15-3では、次の特性のある繰返しを指定しています。

- 値が1の間隔パラメータが含まれており、これにより、繰返しによって出現が毎月生成されることを指定しています。

- 月の週の指定が含まれており、2週目を指定しています。

- 曜日の指定(火曜日)が含まれています。

- 時間の指定が含まれており、値は11:00です。

例15-4に、RecurrenceFieldsヘルパー・クラスを使用して作成され、月単位の頻度と開始日時が指定された繰返しのサンプルを示します。

例15-4では、次の特性のある繰返しを定義しています。

- 終了日がNULLとして指定され、これは終了日がないことを意味します。

- この繰返しを使用すると、開始日がCalendarインスタンスcalで指定され、その値はset()メソッド・コールで設定されます。

例15-1 週単位の頻度による繰返しの定義

Recurrence recur1 =
new Recurrence(RecurrenceFields.FREQUENCY.WEEKLY, 1, null, null);
recur1.addDayOfWeek(RecurrenceFields.DAY_OF_WEEK.MONDAY);
recur1.setRecurTime(RecurrenceFields.TIME_OF_DAY.valueOf(10, 0, 0));
recur1.validate();

例15-2 4時間ごとの頻度による繰返しの定義

Recurrence recur2 =
new Recurrence(RecurrenceFields.FREQUENCY.HOURLY, 4, null, null);
recur2.validate();

例15-3 月単位の頻度による繰返しの定義

Recurrence recur3 =
new Recurrence(RecurrenceFields.FREQUENCY.MONTHLY, 1, null, null);
recur3.addWeekOfMonth(RecurrenceFields.WEEK_OF_MONTH.SECOND);
recur3.addDayOfWeek(RecurrenceFields.DAY_OF_WEEK.TUESDAY);
recur3.setRecurTime(RecurrenceFields.TIME_OF_DAY.valueOf(11, 00, 00));
recur3.validate();

例15-4 開始日時が指定された繰返しの定義

Calendar cal = Calendar.getInstance();
cal.set(Calendar.YEAR, 2007);
cal.set(Calendar.MONTH, Calendar.JULY);
cal.set(Calendar.DAY_OF_MONTH, 1);
cal.set(Calendar.HOUR, 9);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.SECOND, 0);
Recurrence recur4 = new Recurrence(RecurrenceFields.FREQUENCY.WEEKLY,
1,
cal,
null);
recur4.validate();

15.2.2 iCalendar RFC 2445仕様による繰返しの定義方法

RecurrenceコンストラクタとiCalendar (RFC 2445)仕様を含むStringをともに使用して、繰返しパターンを指定できます。

iCalendar RFC 2245式の使用の詳細は、次のリンクを参照してください。

http://www.ietf.org/rfc/rfc2445.txt

例15-5に、iCalendar式を使用して作成された繰返しのサンプルを示します。

注意:

iCalendar式では、次のものはサポートされていません。

COUNT、UNTIL、BYSETPOS、WKST

setCountメソッドを使用して、Recurrenceオブジェクトにカウントを直接指定できます。

例15-5 iCalendar文字列式を使用した繰返しの定義

Recurrence recur5 = new Recurrence("FREQ=YEARLY;INTERVAL=1;BYMONTH=5;BYDAY=2MO;");
recur5.validate();

15.2.3 繰返しフィールド・ヘルパーの使用に関する必知事項

RecurrenceFieldsヘルパーを使用して繰返しを定義する場合は、次のことに注意してください。

- RecurrenceFieldsヘルパー・クラスを使用して繰返しパターンを定義する場合、いずれかのRecurrenceFields.FREQUENCY定数を使用して頻度を指定することが、常に必須となります(頻度の詳細は、表15-1を参照してください)。

- 繰返しコンストラクタにおいて指定される頻度間隔は、指定された頻度の乗数として使用される整数です。たとえば、頻度がRecurrenceFields.FREQUENCY.HOURLYであり、間隔が8の場合、この組合せは8時間ごとを表します。

- 開始日または終了日の指定はオプションです。ただし、開始日または終了日が指定された場合、開始日より前および終了日より後(指定されている場合は、関連付けられた開始時間より前および終了時間より後)には、オブジェクトによって出現が生成されないことが保証されます。

- 通常、開始日と繰返しフィールドの両方が使用される場合、繰返しフィールドが常に優先されます。この制限は、次のことを意味します。

- 開始日とRecurrenceFieldsの頻度フィールドのみが指定されている場合、頻度フィールドを使用して、その開始日を最初の出現とする出現が開始日によって定義されます。たとえば、開始日が01-MAY-2007:09:00:00、RecurrenceFields.FREQUENCYがWEEKLYと指定されており、他の繰返しフィールドが使用されていない場合、出現は01-MAY-2007:09:00:00から毎週1回発生します(さらに、08-MAY-2007:09:00:00、15-MAY-2007:09:00:00と続きます)。
つまり、開始日を頻度フィールドの指定とともに指定することによって、繰返しパターンを簡単に定義できます。

- 開始日または終了日がその他の繰返しフィールドとともに指定される場合は、繰返しフィールドが優先され、開始日または終了日は絶対的な境界点としてのみ使用されます。たとえば、開始日が01-MAY-2007:09:00:00、頻度がWEEKLYと指定されている場合に、追加の繰返しフィールドDAY_OF_WEEKに値WEDNESDAYを指定して使用すると、出現は01-MAY-2007直後の水曜日から毎週水曜日に発生します。01-MAY-2007は火曜日であるため、最初の出現は01-MAY-2007:09:00:00ではなく、02-MAY-2007:09:00:00に発生します。
この場合、開始日が01-MAY-2007:09:00:00で、TIME_OF_DAYも11:00:00に指定された場合、すべての出現は11:00:00に発生し、開始日に指定された時間の09:00:00がオーバーライドされます。

- 頻度のみが指定され、繰返しに開始日、開始時間およびTIME_OF_DAYフィールドのいずれも含まれない場合、Oracle Enterprise Schedulerによって実行時に提供されるタイムスタンプに基づいて、出現が発生します(通常、このタイムスタンプはリクエスト発行時に提供されます)。
たとえば、繰返しで2時間ごとの繰返しが指定されている場合、ジョブ・リクエストの発行時間によって出現の開始時間が決まります。つまり、そのような場合、ジョブ・リクエストの出現はそれぞれ2時間ごとになりますが、複数のジョブ・リクエストが発行されると、それぞれの開始時間は異なり、各ジョブ・リクエストのリクエスト発行時に設定されます。

- 開始日を使用しない場合は、繰返しパターンが完全に定義されるように繰返しフィールドを含めることができます。たとえば、MONTH_OF_YEARのみを指定し、開始日がともに指定されない場合、繰返しパターンは定義されません。開始日が指定されない場合に、パターンを定義するために必要な最小繰返しフィールド数は、使用される頻度の値に応じて異なります。たとえば、頻度がWEEKLYの場合、週単位の出現が発生する曜日を定義するには、DAY_OF_WEEKおよびTIME_OF_DAYのみで十分です。頻度がYEARLYの場合に、繰返しパターンを定義するには、MONTH_OF_YEAR、DAY_OF_MONTH(またはWEEK_OF_MONTHおよびDAY_OF_WEEK)およびTIME_OF_DAYで十分です。

- 頻度フィールドを除き、繰返しフィールドには複数の値を指定できます。ただし、実行時、無効な組合せは、Oracle Enterprise Schedulerによって警告なしでスキップされます。たとえば、MONTH_OF_YEARが1月から6月と指定され、DAY_OF_MONTHが30と指定される場合、繰返しでは無効な日(2月の30日)がスキップされます。

15.2.4 iCalendar式の使用に関する必知事項

iCalendar式で繰返しを定義する場合は、次のことに注意してください。

- 繰返しに開始日および時間のいずれも含まれず、iCalendar式で時間が指定されない場合、Oracle Enterprise Schedulerによって実行時に提供されるタイムスタンプに基づいて、出現が発生します(通常、このタイムスタンプはリクエスト発行時に提供されます)。
たとえば、繰返しで2時間ごとの繰返しを指定でき、ジョブ・リクエストの発行の開始日時によって出現の具体的な開始時間が決まります。このように開始時間が指定されないと、異なるジョブ・リクエストの出現の発生時間は、各リクエストの発行時間に応じて異なる場合がありますが、個々の出現の間隔は2時間です。

- setStartDate()による開始日の指定またはsetEndDate()による終了日の指定はオプションです。ただし、開始日または終了日が指定された場合、開始日より前および終了日より後(指定されている場合は、関連付けられた開始時間より前および終了時間より後)には、オブジェクトによって出現が生成されないことが保証されます。

15.3 明示的な日付の定義

明示的な日付により、スケジュールまたは除外で使用される日時が定義されます。RecurrenceFieldsクラスの適切なフィールドを使用して、ExplicitDateを構築します。

15.3.1 明示的な日付の定義方法

例15-6に明示的な日付の定義を示します。

例15-6 明示的な日付の定義

ExplicitDate date = new ExplicitDate(RecurrenceFields.YEAR.valueOf(2007), RecurrenceFields.MONTH_OF_YEAR.AUGUST,RecurrenceFields.DAY_OF_MONTH.valueOf(17));

例15-6では、RecurrenceFieldsヘルパーによりコンストラクタ内で日付が定義され、値には時間が含まれていません。オプションでsetTimeを使用して、明示的な日付に関連付けられる時間を設定できます。

15.3.2 明示的な日付に関する必知事項

時間部分が指定されないjava.util.Calendarと比較した場合、ExplicitDateクラスでは部分的な日付を定義できます。さらに、TimeZoneなどのその他すべてのjava.util.Calendarフィールドは、ExplicitDateとともには定義されません。ExplicitDateで時間部分が指定されない場合、Oracle Enterprise Schedulerにより適切な時間が算出されます。たとえば、2007年6月1日より後の毎週月曜日を示すスケジュールがあるとし、2007年8月17日(金曜日)の明示的な日付を追加するとします。この例では、2007年8月17日には時間が含まれていないため、これは部分的な日付です。

15.4 除外の定義および格納

Oracle Enterprise Schedulerの除外を使用して、スケジュールから除外する必要がある日付を表すことができます。たとえば、除外を使用して、スケジュールでスキップする休日のリストを作成できます。

15.4.1 除外の定義方法

Exclusionオブジェクトを使用して、個別の除外を表します。ExplicitDateまたはRecurrenceオブジェクトのいずれかを使用して、除外で除外する日付を定義できます。

例15-7に、繰返しを使用してExclusionインスタンスを作成する方法を示します。

例15-7では、個別の除外を定義しています。除外のリストの作成の詳細は、「除外定義の作成方法」を参照してください。

例15-7 明示的な日付および除外の定義

Recurrence recur = new Recurrence(RecurrenceFields.FREQUENCY.YEARLY, 1);
recur.addMonth(RecurrenceFields.MONTH_OF_YEAR.JULY);
recur.addDayOfMonth(RecurrenceFields.DAY_OF_MONTH.valueOf(4));
Exclusion e = new Exclusion("Independence Day", recur);

15.4.2 除外定義の作成方法

除外のリストを作成して、除外日を維持するには、次を実行します:

1. 除外のリストを作成します。

2. 除外のリストを使用して、ExclusionsDefinitionオブジェクトを定義します。

3. メタデータ・サービスのaddExclusionDefinition()メソッドを使用して、ExclusionsDefinitionを維持します。

例15-8 ExlusionDefinitionでの除外のリストの作成および格納

Collection<Exclusion> exclusions = new ArrayList<Exclusion>();
Exclusion e = new Exclusion("Independence Day", recur);
exclusions.add(e);
ExclusionsDefinition exDef1 =
new ExclusionsDefinition("OrclHolidays1", "Annual Holidays", exclusions);
MetadataServiceHandle handle = m_service.open();
MetadataObjectId exId1 = m_service.addExclusionDefinition(handle,exDef1,
"METADATA_UNITTEST_PROD");

最後に、ExclusionsDefinitionをスケジュールに関連付ける場合は、スケジュールのaddExclusion()メソッドを使用します。

例15-8に、ExclusionDefinitionを作成して、メタデータ・リポジトリに定義を格納する方法を示します。

例15-8では、ExclusionsDefinitionコンストラクタに3つの引数が必要であることに注意してください。

15.5 スケジュールの定義および格納

Oracle Enterprise Schedulerを使用してスケジュールを作成し、ジョブ・リクエストが実行されるタイミングを決定したり、他の目的にもスケジュールを使用できます(作業割当てがアクティブになるタイミングを決定するなど)。スケジュールには、2007年6月13日などの明示的な日付のリスト、または繰り返される日付や日付および時間を表す式のセットが含まれます。スケジュールでは、特定の除外および包含日付も指定できます。

次のものを使用してスケジュールを作成します。

- 明示的な日付: スケジュールまたは除外で使用する日付を定義します。詳細は、「明示的な日付の定義」を参照してください

- 繰返し: 繰り返される日付と時間のパターンを表す式を含めます。たとえば、毎週月曜日の10:00AMなど、定期的な時間を表す繰返しを指定できます。詳細は、「繰返しの定義」を参照してください

- 除外: スケジュールから除外する日付または日付と時間のリストを含めます。たとえば、除外を作成して、スケジュールから除外する休日のリストを含めることができます。詳細は、「除外の定義および格納」を参照してください

15.5.1 スケジュールの定義および格納方法

スケジュールを定義する手順は、次のとおりです。

1. Oracle Enterprise SchedulerのScheduleオブジェクトを定義し、新しいスケジュールを作成するためのスケジュール・コンストラクタを使用して、スケジュールを作成します。

2. メタデータ・サービス参照m_metadataServiceを取得し、MetadataServiceHandleを使用して、tryブロック内でメタデータ・セッションを開きます。

MetadataObjectId scheduleId = m_service.addScheduleDefinition(handle,schedule,"HOW_TO_PROD");

3. 日付、繰返しおよび除外を定義します。

4. addScheduleDefinitionを使用してスケジュールを格納します。

5. finallyブロックでセッションを閉じます。

15.5.2 スケジュールの定義および格納時の処理内容

例15-9に、毎週月曜日の10:00AMに実行するように指定された、週次スケジュールのRecurrenceFieldsヘルパー・クラスを持つ繰返しを使用したスケジュール定義のサンプルを示します。

このスケジュールでは、addInclusionDate()メソッドを使用してスケジュール内の出現に明示的な日付を追加し、addExclusionDate()メソッドを使用してスケジュールの出現から5月15日の日付を明示的に除外します。

例15-10に、スケジュールを格納するために使用されるサンプル・コードを示します。メソッドaddScheduleDefinition()は、tryブロック内でスケジュールを格納するために使用され、その後にエラー処理を含むfinallyブロックが続きます。

例15-9 RecurrenceFieldsヘルパーを使用したスケジュールの繰返しの作成

Recurrence recur = new Recurrence(RecurrenceFields.FREQUENCY.WEEKLY, 1);
recur.addDayOfWeek(RecurrenceFields.DAY_OF_WEEK.MONDAY);
recur.setRecurTime(RecurrenceFields.TIME_OF_DAY.valueOf(10, 0, 0));

ExplicitDate july10 = new ExplicitDate(RecurrenceFields.YEAR.valueOf(2008),
RecurrenceFields.MONTH_OF_YEAR.JULY,
RecurrenceFields.DAY_OF_MONTH.valueOf(10));

ExplicitDate may15 = new ExplicitDate(RecurrenceFields.YEAR.valueOf(2008),
RecurrenceFields.MONTH_OF_YEAR.MAY,
RecurrenceFields.DAY_OF_MONTH.valueOf(15));

Schedule schedule = new Schedule("everyMonday", "Weekly Schedule", recur);
schedule.addInclusionDate(july10);
schedule.addExclusionDate(may15);

例15-10 スケジュールの格納

MetadataServiceHandle handle = null;
boolean abort = true;
try
{
handle = m_service.open();
m_service.addScheduleDefinition(handle, schedule, "HOW_TO_PROD");
abort = false;
}
finally
{
if (handle != null)
{
m_service.close(handle, abort);
}
}

15.5.3 スケジュールでのタイムゾーンの処理に関する必知事項

java.util.TimeZoneオブジェクトを使用して、スケジュールにタイムゾーンを設定できます。スケジュールのsetTimeZone()メソッドを使用して、スケジュールのTimeZoneを設定するか消去します。スケジュール・オブジェクトにTimeZoneが設定されている場合は、スケジュール・メソッドgetTimeZone()によってjava.util.TimeZone値が返されます。

15.6 特定のスケジュールを使用するジョブ・リクエストの識別

Fusion Middleware Controlを使用して、特定のスケジュールを使用するジョブ・リクエストを検索できます。

特定のスケジュールを使用するジョブ・リクエストの検索の詳細は、『Oracle Fusion Middleware Oracle Enterprise Schedulerの管理』の「Oracle Enterprise Schedulerリクエストの管理」、Oracle Enterprise Schedulerジョブ・リクエストの検索に関する項を参照してください。

15.7 スケジュールの更新および削除

Fusion Middleware Controlを使用して、スケジュールを編集および削除できます。

スケジュールの編集および削除の詳細は、『Oracle Fusion Middleware Oracle Enterprise Schedulerの管理』の「Oracle Enterprise Schedulerリクエストの管理」、スケジュールの管理に関する項を参照してください。

16 Oracle Enterprise Scheduler Webサービスの使用

この章では、Oracle Enterprise Scheduler Webサービスを使用して、Oracle Enterprise Schedulerランタイム機能のサブセットにアクセスする方法について説明します。

この章の内容は次のとおりです。

- Oracle Enterprise Scheduler Webサービスの概要

- ESSWebserviceアプリケーションの開発および使用

- ESSWebservice WSDLファイル

- ユースケース: BPELプロセスでのOracle Enterprise Scheduler ESSWebserviceの使用

16.1 Oracle Enterprise Scheduler Webサービスの概要

Oracle Enterprise Schedulerでは、エンタープライズ・レベルのスケジューリング用の豊富な機能セットを提供します。

機能には、次の操作のサポートが含まれます。

- Oracle Enterprise Schedulerメタデータの作成および管理

- Oracle Enterprise Schedulerジョブ・リクエストの発行および管理

- Oracle Enterprise Schedulerの構成および管理

クライアント・アプリケーションは、Oracle Enterprise Scheduler Webサービス(ESSWebservice)を使用して、Oracle Enterprise Schedulerランタイム機能のサブセットにアクセスできます。ESSWebserviceは、主に、BPELプロセスからOracle Enterprise Schedulerを呼び出すなど、SOA統合をサポートするために提供されています。ただし、Webサービスを使用してOracle Enterprise Schedulerと相互作用する必要があるすべてのクライアントでは、ESSWebserviceを使用できます。ESSWebserviceでは、リクエスト発行およびリクエスト管理用のジョブ・スケジューリングおよび管理機能を公開しています。

ESSWebserviceは、Oracle Enterprise Schedulerランタイム・フレームワークにおけるJava EEアプリケーションであるOracle Enterprise Schedulerアプリケーション内でデプロイされます。このため、ESSWebserviceは、Oracle Enterprise Schedulerがインストールおよびデプロイされているすべてのノードで使用できます。

ESSWebserviceは同期Webサービスであり、たとえば、呼び出された操作はすべて同期操作となります。Oracle Enterprise Scheduler内部ジョブの実行モデルは非同期ですが、ESSWebservice APIは非同期である必要はありません。ただし、Oracle Enterprise Scheduler Webサービスは、ジョブ完了イベントを(コアAPIレイヤーでのOracle Enterprise Scheduler EventListener規定の実装と同様の方法で)非同期で取得する機能も提供します。

ESSWebservice WSDLでは、ESSWebserviceの完全な機能を記述します。表16-1に、ESSWebserviceで使用可能な操作の要約を示します。

表16-1 ESSWebserviceで使用可能な操作の要約

操作

通信タイプ

説明

addPPAction

同期

後処理アクションをジョブ・セット・リクエスト内のステップに追加します。このメソッドは、リクエストの発行前にコールされます。このメソッドでは、同時処理においてadd_printer、add_notification、add_layoutによって以前サポートされていたアクションのサポートを提供します。これらのレガシー・ルーチンへのパラメータは、addPPActionへの引数として、元のルーチンで宣言されていた順序で渡されます。

addPPActions

同期

リクエスト内の複数のアクションをパッケージ化できる点を除き、addPPActionと似ています。

cancelRequest

同期

終了状態にないリクエストの処理を取り消します。

Oracle Enterprise SchedulerOracle Enterprise SchedulerOracle Enterprise Scheduler

Oracle Enterprise SchedulerOracle Enterprise Scheduler

同期

終了状態にあるリクエストを削除対象としてマークします。リクエストがほとんどのメソッドでアクセスできなくなりますが、データは物理的に削除されません。

親リクエストの場合、この操作はすべての子にカスケードされます。

getCompletionStatus

非同期

リクエストの完了時に非同期ステータス更新に登録します。個別の非同期レスポンスでの一方向操作です。

getRequestExecutionContext

同期

oracle.as.scheduler.RequestExectionContextオブジェクトを、シリアライズされたリクエスト実行コンテキスト文字列から取得します。この操作は、リモートで実行中のESSジョブからのみ起動する必要があります。

getRequestDetail

同期

指定したリクエストのランタイム詳細を取得します。

getRequestState

同期

指定したリクエストの現在の状態を取得します。

holdRequest

同期

WAITまたはREADY状態にあるリクエストのそれ以降の処理を保留にします。親リクエストの場合、この操作は適格なすべての子リクエストにカスケードされます。

releaseRequest

同期

リクエストのHOLD状態を解除します。親リクエストの場合、この操作は適格なすべての子リクエストにカスケードされます。

setAsyncRequestStatus

同期

非同期Javaジョブのステータスを設定します。

setNLSOptions

同期

リクエストのNLS環境オプションを設定します。

setStepsArgs

同期

以前の同時処理スタイルでの引数を、ジョブ・セット・リクエスト内のステップ用のOracle Enterprise Schedulerプロパティにマーシャリングします。この操作は、リクエストの発行前に呼び出されます。

setSubmitArgs

同期

以前の同時処理スタイルでの引数をOracle Enterprise Schedulerプロパティにマーシャリングします。この操作は、リクエストの発行前に呼び出されます。各引数のキーはARGUMENT_PREFIX#であり、#は引数の元の値です。たとえば、ARGUMENT_PREFIX1="firstArg"およびARGUMENT_PREFIX2="secondArg"です。

submitRecurringRequest

同期

新しい再帰ジョブ・リクエスト(スケジュールが設定されたリクエスト)を発行します。

submitRequest

同期

新しいジョブ・リクエストを発行します。詳細は、「ユースケース: BPELプロセスでのOracle Enterprise Scheduler ESSWebserviceの使用」を参照してください

16.2 ESSWebserviceアプリケーションの開発および使用

Oracle Enterprise Schedulerは、ジョブ・リクエスト(Javaタイプのジョブ・リクエストなど)をそのジョブを発行したアプリケーションのコンテキストで実行します。

開発目的の場合は、通常、Oracle Enterprise Schedulerがターゲット・アプリケーションのコンテキストでジョブを実行できる任意のノード上にローカルに、Oracle Enterprise Schedulerとクライアント・アプリケーションを共存させます。目的が本番である場合は、一般的に、クライアント・アプリケーションとOracle Enterprise Schedulerは異なるサーバーに常駐します。

Oracle Enterprise Schedulerを使用するJava EEアプリケーションには、すべてのOracle Enterprise Schedulerアーティファクトが含まれており、この中には次のものがあります。

- ジョブ・タイプ、ジョブ定義、スケジュール、およびジョブ・セットなどのその他の必須メタデータを含むメタデータ

- ジョブ実装クラス(Javaジョブ用)

- 必要なOracle Enterprise Schedulerエンドポイント記述(ejb-jar.xmlでのMDB記述)

ESSWebserviceを使用してOracle Enterprise Schedulerと相互作用するクライアントでは、Oracle Enterprise Schedulerが適切なターゲット・アプリケーションのコンテキストでジョブを実行できるように、このタイプのJava EEアプリケーションを提供する必要があります。このようなすべてのWebサービス・クライアントでは、対応するJava EEホスティング・アプリケーションの名前を認識し、その名前をOracle Enterprise Schedulerに渡し、必要に応じて(WSDLで定義されます)その名前をOracle Enterprise Scheduler Webサービス・コールに渡す必要があります。

このようなアプリケーションは標準的なOracle Enterprise Schedulerクライアント・アプリケーションであり、このアプリケーションではジョブ・リクエストの発行および管理がESSWebservice操作を使用して実行されます。

16.2.1 ESSWebservice Java EEアプリケーションの開発および使用方法

ESSWebservice Webサービスを使用してOracle Enterprise Scheduler機能にアクセスする場合、対応するホスティングJava EEアプリケーションがOracle Enterprise Schedulerで使用できる必要があります。クライアントが、Oracle Enterprise Scheduler Webサービスを使用してOracle Enterprise Schedulerとリモートで相互作用できる場合も、関連付けられているJava EEホスティング・アプリケーションはOracle Enterprise Schedulerと同じ場所に配置されている必要があります。これにより、Oracle Enterprise Schedulerは正しいアプリケーション・コンテキストでジョブ・リクエストを実行できます。このため、ESSWebserviceクライアントでは、必要なすべてのOracle Enterprise Schedulerアーティファクトが含まれた、対応するJava EEホスティング・アプリケーションを依然として開発、パッケージ化およびデプロイする必要があります。

16.2.2 BPELによるESSWebservice SOAアプリケーションの開発および使用方法

SOAクライアントの場合、BPELプロセスなどのすべてのSOAコンポーネントは、SOAコンポジットとしてデプロイされます。SOAコンポジットはJava EEアプリケーションではありません。このコンポジットは、(SOAインフラ内の)SOAファブリック・ランタイム・フレームワークを使用して実行されます。

SOAコンポーネントの場合、コンポジットとOracle Enterprise Schedulerとの間のプロキシとして機能する個別のJava EEホスティング・アプリケーションを作成します。このホスティング・アプリケーションは、デプロイされたコンポジットごとに1つのOracle Enterprise Schedulerアプリケーションという1対1のアソシエーションで作成したり、複数のコンポジットによって単一のJava EEホスティング・アプリケーションが共有されるようにできます。Java EEホスティング・アプリケーションには、必要なすべてのOracle Enterprise Schedulerアーティファクトが含まれています。

16.2.3 getCompletionStatus()操作のWebサービスAddressingヘッダーの設定

ESSWebservice WSDLで示されているように、クライアントは、ジョブ完了に関して非同期に通知される必要がある場合、getCompletionStatus()操作を呼び出すことができます。ジョブ完了時に、Oracle Enterprise Schedulerは、ESSWebserviceが着信コール内のコール元アドレスを取得するws-addressingに続いてコールバック操作onJobCompletion()を呼び出します。クライアントは、このコールバックを今後いつでも受信できる必要があります。このようなコールバックは、ジョブの完了に必要な時間に完全に依存します。これは、ジョブ完了時に(Oracle Enterprise Scheduler EventListener規約を実装する)クライアントのリスナーを呼び出すためのOracle Enterprise Scheduler機能に似ています。

getCompletionStatus()を使用する場合、クライアントには、特定の必須WebサービスAddressingヘッダー(特に、wsa:MessageIDヘッダーとwsa:ReplyToヘッダー)が含まれている必要があります。これにより、Oracle Enterprise Schedulerランタイムは、ジョブ完了ステータスが適切なReplyToアドレスに送信されたことを非同期で通知できます。BPELプロセスでgetCompletionStatus()を使用すると、SOAランタイムは必須ヘッダーを自動的に追加します。クライアント側でWebサービス・プロキシを使用している場合にgetCompletionStatus()をプログラムで使用するには、これらのAddressingヘッダーをWebサービス・クライアントで設定する必要があります。

16.2.4 ESSWebserviceの使用上の制限

ESSWebserviceは、次のOracle Enterprise Scheduler機能をサポートしていません。

- 非定型リクエストの発行: ESSWebserviceでは、非定型のジョブ・リクエストの発行がサポートされていません(非定型リクエストの発行を使用するには、EJB APIを使用します)。このため、ESSWebserviceを使用して発行されるすべてのジョブに、対応する定義(関連プロキシ・アプリケーションでメタデータ・オブジェクトとして作成されたジョブ・タイプ、ジョブ定義、スケジュール定義など)が存在する必要があります。Webサービス操作は、そのようなメタデータ・オブジェクトを、WSDLで指定されたそれらのオブジェクトの識別子引数を使用して参照できるようになります。

- 問合せAPI: ESSWebserviceでは問合せAPIを公開しません。Webサービス・クライアントでは、Oracle Enterprise Schedulerリクエストに関する問合せ情報を取得する必要はありません。ESSWebservice Webサービス・クライアントは、問合せAPIを使用する必要がある汎用のモニタリングおよび管理機能は提供していません。

16.2.5 ESSWebserviceの実装

Oracle Enterprise Scheduler機能は、JAX-WS注釈付きサービス・エンドポイント・インタフェース(SEI)を使用するWebサービスとして公開されます。このSEI WebサービスのWebサービス実装によって、共通のOracle Enterprise Scheduler実装レイヤーが呼び出されます。ESSWebserviceは、最大限の互換性を得るためにドキュメント/リテラル/ラップ・モードで公開されます。

ESSWebserviceで使用される一部のデータ型は、Webサービスで直接使用することには適していません。このようなデータ型は、対応するXML表現に簡単に変換できません。このため、Oracle Enterprise Scheduler Webサービス・レイヤーでは、ESSWebserviceで公開され、WSDLで表示されるこれらのデータ型に適用するラッパー・クラスを定義します。一般的に、Webサービス・レイヤーでは、可能な場合には既存のデータ型を再利用します。

16.3 ESSWebservice WSDLファイル

Oracle Enterprise Schedulerがインストールされ、実行されている場合、Webサービス・ページからWSDL定義ファイルを取得できます。

Oracle Enterprise Schedulerがインストールされ、実行されている場合、次のタイプのURLにあるWebサービス・ページからWSDL定義ファイルを取得できます。

http://host:port/ess/esswebservice?WSDL

次に例を示します。

http://system1:7001/ess/esswebservice?WSDL

ブラウザからESSWebservice URLに直接アクセスすることによってWebサービス操作を起動することはできません。

16.4 ユースケース: BPELプロセスでのOracle Enterprise Scheduler ESSWebserviceの使用

この例では、BPELプロセスからESSWebServiceを使用する方法を示しています。BPELプロセスでは、ESSWebServiceを使用してジョブ・リクエストを発行します。

このユースケースでは、BPELおよびSOAユーザーがOracle Enterprise Schedulerを使用する場合の1つの方法を示しています。経験豊富なSOAユーザーおよび設計者は、Webサービスを使用するOracle Enterprise Schedulerで作業する方法として、他に案がある場合があります。

Oracle JDeveloperは、アプリケーションおよびそのアプリケーション内のプロジェクト(アプリケーション用のコードとサポート・ファイルが含まれている)の作成に使用されます。

JDeveloperには、スクリーン・リーダー、スクリーン拡大鏡、キーボード移動用の標準のショートカット・キーなどのアクセシビリティ・オプションが用意されています。さらに読みやすくするため、フォントのサイズや色、オブジェクトの色や形など、JDeveloperをカスタマイズすることもできます。JDeveloperでのアクセシビリティについて、およびこれを構成する手順は、『Oracle JDeveloperによるアプリケーションの開発』のOracle JDeveloperのアクセシビリティ情報に関する項を参照してください。

ESSWebServiceサンプル・アプリケーションを作成するには、次の手順に従います。

1. Oracle JDeveloperを起動します。

2. 「新規アプリケーション」ボタンをクリックします。

3. 「新規ギャラリ」 - 「アイテム」領域で、「SOAアプリケーション」を選択します。

4. 「OK」をクリックします。

5. 「アプリケーションの名前付け」ウィンドウを使用して、新しいアプリケーションの名前と場所を入力し、アプリケーション・テンプレートを指定します。

a. 「アプリケーション名」フィールドで、アプリケーション名を入力します。この例では、EssWebApplicationと入力します。

b. 「ディレクトリ」フィールドで、デフォルトをそのまま使用するか、作成するアプリケーションの場所を指定します。

c. アプリケーション・パッケージ接頭辞を入力するか、またはデフォルトである接頭辞なしを受け入れます。
接頭辞に続いてピリオドが、アプリケーションの初期プロジェクト内に作成されたオブジェクトに付加されます。

d. 「次へ」をクリックします。

6. 「プロジェクトの名前付け」ダイアログで、SOAプロジェクトのオプションを選択します。

a. 「プロジェクト名」フィールドで、プロジェクト名を入力するか、またはデフォルトのProject1を受け入れます。

b. 「プロジェクトの機能」タブで、「SOAスイート」を選択します。

c. 「次へ」をクリックします。

7. 「SOA設定の構成」ダイアログで、「BPELプロセスを使用するコンポジット」を選択し、「終了」をクリックします。

8. 図16-1に示すように、2つのBPEL仕様のうち1つを選択します。

図16-1 BPEL仕様の選択

9. 図16-2に示すようにサービス・タイプを「テンプレート」ドロップダウン・メニューから選択し、「OK」をクリックします。

図16-2 サービス・タイプの選択

10. 「エディタ」ペイン(BPELProcess1.bpel)で、「コンポーネント」パレットのOracle拡張機能セクションから「ジョブのスケジュール」コンポーネントをreceiveInputおよびcallBackClientコンポーネントの間にドラッグします(図16-3を参照)。

図16-3 スケジュール・ジョブ・コンポーネントの追加

11. メタデータ・サーバーへの接続を作成します(図16-4を参照)。

a. リソース・ウィンドウ内の「新規」ボタンをクリックします。

b. ドロップダウン・メニューで、IDE接続→SOA-MDSを選択します。「SOA-MDS接続の作成」ダイアログで、MDSサーバーに関する適切な情報を入力します。

注意:

また、「ファイル」→「新規ギャラリ」→「一般」→「接続」→SOA-MDS接続を選択して、接続を作成することもできます。

図16-4 メタデータ・サーバーへの接続の作成

12. Schedulejob1コンポーネントを右クリックして、「編集」項目を選択します。図16-5に示す「スケジュール・ジョブの編集」ダイアログが表示されます。

図16-5 スケジュール・ジョブの編集

13. 「ジョブ」参照ボタンをクリックし、MDS接続を介してジョブ定義を選択します。図16-6に例を示します。

図16-6 MDS接続を介したジョブ定義の選択

14. Sys_effectiveApplicationプロパティが、選択したジョブ定義で定義されていない場合、一般タブの「アプリケーション」フィールドでこれを指定することが要求されます。Sys_effectiveApplicationプロパティが、選択したジョブ定義で定義されている場合、「アプリケーション」フィールドに表示され編集できません。図16-7を参照してください。

図16-7 Sys_effectiveApplicationプロパティの定義(定義されていない場合)

15. システム・プロパティを追加します。

a. 「システム・プロパティ」タブを選択します。

b. 「ジョブ・プロパティ」ペインには、ジョブ定義からMDS接続を介して取得されたシステム・プロパティを移入する必要があります。

c. 「追加」ボタンを使用して、「ユーザー定義プロパティ」ペインで追加システム・プロパティを追加します。

図16-8 ユーザー定義プロパティの追加

16. アプリケーション・プロパティを追加します。

a. 「アプリケーションのプロパティ」タブを選択します。

b. 「ジョブ・プロパティ」ペインには、ジョブ定義からMDS接続を介して取得されたプロパティを移入する必要があります。

c. 「追加」ボタンを使用して、「ユーザー定義プロパティ」ペインで追加プロパティを追加します。

図16-9 追加のユーザー定義プロパティの追加

17. WSDL URLをアタッチします。

a. プロジェクト・エディタ・タブをクリックします(図16-10を参照)。

b. ESSServiceコンポーネントを編集します。「名前」、「WSDL URL」、「ポート・タイプ」およびその他の情報を指定します(図16-11)

図16-10 プロジェクト・エディタ・タブ

図16-11 参照の更新ダイアログ

18. セキュリティ・ポリシーをサービスに追加します。

a. プロジェクト・エディタ・タブで、Oracle Enterprise Scheduler Webサービスを右クリックし、「SOA WSポリシーの構成」→「リクエスト用」を選択し、「SOA WSポリシーの構成」ダイアログを開きます(図16-12を参照)。

図16-12 「SOA WSポリシーの構成」を開く

b. 「SOA WSポリシーの構成」の「セキュリティ」領域で、「追加」ボタンをクリックし必要なセキュリティ・ポリシーをアタッチします。たとえば、図16-13および図16-14に示すようにoracle/wss_http_token_client_policyとなります。非同期BPELプロセスを作成している場合、このプロセスを使用してサービス・ポリシーをコールバックにアタッチする必要もあります。

図16-13 「SOA WSポリシーの構成」ダイアログ

図16-14 セキュリティ・ポリシーの選択ダイアログ

19. getCompletionStatus操作のInvokeアクティビティを追加します。

a. 「設計」タブをクリックして、表示をソース・ビューからデザイン・ビューに切り替えます。

b. 「コンポーネント・パレット」のBPEL構成セクションから、InvokeコンポーネントをSchedulejob1とcallbackClientの間にドラッグ・アンド・ドロップします(図16-15を参照)。

図16-15 Schedulejob1とcallbackClientの間へのInvokeコンポーネントのドラッグ・アンド・ドロップ

c. Invoke1ボタンを右クリックして、「Invokeの編集」ダイアログを開きます。コンポーネントgetStatusAsyncの名前を変更します。

d. 「パートナ・リンク」領域で、矢印をgetStatusAsyncコンポーネントからEssServiceコンポーネントにドラッグします。図16-16に示すように、「Invokeの編集」ダイアログが開きます。

e. 「Invokeの編集」ダイアログの「操作」ドロップダウンからgetCompletionStatusを選択します(図16-16を参照)。

f. xという名前の入力変数を作成し、「OK」をクリックして「Invokeの編集」」ダイアログを閉じます。

図16-16 「Invokeの編集」ダイアログ

g. Assignコンポーネントを「コンポーネント・パレット」のBPEL構成領域から、ScheduleJob1コンポーネントとgetStatusAsyncコンポーネントの間にドラッグ・アンド・ドロップします。

h. Assignコンポーネントをダブルクリックし「Assignの編集」ダイアログを開き、ScheduleJob1出力パラメータのrequestIDをgetStatusAsync入力パラメータのrequestIDにマップします(図16-17を参照)。「OK」をクリックします。

図16-17 「Assignの編集」ダイアログを使用したScheduleJob1出力パラメータrequestIDのgetStatusAsync入力パラメータrequestIDへのマップ

20. ジョブ完了ステータスを受信します。

a. 「コンポーネント・パレット」のBPEL構成セクションから、ReceiveコンポーネントをgetStatusAsyncコンポーネントとcallbackClientコンポーネントの間にドラッグ・アンド・ドロップします(図16-18を参照)。

図16-15 getStatusAsyncコンポーネントとcallbackClientコンポーネントの間へのReceiveコンポーネントのドラッグ・アンド・ドロップ

b. Receive1コンポーネントからESSServiceコンポーネントに矢印をドラッグして、Receive1コンポーネントを「パートナ・リンク」領域内のESSServiceにアタッチします。このアクションにより、「Receiveの編集」ダイアログも開きます。Receive1コンポーネントの名前をOnJobCompletionに変更します(図16-19を参照)。

図16-19 Receive1コンポーネントのOnJobCompletionへの名前変更

c. OnJobCompletion操作を選択し、yという名前の変数を追加します(図16-19を参照)。「OK」をクリックし、「Receiveの編集」ダイアログを閉じます。

d. Assignコンポーネントを「コンポーネント・パレット」のBPEL構成領域から、onJobCompletionコンポーネントとcallbackClientコンポーネントの間にドラッグ・アンド・ドロップします。

e. AssignコンポーネントをダブルクリックしてAssignの編集ダイアログを開き、onJobCompletionコンポーネントの出力パラメータresultMessageを、callbackClientコンポーネントの入力パラメータresult変数にマップします(図16-20を参照)。「OK」をクリックします。

図16-20 onJobCompletionコンポーネントの出力パラメータresultMessageのcallbackClientコンポーネントの入力パラメータresult変数へのマップ

17 ジョブ・セットの定義および使用

この章では、Oracle Enterprise Schedulerのジョブ・セット(1つの単位として実行するためにグループ化できるジョブ定義の集合)を定義および発行する方法について説明します。

この章の内容は次のとおりです。

- ジョブ・セットの定義および使用の概要

- ジョブ・セットの定義

- アプリケーション間ジョブ・セット

- ジョブ・セットでの入力および出力転送のサポート

17.1 ジョブ・セットの定義および使用の概要

Oracle Enterprise Schedulerは、ジョブ・セットと呼ばれる、1つの単位として実行するためにグループ化できるジョブ定義の集合に対応しています。ジョブ・セットはネストできるため、ジョブ・セットにはジョブ定義の集合または1つ以上の子ジョブ・セットを含めることができます。ジョブ・セット内に含まれる各ジョブ定義やジョブ・セットは、ジョブ・セット・ステップと呼ばれます。

ジョブ・セットは、シリアル・ジョブ・セットまたはパラレル・ジョブ・セットとして定義されます。実行時、Oracle Enterprise Schedulerではパラレル・ジョブ・セット・ステップを並行して実行します。シリアル・ジョブ・セットが実行されるとき、Oracle Enterprise Schedulerでは、ステップを特定の順序で1つずつ実行します。Oracle Enterprise Schedulerでは、シリアル・ジョブ・セットを使用することによって、前のステップの実行ステータスに基づく、ステップ間の条件付き分岐がサポートされています。

シリアル・ジョブ・セットを定義してパラレル・ジョブ・セットを含めたり、パラレル・ジョブ・セットを定義してシリアル・ジョブ・セットを含めたりできます。パラレルおよびシリアル・ジョブ・セットが混在するジョブ・セットは、complex job setと呼ばれます。たとえば、シリアル・ジョブ・セットに子パラレル・ジョブ・セットが含まれる場合、シリアル・ジョブ・セットは子パラレル・ジョブ・セットに到達するまで、逐次実行されます。その後、子パラレル・ジョブ・セット内のすべてのジョブ定義またはジョブ・セット定義が並行して実行されます。子パラレル・ジョブ・セットが完了すると、続いて、シリアル・ジョブ・セットの残りのステップが逐次実行されます。ネストされたパラレル・ジョブ・セットは、ネストされていないパラレル・ジョブ・セットと同じように動作します。

ジョブ・セットのすべてのステップに対して、Oracle Enterprise Schedulerでは、特定のステップがジョブ・セット全体にどのように影響を及ぼすかについて、実行時の柔軟性をもたらすプロパティ(SYS_selectState)がサポートされています。このプロパティはステップごとに定義します。表17-1に、SYS_selectStateを示します。

表17-1 ジョブ・セット・ステップのプロパティ

プロパティ

説明

SYS_selectState

ジョブ・セットの状態を決定するときに、ジョブ・セット・ステップの結果の状態を含めるかどうかを指定します。ステップの実行状態がジョブ・セット全体の最終的な状態に影響するかどうかを指定します。

デフォルトでは、すべてのジョブ・セット・ステップがジョブ・セットの状態に影響を及ぼします。特定のジョブ・セット・ステップの状態がジョブ・セットの状態に影響しないようにするには、そのステップに対してSELECT_STATEをfalseに設定します。ジョブ・セット・ステップの状態がジョブ・セット全体の状態に影響することを許可するには、そのステップに対してSELECT_STATEをtrueに設定します。

Oracle Enterprise Schedulerには、複数のアプリケーションをまたいで1つのジョブ・セットを実行する機能が備えられています。ジョブ・セットはホスティング・アプリケーションで実行され、デフォルトで、すべてのジョブ・セット・ステップもそのアプリケーションで実行されます。

17.2 ジョブ・セットの定義

ジョブ・セットの内容は、ジョブ・セット・ステップを定義するときに指定します。たとえば、シリアル・ジョブ・セットの場合は、名前と実行モードを指定し、次に、ジョブ定義の順序を定義するジョブ・セット・ステップか、またはジョブ・セットの実行時に実行される子ジョブ・セットを追加します。

次を指定して、Oracle JDeveloperでジョブ・セットを定義できます。

- ジョブ・セットの名前、パッケージおよび説明

- ジョブ・セットのアプリケーション定義プロパティ

- ジョブ・セットのシステム・プロパティ

- ジョブ・セット・ステップの指定

17.2.1 ジョブ・セットの定義方法

Oracle Enterprise Schedulerのジョブ・セットは、名前、パッケージ、ジョブ・セット実行モード、ステップ定義、アプリケーション定義プロパティおよびシステム・プロパティによって定義されます。

ジョブ・セットを作成する手順は、次のとおりです。

1. Oracle JDeveloperで、プロジェクト内で右クリックして「新規ギャラリ」を表示します。

2. 「すべてのテクノロジ」タブの「カテゴリ」で、「ビジネス層」を展開し、「エンタープライズ・スケジューラ・メタデータ」を選択します。

3. 「アイテム」で、「ジョブ・セット」を選択し、「OK」をクリックします。これにより、「ジョブ・セットの作成」ウィンドウが表示されます。

4. 「ジョブ・セットの作成」ウィンドウで、次を指定します。

a. 「名前」フィールドにジョブ・セットの名前を入力するか、またはデフォルト名を受け入れます。

b. 「パッケージ」フィールドに、ジョブ・セットのパッケージ名を入力します。

c. 「場所」フィールドに、ジョブ・セット・ファイルが格納されているディレクトリの完全パスが表示されます。

d. 「OK」をクリックします。これにより、ジョブ・セットが作成され、図17-1に示すように、ジョブ・セット定義のページが表示されます。

図17-1 シリアル・ジョブ・セットが示されたジョブ・セット・エディタ

5. ジョブ・セット・エディタ・ペインで、「説明」フィールドにジョブ・セットの説明を入力します。

6. 「ジョブ・セット・ステップ」領域で、「パラレル」または「シリアル」ラジオ・ボタンを選択してジョブ・セットに対してパラレルまたはシリアル実行モードを指定します。

7. ジョブ・セット・エディタ・ペインでジョブ・セット・ステップを追加します。ジョブ・セット・ステップの追加の詳細は、「シリアル・ジョブ・セット・ステップの定義方法」または「パラレル・ジョブ・セット・ステップの定義方法」を参照してください。

8. 「アプリケーション定義プロパティ」領域で、「追加」をクリックしてジョブ・セットに関連付けられているプロパティを追加します。これらを使用して、ジョブ・セットのアプリケーション固有またはステップ固有のアプリケーション定義プロパティを表します。アプリケーション定義プロパティの使用の詳細は、「パラメータとシステム・プロパティの使用の概要」を参照してください。詳細は、「ジョブ・セット・レベル・パラメータのマテリアライズに関する必知事項」を参照してください。

9. 「システム・プロパティ」領域で、「追加」をクリックしてジョブ・セットに関連付けられているシステム・プロパティを追加します。システム・プロパティの使用の詳細は、「システム・プロパティの使用」を参照してください。

10. 「アクセス制御」領域で、「追加」をクリックしてこのメタデータにアクセスできるロールのリストを、そのアクセス・レベルとともに変更します。アクセスの定義の詳細は、「Oracle Enterprise Schedulerセキュリティ」を参照してください。

11. 「ローカライゼーション」領域で、このジョブ・セットをローカライズするための次の情報を入力します。

- リソース・バンドルの基準名 -- 国際化された値を指定するリソース・バンドルの基準名

- 表示名リソース・キー -- リソース・バンドルで表示名値を指定するリソース・キー

- 説明リソース・キー -- リソース・バンドルで説明テキストを指定するリソース・キー

12. ジョブ・セットを保存します。

17.2.2 シリアル・ジョブ・セット・ステップの定義方法

シリアル・ジョブ・セット・ステップを定義するには、シリアル実行モードを選択し、次に、ジョブ・セット・ステップを追加します。ジョブ・セット・ステップは、使用可能なジョブ定義および現在のプロジェクトで定義されたジョブ・セットから作成されます。シリアル・ジョブ・セット・ステップは、ステップIDおよびそのステップに関連付けられるジョブ定義の子ジョブ・セット定義を指定する場合に定義します。次のステップを指定するために、ジョブ・セット・ステップの終了状態からのリンクも定義します。表17-2に、JDeveloperを使用して指定できる可能な終了状態を示します。

表17-2 ジョブ・セットのシリアル実行ステップの終了状態

終了状態

説明

SUCCEEDED

Oracle JDeveloperでは、この状態はチェックマーク・アイコンで示されます。このパスは、子ステップまたは子ジョブ・セットが正常に処理されたことを表します。

WARNING

Oracle JDeveloperでは、このステップは警告ボタンで示されます。子ステップまたは子ジョブ・セットによって警告が発生しました。

ERROR

Oracle JDeveloperでは、このステップはエラー・ボタンで示されます。子ステップまたは子ジョブ・セットの処理を実行するリクエストの一部の処理によって、エラーが発生しました。

シリアル・ジョブ・セット・ステップを追加する手順は、次のとおりです。

1. 最初に、適切なジョブ定義またはジョブ・セットを定義し、ステップを含める親ジョブ・セットを定義します。

2. ジョブ・セット・エディタ・ペインの「ジョブ・セット・ステップ」領域で、「シリアル」実行モードを選択します。

3. 「追加」ボタンをクリックして、ジョブ・セットのステップを追加します。これにより、「ステップの追加」ウィンドウが表示されます。

4. 「ステップID」フィールドに、ステップIDを入力します。たとえば、step1と入力します。

5. 「ジョブ」フィールドで、ステップに関連付けるジョブ定義またはジョブ・セットをドロップダウン・リストから選択します。たとえば、Job1を選択します。

6. ステップ・レベルのアプリケーション定義プロパティを定義する必要がある場合は、「アプリケーション定義プロパティ」タブを選択してステップのプロパティを追加します。

7. ステップ・レベルのシステム・プロパティを定義する必要がある場合は、「システム・プロパティ」タブを選択してステップのジョブ・セット・ステップ・システム・プロパティを追加します。

8. ステップの宛先を選択します。「メイン・ダイアグラムへの挿入」を選択して、ステップをジョブ・セットの一部として追加できます。ステップを(エラーまたは警告状態の)別のステップで使用できるようにするには、「使用可能なステップのリストへの追加」を選択します。

9. 「OK」をクリックします。これにより、図17-2に示すように、ジョブ・セット・ステップが追加されます。

図17-2 ステップが追加されたジョブ・セット

10. エラー・アイコンの横のドロップダウン・リストから「停止」を選択するか、またはステップに対してERROR終了状態のステップを選択します。たとえば、ドロップダウン・リストからStep_errorを選択します(Step_errorを定義する必要があります)。

11. 警告アイコンの横のドロップダウン・リストから「停止」を選択するか、またはステップに対してWARNING終了状態のステップを選択します。たとえば、ドロップダウン・リストからStep_warningを選択します(Step_warningを定義する必要があります)。

12. 必要に応じて、「追加」ボタンをクリックして追加のステップを追加します。

13. 図17-3に示すように、「OK」をクリックします。

図17-3 2つのステップが追加されたジョブ・セット

17.2.3 パラレル・ジョブ・セット・ステップの定義方法

ジョブ・セットにパラレル・ジョブ・セット・ステップを追加できます。

パラレル・ジョブ・セット・ステップを追加する手順は、次のとおりです。

1. 最初に、適切なジョブ定義とジョブ・セット定義および親ジョブ・セットを定義します。

2. ジョブ・セット・エディタで、「パラレル」実行モードを選択します。

3. 「追加」ボタンをクリックして、ジョブ・セットにジョブ・セット・ステップを追加します。

「ステップの追加」ウィンドウが表示されます。

4. 「ジョブ」フィールドで、ジョブ定義またはジョブ・セットを選択します。

5. ステップ・レベルのアプリケーション定義プロパティを定義する必要がある場合は、「アプリケーション定義プロパティ」タブを選択してステップのプロパティを追加します。

6. ステップ・レベルのシステム・プロパティを定義する必要がある場合は、「システム・プロパティ」タブを選択してステップのジョブ・セット・ステップ・システム・プロパティを追加します。

7. 「OK」をクリックすると、ジョブ・セット・ステップが追加されます。

8. 「追加」ボタンをクリックします。

9. 「ステップの追加」ダイアログで、パラレル・ジョブ・セットの次のジョブに使用するジョブ・セットまたはジョブ定義を選択します。

10. 「OK」をクリックします。図17-4に示すように、ジョブ・セットにジョブ・セット・ステップが表示されます。

図17-4 パラレル・ジョブ・セットへのジョブ・セット・ステップの追加

17.2.4 ジョブ・セットの定義時の処理内容

Oracle JDeveloperでジョブ・セットを定義すると、Oracle JDeveloperによって、定義したステップを表す要素を含むXMLファイルが作成されます。

パラレル・ジョブ・セットを定義する場合は、同時に実行される一連のジョブ・セット・ステップを指定します。パラレル・ジョブ・セットにはステップのみが含まれ、すべてのステップが同時に実行されて、相互に依存することも各ステップの実行順序に依存することもないため、ステップ間のリンクは含まれません。

ジョブ・セットを定義すると、Oracle JDeveloperによって、Oracle Enterprise Schedulerのジョブ・ステップ・スキーマに準拠するXMLドキュメントが作成されます。

17.2.5 シリアル・ジョブ・セットに関する必知事項

シリアル・ジョブ・セットを定義する場合、関連付けられたXMLドキュメントにはジョブ・セット・ステップとリンクが含まれます。Oracle Enterprise Schedulerでは、シリアル・ジョブ・セットの定義に対して次の制限事項が適用されます。

- ジョブ・セット内でのループを回避するため、ジョブ・セット定義に循環実行パスを含めることはできません。循環実行パス、すなわちループは、次のようにジョブ・セット・レベルで定義されます。ループは、1つのジョブ・セット・ステップから、任意の数の他のステップを経由するリンクに従って、同じジョブ・セット・ステップに戻るパスです。たとえば、Job_AからJob_B、Job_Cへのフローが定義されたジョブ・セットにおいて、Job_BまたはJob_CからJob_Aに戻る実行パスを定義することはOracle Enterprise Schedulerによって許可されません。たとえば、成功、エラーまたは警告リンクのジョブ・セット・ステップ内のリンクの1つが同じジョブ・セット・ステップに戻る場合、循環実行パス、すなわちループを作成できます。このため、各ジョブ・セット・ステップはいずれかの使用可能なジョブ定義またはジョブ・セットにリンクするか、あるいはすべてのジョブ・セット・ステップで同じジョブ定義またはジョブ・セットを成功、エラーおよび警告の場合のリンクとして使用できます。ループとしては、ジョブ・セット・ステップIDによって識別されるジョブ・セット・ステップを経由するパスに基づくもののみが可能です。Oracle Enterprise Schedulerでは、ジョブ・セット・ステップ・レベルでのループを回避するために送信時にジョブ・セットが検証されます。また、Oracle JDeveloperではジョブ・セット・ステップ・レベルのループを含むジョブ・セットを作成することはできません。

- ジョブ・セット内でのループを回避するため、ジョブ・セット定義に自己参照実行パスを含めることはできません。たとえば、Job_Bが定義されたジョブ・セットにおいて、Job_BがERRORの終了状態で終了した場合のためにJob_BからJob_B自体への実行パスを定義することは、Oracle Enterprise Schedulerによって許可されません。ただし、ジョブ定義またはジョブ・セットに使用可能なRETRIESプロパティを使用して、構成されたRETRIESの数だけ複数実行を行うことができます。

- ステップの終了状態に対してジョブ・セット・リンクが定義されていない場合、ステップが指定されていない終了状態で終了するとジョブ・セットが停止することを意味します。たとえば、状態WARNINGのステップJob_Dに対してリンクが定義されておらず、ステップJob_DがWARNINGの状態で終了した場合、ジョブ・セットの実行は停止します。

各ジョブ・セット・ステップは、いずれかの使用可能なジョブ定義またはジョブ・セットを使用するように定義することも、複数のステップで同じジョブ定義またはジョブ・セットを使用するように定義することもできます。

17.2.6 ジョブ・セットのアプリケーション定義プロパティおよびシステム・プロパティに関する必知事項

ジョブ・セットのアプリケーション定義プロパティまたはシステム・プロパティが、メタデータで設定された、またはジョブ・リクエストを発行するときに設定されたアプリケーション定義プロパティまたはシステム・プロパティと競合する場合があります。ジョブ・セットのアプリケーション定義プロパティおよびシステム・プロパティが処理される方法の詳細は、「メタデータ・サービスでのパラメータの使用」および「ランタイム・サービスでのパラメータの使用」を参照してください。

17.2.7 ジョブ・セットの状態の優先度および状態遷移に関して実行時に行われる処理

実行時、ジョブ・セットの個々のステップは、表17-2に示す様々な終了状態で終了する可能性があります。ジョブ・セット・ステップがジョブ・セットである場合、ジョブ・セット・ステップもそれらのいずれかの終了状態で終了します。Oracle Enterprise Schedulerには、ジョブ・セット・ステップの終了状態について優先度の階層があります。これは、ジョブ・セットに複数のステップがある場合に、ジョブ・セットの終了状態には最も優先度の高い終了状態のステップの終了状態が適用されることを意味します。したがって、ステップの最も優先度の高い終了状態によって、ジョブ・セット全体の結果の状態が決定されます。

ジョブ・セットの結果の状態は、システム内の後続のすべての状態依存処理に影響を及ぼします。ジョブ・セットは、すべての子リクエストが完了した後にのみ、子リクエストの終了状態に基づいて終了状態への遷移の基本的なルールに常に従います。通常、ジョブ・セットは、すべての子リクエストが終了し、終了状態に遷移した後にのみ、計算されたいずれかの終了状態に遷移します。たとえば、特定のジョブ・セットが実際は別のジョブ・セット内のステップである場合、内部ジョブ・セット・リクエストの状態が計算される方法は、外部ジョブ・セット内での条件付き実行に影響を与えます。

表17-3に、可能なジョブ・セットの終了状態および示されるレベル(優先度の列)を示します。

表17-3 ジョブ・セットの終了状態の遷移

終了状態

説明

優先度

ERROR

ジョブ・セットのいずれかのステップがERRORの終了状態で終了した場合、他のステップがどのような状態であっても、ジョブ・セット全体にERRORの終了状態のマークが付けられます。

シリアル・ジョブ・セットでは、1つのステップがERRORになると、後続のステップは実行されません。パラレル・ジョブ・セットでは、すべてのステップが同時に開始され、ジョブ・セットの状態はジョブ・セット・ステップが終了状態に到達するまで決定されません。

ERROR状態は優先度が最も高くなります。

WARNING

ジョブ・セットのいずれかのステップがWARNINGの終了状態で終了し、終了状態がERRORのステップがない場合、ジョブ・セットはWARNINGの終了状態のマークが付けられます。終了状態がWARNINGの場合、後続処理が開始されます。

ERRORより低い

EXPIRED

少なくとも子リクエストの1つが期限切れになり、ERRORまたはWARNINGの終了状態で終了したステップがない場合、ジョブ・セットはEXPIRED状態に遷移します。

ERRORおよびWARNINGより低くなります。

CANCELLED

少なくとも1つの子リクエストで取消しの試行が正常に処理され、CANCELLED状態に遷移した場合、取消しの試行の実際の結果に基づいて、ジョブ・セットがCANCELLEDに遷移することがあります。取消しは、ジョブ・セット全体に対してリクエストされる場合と、特定の子リクエストに対してのみリクエストされる場合があります。

さらに、CANCELLEDへの遷移は終了状態の優先度に従います。したがって、ERROR、WARNINGまたはEXPIREDの状態で終了したステップがなく、終了状態がCANCELLEDのステップが少なくとも1つある場合、ジョブ・セットはCANCELLEDの終了状態に遷移します。

ジョブ・セットが取り消された場合、追加または実行されていないステップは、最終状態のためにCANCELLEDとみなされます。

ERROR、WARNINGおよびEXPIREDより低くなります。

SUCCEEDED

すべての子リクエストがSUCCEEDEDの終了状態で終了した場合にのみ、ジョブ・セットはSUCCEEDEDであるとみなされます。

SUCCEEDED状態は、すべての終了状態の中で優先度が最も低くなります。

表17-4に、追加の可能なジョブ・セットの状態を示します。

表17-4 可能なジョブ・セットの実行時の状態

状態

説明

WAIT

これは発行されたジョブ・セット・リクエストの初期状態です。ただし、ジョブ・セット・リクエストがRUNNING状態に遷移した後、生成されたすべての子リクエストはWAIT状態ではなく、直接READY状態に遷移します。

READY

ジョブ・セットは、WAIT、READY、RUNNINGの順に遷移します。これは、すべてのジョブ・セット・ステップに当てはまり、ステップがジョブ定義でもネストされたジョブ・セットでも同様です。

RUNNING

発行されたジョブ・セットは、WAIT、READY、RUNNING状態の順に遷移します。ネストされたジョブ・セットは、READYで始まりRUNNINGに遷移します。

CANCELLING

ユーザーがジョブ・セット全体の取消しをリクエストした場合、ジョブ・セットはCANCELLINGに遷移します。これは、ジョブ・セットを表す親リクエストのリクエストIDを使用してcancelRequest()をコールすることによって実行できます。親リクエストIDを渡すことは、ジョブ・セットの現在の(非終了)状態および子リクエストの状態に関係なく、ユーザーがジョブ・セット全体を取り消すことを示します。

このような場合、現在もアクティブでまだ終了状態に遷移していないすべての子リクエストに対して取消しが試行されます。

一方、取消しがジョブ・セットの特定の子リクエストに対して試行された場合、親リクエストの状態は変更されず、可能であれば特定の子リクエストのみがCANCELLINGに遷移します。

後処理中に取消しが発生した場合、状態はCANCELLEDではなくWARNINGに設定されます。取消しが発行される前にジョブ・セットが終了した場合、ジョブ・セットはSUCCEEDEDの状態になります。

COMPLETED

この状態は、ジョブ・セットまたはジョブ・セット・ステップの実行が終了し、後処理が開始されることを示します。

BLOCKED

BLOCKED状態は終了状態ではありません。ただし、ブロック状態が解消されるまで(非互換性など)、いずれのリクエストも長時間BLOCKED状態のままであることが可能です。

ジョブ・セットの場合、他のステップが完了するか、実行中の間、個々のステップはBLOCKEDになることがあります。ただし、ジョブ・セット自体はRUNNING状態のままとなります。その後、BLOCKED状態のステップを除く、ジョブ・セットのすべてのステップが完了した場合、ブロックされているステップを実行する準備が整うまで、ジョブ・セットでは以降の処理を続行できません。ブロックされているステップのブロックが解除されて完了すると、ジョブ・セットは先に進むことができます。ステップが完了した後、ジョブ・セットは最終的に適切な終了状態になります。

シリアル・ジョブ・セットの場合、ジョブ・セットはBLOCKED状態のステップで停止する可能性があります。そのような場合、それ以前のすべてのステップは完了し、ブロックされているステップが実行されるまでジョブ・セットは続行できません。

ただし、パラレル・ジョブ・セットでは、複数のステップがBLOCKED状態のままとなることがあります。さらに、一部のステップがブロックされている間も、他のステップは引き続き実行できます。

HOLD

HOLD状態はBLOCKED状態とよく似ています。BLOCKED状態と同じルールに従い、ステップがHOLD状態にある間ジョブ・セットでは実行を続行できません。実行フローの現在のステップがHOLD状態でスタックした場合、シリアル・ジョブ・セットは続行できません。パラレル・ジョブ・セットの場合は、他のすべてのステップは完了したが少なくとも1つのステップがHOLD状態でスタックした場合、ジョブ・セットはステップがHOLD状態でなくなったときに完了できます。

17.3 アプリケーション間ジョブ・セット

Oracle Enterprise Schedulerには、複数のアプリケーションをまたいで1つのジョブまたはジョブ・セットを実行する機能が備えられています。

- ジョブ・セットFINには3つのステップがあり、そのうちの2つは異なるアプリケーションで実行されるように定義されています。

- ジョブ・セットFINはGLアプリケーションに対して発行されます。

- ステップ1はEFFECTIVE_APPLICATIONシステム・プロパティがODIに設定されているため、ODIアプリケーションで実行されます。

- ステップ2には有効なアプリケーションが設定されていないため、GLアプリケーションで実行されます。

- ステップ3はEFFECTIVE_APPLICATIONシステム・プロパティがINVに設定されているため、INVアプリケーションで実行されます。

図17-5 アプリケーション間ジョブ・セット・ステップ

17.3.1 アプリケーション間ジョブ・セットの概要

ジョブ・セットはホスティング・アプリケーションで実行され、デフォルトで、すべてのジョブ・セット・ステップもそのアプリケーションで実行されます。システム・プロパティSYS_effectiveApplicationは、ジョブ定義または(ジョブ・セット・ステップではなく)ジョブ・セットで定義する必要があります。SYS_effectiveApplicationを定義するネストされたジョブ・セットの場合、アプリケーションはネストされたジョブ・セットのすべての子リクエストに適用されます。ネストされたジョブ・セットである場合、ネストされたジョブ・セットのジョブは有効なアプリケーションで実行されます。ジョブに対してSYS_effectiveApplicationが定義されている場合、ジョブ・セットのリクエストおよびそのジョブ・セットのすべての子リクエストは有効なアプリケーションに関連付けられます。つまり、これらのリクエストのAPPLICATIONシステム・プロパティは有効なアプリケーションに設定されます。

SYS_effectiveApplicationシステム・プロパティは、メタデータ、具体的には、ジョブ・セット、ジョブ・セット・ステップ、ジョブ・タイプおよびジョブでのみ定義できます。プロパティSYS_effectiveApplicationは、リクエスト・パラメータではサポートされていません。有効なアプリケーションは、ホスティング・アプリケーションと同じクラスタ内にある必要があり、そうでない場合、エラーが発生します。発行されたジョブ・セットによって有効なアプリケーションが定義されている場合、その値はホスティング・アプリケーションと同じである必要があり、そうでない場合、ジョブ・セットの発行は拒否されます。

複数のアプリケーションをまたいで実行されるジョブ・セットの場合、アプリケーションによるリクエストの問合せは、すべての子を取得するには不十分です。Oracle Enterprise Schedulerでは、問合せフィールドとして絶対親IDがサポートされているため、アプリケーションに関係なく、ジョブ・セットのすべてのリクエストを問い合せることができます。絶対親IDは、ホスティング・アプリケーションに対して発行されたジョブ・セットのリクエストIDです。

17.3.2 アプリケーション間ジョブ・セットの要件

Oracle Enterprise Schedulerでは、次の要件が適用されるアプリケーション間ジョブ・セットがサポートされています。

1. 指定したジョブ・セットのすべてのアプリケーションは同じクラスタにデプロイされる必要があります。

2. ジョブ・セット内のすべてのアプリケーションは同じエンタープライズ・セキュリティを共有する必要があります。

3. すべてのリクエスト・メタデータは、ジョブ・セットの発行先のアプリケーション(ホスティング・アプリケーション)からアクセスできる必要があります。リクエストのすべてのメタデータは、ホスティング・アプリケーションのランタイム・ストアに維持される必要があります。維持されるメタデータには、発行されたジョブ・セットおよびすべてのネストされたジョブ・セットで使用されるメタデータがすべて含まれます。

4. サブリクエストで使用されるメタデータがジョブ・セットの発行時にランタイム・ストアにすでに維持されていないかぎり、サブリクエストのメタデータはサブリクエストを発行するアプリケーションからアクセスできる必要があります。

17.4 ジョブ・セットでの入力および出力転送のサポート

ジョブ・セットのステップでは、ジョブ・セットの前のステップからの入力が必要になる場合があります。Oracle Enterprise Schedulerでは、1つのステップから次のステップの入力へ出力を簡単に転送するために、2つのシステム・プロパティSYS_inputListおよびSYS_outputListが使用されます。

ジョブ・セットの次のステップに渡す必要がある情報(出力ファイルのリストなど)がジョブで生成されると、ジョブではSYS_outputListプロパティに情報が追加されます。ジョブ・リクエストの実行が完了すると、Oracle Enterprise Schedulerでは、次のステップが実行される前に、リクエストのSYS_outputListプロパティを転送し、これが次のステップのSYS_inputListプロパティになるようにします。次のステップはその入力として前のステップの出力を受け取ります。

ジョブ・セット・ステップは単一ジョブである場合とジョブ・セットである場合があり、Oracle Enterprise Schedulerでは、ネストされたジョブ・セットによる転送もサポートされています。シリアル・ジョブ・セットの場合、Oracle Enterprise Schedulerではジョブ・セットの出力がジョブ・セットの最後のステップの出力として定義されます。つまり、最後のステップのSYS_outputListプロパティのみが次のステップに転送されます。同様に、シリアル・ジョブ・セットへの入力は、そのジョブ・セットの最初のステップにのみ転送されます。つまり、シリアル・ジョブ・セットの最初のステップのみで、SYS_inputListプロパティが前のステップのSYS_outputListプロパティの値に設定されます。

パラレル・ジョブ・セットの場合、Oracle Enterprise Schedulerでは、ジョブ・セットの出力はジョブ・セットのすべてのジョブのSYS_outputListプロパティの連結(デリミタで区切られ、順序の保証なし)であることが指定されます。パラレル・ジョブ・セットへの入力はジョブ・セットのすべてのジョブに転送されます。つまり、パラレル・ジョブ・セットのすべてのジョブで、INPUT_LISTプロパティが同じになります。システム・プロパティOUTPUT_LIST_DELIMITERでは、出力ファイルを一覧表示するときに使用するデリミタが指定されます。

ジョブ・セットに2つのジョブがあり、各ジョブで独自の出力ファイルfile1.txtおよびfile2.txtが生成されるとします。OUTPUT_LIST_DELIMITERの値がセミコロンである場合、そのジョブ・セットのシステム・プロパティSYS_outputListの値はfile1.txt;file2.txtになります。出力ファイルの連結されたリストを使用して、ジョブ・セットの次のジョブ・ステップでは、ジョブ・セット内の前のステップによって生成された出力ファイルにアクセスできます。

InputFileクラスはジョブ定義の入力としてファイルへのアクセスを提供します。現在、ファイルをジョブ・リクエストへの入力として受け入れるためのメカニズムはありません。

ステップのSYS_outputListプロパティの値を次のステップのSYS_inputListプロパティの値へ転送する場合を除き、Oracle Enterprise Schedulerでは2つのプロパティは他のシステム・プロパティと同様に処理されます。Oracle Enterprise Schedulerではプロパティの値の形式は定義されません(パラレル・ジョブ・セットの場合のセミコロンのデリミタを除く)。プロパティの構文およびセマンティクスの定義は、たとえば、完全修飾名または相対パス名、およびデリミタとしてのカンマまたはスペースを使用して、ジョブで行われます。

18 ジョブ非互換性の定義および使用

この章では、Oracle Enterprise Schedulerのジョブ非互換性の使用方法について説明します。この機能を使用して、同時に実行できないジョブ・リクエストを指定できます。

この章の内容は次のとおりです。

- ジョブ非互換性の使用の概要

- Oracle JDeveloperとの非互換性の定義

- ジョブ非互換性を処理するために実行時に行われる処理

ジョブ・リクエストの作成および発行方法の詳細は、「PL/SQLジョブの作成と使用」および「プロセス・ジョブの作成と使用」を参照してください。ジョブ・セットの使用の詳細は、「ジョブ・セットの定義および使用」を参照してください。

注意:

説明を単純化するために、この非互換性の章ではジョブ定義についてのみ言及しますが、ここでの説明は、すべての場合において、ジョブ定義とジョブ・セットの両方に当てはまります。

18.1 ジョブ非互換性の使用の概要

それぞれの非互換性については、グローバルな非互換性とドメイン(プロパティベース)の非互換性のいずれかが指定されます。Oracle Enterprise Schedulerでは、oracle.as.scheduler.Incompatibility Javaクラスによって表される非互換性定義に基づき、ジョブ定義またはジョブ・セットの間の非互換性がサポートされています。IncompatibilityType列挙によって、有効な非互換性タイプが指定されます。

- ドメイン固有(DOMAIN): この場合、1つ以上のジョブ定義がリソースのスコープ内で非互換としてマークされ、リソースはシステム・プロパティ名またはユーザー定義パラメータ名によって識別されます。非互換性を定義するために使用するジョブ定義ごとに、プロパティ名を指定する必要があります。互換性のないジョブに対するリクエストのリソースの値が同じ場合、Oracle Enterprise Schedulerにより、これらが同時に実行されないようにできます。parameterVOを介して指定されたパラメータは、プロパティ名submit.argument1、... submit.argument#を持つリクエスト・プロパティとして発行されます。ドメイン非互換性プロパティとしてこのようなパラメータを使用するには、非互換性プロパティ名にsubmit.argument1、... submit.argument#を指定します。

- グローバル(GLOBAL): この場合、1つ以上のジョブ定義が、リソースやプロパティに関係なく非互換としてマークされます。Oracle Enterprise Schedulerにより、互換性のないジョブに対するリクエストが同時に実行されないようにできます。

Oracle Enterprise Schedulerの非互換性定義により、グローバルな非互換性とドメイン(プロパティベース)の非互換性のいずれかが指定されます。非互換性は1つ以上のエンティティ(ジョブ定義またはジョブ・セット)、およびこれらのエンティティが非互換となる必要があるリソースで構成されています。グローバルの非互換性にリソースは指定しません。各エンティティには、自己非互換としてフラグを付けることができます。非互換性が1つのエンティティにのみ定義されている場合、そのエンティティに自己非互換としてフラグを付ける必要があります。Oracle Enterprise Schedulerでは、1つのエンティティがドメイン(プロパティベース)のエンティティを表し、別のエンティティがグローバルな(プロパティのない)エンティティを表す混合モードはサポートされていません。

ドメインの非互換性の場合、リソースは非互換性のエンティティごとに異なる場合があるプロパティ名によって表されます。たとえば、ドメインの非互換性が2つのジョブ定義(JobAとJobB)に対して作成される場合、各エンティティに対して識別されるリソース(プロパティ)のプロパティ名は、JobAとJobBで異なることがあります。これはJobAでfooと呼ばれ、JobBでfoo2と呼ばれる可能性があります。Oracle Enterprise Schedulerでは、JobAに対するリクエストとJobBに対するリクエストのそれぞれのプロパティ値が同じである場合、これらのリクエストは互換性がないとみなされ、同時に実行されることはありません。リクエストのそれぞれのプロパティ値が異なる場合、これらのリクエストは互換性があるとみなされ、同時に実行できます。

非互換性定義により、別のジョブ定義と互換性のないジョブ定義が指定されます。指定されたジョブ定義により、任意の非互換性定義を直接指したり参照することはありません。

Oracle Enterprise Schedulerにより、リクエストが最初に実行されるときにリクエストのジョブ定義を参照する非互換性定義(ある場合)が決定されます。また、その際に任意のドメインの非互換性に対するリソース(プロパティ)値も決定されます。この情報はリクエストのライフ・サイクルの後続の処理全体(リクエストの再試行を含む)を通して使用されます。ジョブ・セット・リクエストの場合、個別のステップ・リクエストが実行されるときではなく最上位のジョブ・セット・リクエストが実行されるときに、Oracle Enterprise Schedulerにより、潜在的なジョブ・セット・ステップのジョブ定義を参照する非互換性定義(ある場合)が決定されます。

スケジュールベースの発行の場合、Oracle Enterprise Schedulerにより、スケジュールのインスタンスに新しい子リクエストが作成されます。指定した時間に実行されるインスタンスは1つのみです。インスタンス・リクエストが最初に実行されるときに、Oracle Enterprise Schedulerにより、非互換性定義に行われたメタデータ変更が追跡され、非互換性定義(ある場合)がリフレッシュされる場合があります。これは、次のインスタンス・リクエストが実行されるときに使用される非互換性定義が、前のインスタンス・リクエストが実行されたときに使用された非互換性定義と異なる場合があることを意味します。

18.1.1 ジョブの自己非互換性

ジョブ定義またはジョブ・セットは、それら自体と互換性がない場合、自己非互換として定義できます。自己非互換とは、単一のジョブ定義に関連付けられる複数のジョブ・リクエストを同時に実行できないことを意味します。単一のエンティティが自己非互換としてマークされる場合、非互換性定義にそのエンティティを含めることができます。グローバルな自己非互換性では、特定のジョブまたはジョブ・セット定義に対する複数のリクエストは同時に実行されません。プロパティベースの自己非互換性では、特定のジョブまたはジョブ・セット定義に対するリクエストは、プロパティ値が同じである場合、同時に実行されません。

18.2 Oracle JDeveloperとの非互換性の定義

次のことを指定することによって、Oracle JDeveloperにおける非互換性を定義できます。

- 非互換性の名前とパッケージ

- 非互換性タイプ

- 非互換性のエンティティおよび自己非互換性の有無

- ドメイン固有の非互換性の場合には、エンティティごとの非互換性に関連付けられるプロパティ

18.2.1 グローバルな非互換性の定義方法

Oracle Enterprise Schedulerのグローバルな非互換性は、名前、パッケージおよびエンティティによって定義されます。

グローバルな非互換性を作成する手順は、次のとおりです。

1. Oracle JDeveloperで、プロジェクト内で右クリックして「新規ギャラリ」を表示します。

2. 「カテゴリ」で「ビジネス層」を展開し、「エンタープライズ・スケジューラ・メタデータ」を選択します。

3. 「アイテム」で「非互換性」を選択して、「OK」をクリックします。これにより、図18-1に示すように、「非互換性の作成」ウィンドウが表示されます。

図18-1 「非互換性の作成」ウィンドウ

4. 「非互換性の作成」ダイアログを使用して、次を指定します。

a. 「名前」フィールドで、非互換性の名前を入力するか、またはデフォルト名前をそのまま使用します。

b. 「パッケージ」フィールドで、非互換性のパッケージ名を入力します。

c. 「場所」フィールドに非互換性ファイルが格納されているディレクトリのフルパスが表示されます。

d. 「非互換性タイプ」フィールドで「グローバル」を選択し、「OK」をクリックします。
非互換性が作成され、非互換性定義ページが表示されます。

5. 「非互換性エディタ」ペインの「説明」フィールドで、非互換性の説明を入力します。

6. 「エンティティ」領域で、「追加」をクリックしてエンティティを追加します。これにより、図18-2に示すように、「エンティティの追加」ダイアログが表示されます。

図18-2 非互換性の「エンティティの追加」ウィンドウ

7. 非互換性に対して1つ以上のエンティティを選択して、「OK」をクリックします。非互換性エディタが表示されます。

8. 自己非互換性を指定するか、またはエンティティを変更するには、「エンティティ」領域内のエンティティをダブルクリックします。これにより、図18-3に示すように、「エンティティの編集」ダイアログが表示されます。

図18-3 グローバルな非互換性の「エンティティの編集」ウィンドウ

9. 自己非互換性を指定するには、「自己非互換」を選択します。

10. 非互換性を保存します。

18.2.2 ドメインの非互換性の定義方法

Oracle Enterprise Schedulerのドメインの非互換性は、名前、パッケージ、エンティティおよび各エンティティのプロパティによって定義されます。

非互換性を作成する手順は、次のとおりです。

1. Oracle JDeveloperで、プロジェクト内で右クリックして「新規ギャラリ」を表示します。

2. 「カテゴリ」で「ビジネス層」を展開し、「エンタープライズ・スケジューラ・メタデータ」を選択します。

3. 「アイテム」で「非互換性」を選択して、「OK」をクリックします。これにより、「非互換性の作成」ウィンドウが表示されます。

4. 「非互換性の作成」ダイアログを使用して、次を指定します。

a. 「名前」フィールドで、非互換性の名前を入力するか、またはデフォルト名前をそのまま使用します。

b. 「パッケージ」フィールドで、必要に応じて非互換性のパッケージ名を入力します。

c. 「場所」フィールドに非互換性ファイルが格納されているディレクトリのフルパスが表示されます。

d. 図18-4に示すように、「非互換性タイプ」フィールドで「ドメイン」を選択します。

図18-4 「非互換性の作成」ウィンドウ

「OK」をクリックします。これにより非互換性が作成され、「非互換性エディタ」が表示されます。

5. 「非互換性エディタ」ペインの「説明」フィールドで、非互換性の説明を入力します。

6. 「非互換性エンティティ」領域で、「追加」をクリックします。
「エンティティの追加」ウィンドウが表示されます。

7. 非互換性に追加する1つ以上のジョブまたはジョブ・セットを選択して、「OK」をクリックします。
非互換性エディタが表示されます。

8. 自己非互換性を指定するか、またはエンティティやそのプロパティを変更するには、「エンティティ」フィールドでエンティティをダブルクリックします。
図18-5に示すように、「エンティティの編集」ウィンドウが表示されます。

図18-5 非互換性の「エンティティの編集」ウィンドウ

9. 自己非互換性を指定するには、「自己非互換」を選択します。

10. 非互換性を保存します。

18.3 ジョブ非互換性を処理するために実行時に行われる処理

実行時、Oracle Enterprise Schedulerによって、非互換性タイプのグローバルまたはドメイン(プロパティベース)に応じて非互換性定義が処理されます。

ジョブ・リクエストが実行されるときに、Oracle Enterprise Schedulerによって、リクエストの発行に使用されるジョブまたはジョブ・セット定義を参照する非互換性定義が決定されます。各ドメインの非互換性について、その非互換性に使用するリソースまたはプロパティの値も決定されます。すでに実行中の非互換性リクエストがあるかどうかを決定するためにOracle Enterprise Schedulerによって確認されます。そうである場合、リクエストは、そのリクエストが互換性のないすべてのリクエストが完了するまでブロックされます。

注意:

ドメイン非互換性のプロパティの値が、リクエストの実行時にリクエスト・パラメータから取得されます。通常、値はリクエストの発行時に指定されたジョブ定義またはリクエスト・パラメータのいずれかに基づきます。このようなパラメータが見つからない場合、この非互換性は、後続のリクエスト処理で無視されます。この非互換性定義に関して、リクエストは他のリクエストと互換性を持ちます。初期プロパティ値は、プロパティが後で変更された場合も、非互換性リソース値として使用されます。

18.3.1 互換性のない親リクエストを含むサブリクエストについての処理

別のリクエストと互換性のないリクエストは、そのリクエストのサブリクエスト(子)とも互換性がありません。サブリクエストの親によってブロックされたリクエストは、サブリクエストが実行される間、およびサブリクエストの親リクエストが再開されて完了するまでブロックされたままとなります。

19 ランタイム・サービスの使用

この章では、Oracle Enterprise Schedulerランタイム・サービスAPIを使用して、ジョブ・リクエストを発行および管理し、ジョブ・リクエスト履歴からジョブ・リクエスト情報を問い合せる方法について説明します。

注意:

ランタイム・サービスには、ログおよび出力APIも含まれます。これらのAPIについては、「ジョブ・リクエスト・ログと出力」で別々に説明します。

この章の内容は次のとおりです。

- ランタイム・サービスの概要

- ランタイム・サービスへのアクセス

- ジョブ・リクエストの発行

- ジョブ・リクエストの管理

- ジョブ・リクエストの問合せ

- 非定型ジョブ・リクエストの発行

- 前処理および後処理ハンドラの実装

19.1 ランタイム・サービスの概要

Oracle Enterprise Schedulerを使用すると、Javaクラス、PL/SQLプロシージャおよびプロセス・ジョブ・タイプ(分岐プロセス)など、様々なジョブ・タイプを定義して実行できます。これらのジョブ・タイプを実行するには、ジョブ定義を発行する必要があります。

ランタイム・サービスを使用して、次のような様々なタイプの操作を実行できます。

- 発行: これらの操作では、Oracle Enterprise Schedulerにジョブ定義を提供して、ジョブ・リクエストを作成できます。

- 管理: これらの操作では、ジョブ・リクエストの状態を変更して、ジョブ・リクエストを更新できます。

- 問合せ: これらの操作では、ジョブ・リクエストの状態とレポート・ジョブ・リクエスト履歴を確認できます。

19.2 ランタイム・サービスへのアクセス

メタデータ・サービスと同様に、Oracle Enterprise SchedulerではランタイムMBeanプロキシ・インタフェースを提供します。

ランタイム・サービスのopen()メソッドにより、各Oracle Enterprise Schedulerランタイム・サービス・ユーザー・トランザクションが開始されます。Oracle Enterprise Schedulerアプリケーション・クライアントでは、open()により作成されるRuntimeServiceHandle参照を取得して、その参照をランタイム・サービス・メソッドに渡します。RuntimeServiceHandle参照により、クライアント・アプリケーションにランタイム・サービスへの接続が提供されます。クライアント・アプリケーションでは、close()をコールしてランタイム・サービスを明示的に終了する必要があります。これによりトランザクションが終了し、トランザクションがコミットまたはロールバック(取消し)されます。close()はランタイム・サービス内のトランザクション動作を制御するだけでなく、Oracle Enterprise SchedulerによりRuntimeServiceHandleに関連付けられているリソースを解放できるようにします。

19.2.1 ランタイム・サービスにアクセスしてランタイム・サービス・ハンドルを取得する方法

Oracle Enterprise Schedulerでは、アプリケーション・プログラムに対して、ランタイム・サービスをステートレス・セッションEnterprise Java Bean (EJB)として公開します。Oracle Enterprise Schedulerランタイム・サービスのステートレス・セッションEJBを見つけるために、JNDIを使用できます。

例19-1に、RuntimeServiceLocalHomeオブジェクトを使用したOracle Enterprise Schedulerランタイム・サービスのルックアップを示します。

注意:

ランタイム・サービスにアクセスするときは、次のことに注意してください。

- JndiUtil.getRuntimeServiceEJB()では、RuntimeService EJBがローカルのJNDIロケーション"ess/runtime"にマップされていることを前提としています。これは、ホストされているアプリケーションのメッセージドリブンBean (MDB)内で自動的に行われます。

- open()コールによって、RuntimeServiceHandle参照が提供されます。この参照は、アプリケーション・プログラム内の、ランタイム・サービスにアクセスするメソッドで使用します。

- ランタイム・サービスの使用が終了したら、close()をコールして、RuntimeServiceHandleに関連付けられているリソースを解放する必要があります。

例19-1 Oracle Enterprise Schedulerランタイム・サービスにアクセスするためのJNDIルックアップ

import oracle.as.scheduler.core.JndiUtil;
// Demonstration of how to lookup runtime service from a
// Java EE application component

RuntimeService runtime = JndiUtil.getRuntimeServiceEJB();
RuntimeServiceHandle rHandle = null;
.
.
.
try
{
...
rHandle = runtime.open();
...
}
finally
{
if (rHandle != null)
{
runtime.close(rHandle);
}
}

19.3 ジョブ・リクエストの発行

ジョブ定義の発行時に、新しいジョブ・リクエストを作成します。

メタデータ・リポジトリで維持されているジョブ定義を使用してジョブ・リクエストを発行するか、ジョブ定義またはスケジュールがメタデータ・リポジトリに格納されない非定型方式でジョブ・リクエストを作成できます(非定型リクエストの詳細は、「非定型ジョブ・リクエストの発行」を参照してください)。

19.3.1 ランタイム・サービスへのリクエストの発行方法

ジョブ・リクエストを作成するには、submitRequest()をコールします。必要に応じて、次のいずれかの形式でジョブ・リクエストを作成できます。

- 特定の時間に1回のみ実行する場合は、メタデータ・リポジトリに格納されているジョブ定義を使用して、新しいジョブ・リクエストを作成します。

- メタデータ・リポジトリに格納されている各ジョブ定義とスケジュールを使用して、新しいジョブ・リクエストを作成します。

例19-2に、メタデータ・リポジトリに常駐するジョブ定義を使用して新しいジョブ・リクエストを作成するsubmitRequest()メソッドを示します。また、ジョブ定義とスケジュールがメタデータ・リポジトリに格納されない、非定型ジョブ・リクエストを発行することもでます。詳細は、「非定型ジョブ・リクエストの発行」を参照してください。サブリクエストを発行することもできます。詳細は、「サブリクエストの使用」を参照してください。

注意:

ランタイム・サービスを使用してジョブ・リクエストを発行するときには、次のことに注意してください。

- 例19-1に示されているように、ランタイム・サービス・ハンドルを取得します。

- ランタイム・サービスでは、メタデータ・サービスを内部的に使用して、指定されたMetadataObjectId、jobDefnIdを持つジョブ定義メタデータを取得します。

例19-2 submitRequest()によるジョブ・リクエストの作成

long requestID = 0L;
MetadataObjectId jobDefnId;

RequestParameters p = new RequestParameters();

Calendar start = Calendar.getInstance();
start.add(Calendar.SECOND, startsIn);

requestID = runtime.submitRequest(r, "My Java job", jobDefnId, start, p);

19.3.2 リクエスト発行時のデフォルト・システム・プロパティに関する注意事項

ジョブ・リクエストを作成するとき、Oracle Enterprise Schedulerによって、ジョブ・リクエストに関連付けられているプロパティが解決および格納されます。特定のシステム・プロパティを、ジョブ・リクエストと関連付けることができます。ジョブ・リクエストが発行されたとき、これらのプロパティをプロパティ階層内に設定していなかった場合は、Oracle Enterprise Schedulerによってデフォルト値が提供されます。

表19-1に、デフォルト・ランタイム・サービス・フィールド名と対応するシステム・プロパティを示します。

表19-1 ランタイム・サービスのデフォルト値フィールドと対応するシステム・プロパティ

値

ランタイム・サービスのデフォルト値フィールド

対応するシステム・プロパティ

説明

0

DEFAULT_REQUEST_EXPIRATION

SYS_requestExpiration

リクエストのデフォルト有効期限(分数)。デフォルト値は、リクエストが有効期限切れにならないことを意味する0です。

4

DEFAULT_PRIORITY

SYS_priority

リクエストに関連付けられているデフォルトのシステム優先度。

5

DEFAULT_REPROCESS_DELAY

SYS_reprocessDelay

Action.DELAYを返すコールアウト・ハンドラにより処理が延期されるデフォルトの時間(分数)。

0

DEFAULT_RETRIES

SYS_retries

失敗したリクエストのデフォルトの再試行回数。デフォルト値は0で、失敗したリクエストが再試行されないことを意味します。

0

DEFAULT_ASYNC_REQUEST_TIMEOUT

SYS_request_timeout

ジョブ実行が開始された後に、プロセッサが非同期レスポンスを待機する時間を分数で指定します。時間が経過した後、リクエストはタイムアウトになります。

19.3.3 リクエスト発行時のメタデータに関する必知事項

ジョブ・リクエストに関連付けられているすべてのOracle Enterprise Schedulerメタデータは、リクエストの発行時にランタイム・ストアに維持されます。維持されるメタデータ・オブジェクトには、ジョブ定義、ジョブ・タイプ、ジョブ・セット、スケジュール、非互換性定義および除外定義があります。メタデータは最上位レベルのリクエストのコンテキストに格納され、各メタデータ・オブジェクトは絶対親リクエストIDおよびそのメタデータIDによって一意に識別されます。最上位レベルのリクエストに対して、一意のメタデータ・オブジェクトはそれぞれ1回のみ格納され、これは、そのリクエスト内で定義が複数回使用されている場合も同様です。これにより、すべての子リクエストで必ず同じ定義が使用されます。

リクエストが発行されると、リクエストのすべての既知のメタデータが維持されます。サブリクエストの場合は、サブリクエストが発行されるまでメタデータが認識されないため、サブリクエスト・メタデータは、サブリクエストの発行時に、メタデータ・オブジェクトがすでにランタイム・ストアにおいて永続化されていないことが確認された後で、維持されます。

ランタイム・ストアに維持されたメタデータは、絶対親リクエストが削除されるときに削除されます。

19.3.4 DMS ECIDおよびFlowIdのサポート

Oracle Enterprise Schedulerは、DMS ECIDおよびFlowId値をすべてのリクエストに関連付けます。Oracle Enterprise Schedulerでは、通常、リクエストの発行時に現在のDMS実行コンテキストからECIDおよびFlowIdを取得し(存在する場合)、そのECIDおよびFlowId値を後続のリクエストの処理で使用します。たとえば、Oracle Enterprise Schedulerは、ジョブの実行可能ファイルを開始するときに、リクエストにECIDおよびFlowIdを関連付けるDMS実行コンテキストを設定します。

リクエストの発行時、DMS FlowIdプロパティがDMS実行コンテキスト内に存在しない場合、新規FlowIdはリクエストに関連付けられます。たとえば、リクエストがSOAによって発行されていない場合、DMS実行コンテキスト上にFlowIdが存在しない場合があり、Oracle Enterprise Schedulerによって新規FlowIdがリクエストと関連付けられます。

DMS実行コンテキストがリクエストの発行時に存在しない場合、新しいECIDおよびFlowIdがリクエストに関連付けられます。たとえば、リクエストがOracle Enterprise Scheduler PL/SQLインタフェースを使用して発行された場合、PL/SQL発行プロシージャがコールされたときにデータベース・セッションから使用できるDMSコンテキスト情報がない場合があります。新しいECIDおよびFlowIdが、Oracle Enterprise Schedulerの中間層によって検証が正常に完了した後、リクエストに関連付けられます。

19.3.4.1 子リクエストのECIDおよびFlowID

一般的に、子リクエストは、親リクエストからECIDおよびFlowIdを継承します。たとえば、ジョブ・セット・ステップ・リクエストの作成時、Oracle Enterprise Schedulerでは親リクエストのECIDおよびFlowIdが使用されます。

サブリクエストは発行済のリクエストであるため、サブリクエストの発行の現在のDMS実行コンテキストのECIDおよびFlowIdがサブリクエストに関連付けられます。通常、ECIDおよびFlowIdの値は、親リクエストの値と同じですが、これは親ジョブの実行可能ファイルを開始する前に、Oracle Enterprise Schedulerにより親リクエストのECIDおよびFlowIdが含まれるDMS実行コンテキストが設定されるためです。Oracle Enterprise Schedulerがサブリクエストの発行を受信する前に、アプリケーションまたは一部のコンポーネント・レイヤーによりECIDまたはFlowIdが変更される場合があります。その場合、親およびサブリクエストのECIDまたはFlowIdが異なる場合があります。

スケジュールがリクエストの発行時に指定されている場合、発行されるリクエストは実行されていない絶対親を表します。Oracle Enterprise Schedulerは、指定されたスケジュールに従って子インスタンス・リクエストを自動的に作成し、新しいECIDおよびFlowIdが各子インスタンスに使用されます。子インスタンス・リクエストは、インスタンスの親リクエストを表し、それ自体の子が含まれる場合があります(サブリクエストまたはジョブ・セット・ステップ・リクエストなど)。一般的にそのような子には、そのインスタンスの親リクエストと同じECIDおよびFlowIdが含まれます。

19.3.4.2 DMS FlowIdおよびSOA CorrelationFlowId

Oracle Enterprise Schedulerでは、プロパティ名がFlowIdであるDMS FlowIdプロパティが使用されます。SOAには、DMS実行コンテキストに存在している場合があるプロパティがいくつかあります。その2つのプロパティは、SOA CorrelationFlowIdおよびSOA FlowIdプロパティです。DMS FlowIdプロパティ(FlowId)は、SOA CorrelationFlowIdの値の伝播に使用されます。DMSプロパティ名"oracle.soa.tracking.FlowId"は、SOA FlowIdプロパティの値の伝播に使用されます。このため、SOAによって発行されるOracle Enterprise Schedulerリクエストに関連付けられているFlowIdプロパティは、SOA CorrelationFlowIdの値と一致する場合があります。

19.4 ジョブ・リクエストの管理

ジョブ・リクエストを発行した後、requestIDを使用して、次のことを実行できます:

- リクエスト情報の取得

- リクエストの状態の変更

- リクエスト・パラメータの更新

19.4.1 getRequestDetailによるジョブ・リクエスト情報の取得方法

ランタイム・サービスをrequestIDとともに使用して、システム内に存在するジョブ・リクエストの情報を取得できます。表19-2に、ジョブ・リクエスト情報を取得できるようにするランタイム・サービス・メソッドを示します。

表19-2 ランタイム・サービスのGetリクエスト・メソッド

ランタイム・サービス・メソッド

説明

getRequestDetail()

指定したリクエストの完全なランタイム詳細を取得します。

getRequestDetailBasic()

指定したリクエストの基本的なランタイム詳細を取得します。このメソッドによって返されるRequestDetailには、ほとんどの情報がgetRequestDetail()として含まれますが、使用頻度の低い特定の情報はパフォーマンスを向上させるために省略されます。

getRequestParameter()

リクエスト・パラメータの値を取得します。

getRequests()

指定したリクエストに関連付けられている直接的な子リクエスト識別子の列挙を取得します。これには、完了していないリクエストのIDが含まれます(リクエスト・トランザクションがロールバックされる場合や、エラーが発生した場合など)。

getRequestState()

指定したリクエストの現在の状態を取得します。

例19-3 に、HOLD状態にある直接的な子リクエストがあるかどうかを判別するコードを示します。

例19-3 直接的な子のジョブ・リクエストが保留中であるかどうかの判別

h = s_runtime.open();
try {

s_runtime.holdRequest(h,reqid);

Enumeration  e = s_runtime.getRequests(h, reqid);

boolean foundHold = false;
while (e.hasMoreElements()) {

long childid = ((Long)e.nextElement()).longValue();
State state = s_runtime.getRequestState(h,childid);
if (state == State.HOLD) {
foundHold = true;
break;
}
}

19.4.2 ジョブ・リクエスト状態の変更方法

ランタイム・サービスをrequestIDとともに使用して、ジョブ・リクエストの状態を変更できます。表19-3に、ランタイム・サービスのジョブ・リクエスト状態変更メソッドを示します。ジョブ・リクエスト管理メソッドを使用すると、ジョブ・リクエストの状態によっては、リクエストの状態を変更できます。たとえば、リクエストがCOMPLETED状態である場合は、cancelRequest()でリクエストを取り消すことはできません。

表19-3 ランタイム・サービスのジョブ・リクエスト状態メソッド

ランタイム・サービス・メソッド

説明

cancelRequest()

終了状態にないリクエストの処理を取り消します。

deleteRequest()

終了状態にあるリクエストを削除対象としてマークします。

holdRequest()

WAITまたはREADY状態にあるリクエストのそれ以降の処理を保留にします。

releaseRequest()

リクエストのHOLD状態を解除します。

例19-4に、submitRequest()とジョブ・リクエストの状態を制御するメソッドを示します。holdRequest()は、ジョブ・リクエストの処理を保留にします。対応するreleaseRequest()によって、リクエストが解放されます。この例では、リクエストを保留にする必要がある条件は示しません。

注意:

例19-4について、次のことに注意してください。

- 例19-1に示されているように、ランタイム・サービス・ハンドルrHandleを取得します。

- holdRequest()によって、リクエストがHOLD状態になります。

- リクエストがHOLD状態にある間も、必要な一部の処理を実行できます。

- releaseRequest()によって、リクエストのHOLD状態が解除されます。

例19-4 ランタイム・サービスのreleaseRequest()の使用

rHandle = runtime.open();
try
{
runtime.holdRequest(rHandle,reqid);
.
.
.
runtime.releaseRequest(rHandle, reqid);
.
.
.
}
finally
{
if (rHandle != null)
{
runtime.close(rHandle);
}
}

19.4.3 ジョブ・リクエストの優先度とジョブ・リクエスト・パラメータの更新方法

ランタイム・サービスを使用して、ジョブ・リクエストのシステム・プロパティまたはリクエスト・パラメータを更新できます。表19-4に、ジョブ・リクエストをロックおよび更新できるようにするランタイム・サービス・メソッドを示します。

表19-4 ランタイム・サービスの更新メソッド

ランタイム・サービス・メソッド

説明

lockRequest()

指定されたリクエストのロックを取得します。ロックは、close()操作がその後で起動されるか、またはそのロックを包含するトランザクションがコミットされると解放されます。他のスレッドによってロックが保持されているときに、アプリケーションがこの操作の起動を試みると、このメソッドはロックが解放されるまでブロックされます。このメソッドは、リクエスト・パラメータまたはシステム・プロパティを更新する際に、データの一貫性を確保するために使用します。

setRequestParameter()

指定されたリクエスト・サブジェクトのプロパティ値を、プロパティの読取り専用制約に更新します。

例19-5に、ジョブ・リクエスト・パラメータを更新するコードを示します。例19-1に示されているように、このコードはtry/finallyブロック内に含められます。

例19-5は、次のことを示しています。

- 例19-1に示されているように、ランタイム・サービス・ハンドルrhandleを取得します。

- lockRequest()を使用して、いずれかのリクエストにロックを取得します。

- setRequestParameter()により更新操作を実行します。

- close()を使用して、トランザクションをコミットまたはロールバック(取消し)します。close()はランタイム・サービス内のトランザクション動作を制御するだけでなく、Oracle Enterprise SchedulerによりRuntimeServiceHandleに関連付けられているリソースを解放できるようにします。

例19-5 ランタイム・サービス・パラメータの更新のサンプル

...
s_runtime.lockRequest(rhandle, reqid);
s_runtime.setRequestParameter(rhandle, reqId, paramName, "yy");
...

19.5 ジョブ・リクエストの問合せ

ランタイム・サービスを使用して、ジョブ・リクエスト情報を問い合せることができます。

これを行うには次の手順が必要になります。

- リクエスト識別子の問合せとフィルタによる結果の制限。

- 問合せにより返される各リクエストIDの追加情報を提供するためのリクエスト詳細の取得。

問合せメソッドは、ランタイム・サービスのqueryRequests()メソッドの1つのみです。このメソッドにより、問合せに一致するリクエストIDの列挙が返されます。queryRequests()メソッドには、問合せ結果の選択に役立つフィールド、コンパレータおよび値の組合せが格納されたフィルタ引数が含まれます。戻り値には、完了していないリクエストのIDが含まれます(リクエスト・トランザクションがロールバックされる場合や、エラーが発生した場合など)。フィルタの詳細は、「フィルタの作成方法」を参照してください。

問合せにフィルタを作成すると、ランタイム・ストアを問い合せるときに、表19-5に示されているいずれかのフィールド名を使用できます。

表19-5 ランタイムの問合せ用の問合せフィルタ・フィールド(列挙RuntimeService.QueryFieldで定義)

名前

説明

ABSPARENTID

リクエストの絶対親リクエストID。

APPLICATION

アプリケーション名。

ASYNCHRONOUS

ジョブが非同期、同期または不明のいずれであるかを示します。フィールドの値は、リクエストが処理されるまで設定されません。フィールドのデータ型はjava.lang.Booleanです。ジョブの性質がまだ決定されていない場合、この値はNULLにできます。

CLASSNAME

リクエストを処理した実行可能クラスの名前。

COMPLETED_TIME

Oracle Enterprise Schedulerでリクエストの処理が終了した日時。このフィールドは、プロセス・フェーズがCOMPLETEDに設定された時間を表します。

DEFINITION

ジョブ定義ID(メタデータ・オブジェクトID)。

ELAPSEDTIME

リクエストの実行に要した時間(ミリ秒)。

ENTERPRISE_ID

エンタープライズID。

ERROR_TYPE

リクエスト・エラー・タイプ。

EXTERNAL_ID

Oracle Enterprise Scheduler非同期Javaジョブの外部部分の識別子。

EXTERNAL_JOB_TYPE

リモート・ジョブのタイプを示します。

INSTANCEPARENTID

インスタンスの親リクエストのリクエストID。

JOB_TYPE

ジョブ・タイプID(メタデータ・オブジェクトID)。

LOGICAL_CLUSTER_NAME

リモート・ジョブが実行される論理クラスタを示します。

NAME

リクエストの説明。

PARENTREQUESTID

親リクエストID。

PRIORITY

リクエストの優先度。

PROCESS_PHASE

リクエストのプロセス・フェーズ。

PROCESSEND

プロセスが終了した日時。PROCESSSTARTは、リクエストがREADYからRUNNINGに遷移した場合にのみ設定されます。これは、(PROCESSEND - PROCESSSTART)に、状態がRUNNINGになってから終了状態に遷移するまでの、実行の全期間が含まれることを意味します。

PROCESSOR

リクエストを処理したインスタンスの名前。

PROCESSSTART

プロセスが開始した日時。PROCESSSTARTは、リクエストがREADYからRUNNINGに遷移した場合にのみ設定されます。これは、(PROCESSEND - PROCESSSTART)に、状態がRUNNINGになってから終了状態に遷移するまでの、実行の全期間が含まれることを意味します。

PRODUCT

製品名。

READYWAIT_TIME

リクエストがREADYになった後、実行を待機している時間(ミリ秒)。

REQUEST_CATEGORY

リクエストに指定されたリクエスト・カテゴリ。

REQUEST_DMS_ECID

リクエストの処理に使用されるDMS ECID。

REQUESTEDEND

リクエストされた終了時間。

REQUESTEDSTART

リクエストされた開始時間。

REQUESTID

発行されたリクエストのリクエストID。

REQUESTTYPE

リクエストのタイプ(つまり、RequestTypeの要素)。

RESULTINDEX

返された結果の開始および終了索引を制御します。ユーザーはこのフィールドを使用して、「10から20までの結果のみを返す」などの結果の制約を示すことができます。

RETRIED_COUNT

ジョブに関連付けられている再試行回数。このフィールドは、ジョブが再試行された回数を表します。

REQUESTTRIGGER

トリガーID (メタデータ・オブジェクトID)。

SCHEDULE

スケジュールID(メタデータ・オブジェクトID)。

SCHEDULED

スケジュールされたリクエストの実行時間。

STATE

ジョブ・リクエストの状態。

SUBMISSION

リクエストの発行時間。

SUBMITTER

リクエストの発行者。

SUBMITTER_DMS_ECID

リクエスト発行時のDMSコンテキストからのDMS ECID。

SUBMITTER_FLOWID

リクエスト発行時のDMSコンテキストからのSOA/DMS FlowId。

SUBMITTERGUID

リクエストの発行者GUID。

TIMED_OUT

ジョブがタイムアウトしたかどうかを示します。

TYPE

リクエストの実行タイプ。

USERNAME

リクエストを発行したユーザーの名前。

WAITTIME

リクエストが実行を待機している時間(ミリ秒)。

WORKASSIGNMENT

リクエストが処理されたときにアクティブだった作業割当ての名前。

表19-6にジョブ・リクエストを問い合せるランタイム・サービス・メソッドを、例19-6にこのメソッドの使用方法を示します。

表19-6 ランタイム・サービスの問合せメソッド

ランタイム問合せメソッド

説明

queryRequests()

リクエストのサマリーを取得します。

例19-6 queryRequest()メソッドの使用

Filter filter =
new Filter(RuntimeService.QueryField.DEFINITION.fieldName(),
Filter.Comparator.EQUALS,
myJavaSucJobDef.toString())
.and(RuntimeService.QueryField.STATE.fieldName(),
Filter.Comparator.EQUALS,
new Integer(12) );

//
Enumeration requests =
runtime.queryRequests(h, filter,
RuntimeService.QueryField.REQUESTID, true);

19.6 非定型ジョブ・リクエストの発行

非定型リクエストを使用するには、リクエスト・パラメータ、ジョブ定義、およびオプションで、メタデータ・リポジトリに保存せずに作成および定義するスケジュールを指定します。

非定型リクエストでは、メタデータ・リポジトリでジョブ・リクエストの詳細を定義する必要がありません。このため、非定型リクエストによって、メタデータ・リポジトリへの接続を使用しないで実行できる、省略されたジョブ・リクエスト発行プロセスがサポートされます。

注意:

非定型リクエストには、ジョブ・セットはサポートされないという制約があります。

19.6.1 非定型リクエストの作成方法

非定型リクエストを作成するには、非定型バージョンのsubmitRequest()を使用します。ジョブ定義の場合は、ジョブ定義MetadataObjectIdを指定するかわりに、表19-7で示されているように、ジョブ定義オブジェクトを定義して、ジョブ・タイプに対応するシステム・プロパティを使用できます。

表19-7 ジョブ・タイプに対する非定型リクエスト・ジョブ定義のシステム・プロパティ

システム・プロパティ

説明

CLASS_NAME

実行するJavaクラスを指定します(Javaジョブ・タイプに対して)。

PROCEDURE_NAME

実行するPL/SQLストアド・プロシージャを指定します(SQLジョブ・タイプに対して)。

CMDLINE

プロセス・ジョブ・リクエストに対して外部プログラムを起動するために使用されるコマンド行を指定します。

非定型バージョンのsubmitRequest()の1つのシグネチャを使用すると、MetadataObjectIdsを指定する必要はありません。Scheduleオブジェクトを、オブジェクト・インスタンスを表す引数として、直接submitRequest()に指定できます。その他の非定型submitRequest()シグネチャを使用すると、メタデータのジョブ定義およびScheduleオブジェクトのインスタンスを使用して、ジョブ・リクエストを発行できます。

例19-7に、スケジュールを使用する非定型リクエスト発行のサンプル・コードを示します。

この例では、リクエスト発行に関する次の非定型固有の詳細に注意してください。

- CLASS名は、Oracle Enterprise Schedulerによるジョブ・リクエストの実行時に、実行されるJavaクラスを定義するために次のように設定されます。p.add(SystemProperty.CLASS_NAME, "test.job.HelloWorld");

- submitRequest()には、ジョブ・タイプを指定する次の引数が含まれます。JobType.ExecutionType.JAVA_TYPE。

- 表19-7に示されているいずれかのシステム・プロパティを設定することによって、非定型リクエストが処理されるときに実行するJavaクラス、プロシージャ名またはコマンド行プログラムを指定します。

- 非定型バージョンのsubmitRequest()をコールして、リクエストを定義するために設定するシステム・プロパティに対応するタイプ引数を指定します。指定するタイプは、JAVA_TYPE、SQL_TYPEまたはPROCESS_TYPEのいずれかである必要があります。

- 他のすべてのジョブ・リクエストと同様に、ジョブ・リクエストに関連付ける適切なシステム・プロパティを設定します。

例19-7 非定型リクエストのリクエスト・パラメータとスケジュールの作成

RequestParameters p = new RequestParameters();
String propName = "testProp";
String propValue = "testValue";
p.add(propName, propValue);
p.add(SystemProperty.REQUEST_EXPIRATION, new Integer(10));
p.add(SystemProperty.LISTENER, "test.listener.TestListener");
p.add(SystemProperty.EXECUTE_PAST, "TRUE");
p.add("application", getApplication());
p.add(SystemProperty.CLASS_NAME, "test.job.HelloWorld");

Calendar start = Calendar.getInstance();
start.add(Calendar.SECOND, 5);
Calendar end = (Calendar) start.clone();
end.add(Calendar.SECOND, 5);

Recurrence recur = new Recurrence(RecurrenceFields.FREQUENCY.SECONDLY,
2, start, end);

Schedule schedule = new Schedule("mySchedule",
"Run every 2 sec for 5 seconds.", recur);

// adhoc submission, no metadata definitions passed
reqId = runtime.submitRequest(h,
"testAdhocJavaWithSchedule",
JobType.ExecutionType.JAVA_TYPE, schedule,                                       null, Calendar.getInstance(), null, p);

19.6.2 非定型リクエストの作成時の処理内容

非定型のsubmitRequest()では、リクエストに対してリクエスト識別子が返されます。他のすべてのジョブ・リクエストと同様に、このリクエスト識別子をsetRequestParameter()やgetRequestDetail()などのランタイム・コールとともに使用できます。

非定型ジョブ定義を使用してリクエストを作成するsubmitRequestシグネチャは1つのみ存在します。この場合、RequestDetail.getJobDefn()から取得されるジョブ定義IDはNULLです。非定型ジョブ定義がない場合、リクエストは非定型とはみなされません。

19.6.3 非定型リクエストに関する必知事項

非定型リクエストで使用するスケジュールを定義し、除外日を指定するには、スケジュールに対してaddExclusionDate()メソッドを使用して日付を除外する必要があります。非定型リクエストでは、スケジュールに対してaddExclusion()メソッドを使用して除外日を指定するスケジュールは使用できません。

現在、スケジュールが非定型の場合、ExclusionDefinitionのチェックはスキップされます。このため、スケジュールを使用し、addExclusion()を使用して非定型ジョブ・リクエストを発行する場合は、ジョブ・リクエストに対してExclusionsDefinition IDが使用されません。

19.7 前処理および後処理ハンドラの実装

ジョブのコア・ロジックとともに、ジョブの主要実行コードの前後で実行されるコードを含めることができます。前処理ハンドラと呼ばれる、前に実行されるコードを使用して、ジョブ実行可能ファイルに特定の条件を設定するなどの操作を実行できます。

後処理ハンドラと呼ばれる、後で実行されるコードを使用すると、レポートの印刷や通知の送信などによる、ジョブ実行可能ファイルの結果の処理といった操作を実行できます。

特定のインタフェースを実装し、使用するクラスを示すシステム・プロパティを通じてサービスに実装を接続することによって、前処理および後処理ハンドラを提供します。

19.7.1 前処理ハンドラの実装

前処理ハンドラを使用すると、コードでジョブの実行環境を作成するための操作を実行できます。これには、ジョブで必要なリソースへの接続の作成などが含まれます。

プリプロセッサは、リクエストがRUNNING状態に遷移した場合に、リクエストの実行開始時にインスタンス化および起動されます。これはリクエストが実行されるたびに行われ、失敗したリクエストが再試行されたり、一時停止されたリクエストがそのサブリクエストの完了後に再開される場合にも行われます。

前処理ハンドラは、oracle.as.scheduler.PreProcessHandlerインタフェースを実装することにより作成します。前処理ハンドラ・クラスを用意して、SYS_preProcessシステム・プロパティをハンドラ・クラスの完全修飾名に設定することにより、これを使用する必要があることを指定します。ジョブ・メタデータでプロパティを定義するか、リクエスト発行パラメータにプロパティを含めることができます。

19.7.1.1 PreProcessHandlerインタフェースの実装

PreProcessHandler実装では、ジョブで必要な前処理アクションを実行してから、インタフェースの1つのメソッドであるpreProcessからoracle.as.scheduler.HandlerActionインスタンスを返す必要があります。(ジョブで取消しがサポートされるようにするために、クラスでCancellableインタフェースを実装することもできます。これには、空のコンストラクタも提供する必要があります。)

preProcess実装により返されるHandlerActionインスタンスでは、ジョブを続行する必要があるかどうか、および続行する条件に関するステータスを示す必要があります。HandlerActionクラスを構築する場合、リクエストに対する前処理のステータスを示すHandlerStatusインスタンスにこのクラスを渡します。

サポートされているHandlerStatus値とアクションを次のリストに示します。サポートされていないステータスの場合は、リクエストがエラー状態に遷移し、再試行の対象となります(構成されている場合)。

- PROCEEDは、リクエスト処理を開始する必要があることをOracle Enterprise Schedulerに通知します。リクエストは、RUNNING状態のままとなります。

- WARNは、リクエスト処理を開始する必要があるが、警告をログに記録する必要があることをOracle Enterprise Schedulerに通知します。リクエストは、RUNNING状態のままとなります。

- CANCELは、リクエストの前処理が取り消されたことをOracle Enterprise Schedulerに通知します。リクエストは、CANCELLED状態に遷移します。

- DELAYは、SYS_reprocessDelayシステム・プロパティで指定された時間、リクエスト処理を延期するようOracle Enterprise Schedulerに通知します。リクエストは遅延中、RUNNING状態のままとなります。

- SYSTEM_ERRORは、ハンドラでエラーが発生したことをOracle Enterprise Schedulerに通知します。リクエストはエラー状態に遷移し、再試行の対象となります(構成されている場合)。

- BIZ_ERRORは、ハンドラでビジネス・エラーが発生したことをOracle Enterprise Schedulerに通知します。リクエストはエラー状態に遷移し、再試行の対象にはなりません。

19.7.2 後処理ハンドラの実装

後処理ハンドラを使用すると、コードでジョブの実行後に行う必要がある操作を実行できます。これには、ジョブによって要求されたリソースへの接続の解放や、リクエスト固有のデータまたはステータスに基づくレポートの生成などが含まれます。

リクエストがCOMPLETED状態に遷移した場合、ポストプロセッサはジョブの実行後にインスタンス化および起動されます。プリプロセッサとは異なり、ポストプロセッサはリクエストに対して1回のみ起動されます。

後処理ハンドラは、oracle.as.scheduler.PostProcessHandlerインタフェースを実装することにより作成します。後処理ハンドラ・クラスを用意して、SYS_postProcessシステム・プロパティをハンドラ・クラスの完全修飾名に設定することにより、これを使用する必要があることを指定します。ジョブ・メタデータでプロパティを定義するか、リクエスト発行パラメータにプロパティを含めることができます。

19.7.2.1 PostProcessHandlerインタフェースの実装

PostProcessHandler実装では、ジョブで必要な後処理アクションを実行してから、インタフェースの1つのメソッドであるpostProcessからoracle.as.scheduler.HandlerActionインスタンスを返す必要があります。(ジョブで取消しがサポートされるようにするために、クラスでCancellableインタフェースを実装することもできます。これには、空のコンストラクタも提供する必要があります。)

postProcess実装により返されるHandlerActionインスタンスでは、ジョブを終了する必要があるかどうかおよび終了する条件に関するステータスを示す必要があります。HandlerActionクラスを構築する場合、リクエストに対する後処理のステータスを示すHandlerStatusインスタンスにこのクラスを渡します。

サポートされているHandlerStatus値とアクションを次のリストに示します。サポートされていないステータスの場合は、リクエストがWARNING状態に遷移します。

- PROCEEDは、リクエストの後処理が正常に完了したことをOracle Enterprise Schedulerに通知します。ポストプロセッサを起動する直前のリクエストのステータスに応じて、リクエストがSUCCEEDED状態またはWARNING状態に遷移します。

- WARNは、リクエストの後処理により警告が生成されたことをOracle Enterprise Schedulerに通知します。リクエストは、WARNING状態に遷移します。

- CANCELは、リクエストの後処理が取り消されたことをOracle Enterprise Schedulerに通知します。リクエストは、WARNING状態に遷移します。

- DELAYは、SYS_reprocessDelayシステム・プロパティで指定された時間、リクエスト処理を延期するようOracle Enterprise Schedulerに通知します。リクエストは遅延中、COMPLETED状態のままとなります。

- SYSTEM_ERRORは、ハンドラでエラーが発生したことをOracle Enterprise Schedulerに通知します。リクエストは、WARNING状態に遷移します。

- BIZ_ERRORは、ハンドラでビジネス・エラーが発生したことをOracle Enterprise Schedulerに通知します。リクエストは、WARNING状態に遷移します。

20 サブリクエストの使用

この章では、Oracle Enterprise Schedulerサブリクエストを使用し、特に、並列リクエスト数が変動する動的コンテキストにおいてデータを並行して処理する方法について説明します。

この章の内容は次のとおりです。

- サブリクエストの使用の概要

- サブリクエストの作成と管理

- サブリクエストを発行するJavaプロシージャの作成

- サブリクエストを発行するPL/SQLプロシージャの作成

20.1 サブリクエストの使用の概要

Oracle Enterprise Schedulerサブリクエストは、データを並行して処理する場合に役立ちます。実行中のジョブから発行されるリクエストをサブリクエストと呼びます。

単一の親リクエストから複数のサブリクエストを発行できます。Oracle Enterprise Schedulerにおける通常の方法でのパラレル実行はジョブ・セット概念によるものですが、パラレル処理の数が一定にならない場合があります。たとえば、100万行ごとに1つのリクエストを割り当て、先週は、累積された処理対象が970万行となったとします。この場合は、10個のリクエストを割り当てます。460万行が累積された週では5個となります。

Oracle Enterprise Schedulerでは、指定した実行中のリクエスト(ジョブ・リクエスト)によりサブリクエストを発行し、このようなリクエストの完了を待機してから続行できるよう、サブリクエスト機能がサポートされています。

Oracle Enterprise Schedulerでは、オーバーロードされたサブリクエストのメソッドsubmitRequest()を公開することによって、サブリクエストがサポートされています。ジョブ・リクエストを発行するアプリケーションでは、このAPIを起動してサブリクエストを発行できます。

サブリクエストには、次の制限事項が適用されます。

- サブリクエストは1回かぎりの実行としてのみ発行できます。スケジュールは指定できません。通常、サブリクエストは即時実行リクエストとして処理されます。

- 非定型サブリクエストはサポートされていません。サブリクエストは、アプリケーション内の既存のJobDefinitionオブジェクトに対して発行される必要があります。

- ジョブ・セットはサブリクエストに対してサポートされていません。サブリクエストはJobDefinitionオブジェクトに対してのみ発行できます。ただし、実行中の任意のジョブ(ジョブ・セットに含まれる場合があります)によって、サブリクエストを発行できます。

これらの制限によってサブリクエストの実行が簡略化され、発行元のリクエスト自体を実行する場合の混乱や遅延が回避されます。

Oracle Enterprise Schedulerには様々な親リクエストが存在しますが、この章の説明においては、親リクエストはサブリクエストを発行するリクエストのことを指します。

サブリクエストは、標準的な1回かぎりのリクエストの通常フローに従います。ただし、サブリクエストの処理は、親リクエストがその実行を一時停止した場合にのみ開始されます。これを示すために、Oracle Enterprise Schedulerでは、PAUSED状態が使用されます。この状態は、親リクエストが一時停止され、サブリクエストの終了を待機していることを意味します。

親リクエストによりサブリクエストが発行された後、この親リクエストはそのジョブ・タイプに適切な方法でコントロールをOracle Enterprise Schedulerに戻す必要があり、この状態は親リクエストが実行を一時停止したことを示します。次に、Oracle Enterprise Schedulerにより親の状態がPAUSEDに設定され、サブリクエストの処理が開始されます。サブリクエストの終了後、親リクエストは、適切なリクエスト・プロセッサによって取得されるまで、PAUSEDのままで準備完了キューに置かれます。その後、この親はRUNNING状態に設定され、再開されたリクエストとして再実行されます。

20.2 サブリクエストの作成と管理

- サブリクエストの発行方法

- サブリクエストの取消し方法

- サブリクエストの保留方法

- 複数のサブリクエストの発行方法

- 一時停止されたサブリクエストの管理方法

- サブリクエストの処理方法

- サブリクエストの識別方法

- サブリクエストと非互換性の管理方法

20.2.1 サブリクエストの発行方法

サブリクエストは、submitRequest APIをコールすることにより発行できます。サブリクエストはWAIT状態に設定されますが、親リクエストが実行中の間は、Oracle Enterprise Schedulerによりこのリクエストが処理されることはありません。親リクエストが一時停止された後にのみ、サブリクエストを処理できます。

20.2.2 サブリクエストの取消し方法

サブリクエストを取り消す方法は主に2つあり、ユーザーがサブリクエストを直接取り消すか、または親リクエストを取り消すことによって結果的に取り消します。いずれの方法の場合でも、サブリクエストの取消しプロセスは、他の実行可能なリクエストと同じ方法で処理されます。異なる点は、保留中のサブリクエストがすべて完了して終了状態に到達した後に、親リクエストがOracle Enterprise Schedulerで処理される方法です。

Oracle Enterprise Schedulerにより、WAITまたはREADY状態にあるサブリクエストが、直接CANCELLEDに設定されます。サブリクエストが現在実行中である場合、そのサブリクエストはCANCELLINGに設定され、次に、Oracle Enterprise Schedulerにより、そのジョブ・タイプに適切な方法で、実行中の実行可能ファイルの取消しが試行されます。通常、サブリクエストはCANCELLED状態で終了しますが、そのサブリクエストがライフ・サイクルのどのステージに位置するかによって、他の終了状態で終了する場合があります。親リクエストは、すべてのサブリクエストが終了状態に到達するまで、PAUSEDまたはCANCELLING状態のままとなります。

ユーザーがサブリクエストを取り消すと、前述のように、Oracle Enterprise Schedulerによりそのサブリクエストが取り消されます。親リクエストは、すべてのサブリクエストが完了し、その時点でOracle Enterprise Schedulerにより親リクエストが再開または再起動されるまで、PAUSED状態のままとなります。これにより、親リクエストはサブリクエストの完了を、取り消されたものとするなどして、適切な方法で処理できます。したがって、サブリクエストの取消しが上位に伝播されることはありません。

ユーザーが親リクエストを取り消すと、Oracle Enterprise Schedulerによって親リクエストがCANCELLING状態に設定され、次に、前述の方法で、すべての保留中のサブリクエストに対する取消しが開始されます。すべてのサブリクエストが完了した後、親リクエストは、Oracle Enterprise SchedulerによりCANCELLEDに設定され、再開されません。親リクエストの取消しは、そのサブリクエストに伝播されます。

20.2.3 サブリクエストの保留方法

サブリクエストのライフ・サイクルは通常のリクエストのライフ・サイクルと同じであり、WAITまたはREADY状態である場合、保留にできます。親リクエストは、サブリクエストが保留になっている間、PAUSED状態のままとなります。

20.2.4 複数のサブリクエストの発行方法

Oracle Enterprise Schedulerを使用すると、リクエストにより複数のサブリクエストを発行できます。実行中のリクエストにより複数のサブリクエストが発行される場合があります。これらすべてのサブリクエストは、親リクエストが一時停止してPAUSED状態になると、Oracle Enterprise Schedulerによって処理されます。

このような複数のサブリクエストの場合、親リクエストは、すべてのサブリクエストが終了した場合にのみ再開されます。

また、サブリクエストは、任意の深さまで発行することもできます。これにより、ネストされたサブリクエストが作成されます。したがって、このようなサブリクエストの発行の深さについて制限はありません。これは、スタックのプッシュ操作とポップ操作に似ています。

20.2.5 一時停止されたサブリクエストの管理方法

- 一時停止ステータスの指定

- 親リクエストの一時停止状態の格納

20.2.5.1 一時停止ステータスの指定

Java実行可能ファイルにより、RuntimeService.submitRequestを使用してサブリクエストを発行できます。サブリクエストが発行された後、親リクエストは、サブリクエストを処理できるようにするために一時停止することを、Oracle Enterprise Schedulerに示す必要があります。これは、リクエストをPAUSED状態に遷移させるExecutionPausedExcpetionをスローする親によって実行されます。サブリクエストが完了した後、親リクエストは再開されたリクエストとして再度実行されます。RequestExecutionContextを使用すると、実行可能ファイルが再開されたリクエストとして実行中かどうかを判別できます。

20.2.5.2 親リクエストの一時停止状態の格納

ジョブ実行がサブリクエストの発行後に一時停止すると、実装において実行スレッドを一時停止するという概念がないため、Oracle Enterprise Schedulerでは、その実行があらゆる意味で完了したとみなされます。したがって、このような一時停止されたジョブを再開するには、Oracle Enterprise Schedulerによってジョブを再起動する必要があります。このような場合、実行が一時停止された時点から動作を続行することが必要であるのに対し、ジョブ実行は最初から再起動されます。これにより、ジョブ実行において、一時停止された時点を表すなんらかの実行状態を格納することが必要となります。再開したとき、ジョブはこのような状態を取得して一時停止された時点に移動し、ここから続行できます。

通常、ビジネス・ロジック全体における一時停止されたそれぞれの時点から、確定的な方法でジョブを再開できるようにするための実行状態は、個々のジョブで定義する必要があります(ジョブが一時停止された時点は複数存在する可能性があります)。これには、ステップ番号を格納して、再開時にその特定のステップに移動するという簡単な場合と、一時停止時にビジネス・ロジックにとって重要な状態を大規模なデータ・セットに格納する場合があります。Oracle Enterprise Schedulerでは、状態全体を格納するための完全なソリューションまたはフレームワークは提供できません。

Oracle Enterprise Schedulerでは、ジョブがその一時停止された時点を文字列の形式で格納するための簡易的な方法を提供しており、この文字列は、親ジョブがその実行を一時停止するときに指定できます。親ジョブが再開するとき、親では、必要に応じて使用するために、一時停止状態の値を取得できます。

Javaジョブにより、一時停止状態文字列を特別なExecutionPausedExceptionコンストラクタを使用して指定できます。状態パラメータは、親リクエストがPAUSED状態に設定されたときにOracle Enterprise Schedulerによって保存された一時停止状態文字列を表します。

public ExecutionPausedException(String message, String state)

再開された親は、親実行可能ファイルに渡されたRequestExecutionContextに対してgetPausedState()をコールすることにより、一時停止状態の値を取得できます。

単一の文字列値では不十分な場合は、親ジョブにより、setRequestParameter()を使用して任意の数のプロパティをOracle Enterprise Schedulerに書き込むことができ、再開時にはgetRequestParameter()を使用してこれらのプロパティを取得できます。

20.2.6 サブリクエストの処理方法

サブリクエストが発行されると、Oracle Enterprise Schedulerによりリクエストの状態がWAITに設定されますが、遅延モードでは、親リクエストが一時停止するまでディスパッチされません。

Javaジョブの親リクエストは、ExecutionPausedExceptionをスローすることによって、サブリクエストを処理する準備が整ったことを示します。Oracle Enterprise Schedulerでは、このような例外を受信すると、親リクエストの状態をPAUSEDに設定し、親が一時停止したという内容のシステム・イベント・メッセージを発行した後、その親に対する待機中のすべてのサブリクエストを準備完了キューにディスパッチします。

サブリクエストは、Oracle Enterprise Scheduler内の通常のライフ・サイクルに従って実行されます。指定された親リクエストのすべてのサブリクエストが終了した後、親リクエストを再開できます。

親の再開する準備が整うと、Oracle Enterprise Schedulerによって、親リクエストは準備完了キューに置かれます。親の状態は、取得を待機している間はPAUSEDのままとなります。Oracle Enterprise Schedulerにより親リクエストが準備完了キューから取得された後、リクエストの状態はRUNNINGに設定され、リクエストの実行可能ファイルは再開されたリクエストとしてコールされます。

サブリクエストが発行されることなくリクエストが一時停止された場合は、すべてのサブリクエストが終了したものとして処理されます。つまり、これはPAUSED状態で準備完了キューに置かれ、再開されたリクエストとして処理するために取得されます。

サブリクエストの最終状態は、その親実行可能ファイルが完了した後にOracle Enterprise Schedulerが親リクエストを処理する方法、および親リクエストの最終状態には影響を及ぼしません。親リクエストが再開すると、親リクエストのジョブ・ロジックはサブリクエストに関する情報を取得できるようになり、このデータを必要に応じて使用して、後続のアクションを決定します。親リクエストの最終状態は、親リクエストが完了した状態(成功、エラー、警告または取消し)のみに基づきます。

20.2.7 サブリクエストの識別方法

Oracle Enterprise Schedulerでは、リクエストごとにRequestType属性が含まれています。この属性は、リクエストがシングルトン、ジョブ・セットの一部、再帰リクエスト、サブリクエストなどのいずれかであるかを示します。

サブリクエストのRequestTypeは、SUB_REQUESTまたはUNVALIDATED_SUB_REQUESTです。UNVALIDATED_SUB_REQUESTは、Oracle Enterprise SchedulerのPL/SQLインタフェースを使用して発行されたが、まだ検証されていないサブリクエストを表します。親リクエストのRequestTypeは、SINGLETON、RECUR_CHILD、JOBSET_STEPまたはSUBREQUESTのいずれかです。その他すべてのリクエスト・タイプは、サブリクエストの親になることができないリクエストを表します。

サブリクエストに対する親リクエストのID属性は、そのサブリクエストを発行したリクエストです。

20.2.8 サブリクエストと非互換性の管理方法

通常、リクエストがREADYからRUNNING状態に遷移する場合、リクエストにより非互換性ロックが取得されます。これらのロックは、リクエストが終了して終了状態(SUCCEEDED、ERROR、WARNING、CANCELLEDなど)になるまで解放されません。

サブリクエストの親によって取得された非互換性ロックは、親リクエストがPAUSED状態の間も引き続き有効です。サブリクエストの親によってブロックされたリクエストはどれも、サブリクエストが実行される間、および親リクエストが再開されて終了するまでブロックされたままとなります。

サブリクエストは非互換性のすべてのルールに従います。したがって、Oracle Enterprise Schedulerでサブリクエストを実行する準備が整っているときに、互換性のない任意のリクエストが現在実行中である場合は、サブリクエストがブロックされることがあります。このような時間ウィンドウでは、親リクエストはPAUSED状態のままとなり、一方、サブリクエストはBLOCKED状態に遷移します。

20.3 サブリクエストを発行するJavaプロシージャの作成

これは、サブリクエストを発行するJavaジョブ・タイプのJavaクラスの例です。プロシージャによって2つのサブリクエストが発行され、それぞれの間に一時停止します。各サブリクエストでは同じJobDefinitionが使用されますが、リクエスト・パラメータSubRequestDataには異なる値が指定されます。

親リクエストのoracle.as.scheduler.Executable.executeメソッドは、指定されたOracle Enterprise Schedulerリクエストに対して合計3回コールされ、それぞれのコールに対する条件とアクションは、次のサマリーに示すように想定されます。

再開されないリクエストとしてメソッドを実行する最初のコールは、次のようになります。

エントリ条件:

- RequestExecutionContext.isResumed()はfalseです

- RequestExecutionContext.getPausedState()はnullです

メソッドのアクション:

- リクエスト・パラメータ値MyData1を使用したサブリクエストを発行します。

- 値がMyPausedState1のpausedStateを使用したExecutionPausedExceptionをスローします。

Oracle Enterprise Schedulerによって、リクエストがPAUSED状態に遷移し、サブリクエストが実行され、そのサブリクエストが完了した後、リクエストが再開されます。

再開されたリクエストとしてメソッドを実行する最初のコールは、次のようになります。

エントリ条件:

- RequestExecutionContext.isResumed()はtrueです

- RequestExecutionContext.getPausedState()は'MyPausedState1'です

メソッドのアクション:

- リクエスト・パラメータ値MyData2を使用したサブリクエストを発行します。

- 値がMyPausedState2のpausedStateを使用したExecutionPausedExceptionをスローします。

Oracle Enterprise Schedulerによって、リクエストがPAUSED状態に遷移し、サブリクエストが実行され、そのサブリクエストが完了した後、リクエストが再開されます。

再開されたリクエストとしてメソッドを実行する2回目のコールは、次のようになります。

エントリ条件:

- RequestExecutionContext.isResumed()はtrueです

- RequestExecutionContext.getPausedState()は'MyPausedState2'です

メソッドのアクション:

- 正常に終了し、例外は発生しません。

Oracle Enterprise Schedulerによって、リクエストがSUCCEEDED状態に遷移します。

例20-1に、サブリクエストを含むJavaプロシージャを示します。

例20-1 サブリクエストを含むJavaプロシージャ

// constants for the pausedState values
private final static String PAUSED_STATE_1 = "MyPausedState1";
private final static String PAUSED_STATE_2 = "MyPausedState2";

public class SubRequestSubmittor implements Executable {

// method called by Oracle Enterprise Scheduler when the request is executed
public void execute( RequestExecutionContext execCtx,
RequestParameters props )
throws     ExecutionWarningException,
ExecutionErrorException,
ExecutionPausedException,
ExecutionCancelledException {

long requestId =     execCtx.getRequestId();
boolean isResumed =  execCtx.isResumed();
String pausedState = execCtx.getPausedState();

if (!isResumed) {

// Method being called for first time, as non-resumed request.
// Submit first subrequest.
submitSubRequest(execCtx, "MyData1");
throw new ExecutionPausedException("first subrequest", PAUSED_STATE_1);

} else if (PAUSED_STATE_1.equals(pausedState)) {

// Method being called for a resumed request.
// Submit next subrequest.
submitSubRequest(execCtx, "MyData2");
throw new
ExecutionPausedException("second subrequest", PAUSED_STATE_2);

} else if (PAUSED_STATE_2.equals(pausedState)) {

// Method being called for a resumed request.
// All done, just return.

} else {

// Method being called for a resumed request.
// Unknown paused state (should never happen).
String msg = "Request " + requestId +
" was resumed with unexpected pause state " + pausedState;
throw new ExecutionErrorException(msg);

}
}

// Submit subrequest with request parameter having the given value.
private void submitSubRequest( RequestExecutionContext execCtx,
String paramValue )
throws ExecutionErrorException{

RuntimeService        rs = null;
RuntimeServiceHandle  rh = null;

try {
rs = getRuntimeService();

// Retrieve MetadataObjectId of the subrequest job definition
String jobDef = "MySubRequestJobDef";
MetadataObjectId jobDefId = getJobDefinition(jobDef);

// Set value for the request parameter used by subrequest.
RequestParameters rp = new RequestParameters();
rp.add("SubRequestData", paramValue);

// Submit the subrequest
rh = rs.open();

long subReqId = rs.submitRequest(rh,  execCtx,
"subrequest submitter",
jobDefId, rp);

} catch (Exception e) {

String msg = "Error while submitting subrequest for request " +
ExecCtx.getRequestId();
throw new ExecutionErrorException(msg, e);

} finally {

if (null != rh) {
try {
rs.close(rh);
} catch (Exception e) {
String msg = "Error while submitting subrequest for request "
+ ExecCtx.getRequestId();
throw new ExecutionErrorException(msg, e);
}
}
}
}

// Get RuntimeService.
private RuntimeService getRuntime()
throws ExecutionErrorException {
// implementation not shown
}

// Retrieve MetadataObjectId for a given job definition name.
private MetadataObjectId getJobDefinition( String jobDef )
throws ExecutionErrorException {
// implementation not shown
}

}

20.4 サブリクエストを発行するPL/SQLプロシージャの作成

ESS_RUNTIME PL/SQLパッケージは、サブリクエストを発行するために、SQLジョブ・リクエストによって使用されます。これには、リクエストのプロシージャが再開されたリクエストとして実行されているかどうかの判別、および一時停止状態文字列の取得のためのサポートも含まれています。

Javaリクエストの場合、親リクエストがRuntimeService.submitRequestメソッドを使用してサブリクエストを発行し、その後、サブリクエストを実行できるように親リクエストが一時停止する準備が整うと、ExecutionPausedExceptionをスローします。

SQLリクエストの場合は、サブリクエストを発行するために、ess_runtime.submit_subrequestが使用されます。親リクエストは、サブリクエストの実行準備が整ったとき、ess_runtime.mark_pausedをコールし、遷移をコミットして、例外を発生させることなく正常に返す必要があります。mark_pausedメソッドは、親リクエストのプロシージャから正常に返されると、親リクエストをPAUSEDに設定してサブリクエストを実行できるようにする必要があることをOracle Enterprise Schedulerに通知します。mark_pausedメソッドでは、オプションの引数がサポートされており、この引数を使用して、一時停止状態文字列を指定できます。

サブリクエストは、親リクエストが例外を発生させることなくmark_pausedをコールし、コミットして、正常に返されるまで実行されることに注意してください。例外が発生した場合、Oracle Enterprise Schedulerでは親リクエストをPAUSED状態に設定せず、かわりに、SQLエラー・コードに応じて親の状態がERRORまたはWARNINGに設定されます。さらに、サブリクエストは自動的にCANCELLEDとなり、実行されません。

サブリクエストが終了した後、親リクエストのPL/SQLプロシージャは、Java実行可能ファイルのときと同じように、再開されたリクエストとして再実行されます。

Java実行可能ファイルの場合、RequestExecutionContextはリクエストが再開中かどうかを示し、親リクエストが一時停止したときにスローされるExecutionPausedExceptionを使用して指定された、一時停止状態文字列も示します。

SQLリクエストの場合、ess_runtime.is_resumedは、リクエストのプロシージャが再開されたリクエストに対して実行中であるかどうかを示します。メソッドess_runtime.get_paused_stateは、リクエストが一時停止された場合、ess_runtime.mark_pausedプロシージャを使用して指定された一時停止状態文字列を返します。

これは、ESS_RUNTIMEパッケージを使用してサブリクエストを発行するSQLジョブ・タイプのPL/SQLストアド・プロシージャの例です。プロシージャによって2つのサブリクエストが発行され、それぞれの間に一時停止します。各サブリクエストでは同じJobDefinitionが使用されますが、リクエスト・パラメータSubRequestDataには異なる値が指定されます。PL/SQLストアド・プロシージャは、指定されたOracle Enterprise Schedulerリクエストに対して合計3回コールされ、それぞれのコールに対する条件とアクションは、次のサマリーに示すように想定されます。

再開されないリクエストとしてのプロシージャへの最初のコールは、次のようになります。

エントリ条件:

- ess_runtime.is_resumedはfalseです。

- ess_runtime.get_paused_stateはnullです。

プロシージャのアクション:

- リクエスト・パラメータ値MyData1を使用したサブリクエストを発行します。

- 一時停止状態を示すMyPausedState1を使用して、一時停止としてマークされます。

- 正常に終了し、例外は発生しません。

Oracle Enterprise Schedulerによって、リクエストがPAUSED状態に遷移し、サブリクエストが実行され、そのサブリクエストが完了した後、リクエストが再開されます。

再開されたリクエストとしてのプロシージャへの最初のコールは、次のようになります。

エントリ条件:

- ess_runtime.is_resumedはtrueです。

- ess_runtime.get_paused_stateは'MyPausedState1'です。

プロシージャのアクション:

- リクエスト・パラメータ値MyData2を使用したサブリクエストを発行します。

- 一時停止状態を示すMyPausedState2を使用して、一時停止としてマークされます。

- 正常に終了し、例外は発生しません。

Oracle Enterprise Schedulerによって、リクエストがPAUSED状態に遷移し、サブリクエストが実行され、そのサブリクエストが完了した後、リクエストが再開されます。

再開されたリクエストとしてのプロシージャへの2回目のコールは、次のようになります。

エントリ条件:

- ess_runtime.is_resumedはtrueです。

- ess_runtime.get_paused_stateは'MyPausedState2'です。

プロシージャのアクション:

- 正常に終了し、例外は発生しません。

Oracle Enterprise Schedulerによって、リクエストがSUCCEEDED状態に遷移します。

例20-2に、サブリクエストを含むPL/SQLプロシージャを示します。

例20-2 サブリクエストを含むPL/SQLプロシージャ

-- Application stored procedure.
procedure plsql_subreq_sample
( request_handle in varchar2 )
is
v_reqid  number;
v_is_resumed  boolean;
v_paused_str  varchar2(100);
v_paused_state1  varchar2(100) := 'MyPausedState1';
v_paused_state2  varchar2(100) := 'MyPausedState2';
begin
-- Request id of this subrequest parent.
v_reqid := ess_runtime.get_request_id(request_handle);

-- Check is this is a resumed request
v_is_resumed := ess_runtime.is_resumed(request_handle);

if (v_is_resumed = false) then
-- This parent request is being run for the first time.
-- Submit a subrequest and exit as success to allow ESS to pause this parent.
submit_subrequest(request_handle, v_paused_state1, 'MyData1');
else
-- Parent is being run as resumed request.
v_paused_str := ess_runtime.get_paused_state(v_reqid);
if (v_paused_state1 = v_paused_str) then
-- Request being resumed after first pause.
-- Submit a subrequest and exit as success to allow ESS to pause this parent.
submit_subrequest(request_handle, v_paused_state2, 'MyData2');
elsif (v_paused_state2 = v_paused_str) then
-- Request being resumed after second pause.
-- Parent is done. Just return as success.
null;
end if;
end if;
end;

-- Helper procedure to submit subrequest and call mark_paused.
-- Caller should exit normally, without an error, to allow
-- ESS mid-tier to pause the parent and execute the sub-request.
procedure submit_subrequest
( request_handle in varchar2,
paused_state_value in varchar2,
reqprop_value in varchar2 )
is
v_sub_reqid  number := null;
v_req_props  ess_runtime.request_prop_table_t := null;
v_idx  pls_integer := 0;
begin
v_req_props := ess_runtime.request_prop_table_t();
v_idx := 0;

v_idx := v_idx + 1;
v_req_props.extend;
v_req_props(v_idx).prop_name := 'SubRequestData';
v_req_props(v_idx).prop_datatype := ess_runtime.STRING_DATATYPE;
v_req_props(v_idx).prop_value := reqprop_value;

-- Must commit or rollback work done in this block.
begin
-- Submit the subrequest.
v_sub_reqid := ess_runtime.submit_subrequest(
request_handle => request_handle,
definition_name => 'sampleJob',
definition_package => 'samplePkg',
props => v_req_props);

-- Indicate that the parent request should pause.
-- The actual state change does not occur until ESS is notififed
-- that this run of the parent executable finished.
ess_runtime.mark_paused(request_handle, paused_state_value);

-- This procedure is responsible for the txn commit.
commit;
exception
-- Rollback txn on failure and raise an error.
rollback;
raise_application_error(-20000,
'Error submitting sub-request. '||
'SQLCODE='||SQLCODE || ', SQLERRM=['||SQLERRM||']',
true);
end;
end;
end;

21 非同期Javaジョブの使用

この章では、Javaコードを起動する、長時間実行されるジョブ、またはコンテナ管理でないジョブをサポートするために、Oracle Enterprise Schedulerを使用して非同期Javaジョブを起動する方法について説明します。

この章の内容は次のとおりです。

- 非同期Javaジョブの使用の概要

- 非同期Javaジョブの作成

- 非同期ジョブとしてのBPELプロセスの実装を示すユースケース

- 非同期ジョブを使用したBPELの実装方法

- 非同期ジョブのタイムアウトおよびリカバリの処理

- Oracle Enterprise Schedulerのインタフェースとクラス

21.1 非同期Javaジョブの使用の概要

通常、Oracle Enterprise SchedulerのJavaジョブ・リクエストは、Oracle WebLogic Server内部の専用スレッドで実行されますが、長時間実行されるJavaジョブ・リクエスト、またはコンテナ管理でないJavaジョブ・リクエストを発行する機能が必要となる場合があります。

Oracle Enterprise Schedulerでは、次の特徴を持つ非同期Javaジョブの起動がサポートされています。

- Oracle Enterprise Schedulerのユーザーの視点から見ると、非同期Javaジョブの起動をスケジュールする場合に差異はありません。

- Oracle Enterprise Schedulerの観点からは、非同期Javaジョブの起動ジョブ・リクエストは、発行されるとキューに追加され、実行後はすぐに戻ります(ジョブ・リクエストはRUNNING状態になります)。Oracle Enterprise Schedulerは、後処理を適用またはジョブを完了できるようになった時点でジョブから応答があるまで、操作を続行します。

- 非同期Javaジョブを使用すると、Oracle Enterprise Scheduler外部の様々な外部ジョブを開始できます。外部ジョブまたは外部ジョブを管理するエンティティでは、ジョブのステータスをOracle Enterprise Schedulerに通知する必要があります。

21.2 非同期Javaジョブの作成

Oracle Enterprise Schedulerの非同期Javaジョブは、Oracle Enterprise Schedulerのジョブ・リクエストと外部メカニズムで構成されています。Oracle Enterprise Schedulerのジョブ・リクエストは、標準のOracle Enterprise SchedulerのJavaジョブ・リクエストと同様に実装されますが、標準のOracle Enterprise Schedulerリクエストとは異なり、シナリオによっては非同期Javaジョブ・リクエストによる作業が行われない場合があります。

非同期Javaジョブ・リクエストの目的は、外部メカニズムをトリガーすることのみです。外部メカニズムはペイロード(データベースのモニタリングや円周率の計算など、存続期間が長いプロセス)を実行しますが、Oracle Enterprise SchedulerのJavaジョブを実行するスレッドとは分離可能である必要があります。外部メカニズムとしてSOAコンポジット(BPEL)を使用したり、Oracle ADFビジネス・コンポーネントの非同期Webサービス、別のスレッド、JVM、マシンまたは他のメカニズムを使用できます。外部メカニズムとクライアント・アプリケーションの間の通信方法は、ジョブ所有者によって決定されます。ただし、非同期Javaジョブで重要なのは、非同期ジョブを表す物理的なJavaオブジェクトへのポインタが、Oracle Enterprise Schedulerのメモリーに格納されないということです。この理由は次のとおりです。

- ジョブが実行される時間が不確定であり、このハンドルをキャッシュすると、リソースが無駄に消費されるため。

- 存続期間が長いジョブは、コンテナの再起動後まで継続可能である必要があるため。このオブジェクトはキャッシュされず、ガベージ・コレクションされる可能性が高いため、ジョブはステートレスである必要があり、ジョブ・リクエストとそれらを実行している外部メカニズムとの間の相関は、その発行元アプリケーションが保持する必要があります。Oracle Enterprise Schedulerでは、この理由に対するジョブ・リクエストIDとジョブ・リクエスト・ハンドルが提供されています。この情報は、再起動後まで継続可能にするために、維持する必要があります。

21.2.1 非同期Javaジョブの非同期インタフェースの実装

非同期Javaジョブの起動には、AsyncExecutableインタフェースの実装が必要です。

21.2.2 非同期Javaジョブのexecute()メソッド

非同期Javaジョブのexecute()メソッドの役割は、実際の作業が実行される外部メカニズムを設定することです。このメソッドは、外部メカニズムを開始した後、戻ります。非同期Javaジョブの起動execute()メソッドでは、実際の作業は実行できません。executeメソッドの実行中に例外がスローされ、ジョブの初期化中に問題が発生して実行に失敗したことがOracle Enterprise Schedulerに通知される場合があります。executeメソッドの実行中の例外によって、Oracle Enterprise Schedulerに対して、外部メカニズムで実行中の実際の作業に問題が発生したと通知されることはありません。Oracle Enterprise Schedulerでは、例外が捕捉された場合は後続の処理を行わないため、開始または使用された可能性のあるリソースが解放されていることを、ジョブ所有者が確認する必要があります。例外がスローされない場合、Oracle Enterprise Schedulerによってジョブが実行状態になり、ガベージ・コレクションできるように、ジョブのオブジェクトのハンドルが解放されます。

21.2.3 非同期Javaジョブからのリモート・ジョブの起動

外部Webサービスを起動する非同期Javaジョブにより、WebサービスAddressingヘッダーを設定して、リモート・ジョブの作業を簡略化できます。

相関

WSA messageIDヘッダーを使用して、レスポンス・メッセージをリクエストに関連付けます。Oracle Enterprise Schedulerでは、メソッドRequestExecutionContext.getIdStringが提供されており、このメソッドにより、WSA messageIDヘッダーの値に使用されるIDが返されます。

返信Addressing

WSA ReplyToおよびFaultToヘッダーは、Oracle Enterprise Schedulerの汎用コールバック・サービスへの直接返信に使用できます。Oracle Enterprise Schedulerの汎用コールバック・サービス・アドレスは、Oracle Enterprise Schedulerインスタンス・ホーム・ページ(http://host:port/ess/)のWebServices WSDL URLリンクを使用すると取得できます。

21.2.4 ステータス更新を伴うOracle Enterprise Schedulerへのコールバック

Oracle Enterprise Schedulerでは、非同期コールバックのWebサービス操作setAsyncRequestStatusが提供されています(例21-15のインタフェースを参照)。これには、ステータスやステータス・メッセージなどの入力情報、および明示的に指定する相関情報が必要です。

Oracle Enterprise Schedulerでは、別のメカニズム、つまり、非同期コールバックのための汎用のJava Required Files Webサービス・プロバイダが提供されています。このWebサービス・プロバイダではあらゆるタイプのペイロードが受け入れられ、メッセージはSOAPMessageオブジェクトとして配信されます。メッセージをリクエストに関連付けるために、WSA relatesToヘッダーが抽出されます。このヘッダーに、元のリクエストのWSA messageIDヘッダーが移入されます。Actionヘッダーは、レスポンスが非同期ジョブの完了とフォルトのいずれに起因するかを決定するのに使用します。

レスポンスがフォルトに起因する場合、非同期ジョブのリクエスト・ステータスは、一時的にERRORに設定されます。レスポンスが非同期ジョブの正常完了に起因する場合、非同期ジョブのリクエスト・ステータスは、一時的にSUCCESSに設定されます。SOAPMessage本文が抽出され、Updatable.onEventメソッドに渡される文字列に変換されます。

Webサービス・プロバイダのアドレスは、http://host:port/ess-async/essasynccallback.です。

21.2.5 非同期Javaジョブの更新

Oracle Enterprise Schedulerでは、インタフェースoracle.as.scheduler.Updatableが提供されており、このメソッドを使用すると、アプリケーション・コードで開始された更新イベントをジョブ・リクエストで受信できます。ジョブ・リクエストが更新されると、Oracle Enterprise Schedulerにより、クライアント・クラスにUpdatableインタフェースを実装するかどうかが決定されます。クライアント・クラスにUpdatableインタフェースを実装する場合、ホスティング・アプリケーションのMDBのコンテキストでジョブ・クラスの新規オブジェクトがインスタンス化され、onEventメソッドがコールされます。このメソッドでは、Webサービスの起動により決定されたリクエスト・ステータス、およびジョブに認識されるフォーマットで情報を表した文字列(Oracle Enterprise Scheduler WebサービスからのSOAPMessage本文など)を使用します。このメソッドでは、情報のログへの記録などの処理が実行される場合があります。その後、ステータスおよびステータス・メッセージを含むUpdateActionオブジェクトが返されます。

リクエストの実行に関連するユーザーのコンテキストで、onEventに対するコールが発生します。

ジョブにUpdatableインタフェースが実装されていない場合、イベントはOracle Enterprise Schedulerへの非同期コールバックから決定されるステータスに基づいて処理されます。

Updatableインタフェースの詳細は、例21-12を参照してください。

21.2.6 非同期ジョブ完了時のOracle Enterprise Schedulerへの通知

非同期Javaジョブのexecute()メソッドが正常に起動され、ジョブ・リクエストが外部メカニズムで実行されている場合、Oracle Enterprise Schedulerでは、他のジョブの処理が続行されます。ジョブ・リクエストが完了したときまたはエラーが発生したときは、Oracle Enterprise Schedulerに通知する必要があります。この通信チャネルは、外部メカニズムの担当です。

21.2.6.1 非同期ジョブ完了時のWebサービスを使用した通知

Oracle Enterprise SchedulerのWebサービス操作setAsyncRequestStatusを起動すると、これにより、非同期リクエストのステータスおよび関連情報が設定されます。この操作に関連して、次の情報が必要となります。

setAsyncRequestStatus(String requestExecutionContext, AsyncStatus status, String statusMessage)

内容は次のとおりです。

- requestExecutionContextは、開始イベントの一部として渡す必要がある文字列です。このパラメータは、Oracle Enterprise SchedulerジョブのRequestExecutionContextオブジェクトから導出されます。

- statusはSUCCESS、ERROR、WARNING、PAUSE、CANCEL、BIZ_ERRORまたはUPDATEのいずれかです。

- statusMessageは次のとおりです。

- ステータスがERRORまたはBIZ_ERRORの場合は、エラー・メッセージとなります。

- ステータスがWARNINGの場合は、警告メッセージとなります。

- ステータスがPAUSEDの場合は、一時停止状態となります。

- ステータスがUPDATEの場合は、定義してジョブにより適宜解析したカスタマイズ済文字列となります。

- ステータスがSUCCESSまたはCANCELの場合、値は無視されます。

WebアプリケーションにおけるWebサービスの実装の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「WebサービスのFusion Webアプリケーションへの統合」および『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』のWebLogic Webサービスの保護と管理に関する項を参照してください。

21.2.6.2 非同期ジョブ完了時のEJBを使用した通知

外部メカニズムは、ローカルおよびリモートのEJBインタフェースを提供する非同期リクエストEJBを使用して、ステータスをOracle Enterprise Schedulerに通知できます。すべてのEJB参照をカプセル化するヘルパー・クラスが提供されています。このヘルパーは依存関係インジェクションを使用するため、コンテナ内部で使用されている場合にのみ動作します。ヘルパー・クラスには成功、エラー、警告および取消しを通知するためのメソッドが含まれています。次に、例を示します。

非同期リクエストBean: java:comp/env/essnative/asyncrequest

関連するメソッドを次に示します。

/**
* Set the status of an ESS asynchronous java job.
*
* @param context The <code>RequestExecutionContext</code> with which the
* request was started.
* @param status The status of the request.
* @param statusMessage An error message if the status is ERROR,
* a warning message if the status is WARNING,
* the paused state if the status is PAUSED.
* The value is ignored if the status is SUCCESS or CANCEL.
* @throws RequestNotFoundException If a request is not found for the
* <code>context</code>.
*/
public void setRequestStatus(String context,
String status,
String statusMessage)
throws RuntimeServiceException, RequestNotFoundException

21.2.7 非同期JavaジョブのAsyncCancellableインタフェース

ジョブを取消し可能にする場合は、AsyncCancellableインタフェースを実装する必要もあります。このインタフェースは、その取消しメソッドにより、当該ジョブに対してRequestExecutionContextとRequestParametersも提供される点で、通常の取消し可能なインタフェースとは異なります。指定されたコンテキストおよびパラメータを使用して、ペイロードを実行中の外部メカニズムを判別し、停止するよう要求する必要があります。(ジョブのAsyncCancellable.cancel()の実装ではなく)外部メカニズムにより、Oracle Enterprise Schedulerにジョブが取り消されたことが通知されます。

注意:

現在、実行中のOracle ADFビジネス・コンポーネントの非同期Webサービス・プロセスを終了する方法はありません。

21.2.8 イベント配信ネットワークを介してBPELプロセスを起動する非同期Javaジョブのサンプル

非同期リクエストを使用して、BPELプロセスをOracle Enterprise Schedulerから起動できます。Oracle Enterprise Schedulerの非同期Javaジョブを使用して、BPELプロセスを起動します。BPELプロセスが完了すると(成功したか、エラーや警告が発生したか、または取り消されたかどうかに関係なく)、BPELプロセスにより、Oracle Enterprise SchedulerのWebサービス操作を使用してOracle Enterprise Schedulerに通知されます。

BPELプロセスを起動するこの方法の手順は、次のとおりです。

1. Oracle Enterprise Schedulerの非同期Javaジョブを作成します。

2. BPELプロセスをOracle Enterprise SchedulerのJavaジョブから起動します。

3. BPELプロセスが完了したら、Oracle Enterprise Scheduler Webサービスに完了ステータスでコールバックします。Webサービス操作のメソッドを使用して、Oracle Enterprise Schedulerにリクエストの完了を通知します。詳細は、「非同期ジョブ完了時のWebサービスを使用した通知」を参照してください。

4. Oracle Enterprise Schedulerでは、完了情報の受信後、リクエストについて必要な後処理(必要に応じて)を完了します。

関連するWebサービスを直接起動したり、例21-1に示すように、BPELプロセスを起動することをイベント・メディエータに指示するイベントを公開したりできます。

例21-1 イベント・メディエータを介してBPELプロセスを起動するジョブ

import oracle.as.scheduler.RequestParameters;
import oracle.as.scheduler.ExecutionCancelledException;
import oracle.as.scheduler.ExecutionErrorException;
import oracle.as.scheduler.ExecutionPausedException;
import oracle.as.scheduler.ExecutionWarningException;
import oracle.as.scheduler.RequestExecutionContext;

import javax.xml.namespace.QName;
import oracle.fabric.blocks.event.BusinessEventConnection;
import oracle.fabric.blocks.event.BusinessEventConnectionFactory;
import oracle.fabric.common.BusinessEvent;
import oracle.integration.platform.blocks.event.BusinessEventBuilder;
import oracle.integration.platform.blocks.event.BusinessEventConnectionFactorySupport;
import oracle.xml.parser.v2.XMLDocument;
import org.w3c.dom.Element;

// Async imports
import oracle.as.scheduler.AsyncExecutable;
import oracle.as.scheduler.AsyncCancellable;

public class BPELJob implements AsyncExecutable, AsyncCancellable
{
public BPELJob() {
}

public void execute(RequestExecutionContext ctx, RequestParameters params)
throws ExecutionErrorException,
ExecutionWarningException,
ExecutionCancelledException,
ExecutionPausedException
{
// Publish an event to the Event Mediator
publishEvent(ctx.getRequestId() + "", ctx.toString(), "ESS_EVENT");
}

// Cancel

public void cancel (RequestExecutionContext ctx,
RequestParameters requestParams) {
publishEvent(ctx.getRequestId() + "", ctx.toString(), "CANCEL_ESS_EVENT");
return;
} // cancel

// Event publishing

private final String eventName = "ESSDemoEvent";
private final String eventElement = "ESSDemoEventElement";
private final String eventNamespace =
"http://xmlns.oracle.com/apps/ta/essdemo/events/edl";
private final String schemaNamespace =
"http://xmlns.oracle.com/apps/ta/essdemo/events/schema";

private XMLDocument buildEventPayload(String correlationId, String key, String
eventType) {
Element masterElem, childElem1, childElem2, childElem3;
XMLDocument document = new XMLDocument();
masterElem = document.createElementNS(schemaNamespace, eventElement);
document.appendChild(masterElem);
childElem1 = document.createElementNS(schemaNamespace, "requestId");
childElem1.appendChild(document.createTextNode(correlationId));
masterElem.appendChild(childElem1);
childElem2 = document.createElementNS(schemaNamespace,
"executionContext");
childElem2.appendChild(document.createTextNode(key));
masterElem.appendChild(childElem2);
childElem3 = document.createElementNS(schemaNamespace, "eventType");
childElem3.appendChild(document.createTextNode(eventType));
masterElem.appendChild(childElem3);
return document;
}

private void publishEvent(String correlationId, String key, String eventType)
throws ExecutionErrorException
{

try {
// Get event connection
BusinessEventConnectionFactory cf =
BusinessEventConnectionFactorySupport.
findRelevantBusinessEventConnectionFactory(true);

if (cf != null) {
BusinessEventConnection conn =
cf.createBusinessEventConnection();

//  Build event
BusinessEventBuilder builder =
BusinessEventBuilder.newInstance();

// Specify the event name and namespace. In this prototype,
// they are constants, eventNamespace, eventName
builder.setEventName(new QName(eventNamespace, eventName));

// Specify the event payload. In this prototype, the
// getXMLPayload custom method constructs the payload
builder.setBody(buildEventPayload(correlationId, key,
eventType).getDocumentElement());
BusinessEvent event = builder.createEvent();

//  Publish event
conn.publishEvent(event, 5);

// For debug only
System.out.println("Event was sent sucessfully");
} else {
// For debug only
System.out.println("cf is null");
}
} catch (Exception exp) {
String errorMsg = "Failed sending event for correlation ID " +                         correlationId);
exp.printStackTrace();
throw new ExecutionErrorException(errorMsg, exp);
}
} // publishEvent

21.2.8.1 Oracle Enterprise Schedulerを使用したBPELプロセスのデザインタイムのサンプル

非同期Javaジョブを使用して、BPELプロセスを実行できます。プロセスはイベントによって起動され、そのプロセスを起動したイベント・メディエータによって処理されます。例として、図21-1を参照してください。

- プロセスの実際の作業は、DoMyWorkモジュールで行われます。

- 作業が正常に完了すると、AssignAsyncSuccess/AsyncCallbackSUCCESSに制御が移行し、ステータスとしてSUCCESSが指定され、ステータス・メッセージが指定されずに、Oracle Enterprise SchedulerのWebサービス・コールバックが起動されます。

- Oracle Enterprise Schedulerのリクエストが取り消されると、Oracle Enterprise Schedulerジョブの取消しメソッドがコールされます。次に、ジョブ・オブジェクトにより、それを取り消す必要があることがリモート・ジョブに通知されます。取消しが成功すると、リモート・ジョブにより、コールバック・メカニズムを使用してOracle Enterprise Schedulerに通知され、ステータスがCANCELに設定されます。この場合、制御は右端にあるブランチに移行します。

- フォルトが発生した場合、制御は中間ブランチに移行します。AsyncCallbackERRORにより、ステータスERRORおよびフォルトからのエラー・メッセージを指定するOracle Enterprise SchedulerのWebサービス・コールバックが起動されます。AsyncCallbackCANCELにより、ステータスCANCELを指定する(ステータス・メッセージは指定されません)Oracle Enterprise SchedulerのWebサービス・コールバックが起動されます。

図21-1 非同期リクエストによってBPELプロセスをコールして返すJavaジョブ

BPELプロセスでは、AssignAsyncError割当てアクティビティについての図21-2、図21-3および図21-4に示すように、Oracle Enterprise Schedulerの非同期コールバックに対するWebサービス操作の値が必要です。

図21-2 statusMessage要素に対するAsyncCallBackError引数のマッピング

図21-3 requestExecutionContextに対するAsyncCallbackErrorの引数マッピング

図21-4 status要素に対するAsyncCallbackError引数のマッピング

21.3 非同期ジョブとしてのBPELプロセスの実装を示すユースケース

非同期ジョブとしてのBPELプロセスの実装のユースケースは、次のとおりです。

- ヒューマン・ワークフロー通知およびその他のSOA固有アクティビティを使用してタスクの承認を得ます。

- ジョブが完了したことをOracle Enterprise Schedulerに通知すると同時に、他のジョブを実行したりセット内の次のジョブに進むことができます。

デザイン・パターンのサマリー

Oracle Enterprise Schedulerの非同期ジョブはAsyncExecutableインタフェースを実装するJavaジョブであり、このインタフェースは、Oracle Enterprise Schedulerでexecute()メソッドを実装することによって起動されます。このメソッドを使用すると、execute()メソッドが完了する、長時間実行されるタスクやリモートのタスク(ビジネス・イベントの呼出しなど)を開始でき、その間、ジョブはOracle Enterprise SchedulerによってRUNNINGステータスに維持されます。リモート・タスクが完了すると、次のいずれかを実装することにより、ステータス・メッセージを使用してOracle Enterprise Schedulerにその完了が通知されます。

- RuntimeService EJB

- Oracle Enterprise SchedulerのWebサービスsetAsyncRequestStatus操作

このパターンでは、起動されるリモート・タスクが、非同期ジョブのexecute()メソッドでビジネス・イベントを呼び出すことによってトリガーされるBPELプロセスであることを前提としています。完了、エラーまたは取消しを経たプロセスの終了時に、BPELプロセスによってOracle Enterprise Scheduler Webサービスが起動され、ステータスが適宜設定されます。

関連コンポーネント

図21-5に、Oracle Enterprise Scheduler、SOAメディエータおよびBPELを示します。

図21-5 Oracle Enterprise Schedulerの非同期ジョブからのBPELコール

21.3.1 推奨されるデザイン・パターンの概要

ユースケースによっては、Oracle Enterprise SchedulerジョブによってBPELプロセスを双方向方式で起動して、他のジョブに進む前にこのBPELプロセスの完了を追跡する必要があります。Oracle Fusion ApplicationsでJavaコード(Oracle Enterprise SchedulerまたはOracle ADFビジネス・コンポーネント)から非同期Webサービスを起動することは禁止されているため、Oracle Enterprise Schedulerジョブによって非同期BPELプロセスを直接起動することはできず、非同期ジョブの実装タイプに依存する必要があります。

このアプローチはOracle Fusion Middlewareの既存の機能(イベントやBPELなど)を利用するため、お薦めします。

21.3.2 考えられるアプローチ

Oracle Enterprise Schedulerの非同期ジョブ機能のかわりに次のアプローチが考えられますが、許可されていません。

- JAX-WSプロキシを使用したOracle ADFビジネス・コンポーネントやBPELなどの非同期Webサービスの起動 - スレッドのブロックおよびコールバック・サービスがOracle Enterprise Schedulerで許可されていません。

- BPELをトリガーするビジネス・イベントの呼出し: BPELでOracle ADFビジネス・コンポーネント・サービスを起動し、そのADFビジネス・コンポーネント・サービスでRuntimeService EJBを起動してステータスを設定しますが、複雑でエラーが発生しやすい手順です。

21.3.3 ユースケース・サマリー

ある経費システムでは経費をインポートして処理するためのOracle Enterprise Schedulerジョブが定期的に実行され、この処理では、通知と承認にヒューマン・ワークフローを活用するために、BPELプロセスの発行が必要となります。このユースケースでは、Oracle Enterprise Schedulerジョブで経費と明細をインポートし、経費ごとに非同期BPEL機能をトリガーするサブリクエストを経費単位で発行します。このサブリクエストはOracle Enterprise Schedulerの非同期ジョブとして実装され、このジョブでは、ビジネス・イベントを呼び出してそのJava execute()メソッドを完了し、BPELの起動時には実行状態を継続してヒューマン・タスク通知を発行し、ユーザー操作の結果を待機します。この結果の取得後、BPELによって、この特定のサブリクエストが完了したことを通知するOracle Enterprise Scheduler Webサービスが起動されます。

21.4 非同期ジョブを使用したBPELの実装方法

BPELでOracle Enterprise Schedulerの非同期ジョブを実装するには、次の手順を実行する必要があります。

1. execute()とcancel()の各メソッドを記述して、AsyncExecutableとAsyncCancellableの各インタフェースを実装するOracle Enterprise SchedulerのJavaジョブを作成します。

2. Oracle Enterprise Schedulerの非同期ジョブ定義を作成します。

3. イベント・ペイロード・スキーマ(XSD)およびイベント定義(EDL)の各ファイルを設計します。

4. Oracle Enterprise Schedulerの非同期ジョブのexecute()および(必要に応じて)取消しメソッドから、ビジネス・イベントをプログラムによって呼び出します。

5. メディエータおよびBPELを使用してSOAコンポジットを設計します。

6. エラーに対してフォルト処理と相関onMessageブランチを追加し、ジョブ・ステータス更新を取り消します。

21.4.1 ユースケース: Oracle JDeveloperライブラリの追加

Oracle Enterprise Schedulerアプリケーションでは、アプリケーション・コアおよびEnterprise Scheduler ServiceのOracle JDeveloperライブラリを追加し、Oracle Enterprise SchedulerのAsyncExecutableとAsyncCancellableの両方のインタフェースを実装する、(標準に従って)適切なクラス・ネーミングとディレクトリ構造を使用して新規Javaクラスを作成するようにしてください。これらのインタフェースを両方ともインポートするには、例21-2に示すように、Oracle Enterprise Schedulerジョブの必要な動作を開始するためにOracle Enterprise SchedulerのRuntimeService Beanによって起動されるexecute()とcancel()の各メソッドを実装する必要があります。

例21-2 Oracle JDeveloperライブラリの追加

public class ASMEventAsyncJob implements AsyncExecutable, AsyncCancellable {
public ASMEventAsyncJob() {
super();
}

public void execute(RequestExecutionContext ctx, RequestParameters params)
throws ExecutionErrorException,
ExecutionWarningException,
ExecutionCancelledException,
ExecutionPausedException
{
publishEvent(ctx.getRequestId() + "", ctx.toString(), "ESS_EVENT");
return;

}

public void cancel (RequestExecutionContext ctx,
RequestParameters requestParams) {
publishEvent(ctx.getRequestId() + "", ctx.toString(), "CANCEL_ESS_EVENT");
return;
} // cancel

21.4.2 ユースケース: 非同期ジョブ定義の作成

Oracle Enterprise SchedulerのJDeveloperワークスペースで、「新規」をクリックし、Enterprise Scheduler Serviceのテクノロジ・グループを選択して「ジョブ定義」を選択します。図21-6に示すように、Oracle Enterprise Schedulerのジョブ定義の名前を入力して、指定されたJavaJobTypeを選択し、ステップ1で作成したクラスをこのジョブ定義に対してオーバーライドするJavaクラスとして選択します。

図21-6 「ジョブ定義の作成」

ここで、図21-7に示すように、このジョブ定義に対してオーバーライドするJavaクラスとして、ステップ1で開発したクラスを選択し、ユースケースの必要に応じてパラメータおよびアクセス制御を定義します。

図21-7 ジョブ・タイプが定義されたジョブ定義の作成

21.4.3 ユースケース: イベント・ペイロード・スキーマ・ファイルおよびイベント定義ファイルの設計

SOAコンポジット・デザイナには、ビジネス・イベントのペイロード定義(EDL)の設計に役立つUI機能がありますが、スキーマ(.xsd)を最初に設計する必要があります。例21-3に、サンプルのXSDファイルを示します。

ペイロードの要素タイプを完了したら、EDLを手動で作成するか、またはイベント定義ビルダーを使用できます。ビルダーを使用するには、SOAコンポジット・エディタを開き、図21-8に示すように、UIの上部にある稲妻ボタンをクリックして「イベント定義の作成」ウィンドウを開きます。

図21-8 「イベント定義の作成」

次に、名前およびネームスペースを割り当てて「追加」をクリックし、図21-9に示すように、この定義に新規イベントを追加します。

図21-9 「イベントの追加」

「OK」をクリックします。イベント定義サマリーに完成したイベント定義が表示されます。図21-10に示すように、要件の必要に応じて、さらにイベントを追加します。

図21-10 「イベント」リスト

例21-4に、作成されたEDLファイルのサンプルを示します。

例21-3 サンプルXSDファイル

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://xmlns.oracle.com/apps/ta/essdemo/events/schema"
targetNamespace="http://xmlns.oracle.com/apps/ta/essdemo/events/schema"
attributeFormDefault="unqualified"
elementFormDefault="qualified">
<xsd:element name="ESSDemoEventElement" type="ESSDemoEventElementType"/>
<xsd:complexType name="ESSDemoEventElementType">
<xsd:sequence>
<xsd:element name="requestId" type="xsd:string"/>
<xsd:element name="executionContext" type="xsd:string"/>
<xsd:element name="eventType" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>

</xsd:schema>

例21-4 EDLファイル

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<definitions xmlns="http://schemas.oracle.com/events/edl"
targetNamespace="http://xmlns.oracle.com/
AsyncEssDemoComposite/EventDefinition1">
<schema-import namespace="http://xmlns.oracle.com/singleString"
location="xsd/singleString.xsd"/>
<schema-import namespace="http://xmlns.oracle.com/apps/ta
/essdemo/events/schema"
location="xsd/ESSDemoEventSchema.xsd"/>
<event-definition name="ESSEvent">
<content xmlns:ns1="http://xmlns.oracle.com/apps/ta/essdemo/events/schema"
element="ns1:ESSDemoEventElement"/>
</event-definition>
</definitions>

21.4.4 非同期ジョブのメソッドからのビジネス・イベントのプログラムによる呼出し

Oracle Enterprise Schedulerの非同期ジョブから呼び出されたビジネス・イベントには、いずれのジョブが完了したか、取り消されたか、またはエラーが発生したかをBPELで示すために、リクエストの実行コンテキストのtoString()値が含まれている必要があります。Javaからのビジネス・イベントのプログラムによる呼出しについては、ビジネス・イベントを呼び出すJavaコードを記述する方法の仕様を含む、ADFからのSOAの起動に関する項で説明しています。呼び出されたこのビジネス・イベントをサブスクライブするSOAコンポジットを宣言して作成するには、イベント・スキーマ(.xsd)および定義(EDL)を設計する必要があります。Javaコードにより、このXML文書を最初から作成する必要があり、QName値(ペイロード構造における要素やネームスペースの属性など)と完全に一致する必要があります。

execute()メソッドは、Oracle Enterprise Schedulerによりジョブの実行が開始されるときに起動されますが、エンド・ユーザーまたは外部エンティティからOracle Enterprise Schedulerに実行中のジョブを取り消すよう指示があった場合は、Oracle Enterprise SchedulerによってジョブのステータスがCANCELLINGに設定され、cancel()メソッドが起動されます。両方のメソッドで、類似するペイロード・タイプやネームスペースを含むイベントが呼び出されるようにすることをお薦めします。これにより、相関セットを使用して進行中のBPELプロセスに取消しイベントを送信できるようにし、そのBPELプロセスで代替機能を実行してOracle Enterprise Scheduler Webサービスを起動し、ジョブ・ステータスをCANCELLEDに設定できるようにします。

このサンプルでは、イベント呼出しコードがOracle Enterprise Schedulerジョブのクラス・コードに配置されていますが、最適なアプローチはOracle ADFライブラリとしてコードを共有することであり、このプロジェクトにそのライブラリをインポートして公開コードの重複を減らすことができます。

(BPEL相関セットで進行中の取消しが許可されるように) requestIDおよび実行コンテキストのtoString()値を渡すイベント呼出しコードをコールするサンプル・コードを次に示します。

publishEvent(ctx.getRequestId() + "", ctx.toString(), "ESS_EVENT");

例21-5に、サンプルのイベント呼出しコードを示します。

例21-5 イベント呼出しコード

private final String eventElement = "ESSDemoEventElement";
private final String eventNamespace = "http://xmlns.oracle.com/apps/ta/essdemo/events/edl";
private final String schemaNamespace = "http://xmlns.oracle.com/apps/ta/essdemo/events/schema";

private XMLDocument buildEventPayload(String correlationId, String key, String
eventType) {
Element masterElem, childElem1, childElem2, childElem3;
XMLDocument document = new XMLDocument();
masterElem = document.createElementNS(schemaNamespace, eventElement);
document.appendChild(masterElem);
childElem1 = document.createElementNS(schemaNamespace, "requestId");
childElem1.appendChild(document.createTextNode(correlationId));
masterElem.appendChild(childElem1);
childElem2 = document.createElementNS(schemaNamespace,
"executionContext");
childElem2.appendChild(document.createTextNode(key));
masterElem.appendChild(childElem2);
childElem3 = document.createElementNS(schemaNamespace, "eventType");
childElem3.appendChild(document.createTextNode(eventType));
masterElem.appendChild(childElem3);
return document;
}

public void publishEvent(String correlationId, String key, String eventType)        throws ExecutionErrorException    {            // Determine whether we are outside of a JTA transaction            try {                 // Get event connection                 BusinessEventConnectionFactory cf =    BusinessEventConnectionFactorySupport.findRelevantBusinessEventConnectionFactory        (true);                  if (cf != null) {                     BusinessEventConnection conn =                             cf.createBusinessEventConnection();                      //  Build event                     BusinessEventBuilder builder =                             BusinessEventBuilder.newInstance();                      // Specify the event name and namespace. In this prototype,                     // they are constants, eventNamespace, eventName                     builder.setEventName(new QName(eventNamespace, eventName));                      // Specify the event payload. In this prototype, the                     // getXMLPayload custom method constructs the payload                     builder.setBody(buildEventPayload(correlationId, key,                             eventType).getDocumentElement());                     BusinessEvent event = builder.createEvent();                      //  Publish event                     conn.publishEvent(event, 5);                      // For debug only                     System.out.println("Event was sent sucessfully");                     conn.close();                 } else {                     // For debug only                     System.out.println("cf is null");                 }             } catch (Exception exp) {                 String errorMsg = "Failed sending event for correlation ID " +                             correlationId);                 exp.printStackTrace();                 throw new ExecutionErrorException(errorMsg);             }        } // publishEvent

21.4.5 メディエータおよびBPELを使用したSOAコンポジットの設計

このユースケースはBPEL機能によって異なるため、イベント・サブスクリプション用のメディエータを含むSOAコンポジットを作成する必要があり、これにより、ペイロードを変換してBPELプロセスを起動できます。

SOAワークスペースで、新規SOAコンポジットを作成します。このパターンに対してコンポジットを設定するには、Oracle Enterprise Schedulerで呼び出されたイベントをサブスクライブするメディエータを追加して、BPELプロセスに接続します。Oracle Enterprise Scheduler WebサービスWSDLにサービス参照を追加します。次に例を示します。

http://myhost.com:7001/ess/esswebservice?WSDL

1つ以上のネストされたスコープを使用して、BPELプロセスで必要な機能を引き続き作成します。機能は少なくとも1つのプライマリ・スコープ内に存在する必要があり、図21-11に示すように、このスコープでonMessageイベント(進行中の取消しメッセージの受信用)およびフォルト・ハンドラ・ブランチを追加できます。

図21-11 BPELおよびESSWebServiceを使用したコンポジット

Oracle Enterprise Scheduler Webサービスの起動の詳細は、「Oracle Enterprise Scheduler Webサービスの使用」を参照してください。

21.4.6 エラーに対するフォルト処理と相関onMessageブランチの追加およびジョブの取消し

Oracle Enterprise Schedulerでは、execute()メソッドのJavaコードが完了した後、Oracle Enterprise Schedulerの非同期ジョブのハートビートモニタリングは一切行われません。ジョブの発行後、リモート・ジョブ・コード、BPELまたはエンド・ユーザーがOracle Enterprise Schedulerを直接操作してそのジョブのステータスを設定するまで、RUNNING状態でOracle Enterprise Schedulerインフラストラクチャ内に存在します。このため、BPELプロセスの設計では、Oracle Enterprise Schedulerジョブの存続期間中に最もよく発生する、少なくとも2つのタイプのシナリオを処理するように、また、モニタリングUIにジョブの適切な状態を反映してエンド・ユーザーに示すために、できるかぎり状態情報をOracle Enterprise Schedulerに送信して戻すようにする必要があります。

BPEL処理の取消し

たとえば、モニタリングUIをエンド・ユーザーが操作してジョブの取消しをリクエストする場合、図21-12に示すように、Oracle Enterprise Schedulerでは、ジョブのステータスがCANCELLINGに更新され、リモート機能が整理されるのを待機して、ジョブが取り消されたことを確認します。

図21-12 BPEL処理の取消し

BPEL処理エラー

また、リモート機能で障害が発生した場合、この障害については、リモート機能(この場合にはBPEL)からOracle Enterprise Schedulerに通知する必要があり、このとき、Oracle Enterprise Schedulerに対して、ジョブのステータスがERRORであることを通知し、実行されたすべてのロギングとステータス・メッセージを提供することが必要になります。これを図21-13に示します。

図21-13 BPEL処理エラー

取消しを確認して適切なステータスをOracle Enterprise Schedulerインフラストラクチャに調整して戻すために、受信する取消しメッセージの受入れや障害のトラップをサポートし、いずれの場合でもOracle Enterprise Schedulerサブシステムを更新できるよう、特定のレイアウト内でBPELを設計する必要があります。このためには、BPELプロセスに、この非同期ジョブの機能を含む少なくとも1つのスコープが存在する必要があります。これにより、取消しやエラーの状態の処理は十分に制御され、その後、これらの状態はOracle Enterprise Schedulerランタイムにおけるジョブのステータスを更新するためにOracle Enterprise Scheduler Webサービスに送信される必要があります。

これらの状態をサポートする基本的なプロセス・フローを作成するには、次の手順を順番に完了する必要があります。

1. 相関セットを作成して、受信Receiveアクティビティを模倣するためにフラグを付けます。

2. サブステップ1で作成した相関セットを使用して、onMessageブランチを作成します。

3. フォルト処理ブランチを作成します。

4. 必要に応じて、onMessageブランチとフォルト処理ブランチにクリーン・アップ・アクティビティを移入し、Oracle Enterprise Scheduler Webサービスを適切なステータスで起動します。

21.4.6.1 相関セットの作成および開始アクティビティの定義

BPELプロセスで他のアクティビティを実行中か、または非同期コールバックを待機中に取消しイベントの受信をサポートするには、プロセスが相関セットを使用して構成されている必要があります。相関セットは、BPELエンジンに対してBPELプロセスを一意に識別するために使用される1つ以上の受信ペイロード属性から作成されるキー値であり、これにより、新規プロセスを開始するかわりに、一致する属性のセットを含む追加サービス・リクエストを現在実行中のプロセスにルーティングできます。相関は非同期リクエスト・レスポンスに使用される標準機能ですが、スコープ・レベルのonMessageブランチによって、BPELプロセスでの実行フローを変更するためにも使用できます。

相関セットを設定するには、デザイナでBPELプロセスを開き、Receiveアクティビティをダブルクリックして、「相関」タブをクリックします。

相関セットには、この相関セットのライフ・サイクルの開始点となるアクティビティを示す開始プロパティが含まれていることに注意してください。この場合、BPELプロセスは相関セットのライフ・サイクルが開始する必要がある時点に開始され、これにより、相関イベントはプロセスのどの時点であってもこのプロセスにルーティングされます。

相関セットを作成する手順は、次のとおりです。

- 任意のReceive、InvokeまたはonMessageアクティビティの「相関」タブで「新規」ボタンをクリックし、相関セットの名前を指定します。

- 次に、「追加」をクリックして、相関キーとして使用する1つ以上のプロパティ属性を定義します。

- 変数属性を設定プロパティとして選択して、「OK」をクリックします。

- ステップ2と3を必要に応じて繰り返し、常に一意となる属性セットを作成します。

- 相関セットのライフ・サイクルが開始するアクティビティで、相関の「開始」フラグを「はい」に設定します。

図21-14に、相関セットが定義され、「開始」フラグが「はい」に設定されたプライマリ(最初の) Receiveアクティビティを示します。

図21-14 Receiveアクティビティの相関

図21-15に、単一のプロパティが定義されたCorrelationSet_1定義を示します(一意キーが作成されていることを確認するには、必要に応じて追加プロパティを定義します)。

図21-15 「相関セットの編集」

21.4.6.2 相関セットを使用したonMessageブランチの作成

相関セットを開始のために定義して設定すると、受信する取消しメッセージを受け入れるために必要なアクティビティを含むonMessageブランチをスコープに作成して、補正やクリーンアップを実行し、ジョブの完了ステータスをCANCELに割り当てることができるようになります。

注意:

この時点で、onMessageブランチにInvokeアクティビティが含まれていたり、上位順序のスコープでinvokeを実行することが許可されなくなることがあり、この場合、フロー内で必要なinvokeアクティビティの全体数は減少します。

次の手順を実行して、図21-16に示すように、以前に作成した相関セットをonMessageブランチのアクティビティに追加します。

- プロセス機能を含むネストされたスコープで、「OnMessageブランチの追加」ボタンをクリックし、スコープの隅に新規フローを作成します。

- onMessageブランチのアクティビティをダブルクリックしてアクティビティ・エディタを開きます。

- 「相関」タブを選択します。

- 「追加」(+)ボタンをクリックして以前に作成した相関セットを選択し、「開始」フラグが「いいえ」に設定されていることを確認して、「OK」をクリックします。

図21-16 BPEL OnMessageブランチ

21.4.6.3 フォルト・ブランチの作成

ネストされた作業スコープで様々なアクティビティを実行する過程において、BPELではビジネス・サービスまたはシステム機能からフォルトが発生する場合があります。ほとんどの場合、プロセスのコールにスローして戻すことができる1つ以上のWSDL定義フォルトがビジネス・サービスによって定義されます。通常、BPEL CatchAllフォルト・ブランチでは、発生するすべてのフォルトがそのタイプや原因に関係なくトラップされますが、特定のビジネス・フォルトに対して、異なる動作セットを実行するという要件が製品チームに存在する場合があります。特定のビジネス・フォルトに対して独自の補正動作が実行されるようにする場合、開発者は、WSDL定義済フォルトごとに、指定されたフォルト処理ブランチを作成する必要があります。これらの指定されたフォルト・ハンドラ・ブランチに加えて、スコープから発生するシステム・レベルまたは管理対象外のフォルトをトラップするには、CatchAllフォルト処理ブランチの追加が引き続き必要です。

CatchFaultおよびCatchAllのスコープ・ボタンをクリックして必要なフォルト処理ブランチを作成し、次に、指定されたフォルト処理ブランチをダブルクリックして、これらのブランチが捕捉する指定されたフォルトを定義します。

図21-17に示す使用可能なステータスに注意してください。

図21-17 BPELフローのCatchブランチ

21.4.6.4 onMessageおよびフォルト・ブランチへの移入

必要に応じて、onMessageとフォルト・ブランチにクリーン・アップ・アクティビティを移入し、Oracle Enterprise Scheduler Webサービスを適切なステータスで起動する必要があります。

フォルトが発生したり、onMessageブランチを経由して取消しメッセージを受信したりした場合は、ジョブのステータスとステータス・メッセージをモニタリングUIに適切に反映するために、Oracle Enterprise Scheduler Webサービスを使用して、Oracle Enterprise Schedulerインフラストラクチャを直接更新する必要があります。この結果、各フォルト処理ブランチまたはonMessageブランチは、適切なステータスとステータス・メッセージ値をOracle Enterprise Scheduler Webサービスのinvoke変数に割り当てる必要があり、必要に応じて、invokeアクティビティを含めるか、または意図的に、ジョブ・ステータスの結果に左右されないよう設計された上位順序のスコープに戻り、invokeアクティビティをOracle Enterprise Scheduler Webサービスで実行してから完了します。

また、必要に応じてアクティビティをonMessageおよびフォルト・ブランチにドラッグし、クリーンアップ、記録または補正を行います。

図21-18に、onMessageおよびフォルト処理ブランチを含むスコープの例を示します。

図21-18 BPELフロー全体のサンプル

21.4.7 デプロイメントの検証

正常に機能するかどうかテストするには、次の一連の手順を実行する必要があります。

1. 次のサイトにナビゲートしてEDN-DB-LOGページを表示し、ログは有効であると表示されていることを確認します。そうでない場合、「有効化」のリンクをクリックします。

http://host:port/soa-infra/events/edn-db-log

2. 独自のアプリケーション(ジョブ・リクエストを発行するためのFusion Middleware Controlのタスク・フロー・ユーザー・インタフェース)を使用してジョブを発行し、ジョブのステータスがRUNNINGであることを確認します。

3. イベントが即座にEDN-DB-LOGページに表示されます。例21-6に示すように、このイベント・ペイロードを確認します。

4. サブスクライブするメディエータがトリガーされたら、例21-7に示すように、Fusion Middleware Control ($DOMAIN_HOME/as.log)またはsoa-diagnostic logs ($DOMAIN_HOME/servers/<serverName>logs/<serverName>.log)を確認して、イベントの結果としてのメディエータのアクティビティを確認できます。

5. Oracle Enterprise Manager Fusion Middleware ControlコンソールでSOAコンポジットのインスタンスを確認して、エラーを確認します。

http://host:port/em

6. BPELプロセスにエラーがなく、ヒューマン・ワークフロー通知からのレスポンスが予期されている場合、ワークリストにナビゲートして割り当てられた承認者としてログインし、設計の要件ごとに通知を承認するか、または拒否します。

7. ここから、BPELプロセスを完了してOracle Enterprise Scheduler Webサービスを起動し、ジョブの完了ステータスとステータス・メッセージを設定する必要があります。モニタリングUIの診断ログで、スタック・トレースとログ・メッセージを確認します。

8. また、Oracle Enterprise SchedulerスキーマのREQUEST_HISTORY表で、ジョブの状態の詳細を確認できます。

例21-6 イベント・ペイロード

Example:Enqueing event: http://xmlns.oracle.com/apps/ta/essdemo/events/edl::ESSDemoEvent from J
Body: <business-event xmlns:ns="http://xmlns.oracle.com/apps/ta/essdemo/events/edl" xmlns="http://oracle.com/fabric/businessEvent">
<name>ns:ESSDemoEvent</name>
<id>df8e34c1-4c65-4379-b9be-2c692670ebbe</id>
<content>
<ESSDemoEventElement xmlns="http://xmlns.oracle.com/apps/ta/essdemo/events/schema">
<requestId>3</requestId>
<executionContext>3, false, null, 6A4A16757764CD60E0402382B7703F44, 12</executionContext>
<eventType>ESS_EVENT</eventType>
</ESSDemoEventElement>
</content>
</business-event>
Subject name:
Enqueing complete
Enqueing event: http://xmlns.oracle.com/apps/ta/essdemo/events/edl::ESSDemoEvent from J
Body: <business-event xmlns:ns="http://xmlns.oracle.com/apps/ta/essdemo/events/edl" xmlns="http://oracle.com/fabric/businessEvent">
<name>ns:ESSDemoEvent</name>
<id>a4104da8-5579-4434-ab8b-d31a226e3b0f</id>
<content>
<ESSDemoEventElement xmlns="http://xmlns.oracle.com/apps/ta/essdemo/events/schema">
<requestId>4</requestId>
<executionContext>4, false, null, 6A4A2BC7E5477C60E0402382B77041C9, 12</executionContext>
<eventType>ESS_EVENT</eventType>
</ESSDemoEventElement>
</content>
</business-event>

例21-7 メディエータのアクティビティ

INFO: MediatorServiceEngine received an event =
{http://xmlns.oracle.com/apps/ta/ess/demo/events/edl}ESSDemoEvent
Apr 17, 2009 1:57:26 PM oracle.tip.mediator.common.persistence.MediatorPersistor persistCallback
INFO: No call back info set in incoming message
Apr 17, 2009 1:57:26 PM oracle.tip.mediator.common.persistence.MediatorPersistor persistCallback
INFO: Message properties :
{id=041ecfcf-8b73-4055-b5c0-0b89af04f425, tracking.compositeInstanceId=50003, tracking.ecid=0000I2pqzVCBLA5xrOI7SY19uEYF00004g:47979}
Apr 17, 2009 1:57:26 PM oracle.tip.mediator.dispatch.InitialMessageDispatcher dispatch
INFO: Executing Routing Service..
Apr 17, 2009 1:57:26 PM oracle.tip.mediator.dispatch.InitialMessageDispatcher processCases
INFO: Unfiltered case list size :1
Apr 17, 2009 1:57:26 PM oracle.tip.mediator.monitor.MediatorActivityMonitor createMediatorCaseInstance
INFO: Creating case instance with name :ESSDemoProcess.essdemoprocess_client.process
Apr 17, 2009 1:57:26 PM oracle.tip.mediator.dispatch.InitialMessageDispatcher processCase
INFO: Immediate case
{ESSDemoProcess.adedemoprocess_client.process}with case id :
{5B52B4A02B9211DEAF64D3EF6E2FB21D}will be executed
Apr 17, 2009 1:57:26 PM oracle.tip.mediator.service.filter.FilterFactory createFilterHandler
INFO: No Condition defined

21.4.8 ユースケースのトラブルシューティング

Oracle ADF UI機能(モニタリングや発行のタスク・フローなど)に関する問題をトラブルシューティングするには、サーバーのコンソール・ログ、アプリケーション・ログおよびサーバー診断ログを使用して、失敗の原因と理由を確認します。

イベント機能に関する問題(リクエストの実行コンテキストが失われない状態でイベントがBPELプロセスに到達しないなど)をトラブルシューティングするには、EDNデータベース・ログ・ページ(http://host:post/soa-infra/events/edn-db-log)を使用してイベント・ペイロードを検査し、スキーマ定義と慎重に比較します(多少不一致があってもトランスフォーメーションは成功する場合がありますが、BPELに対してリクエスト・コンテキスト値が欠落したスケルトン・ペイロードが生成されます)。Oracle JDeveloperおよびサードパーティのツールを使用して、イベント・ペイロードのスキーマを検証したり、そのペイロードに対してトランスフォーメーションをデバッグできます。

メディエータ(BPEL SOA機能)をトラブルシューティングするには、診断にOracle Enterprise Managerおよびサーバー・コンソールまたは診断ログ・ファイルを使用して、ロギングにAppsLoggerセンサー変数を使用します。

実行時のOracle Enterprise Schedulerのトラブルシューティングの詳細は、『Oracle Fusion Middleware Oracle Enterprise Schedulerの管理』の「Oracle Enterprise Schedulerのトラブルシューティング」を参照してください。

21.5 非同期ジョブのタイムアウトおよびリカバリの処理

Oracle Enterprise Schedulerの非同期Javaジョブは、リモート・ジョブに依存してOracle Enterprise Schedulerを完了ステータスで更新した後、リクエスト処理を完了できます。

リモート通信の性質上、ネットワーク障害などが原因で、リモートのリクエスト・ステータスがOracle Enterprise Schedulerで受信されない場合があります。このような場合、リクエストは非終了状態でスタックされることがあります。

タイムアウト・リクエストの終了状態への遷移は、次のことを可能にするので、重要です:

- このジョブ・リクエストで保持されている非互換性ロックを解放します。

- ジョブ・リクエストがジョブ・セット・ステップの場合、ジョブ・セットを続行します。

- リクエストがサブリクエストの場合、親リクエストを再開します。

- ジョブ・リクエストが削除またはパージされるようにします。

21.5.1 非同期リクエストのタイムアウト

Oracle Enterprise Schedulerのシステム・プロパティSystemProperty.ASYNC_REQUEST_TIMEOUTを使用すると、非同期Javaジョブに対するジョブ・リクエストのタイムアウト値を設定できます。デフォルトでは、このプロパティは有効化されておらず、その値はゼロ以下となっています。

プロパティは、ジョブ定義メタデータで設定されたり、ジョブ・リクエストの発行時に設定される場合があります。値は、ジョブ・リクエストによりローカル実行が開始されたときから、非同期ジョブの最終ステータスがリモート・ジョブから受信されるまでの期間(分単位)を表します。

21.5.1.1 タイムアウト値の設定

指定された非同期ジョブ・リクエストの場合、システム・プロパティSystemProperty.ASYNC_REQUEST_TIMEOUTを0より大きい値に設定します。

21.5.1.2 タイムアウトした非同期ジョブ・リクエストの検出

指定されたリクエストについて、RequestDetail.isTimedOutはタイムアウトのステータスを示します。タイムアウトしたリクエストは、例21-8に示す問合せを使用して検出できます。

例21-9に示すように、REQUEST_HISTORY_VIEWを使用して、同様の問合せを実行できます。

例21-8 タイムアウト・ステータスの表示

Filter timedOutRunningFilter = new Filter(
RuntimeService.QueryField.TIMED_OUT.fieldName(),
Filter.Comparator.EQUALS,
Boolean.TRUE)
.and(
RuntimeService.QueryField.STATE.fieldName(),
Filter.Comparator.EQUALS,
State.RUNNING.value());
runtimeService.queryRequests(handle, timedOutRunningFilter, null, true);

例21-9 REQUEST_HISTORY_VIEWの使用

SELECT requestId FROM request_history_view WHERE timedout='Y' AND state=3;

21.5.1.3 タイムアウトがない非同期リクエストの完了

タイムアウト値がない場合、リモート・ジョブがステータスをOracle Enterprise Schedulerに配信せずに完了した非同期リクエストは、RuntimeMXBean.completeAsyncRequestを使用して直接完了することがあります。注意が必要であることを示すフラグをリクエストに付けるためのタイムアウト値がないため、タイムアウトのないリクエストを慎重に追跡する必要があります。

タイムアウトがないジョブ・リクエストの管理の詳細は、『Oracle Fusion Middleware Oracle Enterprise Schedulerの管理』の「Oracle Enterprise Schedulerのトラブルシューティング」を参照してください。

21.5.1.4 非同期ジョブ・リクエストのタイムアウト時の処理内容

Oracle Enterprise Schedulerでは、プロパティSystemProperty.ASYNC_REQUEST_TIMEOUTが設定された非同期ジョブ・リクエストを定期的に確認します。最終ステータスが受信されずに時間が超過すると、タイムアウトしたというフラグがジョブに付けられます。それ以外の場合、ジョブの状態は影響を受けず、RUNNING状態のままとなります。その一方で、Oracle Enterprise Schedulerでは、リモート・ジョブからのステータス更新を引き続き受け入れます。フラグは、リモート・ジョブのステータス調査が必要である可能性があることを示します。

21.5.2 手動リカバリ対象としてマークされた非同期ジョブの処理

リモート・ジョブは完了したが、そのステータスがOracle Enterprise Schedulerに配信されなかった場合、リクエストを手動で完了できます。

ジョブが実行中かどうかわからない場合など、ジョブのステータスを自動で決定できない場合もあります。ジョブが実行中の場合、ジョブ・リクエストが終了状態に遷移しないようにする必要があります。ジョブが終了状態に遷移すると、非互換性ロックが解放され、互換性のないジョブ・リクエストが同時に実行される可能性があります。

次に例を示します。

- リモート・サービスが開始したときに非同期Javaジョブでエラーが発生し、リモート・サービスが実際に起動されたことが不明確になります。リモート・ジョブが実行中かどうかが判断されるまで、ジョブ・リクエストがエラー状態にならないようにする必要があります。ジョブが実行中である可能性がある場合、ジョブでは、ジョブ・リクエストがERROR_MANUAL_RECOVERY状態に遷移する必要があることをOracle Enterprise Schedulerに示すために、oracle.as.scheduler.ExecutionManualRecoveryExceptionをスローする必要があります。

- Oracle Enterprise Schedulerの非同期Javaジョブはjava.lang.Errorをスローしますが、これにより、リモート・サービスが起動されたかどうかをOracle Enterprise Schedulerに示すことはありません。

- 生成されたジョブはクラスタ化された環境で実行中であり、ジョブ・リクエストはOracle Enterprise Scheduler instance1で実行中です。Oracle Enterprise Scheduler instance1サーバーは、関連するPerlエージェントとともに停止します。instance1がしばらくの間リカバリしない場合、ジョブ・ステータスは不明となります。このタイプの状況では、プロパティState.ERROR_MANUAL_RECOVERYを使用します。これは、リカバリ操作が手動で起動されるまでジョブ・リクエストの処理を一時停止する非終端状態です。取得された非互換性ロックは、手動リカバリが完了するまで保持されます。

手動リカバリ対象としてマークされた非同期ジョブの処理の詳細は、『Oracle Fusion Middleware Oracle Enterprise Schedulerの管理』の「Oracle Enterprise Schedulerのトラブルシューティング」、手動リカバリを要するスタック非同期ジョブの処理に関する項を参照してください。

21.5.3 ジョブ・リクエストの手動リカバリに対するRecoverRequestの使用

一部のジョブ・リクエストが不完全な状態でスタック状態となった場合、最初に、ジョブ・リクエストが通常の方法で完了できるかどうかを判断する必要があります。たとえば、ジョブ・リクエストがRUNNING状態の場合、リモートで実行中の非同期Javaジョブのためである場合があります。リモート・ジョブが応答できない場合、ジョブ・リクエストの取消しを試行する必要があります。これにより、ジョブ・リクエストはCANCELLING状態に遷移します。ジョブ・リクエストがCANCELLED状態に遷移しない場合は、リカバリ対象の候補にすることができます。

リカバリ対象となるリクエストの子リクエストはすべて、すでに完了している必要があり、これは、そのプロセス・フェーズがProcessPhase.Completeであることを意味します。RequestDetail.getProcessPhase()を実行して、プロセス・フェーズを取得できます。

RuntimeService.queryRequestsを使用すると、例21-10に示すフィルタを使用して、不完全な子リクエストを判別する問合せを実行できます。

いずれかの子リクエストで手動リカバリが必要であると判断された場合、最初に、これらのジョブに対してrecoverRequestを起動します。不完全な子リクエストを含む親リクエストに対してrecoverRequestが起動されると、例外がスローされます。この例外メッセージには、不完全な子リクエストがリストされます。例21-11に、recoverRequest構文を示します。

同期Javaジョブの手動による処理の詳細は、『Oracle Fusion Middleware Oracle Enterprise Schedulerの管理』の「Oracle Enterprise Schedulerのトラブルシューティング」、手動リカバリを要する同期Javaジョブの処理に関する項を参照してください。

例21-10 不完全な子リクエストのフィルタリング

Filter filter =
new Filter(RuntimeService.QueryField.ABSPARENTID.fieldName(),
Filter.Comparator.EQUALS, requestId)
.and(RuntimeService.QueryField.REQUESTID.fieldName(),
Filter.Comparator.NOT_EQUALS, requestId)
.and(RuntimeService.QueryField.PROCESS_PHASE.fieldName(),
Filter.Comparator.NOT_EQUALS,
ProcessPhase.Complete.value());

例21-11 recoverRequest

/**
* Attempts to force a request to complete under certain conditions.
* <p>
* 1. The request must already by in a terminal state, {@code
*    State.CANCELLING}, or {@code State.ERROR_MANUAL_RECOVER}.
*    If a request is in another state,
*    {@code RuntimeService.cancel} must be called first. If the
*    request does not eventually transition to {@code State.CANCELLED},
*    then this operation may be invoked on the request.
* 2. All child requests of the given request must already be complete.
* <p>
* A <b>completed></b> request is a request in a terminal state with
* a process phase of {@code ProcessPhase.Complete}.
* <p>
* Note that this operation locks the request.
* <p>
* @param requestId the request identifier of the request.
* @throws IOException if a protocol error occurred.
* @throws InstanceNotFoundException if the request is not found
* @throws OperationException if the given request has child requests
*  that are not complete.
* @throws RuntimeOperationsException if a RuntimeService subsystem failure
* occurs.
*/
public void recoverRequest( long requestId )
throws IOException, InstanceNotFoundException, OperationsException,
RuntimeOperationsException;

21.6 Oracle Enterprise Schedulerのインタフェースとクラス

この項では、Oracle Enterprise Scheduler非同期コールバック・インタフェースおよびクラスのサンプルコードを示します。

Oracle Enterprise Schedulerの非同期コールバック・インタフェースとクラスのサンプル・コードを例21-12、例21-13、例21-14および例21-15に示します。

UpdateActionクラスはUpdatable.onEventによって返されます。

例21-12 Oracle Enterprise SchedulerのUpdatableインタフェース

public interface Updatable
{
/**
* Invoked by Enterprise Scheduler when a job request is updated.
* This method must eventually return control to the caller.
*
* @param  context  An oracle.as.scheduler.RequestExecutionContext
* object for this request.
*
* @param parameters  the request parameters associated with this request
*
* @param resultCode the {@code
* oracle.as.scheduler.async.UpdateAction.ActionCode} indicating the
* action that generated this event.
*
* @param messagePayload a {@code String} representing the body of this
* event. The content and format are not known by the Enterprise Scheduler.
*/
public UpdateAction onEvent( RequestExecutionContext context,
RequestParameters parameters,
oracle.as.scheduler.async.AsyncStatus resultCode,
String messagePayload );
}

例21-13 Oracle Enterprise SchedulerのUpdateActionクラス

package oracle.as.scheduler.async;

/**
* Enumeration of return values from application execution callout. The
* action returned determines how the subsequent processing of the request
* proceeds.
*/
public class UpdateAction
{
/**
* Constructor. Creates an UpdateAction object from the status
* and message components.
*
* @param status Indicates the status of execution of this update event.
* This status may result in a state transition for the request.
*
* @param message A message that, depending on the value of {@code status},
* may be used for various purposes.
*/
public UpdateAction( AsyncStatus status, String message );

public AsyncStatus getAsyncStatus( );

public String getMessage( );
}

例21-14 Oracle Enterprise SchedulerのAsyncStatus列挙

Package oracle.as.scheduler.async;

/**
* Valid values for the callback status of an asynchronous java job.
* Returning an {@code AsyncStatus} does not guarantee that the state of the
* request changes to the corresponding value. The new state of the request
* depends on the old state, the async status, the result of the
* post-Process handler (if any), and any errors that may occur in
* subsequent processing.
*/
public enum AsyncStatus
{
/**
* The asynchronous job ran successfully.
*/
SUCCESS,

/**
* The asynchronous job has paused for the execution of sub-requests.
*/
PAUSE,

/**
* The asynchronous job is issuing a WARNING.
*/
WARNING,

/**
* The asynchronous job encountered an error.
*/
ERROR,

/**
* The asynchronous job has canceled its execution. Usually this
* originates from a {@code RuntimeService.cancel} call.
*/
CANCEL,

/**
* The asynchronous job is updated. The request state is not changed
* by this action.
*/
UPDATE,
/**
* The asynchronous job encountered a business error.
*/
BIZ_ERROR,

/**
* The asynchronous job requests manual recovery to complete the request.
*/
ERROR_MANUAL_RECOVERY;
}

例21-15 既存の非同期コールバックWebサービス操作

/**
* Set the status of an Oracle Enterprise Scheduler asynchronous java job.
*
* @param requestExecutionContext A java.lang.String representing
* an oracle.as.scheduler.RequestExecutionContext object.
* @param status
* @param statusMessage
*   An error message if the status is ERROR,
*   A business error message if the status is BIZ_ERROR,
*   A warning message if the status is WARNING,
*   A paused state if the status is PAUSED.
*   The value is ignored if the status is SUCCESS or CANCEL.
*
*/
public void setAsyncRequestStatus( String requestExecutionContext,
AsyncStatus status,
String statusMessage )
throws RequestNotFoundException, RuntimeServiceException ;

22 ジョブ・リクエスト・ログと出力

この章では、Oracle Enterprise Schedulerを使用して、管理者とユーザーが後で使用できるように保存する必要があるジョブ・リクエスト・ログと出力を生成する方法について説明します。

ジョブ・リクエストによって生成されるログは、管理者が問題を診断したり、ジョブ固有の状態を確認するのに役立ちます。ログには、Fusion Middleware Controlからアクセスできます。さらに、一部のジョブでは、ジョブの完了後にユーザーが確認できるジョブ固有のデータに関するレポートなどの出力が、その作業の一環として生成されます。コードで、リクエスト・ログ情報およびリクエストの出力を作成および格納できます。

この章の内容は次のとおりです。

- リクエスト・ログ

- リクエスト出力

22.1 リクエスト・ログ

Oracle Enterprise Schedulerでは、ジョブがリクエストのロギングに使用できるAPIが提供されています。プロセス・ジョブを除くすべてのジョブ・タイプで、ロギングAPIが使用されます。また、Oracle Enterprise Schedulerは、コンテンツ・ストア内のリクエスト・ログを処理するAPIも提供します。

Oracle Enterprise Schedulerでは、リクエストごとに1つのログがサポートされます。このログにはREQUESTID.logという形式の名前が付けられます。ロギングAPIでは、コンテンツ・ストアに直接ログが記録され、ログ・コンテンツはロールバックできません。

Fusion Middleware Controlによるジョブ・リクエストの表示の詳細は、『Oracle Fusion Middleware Oracle Enterprise Schedulerの管理』のジョブ・リクエスト・ログの表示に関する項を参照してください。

22.1.1 システム・プロパティ

APIによりメッセージが記録されるシステム・プロパティSYS_EXT_requestLogLevel制約は、リクエスト・ログに格納されます。

プロパティの値は、デフォルトでINFOに設定されます。有効な値の完全なセットは、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINESTです。JavaおよびPL/SQL APIを使用して、リクエストのログ・レベルを検出します。

プロセス・ジョブではロギングAPIが使用されないため、SYS_EXT_requestLogLevelはプロセス・ジョブに適用されないことに注意してください。

22.1.2 ログ・ヘッダー

ロギング・コードにより、次の見出し情報で始まるログにエントリが書き込まれます。このヘッダーは、ロギングAPIによりログに書込まれる各レコードの先頭に自動的に付けられるため、プロセス・ジョブには適用されません。

####[TIMESTAMP] [LOGLEVEL]

Sample log lines:
####[2011-07-11T14:20:32.276-07:00] [INFO] This is a log record.
####[2011-07-11T14:20:32.282-07:00] [INFO] This is the first line of a multi-line log record:
second line of multi-line log record.

22.1.3 Javaジョブからのリクエスト・ロギング

Javaリクエスト・ロガーを使用して、Javaまたは非同期Javaジョブの実行および更新ステージ中、およびすべてのジョブ実行タイプの前処理および後処理中にログを記録できます。

ジョブ・ロジックでは、ContentFactory APIを使用して、リクエスト・ログへのメッセージの記録に使用できるRequestLoggerを取得する必要があります。Oracle Enterprise Schedulerでは、ロガーが取得されるたびに、SYS_EXT_requestLogLevelシステム・プロパティの現行値を使用して、ロギング・レベルを制限します。

22.1.3.1 Javaジョブ・ログ出力用API

Javaジョブのロジックで、oracle.as.scheduler.request.ContentFactoryクラスのgetRequestLoggerメソッド(表22-1を参照)を使用して、ログ・エントリを追加するためのRequestLoggerインスタンスを取得できます。リクエスト・ロガーでは、リソース・バンドルはサポートされていないことに注意してください。

ログの処理に使用できるJava APIは次のとおりです。

- ContentFactoryクラスは、ログの作成やエントリの追加に使用できるRequestLoggerのインスタンスを取得するために使用します。表22-1を参照してください。

- RequestLoggerクラスは、ログを書き込むために使用します。表22-2を参照してください。

oracle.as.scheduler.request.ContentFactoryクラスには、コードが、出力コンテンツ・フレームワークにアクセスしたり、出力自体を作成するために使用できるインスタンスにアクセスできるようにするメソッドが備えられています。

表22-1 リクエスト・ログを作成するためのContentFactoryメソッド

メソッド

説明

getRequestLogger( long requestId )

指定されたrequestIdに対してRequestLoggerインスタンスを返し、requestId.logという名前のログ・コンテンツをOracle Enterprise Schedulerコンテンツ・ストアに作成します。

ロガー・インスタンスを取得すると、エントリを追加するために、表22-2に示されているメソッドを使用できます。

表22-2 リクエスト・ログを作成するためのRequestLoggerメソッド

メソッド

説明

log( Level level, String msg )

fine( String msg )

finer( String msg )

finest( String msg )

これらのメソッドによって、指定されたレベルでメッセージがログに記録されます。

指定されたロギング・レベルが、SYS_EXT_requestLogLevelシステム・プロパティで指定されたログ・レベル以上である場合にのみ、メッセージがログに記録されます。このプロパティが設定されていない場合のデフォルト・ログ・レベルはINFOです。

logメソッドを使用する場合、java.util.logging.Levelでは、次に降順で示す値をサポートします。

- SEVERE

- WARNING

- INFO

- CONFIG

- FINE

- FINER

- FINEST

22.1.3.2 Javaリクエスト・ロギングの例

例22-1に、ロギングを行う非常に単純なJavaジョブの例を示します。

例22-1 Javaのリクエスト・ロギングの例

import oracle.as.scheduler.request.ContentFactory;
import oracle.as.scheduler.request.RequestLogger;
import java.util.logging.Level;

class ExampleJavaLogger{

private boolean m_loggingEnabled = false;
private RequestLogger m_requestLogger = null;

public void execute( RequestExecutionContext ctx,
RequestParameters params )
{
try
{
m_requestLogger = ContentFactory.getRequestLogger(ctx.getRequestId());
m_loggingEnabled = true;
}
catch (Exception ex)
{
// failed to get request logger
}

log(Level.INFO, "Starting the job.");
// ...
log(Level.INFO, "Ending the job.");
}

private void log( Level level, String message )
{
if (m_loggingEnabled)
{
m_requestLogger.log(level, message);
}
}
}

22.1.4 PL/SQLジョブからのリクエスト・ロギング

PL/SQLからログを作成する場合は、ログ・エントリを書き込むために、コードでESS_JOB PL/SQLパッケージを使用できます。

22.1.4.1 ログを作成するためのESS_JOBパッケージ・サポート

Oracle Enterprise Schedulerには、PL/SQLコードからログを作成するためのファンクションおよびプロシージャを含むESS_JOBパッケージが備えられています。

表22-3 リクエスト・ロギング用のESS_JOBファンクションおよびプロシージャ

メソッド

説明

procedure write_log( p_level in integer, p_text in varchar2 );

現行セッションに関連付けられているOracle Enterprise Schedulerリクエストに対して、p_textをメッセージとしてリクエスト・ログ・コンテンツに書き込みます。

指定されたロギング・レベルが、SYS_EXT_requestLogLevelシステム・プロパティで指定されたログ・レベル以上である場合にのみ、メッセージがログに記録されます。このプロパティが設定されていない場合のデフォルト・ログ・レベルはLEVEL_INFOです。

ログ・レベルの値は、java.util.logging.Levelで定義された値に対応します。

p_levelパラメータに次の値を使用します(降順で示します)。

- LEVEL_SEVERE

- LEVEL_WARNING

- LEVEL_INFO

- LEVEL_CONFIG

- LEVEL_FINE

- LEVEL_FINER

- LEVEL_FINEST

22.1.4.2 PL/SQLのリクエスト・ロギングの例

SQLリクエスト・ジョブ・プロシージャによるリクエスト・ロギングの例を次に示します。

create or replace procedure log_example_job
( request_handle in varchar2 )
as
v_request_id  number := null;
begin
ess_job.write_log(ess_job.level_fine,
'LOG_EXAMPLE_JOB Procedure Begin');

-- Oracle Enterprise Scheduler request id being executed.
begin
v_request_id := ess_runtime.get_request_id(request_handle);
exception
when others then
ess_job.write_log(ess_job.level_severe,
'Bad request handle: '||request_handle);
raise_application_error(-20000,
'Failed to get request id for request handle '||request_handle,
true);
end;

-- Job logic
ess_job.write_log(ess_job.level_info,
'Executing job logic...');

ess_job.write_log(ess_job.level_fine,
'LOG_EXAMPLE_JOB Procedure End');
end;
/

22.1.5 プロセス・ジョブからのリクエスト・ロギング

プロセス・ジョブからジョブ・リクエスト・ログに書き込むことができます。この動作は、特定のレベルでエントリを書き込むためのAPIに実行コードからアクセスできる、JavaおよびPL/SQLジョブとは大きく異なります。プロセス・ジョブでは、かわりに、ジョブの標準出力および標準エラーが、リクエストのログ作業ディレクトリ(Oracle Enterprise Schedulerにより設定される場所)にあるファイルにリダイレクトされます。Oracle Enterprise Schedulerは、このファイルをインポートし、コンテンツ・ストア内のリクエスト・ログに付加します。

つまり、プロセス・ジョブからログを記録するために必要なのは、ジョブ・ロジック・コードから標準出力に書き込むことのみです。

ログ・ファイルの読取りに使用されるエンコーディングは、「プロセス・ジョブのロケール」の説明に従って決定されます。

プロセス・ジョブから特定のレベルでログを記録できないことに注意してください(レベルを設定するためのAPIが使用できないため)。このため、ログ・コンテンツはSYS_EXT_requestLogLevelシステム・プロパティによって制限されません。Oracle Enterprise Schedulerでは、常にログ・ファイルのコンテンツをコンテンツ・ストア内のリクエスト・ログに付加します。

22.1.6 EJBジョブからのリクエスト・ロギングおよび出力

EJBジョブはリモートで実行されるJavaジョブであるため、リモートEJBジョブ実装はコンテンツをログおよび出力に書込むことができます。このコンテンツを処理するには、oracle.as.scheduler.request.RemoteContentHelper APIを使用します。次の箇条書きの項目は、必要な手順の概要を示しています。例22-2に、この機能を表すEJBジョブ実装を示します。

- RemoteContentHelperを設定します。パラメータRequestExecutionContextおよびRequestParametersは、ジョブ実装のexecute()メソッドから取得できます。

RemoteContentHelper rch=new RemoteContentHelper(RequestExecutionContext, RequestParameters);

- コンテンツをログ・ファイルに書き込みます。

rch.log(Level.INFO, logMessage)

- テキスト出力を書き込みます。

RuntimeServiceHandle rsh = null;
ContentHandle ch = null;
String contentName = "Content1";
String contentData = "Some text content";
try {
rsh = rch.getRuntimeService().open();
ch = rch.openOutputContent(rsh, contentName, ContentType.Text,        EnumSet.of(ContentHandle.ContentOpenOptions.Write));
rchelper().write(ch, contentData);
} catch (Exception ex) {
throw new ExecutionErrorException(ex);
} finally {
rch.closeOutputContent(ch);
rch.getRuntimeService().close(rsh);
}

- バイナリ出力を書き込みます。

RuntimeServiceHandle rsh = null;
ContentHandle ch = null;
String contentName = "Content1";
String contentData = "Some binary content"; //Binary content can differ in the     variable declaration.
try {
rsh = rch.getRuntimeService().open();
ch = rch.openOutputContent(rsh, contentName, ContentType.Binary,         EnumSet.of(ContentHandle.ContentOpenOptions.Write));
rchelper().write(ch, contentData.getBytes());
} catch (Exception ex) {
throw new ExecutionErrorException(ex);
} finally {
rch.closeOutputContent(ch);
rch.getRuntimeService().close(rsh);
}

例22-2に、出力およびログの処理方法を表すEJBジョブ実装を示します。

例22-2 SimpleSyncEssBean

import java.util.ArrayList;
import java.util.logging.Level;
import java.util.EnumSet;

import javax.ejb.Stateless;

import oracle.as.scheduler.RuntimeServiceHandle;
import oracle.as.scheduler.ExecutionCancelledException;
import oracle.as.scheduler.ExecutionErrorException;
import oracle.as.scheduler.ExecutionPausedException;
import oracle.as.scheduler.ExecutionWarningException;
import oracle.as.scheduler.RemoteExecutable;
import oracle.as.scheduler.RequestExecutionContext;
import oracle.as.scheduler.RequestParameters;
import oracle.as.scheduler.request.RemoteContentHelper;
import oracle.as.scheduler.request.ContentDetail;
import oracle.as.scheduler.request.ContentHandle;
import oracle.as.scheduler.request.ContentType;

@Stateless(name = "SimpleSyncEssBean")
public class SimpleSyncEssBean implements RemoteExecutable {
private RemoteContentHelper m_rch = null;

public void execute(RequestExecutionContext requestExecutionContext,
RequestParameters requestParameters) throws ExecutionErrorException, ExecutionWarningException,
ExecutionCancelledException,
ExecutionPausedException {
long requestId = requestExecutionContext.getRequestId();
// setup helper now so it is available to println
m_rch = setupRemoteContentHelper(requestExecutionContext, requestParameters);

ContentType contentType = ContentType.Text;
String contentName = requestId + "Output.txt";

ArrayList<String> srcLines = new ArrayList<String>();
srcLines.add("SimpleSyncEssBean Output Details \n");
boolean success = false;
String exmsg = "";

try {
createOutputContent(contentName, contentType, srcLines);
success = verifyOutputContent(contentName, contentType, srcLines);
} catch (ExecutionErrorException ex) {
exmsg = ex.getMessage();
}

if (!success) {
throw new ExecutionErrorException("Output test failed: " + contentName                 + ", " + exmsg);
} else {
printToLog("Output test succeeded: " + contentName);
}
printToLog(" SimpleSyncEssBean job succeeded. RequestId:" + requestId);
}

/**
* Creates the remote content helper for log/output.
*/
private RemoteContentHelper setupRemoteContentHelper(RequestExecutionContext        ctx, RequestParameters params) throws ExecutionErrorException {

RemoteContentHelper rch = null;
try {
rch = new RemoteContentHelper(ctx, params);
} catch (Exception ex) {
throw new ExecutionErrorException(ex);
}

return rch;
}

/**
* Gets the remote content helper that is setup.
* Throws if it is not setup.
*/
private RemoteContentHelper rchelper() throws ExecutionErrorException {
if (null == m_rch) {
throw new ExecutionErrorException("RemoteContentHelper is not setup");
}

return m_rch;
}

private void printToLog(String message) throws ExecutionErrorException {
System.out.println(message);
if (m_rch != null) {
try {
m_rch.log(Level.INFO, message);
} catch (Exception ex) {
// ignore
}
} else {
rchelper();
}

}

/**
* Writes dataList as either Text or Binary output content.
*/
private void createOutputContent(String contentName, ContentType contentType,
ArrayList<String> dataList) throws ExecutionErrorException {
RuntimeServiceHandle rsh = null;
ContentHandle ch = null;
try {
rsh = rchelper().getRuntimeService().open();
ch =
rchelper().openOutputContent(rsh, contentName, contentType,
EnumSet.of(ContentHandle.ContentOpenOptions.Write));

for (String data : dataList) {
if (ContentType.Text == contentType) {
rchelper().write(ch, data);
} else {
rchelper().write(ch, data.getBytes());
}
}
} catch (Exception ex) {
throw new ExecutionErrorException(ex);
} finally {
if (ch != null) {
try {
rchelper().closeOutputContent(ch);
} catch (Exception ex) {
printToLog("Error while closing ch: " + ex.getMessage());
//ex.printStackTrace();
throw new ExecutionErrorException(ex);
}
}
if (rsh != null) {
try {
rchelper().getRuntimeService().close(rsh);
} catch (Exception ex) {
printToLog("Error while closing rsh: " + ex.getMessage());
//ex.printStackTrace();
throw new ExecutionErrorException(ex);
}
}
}
}

/**
* Verifies Text or Binary output content.
*/
private boolean verifyOutputContent(String contentName,         ContentType contentType, ArrayList<String> srcDataList)         throws ExecutionErrorException {

String actualData = getOutputContent(contentName, contentType);

StringBuffer sb = new StringBuffer();
for (String str : srcDataList) {
sb.append(str);
}
String srcData = sb.toString();

boolean success = srcData.equals(actualData);

if (!success) {
printToLog("Test failed for " + contentName);
printToLog("Expected data: <\n" + srcData + ">");
printToLog("Actual data: <\n" + actualData + ">");
}

try {
if (rchelper().outputContentExists(contentName)) {
ContentDetail detail =                     rchelper().getOutputContentDetail(contentName);
printToLog("ContentDetail:\n" + detail);
} else {
printToLog("The output content details are not present:\n");
}

} catch (Exception ex) {
String exm = "Failed to get output content detail: " + contentName;
printToLog(exm);
throw new ExecutionErrorException(ex);
}

return success;
}

/**
* Gets either Text or Binary output content as String.
*/
private String getOutputContent(String contentName, ContentType contentType)        throws ExecutionErrorException {
RuntimeServiceHandle rsh = null;
long requestId = rchelper().getRequestExecutionContext().getRequestId();
ContentHandle ch = null;
String result = null;
try {
rsh = rchelper().getRuntimeService().open();
ch =
rchelper().openOutputContent(rsh, contentName, contentType,
EnumSet.of(ContentHandle.ContentOpenOptions.Read));

if (ContentType.Text == contentType) {
char[] chars = rchelper().getTextContent(ch, Integer.MAX_VALUE);
result = new String(chars);
} else {
byte[] bytes = rchelper().getBinaryContent(ch, Integer.MAX_VALUE);
result = new String(bytes);
}
} catch (Exception ex) {
throw new ExecutionErrorException(ex);
} finally {
if (ch != null) {
try {
rchelper().closeOutputContent(ch);
} catch (Exception ex) {
printToLog("Error while closing ch: " + ex.getMessage());
//ex.printStackTrace();
throw new ExecutionErrorException(ex);
}
}
if (rsh != null) {
try {
rchelper().getRuntimeService().close(rsh);
} catch (Exception ex) {
printToLog("Error while closing rsh: " + ex.getMessage());
//ex.printStackTrace();
throw new ExecutionErrorException(ex);
}
}
}

return result;
}

}

22.1.7 Webサービス・ジョブからのリクエスト・ロギング

進捗状況メッセージは、非同期ジョブにのみ提供されます。Oracle Enterprise Scheduler AsyncWebServiceJobコールバック・エンドポイントは、新しいlogAsyncWSJobProgressMessage一方向操作をサポートします。この操作では、非同期SOAコンポジット(またはその他の非同期Webサービス)により、相関のws-addressing、および同じコールバック・エンドポイントおよび関連付けされたコールバックOWSMポリシーを使用して進捗状況メッセージを記録できます。これにより、非同期SOAコンポジットからのロギング進捗状況メッセージのための簡易的で便利なオプションが提供されます。

Oracle Enterprise Schedulerの非同期Webサービス・ジョブのコールバック・エンドポイントWSDLは、この操作の使用に必要な情報を提供します。WSDLの一部分を例22-3に示します。

例22-3 非同期Webサービス・ジョブ・コールバック・エンドポイントWSDL

<xsd:complexType name="logAsyncWSJobProgressMessage">
<xsd:sequence>
<xsd:element name="level" type="tns:logLevel" form="qualified"/>
<xsd:element name="message" type="xsd:string" form="qualified"/>
</xsd:sequence>
</xsd:complexType>

<xsd:element name="logAsyncWSJobProgressMessage" type="tns:logAsyncWSJobProgressMessage"/>
<message name="logAsyncWSJobProgressMessageInput">
<part name="parameters" element="tns:logAsyncWSJobProgressMessage"/>
</message>

<portType name="RequestPort">
<operation name="logAsyncWSJobProgressMessage">
<input message="tns:logAsyncWSJobProgressMessageInput"                  xmlns:ns1="http://www.w3.org/2006/05/addressing/wsdl"                   ns1:Action="logAsyncWSJobProgressMessage"/>
</operation>
</portType>

22.1.8 リクエスト・ログを処理するためのAPI

oracle.as.scheduler.RuntimeServiceクラスのメソッドを使用して、Oracle Enterprise Schedulerコンテンツ・ストアに格納されているログを処理できます。最初に、RuntimeServiceHandleインスタンスを取得する必要があります。このインスタンスを、これらのRuntimeServiceメソッドそれぞれの引数として渡します。

RuntimeServiceHandleの詳細は、「ランタイム・サービスへのアクセスおよびランタイム・サービス・ハンドルの取得方法」を参照してください。

表22-4 リクエスト・ログを処理するためのRuntimeServiceメソッド

メソッド

説明

getLogContentDetail(RuntimeServiceHandle handle, long requestId)

リクエストに対してContentDetailインスタンスをログ・コンテンツの詳細とともに返すか、ログが存在しない場合はNULLを返します。

openLogContent( RuntimeServiceHandle handle, long requestId )

指定されたリクエストに対して、リクエスト・ログを開いてログ・データを取得し、ContentHandleインスタンスを返します。ハンドルを使用して出力データを取得できます。ハンドルを解放するには、コンテンツを閉じる必要があります。

getLogLines( RuntimeServiceHandle handle, ContentHandle contentHandle, int maxLines )

リクエスト・ログから最大maxLines行の文字列配列を返します。最後のコールからこのメソッドまで続けられます。コンテンツ・ハンドルは、前のコールからopenLogContentまでです。これにより、ログから行の文字列配列が行終了文字なしで返されます。行がない場合、配列は空になります。

getTextContent( RuntimeServiceHandle handle, ContentHandle contentHandle, int maxChars )

ログまたは出力テキスト・コンテンツから、最大maxChars文字の文字配列を返します。

closeContent( RuntimeServiceHandle handle, ContentHandle contentHandle )

以前開いたログまたは出力コンテンツを閉じ、ハンドルを解放します。

22.2 リクエスト出力

ジョブを使用して実行時に出力コンテンツを作成できます。たとえば、ユーザーへのレポートで有用なデータをジョブで収集するとします。実行時に生成した出力は、クライアント・ユーザー・インタフェースまたはFusion Middleware Controlを使用して後から取得できます。

コードによって作成される出力は、Oracle Enterprise Schedulerコンテンツ・ストア内で直接作成でき、またファイル・システム内で作成しコンテンツ・ストアにインポートすることもできます。Oracle Enterprise Schedulerにより自動的にインポートすることも、ジョブでOracle Enterprise Scheduler APIを使用して明示的にインポートすることもできます。

ファイル・システムを使用する場合は、Oracle Enterprise Schedulerのess-config.xmlファイルで構成された場所にある特定のディレクトリに書き込みます。Oracle Enterprise Schedulerにより、すべてのリクエストから書き込まれたファイルを格納するためのリクエスト・ファイル・ディレクトリが作成されます。コードでは、リクエスト用に作成されたこのディレクトリのサブディレクトリに書き込みます。Oracle Enterprise Schedulerによって、すべてのリクエストの出力が自動的にコンテンツ・ストアにインポートされ、リクエスト固有のサブディレクトリは削除されます。

Oracle Enterprise Schedulerは、コンテンツ・ストア内の出力コンテンツを管理するためのAPIを提供します。

22.2.1 リクエスト・ファイル・ディレクトリの使用

リクエスト・ファイル・ディレクトリは、Oracle Enterprise Schedulerのess-config.xmlファイルで指定されます。Oracle Enterprise Schedulerでは、リクエストごとに、このリクエスト・ファイル・ディレクトリのリクエスト固有のサブディレクトリを作成できます。これは、一時ファイル用の作業ディレクトリおよびコンテンツ・ストアにインポートする必要がある出力ファイル用の出力ディレクトリです。

コードでは実行時に、それぞれのリクエスト固有のディレクトリに一時ファイルおよび出力ファイルを書き込むことができます。Oracle Enterprise Schedulerにより、リクエストの出力ディレクトリ内のファイルがコンテンツ・ストアにインポートされます。コンテンツのインポートのタイミングは、リクエスト・ファイル・ディレクトリが共有とローカルのどちらであるかに応じて異なります。「リクエスト・ファイル・ディレクトリの共通動作」、「共有リクエスト・ファイル・ディレクトリの動作」および「ローカル・リクエスト・ファイル・ディレクトリの動作」を参照してください。

リクエストのすべての出力がコンテンツ・ストアに自動的にインポートされた後、Oracle Enterprise Schedulerによって、リクエスト固有の出力ディレクトリとそのコンテンツが削除されます。

リクエスト・ファイル・ディレクトリはローカルにすることもでき、この場合、単一のサーバーでの作業にのみ使用することを意味します。または共有することもでき、この場合、複数のサーバーで実行される作業によって単一のディレクトリが使用されます。実行時の動作は、ディレクトリがローカルまたは共有のいずれに構成されているかによって異なります。

例22-4に示されているように、ディレクトリはess-config.xmlファイルで指定されます。Oracle Enterprise Schedulerは、RequestFileDirectoryに基づいてUSER_FILE_DIR (SYS_userFileDir)を設定し、プロパティを読取り専用にします。ジョブは、USER_FILE_DIRを設定することでこれをオーバーライドできません。

例22-4 ess-config.xmlファイルによるリクエスト・ファイル・ディレクトリの構成

<ess:EssConfig xmlns:ess="http://ess.oracle.com"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ess:EssProperties>
<ess:EssProperty key="RequestFileDirectory" value="/etc/outputfiles"
immutable="true"/>
<ess:EssProperty key="RequestFileDirectoryShared" value="false"
immutable="true"/>
</ess:EssProperties>
</ess:EssConfig>

22.2.1.1 リクエスト・ファイル・ディレクトリの共通動作

Oracle Enterprise Schedulerにより、出力ディレクトリからすべてのリクエスト出力ファイルがコンテンツ・ストアに自動的にインポートされ、リクエスト作業ディレクトリとそこに含まれるすべてのファイルが削除されます。

既存のコンテンツが以前にインポートされたものである場合には、常に、インポートされたファイルによって同じファイル名の既存のコンテンツが上書きされます。既存のコンテンツがAPIを使用して作成された場合は、新しいファイルと異なるものとみなされ、新しいファイルで上書きされずに無視されます。つまり、APIにより作成されたコンテンツが優先されます。

Oracle Enterprise Schedulerでは、長さゼロの出力ファイルはインポートされません。

22.2.1.2 共有リクエスト・ファイル・ディレクトリの動作

リクエストによって作成されたすべてのファイルは、リクエストが完了して終了状態になるまで、その作業ディレクトリおよび出力ディレクトリに保持されます。共有ファイル・ディレクトリにあるリクエストによって作成されたすべてのファイルは、リクエストのすべてのステージで使用できます。

22.2.1.2.1 共有リクエスト・ファイル・ディレクトリを使用する場合のエラー処理

Oracle Enterprise Schedulerによって、ジョブ・リクエストがRUNNING状態に遷移する前に、リクエスト作業ディレクトリが作成されます。ディレクトリの作成中にエラーが発生すると、常に、リクエストのシステム・エラーが発生します。

ジョブの処理では、ログのインポートはリクエストが終了状態に遷移した後に行われます。ログのインポート中にエラーが発生すると、エラーがログに記録され、リクエスト・ログがファイル・システム内に残されます。ログはコンテンツ・ストアに手動でインポートする必要があります。

すべてのジョブ・タイプで、出力ファイルのインポートはリクエストが終了状態に遷移した後に行われます。出力ファイルのインポート中にエラーが発生すると、エラーがログに記録され、ファイル・システム上の該当ディレクトリに出力ファイルが残されます。出力ファイルを削除する必要があります。

22.2.1.3 ローカル・リクエスト・ファイル・ディレクトリの動作

ステージのリクエストが実行される前には必ず、Oracle Enterprise Schedulerによって、リクエスト固有のディレクトリが作成されます。リクエスト・ファイル・ディレクトリがローカルである場合は、どのサーバーのローカルにも存在することが保証されている場所である必要があります。この場合、あるステージのリクエストによって作成されたファイルが、次のステージでも使用できるとは保証されません。これは、各ステージは独立した作業単位であり、異なるサーバーで実行される可能性があるためです。

ローカル・リクエスト・ファイル・ディレクトリには、Oracle Enterprise Schedulerによって各ステージに対するアクションが実行されることを除き、共通動作が適用されます。これは、各ステージが異なるサーバーで実行される場合があり、次のステージではファイルが存在しない可能性があることから、Oracle Enterprise Schedulerでは各ステージのファイルを取得してクリーン・アップする必要があるためです。

以前にインポートされたすべての出力ファイルにリクエストからアクセスする必要がある場合は、パラメータSYS_EXT_executeAutoExport = trueを設定できます。これが設定されている場合、実行ステージの始めに、以前にインポートされた出力ファイルがOracle Enterprise Schedulerによって自動的にリクエストの作業出力ディレクトリにエクスポートされます。これにより、実行ステージの終わりにファイルがコンテンツ・ストアに再びインポートされる前に、ファイルを更新できるようになります。(コンテンツがエクスポートされても、コンテンツ・ストアからコンテンツは削除されないことに注意してください。)さらに、Oracle Enterprise Schedulerには、以前にインポートされた出力ファイルをリクエストによって選択的にエクスポートするためのAPIが備えられています。

22.2.1.3.1 ローカル・リクエスト・ファイル・ディレクトリを使用する場合のエラー処理

ローカル・リクエスト・ファイル・ディレクトリを使用する場合、ファイルのインポートは各ステージ(前処理、実行、更新、後処理)の終わりに行われます。ログまたは出力ファイルのインポート中にエラーが発生した場合、インポートに失敗したログおよび出力ファイルはrequest_file_directory/preserveにあるミラー・ディレクトリに移動されます。たとえば、リクエスト18の場合は、request_file_directory/preserve/18になります。

前処理ステージでは、ステージの始めにリクエスト・ディレクトリを作成するときか、またはステージの終わりに出力ファイルをインポートするときにエラーが発生すると、リクエストに対するシステム・エラーが発生します。

後処理ステージでは、ステージの始めにリクエスト・ディレクトリを作成するときか、またはステージの終わりに出力ファイルをインポートするときにエラーが発生すると、リクエストに対する警告が発生します。

Javaジョブ、非同期Javaジョブおよびプロセス・ジョブ・リクエストの実行ステージでは、ステージの始めにリクエスト・ディレクトリを作成するときか、以前にインポートされた出力ファイルを自動的にエクスポートするとき(SYS_EXT_executeAutoExportシステム・プロパティを使用する場合など)、またはステージの終わりに出力ファイルをインポートするときにエラーが発生すると、リクエストに対するシステム・エラーが発生します。

リクエストがプロセス・ジョブの場合、リクエスト・ログをインポートするときに発生したエラーはログに記録され、エラーとして処理されません。ログはファイル・システム内に残され、コンテンツ・ストアに手動でインポートできます。プロセス・ジョブの実行中に内部エラーが発生した場合は、ジョブの実行を続行できるため、ジョブおよび出力ファイルはインポートされません。ログおよび出力ファイルは、ジョブの終了時に自動的またはユーザーにより手動でインポートされます。ジョブがERROR_MANUAL_RECOVERYに遷移した場合は、ユーザーがリクエスト・ログおよび出力ファイルをクリーン・アップする必要があります。

更新ステージでは、リクエスト・ディレクトリを作成するときか、または出力ファイルをインポートするときに発生したエラーは、ログに記録されるのみです。

22.2.2 システム・プロパティ

リクエスト・ファイル・ディレクトリを使用して出力ファイルを自動的にインポートする場合は、SYS_EXT_supportOutputFilesシステム・プロパティを設定する必要があります。

リクエストの出力ディレクトリを使用して出力ファイルを作成するには、ジョブでシステム・プロパティSYS_EXT_supportOutputFilesを使用してパラメータを定義する必要があります。ジョブで作成するファイルの種類に応じて、プロパティは次のいずれかの方法で設定できます。

- コンテンツ・ストアにインポートするファイルをリクエストの出力ディレクトリに書き込むには、「output」に設定します。

- 一時ファイルなど、インポートしないファイルをリクエスト作業ディレクトリに書き込むには、「work」に設定します。

- ジョブで出力ファイルや一時ファイルが作成されない場合は、「none」に設定するか、未定義のままにします。

表22-5 リクエスト出力を作成するためのシステム・プロパティ

メソッド

説明

SYS_EXT_supportOutputFiles

ジョブによりファイル・システムにファイルが作成されるかどうかを示す文字列プロパティ。サポートされる値は、work、outputおよびnoneです。無効な値はnoneとして処理されます。

SYS_EXT_executeAutoExport

以前にインポートされた出力ファイルを実行ステージの始めにエクスポートするかどうかを示すブール型プロパティ。コンテンツが自動的にエクスポートされても、コンテンツ・ストアからコンテンツは削除されません。

22.2.3 Javaジョブからのリクエスト出力の作成

Javaからリクエスト出力を作成するには、ジョブのコードで、Oracle Enterprise Scheduler APIを使用してコンテンツ・ストアに出力コンテンツを直接作成するか、ジョブによりファイル・システム内のリクエストの出力ディレクトリにファイルを作成できます。ジョブによりリクエストの出力ディレクトリにファイルが作成される場合、これらのファイルをコンテンツ・ストアに明示的にインポートするか、Oracle Enterprise Schedulerによりファイルをコンテンツ・ストアに自動的にインポートできます。

ジョブでは、APIを使用してテキストまたはバイナリ出力コンテンツを作成できます。インポートされる出力ファイルは常にバイナリ・コンテンツとしてインポートされます。つまり、バイトは解釈されません。

22.2.3.1 Javaジョブからのリクエスト出力を処理するためのAPI

リクエスト出力の処理に使用できるJava APIは次のとおりです。

- ContentFactoryクラスを使用して、RequestOutputおよびOutputContentHelper出力など、出力コンテンツを作成して管理するために使用できるその他のクラスのインスタンスを取得します。表22-6を参照してください。

- RequestOutputクラスを使用して、コンテンツ・ストアに出力コンテンツを直接作成します。表22-7を参照してください。

- OutputContentHelperクラスを使用して、リクエスト出力ファイル・ディレクトリにファイルとして作成したコンテンツを明示的に管理し、コンテンツ・ストアと相互作用します。表22-8を参照してください。

oracle.as.scheduler.request.ContentFactoryクラスには、コードが出力コンテンツ・フレームワークにアクセスしたり、出力自体を作成するために使用可能なインスタンスにアクセスできるメソッドが備えられています。

表22-6 Javaリクエスト出力用のContentFactoryメソッド

メソッド

説明

getRequestOutput( RuntimeServiceHandle rsh, long requestId, ContentType contentType, String contentName )

指定されたリクエストに対して出力とともにRequestOutputインスタンスを返し、そのリクエストの出力コンテンツを作成します。各書込みでは、指定されたリクエスト・サービス・ハンドルが使用されます。トランザクションのコミットまたはロールバックは、コール側のコードで行う必要があります。

getOutputContentHelper( long requestId )

StandardまたはExtendedリクエスト・モードで、リクエストに対して出力コンテンツを作成するためのOutputContentHelperインスタンスを返します。各操作が個別のトランザクションで実行されます。

getOutputContentHelper( long requestId, RuntimeServiceHandle rsh )

StandardまたはExtendedリクエスト・モードで、リクエストに対して出力コンテンツを作成するためのOutputContentHelperインスタンスを返します。各操作では指定されたハンドルが使用され、トランザクションのコミットまたはロールバックはコール元が行います。

oracle.as.scheduler.request.RequestOutputクラスは、コードによって作成される出力を表します。ContentFactory.getRequestOutputからこのクラスのインスタンスを取得してから、そのwriteメソッドを使用して作成中の出力コンテンツに書き込みます。

表22-7 Javaリクエスト出力用のRequestOutputメソッド

メソッド

説明

writeln( String str )

テキスト出力コンテンツに、strとそれに続く改行文字を付加します。

write( String str )

テキスト出力コンテンツにstrを付加します。

write( String str, int offset, int length )

テキスト出力コンテンツにstrを付加します。

write( char[] chars )

テキスト出力コンテンツにcharsを付加します。

write( char[] chars, int offset, int length )

テキスト出力コンテンツにcharsを付加します。

write( byte[] bytes )

バイナリ出力コンテンツにbytesを付加します。

write( byte[] bytes, int offset, int length )

バイナリ出力コンテンツにbytesを付加します。

oracle.as.scheduler.request.OutputContentHelperクラスのメソッドは、Javaジョブにおいて多くの出力ファイル処理を行います。コードでは、これらのメソッドを使用してリクエスト・ファイル・ディレクトリおよびコンテンツ・ストアそのものを操作できます。

コンテンツ・ストアにコンテンツをインポートするためのメソッドでは、インポート中にトランザクション・セマンティクスを指定するために使用できるOutputContentHelper.CommitSemantics列挙インスタンスを取得することに注意してください。詳細は、表22-9を参照してください。

表22-8 Javaリクエスト出力用のOutputContentHelperメソッド

メソッド

説明

workDirectoryExists( )

リクエストの作業ディレクトリが存在する場合にtrueを返します。任意のステージにあるジョブで、一時ファイルの作成を試行する前に、作業ディレクトリが存在するかどうかを判別できるようにします。

Oracle Enterprise Schedulerによって作業ディレクトリが作成されるようにするには、ジョブでSYS_EXT_supportOutputFilesシステム・プロパティにworkまたはoutputの値を定義する必要があります。

outputDirectoryExists( );

リクエストの出力ディレクトリが存在する場合にtrueを返します。更新などの任意のステージにあるジョブで、出力ファイルの作成を試行する前に、出力ディレクトリが存在するかどうかを判別できるようにします。

Oracle Enterprise Schedulerによって出力ディレクトリが作成されるようにするには、ジョブでSYS_EXT_supportOutputFilesシステム・プロパティにoutputの値を定義する必要があります。

isRequestWorkDirectoryShared( );

リクエスト・ファイル・ディレクトリが共有されている場合にtrueを返します。その場合、リクエストの作業ディレクトリまたは出力ディレクトリに、いずれかのステージにおいて作成されたすべてのファイルが、リクエストのそれ以降のすべてのステージで使用できるようになります。

getResolvedWorkDirectory( );

現在のサーバーに解決されるリクエスト作業ディレクトリを含む文字列を返します。ジョブでは作業ディレクトリに一時ファイルを作成でき、作業ディレクトリは、リクエストの実行終了時(RequestFileDirectoryが共有されている場合)または各ステージ(前処理、実行、更新、後処理)の終わり(RequestFileDirectoryがローカルである場合)に、Oracle Enterprise Schedulerによって自動的に削除されます。

getResolvedOutputDirectory( );

現在のサーバーに解決されるリクエストの出力ディレクトリを含む文字列を返します。ジョブでは、Oracle Enterprise Schedulerコンテンツ・ストアに自動的または手動でインポートできる出力ファイルを出力ディレクトリに作成できます。

importOutputFiles( List<String> fileNames, CommitSemantics semantics );

解決された出力ディレクトリから、指定されたファイルをインポートして、ImportExportResultインスタンスを返します。既存のコンテンツがAPIを使用して作成されている場合を除き、インポートされたコンテンツによって、同じ名前を持つ既存のコンテンツが上書きされます。その場合、ファイルはインポートされません。

importOutputFiles( CommitSemantics semantics );

解決された出力ディレクトリから、すべてのファイルをインポートして、ImportExportResultインスタンスを返します。既存のコンテンツがAPIを使用して作成されている場合を除き、インポートされたコンテンツによって、同じ名前を持つ既存のコンテンツが上書きされます。その場合、ファイルはインポートされません。

exportOutputContent( List<String> contentNames );

リクエストの出力ディレクトリ内のファイルに、指定された以前にインポート済の出力コンテンツをエクスポートして、ImportExportResultを返します。エクスポートされたファイルによって、同じ名前を持つすべての既存のファイルが上書きされます。APIを使用して作成された出力コンテンツはエクスポートできないことに注意してください。

exportOutputContent( );

以前にインポートされたすべての出力コンテンツをリクエストの出力ディレクトリ内のファイルにエクスポートして、ImportExportResultインスタンスを返します。エクスポートされたファイルによって、同じ名前を持つすべての既存のファイルが上書きされます。APIを使用して作成された出力コンテンツはエクスポートできないことに注意してください。

queryOutputContent( )

コンテンツ・ストア内にある既存の出力コンテンツすべての詳細情報とともにContentDetailインスタンスのリストを返します。ここでは、インポートされた出力コンテンツとAPIを使用して作成された出力コンテンツ両方の情報が返されます。

queryOutputContent( String contentName )

コンテンツ・ストア内に出力コンテンツがある場合は、その詳細情報とともにContentDetailインスタンスを返し、ない場合はNULLを返します。ここでは、インポートされた出力コンテンツとAPIを使用して作成された出力コンテンツ両方の情報が返されます。

outputContentExists( String contentName )

リクエストに対して、コンテンツ・ストア内に指定された出力コンテンツが存在する場合にtrueを返します。ここでは、インポートされた出力コンテンツとAPIを使用して作成された出力コンテンツの情報が返されます。

deleteOutputContent( List<String> contentNames )

リクエストに対して、コンテンツ・ストアから、指定された出力コンテンツを削除します。インポートされた出力コンテンツとAPIを使用して作成された出力コンテンツを削除できます。

コンテンツ・ストアにコンテンツをインポートしているときにエラーが発生した場合の動作を指定するには、oracle.as.scheduler.request.OutputContentHelper.CommitSemantics列挙を使用します。

表22-9 コミット・セマンティクスを表すCommitSemantics列挙メンバー

フィールド

説明

StopOnFirstError

1つのファイルにエラーがある場合に、すべてのファイルに対する操作を停止します。ハンドルが内部である場合、これはコミットされます。

IgnoreErrors

エラーに関係なく、すべてのファイルに対する操作を行います。ハンドルが内部である場合、これはコミットされます。

Transactional

いずれかのファイルにエラーがある場合に、すべてのファイルに対する操作を停止します。ユーザー指定のハンドルでは、これは無効です。

22.2.3.2 Javaリクエスト出力の例

例22-5は、RequestOutput APIを使用した出力コンテンツの作成方法を示しています。出力コンテンツは、コンテンツ・ストア内に直接作成されます。

例22-6は、リクエストの出力ディレクトリに出力ファイルを作成する方法を示しています。ジョブでSYS_EXT_supportOutputFilesシステム・プロパティをoutputとして定義する必要があることに注意してください。この例は、Javaジョブ、非同期Javaジョブ、プリプロセッサまたはポストプロセッサに適用されます。

次の例では、出力ファイルを手動でエクスポートおよびインポートする方法を示します。これは、更新中にファイルからコンテンツを作成する必要がある場合に役立ちます。インポートされたファイルのみをエクスポートでき、APIを使用して作成されたファイルはエクスポートできないことに注意してください。

例では、以前に作成された可能性のあるファイルを更新してインポートする必要があるというシナリオを示します。

import oracle.as.scheduler.request.ContentFactory;
import oracle.as.scheduler.request.ImportExportResult;
import oracle.as.scheduler.request.ImportExportResult.ImportExportStatus;
import oracle.as.scheduler.request.OutputContentHelper;
import oracle.as.scheduler.request.OutputContentHelper.CommitSemantics;

class ExampleExportImport{

OutputContentHelper helper = ContentFactory.getOutputContentHelper(requestId);

if (!helper.outputDirectoryExists())
{
// error - make sure job definition defines SYS_EXT_supportOutputFiles
}

String outputDir = helper.getResolvedOutputDirectory();
String fileName = "myfile.out";
List<String> fileNamesList = new ArrayList<String>();
fileNamesList.add(fileName);

// Export the file if it exists; otherwise, create it.

if (helper.outputContentExists(fileName))
{
ImportExportResult exportResult =                  helper.exportOutputContent(fileNamesList);
if (exportResult.getStatus() != ImportExportStatus.Success)
{
// handle error
}
}
else
{
File f = new File(outputDir, fileName);
f.createNewFile();
}

// ... update the file as needed ...

// Import the new or updated file.
// Updated file overwrites previous contents.

ImportExportResult importResult =
helper.importOutputFile(fileNamesList, CommitSemantics.IgnoreErrors);

if (importResult.getStatus() != ImportExportStatus.Success)
{
// handle error
}
}

例22-5 RequestOutputを使用した出力コンテンツの作成

import oracle.as.scheduler.request.ContentFactory;
import oracle.as.scheduler.request.ContentType;
import oracle.as.scheduler.request.RequestOutput;

class ExampleOutputContentCreator
{
RuntimeService runtimeService = getRuntimeService();
RuntimeServiceHandle handle;
try {
handle = runtimeService.open();
RequestOutput requestOutput = ContentFactory.getRequestOutput(
handle, requestId, ContentType.Text, “SampleOutput.txt");

requestOutput.writeln(“Output data in sample output content.");
}
finally {
runtimeService.close(handle);
}
}

例22-6 自動インポート用の出力ファイルの作成

import oracle.as.scheduler.request.ContentFactory;
import oracle.as.scheduler.request.OutputContentHelper;

class ExampleOutputCreator{

OutputContentHelper helper = ContentFactory.getOutputContentHelper(requestId);
String outputDir = helper.getResolvedOutputDirectory();

File f = new File(outputDir, "myfile");
f.createNewFile();
if (f.exists())
{
// write to file
}
}

22.2.4 PL/SQLジョブからのリクエスト出力の作成

PL/SQLからリクエスト出力を作成する場合は、コンテンツ・ストアに直接出力コンテンツを作成するために、コードでESS_JOB PL/SQLパッケージを使用できます。

ジョブでは、パッケージ内のファンクションおよびプロシージャを使用して、テキストまたはバイナリ出力コンテンツを作成できます。

22.2.4.1 出力を作成するためのPL/SQLパッケージ・サポート

表22-10 リクエスト出力用のESS_JOBプロシージャおよびファンクション

メソッド

説明

open_text_output_content( p_content_name in varchar2 ) return varchar2

open_binary_output_content( p_content_name in varchar2 ) return varchar2

現在のセッションに関連付けられているリクエストに対して、指定された出力コンテンツを開いてハンドルを返します。

適切なコンテンツ・タイプ定数によりopen_output_contentをコールする便利なファンクションです。詳細は、open_output_contentを参照してください。

open_output_content( p_content_name in varchar2, p_content_type in integer ) return varchar2;

現在のセッションに関連付けられているリクエストに対して、出力コンテンツp_content_nameを開いて不透明なハンドルを返します。

指定された名前の出力コンテンツ・エントリが存在しない場合、そのエントリが新規に作成されます。すでに存在する場合は、その名前に対して確立されているコンテンツ・タイプと指定されたコンテンツ・タイプが一致する必要があります。

p_content_typeは、次のいずれかのコンテンツ・タイプ定数を持つコンテンツ・タイプを表します。

CONTENT_TYPE_TEXT (値: 1)(テキスト・コンテンツの場合)

CONTENT_TYPE_BINARY (値: 2)(バイナリ・コンテンツの場合)

これにより、出力コンテンツを操作する後続プロシージャに渡される不透明なハンドルが返されます。

このファンクションから正しい結果が返されると、コンテンツ・エントリはロックされます。このプロシージャが失敗した場合は、ロックされる場合とされない場合とがあります。コミットまたはロールバックによりロックが解放されます。テキスト・コンテンツのデータを書き込むにはwrite_text_contentまたはwrite_ntext_contentプロシージャを、バイナリ・コンテンツのデータを書き込むにはwrite_binary_contentプロシージャを使用する必要があります。

このメソッドによって返されるハンドルに関連付けられているリソースを解放するには、close_contentをコールする必要があります。クローズはトランザクションのコミットまたはロールバックの前に行う必要があります。

注意: コンテンツ出力サポートにはDMLセマンティクスが含まれます。コミットおよびロールバックは、コール元が行います。

write_ntext_content( p_content_handle in varchar2, p_data in nvarchar2 )

write_text_content( p_content_handle in varchar2, p_data in varchar2 );

指定されたハンドルに関連付けられている出力コンテンツにデータをp_dataとして書き込みます。これらの操作は、CONTENT_TYPE_TEXTコンテンツ・タイプでのみサポートされます。

p_content_handleは、以前のopen_output_contentコールからの出力ハンドルです。

注意: コンテンツ出力サポートにはDMLセマンティクスが含まれます。コミットおよびロールバックは、コール元が行います。

write_binary_content( p_content_handle in varchar2, p_data in raw );

指定されたハンドルに関連付けられている出力コンテンツにバイナリ・データをp_dataとして書き込みます。この操作は、CONTENT_TYPE_BINARYコンテンツ・タイプでのみサポートされます。

p_content_handleは、以前のopen_output_contentコールからの出力ハンドルです。

注意: コンテンツ出力サポートにはDMLセマンティクスが含まれます。コミットおよびロールバックは、コール元が行います。

close_content( p_content_handle in varchar2 );

出力コンテンツ・ハンドルをクローズします。これにより、指定されたハンドルに関連付けられているリソースが解放され、ハンドルが無効になります。このメソッドは、トランザクションのコミットまたはロールバックより前にコールしてください。

p_content_handleは、以前のopen_output_contentコールからの出力ハンドルです。

注意: コンテンツ出力サポートにはDMLセマンティクスが含まれます。コミットおよびロールバックは、コール元が行います。このメソッドでは、コミットまたはロールバックは自動的には実行されません。

output_content_exists( p_content_name in varchar2 ) return boolean;

現在のセッションに関連付けられているリクエストに対して、指定された名前を持つ出力コンテンツ・エントリがすでに存在する場合はtrueを返します。

p_content_nameは、出力コンテンツ・エンティティの名前です。

delete_output_content( p_content_name in varchar2 );

現在のセッションに関連付けられているリクエストに対して、指定された出力コンテンツを削除します。

p_content_nameは、出力コンテンツ・エンティティの名前です。

22.2.4.2 PL/SQL出力作成の例

例22-7では、テキスト・コンテンツを出力に書き込む方法およびログ・エントリを書き込む方法を示します。

例22-8では、出力にバイナリ・コンテンツを書き込む方法を示します。

例22-7 PL/SQL出力作成の例

create or replace procedure text_output_example_job
( request_handle in varchar2 )
as
v_request_id  number := null;
v_content_name  varchar2(100) := 'mycontent.txt';
v_content_handle  varchar2(100);
v_ntext nvarchar2(100);
begin
ess_job.write_log(ess_job.LEVEL_FINE,
'TEXT_OUTPUT_EXAMPLE_JOB Procedure Begin');

-- Oracle Enterprise Scheduler request id being executed.
begin
v_request_id := ess_runtime.get_request_id(request_handle);
exception
when others then
ess_job.write_log(ess_job.LEVEL_SEVERE,
'Bad request handle: '||request_handle);
raise_application_error(-20000,
'Failed to get request id for request handle '||request_handle,
true);
end;

begin
-- ----------
-- Delete content entry if it already exists.
-- ----------
if (not ess_job.output_content_exists(v_content_name)) then
ess_job.write_log(ess_job.LEVEL_FINEST,
'Content does not exist: ' || v_content_name);
else
ess_job.write_log(ess_job.LEVEL_INFO,
'Deleting existing content: ' || v_content_name);
ess_job.delete_output_content(v_content_name);
commit;
end if;

-- ----------
-- Write text content. Source data has some non-ascii chars.
-- Illustrate multiple writes.
-- ----------
ess_job.write_log(ess_job.LEVEL_FINE,
'Write text content: '||v_content_name);

v_content_handle := null;
v_content_handle := ess_job.open_text_output_content(v_content_name);

ess_job.write_text_content(v_content_handle,
'Data ');
ess_job.write_ntext_content(v_content_handle,
unistr('(NTEXT data:\00c4\00c5)'));
ess_job.write_text_content(v_content_handle,
' for CONTENT ' || v_content_name);

ess_job.close_content(v_content_handle);
v_content_handle := null;
commit;
exception
when others then
ess_job.write_log(ess_job.LEVEL_WARNING,
'Error during text output operations. ' ||
'content: ' || v_content_name || chr(10) ||
'Error_Stack...' || chr(10) ||
dbms_utility.format_error_stack() || chr(10) ||
'Error_Backtace...' || chr(10) ||
dbms_utility.format_error_backtrace());
if v_content_handle is not null then
ess_job.close_content(v_content_handle);
v_content_handle := null;
end if;
rollback;
raise_application_error(-20000,
'Output content operations failed for '||v_content_name);
end;

ess_job.write_log(ess_job.level_info,
'TEXT_OUTPUT_EXAMPLE_JOB Procedure End');
end;
/

例22-8 リクエスト出力の手動エクスポートおよびインポート

create or replace procedure binary_output_example_job
( request_handle in varchar2 )
as
v_request_id  number := null;
v_content_name  varchar2(100) := 'mycontent.bin';
v_content_handle  varchar2(100);
v_nchar_cs varchar2(100);
v_dest_cs varchar2(100);
v_ntext nvarchar2(100);
v_raw raw(500);
begin
ess_job.write_log(ess_job.LEVEL_FINE,
'BINARY_OUTPUT_EXAMPLE_JOB Procedure Begin');

-- Oracle Enterprise Scheduler request id being executed.
begin
v_request_id := ess_runtime.get_request_id(request_handle);
exception
when others then
ess_job.write_log(ess_job.LEVEL_SEVERE,
'Bad request handle: '||request_handle);
raise_application_error(-20000,
'Failed to get request id for request handle '||request_handle,
true);
end;

begin
-- ----------
-- Delete content entry if it already exists.
-- ----------
if (not ess_job.output_content_exists(v_content_name)) then
ess_job.write_log(ess_job.LEVEL_FINEST,
'Content does not exist: ' || v_content_name);
else
ess_job.write_log(ess_job.LEVEL_INFO,
'Deleting existing content: ' || v_content_name);
ess_job.delete_output_content(v_content_name);
commit;
end if;

-- ----------
-- Write binary content.
-- This is the UTF-8 representation of a string for a known byte
-- encoding rather than whatever the charset/national charset
-- happens to be for this database.
-- Source data has couple non-ascii chars.
-- ----------

-- database national character set being used
select value into v_nchar_cs
from nls_database_parameters
where parameter = 'NLS_NCHAR_CHARACTERSET';
ess_job.write_log(ess_job.LEVEL_FINEST,
'NLS_NCHAR_CHARACTERSET = '||v_nchar_cs);

ess_job.write_log(ess_job.LEVEL_FINE,
'Write binary content: '||v_content_name);

v_content_handle := null;
v_content_handle := ess_job.open_binary_output_content(v_content_name);

v_ntext := unistr('Data (NTEXT data:\00c4\00c5) for CONTENT ' ||
v_content_name);

v_dest_cs := 'AL32UTF8';
v_raw := utl_raw.cast_to_raw(convert(v_ntext, v_dest_cs, v_nchar_cs));
ess_job.write_binary_content(v_content_handle, v_raw);
ess_job.write_log(ess_job.LEVEL_FINE,
'Wrote '||utl_raw.length(v_raw)||' bytes' ||
' using ' || v_dest_cs || ' charset');

ess_job.close_content(v_content_handle);
v_content_handle := null;
commit;
exception
when others then
ess_job.write_log(ess_job.LEVEL_WARNING,
'Error during binary output operations. ' ||
'content_name=' || v_content_name || chr(10) ||
'Error_Stack...' || chr(10) ||
dbms_utility.format_error_stack());
if v_content_handle is not null then
ess_job.close_content(v_content_handle);
v_content_handle := null;
end if;
rollback;
raise_application_error(-20000,
'Output content operations failed for '||v_content_name);
end;

ess_job.write_log(ess_job.level_info,
'BINARY_OUTPUT_EXAMPLE_JOB Procedure End');
end;
/

22.2.5 プロセス・ジョブからのリクエスト出力の作成

すべてのプロセス・ジョブで使用できるESS_OUTPUT_WORK_DIR環境変数により指定された場所にコンテンツを書き込むことによって、プロセス・ジョブ・ロジックから出力を作成します。他のジョブと同様に、SYS_EXT_supportOutputFilesシステム・プロパティがoutputに設定されており、ジョブに対して環境変数が定義されるようになっていることを確認してください。

プロセス・コードによりファイルが書き込まれると、Oracle Enterprise Schedulerにより自動的に、ディレクトリ内の出力ファイルがバイナリ・コンテンツとしてコンテンツ・ストアにインポートされます。

22.2.6 EJBジョブからのリクエスト出力の作成

EJBジョブから出力を作成する方法の詳細と例については、「EJBジョブからのリクエスト・ロギングおよび出力」を参照してください。

22.2.7 Webサービス・ジョブからのリクエスト出力の作成

同期および非同期のWebサービスの場合、リクエスト出力コンテンツは、次に説明するようにレスポンス・メッセージ・ペイロードから自動的に作成されます。出力コンテンツは、WebServiceJobOutput-REQUESTID.txt (REQUESTIDはリクエストのリクエストID)という名前のテキスト・データです。

同期Webサービスの場合、レスポンス・メッセージ・ペイロードはリクエスト出力として取得されます。

非同期Webサービスの場合、EssWsJobAsyncCallbackServiceで受信されるコールバック/レスポンス・メッセージ・ペイロードは、ジョブ・ステータスがSUCCESSになると取得されます。

22.2.8 リクエスト出力を処理するためのAPI

oracle.as.scheduler.RuntimeServiceクラスのメソッドを使用して、Oracle Enterprise Schedulerコンテンツ・ストアに格納されているリクエスト出力を処理できます。最初に、RuntimeServiceHandleインスタンスを取得する必要があります。このインスタンスを、これらのRuntimeServiceメソッドそれぞれの引数として渡します。RuntimeServiceHandleの詳細は、「ランタイム・サービスへのアクセスおよびランタイム・サービス・ハンドルの取得方法」を参照してください。

表22-11 リクエスト出力を処理するためのRuntimeServiceメソッド

メソッド

説明

getOutputContentDetail( RuntimeServiceHandle handle, long requestId, String contentName )

指定されたリクエストに対する指定された出力コンテンツのContentDetailインスタンスを返すか、コンテンツが存在しない場合はNULLを返します。

getOutputContentDetail( RuntimeServiceHandle handle, long requestId )

リクエストに対するすべての出力コンテンツのContentDetailリスト・インスタンスを返します。出力コンテンツがない場合、リストは空です。

openOutputContent( RuntimeServiceHandle handle, long requestId, String contentName )

指定されたリクエスト出力を開いて指定されたコンテンツの出力データを取得し、ContentHandleインスタンスを返します。ハンドルを使用して出力データを取得できます。ハンドルを解放するには、コンテンツを閉じる必要があります。

getTextContent( RuntimeServiceHandle handle, ContentHandle contentHandle, int maxChars )

ログまたは出力テキスト・コンテンツから、最大maxChars文字のchar配列を返します。

getBinaryContent( RuntimeServiceHandle handle, ContentHandle contentHandle, int maxBytes )

バイナリ・コンテンツから最大でmaxBytesバイトのバイト配列を返します。

closeContent( RuntimeServiceHandle handle, ContentHandle contentHandle )

以前開いたログまたは出力コンテンツを閉じ、ハンドルを解放します。

23 Oracle Enterprise Schedulerセキュリティ

この章では、リソースに対するアクセス制御およびジョブ実行に対するアプリケーション・アイデンティティ伝播を提供する、Oracle Enterprise Schedulerのセキュリティ機能について説明します。

この章の内容は次のとおりです。

- Oracle Enterprise Schedulerセキュリティの概要

- Oracle Enterprise Schedulerのメタデータのセキュリティの構成

- Oracle Enterprise Schedulerのデータのセキュリティの構成

- Oracle Enterprise SchedulerのWebサービス・セキュリティの構成

- Oracle Enterprise SchedulerのPL/SQLジョブのセキュリティの構成

- Oracle Enterprise Schedulerジョブに対する権限の昇格

- Oracle Enterprise Schedulerの単一のポリシー・ストライプの構成

23.1 Oracle Enterprise Schedulerセキュリティの概要

Oracle Enterprise Scheduler Securityでは、アプリケーション・アイデンティティの使用のためにMetadataServiceおよびサポートにおいて保護された操作が含まれます。

Oracle Enterprise Schedulerセキュリティには、次のことが含まれています。

- MetadataServiceに対する保護された操作。MetadataPermissionによって保護され、これにより、メタデータのアクセス制御が行われます。メタデータ・オブジェクトに対するアクセス制御。権限を持つユーザーのみが、ジョブの作成、削除および更新と、メタデータのスケジュールを行うことができます。詳細は、「Oracle Enterprise Schedulerのメタデータ・アクセス制御」を参照してください。

- アプリケーション・アイデンティティの使用のサポート。アプリケーション・アイデンティティを使用すると、発行元ユーザーに割り当てられている権限よりも高い権限を必要とするジョブを完了するために、権限を昇格できます。詳細は、「Oracle Enterprise Schedulerのジョブ実行のセキュリティ」を参照してください。

23.1.1 Oracle Enterprise Schedulerのメタデータ・アクセス制御

設計時に、メタデータ作成者は、どのジョブ機能がどのメタデータ・オブジェクトにアクセスできるかを決定する必要があります。これは、各メタデータ・オブジェクトを1つ以上のロールに関連付けて、各ロールに1つ以上のアクションを指定することによって表します。図23-1に、メタデータのセキュリティのサマリーを示します。

図23-1 Oracle Enterprise Schedulerのデザインタイム・メタデータのセキュリティ

23.1.2 Oracle Enterprise Schedulerのジョブ実行のセキュリティ

ジョブの発行中、ジョブ・リクエストを発行する権限を持つユーザーは、発行元ユーザーと呼ばれます。リクエストの実行時、すべてのユーザーのJavaコード(前処理、後処理、Javaジョブ、置換など)は、すべてのロールと資格証明が保持された状態で、発行元ユーザーとして実行されます。

ただし、ジョブ・メタデータにSYS_RUNAS_APPLICAITONIDを指定すると、ジョブは、昇格された権限のアプリケーションIDで実行されます。詳細は、「Oracle Enterprise Schedulerジョブに対する権限の昇格」を参照してください。

23.2 Oracle Enterprise Schedulerのメタデータのセキュリティの構成

ユーザーがRuntimeServiceまたはMetadataServiceを使用してOracle Enterprise Schedulerサービスにアクセスすると、ユーザーのアイデンティティが取得され、Oracle Enterprise Schedulerによって、リソース(メタデータ・オブジェクトなど)にアクセスするために必要な権限がこのユーザーにあるかどうかが確認されます。

たとえば、teller1という名前のユーザーがgetJobDefinitionをコールしてメタデータ・オブジェクトcalculateFeesにアクセスする必要がある場合、Oracle Enterprise Schedulerでは、オブジェクトを返す前に、メタデータ・オブジェクトcalculateFeesに対するREAD権限がteller1にあることを確認します。

設計時に、メタデータ作成者は、どのジョブ機能がどのメタデータ・オブジェクトにアクセスできるかを決定する必要があります。これは、各メタデータ・オブジェクトを1つ以上のロールに関連付けて、各ロールに1つ以上のアクションを指定することによって表します。

メタデータのロール割当てには、次の2つのオプションがあります。

- Oracle JDeveloperツールのOracle ADF Securityウィザードの使用

- Oracle JDeveloper Oracle Enterprise Schedulerのアドインであるメタデータ・ページの使用

Oracle JDeveloperのADFセキュリティ・ウィザードにより、使用するロールが作成されますが、ロールは、メタデータ・オブジェクトに登録する前に作成する必要があります。

23.2.1 Oracle ADF Securityウィザードを使用してアプリケーション・セキュリティを有効にする方法

これらの手順では、Oracle Enterprise Schedulerを使用したアプリケーションに対する最小の検証されたセキュリティ設定について説明します。

次の手順に従って、作業用のjps-config.xmlおよび一部移入されたjazn-data.xmlを作成します。これらの手順を使用して、JPSで使用するサーブレットを構成します。

ADFセキュリティ・ウィザードを使用してセキュリティを有効にする手順は、次のとおりです。

1. Oracle JDeveloperでアプリケーションを開き、「アプリケーション」メニューから「保護」を選択します。

2. ドロップダウン・リストから、「ADFセキュリティの構成」を選択します。「ADFセキュリティの構成」ウィザードが表示されます。

3. 「ADFセキュリティの有効化」ページで、「ADF認証および認可」または「ADF認証」のいずれかを選択して、「次へ」をクリックします。

4. 「認証タイプの選択」ページで、「HTTP Basic認証」または「フォームベース認証」のいずれかを選択して、「次へ」をクリックします。

5. 「自動ポリシー付与の有効化」ページで、「ADF認証および認可」→「フォームベース認証」を選択した場合、「自動付与の有効化」領域で適切なオプションを選択し、「次へ」をクリックします。

6. 「認証されたようこそページを指定」で必要に応じてオプションを選択し、「次へ」をクリックします。

7. 「サマリー」ページでオプションを検証して、「終了」をクリックします。

8. 「セキュリティ・インフラストラクチャが作成されました」ダイアログで、「OK」をクリックします。

23.2.2 EARファイルへのセキュリティ・ファイルの包含

セキュリティを有効にしてjazn-data.xmlがアプリケーション・デプロイメントに含まれていることを確認するには、アプリケーションのEARファイルをアセンブル後、次の手順を実行します。

1. Oracle JDeveloperで、「アプリケーション」→「アプリケーションのプロパティ」を選択します。

2. 「アプリケーションのプロパティ」ページのナビゲータで、「デプロイメント」を選択します。

3. 「デプロイメント・プロファイル」領域で、EARファイルのデプロイメント・ディスクリプタを選択します。

4. 「編集」をクリックします。これにより、「EARデプロイメント・プロファイルのプロパティの編集」ページが表示されます。

5. 「EARデプロイメント・プロファイルのプロパティの編集」ページで、「ファイル・グループ」→「アプリケーション・ディスクリプタ」→「フィルタ」を展開します。

6. 「フィルタ」領域で「ファイル」タブを選択します。

7. ファイルjazn-data.xml、jps-config.xmlおよびweblogic-application.xmlが、META-INFフォルダで選択されていることを確認します。

8. 「OK」をクリックしてディスクリプタを保存します。

23.2.3 セキュリティのプリンシパルの定義方法

ロールは、Oracle Enterprise Schedulerセキュリティで使用する前に、定義する必要があります。定義できるロールには、次の2つのタイプがあります。

- エンタープライズ・ロール: これらは、Oracle WebLogic Serverコンソール、WLSTスクリプト、またはOracle JDeveloperのADFセキュリティ・ウィザードを使用して、Oracle WebLogic Serverで直接定義します。

- アプリケーション・ロール: これらはjazn-data.xmlファイルで定義するか、またはADFセキュリティ・ウィザードを使用して定義できます。

アプリケーション・ロールを作成する手順は、次のとおりです。

1. Oracle JDeveloperでアプリケーションを開き、「アプリケーション・ナビゲータ」で「アプリケーション・リソース」を展開します。

2. 「アプリケーション・リソース」領域で、「ディスクリプタ」および「META-INF」を展開します。

3. META-INFで、ダブルクリックしてjazn-data.xmlを開きます。

4. jazn-data.xmlが表示されているページで、「アプリケーション・ロール」タブを選択します。「アプリケーション・ロール」タブが表示されない場合には、jazn-data.xmlを閉じてから再度開くようにしてください。

5. 「ロール」リスト内の「追加」ボタンをクリックして、「新しいロールの追加」を選択します。

6. 「名前」フィールドでEssApplicationRoleに名前を設定します。

図23-2 アプリケーション・ロールの作成

23.2.4 エンタープライズ・ロールの作成

エンタープライズ・ロールを作成する手順は、次のとおりです。

1. Oracle JDeveloperでアプリケーションを開き、「アプリケーション・ナビゲータ」で「アプリケーション・リソース」を展開します。

2. 「アプリケーション・リソース」領域で、「ディスクリプタ」および「META-INF」を展開します。

3. META-INFで、ダブルクリックしてjazn-data.xmlを開きます。

4. jazn-data.xmlが表示されているページで、「テスト・ユーザーとロール」タブを選択します。「テスト・ユーザーとロール」タブが表示されない場合には、jazn-data.xmlを閉じてから再度開くようにしてください。

5. 「エンタープライズ・ロール」タブを選択します。

6. 「ロール」リスト内の「追加」ボタンをクリックして、「新しいロールの追加」を選択します。

7. 「名前」フィールドでEssEnterpriseRoleに名前を設定します。

図23-3 エンタープライズ・ロールの作成

23.2.5 Oracle Enterprise Schedulerのメタデータ・ページを使用した権限の作成方法

すべてのメタデータへのアクセスは、権限によって制御されています。適切なアイデンティティによるアクセスを確実にするには、適切な権限を与える必要があります。ほとんどのメタデータの権限付与は、Oracle Enterprise Scheduler Oracle JDeveloperのアドインを使用して行われると想定されています。

最初に、「ファイル」→「新規」→「ビジネス層」→「エンタープライズ・スケジューラ・メタデータ」を使用して、必要な任意のOracle Enterprise Schedulerメタデータをアプリケーションに作成します。

Oracle JDeveloperを使用すると、セキュリティ権限をOracle Enterprise Schedulerのメタデータ・オブジェクトに追加できます。

Oracle Enterprise Schedulerのメタデータ・オブジェクトを保護する手順は、次のとおりです。

1. 任意のOracle Enterprise Schedulerのメタデータ・オブジェクトに対して「エディタ」ページを開きます。

2. 「アクセス制御」領域で、「追加」をクリックして新規アクセス制御項目を追加します。

3. 「アクセス制御の追加」ダイアログで、ドロップダウン・リストから「ロール」を選択します。これにより、アクセス権限を付与するロールが選択されます。

4. リストの「読取り」、「実行」、「更新」または「削除」から1つ以上のアクションを選択します。

5. 「OK」をクリックします。これにより、図23-4に示すように、更新されたロールが表示されます。

6. 必要な数のロールに対して繰り返します。

図23-4 Oracle Enterprise Schedulerメタデータのセキュリティ・ロール

23.2.6 MetadataPermission APIについて

メタデータに対する権限付与は、クラスoracle.as.scheduler. security.MetadataPermissionに含まれています。権限の名前またはターゲットはパッケージ、メタデータ・オブジェクト・タイプおよび保護されているメタデータ・オブジェクトの名前に基づいており、この識別子はMetdataObjectId#toPermissionString()から取得できます。

表23-1に、付与に対するアクションを示します。表記法<Type>は、すべてのメタデータ・オブジェクト・タイプに対するプレースホルダです。たとえば、get<Type>()は、メソッドgetJobDefinition()、getJobType()、getJobSet()を参照しています。

表23-1 メタデータのセキュリティに対する付与アクション

アクション

適用

メタデータ関数

READ

None

get<Type>()、query<Type>()

EXECUTE

READ

submitRequest()

CREATE

READ

add<Type>()

UPDATE

READ

update<Type>()

DELETE

READ

delete<Type>()

非定型リクエストを発行する場合は、EXECUTEとCREATEの両方のアクションについて、完全なワイルドカード(*)権限を持つことができます。つまり、特定のMetadataObjectIdsなしでsubmitRequest()を使用して非定型リクエストを発行する場合は、EXECUTEおよびCREATEのアクションを使用して、完全なワイルドカード(*)の権限を付与できます。

23.2.7 メタデータのセキュリティの構成時の処理内容

ユーザー・アプリケーションによってMetdataServiceまたはRuntimeServiceメソッドがコールされるたびに、Oracle Enterprise Schedulerでは、メソッドによってアクセスされるメタデータに対する権限について、現在のサブジェクトを確認します。たとえば、リクエストを発行するには、発行に関連付けられるジョブ定義やジョブ・セットのメタデータ・オブジェクトに対するEXECUTE権限が必要です。updateJobDefinition()をコールするなど、メタデータを変更するメソッドには、UPDATE権限が必要となります。

問合せを除くすべてのMetadataServiceメソッドでは、ユーザーが権限のないメタデータ・オブジェクトにアクセスしようとすると、例外がスローされます。

MetadataService問合せメソッドの場合には動作が異なります。ユーザーが問合せを実行すると、Oracle Enterprise Schedulerにより、READ権限のあるメタデータ・オブジェクトのみが返されます。これにより、メタデータ・オブジェクトに対して権限がないユーザーはすべての問合せについて空のリストを受信しますが、このユーザーには権限がないため、スローされた例外は表示されません。

SystemProperty.USER_NAMEの値は発行時に上書きされるため、ユーザーが発行時にSystemProperty.USER_NAMEを使用して、アイデンティティを偽装することはできません。

23.3 Oracle Enterprise Schedulerのデータのセキュリティの構成

Oracle Enterprise Schedulerスタンドアロン・データ・セキュリティ実装は、RuntimeDataPermissionクラスを使用する機能セキュリティ権限のチェックに基づきます。

デフォルトで、Oracle Enterprise Schedulerは次のレベルのデータ・セキュリティ施行をサポートします。

- ユーザーは、自分が発行するリクエストのみを操作できます。

- ユーザーに管理、オペレータまたはモニター・ロールを割り当てることで、リクエストの発行者にかかわらず、すべてのリクエストを表示する権限がユーザーに付与されます。

- ユーザーは、自分が発行または実行したリクエストによって生成された出力を表示できます。

デフォルトのデータ・セキュリティ権限を追加または変更する場合、「データ・セキュリティ権限の変更方法」の説明に従って、jazn-data.xmlファイルを再構成する必要があります。

23.3.1 データ・セキュリティ権限の変更方法

この項では、「Oracle Enterprise Schedulerのデータ・セキュリティの構成」の説明に従い、即時利用可能なデフォルト設定からジョブ・リクエストのデータ・セキュリティを変更するようにjazn-data.xmlファイルを構成する方法について説明します。

RuntmeDataPermissionを定義するjazn-data.xml権限セクションの例を次に示します。

<permission>
<name>definition like 'oracle.apps.ess.custom.soa.*',product like         "SOA%",PROPERTY1=VALUE1</name>
<class>oracle.as.scheduler.security.RuntimeDataPermission</class>
<actions>ESS_REQUEST_READ,ESS_REQUEST_OUTPUT_READ</actions>
</permission

前述の例で定義されている権限条件では、ジョブ・リクエストが次の条件と一致した場合、ジョブ・リクエストの詳細およびジョブ・リクエスト出力の読取り権限が付与されます。

- そのジョブ定義がパターン: oracle.apps.ess.custom.soa.*と一致し、

- 製品フィールドの値がSOAであり、

- PROPERTY1という名前のユーザー定義プロパティが、VALUE1という値で設定されています。

23.3.1.1 条件

条件は、<name>要素で指定され、=およびlike/LIKE演算子を使用します。%および*のワイルドカード文字は、like/LIKE演算子とともに使用できます。メタデータ・オブジェクト名を指定するフィールド名では%ワイルドカード文字を使用できませんが、フィールド名が別のデータ(製品など)およびリクエスト・カテゴリを指定している場合使用できます。たとえば、次の例は正しく機能します。

- definition LIKE 'oracle.apps.ess.custom.soa.*'

- requestCategory LIKE 'EssFineGrained%',workAssignment LIKE'FineGrainedWA%',className LIKE '%BasicJavaJob%'

一方、次のエントリは正しく機能しません。

- definition LIKE 'oracle.apps.ess.custom.soa.%'

条件は、次の固有のデリミタ構文を使用したキーと値のペアのセットとして指定されます。

- 条件内のキーと値のペアは、「,」文字で区切られます。

- 空白文字は、「,」デリミタの直前または直後には指定できません。

- キーと値の条件の値部分は引用符なしとするか、一重引用符または二重引用符で囲むことができます。

- 同じ要素内で指定されている複数の条件は、論理的にAND演算されるように解釈されます。

- 同じ権限受領者に2つ以上の権限リソースを定義することで、論理的にOR条件を指定できます。

次のルールが、フィールド名およびreqPropキーに適用されます。

- フィールド名は、RuntimeService.QueryFieldのfieldNameで表される値である必要があります。たとえば、QueryField.DEFINITION.fieldName()のように指定します。

- ResultIndexのリクエスト履歴ビューに同等のフィールドがないため、ResultIndexをフィールド名として指定できません。リクエスト履歴ビューは、Request_history表から作成されるデータベース・ビューです。スタンドアロン・データ・セキュリティのSQL問合せは、このビューに対して実行されます。

- reqPropは、Oracle Enterprise Schedulerジョブ・メタデータで、またはリクエスト発行時に定義されるユーザー・プロパティです。たとえば、PARTITION_NAME='SOA'などです。

- 表23-2に、有効なフィールド名のリストと、対応するリクエスト履歴ビューの列エントリを示します。

表23-2 条件問合せフィールドと、対応するリクエスト履歴ビューの列エントリ

問合せフィールド

リクエスト履歴ビューの列

QueryField.REQUESTID

requestid

QueryField.APPLICATION

application

QueryField.USERNAME

userName

QueryField.PRODUCT

product

QueryField.REQUEST_CATEGORY

requestCategory

QueryField.PRIORITY

priority

QueryField.NAME

name

QueryField.ABSPARENTID

absParentId

QueryField.TYPE

type

QueryField.DEFINITION

definition

QueryField.STATE

state

QueryField.SCHEDULE

schedule

QueryField.PROCESSSTART

processStart

QueryField.PROCESSEND

processEnd

QueryField.REQUESTEDSTART

requestedStart

QueryField.REQUESTEDEND

requestedEnd

QueryField.SUBMISSION

submission

QueryField.PARENTREQUESTID

parentRequestId

QueryField.WORKASSIGNMENT

workAssignment

QueryField.SCHEDULE

scheduled

QueryField.REQUESTTRIGGER

requesttrigger

QueryField.PROCESSOR

processor

QueryField.CLASSNAME

processor

QueryField.ELAPSEDTIME

elapsedtime

QueryField.WAITTIME

waittime

QueryField.SUBMITTER

submitter

QueryField.SUBMITTERGUID

submitterguid

23.3.1.1.1 条件の例

次の例は、有効に指定された条件を示しています。

• fieldName=value
• fieldName like 'value%'
• fieldName like "value*"
• reqProp="value"
• reqProp LIKE "value*"
• PermissionName : <name>fieldName1=value1,fieldName2 like 'value2%',reqProp="value",reqProp like 'value*'</name>

23.3.1.2 処置

使用な可能なアクションには、次の組合せです。

- ESS_REQUEST_READ

- ESS_REQUEST_UPDATE

- ESS_REQUEST_HOLD

- ESS_REQUEST_CANCEL

- ESS_REQUEST_LOCK

- ESS_REQUEST_RELEASE

- ESS_REQUEST_DELETE

- ESS_REQUEST_PURGE

- ESS_REQUEST_OUTPUT_READ

- ESS_REQUEST_OUTPUT_DELETE

23.3.2 例

例23-1に、権限を<permission>要素でどのように直接指定するかを示します。

例23-2に、権限セットを使用して権限をどのように指定するかを示します。

注意:

<permission-sets> - <permission-set> - <member-resources> - <member-resource> - <resource-name>要素で定義される内容は、<resources> - <resource> - <name>要素で定義される内容と同じである必要があります。

例23-1 PL/SQLのリクエスト・テキスト出力

<app-roles>
<app-role>
<name>riyanu_soa_role</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<name>riyanu_soa_group</name>
<class>weblogic.security.principal.WLSGroupImpl</class>
</member>
</members>
</app-role>
</app-roles>
<grant>
<grantee>
<description>Allow soa role to pass through</description>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>riyanu_soa_role</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<name>oracle.apps.ess.custom.soa.*</name>
<class>oracle.as.scheduler.security.MetadataPermission</class>
<actions>READ,EXECUTE,CREATE,DELETE,UPDATE</actions>
</permission>
<permission>
<name>definition like oracle.apps.ess.custom.soa.*,           partitionName=SOA_PARTITION,product=SOA</name>
<class>oracle.as.scheduler.security.RuntimeDataPermission</class>
<actions>ESS_REQUEST_READ,ESS_REQUEST_UPDATE,              ESS_REQUEST_OUTPUT_READ</actions>
</permission>
</permissions>
</grant>

例23-2 PLSQLのリクエスト・バイナリ出力の例

<app-roles>
<app-role>
<name>riyanu_soa_role</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<name>riyanu_soa_group</name>
<class>weblogic.security.principal.WLSGroupImpl</class>
</member>
</members>
</app-role>
</app-roles>
<resource-types>
<resource-type>
<name>ESSSOAMetadataResourceType</name>
<display-name>ESSSOAMetadataResourceType</display-name>
<description>ESS SOA Metadata Resource</description>
<matcher-class>oracle.as.scheduler.security.MetadataPermission</matcher-class>
<actions-delimiter>,</actions-delimiter>
<actions>create,read,update,delete,execute</actions>
</resource-type>
<resource-type>
<name>ESSSOARequestResourceType</name>
<display-name>ESSSOARequestResourceType</display-name>
<description>Resource type for simple ESS request accesscontrol</description>
<matcher-class>oracle.as.scheduler.security.RuntimeDataPermission     </matcher-class>
<actions-delimiter>,</actions-delimiter>
<actions>ESS_REQUEST_READ,ESS_REQUEST_UPDATE,ESS_REQUEST_CANCEL,     ESS_REQUEST_DELETE,ESS_REQUEST_OUTPUT_READ</actions>
</resource-type>
</resource-types>
<resources>
<resource>
<name>oracle.apps.ess.custom.soa.*</name>
<type-name-ref>ESSSOAMetadataResourceType</type-name-ref>
<description>All SOA ESS metadata</description>
<display-name>All SOA ESS metaddata</display-name>
</resource>
<resource>
<name>definition like "oracle.apps.ess.custom.soa.*",        partitionName=SOA_PARTITION,product=SOA</name>
<type-name-ref>ESSSOARequestResourceType</type-name-ref>
<description>Any ESS Multi request</description>
<display-name>Any ESS Multi request</display-name>
</resource>
</resources>
<permission-sets>
<permission-set>
<name>READ_ALL_SOA_MULTI_METADATA_RIYANU</name>
<display-name>Read privilege on all SOA ESS metadata
</display-name>
<description>Read privilege on all SOA ESS metadata</description>
<member-resources>
<member-resource>
<type-name-ref>ESSSOAMetadataResourceType</type-name-ref>
<resource-name>oracle.apps.ess.custom.soa.*</resource-name>
<actions>create,read,execute</actions>
</member-resource>
</member-resources>
</permission-set>
<permission-set>
<name>READ_ALL_ESS_SOA_REQUESTS_RIYANU</name>
<display-name>All privileges on all ESS Requests</display-name>
<description>Allow read, update, cancel, hold, delete all the ESS      requests</description>
<member-resources>
<member-resource>
<type-name-ref>ESSSOARequestResourceType</type-name-ref>
<resource-name>definition like        "oracle.apps.ess.custom.soa.*",         partitionName=SOA_PARTITION,product=SOA</resourcename>
<actions>ESS_REQUEST_READ,ESS_REQUEST_OUTPUT_READ</actions>
</member-resource>
</member-resources>
</permission-set>
</permission-sets>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>riyanu_soa_role</name>
</principal>
</principals>
</grantee>
<permission-set-refs>
<permission-set-ref>
<name>READ_ALL_SOA_MULTI_METADATA_RIYANU</name>
</permission-set-ref>
<permission-set-ref>
<name>READ_ALL_ESS_SOA_REQUESTS_RIYANU</name>
</permission-set-ref>
</permission-set-refs>
</grant>
</jazn-policy>

23.4 Oracle Enterprise SchedulerのWebサービス・セキュリティの構成

Oracle Enterprise Scheduler Webサービスの保護の詳細は、「Oracle Enterprise Scheduler Webサービスの使用」を参照してください。

23.5 Oracle Enterprise SchedulerのPL/SQLジョブのセキュリティの構成

PL/SQLジョブでは、ess_runtimeパッケージのAPIをコールするときに、データのセキュリティ・チェックを行いません。

23.6 Oracle Enterprise Schedulerジョブに対する権限の昇格

ユーザーがOracle Enterprise SchedulerサービスにRuntimeServiceまたはMetadataServiceインタフェースを使用してアクセスする場合、メソッドをコールしているユーザーのアイデンティティが取得されます。特定のリソース(メタデータ・オブジェクトなど)へのアクセスに必要な権限がユーザーにあるかどうかを確認するために、このアイデンティティが使用されます。

たとえば、ユーザーteller1がメソッドgetJobDefinitionをメタデータ・オブジェクトcaclulateFeesに対してコールする場合、Oracle Enterprise Schedulerでは、オブジェクトを返す前に、メタデータ・オブジェクトcaclulateFeesに対する読取り権限がteller1にあることを確認します。

コール元のアイデンティティは、ユーザーによってリクエストされたジョブの実行にも使用されます。たとえば、ユーザーteller1がメソッドsubmitRequest()をJavaジョブに対してコールする場合、リクエストされたジョブはteller1の下で実行され、そのユーザーに対して割り当てられたロールおよび資格証明はすべて保持されます。

Oracle Enterprise Schedulerでは、アプリケーション・アイデンティティの使用がサポートされています。アプリケーション・アイデンティティを使用すると、発行元ユーザーに割り当てられている権限よりも高い権限を必要とするジョブを完了するために、権限を昇格できます。

23.7 Oracle Enterprise Schedulerの単一のポリシー・ストライプの構成

Oracle Platform Securityポリシー・ストアは、認可ポリシーのリポジトリとして機能します。認可ポリシーは実行時にJava仮想マシンにロードされ、認可に関する決定を行うために使用されます。認可ポリシーは、アプリケーション・ロールの階層、エンタープライズ・ロールのアプリケーション・ロールへのマッピングおよびアプリケーション・ロールへの権限付与で構成されています。アプリケーション・ロールを階層的にすることもできます。

認可ポリシーに加えて、Oracle Platform Securityポリシー・ストアには、これらの認可ポリシーを保持するのに役立つ管理構成(関連するリソース・タイプを含むリソース・カタログ、権限セット、ロール・カテゴリなど)も格納されます。認可ポリシーおよび管理コンポーネントは、アプリケーションにスコープされています。これは、アプリケーション・ストライプと呼ばれます。

アプリケーション・ストライプとは、JAASポリシーのコレクションのことで、それが関連付けられたアプリケーションに適用可能です。購入した時点で、1つのアプリケーション・ストライプが1つのOracle Java EEアプリケーションにマップされています。Oracle Platform Securityでは、複数のJava EEアプリケーションの1つのアプリケーション・ストライプに対するマッピングもサポートされています。アプリケーションID文字列によって、1つまたは複数のアプリケーションの名前が識別されます。

23.7.1 Oracle Enterprise Schedulerの単一のポリシー・ストライプの構成方法

Oracle Enterprise Schedulerを使用すると、applicationStripe名を指定して、JPSポリシー・コンテキストIDにマッピングできます。アプリケーションをホストする複数のOracle Enterprise Schedulerを単一のポリシー・コンテキストに割り当てることができます。

アプリケーションをホストするOracle Enterprise Schedulerを特定のapplicationStripeに対して構成する手順は、次のとおりです。

1. ejb-jar.xmlファイルを開きます。

2. message-driven要素で、値applicationStripeを含むactivation-config-properties要素を追加します。

3. jpsinterceptor-class要素で、JpsInterceptorを構成します。

<message-driven>要素の下にあるapplicationStripe値が、<interceptor>要素の下にあるapplication.name値と必ず一致するようにしてください。

例23-3に、ポリシー・コンテキストESS_FUNCTIONAL_TEST_APP_STRIPEに対するapplicationStripe構成を示します。

4. アプリケーションにWebモジュールが含まれている場合、web.xmlファイルで、WebモジュールJpsFilterによって同じapplicationStripeが使用されるように構成します。例23-4に、コード・サンプルを示します。

例23-3 applicationStripeおよびJpsInterceptorの構成

<ejb-jar>
....

<enterprise-beans>
<message-driven>
<ejb-name>ESSAppEndpoint</ejb-name>
<ejb-class>oracle.as.scheduler.ejb.EssAppEndpointBean</ejb-class>
<activation-config>
....
<activation-config-property>
<activation-config-property-name>applicationStripe</activation-config-property-name>
<activation-config-property-value>ESS_FUNCTIONAL_TESTS_APP_
STRIPE</activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>
.....

</enterprise-beans>

<interceptors>
<interceptor>
<interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
<env-entry>
<env-entry-name>application.name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>ESS_FUNCTIONAL_TESTS_APP_STRIPE</env-entry-value>
<injection-target>
<injection-target-class>oracle.security.jps.ee.ejb.JpsInterceptor
</injection-target-class>
<injection-target-name>application_name</injection-target-name>
</injection-target>
</env-entry>
</interceptor>
</interceptors>
</ejb-jar>

例23-4 web.xmlでのWebモジュールの構成

<web-app>
<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
...
<init-param>
<param-name>application.name</param-name>
<param-value>ESS_FUNCTIONAL_TESTS_APP_STRIPE</param-value>
</init-param>
</filter>

</web-app>

23.7.2 単一のポリシー・ストライプの構成時の処理内容

設計時には、アプリケーション・ストライプは次のものとして表されます。

- jazn-data.xmlファイルの<policystore>要素の下の<application>要素

- ノードcn=<Weblogic.domain.name>,cn=JPSContext,cn=<root.node>の下のノード(cn=ATGDemo,cn=base_domain,cn=JPSContext,cn=MY_Nodeなど)

23.7.3 実行時の処理

実行時には、アプリケーション・ストライプは、クラスoracle.security.jps.service.policystore.ApplicationPolicyのインスタンスとして表されます。