Oracle Enterprise Manager

Cloud Control拡張プログラマーズ・ガイド

12c リリース4 (12.1.0.4)

B70508-04(原本部品番号:E25159-10)

2014年5月

Oracle Enterprise Manager Cloud Control拡張プログラマーズ・ガイド, 12c リリース4 (12.1.0.4)

B70508-04

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

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

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

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

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

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

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

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

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

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

1 Enterprise Managerの拡張の概要

- 1.1 Oracle Enterprise Managerプラットフォームの概要

- 1.1.1 Oracle Management Service

- 1.1.2 管理リポジトリ

- 1.1.3 管理エージェント

- 1.1.4 Enterprise Managerへのインタフェース

- 1.2 Oracle Management Serviceについて

- 1.2.1 Cloud Controlコンソール

- 1.3 Oracle Management Agentについて

- 1.3.1 管理エージェントのアーキテクチャにおける変更

- 1.4 Oracle Management Repositoryについて

- 1.5 メタデータ・プラグインについて

- 1.6 プラグインの新機能

2 Enterprise Managerプラグインのスタート・ガイド

- 2.1 プラグインとは

- 2.2 Enterprise Managerプラグインの新機能

- 2.3 拡張開発キット(EDK)について

- 2.3.1 EDKの内容

- 2.4 拡張開発キット(EDK)のインストール

- 2.5 プラグイン開発サイクル

- 2.5.1 プラグイン・メタデータの設計

- 2.6 プラグインの内容およびパッケージ化

- 2.6.1 プラグイン・メタデータ

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

- 2.6.3 プラグインのパッケージ化構造

- 2.7 プラグインのリリース

- 2.8 プラグインのデプロイ

- 2.8.1 検出時の自動デプロイ

- 2.8.2 プラグインのアップグレード

- 2.8.3 プラグインのアンデプロイ

3 管理対象ターゲットについて

- 3.1 管理対象ターゲットの概要

- 3.2 管理対象ターゲットの新機能

- 3.3 ターゲット・モデルについて

- 3.3.1 管理可能なエンティティ(ME)

- 3.3.2 管理対象ターゲット

- 3.3.3 グループ

- 3.3.4 システム

- 3.3.5 コンポジット・ターゲット

- 3.3.6 システム・ターゲット

- 3.3.7 サービス

- 3.3.8 サポートされる管理機能

4 エンタープライズ構成管理について

- 4.1 エンタープライズ構成管理の概要

- 4.2 エンタープライズ構成管理の新機能

- 4.3 構成について

- 4.3.1 構成の表示および検索

- 4.3.2 構成の比較

- 4.3.3 構成の保存

- 4.4 アソシエーションおよびトポロジについて

5 導出されたアソシエーションの使用方法

- 5.1 概要

- 5.2 Enterprise Managerのアソシエーションの概念について

- 5.2.1 アソシエーション導出の使用方法

- 5.3 アソシエーション導出ルール管理の使用方法

- 5.3.1 すぐに使用できるアソシエーション・タイプについて

- 5.3.2 プラグイン開発者の担当作業の概要

- 5.3.3 パフォーマンスの維持

- 5.4 オーバーラップ・アソシエーションについて

- 5.4.1 ルールによって導出されたアソシエーション間のオーバーラップについて

- 5.5 よくある質問

- 5.5.1 ルール問合せではどの表を参照できますか。

- 5.5.2 ターゲット・プロパティを使用するときのガイドラインはありますか。

- 5.5.3 検出されたアソシエーションと導出されたアソシエーションはどのような関係ですか。

6 ジョブ・フレームワークの使用方法

- 6.1 ジョブ・フレームワークの概要

- 6.2 ジョブの新機能

- 6.2.1 資格証明拡張機能について

- 6.2.2 ロギング拡張機能の概要

- 6.3 ジョブについて

- 6.3.1 ジョブ・タイプの定義

7 レポート作成フレームワークの使用方法

- 7.1 レポート作成フレームワークの概要

- 7.2 レポート作成の新機能

- 7.3 レポート作成テクノロジの選択

- 7.4 BI Publisherレポートの開発

- 7.5 Enterprise Manager情報パブリッシャ・レポートの開発

8 管理ユーザー・インタフェースについて

- 8.1 MPCUIフレームワークの概要

- 8.2 メタデータのみまたはFlexユーザー・インタフェースの作成

- 8.2.1 ユーザー・インタフェースのコンポーネント

- 8.3 MPCUIについて

- 8.3.1 概要

- 8.3.2 UIフレームワークについて

- 8.4 MPCUIサービス

- 8.5 MPCUIおよび拡張開発者キット

9 検出について

- 9.1 自動検出の概説

- 9.1.1 自動検出を追加する主な利点

- 9.2 検出の新機能

- 9.3 自動検出の概要

10 コンプライアンス標準について

- 10.1 コンプライアンス管理ソリューションについて

- 10.2 コンプライアンス管理の新機能

- 10.3 コンプライアンス管理の概要

- 10.3.1 コンプライアンス・フレームワークについて

- 10.3.2 コンプライアンス標準について

- 10.3.3 コンプライアンス標準ルールについて

- 10.3.4 コンプライアンス標準の作成に関する考慮事項

- 10.3.5 コンプライアンス評価について

11 ソフトウェア・ライブラリについて

- 11.1 ソフトウェア・ライブラリ・フレームワークの概要

- 11.2 ソフトウェア・ライブラリ・フレームワークの主要機能

- 11.3 ソフトウェア・ライブラリの拡張性の概念

- 11.4 ソフトウェア・ライブラリを拡張するためのメタデータの定義

- 11.5 ソフトウェア・ライブラリ・エンティティの作成と管理

- 11.5.1 Enterprise Manager Cloud Control

- 11.5.2 Enterprise Managerコマンドライン・インタフェース(EMCLI)

- 11.6 ソフトウェア・ライブラリ・エンティティの使用

索引

はじめに

このマニュアルでは、Enterprise Manager製品とそのアーキテクチャの簡単な概要を示し、新しいターゲット・タイプまたはカスタマイズされたターゲット・タイプ用に製品機能を拡張するためのインタフェースを提供する各サブシステムについて説明します。

各項では、特定のサブシステムの概要を示し、Enterprise Managerエンドユーザーに公開されている機能と、プラグイン開発者が提供されたインタフェースを利用してEnterprise Managerに追加されている新しいターゲット・タイプに対してそれらの機能をサポートする方法について説明します。

このマニュアルはリファレンス・ガイドではないため、APIの詳細を含めこれらのインタフェースの詳細は記載されていません。それらの詳細は、Oracle Enterprise Manager Cloud Control拡張リファレンス・ガイドおよび各APIのドキュメントを参照してください。

注意:
このマニュアルの最新バージョンは、Oracle Enterprise Managerオンライン・ドキュメント・セットの拡張性ページにアクセスしてください。

http://www.oracle.com/pls/em121/homepage

対象読者

このマニュアルは、カスタム・ターゲット・タイプを管理する機能をサポートするようにOracle Enterprise Managerを拡張したり、すぐに使用できるターゲット・タイプの管理のしやすさを拡張する開発者を対象としています。このドキュメントでは、Enterprise Managerとそのコア機能および概念について基本的な知識があることを前提にしています。

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

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

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 Enterprise Managerの詳細は、Oracle Enterprise Managerオンライン・ドキュメント・セットを参照してください。

http://www.oracle.com/pls/em121/homepage

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

1 Enterprise Managerの拡張の概要

Oracle Enterprise Managerは、様々なOracleテクノロジおよびOracle以外のテクノロジを管理するOracleの管理製品スイートです。Enterprise Managerという名前は、実際には単一の製品を指すのではなく、製品のポートフォリオを指します。製品ポートフォリオの最上位に、Oracle Enterprise ManagerがOracle Database、Oracle Fusion MiddlewareおよびOracle Fusion Applicationsを含め、様々なテクノロジを管理するコンソールのセットで構成されています。

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

- Oracle Enterprise Managerプラットフォームの概要

- Oracle Management Serviceについて

- Oracle Management Agentについて

- Oracle Management Repositoryについて

- メタデータ・プラグインについて

- プラグインの新機能

1.1 Oracle Enterprise Managerプラットフォームの概要

Cloud Controlは、管理ツールを構築するための軽量、多層の拡張可能なプラットフォームを基盤としています。フレームワークは、Fusion Middlewareプラットフォームに基づいて構築されています。Cloud Controlプラットフォームの主要コンポーネントは、次の3つです。

- Oracle Management Service

- 管理リポジトリ

- 管理エージェント

図1-1 Enterprise Managerのアーキテクチャ

1.1.1 Oracle Management Service

Oracle Management Service (OMS)には、管理情報の記憶域と、ネットワークで管理されるすべてのエンティティに対する管理アクティビティの自動化の調整に使用するサービスが用意されています。Webベースのユーザー・インタフェース(Cloud Controlコンソール)を提供する機能もあります。

1.1.2 管理リポジトリ

管理リポジトリはOracle Databaseで、Enterprise Managerで管理されるエンティティの重要な管理情報がすべて格納されます。Oracle Management Service (OMS)では、管理リポジトリを使用して監視データなどの重要な情報を格納および取得します。

1.1.3 管理エージェント

管理エージェントは、Enterprise Managerで管理されるエンティティが存在するネットワーク内の様々なホストでEnterprise Managerのプロキシとして機能する軽量プロセスです。OMSと通信し、監視情報の収集および配信と、管理エンティティに対して実行される管理アクティビティの調整を行います。

1.1.4 Enterprise Managerへのインタフェース

次のツールおよびアプリケーションは、Enterprise Managerへのアクセスに使用できます。

- Cloud Controlコンソール
Cloud Controlコンソールは、監視、管理またはエンタープライズ構成のための管理コンテンツをユーザーに提供するユーザー・インタフェースです。

詳細は、1.2.1項「Cloud Controlコンソール」を参照してください。

- EM CLI
Enterprise Managerコマンドライン・インタフェース(EM CLI)では、様々なオペレーティング・システムのテキストベースのコンソール(シェルおよびコマンド・ウィンドウ)からEnterprise Manager Cloud Control機能にアクセスできます。

詳細は、Oracle Enterprise Managerオンライン・ドキュメント・セットの拡張性ページで、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。

http://www.oracle.com/pls/em121/homepage

- 管理リポジトリ・ビュー
管理リポジトリ・ビューでは、管理リポジトリに格納されているターゲット、メトリックおよび監視情報にアクセスできます。

詳細は、Oracle Enterprise Managerオンライン・ドキュメント・セットの拡張性ページで、『Oracle Enterprise Manager Cloud Control拡張プログラマーズ・リファレンス』の「管理リポジトリ・ビューの使用方法」を参照してください。

http://www.oracle.com/pls/em121/homepage

- クラウドのWebサービスAPI
クラウドのAPIは、Enterprise Managerとカスタムビルドまたはサード・パーティのセルフサービス・コンソールおよびサービス・デスクの統合に使用できます。

詳細は、Oracle Enterprise Managerオンライン・ドキュメント・セットの『Oracle Enterprise Manager Cloud管理ガイド』のクラウドのAPIに関する項を参照してください。

http://www.oracle.com/pls/em121/homepage

1.2 Oracle Management Serviceについて

Oracle Management Service (OMS)層は、Java EE (Enterprise Edition) Webアプリケーションで、いくつかの主要コンポーネントに分けることができます。

- 管理機能を実行するための管理コンソール

- 管理エージェントによって管理対象ターゲットから収集された情報が一元管理される管理リポジトリ

- 管理および保守サービス

管理サービス層は、パフォーマンスのために高性能な環境にさらに分散できます。たとえば、管理サービスが実行されているホストとは別のホストに管理リポジトリをインストールできます。また、フレームワークを管理対象ターゲット層に縮小して、スタンドアロン・デプロイメント構成(管理リポジトリ、管理サービスおよび管理エージェントが単一のホストに存在)をサポートできます。

一般的な構成では、Oracle Management Service (OMS)は管理対象ターゲットとは別のホストに存在します。集中管理が不要な企業向けの小規模なデプロイメントの場合、インフラストラクチャ層を単一のホストに縮小できます。

管理インフラストラクチャのOMS層には、監視、管理、構成、中心となるポリシー設定およびセキュリティなどの管理操作に使用される管理コンソールが含まれます。

1.2.1 Cloud Controlコンソール

Cloud Controlコンソールは、監視、管理またはエンタープライズ構成のための管理コンテンツをユーザーに提供するユーザー・インタフェースです。

Cloud Controlコンソールでは、Enterprise Managerサービスを使用して管理コンテンツをユーザーに表示します。管理者、マネージャまたは開発者は、自分の要件を最も満たすように概念化された管理情報のビューを参照できます。インタフェースのカスタマイズにより、表示する情報および特定のユーザーが実行できる操作を制御できます。たとえば、上位レベルのマネージャは、データベースの停止や起動などの管理機能を使用できない場合でも、サーバーの可用性ステータスを表示できます。

1.3 Oracle Management Agentについて

Oracle Management Agentは、ターゲットを識別し、それらのターゲットに関するデータを収集して環境における問題(高いCPU使用率など)を検出します。一般的な管理フレームワーク・デプロイメントでは、企業に属するホストごとに管理エージェントが1つあります。

管理エージェントは、そのホストで実行されている管理対象ターゲットを担当します。ターゲット、すなわちターゲット・インスタンスは、企業内で監視できるエンティティとして定義できます。このエンティティは、サーバーで実行されているアプリケーション、サーバー自体、ネットワーク、構成要素のいずれかです。

管理エージェントによって収集される情報を格納および処理するために、また管理エージェントに管理タスクの実行を指示するために、フレームワークのコア機能、すなわちOracle Management Serviceを提供するEnterprise Managerの部分に管理エージェントは依存しています。

管理エージェントは、ホスト上の管理アクティビティを調整します。一般的な構成では、1つの管理エージェントがホストで実行されます。ホスト・システム上のターゲットに対して管理タスクを実行します。管理エージェントの担当は、次のとおりです。

- 管理タスクの実行

- メトリック・データの収集および転送

- アラートしきい値(警告およびクリティカル)の検出

1.3.1 管理エージェントのアーキテクチャにおける変更

Enterprise Manager 12cでは、堅牢性、安定性および診断能力が全体的に向上するように、管理エージェントは再設計および再作成されています。一括エージェント・デプロイを可能にするエージェント・プッシュなどの機能のサポートが含まれています。

安全性を拡張するためにプラグインに含まれるコードを実行するため、サンドボックス化された環境が用意されています。他のプラグイン・コードからコードを保護し、エージェント環境でコードが安全に実行できることを再度保証しています。

1.4 Oracle Management Repositoryについて

Oracle Management Repository (管理リポジトリ)は、管理エージェントによって収集されたすべての情報が格納される記憶域です。管理リポジトリは、スキーマ定義、データベース・ジョブおよびOracleデータベース内で実行されるストアド・プロシージャで構成されています。管理リポジトリ内の情報には、次のものがあります。

- 管理対象ターゲットに関する構成情報

- 履歴メトリック・データおよびアラート情報

- クライアントおよびWebサーバーのレスポンス時間情報

- 管理対象ターゲットの可用性情報

- 製品およびパッチのインベントリ情報

管理リポジトリに格納されている情報は、エンドツーエンドのレポートの作成や問題の診断などのタスクの他、サービス・レベルの契約、可用性レポートの作成に役立ちます。管理リポジトリに格納されている情報は、中央管理リポジトリを指すセントラル・コンソールにアクセスしている管理者間で人数に関係なく共有できます。

管理リポジトリは、OMSによって管理されるターゲットに関するすべての管理情報の包括的なソースです。管理リポジトリは、オープン・スキーマとして設計されています。これにより、Oracleの管理インフラストラクチャのユーザーは、デフォルトの機能がビジネス要件を満たすのに不十分であるときに、リポジトリ内の情報を使用する方法をカスタマイズできます。

Enterprise Managerのパートナである拡張開発キット(EDK)を使用している場合、拡張リポジトリを直接変更できません。レポート構成、アソシエーション導出、コンプライアンス・ルール評価、プラグインで構築されたカスタマイズされたUIでの管理情報の表示などの様々な領域で、リポジトリのパブリック・ビューから使用できる情報にアクセスできます。詳細は、このマニュアルの関連する項を参照してください。

1.5 メタデータ・プラグインについて

メタデータ・プラグイン(プラグイン)は、特定のタイプのターゲットを管理および監視するためにEnterprise Managerの機能を拡張します。プラグインは、原則的にターゲットのメトリック・データを収集する方法についてOracle Management Agentに指示し、収集されたデータで実行する内容についてOracle Management Service (OMS)に指示します。

プラグインは、Enterprise Managerフレームワーク内の様々な層で特定の機能を提供するメタデータ・ファイルのセットで構成されています。たとえば、ターゲット・タイプ・メタデータ・ファイルは、新しいターゲット・タイプの定義における不可欠な要素です。EDKには、デフォルト収集ファイルに加えてターゲット・タイプ・メタデータ・ファイルが、プラグイン・アーカイブ内での新しいプラグインの作成に必要です。

新しいターゲット・タイプをCloud Controlに導入すると、デフォルトでは、Enterprise Managerに含まれている管理機能が新しいターゲットに対して自動的にサポートされます。これには、次のようなコア管理機能があります。

- メトリック収集およびアラート

- 可用性およびブラックアウト

- グループおよびシステム

- デフォルトのシステム・レポート

- その他の共通コンソール機能

また、EDKでサポートされるアプリケーション・プログラミング・インタフェース(API)を使用して、ターゲット・タイプに対して追加の管理機能を有効にすることもできます。これには、次の機能があります。

- 自動検出

- ターゲット対ターゲットのアソシエーション

- 構成管理

- カスタム・ターゲット資格証明

- 自動化(またはジョブ)

- カスタム・レポート

- コンプライアンス・ルールおよびコンプライアンス標準

- 管理用のカスタム・ユーザー・インタフェース

これらの各管理機能には、追加のメタデータ・ファイルが必要です。また、プラグインにパッケージ化する必要があるスクリプトの作成が必要な場合もあります。

1.6 プラグインの新機能

この項では、拡張メタデータ・プラグインの新機能について説明します。

- ターゲット・アソシエーション
異なるターゲット間の関係を確立します。

- 自動検出
ユーザーからの入力なしにターゲットを検出します。

- ターゲット資格証明
ターゲットの資格証明タイプおよび資格証明セットを定義します。

- 構成管理
構成の収集、保存された検索、比較メタデータなど

- エンタープライズ・レポート
Enterprise Managerのクラシック・レポートおよびBI Publisherベースのレポート

- コンプライアンス管理
PCIなどのフレームワークを表したり、ターゲットのベスト・プラクティスを定義します。

リポジトリベースのルールおよびリアルタイム監視ルール

- ジョブ・システム
新しいジョブ・タイプを定義し、ジョブ・システムUIまたはWebサービスAPIのいずれかを使用してそれらを起動します。

ジョブを発行またはスケジュールしなくても管理エージェントでスクリプトを実行できるようにするオーバーヘッドの低いリモート操作Webサービス

2 Enterprise Managerプラグインのスタート・ガイド

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

- プラグインとは

- Enterprise Managerプラグインの新機能

- 拡張開発キット(EDK)について

- 拡張開発キット(EDK)のインストール

- プラグイン開発サイクル

- プラグインの内容およびパッケージ化

- プラグインのリリース

- プラグインのデプロイ

2.1 プラグインとは

プラグインは、ファイル(ターゲット定義ファイル、ターゲットからメトリックを収集する収集スクリプト、ユーザー・インタフェースをカスタマイズするカスタムUIコンポーネントなど)のグループで、Enterprise Manager拡張開発キット(EDK)を使用してプラグイン・アーカイブに追加されています。プラグイン・ファイルは、正式にプラグインになる前に、アーカイブに追加する必要があります。プラグイン・アーカイブ・ファイル(*.opar)は、ファイルを関連付け正式なプラグインとしてまとめます。

各プラグインは、Enterprise Managerで監視できるターゲットの新しいタイプを定義します。ターゲット、すなわちターゲット・インスタンスは、企業内で監視できるエンティティとして定義できます。このエンティティは、サーバーで実行されているアプリケーション、サーバー自体、ネットワーク、構成要素のいずれかです。

Enterprise Managerでは、Enterprise Managerコンソールから新しいターゲット・インスタンスを管理フレームワークに追加できるようにすることで、ターゲット・インスタンスの管理が簡単になります。その結果、Enterprise Managerの監視機能および管理機能を利用できます。

プラグインは、Enterprise Managerフレームワーク内の様々な層で特定の機能を提供するいくつかのタイプのファイルで構成されています。たとえば、ターゲット・タイプ・メタデータ・ファイルは、新しいターゲット・タイプの定義における不可欠な要素です。EDKには、デフォルト収集ファイルに加えてターゲット・タイプ・メタデータ・ファイルが、プラグイン・アーカイブ内での新しいプラグインの作成に必要です。

新しいプラグインを作成するには、次のものが必要です(最低要件)。

- プラグイン・メタデータ

- ターゲットタイプ・メタデータ

- デフォルト収集メタデータ

プラグインを使用して、Enterprise Managerで監視するカスタム・ターゲット・タイプを定義すると、すべての管理情報をコンソールに集中化できます。

新しいターゲット・タイプをCloud Controlに導入すると、デフォルトでは、Enterprise Managerに含まれている管理機能が新しいターゲットに対して自動的にサポートされます。これには、次のようなコア管理機能があります。

- メトリック収集およびアラート

- 可用性およびブラックアウト

- グループおよびシステム

- デフォルトのシステム・レポート

- その他の共通コンソール機能

また、EDKでサポートされるアプリケーション・プログラミング・インタフェース(API)を使用して、ターゲット・タイプに対して追加の管理機能を有効にすることもできます。これには、次の機能があります。

- 自動検出

- ターゲット対ターゲットのアソシエーション

- 構成管理

- カスタム・ターゲット資格証明

- 自動化(またはジョブ)

- カスタム・レポート

- コンプライアンス・ルールおよびコンプライアンス標準

- 管理用のカスタム・ユーザー・インタフェース

これらの各管理機能には、追加のメタデータ・ファイルが必要です。また、プラグインにパッケージ化する必要があるスクリプトの作成が必要な場合もあります。

2.2 Enterprise Managerプラグインの新機能

この項では、Enterprise Managerプラグインの新機能について説明します。

- 拡張開発キット(EDK)
このリリースでは、EDKが付属しており、デフォルトではサポートされていないターゲット・タイプを管理するためのカスタム・プラグインの開発をサポートしています。

- プラグインとコネクタのライフサイクル管理
自己更新機能は、メタデータ・プラグインとコネクタをダウンロードおよびデプロイするためのユーザーフレンドリなメカニズムです。プラグインのライフサイクルを管理するコンソールも用意されているため、様々なタイプのプラグインの管理を標準化したり、Oracle Management Serverおよび管理エージェントにプラグインを簡単にデプロイできます。

2.3 拡張開発キット(EDK)について

Enterprise Manager Cloud Controlのアーキテクチャの主要コンポーネントは拡張フレームワークです。OracleパートナがEnterprise Managerプラットフォームを拡張できるように、製品には拡張開発キット(EDK)が付属しています。

EDKは、次のようなツール、ユーティリティおよびドキュメントの集合です。

- Enterprise Manager拡張ドキュメント: Enterprise Managerプラグインをプログラミングするための一般的なガイドラインです。

- リファレンス実装: Enterprise Managerの各種機能に対してリファレンス・コード実装、コード・スニペットなどを提供します。

- EDK適合性を検証するビルド時ツール: Enterprise Manager拡張ガイドラインを基準にして、違反を検証およびレポートするのに使用できるツール

- パッケージング・ツール: プラグイン・コンポーネント・ツール(empdk)をパッケージ化するためのツール。

- 検証ツール: プラグイン・コード・コンポーネントを検証し、違反があればレポートするためのツール。

EDKには、empdkというコマンドライン・ユーティリティがあります。このユーティリティは、プラグイン・アーカイブのパッケージ化または検証に使用します。empdkコマンドおよびそのオプションの詳細は、Oracle Enterprise Manager拡張プログラマーズ・リファレンスを参照してください。

EDKをダウンロードしたら、ローカル・システムで解凍し、現行ディレクトリをEDKを解凍した場所に変更します。EDKには、リファレンス・ドキュメントおよびプラグイン開発に役立つガイドの他、プラグインの開発中に場合によってはまとめる必要があるAPIリファレンスが格納されています。

EDKのダウンロードの詳細は、2.4項「拡張開発キット(EDK)のインストール」を参照してください。

2.3.1 EDKの内容

EDKアーカイブには、次のディレクトリが格納されています。

- \bin
empdkユーティリティが格納されています。このユーティリティは、次の目的で使用します。

- プラグインの構造を検証するため

- プラグインをパッケージ化するため

- 既存(Cloud Control 12より前)のプラグインのメタデータを新しいメタデータ形式に変換するため

- \doc
管理ビューに関するドキュメントを含め、Oracle Enterprise Manager拡張プログラマーズ・ガイドおよびOracle Enterprise Manager拡張プログラマーズ・リファレンスの他、EDK APIリファレンス・ドキュメントが格納されています。付属ドキュメントへのリンクは、overview.htmlを確認してください。

EDK APIリファレンス・ドキュメントには、索引ページ(sdk_api_ref.html)から直接アクセスすることもできます。

- \lib
EDKで使用される内部ライブラリが格納されています。

- \oui
EDKで使用される内部ライブラリが格納されています。

- \samples
プラグインの完全なリファレンス実装が格納されています。demo_hostsample.zipとしてパッケージ化されています。格納されているサンプル・メタデータ・ファイルは、EDKドキュメント全体にわたって参照されるファイルの例として使用します。

サンプル・プラグインのビルド、デプロイおよび使用の詳細は、アーカイブに同梱されているREADMEを参照してください。

EM CLIやEMCTLなど、このマニュアルで参照される他のユーティリティは、Enterprise Managerとともにインストールされ、通常Oracle Management Service (OMS)ホストにデプロイされます。

2.4 拡張開発キット(EDK)のインストール

注意:
EDKをインストールする前に、次のものが必要です。

- 自己更新コンソールからの最新バージョンのEDK ZIPアーカイブ。(自己更新コンソールにアクセスするには、Cloud Controlコンソールから、「設定」、「拡張性」、「自己更新」の順に選択します。)

- Javaバージョン1.6.0_43以上

- Solaris、Linux、HP-UX、AIXまたはNTFS (New Technology File System)搭載のWindowsを実行しているローカル・システム

EDKをインストールするには、次の手順を実行します。

1. 次のオプションのいずれかを使用してEDK ZIPアーカイブをローカル・システムにダウンロードします。

- Enterprise Manager Cloud Controlコンソールを使用して、次のようにします。

1. Enterprise Manager Cloud Controlにログインします。

2. 「設定」メニューから「拡張性」、「開発キット」の順に選択します。
「拡張開発キット(EDK)」ページが表示されます。

3. 「EDKのインストール中」の下の「拡張開発キットをワークステーションにダウンロードします。」を選択します。

4. 12.1.0.4.0_edk_partner.zipをローカル・システムに保存します。

- Enterprise Managerコマンドライン・ユーティリティ(EM CLI)を使用して、コマンド・プロンプトを開き、次のコマンドを実行します。

emcli get_ext_dev_kit

コマンドを実行したのと同じディレクトリにEDK ZIPアーカイブがダウンロードされます。このコマンドにパラメータは必要ありません。

注意:
EM CLIの設定の詳細は、Oracle Enterprise Manager Cloud Control拡張リファレンス・ガイドを参照してください。

2. JAVA_HOME環境変数を設定し、PATHに含まれていることを確認します。次に例を示します。

setenv JAVA_HOME /usr/local/packages/j2sdk1.6.0_24

setenv PATH $JAVA_HOME/bin:$PATH

3. ダウンロードしたEDK ZIPアーカイブをローカル・システムのディレクトリに解凍します。次に例を示します。

Unzip 12.1.0.4.0_edk_partner.zip

EDK ZIPアーカイブを解凍したディレクトリ(release_edk_partner)の下に、次のディレクトリが作成されます。

release_edk_partner
|
bin
doc
lib
oui
samples
README

ディレクトリの内容の詳細は、2.3.1項「EDKの内容」を参照してください。

2.5 プラグイン開発サイクル

プラグイン開発では、次のことを実行します。

1. プラグインに含める一連のエンティティの設計

2. Enterprise Managerにエンティティを記述するメタデータの定義

3. Enterprise Managerインストールでユーザーがデプロイおよび使用できるようにするための、プラグインのパッケージ化および配信

図2-1に、プラグインのライフサイクルを示します。

図2-1 プラグインのライフサイクル

プラグインのライフサイクルは、次のステージを通過するプラグインの遷移を表します。

- 設計/開発: プラグインを設計および開発します。

- パッケージ化: プラグインをパッケージ化(してリリース)します。

- 公開: Oracle Enterprise Managerストアでプラグインを公開します。

- ダウンロード: Enterprise ManagerサーバーによってOracle Enterprise Managerストアからプラグインがダウンロードされます。

- デプロイ: Oracle Management Service (OMS)および管理エージェントにプラグインをデプロイします。

- アップグレード: プラグインを次期バージョンにアップグレード(ダウンロードおよびデプロイ)します。

- アンデプロイ: OMSからプラグインを完全に削除します。

2.5.1 プラグイン・メタデータの設計

プラグイン開発の最初のステップは、プラグインの内容を設計することです。最も大まかなレベルでは、プラグインに含めるターゲット・タイプのセットの決定(1つのプラグインには1つ以上のターゲット・タイプの管理メタデータを含めることができます)と、ターゲット・タイプごとにサポートする管理機能のセットの定義を行います。(詳細は、2.6項「プラグインの内容およびパッケージ化」を参照してください)。

プラグイン・ファイルを作成する前に、新しいコンポーネントを正確に監視および管理するのに必要なターゲット・タイプのパラメータを定義する必要があります。内容は次のとおりです。

- 収集する必要のあるパフォーマンス・メトリックおよび構成メトリックの識別。

- 各メトリックの収集頻度の決定。メトリックの収集頻度は5分間に1回を下回らないようにすることをお薦めします。

- 顧客固有の運用に基づいた、デフォルトの警告またはクリティカルしきい値、あるいはその両方の指定。しきい値を超えるたびに、Enterprise Managerはインシデントを生成して、考えられる問題を管理者に通知します。

これらのメトリックおよび収集の設定は、各プラグインの必須コンポーネントです。ジョブ定義、カスタム・ユーザー・インタフェースなどの追加の機能はオプションです。プラグインに含める各機能には、それらの機能で管理できるターゲットの側面を決定するための思索と設計がさらに必要です。

プラグインの設計時に検討する主要機能には、次のようなものがあります。

- 管理タスクや自動化サポートを必要とするより大規模で複雑なジョブ(たとえば、スケジューリング)など、ターゲットの管理に必要な管理機能

- ターゲットとネットワーク内の他のターゲット間のアソシエーションを含め、ターゲットの管理に使用する構成データ

- ターゲットを管理するためにエンドユーザーに提供されるレポートおよびカスタマイズされたユーザー・インタフェース

これは一部にすぎず、各サブシステムとの統合に関する情報の概要は、このマニュアルに記載されています。詳細は、Enterprise Managerプログラマーズ・リファレンスを参照してください。

2.6 プラグインの内容およびパッケージ化

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

- プラグイン・メタデータ

- メタデータ・サービス

- プラグインのパッケージ化構造

2.6.1 プラグイン・メタデータ

各プラグインにはプラグイン・メタデータが含まれていますが、プラグインに関するすべての情報を表すXMLファイルで定義されています。

プラグイン・メタデータは、プラグインのデプロイ時に使用します。名前やバージョンなど、プラグインを識別するプロパティが含まれており、Enterprise Manager Cloud Controlに追加されるターゲット・タイプのセットが宣言されています。

2.6.2 メタデータ・サービス

Enterprise Manager EDKを使用して公開されるEnterprise Managerの機能のほとんどは、メタデータXMLファイルの構造である必要があります。これらのメタデータ・ファイルでは、特定のサブシステムについてそのターゲット・タイプのために統合される項目を定義します。たとえば、プラグインには、そのターゲット・タイプに使用可能なジョブ・タイプを定義するメタデータXMLファイルを含めることができます。デプロイ後、そのターゲット・タイプのインスタンスについて、ジョブを発行または実行できます。

ターゲット・タイプ・メタデータは、公開するメトリックと、それらのメトリックの取得および計算に使用されるメソッドで構成されています。ターゲット・タイプ・メタデータ・ファイルは、取得するデータ、およびこのターゲット・タイプについてそのデータを取得する方法をOracle Management Agentに指示します。

ターゲット・タイプについて収集されるメトリックに加えて、ターゲット・タイプ・メタデータにはターゲット・プロパティおよび資格証明情報が含まれています。ターゲット・プロパティは、ターゲットの定義を支援する重要なプロパティ・セットです。Enterprise Managerでは管理エージェントによって評価される動的インスタンス・プロパティの定義機能がサポートされていますが、これらのプロパティは通常、静的です。動的インスタンス・プロパティの定義の詳細は、Enterprise Managerプログラマーズ・リファレンスを参照してください。

プラグインにはデフォルト収集ファイルが含まれていますが、メトリックおよび構成データが収集される頻度を定義します。

Enterprise Manager拡張フレームワークは、EDKでのこれらのメタデータ・ファイルのパッケージ化の他、Enterprise Manager内の適切なサブシステムへのこれらのファイルのデプロイをサポートします。これには、管理サーバーまたは管理エージェント(場合によってはその両方)への情報のデプロイが含まれることもあります。EDKでのメタデータ・ファイルのパッケージ化の詳細は、2.6.3項「プラグインのパッケージ化構造」を参照してください。

特定のインスタンスでは、プラグインにパッケージ化されている他のコンポーネントへの参照がメタデータに含まれます。たとえば、ジョブ・タイプ定義に、管理タスクを実行するターゲットの1つに対してPerlスクリプトを実行するステップが含まれていることがあります。その場合、ジョブ・タイプ定義はメタデータで宣言され、プラグインの管理サーバー部分に組み込まれますが、スクリプトはプラグインの管理エージェント部分に組み込まれます。

使用可能なすべてのメタデータ・サービスの詳細なリストおよび各サービスの使用方法を説明する詳細なドキュメントは、Enterprise Managerプログラマーズ・リファレンスを参照してください。

2.6.3 プラグインのパッケージ化構造

プラグイン開発の最後のステップは、プラグイン・アーカイブにプラグインをパッケージ化することです。このステップでは、プラグインを構成するファイルがあるステージング・ディレクトリ(plugin_stage)を入力として取ります。例2-1に、ディレクトリ構造およびファイルの場所をまとめます。

例2-1 プラグインのディレクトリ構造

plugin_stage/
|
plugin.xml
agent/
|
plugin_registry.xml
default_collection/
|
target_type.xml
metadata/
|
target_type.xml
scripts/
|
scripts
oms/
|
metadata/
|
default_collection/
|
target_type.xml
derivedAssoc/
|
derivedAssoc_rule.xml
discovery/
|
discovery.xml
gccompliance/
|
compliance_rule.xml
jobTypes/
|
job_type.xml
mpcui/
|
mpcui.xml
reports/
|
report.xml
snapshotlive/
|
target-type_ecmdef.xml
targetType/
|
target_type.xml
discovery/
|
discovery scripts

プラグイン・ディレクトリの内容の詳細は、Enterprise Managerプログラマーズ・リファレンスを参照してください。

2.7 プラグインのリリース

プラグインをパッケージ化すると、そのプラグインに含まれるターゲット・タイプのサポートを必要とするEnterprise Manager管理者にプラグイン・アーカイブ(OPAR)ファイルを配布できます。このモードでは、オラクル社は本番環境での使用においてプラグインの品質または安全性を保証しないため、オラクル社が保証しないプラグインをデプロイする前にテスト環境での適切な評価をお薦めします。

プラグインをデプロイできるようにするために、Enterprise Manager管理者はプラグイン・アーカイブをEnterprise Managerインストールにインポートする必要があります。これが完了したら、プラグインはオラクル社からダウンロードした他のプラグインと同様にデプロイできます。プラグインのインポート・コマンドの詳細は、Enterprise Managerプログラマーズ・リファレンスを参照してください。

2.8 プラグインのデプロイ

プラグインをEnterprise Managerにインポートした後に、Enterprise Manager管理者はプラグインを管理サーバーおよび適切な管理エージェントに明示的にデプロイする必要があります。

プラグインのデプロイは、Enterprise Managerコマンドライン機能(EM CLI)を使用するか、Enterprise Managerコンソールの「設定」メニューから「拡張性」を選択して実行できます。これらのオプションの使用方法の詳細は、Enterprise Managerプログラマーズ・リファレンスを参照してください。

2.8.1 検出時の自動デプロイ

プラグインに自動検出のサポートが含まれている場合、Enterprise Managerでターゲットが検出され、管理可能ターゲットとしてマーク(昇格)されると、プラグインは適切な管理エージェントに自動的にデプロイされます。自動検出を有効にするには、適切な検出メタデータをプラグインに含める必要があります。

ターゲットの自動検出のサポートが含まれていないプラグインの場合、Enterprise Manager管理者は、ターゲットがある管理エージェントを指定して、ターゲットをEnterprise Managerコンソールに手動で追加する必要があります。その場合、Enterprise Manager管理者は、ターゲットを手動で追加する前に、それらの管理エージェントにプラグインをデプロイする必要があります。

2.8.2 プラグインのアップグレード

プラグインの新しいバージョンがリリースされると、Enterprise Manager管理者は、Enterprise Managerの自動更新機能を使用してOracleストアから新しいバージョンをダウンロードするか、プライベート配布である場合は新しいプラグイン・アーカイブをインポートして、新しいプラグインをインポートできます。

この時点で、新しいバージョンのプラグインはEnterprise Managerで使用できますが、管理サーバーまたは管理エージェントのいずれにもデプロイされていません。Enterprise Manager管理者は、2.8項「プラグインのデプロイ」で説明されているのと同じデプロイ・プロセスを使用して、新しいバージョンのプラグインを明示的にデプロイする必要があります。

2.8.3 プラグインのアンデプロイ

プラグインをもう使用しない場合は、Enterprise Managerから削除できます。プラグインをアンデプロイすると、管理サーバーおよびプラグインが以前にデプロイされた管理エージェントからプラグインのすべての要素が削除されます。

3 管理対象ターゲットについて

この章では、管理対象ターゲットに関する情報を示します。内容は次のとおりです。

- 管理対象ターゲットの概要

- 管理対象ターゲットの新機能

- ターゲット・モデルについて

3.1 管理対象ターゲットの概要

各プラグインは、Enterprise Managerで監視できる新しいタイプのターゲットを定義します。ターゲット、すなわちターゲット・インスタンスは、企業内で監視できるエンティティとして定義できます。管理対象ターゲットは、Enterprise Managerが監視および管理できるエンティティです。ターゲットの例には、ホスト、データベース、アプリケーション・サーバー、アプリケーションおよびリスナーがあります。環境の変化につれて、必要に応じてEnterprise Managerに対してターゲットを追加および削除できます。

一般的に使用される管理対象ターゲットの多くは、Enterprise Managerのベース製品の一部として定義されています。これらは、管理可能な製品がインストールされると、管理用に自動的に事前構成されます。Oracleアプリケーション、Oracleデータベース、Oracleアプリケーション・サーバー、Oracle製品を実行する多くのオペレーティング・システムは、すべて管理可能なターゲットとして分類されます。

ターゲットが事前定義されていても(監視レベル、しきい値、通知ルールなど)、ビジネス要件に合うように必要に応じてEnterprise Managerをカスタマイズすることもできます。つまり、拡張インスツルメンテーションを実行して、標準的なターゲット構成で提供されるEnterprise Managerの豊富な管理機能により多くアクセスできます。

管理対象ターゲットは、次のとおりです。

- 管理を必要とするアプリケーション

- 個別に構成または管理できる、アプリケーションのサブシステム

- 基礎となるアプリケーション・ハードウェア・トポロジの管理コンポーネント

3.2 管理対象ターゲットの新機能

メトリック拡張は次世代のユーザー定義メトリックで、任意のターゲット・タイプに新しいメトリックを作成することにより、Enterprise Managerを拡張して企業環境に固有の条件を監視できます。既存のユーザー定義メトリックをメトリック拡張に移行できるようにする移行機能が用意されています。

その他の拡張機能は、次のとおりです。

- オペレーティング・システムおよびSQL問合せ以外のデータ収集方式のサポート強化。

- バージョニング、デプロイメントを含め、メトリックのライフサイクル・サポートの作成および更新。

- システム・ダッシュボードやレポート機能など、メトリックに対応しているすべての機能の暗黙的なサポート。

- コンポジット・ターゲット・タイプおよびシステム・ターゲット・タイプのサポート

3.3 ターゲット・モデルについて

ターゲット・モデルは、様々なタイプのエンティティで構成されていますが、エンティティはすべて、ターゲットのセキュリティ・インフラストラクチャによってもたらされるセキュリティの利点を引き出すためにターゲットとしてモデル化されます。たとえば、システム、サービスおよびグループはすべてターゲットとしてモデル化されます。各種エンティティの区別は、時間の経過とともに曖昧になり、ターゲットの概念全体に含まれてしまいます。そのため、別のプラグイン開発者にはターゲットが異なるものを意味することがあります。

どの種類のエンティティが実際にモデル化されているかを明確に区別するために、Enterprise Managerでは、管理可能なエンティティ(ME)クラスと呼ばれる上位レベル・クラスの概念を採用して、各エンティティを分類しています。各クラスには、明確に定義された定義および機能があります。定義を調べると、モデル化されたエンティティが分類されるクラスを把握することができます。

たとえば、今日、冗長性グループはグループであるとよく間違えられますが、実はシステムです。グループおよびシステムの定義を追跡すると、どのクラスに分類されるか明確になります。

3.3.1 管理可能なエンティティ(ME)

Enterprise Managerのコンテキストでは、管理可能なエンティティとはEnterprise Managerが管理できるエンティティです。これには、エンティティはCloud Controlアプリケーションでエンドユーザーになんらかの形で公開され、明確に定義された属性およびセマンティクスを持っているという意味が含まれます。

Enterprise Managerには、様々なクラスの管理可能なエンティティがあります。管理可能なエンティティ・クラスにはそれぞれ次の特性があります。

- 定義: エンティティ・クラスのルールおよび固有の属性を指定します。

- 表現: Enterprise Managerデータ・モデルでそのクラスのエンティティをどのように表現し、エンドユーザーに公開するかを処理します。

- Enterprise Managerの機能: そのクラスのエンティティに対してEnterprise Managerに用意されている機能です。

Enterprise Managerでは、すべての管理可能なエンティティに次の共通機能があります。共通機能に加えて、それぞれのMEにリストされる機能があります。

- Enterprise Managerセキュリティ・モデルで保護されます。

- すべて、他のMEとの関係(アソシエーション)に追加できます。クラスとともに、注意する制限がいくつかあります。

- 一意のIDを持っています。

- プロパティ(名前/値ペア)をMEにアタッチできます。

Enterprise Managerでは、管理可能なエンティティは次のクラスのいずれかにのみ分類されます。将来のリリースでは、その他のクラスが追加される可能性があります。エンティティがどのクラスにも分類されない場合は、管理可能なエンティティではないか、サポートを必要とする新しいクラスのMEです。

- 管理対象ターゲット

- サービス

- システム

- グループ

- ターゲット・コンポーネント

管理可能なエンティティは、次に説明する複数の状態になる可能性があります。

- 管理対象状態または管理未定(NYM)状態
ターゲットが検出されると、最初は、NYMエンティティとして管理リポジトリにロードされます。この状態では、エンティティはアソシエーションを保持できますが、管理エージェントによってまだ管理されていません。ユーザーは、検出結果ページに移動して、必須の資格証明とともに管理エージェントに割り当てることができます。その結果、エンティティは管理対象状態に移行します。また、Enterprise Manager UIからターゲット検出を手動で起動し、ターゲットの必要なプロパティをすべて取得または指定して管理対象ターゲットとして直接保存することもできます。自動検出は、NYMターゲットが存在するようになる1つのユースケースです。

- 存在のみ状態
Oracleでサポートされない検出されたエンティティは存在のみ状態になります。Oracleで管理できないことを除いては、NYMエンティティに似ています。

プラグイン開発者は、このターゲット・タイプを登録するときに、is_existenceタイプ・プロパティをターゲット・タイプ・メタデータ・ファイルに追加する必要があります。タイプ・プロパティおよびターゲット・タイプ・メタデータ・ファイルの詳細は、Oracle Enterprise Managerオンライン・ドキュメント・セットの拡張性ページで、Cloud Control拡張プログラマーズ・リファレンスの「ターゲット・メタデータ・ファイルの作成」を参照してください。

http://www.oracle.com/pls/em121/homepage

注意:
EDKを使用しているプラグイン開発者は、Enterprise Manager内で管理される新しいターゲット・タイプを定義できますが、これは管理対象ターゲットおよびターゲット・コンポーネントに限定されます。新しいインストール・ホーム、サービス、システムまたはグループ・タイプを定義する機能は、EDKの一部としてサポートされていません。
各クラスの定義および機能は、次の各項を参照してください。

3.3.2 管理対象ターゲット

管理対象ターゲットは、本質的に次の条件をすべて満たす(また、モデリングに適している)Enterprise Manager内の管理可能なエンティティです。これらは、エンティティに固有で、Enterprise Managerでの表現からは導出されません。

- 可用性(稼働中/停止ステータス)。

- 収集できる構成属性

- レスポンス時間など、測定できるパフォーマンス属性

管理対象ターゲットの例には、ホスト、データベース、リスナーなどがあります。

ターゲット・タイプは、3.3.2.1項「ターゲット・アイデンティティ」で説明されているターゲット・メタデータXMLを使用して登録できます。

3.3.2.1 ターゲット・アイデンティティ

このリリースのEnterprise Managerでは、履歴を失わずにターゲットを新しい名前に変更できます。Enterprise Managerターゲット名は、Enterprise Managerでターゲットを探すのに後で使用できるターゲットに関連付けられた外部データとともに格納する必要はありません。

3.3.2.2 ライフサイクル・ステータス

ライフサイクル・ステータス・プロパティは、エンドユーザーによって次のいずれかの値に設定されます。

- 開発

- テスト

- リリース

- 本番

たとえば、このプロパティはイベントの優先処理で使用できます。このプロパティを使用するのに何もする必要はありません。

3.3.3 グループ

グループは管理可能なエンティティの集合で、エンドユーザーは多数のMEを1つの論理ユニットとして管理できるようになります。グループのメンバー間に必須のアソシエーションはありません。そのため、グループのメンバーは、メンバー間やメンバーを含むグループと固有の関係を持っていたり、持っていなかったりします。グループは、メンバーとの包含アソシエーションを持っています。

ユーザーは、グループのメンバーシップを(直接追加または基準に基づき)決定するため、設計時にグループ構成について何も仮定しません。

グループは、エンドユーザーによって非定型な方法でまたは特定のビジネス基準(ライン・オブ・ビジネス、テスト対本番、ターゲット・バージョンなどに)を指定してアセンブルできます。

権限の観点から、次の2つの異なるタイプのグループがあります。

- 通常のグループ
グループに対する表示権限のみがメンバーに伝播されます。

- 権限伝播グループ
グループに対するすべての権限がメンバーに伝播されます。

3.3.4 システム

システムは、本質的に関連し、連携して1つ以上のビジネス機能またはサービスを提供する管理可能なエンティティの集合です。

システムのメンバーは、明確に定義された関係を持っています。これらの関係は、アソシエーションによって指定されます。

システムとグループの主な相違点は、システムは本質的に関連するエンティティの集合であるのに対し、グループは主に多数のエンティティを1つとして管理するために作成されることです。システムにはグループを含めることができませんが、グループにはシステムを含めることができます。

3.3.4.1 システムの状態

システムは、基礎となるターゲットおよび必須のアソシエーションがすべて検出されている場合、完全に形成されます。必須のターゲットおよびアソシエーションのいずれかが検出されなかった場合、システムは部分的に形成されます。根本的な論理的問題のためにシステムが作成できない場合、システムは破損します。

システム操作は、完全に形成されたシステムに対してのみ可能です。システム操作は、部分的に形成されたシステムに対しても実行できます。部分的に形成されたシステムに対して操作をサポートするかどうかは自由に決定できます。

可用性は、完全に形成されたシステムについてのみ計算されます。チャートおよびトポロジは、部分的に形成されたシステムまたは破損したシステムに対しても表示できます。根本原因分析(RCA)および他の診断ユーティリティは、完全に形成されたシステムに対してのみ確実に機能します。

3.3.5 コンポジット・ターゲット

コンポジット・ターゲットは、グループとして管理される多数の関連ターゲットで構成されているターゲットです。関連ターゲットは、しばしばコンポジット・ターゲットの子またはメンバーと呼ばれます。プラグインの一部として、コンポジット・ターゲット自体を記述する様々なターゲット・タイプの他、その子のターゲット・タイプを定義します。

コンポジット・ターゲットは、ターゲットの固有グループで、そのセマンティクスはプラグイン自体に記述されます。Enterprise Managerでは、ターゲット・ナビゲータまたはコンポジット・ターゲットのトポロジ・ビューのいずれかでコンポジットと子の関係を視覚的に表す機能以外、追加のセマンティクスをコンポジット・ターゲットに割り当てません。その他のセマンティクスは、コンポジット・メトリックへのデータの集計、メンバー間のアソシエーション、またはコンポジットの子にまたがる操作(タスクまたはジョブ)として、プラグイン・コードで実施されます。

一般的なコンポジットの例の1つは、冗長グループのコンポジットです。この場合、一連の関連ターゲットにより、1つのコンポジット・エンティティとして管理されるグループが形成されます。グループの各メンバーは、別個に管理することもグループ(コンポジット)自体の一部として管理することもできます。フェイルオーバーの発生方法、監視情報の集計方法など、グループの動作方法の特定のセマンティクスは、プラグイン内で定義されているロジックの一部です。Enterprise Managerでは、追加のセマンティクスをコンポジット定義から推論しようとしませんが、コンポジットの一連のメンバーをまとめて表示し、メンバーと他のターゲット間のアソシエーション、メンバーとコンポジット・ターゲット自体間のアソシエーションを管理するためのサービスと、コンポジット・ターゲットまたはそのメンバーに関するメンバーシップまたはアソシエーションの詳細を取得するためのサービスを提供できます。

3.3.6 システム・ターゲット

コンポジット・ターゲットに加えて、このリリースのEDKでは、メタデータ・プラグインの一部としてシステム・ターゲット・タイプの定義に対するサポートを追加します。コンポジット・ターゲットを使用するとグループとして管理する関連ターゲットのセットを定義できますが、システム・ターゲット・タイプにはEnterprise Managerに付属する追加のセマンティクスに対するサポートが含まれています。

システム・ターゲットは、ITインフラストラクチャで実行されるアプリケーションのコンポーネントである監視対象サービスを定義するための基礎です。ITインフラストラクチャは、サービスが実行される一連のシステムとしてモデル化されます。したがって、Enterprise Managerでは、システムを表示および監視する機能、システムで実行されているサービスに対するサービス失敗の根本原因分析などの操作を実行する機能がサポートされています。

3.3.7 サービス

サービスは、ターゲットまたはシステムによって提供されるビジネス機能のアクセス・ポイントをモデル化します。サービスはゼロまたは1つのシステムと関連付けることができます。サービスでは、ビーコンまたはシステム・コンポーネントを使用して可用性およびパフォーマンス・データを計算できます。

たとえば、Beehiveアプリケーション・システムの電子メール・サービスではビーコン・トランザクションを使用しますが、SMTPプロトコルを使用して電子メールの可用性をチェックするためです。あるいは、サービスが依存するシステムの主要コンポーネントを定義して条件すべての主要コンポーネントが稼働中またはいずれかの主要コンポーネントが稼働中を指定することで、エンドユーザー・システムのサービス可用性を定義することもできます。

Enterprise Managerで管理されるシステムに関連付けられていないサービスの例に、リモートWebサービスがあります。Enterprise Managerでは、基礎となるシステムが不明なインフラストラクチャであってもEnterprise Managerによって管理されるインフラストラクチャであっても、可用性およびパフォーマンスのチェックにビーコン・トランザクションを使用してサービスを監視できます。

これにより、Enterprise Managerユーザーは、リモート・サービスをアプリケーションのトポロジに含めることができ、それらのサービスの監視をアプリケーション監視ソリューションの一部に組み込むことができます。

3.3.8 サポートされる管理機能

次の表に、Enterprise Managerでサポートされる様々なエンティティ・タイプごとにサポートされる機能のタイプを示します。メンバーのみとは、操作が、ME自体ではなく、MEのメンバーに対するものであることを意味します。たとえば、ジョブはグループのメンバーに対して実行できますが、ジョブがグループに対して発行されてもグループ自体に対しては実行できません。

機能

ターゲット

NYM

グループ

システム(検出)

システム(ユーザー定義)

サービス

可用性(稼働中/停止ステータス)

Y

N

N

Y (オプション)

N

Y

パフォーマンス・メトリック(収集およびロールアップ)

Y

N

ロールアップのみ

Y

ロールアップのみ

Y

構成の収集(保存/比較操作)

Y

N

N

Y

メンバーのみ

Y

コンプライアンス・ルールおよびコンプライアンス標準

Y

N

Y

Y

Y

Y

アソシエーションに追加可能

Y

Y

メンバーとの包含に制限

Y

ユーザー定義のみ

Y

アソシエーション導出

Y

N

N

Y

N

Y

ジョブ

Y

N

メンバーのみ

Y

メンバーのみ

Y

イベント

Y

N

メンバーのみ

Y

メンバーのみ

Y

パッチ適用、プロビジョニング

Y

N

メンバーのみ

Y

メンバーのみ

Y

ブラックアウト

Y

N

メンバーのみ

Y

メンバーのみ

Y

テンプレート

Y

N

メンバーのみ

Y

メンバーのみ

Y

自動検出(Enterprise Managerによってエンティティを自動的に検出または構成可能)

Y

Y

N

Y

N

Y

権限

Y

Y

Y

Y

Y

Y

権限の伝播(権限をメンバーに伝播)

N

N

Y (オプション)

Y (オプション)

Y (表示のみ)

N

メトリック拡張

Y

N

N

Y

N

Y

4 エンタープライズ構成管理について

この章では、エンタープライズ構成管理およびエンタープライズ構成管理フレームワークの概要について説明します。

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

- エンタープライズ構成管理の概要

- エンタープライズ構成管理の新機能

- 構成について

- アソシエーションおよびトポロジについて

4.1 エンタープライズ構成管理の概要

エンタープライズ構成管理を使用するとターゲットから構成情報を収集できますが、これは、大規模でまれにしか変化しない、重要な構造を持つ情報の集合であると特徴付けられます。このような集合は、通常の(パフォーマンス)メトリックと比較してまれにしか収集されません。

構成データが影響を受けるのは、管理者がシステムに対し、パッチのインストールやなんらかの点でのターゲットの再構成といった変更を明示的に実施する場合のみです。実行中のシステムによって開始された変更が原因となる場合を除き、管理者による明示的な操作なしで構成データを変更しないでください。構成データの収集は最大で1日1回行われ、通常は前回の収集時とまったく同じデータが生成されます。

構成データの例としては、システムにおける構成済プロセスの最大数や使用可能なディスク領域の最大サイズなどがあげられます。非構成データの例としては、システムにおける現在のプロセス数や使用済ディスク領域と空きディスク領域の現在のサイズなどがあげられます。

エンタープライズ構成管理には、次のような様々な機能があります。

- 比較的多量の関連構成データの低頻度(デフォルト、日次)収集

- 構成情報のオンデマンド・リフレッシュおよび(ジョブによる)スケジュールされたリフレッシュ

- ターゲット間でどの程度異なるかを検出するための構成の比較。ユーザーは、比較テンプレートによって比較をカスタマイズできます。

- 後で表示、比較、構成に関連するその他の操作を行うために、保存済スナップショットとして構成を管理リポジトリに保存すること。

- 構成をファイルにエクスポートしたり、エクスポートされたファイルを保存済スナップショットとしてEnterprise Managerにインポートしなおすこと。これは、構成スナップショットをサード・パーティ・システムでアーカイブしたり、あるリポジトリから別のリポジトリに(たとえば、構成スナップショットをOracleサポートに)転送するのに使用できます。

- 履歴変更トラッキング。新しい構成が管理リポジトリに挿入されると、同じターゲットの古い構成との比較により、構成情報で変更された内容が明らかになります。これらの変更は、構成情報の履歴の一部として格納されます。エンドユーザーは、この履歴を表示および検索できる他、特定の変更が発生したときに通知されるようサインアップできます。

- 企業内またはターゲットのサブセット(たとえば、グループ内)での、すべての構成情報にわたる強力な検索。

- 関連ターゲットにアソシエーション(関係)の収集をトリガーすること。

- コンプライアンスのルールおよび標準の基礎を提供すること。これらのルールおよび標準は、エンタープライズ構成管理データで実施されます。

4.2 エンタープライズ構成管理の新機能

この項では、エンタープライズ構成管理の新機能を示します。

- トポロジ・ビューア
詳細は、4.4項「アソシエーションおよびトポロジについて」を参照してください。

- カスタム構成データを収集する機能
詳細は、4.3項「構成について」を参照してください。

- 比較機能で比較テンプレートを指定する機能
詳細は、4.3.2項「構成の比較」を参照してください。

- 強化された検索機能
詳細は、4.3.1項「構成の表示および検索」を参照してください。

- 以前のリリースと比較してより包括な構成の収集。

4.3 構成について

エンタープライズ構成管理では、構成スナップショットの集合として構成を収集します。構成スナップショットは、パフォーマンス・メトリックに関連してまれにしか変化しない情報の大規模な集合です。各構成スナップショットは、Enterprise Managerターゲットに関連付けられます。たとえば、Oracleホーム構成スナップショットは、Oracleホーム・ターゲットに関連付けられます。

各スナップショット・タイプは、特定のターゲット・タイプに関連付けられます。たとえば、タイプoracle_home_configの構成スナップショットは、タイプoracle_homeのターゲットに関連付けられます。

注意:
ターゲット・タイプには、複数のスナップショット・タイプを関連付けることができます。たとえば、oracle_homeに他のスナップショット・タイプを関連付け、oracle_home_configによってまだ収集されていない他の構成情報を収集することができます。

ターゲット構成は、多数の収集された構成スナップショットで構成されています。通常、スナップショット収集は、管理エージェントがスケジュール済イベントとして起動すると、自動的に発生します。これらの収集のサイズおよび低頻度の変更率のため、スケジュール・サイクルとして24時間が適切です。エンタープライズ構成管理には、スケジュールに関係なく、新しい構成が必要なときにいつでもトリガーできるオンデマンド・リフレッシュ機能があります。

構成が管理リポジトリに挿入されると、特定のターゲットの以前の構成が置き換えられます。エンタープライズ構成管理では、相違がないか2つの構成を比較し、その相違をターゲットの構成履歴として記録します。変更の正確な時間は不明ですが、タイムスタンプはスケジュール・サイクル(24時間)またはオンデマンド・リフレッシュ内にあります。構成に関連する履歴情報の他、現在の情報も参照できます。

4.3.1 構成の表示および検索

Enterprise Manager UIから、収集された構成を表示し、その構成に対して様々な操作を実行できます。構成はすべて同じ管理リポジトリに記録されるため、すべてのターゲットまたはターゲットのサブセットで構成の検索を実行できます。たとえば、企業内で4つのCPUおよび最低1GBのRAMを持つホストをすべて検索します。

検索機能にアクセスするには、「すべてのターゲット」ページで必要なターゲットを右クリックし、「構成」、「検索」の順に選択します。図4-1のような、選択したターゲットの「構成検索ライブラリ」ページが表示されます。構成の検索の詳細は、Cloud Controlオンライン・ヘルプを参照してください。

図4-1 「構成検索ライブラリ」ページ

4.3.2 構成の比較

相違がないか構成を比較できます。たとえば、同じ構成を持つ2つのホストを比較して一方のホストにおける問題を識別できます。

また、最も標準的であるとみなされるターゲットの構成を、構成ドリフトがないか多数の他のターゲットと比較することもできます。このような操作には大量のデータを必要とするため、これらの比較をオフピーク時にスケジュールすることができます。

比較テンプレートを使用して、比較をカスタマイズすることもできます。比較テンプレートを使用すると、特定のターゲット・タイプの構成を比較するときに考慮に入れる特定の定数を設定できます。たとえば、間違いなく異なる項目を無視して、情報を減らしたり誤検出を除外します。このようなカスタマイズされた比較を保存して、ユーザーおよびグループ間でテンプレートを共有することができます。

構成を比較するには、「すべてのターゲット」ページで必要なターゲットを右クリックし、「構成」、「比較」の順に選択します。図4-2のような、比較ウィザードが表示されます。

比較の設定の詳細は、Cloud Controlオンライン・ヘルプを参照してください。

図4-2 「構成の比較」ページ

4.3.3 構成の保存

収集時に構成によって以前の構成が上書きされても、アーカイブのために管理リポジトリに構成を保存することができます。

注意:
保存済スナップショットという用語は、ターゲット全体の保存された構成を指し、そのターゲット用に保存された多数の構成スナップショットと、保存済アソシエーションが含まれることがあります。

また、構成をファイルにエクスポートできます。このファイルは、後で保存済スナップショットとして同じ管理リポジトリまたは別の管理リポジトリにインポートしなおすことができます。

最新の構成を保存するには、「ターゲット」ページで必要なターゲットを右クリックし、「構成」、「保存」の順に選択します。図4-3のような、「最新を保存」ウィンドウが表示されます。構成の説明を指定してから、「ジョブの発行」をクリックします。

保存された構成の使用の詳細は、Cloud Controlオンライン・ヘルプを参照してください。

図4-3 「最新を保存」ウィンドウ

4.4 アソシエーションおよびトポロジについて

エンタープライズ構成管理フレームワークには、ターゲットと他のIT管理対象エンティティ間の関係を表す共通の方式および規則が用意されています。これらの関係(アソシエーション)は、ターゲットを参照できます。また、アプリケーションのWebサービスやJ2EEコンテナのデータ・ソースなど、ターゲット・コンポーネントと呼ばれるよりきめの細かいエンティティを参照することもできます。

アソシエーションは、収集された構成データに基づいて最新状態に保つことができます。プラグイン開発者は、構成データからアソシエーションを導出するロジックを指定できます。アソシエーションの詳細は、第5章「導出されたアソシエーションの使用方法」を参照してください。

Enterprise Managerのトポロジ・ビューアは、管理対象エンティティが企業内の他のエンティティとどのように関連するかをグラフィックで表示します。ビューアを使用すると、現在のアソシエーションを表示できます。

5 導出されたアソシエーションの使用方法

ITインフラストラクチャを効率的に管理するには、ITエンティティ間の関係を把握する必要があります。ITIL(情報技術基盤ライブラリ)で説明されているようなベスト・プラクティスは、このような関係を取得および使用することに基づいています。Enterprise Manager Cloud Control 12cでは、サポートされている様々な関係を拡張し、これらの関係を保持できる宣言型方式を追加しています。また、システム内のエンティティのメンバーシップを関係に基づいて決定します。正確な関係に基づいて、各種Enterprise Managerアプリケーションおよびコンポーネントでは、次のような顧客の利用をサポートできます。

- 依存性分析。
たとえば、ホストの停止による(アプリケーションおよびインフラストラクチャに対する)影響を把握するため。

- トポロジ・ビューア。

- 変更管理。
たとえば、テストから本番インスタンスまでなど、クローン・データベースのソースを追跡するため。

- エンドツーエンドのパフォーマンス分析。この分析では、問題を分析して分離するためにアプリケーション・コンポーネント間の相互依存性を把握する必要があります。

- VMリソースが割り当てられる方法における変更など、関係の変更トラッキング。

この章では次の内容について説明します。

- 概要

- Enterprise Managerのアソシエーションの概念について

- アソシエーション導出ルール管理の使用方法

- オーバーラップ・アソシエーションについて

- よくある質問

5.1 概要

Enterprise Managerでは、関係の概念は、内部的にアソシエーションと呼ばれます。アソシエーション(アソシエーション・インスタンス)は、2つの管理対象エンティティ間の関係を表し、3つの値、すなわちソース、宛先およびアソシエーション・タイプを指定します。たとえば、"database1 exposed_by listener1"では、database1がソース、listener1が宛先、"exposed_by"がアソシエーション・タイプです。

プラグイン開発者が、管理対象エンティティ・タイプに適用されるアソシエーション・タイプを定義し、正しいアソシエーション(アソシエーション・インスタンス)が存在することを検証します。

5.2 Enterprise Managerのアソシエーションの概念について

この項では、アソシエーション・タイプを定義する簡潔かつ宣言的な方法であるアソシエーション導出ルールについて説明します。アソシエーション導出(アソシエーションの有無が収集されたデータから導出されるため、このように呼ばれます)は、開発者がターゲットから収集されたデータに基づいてアソシエーション・インスタンスを作成および削除できるメカニズムです。

アソシエーション導出メカニズムを使用すると、アソシエーションと収集された構成データの一貫性を保ち、すべての既知のデータに基づいて(より少ないデータにアクセスできるエージェント・ロジックによって実行するかわりに)アソシエーションを一元的に決定できます。

5.2.1 アソシエーション導出の使用方法

アソシエーション導出を使用するには、開発者は一般に次の手順を実行します。

1. ターゲット構成の収集後に実行するロジックを指定します。
このロジックは、ソース管理対象エンティティGUID、アソシエーション・タイプおよび宛先管理対象エンティティGUIDを指定するトリプル形式でアソシエーション・インスタンスのセットを導出します。たとえば、タイプoracle_listenerのターゲットに対するアソシエーション導出ロジックは、リスナーとリスニングする各データベース間のアソシエーションを表すトリプルを返します。

2. トリプルの導出に使用するロジックを含むSELECT文を作成して実行します。
返された各行には、アソシエーション・タイプ、ソースおよび宛先の列が含まれ、存在するアソシエーションを表します。

3. エンタープライズ構成管理のスナップショット・タイプに対する導出ロジックを登録します。
すべてのスナップショットの収集後、登録したロジックが起動されます。ロジックへの入力は、データが収集されたターゲットのGUIDです。

ターゲットTのスナップショットSに対するアソシエーション導出ロジックが実行されると、導出されたアソシエーションで、ターゲットTのスナップショットSに対する以前に導出されたアソシエーションが置換されます。たとえば、昨日アソシエーションA1およびA2が収集され、今日A1のみが収集された場合、A2は事実上削除されます。

5.3 アソシエーション導出ルール管理の使用方法

Enterprise Manager Cloud Control 12cは、Enterprise Managerコンポーネントによるアソシエーションの使用を拡張し、アソシエーション・フレームワーク全体を強化しています。システム・ステンシルやトポロジ・ビューアを含め、アソシエーションの新しいコンシューマが導入されています。

アソシエーション・フレームワーク拡張機能には、アソシエーションを構成データとして処理することが含まれています。変更トラッキングや保存済スナップショットなどのエンタープライズ構成管理の機能は、アソシエーションおよび従来の構成データに適用されるようになりました。現在、アソシエーションでは、ソースおよび宛先のターゲット・コンポーネントの他にターゲットGUIDも指定できます。

5.3.1 すぐに使用できるアソシエーション・タイプについて

Enterprise Managerには、ほとんどのプラグイン開発者のニーズを満たすアソシエーション・タイプの共通セットが用意されています。プラグイン開発者はこれらのアソシエーション・タイプについてよく理解して使用する(該当する場合)ことをお薦めします。また、インテグレータおよびドキュメントの表を、アソシエーション・タイプおよびすべてのアソシエーション・タイプの使用状況(allowed_pairs)が記載されているドキュメントへのリンクで更新する必要があります。

次の図は、コア・アソシエーション・タイプの階層を示したものです。

図5-1 コア・アソシエーション・タイプの階層

5.3.2 プラグイン開発者の担当作業の概要

プラグイン開発者は、導出されたアソシエーションに関して次の手順を実行します。

1. 所有する管理対象エンティティ(ME)について表す必要があるすべてのアソシエーションを特定します。
一般に、これには、所有するMEとその他のME間の包含または依存のアソシエーションが含まれます。特定されたアソシエーションの種類ごとに、そのタイプのアソシエーション・インスタンスが必ず最新状態に保たれるようにする担当者を決定するために、関連MEタイプの所有者との調整が必要な場合があります。一部のアソシエーション(特にhosted_byおよびmanaged_by)は、Enterprise Managerによって自動的に保持されるため、アソシエーション導出ルールを使用する必要はありません。

2. Enterprise Managerに同梱されているすぐに使用できるアソシエーション・タイプのセットを理解し、最も適切なタイプの使用を確認します。
詳細は、5.3.1項「すぐに使用できるアソシエーション・タイプについて」を参照してください。

3. 正しいアソシエーションを返し、許容できる状態で実行する問合せを指定します。
必要な構成データが収集されていない場合は、許容できるパフォーマンスを保証するような収集を追加する必要もあります。ルールでは、必要な場合に評価がトリガーされるように、ルール問合せのベースとなる構成表を特定する必要があります。

4. アソシエーション導出ルールを使用して、リポジトリに存在する構成データに基づいて、存在するアソシエーションを(宣言的に)記述していることを確認します。
ルールは、(ターゲット・プロパティ変更も構成収集として処理される)構成収集によってトリガーされます。

5.3.3 パフォーマンスの維持

導出ルールの評価は頻繁になる場合があるため、低パフォーマンスのルール問合せは問題となる可能性があります。ルール作成者は、必要な索引が存在すること確認し、トリガーごとに生成される特定の問合せに基づいて問合せパフォーマンスをテストする必要があります。

特に、ルール問合せのテストは、各トリガーによって異なる問合せが実行されるため、トリガーごとに実行する必要があります。ルール問合せが値を返す方法は、トリガーに応じて特定のターゲット・グローバル一意識別子(GUID)にバインドされていることに注意してください。

これらのバインディングを使用する索引が必要です。さらに、問合せは、外部から問合せへのバインディングのプッシュを妨げない方法で記述する必要があります。

5.4 オーバーラップ・アソシエーションについて

複数のルールによって同じアソシエーションを導出することは可能ですが、通常、このようなオーバーラップ・ルールを作成することは避けます。この項では、複数のルールでアソシエーションが導出された場合の処理について説明、これを回避する場合および方法に関する推奨を示します。

5.4.1 ルールによって導出されたアソシエーション間のオーバーラップについて

複数のルールが同じアソシエーションを導出すると、そのアソシエーションは各ルールが導出しなくなるまで存在し続けます。これが求めるものである場合もあります。たとえば、2つのアプリケーション・ターゲット・タイプがそれぞれ実行されているOracle WebLogic Serverとアクセスするデータベースの両方を認識しているとします。その認識に基づいて、Oracle WebLogic Serverとデータベース間のアソシエーションを導出する方法をそれぞれ持っています。いずれかのルールがアソシエーションを導出した場合、そのアソシエーションは現実に存在します。両方のルールがそのアソシエーションを導出しなくなった場合のみ、アソシエーションは存在しなくなったと考えることができます。

"いずれかのルールが導出した場合は存在する"というセマンティクスは、意図したものでないことがあります。データベースとOracleホーム間のinstalled_onアソシエーションについて定義できる2つのルールを考えてみます。いずれも同じデータにアクセスしますが、一方はOracleホームに対するプロパティ変更によってトリガーされ、他方はデータベースに対する変更によってトリガーされます。いずれかのルールが関係がなくなったと判断するとすぐに、アソシエーションは削除される必要があります。このような場合、2つのトリガーを持つ単一のルールを使用する必要があります。

このような場合に、1つのルールのみを記述するように配慮しなかったとします。結局、アソシエーションはすぐに削除されるため、このミスは深刻ではないと考えるかもしれません。しかし、これがそうではなく、偽のアソシエーションがいつまでも存在する可能性があります。前述の例で、2つのルールを使用してアソシエーションが導出された場合に、データベースをアップグレードしてOracleHomeプロパティを変更します。古いホームとのアソシエーションは削除される必要がありますが、他方のルールが起動されるまで削除されません。しかし、Oracleホーム・ターゲットに関して何も変更されなかったため、ルールはトリガーされず、アソシエーションは残ります。確かに、一方のターゲットのみが変更され、他方のターゲットは長期間変更されないままであることはよくあります。一般的な経験則から、表の特定のセットからのデータに基づいたアソシエーションは複数のトリガーを持つ単一のルールを使用して導出する必要があります。

アソシエーションが存在すると断定する別の理由がないかぎり、1つのルールのみを使用する必要があります。このような場合、導出ルールによって返されるアソシエーションは切り離す必要があります。これを別の言い方をすると、これらのアソシエーションの場合、すべてのルール問合せによって返されるすべての行のセットで重複しない必要があります。アソシエーションはソース、宛先およびアソシエーション・タイプによって特定されます。つまり、これら3つの値の組合せは一意である必要があります。

5.5 よくある質問

この項では、最もよくある質問のうち、次の3つを説明します。

1. ルール問合せではどの表を参照できますか。

2. ターゲット・プロパティを使用するときのガイドラインはありますか。

3. 検出されたアソシエーションと導出されたアソシエーションはどのような関係ですか。

5.5.1 ルール問合せではどの表を参照できますか。

ほとんどの場合、問合せでは、CM$ビューを使用して構成(エンタープライズ構成管理)表を参照します。トリガーも同様です。他の表を参照する場合およびそのデータがエンタープライズ構成管理表の変更とは関係なく変更されることがある場合、アソシエーションは必要なときに更新されないことがあります。表に対する変更がルール評価をトリガーする必要があるエンタープライズ構成管理以外の表を参照するユースケースがある場合は、Oracle担当者に連絡してください。

もう1つの考慮事項は、表が存在するコンポーネントです。ルールで参照する表がEnterprise ManagerコアSDKに含まれていない場合、プラグインではその表のプラグインに対する依存性を考慮する必要があります。たとえば、プラグイン依存性メカニズムを使用して、参照するオブジェクトがリポジトリ内にすでに存在していることを確認する必要があります。

5.5.2 ターゲット・プロパティを使用するときのガイドラインはありますか。

ターゲット・プロパティは構成データとして処理され、ターゲット・タイプごとに移入されるエンタープライズ構成管理スナップショット表があります。この表のデータを使用する場合、注意する必要があります。

- 多くのターゲット・プロパティは、検出時に設定され、変更できません。

- 名前/値ペア・データの問合せは扱いにくく、データがさらに構造化されている他の表に対する問合せよりも時間がかかる可能性があります。

- ターゲット・プロパティ表とエンタープライズ構成管理スナップショット表の両方からデータが使用できる場合は、後者を使用します。

- 構成データの収集を追加する必要がある場合は、ターゲット・プロパティ表の新しい行としてではなく、エンタープライズ構成管理表に追加します。

一般に、ターゲット・プロパティの使用は避け、標準のECMメカニズムを使用してデータを収集およびモデル化します。

しかし、追加できるエンタープライズ構成管理の収集がターゲットにないなどの場合、ルールでターゲット・プロパティの参照が必要になることがあります。そのようなターゲットに対するアソシエーションを作成する場合は、それを特定する方法が必要です(たとえば、ルールでそのターゲット・プロパティを参照する必要があります)。

ターゲット・プロパティを使用する必要がある場合は、ルール問合せでMGMT_TARGET_PROPERTIESを参照します。また、実行する必要がある結合をビューですでに実行している場合は、ルール問合せでMGMT$TARGET_PROPERTIESを参照することもできます。しかし、トリガーでは、GC$TARGET_PROPERTIESビューをorcl_tp_configスナップショット・タイプに使用する必要があります。

MGMT_TARGET_PROPERTIESは、より効率的であるため問合せで使用しますが、GC$ビューで使用できないプロパティがいくつか含まれることがあります。GC$ビューでのプロパティ変更に基づいたトリガーのみ使用できます。たとえば、Enterprise Managerに正しく登録されたプロパティが含まれるのは、GC$ビューのみです。

5.5.3 検出されたアソシエーションと導出されたアソシエーションはどのような関係ですか。

これは、オーバーラップ・アソシエーション(詳細は、5.4項「オーバーラップ・アソシエーションについて」を参照)のもう1つの例です。たとえば、ターゲットT1とT2間のアソシエーションを検出する検出ロジックに加えて、同じアソシエーションを導出するルールがある場合があります。同じアソシエーションを作成する2組のロジックを記述しないことをお薦めします。この場合は、次のようにすることをお薦めします。

- アソシエーションが変化することがあるため導出ルールが必要な場合は、導出ルールのみを記述します。

- ソースまたは宛先が削除されるまで検出されたアソシエーションが変化しない場合は、アソシエーションの検出で構わず、より簡単または効率的である可能性もあります。

同じアソシエーションを作成するロジックを2組(検出ロジックと導出ルール)記述すると、検出されたアソシエーションが残り、導出ロジックもそのアソシエーションの存在を断定します。その後、アソシエーションがもう存在しないとルール評価が判断した場合、ルールの断定は削除されますが、検出されたアサーションを手動で削除するまでアサーションは存在し続けます。

6 ジョブ・フレームワークの使用方法

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

- ジョブ・フレームワークの概要

- ジョブについて

- ジョブの新機能

6.1 ジョブ・フレームワークの概要

Enterprise Managerには、ターゲットまたはターゲットのグループに対して実行される管理タスクの自動化を管理するジョブ・フレームワークがあります。自動化フレームワークは、ターゲット、資格証明、イベントなどの他のEnterprise Managerサブシステムと緊密に統合されているため、顧客は1つのコンソールからターゲットを監視および管理できます。

ジョブ・フレームワークによって提供されるインタフェースを使用すると、プラグインに定義されているターゲット・タイプの自動化要件をサポートできます。重要な管理機能の自動サポートを提供して、ジョブ・タイプをプラグインの一部として定義できます。

その結果、Enterprise Manager管理者は、プラグインでサポートされるターゲットを管理するために、それらのジョブをスケジュール、実行および監視できます。これらのジョブは、管理ベスト・プラクティスを施行する、修正処理としてアラートに対処する、あるいは企業の管理全般を自動化するために使用できます。Enterprise Managerには、ジョブ・コンソールが組み込まれており、管理者はジョブの実行を発行および監視できます。

6.2 ジョブの新機能

このリリースの新機能は次のとおりです。

- 資格証明の使用
資格証明の使用は、ジョブ・タイプと資格証明セット間のより直接的なリンクを可能にします。詳細は、6.2.1項「資格証明拡張機能について」を参照してください。

- Enterprise Managerの診断機能フレームワーク
各種Enterprise Managerコンポーネント内の診断機能を向上させます。詳細は、6.2.2項「ロギング拡張機能の概要」を参照してください。

6.2.1 資格証明拡張機能について

Oracle Enterprise Manager 12c リリース4 (12.1.0.4)より前は、ジョブ資格証明は2つのパラメータ(ユーザー名およびパスワード)で表していました。これには、資格証明セット、資格証明タイプおよびその列に関する知識と、Enterprise Managerでサポートできる認証スキームのプールに関係なく、ジョブ・タイプでサポートされる各種認証方式に関する知識も必要でした。

これらの問題を克服し、ジョブ・タイプの統合メカニズムを進化させて資格証明を指定するために、資格証明の使用と呼ばれる新しい概念が導入されました。資格証明の使用は、ジョブ・タイプと資格証明セット間のより直接的なリンクを可能にします。資格証明に含まれる個々の項目を特に参照する必要はありません。資格証明情報の指定の詳細は、Enterprise Managerプログラマーズ・リファレンスを参照してください。

6.2.1.1 資格証明タイプについて

資格証明タイプは、ターゲット・タイプでサポートされる認証のタイプです。たとえば、ホストでは、ユーザー名/パスワード・ベースの認証、公開鍵認証、Kerberos認証がサポートされます。ネイティブ・エージェント認証およびSSHを含め、様々な認証スキームがサポートされます。

ネイティブ・エージェント認証スキームではユーザー名/パスワード構造を採用していますが、SSH鍵認証スキームではユーザー名/秘密鍵/公開鍵構造を使用しています。

6.2.1.2 名前付き資格証明について

名前付き資格証明は、システム上のユーザーの認証情報です。名前付き資格証明には、ユーザー名/パスワード、公開鍵/秘密鍵のペア、またはX509v3証明書を使用できます。Enterprise Manager管理者は、これらの資格証明を名前付きエンティティとしてEnterprise Managerに格納し、ジョブの実行、パッチの適用、その他のシステム管理タスクなどの操作を実行するときに使用できます。たとえば、パッチの適用に使用するユーザー名およびパスワードをMyPatchingCredsとして格納できます。その結果、後でMyPatchingCredsを使用するパッチ適用ジョブを発行して、本番環境のデータベースにパッチを適用できます。

6.2.2 ロギング拡張機能の概要

Oracle Enterprise Manager 12c リリース4 (12.1.0.4)から、Enterprise Manager診断機能フレームワークが提供されており、各種Enterprise Managerコンポーネント内の診断機能を向上させることができます。このフレームワークは、構造化された最初の障害診断データを簡単に取得し、診断データの収集、パッケージ化およびOracleへのアップロードのプロセスを自動化します。

ジョブ・タイプをプラグインに定義しているときに、管理エージェントで実行中のジョブ・ステップからメッセージをロギングして、このフレームワークを利用できます。

6.3 ジョブについて

ジョブは、ジョブ・システムによって実行される作業単位です。管理者は、ジョブを作成し、ジョブの実行時期について日曜午前0時システムBにパッチ適用などのスケジュールを指定します。管理サーバーにより、ジョブはスケジュールおよび実行されます。

ジョブは、ジョブを構成するステップを定義するジョブ・タイプ定義の他、ジョブの実行に入力として必要なパラメータおよびジョブでアクセスするターゲットへのアクセスに必要な資格証明に基づいています。ジョブの発行時、パラメータおよび資格証明の値は発行者によって指定されます。

ジョブの実行は、相互に関連するジョブ・ステップの集合です。ステップは、ステップセットにグループ化できます。ステップセット内のステップは、シリアル(1つずつ)またはパラレル(同時)に実行できますが、両方で実行することはできません。ステップ(およびステップセット)は、他のステップの成否に基づいて実行することもできます。これらの概念の詳細は、Enterprise Managerプログラマーズ・リファレンスを参照してください。

ジョブ内のステップでは、管理エージェントでコマンド、スクリプトなどを処理できます。Enterprise Managerには、作成するジョブ・タイプ定義に含めることができる共通コマンドがいくつか用意されています。これには、(スクリプトの実行を可能にする)リモート操作などのコマンドと、putやgetなどのファイル転送コマンドが含まれます。

各ステップに関連付けられたコマンドは通常、管理エージェントによってリモート・ノードに対して実行されます。ジョブの調整および全体ステータスは、管理サーバーによって保持され、管理リポジトリに格納されます。

図6-1 ジョブの概要

ジョブは、1つ以上のターゲット・リストを持っていることがあります。しかし、一部のジョブはターゲットを持たず、このようなジョブの場合、ターゲット・リストは空またはnullです。ターゲット・リストは、ジョブの1回の実行に必要なターゲットのセットです。ターゲット・リストを解析するかどうかはジョブ・タイプによります。たとえば、OSCommandジョブ・タイプは、指定パラメータで指定コマンドをリストのすべてのターゲットに対してパラレルに実行します。データベースのスキーマをクローニングするジョブは、若干異なる方法でターゲット・リストを解析します。たとえば、最初のターゲットをクローニング元のソース・データベースとみなします。2番目の引数をクローニングされたスキーマを移入するターゲット・データベースとみなします。ジョブは複数のターゲット・リストを指定して発行でき、それぞれが別個の実行になります。

最後に、すべてのジョブにはスケジュールが必要です。スケジュールでは、ジョブの実行時期を指定します。ジョブ・システムには、即時実行のジョブを発行する機能、多種多様なスケジューリング・オプションに従って繰り返し実行するジョブを発行する機能など、豊富なスケジューリング機能があります。

6.3.1 ジョブ・タイプの定義

ジョブ・タイプは、特定のジョブ・カテゴリで、明確に定義された作業単位を実行します。ジョブ・タイプは名前によって一意に識別されます。たとえば、AppPatchは、Oracleアプリケーション・インストールにパッチを適用するジョブ・タイプです。OSCommandは、リモート・コマンドなどを実行するジョブ・タイプです。

ジョブ・タイプは、ジョブ内のステップ、各ステップで実行する作業(コマンド)およびステップ間の関係を指定するXMLドキュメントによって定義できます。jobTypeメタデータ・サービスを使用して、プラグインにジョブ・タイプを含めます。

ジョブ・タイプ定義に加えて、管理エージェントのデプロイの一環として、ジョブ・タイプで参照されるスクリプトをプラグインにパッケージ化する必要があります。

ジョブの定義およびパッケージ化の詳細は、Enterprise Managerプログラマーズ・リファレンスを参照してください。

7 レポート作成フレームワークの使用方法

この章では、次の項目について説明します。

- レポート作成フレームワークの概要

- レポート作成の新機能

- レポート作成テクノロジの選択

- BI Publisherレポートの開発

- Enterprise Manager情報パブリッシャ・レポートの開発

7.1 レポート作成フレームワークの概要

Enterprise Managerの強力なレポート作成フレームワークを使用すると、企業全体で対象読者が管理対象の環境に関する情報にアクセスできるようになります。戦略的には、レポートは、エンタープライズの監視情報のビューをビジネス・インテリジェンス目的で提示するために使用されますが、管理対象ターゲットのアクティビティ、リソース使用率および構成を示すことで管理目的でも役立ちます。IT管理者は、レポートを使用して、一連の管理対象システムの可用性を示すことができます。エグゼクティブは、一定期間におけるアプリケーション(会社の電子メールなど)の可用性に関するレポートを表示できます。Enterprise Managerには、このような様々なニーズに対応する100を超えるレポートが同梱されています。さらに、顧客はカスタマイズされた独自のレポートを作成できます。

7.2 レポート作成の新機能

BI Publisherは、あらゆるタイプの高度にフォーマットされたドキュメントを作成、管理および配信するOracleのエンタープライズ・レポート・サーバーです。エンドユーザーは、Webブラウザで直接または使い慣れたデスクトップ・ツールを使用してレポートのレイアウトを設計でき、レポートの開発および保守に必要な時間とコストは大幅に削減されます。非常に効率的で拡張性が高いため、BI Publisherでは、トランザクション・システムへの影響を最小限に抑えながら1時間に何万ものドキュメントを生成できます。

Enterprise Managerリリース10.2以降、埋込みレポート・ソリューションである情報パブリッシャが同梱されています。しかし、このリリースの時点では、情報パブリッシャのレポート作成フレームワークは非推奨であり、BI Publisher製品を使用してレポートを開発することを推奨しています。新しいレポートは、BI Publisherを使用して開発する必要があり、古いレポートは新しいテクノロジに移行します。Enterprise Manager情報パブリッシャは引き続きEnterprise Manager 12c リリース4 (12.1.0.4)に同梱され、このソリューションに基づいたすぐに使用できる既存のレポートは残存し、サポートされます。

顧客は、印刷可能なPDF形式でレポートを作成したり、電子メール、FTP、印刷などの様々な配信オプションでスケジュールするなど、BI Publisherの標準機能を利用できます。また、Enterprise Managerリポジトリに対して独自のカスタム・レポートを開発することもできます。顧客がBI Publisherレポートにアクセスするには、BI Publisher UIを使用するか、またはEnterprise Managerコンソール内からレポートを選択してBI Publisher UIを起動します。

Enterprise ManagerとBI Publisher間を統合すると、管理者は、Enterprise ManagerユーザーがEnterprise Managerユーザー名およびパスワードを使用してBI Publisherにログオンできるように、BI PublisherおよびEnterprise Managerにセキュリティ設定を設定できます。この認証委任メカニズムが機能する対象は、次のとおりです。

- Enterprise Managerのネイティブ認証(リポジトリ/dbmsベースの認証など)。

- LDAP認証によってサポートされるEnterprise Manager SSO
BI Publisherは、この場合にEnterprise Managerが使用するのと同じLDAP認証メカニズムを共有します。しかし、BI Publisherは、SSOを使用するように構成されず、かわりにBI Publisherのネイティブ・ログイン画面を使用します。

Enterprise Manager 12cを使用すると、BI PublisherとEnterprise Managerは緩やかに統合されます。BI Publisherは別個の製品として独自のOracleホーム・ディレクトリにインストールされます。

7.3 レポート作成テクノロジの選択

新しいレポートは、製品の要件に基づいてBI PublisherまたはEnterprise Manager情報パブリッシャ(IP)のいずれかのレポート作成フレームワークを使用して開発できます。しかし、情報パブリッシャ・レポートはリリース12c リリース1 (12.1.0.2)から非推奨であるため、BI Publisherをお薦めします。

BI Publisherレポートには、次の利点があります。

- ページ区切りおよびヘッダー/フッターを使用した、高度にフォーマットされた出力専用の業務用レポート。

- PDF、XLSおよびHTML出力形式。

- JDBC (Java Database Connectivity)データ・ソースによってサポートされるEnterprise Managerリポジトリのアクセス・モデルと、仮想プライベート・データベース(VPD)のプロセスごとの関数(VPDはログインしているBIPユーザーとして設定されます)。MGMT_VIEWアカウントに使用できるselect文およびパイプラインPL/SQL関数のサポート。

- "フォルダリング"を使用し、フォルダにアクセス権を付与するBI Publisherレポートのアクセス・モデル。

- スケジュール機能および配信メカニズム(FTPなど)。

- レポート定義とは別に編集できる書式。

- レポート生成時のBI Publisherパラメータ機能によるパラメータ化。

Enterprise Manager情報パブリッシャ・レポートには、次の利点があります。

- Enterprise Managerコンソール・ページのような外観のレポート(レイアウトに対する制御が厳格ではありません)。

- Enterprise Manager Oracle Management Services (OMS)およびリポジトリとの緊密な結合。

- 統合されたダッシュボード。

7.4 BI Publisherレポートの開発

BI Publisherレポートには、データ・モデル・コンポーネント、レイアウト・コンポーネントおよび変換コンポーネントがあります。データ・モデル・コンポーネントは、BI Publisher UIを使用してモデル化されます。レポート・レイアウトはRTFテンプレートを使用して生成されます。RTFテンプレートは、BI Publisherレポート開発者によってBI Publisherデスクトップ・アプリケーションを使用して作成されます。このアプリケーションは、Microsoft Wordプラグインとして配信されます。

BI Publisherレポートの完全な例は、BI Publisher統合に同梱されています。これには、データ・モデルおよびレポート定義が含まれます。

レポートの開発およびテストが済むと、これらのコンポーネントはすべてBI Publisherからファイルとしてエクスポートして、プラグインの一部としてパッケージ化できます。

レポートの開発およびパッケージ化プロセスの詳細は、プログラマーズ・リファレンスを参照してください。

7.5 Enterprise Manager情報パブリッシャ・レポートの開発

Enterprise Manager情報パブリッシャ・レポートは、XMLで定義され、プラグインにパッケージ化されます。これらのレポート定義は、レポートのレイアウトおよびコンテンツを指定します。新しいレポート定義はBI Publisherインタフェースを使用して開発する必要があります。Enterprise Manager情報パブリッシャのPL/SQL APIを使用しないでください。

これらのAPIは、Enterprise Manager 12c リリース1 (12.1.10.2)より前に作成されたプラグインに含まれるレポートに対して引き続きサポートされますが、12c リリース1 (12.1.10.2)に変換されます。これらのAPIは、新しいレポートの開発にはサポートされません。

8 管理ユーザー・インタフェースについて

Enterprise Managerを拡張して、検出、監視および自動化を導入することによって新しいドメインの管理をサポートできます。Enterprise Managerフレームワークにはこれらの管理機能に関連する強力な機能のセットが用意されていますが、ほとんどのプラグイン開発者は自分のドメインに適した方法で管理機能を公開したいと思っています。Enterprise Managerのメタデータ・プラグイン・カスタム・ユーザー・インタフェース(MPCUI)機能は、この機能を備えています。

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

- MPCUIフレームワークの概要

- メタデータのみまたはFlexユーザー・インタフェースの作成

- MPCUIサービス

- MPCUIおよび拡張開発者キット

8.1 MPCUIフレームワークの概要

MPCUIフレームワークでは、サポートされているAPIによるEnterprise Managerサービスへの制御されたアクセスをサポートしています。これらのAPIを使用すると、他の機能をサポートするEnterprise Managerのアップグレードに関係なく、ユーザー・インタフェースをEnterprise Managerにプラグインの一部として安全に追加できます。

MPCUIでは、要件に応じてUIを構築するための漸進的なオプションのセットを提供しています。MPCUIには、テンプレートおよび再利用可能なコンポーネントが用意されており、UIの開発のためのフレームワーク習得と動作保証のためのフレームワーク習得という両方の観点から、最小限の作業でカスタムUIを構築できます。UIに対する制御の強化が必要な場合、MPCUIでは、カスタマイズされた管理ユーザー・エクスペリエンスを構築するための構成要素を提供して、ドメインに最適な方法でそのUIを柔軟に構築できるようにしています。

注意:
MPCUIは、プラグインの一部として含める必要はありません。プラグインを作成してカスタムUIを提供しない場合、ターゲットは引き続きCloud Controlに表示され、デフォルトのUIが表示されます。

8.2 メタデータのみまたはFlexユーザー・インタフェースの作成

MPCUI実装は、プラグインの「管理サービス」セクションの一部として(oms/metadataディレクトリの下など)、プラグインに含まれます。MPCUIには、ユーザー・インタフェースの実装について2つの選択肢があります。

- メタデータのみ
メタデータのみ方式では、ユーザー・インタフェース全体をXMLで記述でき、複数ページのサポート、ダイアログ定義、チャート、表など、MPCUIに用意されている多くの機能が含まれます。主に管理データ(監視または構成データ)の表示に基づいて、カスタマイズされたユーザー・エクスペリエンスを提供する場合、"メタデータのみ"の選択で十分です。

- Flex UI
Flex実装オプションにより、ジョブまたは管理エージェント・スクリプトとしてプラグインに含まれている管理機能に加えて、カスタマイズされたUIを提供するための追加機能が提供されます。きわめて柔軟性の高いFlex実装によって、さらに複雑なユーザー・インタラクティビティが可能です。

時間の経過とともに要件が変化する場合、メタデータのみ実装用に提供されるタグ言語がFlex実装でサポートされる言語のサブセットであるため、フレックス実装の開始点としてメタデータ実装を使用できます。

8.2.1 ユーザー・インタフェースのコンポーネント

ユーザー・インタフェースを構成するコンポーネントは、次のとおりです。

- ページ、レイアウトおよびナビゲーション

- パッケージ化されたリージョン

- チャートおよび表

- その他のコンポーネントおよびルック・アンド・フィール

8.2.1.1 ページ、レイアウトおよびナビゲーション

MPCUIを使用すると、複数ページ、ダイアログおよびトレイン(ウィザード)で構成されるユーザー・インタフェースを構築できます。これらのページ間のナビゲーションをMPCUI実装の一部として定義する他、Enterprise Managerの他のページまたは外部URLへのナビゲーションも定義します。

MPCUIフレームワークを使用すると、Enterprise Managerメニュー・サブシステムに登録する必要があるページを選択できます。これにより、メニュー項目をターゲット・メニューに表示できるようになり、MPCUI実装で定義されているページへのナビゲートが可能になります。

MPCUIフレームワークには、グリッド・スタイル・レイアウトを使用してUIに定義されているページ上にコンポーネントを簡単にレイアウトする方法があります。フレームワークには、ページ内でコンテンツ・コンテナを提供し、そのコンテンツの展開および折りたたみをサポートするリージョン・コンポーネントが含まれています。図8-1に、サマリー情報が表示されているリージョンを示します。

図8-1 「サマリー」リージョン

8.2.1.2 パッケージ化されたリージョン

MPCUIフレームワークでは、プラグイン開発キットにパッケージ化された多数の再利用可能なリージョンを提供しています。これを使用すると、イベント情報やジョブ・サマリー情報など、共通して表示されるコンテンツをターゲット・ホーム・ページに含めることができます。

図8-2に、MPCUIフレームワークで提供される「問題」リージョンを示します。

図8-2 「問題」リージョン

ページ定義で次のようなエントリを1つ使用して、ユーザー・インタフェースで構築されるページにリージョンを追加できます。

<events:IncidentRegion height="33%" width="100%" />

8.2.1.3 チャートおよび表

MPCUIでは、ユーザー・インタフェースにチャートおよび表を含めることをサポートしており、表示するメトリックまたはSQL文の実行結果を指定することで、それらのコンポーネントに表示するデータの選択機能を簡略化しています。サポートされるチャート・タイプには、円グラフ、棒グラフ、線グラフおよび面グラフがあります。

図8-3 「リソース」リージョン

8.2.1.4 その他のコンポーネントおよびルック・アンド・フィール

ページ定義、リージョンおよびチャートの上位レベルのコンポーネントに加えて、ボタン、ラベル、テキスト入力などのFlexコンポーネントのフルセットにアクセスできます。

どのような場合でも、MPCUIフレームワークでは、その他すべてのCloud Controlユーザー・インタフェースの同じルック・アンド・フィールで表示されるようにコンポーネントのスタイルを設定し、カスタマイズされたUIがEnterprise Manager Cloud Control製品の完全に統合された部分として必ず表示されるようにしています。

8.3 MPCUIについて

MPCUIでは、Adobe Flex UIフレームワークを使用して、Enterprise Managerページ(クロム)内で実行されるアプリケーション(SWF)の構築を可能にしています。残りのEnterprise Manager UIと統合されたエクスペリエンスを提供しながら、UIおよびコードとEnterprise Managerの残りの部分の分離を維持しています。

このフレームワークはAdobe FlexおよびWebサービスをベースにしていますが、フレームワークの主な目的は、管理UIの構築プロセスを簡略化することです。そのため、フレームワークでは、できるだけ基礎となるテクノロジが除外されています。フレームワークには、パッケージ化されたコンポーネントおよびサービスが備えられており、Adobe Flex、WebサービスまたはUIフレームワークの専門家にならなくても、それらを組み合せてドメインに適した管理UIを作成できます。

8.3.1 概要

MPCUIフレームワークでは、監視データ(ターゲット・アソシエーション、プロパティ、メトリック、構成データなど)の取得に使用する一連のWebサービスと、同期タスクおよび非同期ジョブを実行する自動化サービスを公開しています。

構築したUIは、プラグインにパッケージ化され、メトリック定義、ジョブ定義、検出スクリプト、監視スクリプトなどの他の統合オブジェクトとともにEnterprise Managerにデプロイされます。

プラグインのMPCUIオブジェクトは、管理リポジトリに格納されます。実行時に、Enterprise Managerクロムが表示されるラッパー・ページをレンダリングするEnterprise Managerフレームワーク・コードによって取得されます。MPCUIは、エンドユーザーのブラウザでAdobe FlashPlayerプラグイン内で実行されます。これは、1つのプラグインのカスタムUIに関連するあらゆる問題からEnterprise Managerの残りの部分を保護するサンドボックス化された環境です。

管理UIは、リポジトリ・データ、ジョブ・サブシステム、エージェント・サービスなどのEnterprise ManagerサービスにMPCUIサービス・レイヤーからアクセスできます。MPCUIサービス・レイヤーは、Enterprise Managerフレームワークで提供されるWebサービスで構成されています。

8.3.2 UIフレームワークについて

MPCUIには、ページ、トレイン、リージョン、チャート、表、パッケージ化されたコンポーネントを含め、管理UIの構築に使用できる多くのUIコンポーネントが含まれています。これらのコンポーネントの多くもまた、Enterprise Managerサービスを利用して、管理情報へのアクセスや表示を簡略化しています。

たとえば、チャートおよび表コンポーネントを使用すると、メトリックまたはパッケージ化されたSQL問合せをコンポーネント・タグ内に指定して、監視データをUIに簡単に含めることができます。

MPCUIフレームワークには、利用できる様々なコンポーネント・レイヤーがあります。このフレームワークには、追加の作業をしなくても管理UIのスタイルがEnterprise Managerのスタイル・ガイドラインと必ず一致するようにするためのサポートが含まれています。

MPCUIベースのアプリケーションの構造を簡略化し、より自然にEnterprise Managerフレームワークに合せるために、MPCUIにはページの概念が組み込まれています。管理UIに1つ以上のページを含めて、MPCUIフレームワークによって提供される構造を使用してページ間を移動することができます。1つ以上のページをEnterprise Managerメニュー・システムに統合することもできます。

MPCUIフレームワークに含まれている適切なUI要素を使用してドメイン固有の管理UIを構築し、MPCUIサービス・クライアント・ライブラリからEnterprise Managerサービスにアクセスしてください。

8.4 MPCUIサービス

MPCUIをしてユーザー・インタフェースを構築すると、フレームワークに同梱されている多くのサービスにアクセスでき、Enterprise Managerデータへのアクセスおよび操作の実行が可能になります。これには、次のサービスがあります。

- ターゲット・プロパティ
バージョン、カテゴリ、その他の動的インスタンス・プロパティなど、ターゲット・インスタンスのプロパティの取得をサポートします。

- ターゲット・アソシエーション
現在のターゲット、関連ホスト、メンバーなどに関連付けられたターゲットの取得をサポートします。

- メトリック・データ
管理エージェントからの現在(リアルタイム)の値や管理リポジトリに格納されている履歴データなど、メトリック・データの取得をサポートします。

- SQLの結果
プラグインにパッケージ化されたSQL文の処理と、それらの文の結果の取得をサポートします。

- ジョブおよびリモート操作
ジョブのスケジューリングまたは管理機能を実行するリモート操作の即時処理(管理エージェント・スクリプト)をサポートします。

8.5 MPCUIおよび拡張開発者キット

拡張開発キット(EDK)には、ライブラリやMPCUIを構築するスクリプトなど、MPCUIの開発に必要な要素が含まれています。しかし、Flex実装オプションを使用してMPCUIを実装する場合は、Adobe Flexソフトウェア開発キット(SDK)またはAdobe Flex Builderのライセンス供与されたコピーのいずれかを取得して、カスタムUIソースをコンパイルし、プラグインに同梱するFlexバイナリ(SWFファイル)を作成します。Adobe Flex SDKまたはAdobe Flash Builderは、EDKに付属していません。

9 検出について

自動検出は、Enterprise Managerの構成管理の一部です。この機能は、ITコンポーネントを識別し、Enterprise Managerを使用してそれらのコンポーネントを管理できるようにすることにより、構成管理およびEnterprise Managerの基盤を形成します。

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

- 自動検出の概説

- 検出の新機能

- 自動検出の概要

9.1 自動検出の概説

検出によってターゲットをEnterprise Managerに追加するには、次の2つの手順を実行します。

1. Enterprise Managerで管理されているホスト上で潜在的なターゲットを検出します。

2. ターゲットを管理エージェントに割り当てて、Enterprise Managerで管理されるようにターゲットを昇格します。

ユーザーは、Enterprise Managerで管理されているホスト上で潜在的なターゲットの自動検出を有効にできます。

自動検出を有効にするには、管理エージェント側の検出スクリプトをプラグインにパッケージ化します。自動検出がホストで構成されると、プラグインの検出部分(検出スクリプト)がホストにデプロイされます。

管理対象ホストで実行されるように自動検出が構成されると、検出は定期的に実行され、潜在的なターゲットが管理リポジトリに送信されます。

ユーザーは検出結果UIからターゲットを表示できるため、Enterprise Managerで管理されるようにターゲットを昇格するなど、様々なアクションを実行できます。

9.1.1 自動検出を追加する主な利点

自動検出を追加する主な利点は、次のとおりです。

- Enterprise Managerにターゲットを追加しやすくなります。それ以外の場合、ユーザーは各ターゲットをEnterprise Managerに手動で個別に追加する必要があります。これは、非効率的で時間のかかるタスクです。

- 1つのホストで複数のオブジェクトを管理しやすくなります。それ以外の場合、ユーザーはホストで各オブジェクトをターゲットとして手動で追加し、他のすべてのホストでこのプロセスを繰り返す必要があります。

9.2 検出の新機能

この項では、検出の新機能について説明します。

- プラグインのターゲットに対して、管理エージェント側で実行されるように自動検出を構成できます。現在、自動検出は毎日実行されるようにスケジュールされています。

- 自動構成を構成して実行すると、ユーザーが確認するように、管理エージェントはターゲットをOracle Management Serviceに送り返します。

- ユーザーは、まだ管理されていないターゲットを構成し、Enterprise Managerで管理できるように昇格することができます。

9.3 自動検出の概要

この項では、自動検出のコンポーネントの概要を示します。

- プラグイン
プラグインには、特定のターゲット・タイプのターゲットを検出および昇格するのに必要なコンポーネントが含まれます。検出フレームワークに登録する検出メタデータ、検出スクリプトおよび監視スクリプトもプラグインに含まれます。

注意:
プラグインの検出部分のみ(検出スクリプトおよび検出の実行に必要なコンテンツ)が検出のスケジュール時にデプロイされます。
プラグイン全体(監視および検出)がデプロイされるのは、検出されたターゲットが昇格されるときまたはターゲットが手動で追加されるときのみです。

- 検出モジュール
検出モジュールでは、プラグインがデプロイされるホスト上で検出するターゲット・タイプのセットを定義します。

検出モジュールは検出メタデータXMLファイルで指定します。検出メタデータXMLファイルの詳細は、Enterprise Managerプログラマーズ・リファレンスを参照してください。

- 検出メタデータ
検出メタデータを使用すると、自動検出を検出フレームワークに登録できます。拡張開発キット(EDK)には、自動検出を登録するための検出XMLスキーマ定義(XSD)が用意されています。検出メタデータの定義の詳細および要素の説明は、Enterprise Managerプログラマーズ・リファレンスを参照してください。

- 検出コンテンツ
検出コンテンツには、特定のタイプのターゲットを検出するのに必要なPerlスクリプトおよびJARファイルがすべて含まれます。

- 検出パラメータ
検出パラメータは、UIから入力された入力を検出スクリプトに渡します。これらの検出パラメータは、管理エージェントで実行される検出スクリプトで環境変数として使用できます。検出スクリプトでは、検出の実行時にこの情報を使用します。

検出パラメータは、検出メタデータXMLファイルで定義します。検出メタデータXMLファイルの詳細は、Enterprise Manager Cloud Controlプログラマーズ・リファレンスを参照してください。

- 検出スケジュール
管理エージェントが新しいホストにインストールまたはデプロイされるときに、すでにデプロイされているプラグインに対して、検出にはユーザーの入力が不要である場合、検出は自動的に構成され、24時間ごとに実行されます。

10 コンプライアンス標準について

Oracle Enterprise Manager Compliance Managementソリューションには、コンプライアンス・フレームワークおよびコンプライアンス標準を定義、カスタマイズおよび管理する機能が用意されています。また、構成、セキュリティ、記憶域などの観点から企業のベスト・プラクティスに準拠するために、ターゲットおよびシステムを評価するツールもあります。

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

- コンプライアンス管理ソリューションについて

- コンプライアンス管理の概要

コンプライアンスの詳細は、『Oracle Enterprise Managerライフサイクル管理の管理者ガイド』のコンプライアンス管理に関する章を参照してください。

10.1 コンプライアンス管理ソリューションについて

Oracle Enterprise Manager Compliance Managementソリューションで実行できることは、次のとおりです。

- ターゲットおよびシステムに有効な構成設定があるかどうかを自動的に判断します。

- ターゲットおよびシステムが構成関連の脆弱性にさらされるかどうかを自動的に判断します。

- ターゲットおよびシステムをベスト・プラクティスに準拠した状態にするために構成を変更する方法についてアドバイスします。

- ターゲットのファイル、プロセスおよびユーザー、Windowsレジストリ・エントリなどをリアルタイムに監視して、Enterprise Managerユーザーに、環境内で構成変更が行われている場所を知らせます。

- リアルタイムで検出された構成変更がオープンな変更管理リクエストによって認可されるかどうかを判断します。アクションが認可されないと判断されると、違反が作成されます。

- コンプライアンス標準ルールにマッピングするための、Oracle提供のコンプライアンス標準が用意されています。このマッピングによって、コンプライアンスに準拠していない設定およびアクションが組織で従うコンプライアンス・フレームワークにどのように影響を及ぼすかを視覚化できます。

- ライン・オブ・ビジネス所有者、ITマネージャおよびコンプライアンス・マネージャに適したIT構成および変更を定期的に参照して、組織のコンプライアンスの適用範囲を確認できるようにする場合の、コンプライアンスに焦点を合せたビューを提供します。

10.2 コンプライアンス管理の新機能

この項では、コンプライアンス管理ソリューションの新機能について説明します。

- コンプライアンスの管理とレポート
この機能では、構成、セキュリティおよび記憶域に関する企業のベスト・プラクティスについて、ターゲットおよびシステムのコンプライアンスを評価できます。この機能をサポートするため、コンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールを定義するためのフレームワークが用意されています。また、この機能は、ターゲットおよびシステムをコンプライアンスに準拠させる構成変更の推奨も行います。

- データベース構成のコンプライアンス標準のサポート
Oracleデータベースの構成データは、新しい構成およびコンプライアンス標準のフレームワーク内で管理できるようになりました。データベース記憶域に対する変更、構成データ収集、コンプライアンス領域、コンプライアンス標準への記憶域および構成ポリシーの変換。

10.3 コンプライアンス管理の概要

次の各項では、コンプライアンス管理の機能の概要を示します。

- コンプライアンス・フレームワークについて

- コンプライアンス標準について

- コンプライアンス標準ルールについて

- コンプライアンス標準の作成に関する考慮事項

- コンプライアンス評価について

10.3.1 コンプライアンス・フレームワークについて

コンプライアンス・フレームワークは、基礎となるITインフラストラクチャ、アプリケーション、ビジネス・サービス、ビジネス・プロセスおよびこれらを編成、管理、監視する方法を処理する、業界指定のベスト・プラクティスのガイドラインです。コンプライアンス・フレームワークは、これらの業界フレームワークを直接的に表現できるよう、階層的になっています。

コンプライアンス・フレームワークの定義の詳細およびコンプライアンス・フレームワークの例は、『Oracle Enterprise Manager Cloud Control拡張プログラマーズ・リファレンス』を参照してください。

10.3.2 コンプライアンス標準について

コンプライアンス・フレームワークは、ITインフラストラクチャ、アプリケーション、ビジネス・サービスおよびビジネス・プロセスが適切に編成、構成、管理および監視されることを確認するために、広く受け入れられたベスト・プラクティスに従ってチェックの集合を実行するコンプライアンス標準のセットにマップされます。コンプライアンス標準の評価は、プラットフォーム互換性、類似の構成を持つ他のカスタマに影響する既知の問題、セキュリティ脆弱性、パッチ推奨などに関連する情報を提供します。顧客は、システムを推奨されるベスト・プラクティスに準拠した状態にし、システムの安定性およびセキュリティを高める方法を習得するために、コンプライアンス標準を評価します。

コンプライアンス標準は、制御に従っているかどうかを判断するために、ITインフラストラクチャのセットに対してテストする必要があるコンプライアンス制御をEnterprise Managerによって表現したものです。コンプライアンス制御は、ポリシー、プロセスまたはプロシージャが準拠した方法に従っていることを確認するために、IT組織が実行するテストを記述したものです。コンプライアンス標準は、違反がコンプライアンス・フレームワークのコンプライアンス・スコアに影響を与えることができるように、コンプライアンス・フレームワークにマップできます。

コンプライアンス標準の定義の詳細およびコンプライアンス標準の例は、『Oracle Enterprise Manager Cloud Control拡張プログラマーズ・リファレンス』を参照してください。

10.3.3 コンプライアンス標準ルールについて

Oracle Enterprise Manager Cloud Control 12cには、次の3つのタイプのルールがあります。

- リポジトリ・ルール
Enterprise Managerリポジトリ内のメトリック収集データに対してチェックを実行します。

- リアルタイム監視ルール
ファイル、プロセスなどに対するアクションを監視します。ユーザー・ログイン/ログアウト・アクティビティの取得も行います。

- WebLogic Server (WLS)署名ルール
ベスト・プラクティスの構成をサポートするためのWebLogicターゲットをチェックします。

- エージェント側ルール
エージェントの構成の問題を検出します。これにより、Security Technical Implementation Guide (STIG)のセキュリティ仕様の実装が可能になります。

- 手動ルール
実行する必要があるが、自動化できないチェックがあります。たとえば、一般的なセキュリティ・チェックは、データ・センターへのセキュアなアクセスを確保することです。これらのタイプのチェックは、コンプライアンス・フレームワークで考慮されます。

コンプライアンス標準ルールでは、実行される実際のチェックを指定します。これらのルールは、1つ以上のコンプライアンス標準にマップされます。

コンプライアンス標準ルールの定義の詳細およびコンプライアンス標準ルールの例は、『Oracle Enterprise Manager Cloud Control拡張プログラマーズ・リファレンス』を参照してください。

10.3.4 コンプライアンス標準の作成に関する考慮事項

コンプライアンス標準は、1つ以上のコンプライアンス標準ルールを参照します。コンプライアンス標準を作成する場合、1つ以上の関連するコンプライアンス・フレームワークに適切にマップできる程度まで、標準は詳細にする必要があります。たとえば、Oracleの汎用コンプライアンス・フレームワークに存在する、次のようなコンプライアンス・フレームワーク構造を考えてみます。

- 変更および構成管理(コンプライアンス・フレームワーク・サブグループ)

- データベース変更(コンプライアンス・フレームワーク・サブグループ)

- Oracle Databaseを構成するためのベスト・プラクティス(コンプライアンス標準)

- Oracle RACデータベースを構成するためのベスト・プラクティス(コンプライアンス標準)

- Oracleプラガブル・データベースを構成するためのベスト・プラクティス(コンプライアンス標準)

このコンプライアンス・フレームワーク構造の一部にマップされる必要がある多くのコンプライアンス標準が存在し、それぞれに、この特定の要件に対処するための独自のルールがあります。ある標準は、構成設定が正しく設定されていることをチェックします。別の標準は、構成設定が変更されたかどうかをリアルタイムでチェックするために使用されます。

この例では、データベース変更コンプライアンス・フレームワーク・サブグループは、多くの異なるタイプのターゲットに関連しています。すべてのOracle Database、Oracle RACデータベースおよびOracleプラガブル・データベースには、すべてが保護される必要がある独自のタイプの構成があります。これらのターゲット固有の構成を監視するために作成されたすべての標準は、同じデータベース変更サブグループにマップされます。

コンプライアンス標準が、既存および将来のコンプライアンス・フレームワークにマップできるように詳細な方法で構造化される場合、ルール内の違反をロールアップし、コンプライアンス・フレームワークのスコアに正しく影響を与えることができます。

10.3.5 コンプライアンス評価について

コンプライアンス標準は、ターゲットで評価されます。コンプライアンス・フレームワーク、コンプライアンス標準およびターゲットの各レベルの評価結果を、エンドユーザーはEnterprise Manager UIから使用できます。

コンプライアンス評価は、ターゲットに対してコンプライアンス標準によって設定された要件および規則を検証するプロセスです。これを測定するために、コンプライアンス標準ルールは、単一の状態モニター・チェックまたはリアルタイム・モニター・チェックを実行します。これらのチェックは、コンプライアンスの1つのテストを構成するコンプライアンス標準にグループ化されます。その後、顧客のフレームワークの関連領域にテストの結果を関連付けることができるように、これらのコンプライアンス標準は、それぞれのコンプライアンス・フレームワークにグループ化されます。

コンプライアンス評価によって、ターゲットがどの程度標準に準拠しているかを示す、ターゲットのスコアが生成されます。100%のコンプライアンス・スコアとは、ターゲットがコンプライアンス標準によって設定されたすべての要件および規則に従っていることを意味します。

ターゲット・コンプライアンスを定期的に監視する必要があるため、コンプライアンス標準をターゲットに関連付ける必要があります。関連付けられたターゲットの状態がリフレッシュされると、それらのターゲットに対して評価は自動的に実行されます。

11 ソフトウェア・ライブラリについて

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

- ソフトウェア・ライブラリ・フレームワークの概要

- ソフトウェア・ライブラリ・フレームワークの主要機能

- ソフトウェア・ライブラリの拡張性の概念

- ソフトウェア・ライブラリを拡張するためのメタデータの定義

- ソフトウェア・ライブラリ・エンティティの作成と管理

- ソフトウェア・ライブラリ・エンティティの使用

11.1 ソフトウェア・ライブラリ・フレームワークの概要

Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)は、Enterprise Manager Cloud Controlで提供されるコア機能の1つです。技術的には、ソフトウェア・パッチ、仮想アプライアンス・イメージ、参照ゴールド・イメージ、アプリケーション・ソフトウェアおよび関連するディレクティブのスクリプトなど、認証済ソフトウェア・エンティティを格納するリポジトリです。ソフトウェア・ライブラリを使用することにより、Oracleが提供する任意のエンティティを選択し、これらをカスタマイズするか、独自のカスタム・エンティティを作成できます。定義すると、これらの再利用可能なエンティティをデプロイメント・プロシージャから参照し、パッチ適用、プロビジョニングなどの操作を自動化できます。

11.2 ソフトウェア・ライブラリ・フレームワークの主要機能

ソフトウェア・ライブラリ・フレームワークでは、次の項目がサポートされます。

- プラグイン・インテグレータで使用されるメタデータの定義と登録。これによりソフトウェア・ライブラリを拡張し、拡張機能やそのまま使用できるエンティティを含めることができます。詳細は、11.4項を参照してください。

- 登録済のカスタム拡張機能を活用するソフトウェア・ライブラリ・コンソール、EM CLI、アクション・スクリプトAPIなどの様々なインタフェースの使用によるソフトウェア・ライブラリ・エンティティの作成、管理およびアクセス。詳細は、11.5項を参照してください。

- ソフトウェア・ライブラリ・コンソール経由のステージング、ジョブ・ステップの実行、デプロイメント・プロシージャなど、様々なフローでのソフトウェア・ライブラリ・エンティティの使用。詳細は、11.6項を参照してください。

11.3 ソフトウェア・ライブラリの拡張性の概念

この項では、ソフトウェア・ライブラリの拡張性フレームワークで使用される様々な属性の概要を説明します。

- タイプとサブタイプ
ソフトウェア・ライブラリのすべてのエンティティは、タイプまたはサブタイプに属します。通常、タイプとサブタイプは両方で、共通の検索可能なメタデータ/構成プロパティ、デフォルト値、ファイル・アソシエーション要件などに関する、エンティティの特定の共通機能を定義します。一般的に、ソフトウェア・ライブラリ・フレームワークは、次の種類のアーティファクトを定義および維持します。

- ディレクティブ: この種類のエンティティは、スクリプトまたは実行可能ファイルを表します。

- コンポーネント: この種類のエンティティは、通常、インストール可能なソフトウェア・バンドルを表します。汎用コンポーネントと呼ばれるコンポーネントの種類のサブタイプも、デフォルトで、Enterprise Manager Cloud Controlで利用できます。

ソフトウェア・ライブラリ・コンソールに表示される他のすべてのエンティティ・タイプ(たとえば、仮想化、ベア・メタル・プロビジョニングなど)は、基本的に、ソフトウェア・ライブラリに対する拡張機能です。これらのカスタム・タイプおよびサブタイプは、Enterprise Managerにデフォルトで同梱されるプラグインの一部で、EMが構成されると、ソフトウェア・ライブラリ・コンソールに表示されます。Enterprise Manager 12.1.0.3パッチ・セット2以上では、ソフトウェア・ライブラリ・フレームワークの対象はOracleパートナーにまで広がり、Oracleパートナーはソフトウェア・ライブラリ・フレームワークを有効に活用して、独自のカスタム・タイプおよびサブタイプを定義および登録できます。

注意:
ディレクトリ以外のエンティティがある場合、独自のカスタム・タイプと1つ以上のサブタイプを作成することをお薦めします。

- フォルダ
フォルダはエンティティのコンテナです。フォルダは、別の子フォルダまたはエンティティをその中に含みます。ソフトウェア・ライブラリを使用すると、様々なユーザー定義またはプラグイン定義のエンティティを論理フォルダにまとめることができ、効率的な管理を実現できます。フォルダは、ソフトウェア・ライブラリ内のそれらのURNでも参照できます。

- エンティティ
エンティティは、ソフトウェア・ライブラリに格納された主要なアーティファクトです。エンティティは常にフォルダに関連付けられます。類似のエンティティは論理フォルダの下にグループ化され、割り当てられているタイプまたはサブタイプによりさらに分類されます。一般的に、関連するエンティティをそれら独自のフォルダにまとめることをお薦めします。

エンティティには任意で次の特性を持たせることができます。

- 属性: 属性はタイプとサブタイプの定義により定義されます。通常、属性は単純な文字列データ型を含み、メタデータで定義される必要があります。属性は、エンティティのすべてのリビジョンに適用可能です。

- プロパティ: プロパティは、環境固有の値を指定するために使用されます。プロパティは、エンティティの特定のリビジョンにのみ適用できます。

- 添付ファイル: 添付ファイルは、エンティティに関連付けられているファイルで、エンティティと一緒に格納されます。添付ファイルは、エンティティまたはそれが関連付けられているスクリプト/ソフトウェア/構成をその利用者に説明する任意の文書またはファイルです。たとえば、Readmeファイルです。添付ファイルは、通常、パッチ適用/プロビジョニングのフローに含まれず、ターゲットにステージングまたはコピーされません。

- ノート: ノートは、エンティティに追加できるコメントです。これらは、エンティティのすべてのリビジョンに適用できます。

- 関連ファイル: 関連ファイルは、ソフトウェア・ライブラリにアップロードされるか、外部の場所に格納して外部の場所から参照できます。関連ファイルは、いったん関連付けられると、ソフトウェア・ライブラリにより、プロビジョニング時に取得され、目的の宛先ターゲットにステージングされます。これらは、エンティティの特定のリビジョンにのみ適用されます。

すべてのエンティティ・リビジョンに対して、「未テスト」、「ベータ」または「本番」のいずれかの成熟度ステータスを指定できます。エンティティのリビジョンの状態は、「不完全」、「アクティブ」、「準備完了」のいずれかです。エンティティのリビジョンの状態は、その関連ファイルと関連するメタデータの状態に基づいて計算されます。

参照:
ソフトウェア・ライブラリのエンティティとその使用方法の詳細は、Oracle Enterprise Manager管理を参照してください。

- エンティティのリビジョン
エンティティには、1つ以上のリビジョンがあります。エンティティを作成すると、ソフトウェア・ライブラリ内でのそのリビジョンは、0.1に設定されます。その後、更新されるごとに、0.1ずつ増加します。エンティティの各リビジョンは、リビジョンのUniform Resource Name (URN)と呼ばれる一意の内部識別子により識別されます。URNを使用することにより、たとえば、ジョブ内やデプロイメント・プロシージャなどソフトウェア・ライブラリ・フレームワーク外でもエンティティを識別できます。URNは、EM CLIやJobtypeなどのインタフェースを使用してエンティティのリビジョンを使用、作成または変更するときに、エンティティのリビジョンを参照するために使用されます。

- 外部ID
プラグイン・インテグレータがソフトウェア・ライブラリのメタデータXMLでエンティティを定義する場合、外部IDと呼ばれる識別子をそのエンティティ用に指定する必要があります。この識別子は、プラグインのリリース時に以前のリリースのプラグインと比較して、エンティティの定義に対する変更を追跡するために使用されます。プラグインがアップグレードされると、最新リビジョンの外部IDが以前のリビジョンの外部IDと比較され、IDが一致しない場合のみ、XMLからの更新されたエンティティが再び適用されます。このため、リビジョンは、ソフトウェア・ライブラリのエンティティの各更新版に対して固有で、外部IDはメタデータ内のエンティティ定義に対する変更を追跡するのに役立ちます。

11.4 ソフトウェア・ライブラリを拡張するためのメタデータの定義

プラグイン・インテグレータは、タイプ、サブタイプ、エンティティ、フォルダなどのソフトウェア・ライブラリ・メタデータを定義し、メタデータ登録サービス(MRS)を使用して登録できます。UI、デフォルト値、属性を通してエンティティを作成および編集する場合に必要な手順は、タイプ/サブタイプ・メタデータ内で記述できます。名前、説明、プロパティおよびファイルを、エンティティ・メタデータ内に記述できます。プラグインのインストール時に、メタデータはソフトウェア・ライブラリに登録され、定義されたタイプ、サブタイプ、フォルダおよびエンティティが、それらに応じて作成されます。

いったん登録されると、カスタム・タイプ、サブタイプ、フォルダおよびエンティティは、Cloud Control UIやEMCLIなどのソフトウェア・ライブラリ・インタフェースを使用してアクセスできるようになります。登録されたフォルダやエンティティは、Oracle所有となり、閲覧できるようになります。それらを使用するには、ソフトウェア・ライブラリのCreate Like機能を使用します。この機能を使用すると、要件を満たすようにデフォルトのエンティティをカスタマイズできます。さらに、登録されたカスタム・タイプまたはサブタイプ用に、UIまたはEMCLIを通して新しいエンティティを作成できます。カスタム・タイプ/サブタイプのエンティティのUIフローは、メタデータのUI仕様により定義されます。

プラグインをアンインストールすると、タイプ、サブタイプ、フォルダ、エンティティは削除されます。UIまたはEMCLIを使用して作成されたカスタム・タイプ/サブタイプのエンティティも、プラグインをアンデプロイするときに削除されます。

11.5 ソフトウェア・ライブラリ・エンティティの作成と管理

ソフトウェア・ライブラリ・エンティティは、様々なインタフェースを使用して作成および管理できます。

- Enterprise Manager Cloud Control

- Enterprise Managerコマンドライン・インタフェース(EMCLI)

注意:
ソフトウェア・ライブラリ・コンソール、EM CLI、アクション・スクリプトAPIなどのインタフェースの1つを使用してソフトウェア・ライブラリで作成され、ソフトウェア・ライブラリにいったん保存されたエンティティは、後で他の任意のインタフェースを使用してアクセスできます。

11.5.1 Enterprise Manager Cloud Control

ソフトウェア・ライブラリ・コンソールを使用するには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。ソフトウェア・ライブラリ・コンソールは、エンティティの完全なライフサイクル(作成、管理、削除)を効率的に管理できるようにする単一のGUI対応ページです。ソフトウェア・ライブラリ機能を使用することにより、フォルダの作成、エンティティの作成、エンティティの編集、エンティティの削除、成熟度状態の管理、ノートや添付ファイルの追加、権限の管理などの多くのタスクを実行できます。プラグインをいったん定義および登録すると、ソフトウェア・ライブラリ・コンソールから、プラグイン･インテグレータ定義のタイプおよびサブタイプをエンティティの作成時に選択できます。これにより、必要なアーティファクトを厳密にモデル化するエンティティを作成できます。また、Create Likeオプションを使用して、デフォルトのOracle所有のエンティティをカスタマイズできます。Enterprise Manager Cloud Controlを使用してこれらの操作を実行する方法の詳細は、Oracle Enterprise Manager管理を参照してください。

11.5.2 Enterprise Managerコマンドライン・インタフェース(EMCLI)

EM CLIと呼ばれるコマンドライン・インタフェースを使用することで、エンティティの作成と管理を自動化できます。ソフトウェア・ライブラリの動詞とその使用方法の詳細は、『Oracle Enterprise Managerライフサイクル管理ガイド』を参照してください。

11.6 ソフトウェア・ライブラリ・エンティティの使用

ユーザー定義のエンティティとソフトウェア・ライブラリからのデフォルトのエンティティを使用して、様々な処理フローを完了できます。

注意:
プラグインUIがソフトウェア・ライブラリ検索サービスを使用する方法の詳細は、『Oracle Enterprise Manager Cloud Control拡張プログラマーズ・リファレンス』を参照してください。

- ジョブでのエンティティの使用
カスタム・ジョブ・タイプを作成および登録するプラグイン・インテグレータは、そのジョブ・タイプ定義内に、ソフトウェア・ライブラリ・ジョブ・タイプのSwlibStageEntitiesおよびSwlibUploadFilesをネストさせて、カスタム・フローを作成できます。

カスタム・ジョブ・タイプを作成する方法の詳細は、EDKでジョブ・タイプの追加に関する項を参照してください。

- デプロイメント・プロシージャでのエンティティの使用
独自のデプロイメント・プロシージャをPAFフレームワーク(ユーザー定義デプロイメント・プロシージャ)を使用して作成できます。また、要件を満たすように、デフォルトのOracle所有のデプロイメント・プロシージャをカスタマイズすることもできます。これを行うには、コンポーネント/ディレクティブを検索するコンポーネント手順またはディレクティブ手順を含める必要があり、さらに、それらをプロシージャに含める必要があります。プロシージャ内でこれらの手順が実行されると、選択したエンティティのステージングが実行されます。

UDDPの作成方法およびOracle所有のプロシージャをカスタマイズする方法の詳細は、『Oracle Enterprise Managerライフサイクル管理ガイド』を参照してください。

- ソフトウェア・ライブラリ・コンソールUIによるステージング
手順を他のフローに含める前にその使用方法をテストおよび検証するには、必要なエンティティを選択し、ソフトウェア・ライブラリ・コンソールUIを使用してステージングします。

- アクション・スクリプトAPIの使用
エンティティの詳細情報は、アクション・スクリプトWebサービスAPIを通して検索および取得できます。いったん取得された詳細情報は、FLEX UIなどの独自の方法で表示できます。

索引
A  C  D  E  F  G  I  J  L  M  N  O  P  R  S  T  U  V

A

Enterprise Managerへのターゲットの追加, 9.1

追加の管理機能

自動検出, 1.5, 2.1

自動化, 2.1

自動化(ジョブ), 1.5

コンプライアンス・ルールおよびコンプライアンス標準, 1.5, 2.1

構成管理, 1.5, 2.1

カスタム・レポート, 1.5, 2.1

カスタム・ターゲット資格証明, 1.5, 2.1

管理用のカスタム・ユーザー・インタフェース, 1.5

ジョブ, 2.1

ターゲット対ターゲットのアソシエーション, 1.5, 2.1

Adobe Flex UIフレームワーク, 8.3 エージェント・プッシュ, 1.3.1 API, クラウド, 1.1.4 アーカイブ・ファイル, プラグイン, 2.1 自動検出, 1.6, 3.3.1

コンポーネント, 9.3

有効化, 9.1

概説, 9.1

主な利点, 9.1.1

概要, 9.3

登録, 9.3

C

チャート・タイプ, 8.2.1.3

Cloud Control

管理リポジトリ, 1.1.2

Oracle Management Service, 1.1.1

プラットフォーム, 1.1

Cloud Controlコンソール, 1.1.4, 1.2.1 クラウドのWebサービスAPI, 1.1.4 構成の比較, 4.3.2 コンプライアンス制御, 10.3.2 コンプライアンス評価, 10.3.5 コンプライアンス管理, 1.6 コンプライアンス管理ソリューション, 概要, 10.1 コンプライアンス管理, 新機能, 10.2 コンプライアンス管理, 概要, 10.3 コンプライアンス標準ルール, 10.3.4

概要, 10.3.3

リアルタイム監視ルール, 10.3.3

リポジトリ・ルール, 10.3.3

WebLogic Server署名ルール, 10.3.3

コンプライアンス標準, 10

概要, 10.3.2

作成, 10.3.4

構成情報, 収集, 4.1 構成管理, 1.6 構成メトリック, 識別, 2.5.1 構成スナップショット, 集合, 4.3 構成, 概要, 4.3 コネクタ, 2.2 制御, コンプライアンス, 10.3.2 コア管理機能

可用性およびブラックアウト, 1.5, 2.1

共通コンソール機能, 1.5, 2.1

デフォルトのシステム・レポート, 1.5, 2.1

グループおよびシステム, 1.5, 2.1

メトリック収集およびアラート, 1.5

メトリック収集およびアラート, 2.1

コンプライアンス標準の作成, 10.3.4 クリティカルしきい値, 指定, 2.5.1 管理用のカスタム・ユーザー・インタフェース, 2.1 カスタマイズされたUI, 8.1

D

データベース・ジョブ, 1.4

デフォルト収集メタデータ, 2.1

デフォルト収集ファイル, 2.1, 2.6.2

デフォルトの警告, 指定, 2.5.1

定義

ジョブ・タイプ, 2.6.2

定義, スキーマ, 1.4 デプロイメント構成, スタンドアロン, 1.2 内容の設計, 2.5.1 メトリックの収集の決定, 2.5.1 検出されたエンティティ, 3.3.1 潜在的なターゲットの検出, 9.1 検出

コンテンツ, 9.3

検出モジュール, 9.3

メタデータ, 9.3

新機能, 9.2

パラメータ, 9.3

プラグイン, 9.3

スケジュール, 9.3

検出コンテンツ, 9.3 検出フレームワーク, 9.3 検出メタデータ, 9.3, 9.3 検出メタデータXMLファイル, 9.3 検出モジュール, 9.3 検出パラメータ, 9.3 検出スクリプト, 8.3.1, 9.3 検出スクリプト, パッケージ化, 9.1

E

EDK, 2.1, 2.2, 2.3, 8.5

ダウンロード, 2.3

インストール, 2.4

要件, 1.5

EDK, コンポーネント, 2.3 EM CLI, 1.1.4 empdkツール, 2.3 エンタープライズ構成管理

概要, 4.1

構成の比較, 4.1

構成のエクスポート, 4.1

機能, 4.1

フレームワーク, 4.4

新機能, 4.2

構成の保存, 4.1

構成情報の検索, 4.1

変更の追跡, 4.1

Enterprise Manager, フレームワーク, 1.5 エンタープライズ・レポート, 1.6 拡張開発キット, 「EDK」を参照 拡張プラグイン

説明, 概要, 1.5

新機能, 1.6

F

Flexバイナリ, 8.5

Flex Builder, 8.5

Flexコンポーネント, 8.2.1.4

Flexソフトウェア開発キット, 8.5

Flex UI, 8.2

フレームワーク

Adobe Flex UI, 8.3

エンタープライズ構成管理, 4.4

MPCUI, 8.2.1.2

UI, 8.3.2

G

グループ, 3.3.3

アセンブル, 3.3.3

定義, 3.3.3

メンバー, 3.3.3

通常, 3.3.3

権限伝播, 3.3.3

I

MPCUIの実装

Flex UI, 8.2

メタデータのみ, 8.2

インストール, EDK, 2.4 統合オブジェクト, 8.3.1

J

ジョブ定義, 8.3.1

ジョブ・システム, 1.6

ジョブ・タイプ定義, 2.6.2

L

ルック・アンド・フィール, UI, 8.2.1.4

M

管理可能なエンティティ

クラス, 3.3.1

存在のみ状態, 3.3.1

管理対象状態, 3.3.1

複数の状態, 3.3.1

NYM状態, 3.3.1

「ME」を参照

管理可能なエンティティ・クラス

定義, 3.3.1

Enterprise Managerの機能, 3.3.1

表現, 3.3.1

管理対象状態, 3.3.1 管理対象ターゲット

概要, 3.3.2

定義, 3.3.2

例, 3.3.2

管理対象ターゲット, 1.3

その他の拡張機能, 3.2

ライフサイクル・ステータス, 3.3.2.2

ターゲット・アイデンティティ, 3.3.2.1

管理対象ターゲット, 構成情報, 1.4 管理対象ターゲット, 新機能, 3.2 管理エージェント, 1.1.3, 1.2 管理コンソール, 1.2 管理フレームワーク・デプロイメント, 一般的, 1.3 管理メタデータ, 2.5.1 管理リポジトリ, 1.1.2, 8.3.1

NYMエンティティ, 3.3.1

管理リポジトリ, 1.4, 4.3

情報, 1.4

管理リポジトリ・ビュー, 1.1.4 ターゲットの管理, 3 ME, 3.3.1 MEクラス, 3.3 メタデータ

検出, 9.3, 9.3, 9.3

メタデータ・ファイル

ターゲット・タイプ, 2.6.2

メタデータ・ファイル

パッケージ化, 2.6.2

ターゲット・タイプ, 2.1

メタデータのみUI, 8.2 メタデータ・プラグイン・カスタム・ユーザー・インタフェース

「MPCUI」を参照

メタデータ・プラグイン, 2.2 メトリック定義, 8.3.1 メトリック拡張, 3.2 監視データ, 取得, 8.3.1 監視スクリプト, 8.3.1, 9.3 MPCUI

概要, 8.3

フレームワークの概要, 8.1

構成要素, 8.1

EDK, 8.5

実装, 8.2

UI構築のオプション, 8.1

概要, 8.3.1

再利用可能なコンポーネント, 8.1

サポートされているインタフェース, 8.1

テンプレート, 8.1

MPCUIフレームワーク, 8.2.1.2 MPCUIサービス

ジョブ, 8.4

メトリック・データ, 8.4

リモート操作, 8.4

SQLの結果, 8.4

ターゲット・アソシエーション, 8.4

ターゲット・プロパティ, 8.4

N

新機能

コンプライアンスの管理, 10.2

検出, 9.2

エンタープライズ構成管理, 4.2

拡張プラグイン, 1.6

管理対象ターゲット, 3.2

プラグイン, 2.2

管理未定, 「NYM」を参照 NYM, 3.3.1 NYMエンティティ, 3.3.1

O

OMS

「Oracle Management Service」を参照

Oracle Management Agent

「管理エージェント」を参照

Oracle Management Repository

「管理リポジトリ」を参照

Oracle Management Service, 1.1.1, 1.2, 1.5

P

パッケージ化, メタデータ・ファイル, 2.6.2

パッケージ化ツール, 2.3

パラメータ, 検出, 9.3

パフォーマンス・メトリック, 識別, 2.5.1

プラグイン

管理機能, 2.5.1

内容, 2.6

作成, 2.1

ファイルの作成, 2.5.1

デプロイ, 2.5

デプロイ, 2.2

設計, 2.5, 2.5.1

内容の設計, 2.5.1

開発サイクル, 2.5

ダウンロード, 2.5

概要, 2.1

メタデータ, 2.6.1

メタデータ・ファイル, 1.5

新機能, 2.2

パッケージ化, 2.3, 2.5

公開, 2.5

ターゲット・タイプ, 2.1

アンデプロイ, 2.5

アップグレード, 2.5

検証, 2.3

プラグイン・アーカイブ, 2.1 プラグイン・アーカイブ・ファイル, 2.1 プラグイン・メタデータ, 2.1 プラグイン

スタート・ガイド, 2

ターゲットの昇格, 9.1

R

冗長性グループ, 3.3

プラグインの削除, 2.5

名前変更, ターゲット, 3.3.2.1

根本原因分析, 3.3.4.1

S

保存済スナップショット, 4.3.3

保存済スナップショット, 4.1

構成の保存, 4.3.3

スキーマ定義, 1.4

構成の検索, 4.3.1

自己更新, 2.2

サービス

定義, 3.3.7

例, 3.3.7

スナップショット・タイプ, 4.3 スタンドアロン・デプロイメント構成, 1.2 ストアド・プロシージャ, 1.4 サポートされるチャート・タイプ, 8.2.1.3 SWFアプリケーション, 8.3 システム

定義, 3.3.4

メンバー, 3.3.4

関係, 3.3.4

システムの状態, 3.3.4.1 システム

操作, 3.3.4.1

状態, 3.3.4.1

T

ターゲット

Enterprise Managerへの追加, 9.1

名前変更, 3.3.2.1

ターゲット・アソシエーション, 1.6 ターゲット構成, 4.3 ターゲット資格証明, 1.6 ターゲット定義ファイル, 2.1 ターゲット・アイデンティティ, 3.3.2.1 ターゲット・インスタンス, 3.1 ターゲット・モデル, 3.3

グループ, 3.3.3

サービス, 3.3.7

サポートされる管理機能, 3.3.8

システム, 3.3.4

ターゲット・タイプ, 4.3 ターゲット・タイプ・メタデータ・ファイル, 2.1, 2.6.2 ターゲット・タイプのパラメータ, 定義, 2.5.1 ターゲット

管理対象の概要, 3.1

定義, 3.1

検出, 9.1

例, 3.1

管理, 3

事前構成, 3.1

昇格, 9.1

ターゲットタイプ・メタデータ, 2.1 テンプレート, MPCUI, 8.1 トポロジ・ビューア, 4.4 タイプ, 3.3.3

U

UIフレームワーク, 8.3.2

UIルック・アンド・フィール, 8.2.1.4

UI, カスタマイズ, 8.1

ユーザー・インタフェースのコンポーネント

チャートおよび表, 8.2.1.3

レイアウト, 8.2.1.1

ルック・アンド・フィール, 8.2.1.4

ナビゲーション, 8.2.1.1

パッケージ化されたリージョン, 8.2.1.2

ページ, 8.2.1.1

V

拡張インスツルメンテーション, 3.1

検証ツール, 2.3

構成の表示, 4.3.1

ビュー, 管理リポジトリ, 1.1.4

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

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の登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。