| Oracle® Enterprise Manager Connectors統合ガイド 13c リリース2 E94901-01 |
|
 前へ |
 次 |
この章の内容は、次のとおりです。
Enterprise Manager Cloud Control 12cには、管理コネクタ・フレームワーク(コネクタ・フレームワークとも呼ばれる)が用意されており、開発者は、外部アプリケーションでイベントを作成/更新するために使用できるイベント・コネクタを構築できます。
コネクタが外部アプリケーションとデータを交換するには、Webサービスが使用可能で、コネクタがイベント情報の作成および更新のために起動できる必要があります。コネクタは、UIでのコネクタの表示方法および外部アプリケーションに接続してデータを交換する方法を定義する一連のXMLとXSLTメタデータ・ファイルで構成されています。
ユーザー独自のシステムでイベント・コネクタを作成するには、一連のメタデータ・ファイルを提供する必要があります。表2-1に、イベント・コネクタを構成するメタデータ・ファイルのカテゴリを示します。
表2-1 メタデータ・ファイルのカテゴリ
| カテゴリ | タイプ | 説明 |
|---|---|---|
コネクタ記述子 |
XML |
コネクタ記述子ファイルは、Enterprise Managerにコネクタを定義します。このファイルには、UIでのコネクタの表示方法、Webサービスの配置場所とそれに接続する方法、およびシステム間で送信されるデータの変換に使用するテンプレートに関する情報が含まれています。 |
リクエスト・テンプレート |
XMLまたはXSL |
これらのテンプレートは、イベントを作成または更新するためにWebサービスに送信されるXMLリクエストを生成するのに使用されます。これらのテンプレートは、Enterprise Managerのイベント・データ・フィールドを、Webサービスで想定されている形式に変換します。 |
レスポンス・テンプレート |
XSL |
レスポンス・テンプレートは、Webサービス・コールで返されたXMLレスポンスを、コネクタ・フレームワークで想定されている形式に変換します。 |
イベント・コネクタの作成方法を理解するには、それがどのように機能するかを理解する必要があります。connectorDeploy.xmlファイル(通常は、コネクタ記述子ファイルと表記)は、Enterprise Managerにコネクタを定義します。コネクタがインストールされると、Enterprise Managerではコネクタ記述子ファイルの内容が検証され、コネクタに必要なフィールドおよびWebサービスとのXMLメッセージの交換時に使用するテンプレートが決定されます。
オペレータがコネクタを構成すると、コネクタ記述子ファイルの情報に基づいて構成ページが生成されます。通常、このページには、Webサービスへの接続時に使用するURLと資格証明が記載されたフィールドが含まれています。オペレータは必須フィールドを指定した後、「OK」ボタンをクリックして構成プロセスを完了します。ボタンをクリックすると構成値が保存され、コネクタで定義された設定または初期化サービス操作が実行されます。
注意:
指定可能な4つのオプション・サービス操作があります。設定および初期化操作は、コネクタの最初のインスタンスが構成されるときに実行されます。これらは、コネクタを有効にするために必要な設定を実行するのに使用されます。他の2つの操作は初期化解除およびクリーン・アップです。これらの操作は、設定または初期化操作で実行された内容を元に戻すために使用されます。これらの操作は両方とも、コネクタの最後のインスタンスが削除されるときに実行されます。
構成が正常に完了した場合、コネクタは完了としてマークされ、使用する準備ができます。エラーが発生した場合、構成の変更は保存されますが、コネクタは完了としてマークされません。失敗した場合は、その理由を調査し、問題に対処する必要があります。問題に対処した後は、構成ページに戻って「OK」をクリックし、設定/初期化を再度実行できます。
コネクタが完了とマークされた後は、インシデント・ルールを設定して、特定イベントの発生時に、外部アプリケーションでイベントを作成できます。たとえば、データベースの表領域が指定されたしきい値を超えた場合にイベントを作成するルールを設定できます。ルールを設定するときは、ルールを適用するターゲット、ルールのトリガーに使用する基準、および起動するイベント・コネクタを指定します。
基準が満たされてルールが起動すると、コネクタ・フレームワークではイベント・コネクタを起動して、リモート・アプリケーションでイベントを作成するために必要なXMLを生成します。コネクタ・フレームワークでは、コネクタで定義されたcreateEventリクエスト・テンプレートを使用してEnterprise Managerイベント・データに対してXSLT変換を実行することで、リクエストXMLを作成します。コネクタ・フレームワークでは、生成された作成リクエストを、createEventサービス用に構成されたWebサービスURLに送信します。Webサービスでは、外部アプリケーションでイベントを作成し、新しいイベントの識別子を使用してレスポンスを送信します。コネクタ・フレームワークでは、createEventレスポンス・テンプレートを使用して、新しいイベント識別子をコネクタ・フレームワークで想定されている形式に変換します。レスポンスを取得したコネクタ・フレームワークは、外部イベント識別子をイベントとともに保持します。
Enterprise Managerでイベントの更新の原因となる状況が発生した場合、コネクタ・フレームワークでは、updateEventリクエスト・テンプレートを使用して、Enterprise Managerのイベント・データ形式を、Webサービスに送信するXML更新リクエストに変換します。Webサービスは、外部アプリケーションでイベントを更新し、レスポンスを送信します。レスポンスを取得したコネクタ・フレームワークは、updateEventレスポンス・テンプレートを使用して、そのレスポンスを、コネクタ・フレームワークで想定されている形式に変換します。コネクタ・フレームワークでは、このレスポンスを使用して、更新が正常に完了したことを確認します。
イベントが最終的に解決され、クリア済ステータスになると、コネクタ・フレームワークはCLEARに設定されたSeverityCodeフィールドを使用して、通常のupdateEvent操作を実行します。
注意:
現行リリースでは、アウトバウンド操作(外部アプリケーションへのイベントの送信)のみがサポートされます。インバウンド(Enterprise Managerへの外部イベントのインポート)のサポートは、将来のリリースで検討される可能性があります。
コネクタの作成中は、複数のXMLファイルおよびXSLTファイルの生成が必要となるため、XML、XSD、XSLTテクノロジの十分な理解が必要です。コネクタを作成する前にこれらのテクノロジをよく理解しておくことをお薦めします。
チケッティング・コネクタおよびイベント・コネクタを作成するには、異なるファイルの形式を定義するスキーマ・ファイルへのアクセスが必要になります。スキーマ・ファイルは、拡張開発キット(EDK)に配置されています。EDKをインストールするには、「設定」メニューに移動し、「拡張性」、「開発キット」の順に選択します。このページは、EDKをダウンロードしてインストールするための手順を示します。「要件」セクションをレビューし、EDKをインストールする前に前提条件が満たされていることを確認してください。前提条件を確認した後は、「デプロイメント」セクションに従ってEDKをインストールします。
スキーマ・ファイルは、emSDKディレクトリのemMrsXsds.jarファイルにあります。ファイルにアクセスするには、jarコマンドまたはjarファイル形式を認識している他のユーティリティを使用して、そのファイルを抽出する必要があります。jarコマンドを使用してEDKインストール・ディレクトリからファイルを抽出するには、次のコマンドを使用します。
$JAVA_HOME/bin/jar xvf emSDK/emMrsXsds.jar
表2-2に、抽出したスキーマ・ファイルの場所を示します。この表は、スキーマ・ファイルが説明されている様々な項で参照されます。
表2-2 スキーマ・ファイルの場所
| ファイル名 | 場所 |
|---|---|
connectorDeploy.xsd |
oracle/sysman/emSDK/core/connector/common |
EMEvent.xsd |
oracle/sysman/emSDK/core/connector/eventConnector |
EMEventResponse.xsd |
oracle/sysman/emSDK/core/connector/eventConnector |
SelfUpdateManifest.xsd |
oracle/sysman/emSDK/core/selfupdate/model |
setupResponse.xsd |
oracle/sysman/emSDK/core/connector/eventConnector |
initialze_response.xsd |
このファイルは、EDKでは使用できません。「イベント・コネクタのサンプル」の例C-16を参照してください。 |
uninitialize_response.xsd |
このファイルは、EDKでは使用できません。「イベント・コネクタのサンプル」の例C-17を参照してください。 |
これで、コネクタがどのように機能するかを理解し、イベント・コネクタの作成プロセスを開始する準備が整いました。コネクタを作成するには、次の各項で指定されている手順に従う必要があります。
コネクタを作成するには、要件を分析して、コネクタに含める機能を決定する必要があります。この項は、自分のイベント・コネクタに必要なテンプレートの決定に役立ちます。この項を終了すると、コネクタに対して実装する必要があるテンプレートのリストが手に入ります。
すべてのイベント・コネクタに含める必要がある、必須のテンプレートがいくつかあります。これらのテンプレートは、含める以外の選択肢がありません。必要に応じてコネクタに含めることができる、オプションのテンプレートが他にあります。表2-3に、イベント・コネクタに対して定義可能なテンプレートを示します。この表の「説明」列では、テンプレートが提供する機能を説明します。オプションのテンプレートが提供する機能を分析し、コネクタに含める必要があるものを決定する必要があります。この分析が完了した後は、提供する必要があるテンプレートのリストが手に入ります。リストは、必須のテンプレートと、含めるように選択したオプションのテンプレートで構成されます。
注意:
オプションのテンプレートは、ほとんどのコネクタで使用されません。オプションのテンプレートを使用するのは、外部アプリケーションでなんらかの設定を行うためにWebサービス・コールを実行する必要がある場合のみです。初期化中に行われる設定の例として、外部アプリケーションでのコネクタの登録があります。
表2-3 定義可能なイベント・テンプレート
| テンプレート | 必須/オプション | 説明 |
|---|---|---|
setupリクエスト |
オプション |
コネクタの設定を実行するためにWebサービスに送信されるリクエストを生成するのに使用します。 |
setupレスポンス |
オプション |
Webサービスからの設定レスポンスを、Enterprise Managerで想定されている形式に変換するために使用します。 |
initializeリクエスト |
オプション |
コネクタの初期化を実行するためにWebサービスに送信されるリクエストを生成するのに使用します。 |
initializeレスポンス |
オプション |
Webサービスからの初期化レスポンスを、Enterprise Managerで想定されている形式に変換するために使用します。 |
createEventリクエスト |
必須 |
イベントを作成するためにWebサービスに送信されるリクエストを生成するのに使用します。 |
createEventレスポンス |
必須 |
Webサービスからの作成レスポンスを、Enterprise Managerで想定されている形式に変換するために使用します。 |
updateEventリクエスト |
必須 |
イベントを更新するためにWebサービスに送信されるリクエストを生成するのに使用します。 |
updateEventレスポンス |
必須 |
Webサービスからの更新レスポンスを、Enterprise Managerで想定されている形式に変換するために使用します。 |
uninitializeリクエスト |
オプション |
コネクタの初期化の取消しを実行するためにWebサービスに送信されるリクエストを生成するのに使用します。 initializeテンプレートが定義されている場合に必要です。 |
uninitializeレスポンス |
オプション |
Webサービスからの初期化解除レスポンスを、Enterprise Managerで想定されている形式に変換するために使用します。 initializeテンプレートが定義されている場合に必要です。 |
cleanupリクエスト |
オプション |
コネクタの設定の取消しを実行するためにWebサービスに送信されるリクエストを生成するのに使用します。 setupテンプレートが定義されている場合に必要です。 |
また、各テンプレートに対して使用するファイル名を決定する必要があります。テンプレート・ファイル名に関する要件はありませんが、次の命名規則を使用することをお薦めします。
<methodName>_request.xml <methodName>_request.xsl <methodName>_response.xsl
表2-4に、推奨ネーミング規則に基づいて、異なるテンプレートに対して推奨されるファイル名を示します。
表2-4 推奨テンプレート・ファイル名
| テンプレート | 推奨ファイル名 |
|---|---|
setupリクエスト |
|
setupレスポンス |
|
initializeリクエスト |
|
initializeレスポンス |
|
createEventリクエスト |
|
createEventレスポンス |
|
updateEventリクエスト |
|
updateEventレスポンス |
|
uninitializeリクエスト |
|
uninitializeレスポンス |
|
cleanupリクエスト |
|
これで、提供する必要があるテンプレートを識別しました。次のステップは、テンプレート・ファイルを作成することです。テンプレート・ファイルの生成とテストには、XML/XSLTツールの使用をお薦めします。ファイルは標準のテキスト・エディタを使用して作成できますが、プロセスが非常に困難となり時間がかかります。Enterprise Managerでコネクタをパッケージ化してインストールする前に、ツールでは形式エラーが捕捉され、テンプレートをテストできます。これによって、インストールされているコネクタに対して実行する必要がある修正の数が大幅に削減されます。コネクタに対して実行する必要がある各修正では、古いコネクタをアンインストールし、新しいバージョンのコネクタを再パッケージ化して、再インストールする必要があります。
次の各項では、様々なテンプレート・ファイルを作成するために必要なステップについて説明します。使用するコネクタの対象とならないテンプレートを説明している項は無視できます。
変換するイベントXMLデータがないため、これらのテンプレートはXSLTファイルではなくXMLファイルとして定義する必要があります。これらのテンプレートは、XMLファイルとして定義されるため、必要な操作を実行するのに使用するサンプルXMLを取得し、それをXMLファイルとして使用するのみで済みます。
レスポンス・テンプレートは、WebサービスからのレスポンスをEnterprise Managerで想定されている形式に変換するために使用するXSLTファイルです。WebサービスからのレスポンスXMLの形式は、WSDL、またはWebサービスが提供するスキーマによって定義されている必要があります。Enterprise Managerで想定されている形式は、initialize_response.xsd、setup_response.xsdおよびuninitialize_response.xsdスキーマ・ファイルに指定されています。これらのスキーマ・ファイルの場所は、「スキーマ・ファイルの抽出」の項の表2-2を参照してください。
例2-1は、Webサービスからのサンプル・レスポンス・ファイルを示しています。例2-2は、データをEnterprise Managerで想定されている形式に変換するために設計されたサンプルXSLTテンプレートを示しています。XSLTテンプレートでは、次のネームスペースを持つregisterResponseという名前のルート要素が検索されます。
http://oracle.com/services/adapter-framework
次のネームスペースを持つSetupResponseルート要素が作成されます。
http://xmlns.oracle.com/sysman/connector
ConnectorVariable子要素が作成され、REGISTRATION_IDに設定されたVariableName要素が含まれます。また、VariableValue要素が作成され、registrationId要素に指定された識別子に設定されます。例2-3は、XSLTツールを使用して変換を実行することによって生成されたXMLを示しています。
例2-1 Webサービスからの入力レスポンスXML
<adap:registerResponse xmlns:adap="http://oracle.com/services/adapter-framework"> <adap:registrationId>2834782347</adap:registrationId> </adap:registerResponse>
例2-2 サンプルXSLTテンプレート・ファイル
<?xml version='1.0' ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:adap="http://oracle.com/services/adapter-framework">
<xsl:template match="/adap:registerResponse">
<SetupResponse xmlns="http://xmlns.oracle.com/sysman/connector">
<ConnectorVariable>
<VariableName>REGISTRATION_ID</VariableName>
<VariableValue><xsl:value-of select="adap:registrationId"/></VariableValue>
</ConnectorVariable>
</SetupResponse>
</xsl:template>
</xsl:stylesheet>
例2-3 変換の結果生成されたファイル
<?xml version="1.0" encoding="UTF-8"?>
<SetupResponse xmlns="http://xmlns.oracle.com/sysman/connector" xmlns:adap="http://oracle.com/services/adapter-framework">
<ConnectorVariable>
<VariableName>REGISTRATION_ID</VariableName>
<VariableValue>2834782347</VariableValue>
</ConnectorVariable>
</SetupResponse>
これらのテンプレートは、他のテンプレートよりも大きく複雑なため、作成が最も困難です。テンプレートの入力XMLには、作成/更新されたEnterprise Managerイベントに関するデータが含まれています。変換の結果生成されるXMLは、外部アプリケーションでイベントを作成または更新するためにWebサービスに送信されるXMLです。
テンプレートを作成するには、外部アプリケーションで作成/更新されるデータの形式およびEnterprise Managerから取得されるデータの形式を理解しておく必要があります。形式の理解には、使用可能なフィールドやそれらのフィールドに入力可能な値の識別が含まれます。
外部アプリケーションでイベントを作成/更新するためには、指定されたデータの形式を理解しておく必要があります。手始めは、WSDLまたはデータの形式を定義するスキーマ・ファイルです。また、データの形式を設定する方法を確認するためにサンプルの作成/更新リクエストを参照する必要があります。サンプルを使用できない場合は、XMLクライアント・ツールを使用して既存のイベントのデータを手動で取得できるようにする必要があります。これによって、データがどのように表示されるかを把握できます。
外部アプリケーションのデータを理解した後は、Enterprise Managerから取得したデータを調査し、理解する必要があります。Enterprise Managerのイベント・データで使用できるフィールドは、EMEvent.xsdスキーマ・ファイル内で識別されます。EMEvent.xsdスキーマ・ファイルの場所は、「スキーマ・ファイルの抽出」の項の表2-2を参照してください。
スキーマ・ファイルはフィールドを識別し、それらのフィールドのデータのタイプを示しますが、実際に存在するデータの内容は把握していません。データがどのように表示されるかを理解するには、Enterprise Managerによって生成されたサンプルXMLファイルが必要です。「サンプル・イベント・データ」では、Enterprise Managerによって生成されたサンプル・イベント・トランザクションを示しています。
データをよく理解した後は、各テンプレート(createEventおよびupdateEvent)で実行するマッピングを決定する必要があります。これには、リクエストに指定するフィールドと、それらのフィールドのデータ形式の決定が含まれます。データのソースに関する選択肢は2つのみです。データはハードコードするか、またはEnterprise Managerのイベント・データから取得できます。マッピングは状況にあわせて複雑または単純にできます。最終的には、自分の環境に適したフィールドと設定を決定する必要があります。
マッピングを識別した後は、XSLTファイルの作成準備が整います。最初のテンプレートに着手するには、例2-4に示すXMLを、XSLTファイルを作成しているエディタにコピーします。これには、テンプレートの作成に必要な基本的なスケルトンが含まれています。指定の場所にマッピングのロジックを追加する必要があります。推奨されるアプローチは、createEventテンプレートを最初に作成し、それを十分にテストすることです。これが機能することを確認した後は、そのテンプレートのコピーを作成してupdateEventテンプレートのベースラインとして使用できます。
「イベントの作成用テンプレートの例」では、createEventテンプレートの作成方法を示す例を順を追って説明します。
例2-4 テンプレート・スケルトン
<?xml version='1.0' encoding='UTF-8'?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:emcf="http://xmlns.oracle.com/sysman/connector">
<xsl:template match="emcf:EMEvent">
<!-- Add your mapping here -->
</xsl:template>
</xsl:stylesheet>
これらのテンプレートは、WebサービスからのレスポンスをEnterprise Managerで想定されている形式に変換するために使用するXSLTファイルです。WebサービスからのレスポンスXMLの形式は、WSDL、またはWebサービスが使用するスキーマによって定義されている必要があります。Enterprise Managerで想定されている形式は、EMEventResponse.xsdスキーマ・ファイルに指定されています。EMEventResponse.xsdスキーマ・ファイルの場所は、「スキーマ・ファイルの抽出」の項の表2-2を参照してください。
例2-5は、Webサービスからのサンプル・レスポンス・ファイルを示しています。例2-6は、データをEnterprise Managerで想定されている形式に変換するために設計されたサンプルXSLTテンプレートを示しています。XSLTテンプレートでは、http://oracle.com/services/adapter-frameworkというネームスペースおよびreturnという子要素を持つcreateResponseという名前のルート要素が検索されます。http://xmlns.oracle.com/sysman/connectorというネームスペースを持つEMEventResponseルート要素が作成され、入力ドキュメントのidentifier要素の内容に従って設定される2つの子要素が作成されます。identifier要素が存在し、データが含まれている場合は、SuccessFlag要素がtrue、ExternalEventId要素が識別子に設定されます。識別子が指定されていない、または空の場合は、SuccessFlagがfalseに設定され、ErrorMessage要素が作成されて、"Request to create an event in the external application failed"に設定されます。例2-7は、XSLTツールを使用して変換を実行することによって生成されたXMLを示しています。
例2-5 Webサービスからの入力レスポンスXML
<?xml version="1.0" encoding="UTF-8" ?>
<adap:createResponse xmlns:adap="http://oracle.com/services/adapter-framework">
<return>
<identifier>abcd-1234-5678</identifier>
<status>0</status>
</return>
</adap:createResponse>
例2-6 サンプルXSLTテンプレート・ファイル
<?xml version='1.0' ?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:oracleaf="http://oracle.com/services/adapter-framework"
xmlns:a="http://xmlns.oracle.com/sysman/connector">
<xsl:template match="oracleaf:createResponse/return">
<a:EMEventResponse>
<xsl:choose>
<xsl:when test="identifier">
<a:SuccessFlag>true</a:SuccessFlag>
<a:ExternalEventId>
<xsl:value-of select="identifier"/>
</a:ExternalEventId>
</xsl:when>
<xsl:otherwise>
<a:SuccessFlag>false</a:SuccessFlag>
<a:ErrorMessage>Request to create an event in the external application failed</a:ErrorMessage>
</xsl:otherwise>
</xsl:choose>
</a:EMEventResponse>
</xsl:template>
</xsl:stylesheet>
例2-7 変換の結果生成されたファイル
<?xml version="1.0" encoding="UTF-8"?> <a:EMEventResponse xmlns:a="http://xmlns.oracle.com/sysman/connector" xmlns:oracleaf="http://oracle.com/services/adapter-framework"> <a:SuccessFlag>true</a:SuccessFlag> <a:ExternalEventId>abcd-1234-5678</a:ExternalEventId> </a:EMEventResponse>
XSLTテンプレートを作成する場合は常に、既存のテンプレートをコピーし、状況にあわせてカスタマイズするほうが簡単です。前述のテンプレートをカスタマイズする手順は、次のとおりです。
oracleafネームスペース定義を、Webサービスから生成されたXMLに指定されるネームスペースに置き換えます。
テンプレートのmatch属性を変更して、Webサービスから生成されたXMLのルート要素を参照するようにします。
識別子をチェックし、ExternalEventId要素を作成するときにイベント識別子情報を取得する要素の名前を変更します。
ファイルを作成した後は、XSLTツールを実行して、サンプルXMLからのデータを変換することでテンプレートをテストし、正しいXML形式が生成されることを確認する必要があります。
これでテンプレートが作成され、今度は、Enterprise Managerでコネクタを定義するコネクタ記述子ファイルを作成します。コネクタ記述子XMLファイルには、コネクタ・メタデータおよびコネクタの構成プロパティ(Webサービス・エンドポイントおよび認証スキーマなど)が記述されています。
記述子を作成する際の重要な留意点は次のとおりです。:
コネクタ記述子ファイル名は、connectorDeploy.xmlにする必要があります。
XMLファイルは、connectorDeploy.xsdスキーマに準拠する必要があります。
connectorDeploy.xsdスキーマ・ファイルの場所は、「スキーマ・ファイルの抽出」の項の表2-2を参照してください。
リファレンス実装は、「イベント・コネクタのサンプル」のサンプルconnectorDeploy.xmlを参照してください。
表2-5に、コネクタ記述子を構成するセクションと、各セクションが実行する内容の要約を示します。
表2-5 メタデータ・セクション
| メタデータ・セクション | 必須 | 説明 |
|---|---|---|
コネクタ情報 |
はい |
このセクションでは、UIに表示されるコネクタに関する情報を提供します。 |
認証 |
いいえ |
認証方式およびWebサービスへの接続に必要なパラメータを指定します。 |
サービス |
はい |
このセクションは、様々なサービス操作のWebサービスへの接続に使用するURLを構成するために使用します。 |
テンプレート登録 |
はい |
このセクションは、コネクタに対して使用するすべてのテンプレートを定義するために使用します。 |
次の各項では、コネクタ記述子のコンテンツの詳細について説明します。
コネクタ・デプロイメント・ファイルの各セクションには、コネクタに関する特定の情報を提供するフィールドが含まれています。次の各セクションには、使用可能なフィールドとこれらのフィールドの内容に関する詳細情報が含まれています。
コネクタ情報セクションでは、UIに表示される名前、バージョン、説明など、コネクタに関する情報を提供します。表2-6に、このセクションのフィールドの一覧を示し、各フィールドの説明を示します。
表2-6 コネクタ情報フィールド
| セクション/フィールド | 必須 | 説明 | |
|---|---|---|---|
Name |
はい |
UIに表示されるコネクタ名。 |
|
Version |
はい |
UIに表示されるコネクタ・バージョン。 |
|
EMCompatibleVersion |
はい |
サポートされているEnterprise Managerの最も初期のバージョン。 |
|
Description |
はい |
UIに表示されるコネクタの説明。 |
|
Category |
はい |
可能な値は次のとおりです。 EventConnector
TicketingConnector
この場合、値は |
|
NewTargetType |
はい |
このセクションは使用されませんが、定義しておく必要があります。 |
|
|
はい |
ターゲット・タイプの名前。 |
|
|
はい |
ターゲット・タイプのUIに表示する名前。 |
|
|
はい |
ターゲット・タイプのデフォルト・ターゲットの名前。 |
|
|
はい |
ターゲット・タイプのデフォルト・ターゲットのUIに表示する名前。 |
|
例2-8は、コネクタ情報セクションに含まれている情報を示しています。このセクションのすべてのフィールドは、ManagementConnectorノードに含まれています。
例2-8 コネクタ情報セクションのサンプル
<Name>SCOM 2012 Connector</Name>
<Version>12.1.0.1.0</Version>
<EMCompatibleVersion>12.1.0.1.0</EMCompatibleVersion>
<Description>Microsoft System Center Operations Manager 2012 Integration with Enterprise Manager</Description>
<Category>EventConnector</Category>
<NewTargetType>
<TargetTypeName>scom_managed_host</TargetTypeName>
<TargetTypeDisplayName>SCOM Managed Host</TargetTypeDisplayName>
<DefaultTargetName>generic_scom_managed_host</DefaultTargetName>
<DefaultTargetDisplayName>Generic SCOM Managed Host</DefaultTargetDisplayName>
</NewTargetType>
認証セクションでは、認証方式およびWebサービスへの接続に必要な資格証明を指定します。構成可能な3種類の認証タイプがあります。認証セクションが指定されていない場合、コネクタがWebサービスに接続するときに認証は実行されません。表2-7に、3種類の認証セクションとそれぞれに含まれているフィールドを示します。
表2-7 認証フィールド
| セクション/フィールド | 必須 | 説明 | |
|---|---|---|---|
SOAPHeaderAuthentication |
いいえ |
SOAPヘッダーの認証を使用したWebサービスへの接続に使用する資格証明を指定します。 |
|
*Username |
はい |
SOAPヘッダーに指定するユーザー名 |
|
*Password |
はい |
SOAPヘッダーに指定するパスワード |
|
*AuthVariable |
いいえ |
SOAPヘッダーで渡す最大20の他の変数 |
|
*SOAPHeader |
はい |
SOAPヘッダーのテンプレートとして機能する文字列。これは、指定の場所で上に定義され、HTTPリクエストとバインドされている変数をユーザー入力で置き換えることによって更新されます。 |
|
HTTPBasicAuthentication |
いいえ |
基本認証を使用したWebサービスへの接続に使用する資格証明を指定します。 |
|
*Username |
はい |
Webサービスをコールするときに指定するユーザー名 |
|
*Password |
はい |
Webサービスをコールするときに指定するパスワード |
|
UserNameTokenAuthentication |
いいえ |
ユーザー名トークン・プロファイルの認証を使用したWebサービスへの接続に使用する資格証明を指定します。 |
|
*Username |
はい |
指定するユーザー名 |
|
*Password |
はい |
指定するパスワード |
|
* アスタリスク付きのフィールドは、次のサブフィールドで構成されています。
VariableName: 定義されている変数の名前
DisplayName: UIでこのフィールドに関する情報を表示するときに使用する名前
"required"属性: フィールドが必須かどうかを指定します(未指定の場合は、falseにデフォルト設定されます)
例2-9は、認証セクションに含まれている情報を示しています。この例での認証方式は、基本認証です。コネクタを構成する場合、オペレータは、SCOM Webサービス・ユーザー名およびSCOM Webサービス・パスワードの値を指定する必要があります。オペレータが入力した値は、Webサービスに送信されるすべてのリクエスト用の基本認証ヘッダーで渡されます。
例2-9 認証セクションのサンプル
<HTTPBasicAuthentication>
<Username required="true">
<VariableName>Username</VariableName>
<DisplayName>SCOM Web Service Username</DisplayName>
</Username>
<Password required="true">
<VariableName>Password</VariableName>
<DisplayName>SCOM Web Service Password</DisplayName>
</Password>
</HTTPBasicAuthentication>
このセクションは、様々なサービス操作のWebサービスへの接続に使用するURLを構成するために使用します。このセクションに定義されている各エントリによって、テンプレート登録セクションの対応するテンプレートも定義する必要があります。次の各操作について個別のサービス・セクションのエントリが必要です。
createEvent
updateEvent
次のサービス操作はオプションです。
setup
initialize
uninitialize
cleanup
注意:
コネクタ記述子でのサービス名は、前述で定義した名前と完全に一致する必要があり、大/小文字を区別します。
表2-8に、セクションのフィールドの一覧を示し、各フィールドの説明を示します。
表2-8 サービス・フィールド
| セクション/フィールド | 必須 | 説明 | |
|---|---|---|---|
サービス |
はい |
このセクションで、外部システムWebサービス固有の構成を指定できます。 |
|
Method |
はい |
メソッドには、EM固有のサービス操作名の1つを定義します。 イベント・コネクタの場合は、次のいずれかの値に設定する必要があります。 setup initialize createEvent updateEvent uninitialize cleanup cleanupリクエスト・テンプレートは定義できますが、cleanupレスポンス・テンプレートは定義できません。 |
|
WebServiceEndpoint |
はい |
このフィールドでは、デフォルトのWebサービス・エンドポイント文字列が「管理コネクタ」ページの「Webサービス」セクションに表示されるように指定します。 |
|
SOAPAction |
いいえ |
Webサービスをコールするときに指定するSOAPAction |
|
SOAPBindingType |
いいえ |
可能な値は次のとおりです。 SOAP11HTTP_BINDING SOAP12HTTP_BINDING SOAP11HTTP_MTOM_BINDING SOAP12HTTP_MTOM_BINDING |
|
例2-10は、2つの必須サービス・セクションと3つのオプションのセクションを示しています。WebServiceEndpoint要素内のURLは、予約済XML文字との競合を避けるためにCDATAセクションに配置されます。大カッコ[]で囲まれた値は、オペレータが構成ページで置換する必要があります。
たとえば、createEvent操作のデフォルトのURLは、次のとおりです。
http://<host name>:8080/services/SCOM/EventService
この値はcreateEvent操作の横にある構成ページの「Webサービス・エンドポイント」セクションに表示されます。オペレータは、<host name>をWebサービスがホストされているシステムのホスト名またはIPアドレスで置き換える必要があります。
例2-10 サービス・セクションのサンプル
<Service>
<Method>setup</Method>
<WebServiceEndpoint>
<![CDATA[http://<host name>:8080/services/SCOM/SCOMService]]>
</WebServiceEndpoint>
<SOAPAction>setup</SOAPAction>
<SOAPBindingType>SOAP11HTTP_BINDING</SOAPBindingType>
</Service>
<Service>
<Method>initialize</Method>
<WebServiceEndpoint>
<![CDATA[http://<host name>:8080/services/SCOM/SCOMService]]>
</WebServiceEndpoint>
<SOAPAction>initialize</SOAPAction>
<SOAPBindingType>SOAP11HTTP_BINDING</SOAPBindingType>
</Service>
<Service>
<Method>createEvent</Method>
<WebServiceEndpoint>
<![CDATA[http://<host name>:8080/services/SCOM/EventService]]>
</WebServiceEndpoint>
<SOAPAction>createEvent</SOAPAction>
<SOAPBindingType>SOAP11HTTP_BINDING</SOAPBindingType>
</Service>
<Service>
<Method>updateEvent</Method>
<WebServiceEndpoint>
<![CDATA[http://<host name>:8080/services/SCOM/EventService]]>
</WebServiceEndpoint>
<SOAPAction>updateEvent</SOAPAction>
<SOAPBindingType>SOAP11HTTP_BINDING</SOAPBindingType>
</Service>
<Service>
<Method>uninitialize</Method>
<WebServiceEndpoint>
<![CDATA[http://<host name>:8080/services/SCOM/SCOMService]]>
</WebServiceEndpoint>
<SOAPAction>uninitialize</SOAPAction>
<SOAPBindingType>SOAP11HTTP_BINDING</SOAPBindingType>
</Service>
このセクションは、前の章で作成されたすべてのテンプレートを定義するために使用します。表2-9に、セクションのフィールドの一覧を示し、各フィールドの説明を示します。
表2-9 テンプレート登録フィールド
| セクション/フィールド | 必須 | 説明 | |
|---|---|---|---|
TemplateRegistration |
はい |
このセクションでは、最大50のコネクタ・テンプレートを定義します。 「必要なテンプレート・ファイルの開発」で作成した各テンプレートは、ここで定義する必要があります。 |
|
FileName |
はい |
テンプレートを定義するファイルの名前。 |
|
InternalName |
はい |
内部テンプレート名。次のサービス・メソッド名のいずれかに設定する必要があります。大/小文字が区別されるため、正確に一致する必要があります。 setup initialize createEvent updateEvent uninitialize cleanup |
|
TemplateName |
はい |
このテンプレートを参照するときにUIで使用する名前。 |
|
TemplateType |
はい |
テンプレートには、次の2つのタイプがあります。1つはアウトバウンド、もう1つはインバウンドです。アウトバウンドは外部Webサービスに送信されるXMLを生成するために使用され、インバウンドは受信したXMLをEnterprise Managerで想定されている形式に変換するために使用されます。 テンプレート・タイプに指定可能な値は次のとおりです。 InboundXSL OutboundXSL OutboundXML |
|
Description |
はい |
UIに表示されるテンプレートの説明。 |
|
例2-11は、様々なTemplateRegistrationセクションを示しています。
例2-11 テンプレート登録セクションのサンプル
<TemplateRegistration>
<FileName>setup_request.xml</FileName>
<InternalName>setup</InternalName>
<TemplateName>Setup Request</TemplateName>
<TemplateType>OutboundXML</TemplateType>
<Description>This is the request xml file for the setup method</Description>
</TemplateRegistration>
<TemplateRegistration>
<FileName>setup_response.xsl</FileName>
<InternalName>setup</InternalName>
<TemplateName>Setup Response</TemplateName>
<TemplateType>InboundXSL</TemplateType>
<Description>This is the response xsl file for the setup method</Description>
</TemplateRegistration>
<TemplateRegistration>
<FileName>setup_request.xml</FileName>
<InternalName>initialize</InternalName>
<TemplateName>Initialize Request</TemplateName>
<TemplateType>OutboundXML</TemplateType>
<Description>This is the request xml file for the initialize method</Description>
</TemplateRegistration>
<TemplateRegistration>
<FileName>createEvent_request_2012.xsl</FileName>
<InternalName>createEvent</InternalName>
<TemplateName>Create Event Request</TemplateName>
<TemplateType>OutboundXSL</TemplateType>
<Description>This is the request xsl file for the createEvent method</Description>
</TemplateRegistration>
<TemplateRegistration>
<FileName>createEvent_response.xsl</FileName>
<InternalName>createEvent</InternalName>
<TemplateName>Create Event Response</TemplateName>
<TemplateType>InboundXSL</TemplateType>
<Description>This is the response xsl file for the createEvent method</Description>
</TemplateRegistration>
<TemplateRegistration>
<FileName>updateEvent_request_2012.xsl</FileName>
<InternalName>updateEvent</InternalName>
<TemplateName>Update Event Request</TemplateName>
<TemplateType>OutboundXSL</TemplateType>
<Description>This is the request xsl file for the updateEvent method</Description>
</TemplateRegistration>
<TemplateRegistration>
<FileName>updateEvent_response.xsl</FileName>
<InternalName>updateEvent</InternalName>
<TemplateName>Update Event Response</TemplateName>
<TemplateType>InboundXSL</TemplateType>
<Description>This is the response xsl file for the updateEvent method</Description>
</TemplateRegistration>
<TemplateRegistration>
<FileName>cleanup_request.xml</FileName>
<InternalName>uninitialize</InternalName>
<TemplateName>Uninitialize Request</TemplateName>
<TemplateType>OutboundXML</TemplateType>
<Description>This is the request xml file for the uninitialize method</Description>
</TemplateRegistration>
「イベント・コネクタのサンプル」の例C-1は、前述のセクションで示したサンプルを含めた完全なコネクタ・デプロイメント・ファイルを示しています。図2-1は、サンプル・デプロイメント・ファイルに対して表示されるコネクタ構成ページの例を示しています。このイメージには、デプロイメント・ファイル内でフィールドが定義された場所を示すラベルが付けられています。
図2-1 完全なコネクタ・デプロイメント・ページ
コネクタをデプロイするために、Enterprise Managerでは自己更新機能が使用されます。この機能はコンソールからアクセスできますが、Enterprise Manager環境にコネクタをインポートするための機能です。コネクタをデプロイするには、次の手順を実行します。
コネクタjarファイルを準備します。
XMLおよびXSLTテンプレート・ファイルをすべて1つの.jarファイルとしてパッケージします。
<name>_connector.jar ---> connectorDeploy.xml --->template1.xml --->template2.xsl ….. ….. --->templateN.xsl
マニフェスト・ファイルを作成します。
表2-10に、自己更新マニフェスト・ファイルのキー属性を示します。
表2-10 自己更新マニフェスト・ファイルの属性
| Name | 説明 |
|---|---|
EntityType |
値はcore_connectorです。 |
EntityTypeVersion |
現行リリース・バージョンです。値は12.1.0.1.0です。 |
Version |
コネクタのバージョン番号です。 |
Attribute @Name=connector_type |
コネクタ・タイプ名です。 |
Attribute @Name=connector_category |
カテゴリ・タイプは、TicketingConnectorまたはEventConnectorです。 |
ArchiveList |
この要素には、コネクタ設定の一部であるアーカイブのリストが含まれます。一般に、コネクタjarは1つ存在しますが、特殊な実装の場合は追加のjar (アダプタまたはエージェント)が存在することがあります。このような場合、コネクタ固有のjarは定義リストの最初のjarである必要があります。これは必須要件です。 |
SelfUpdateManifest.xsdスキーマ・ファイルは、マニフェスト・ファイルの形式を定義します。
SelfUpdateManifest.xsdスキーマ・ファイルの場所は、「スキーマ・ファイルの抽出」の項の表2-2を参照してください。
次の例に、connector_manifest.xmlファイルのコードを示します。
emedkツールを構成します。
emedkツールは、次の指示に従ってEnterprise Managerユーザー・インタフェースから構成できます。「設定」メニューから「拡張性」、「開発キット」の順に選択します。
自己更新アーカイブを準備します。
これにはコネクタjarファイルおよびコネクタ用のマニフェスト・ファイルが必要です。自己更新を準備するには、次のユーティリティをコールして自己更新アーカイブ・ファイルを作成します。
edkutil prepare_update
-manifest "manifest xml"
-archivedir "archives directory"
-out "output file or directory"
[-typexml "update type xml"]
表2-11に、ユーティリティで使用可能なオプションを示します。
表2-11 自己更新ユーティリティのオプション
| オプション | 説明 |
|---|---|
-manifest |
更新が記述されている自己更新マニフェスト・ファイル。 |
-archivedir |
マニフェスト・ファイルに指定されているアーカイブ・ファイルがあるディレクトリ。 |
-out |
自己更新アーカイブのディレクトリまたはファイル名。ディレクトリが指定されている場合、ファイル名は自動生成されます。 |
-typexml |
更新タイプxmlへのオプション・パス。 |
次の例では、マニフェスト・ファイル/u01/connector/connector_manifest.xmlに基づいて自己更新アーカイブを/u01/sarディレクトリに作成しています。connector_manifest.xmlで参照されるアーカイブは、ディレクトリ/u01/connector/archivesから取得されます。
edkutil prepare_update
-manifest /u01/connector/connector_manifest.xml
-archivedir /u01/connector/archives
-out /u01/sar/sample_connector.zip
次のemcliコマンドのいずれかをコールして、Enterprise Managerにコネクタ・アーカイブをインポートします。
emcli import_update -file=\ file\ -omslocal
または
emcli import_update -file=\ file\ -host=\ host name\ [-credential_set_name=\ setname\ ] | -credential_name=\ name\ -credential_owner=\ owner\
これらのコマンドにより、自己更新アーカイブ・ファイルがEnterprise Managerにインポートされます。正常にインポートされると、更新が次のアクションを促す「ダウンロード」ステータスで自己更新ホームに表示されます。表2-12に、コネクタ・アーカイブ・コマンドのオプションを示します。
表2-12 コネクタ・アーカイブ・コマンドのオプション
| オプション | 説明 |
|---|---|
-file |
更新アーカイブ・ファイルの完全パス名 |
-omslocal |
ファイルがOMSからアクセス可能であることを示すフラグ |
-host |
ファイルが使用可能なホスト・ターゲットのターゲット名 |
-credential_set_name |
ホスト・ターゲットのリポジトリに格納されている優先資格証明のセット名。次のいずれかです。
|
-credential_name |
リポジトリに格納されている名前付き資格証明の名前。このオプションは、-credential_ownerオプションとともに指定する必要があります。 |
-credential_owner |
リポジトリに格納されている名前付き資格証明の所有者。このオプションは、-credential_nameオプションとともに指定する必要があります。 |
emcliコマンドの使用例をいくつか次に示します。
例1
ファイルupdate1.zipをインポートします。このファイルはOMSホストに存在する必要があります。複数のOMSが設定されている場合、リクエストは、どのOMSでも処理できます。そのため、ファイルは、リクエストを処理するOMSからアクセス可能である必要があります。通常、これは、すべてのOMSからアクセス可能な共有の場所にファイルを保存しておく必要があることを意味します。
emcli import_update -file=\ /u01/common/update1.zip\ -omslocal
例2
host1.example.comホストに存在するファイルupdate1.zipをインポートします。ホストは、Enterprise Managerの管理対象ホスト・ターゲットであり、このホストのエージェントは起動し実行中である必要があります。リモート・ファイルの取得には、ホストhost1.example.comの非特権優先資格証明が使用されます。
emcli import_update -file=\ /u01/common/update1.zip\ -host=\ host1.example.com\ -credential_set_name=\ HostCredsNormal\
例3
host1.example.comホストに存在するファイルupdate1.zipをインポートします。ホストは、Enterprise Managerの管理対象ホスト・ターゲットであり、このホストのエージェントは起動し実行中である必要があります。リモート・ファイルの取得には、ユーザー\ admin1\が所有する名前付き資格証明\ host1_creds\が使用されます。
emcli import_update -file=\ /u01/common/update1.zip\ -host=\ host1.example.com\ -credential_name=\ host1_creds\ -credential_owner=\ admin1\
次のいずれかの方法を使用してコネクタを適用します。
Cloud Controlコンソールから、次の操作を実行します。
「自己更新」ホームページに移動します。コネクタは「ダウンロード」と表示されます。
コネクタの行を選択し、「適用」をクリックしてコネクタをデプロイします。
インポートされたばかりのコネクタの識別子を確認するには、コマンドラインから次のemcli listコマンドを実行します。
emcli list -resource=Updates -bind="et_name = 'core_connector'"
このコマンドの出力は、次の例のようになります。
Status Category Type Version Id
------- ---------- ------------------ ---------- --------------
Applied Ticketing Remedy Service 12.1.0.1.0 123456789ABCDE
Connector Desk Connector
Applied Event HP OMU Connector 12.1.0.3.0 11223344AABBCC
Connector
Applied Ticketing Remedy Service 12.1.0.3.0 1A2B3C4D5E6F7G
Connector Desk 7.6 Connector
Applied Ticketing CASD Connector 12.1.0.3.0 55443322CCBBAA
Connector
インポートされたばかりのコネクタのIDに注意してください。インポートされたばかりのコネクタのIDを選択して、次にリストされているemcli apply_updatesコマンドに指定する必要があります。
emcli apply_updates -id=<ID>
例2-12 マニフェスト・ファイルのサンプル
<EntityInstanceList xmlns="http://www.oracle.com/EnterpriseGridControl/SelfUpdateManifest">
<EntityInstance xmlns="http://www.oracle.com/EnterpriseGridControl/SelfUpdateManifest"
EntityTypeVersion="12.1.0.1.0" EntityType="core_connector" Maturity="PRODUCTION"
Vendor="Oracle" PluginID="oracle.sysman.core">
<Description>
<![CDATA[ Microsoft SCOM 2012 Connector - 12.1.0.1.0 ]]>
</Description>
<AttributeList>
<Version>12.1.0.1.0</Version>
<Attribute Name="connector_type" Value="SCOM 2012 Connector" Label="SCOM 2012 Connector"/>
<Attribute Name="connector_category" Value="EventConnector" Label="Event Connector"/>
</AttributeList>
<Readme><![CDATA[
The Oracle Management Connector for Microsoft System Center Operations Manager (SCOM) 2012 enables you to forward Enterprise Manager alerts to SCOM 2012. The integration is a uni-directional connection so information only flows from Enterprise Manager to SCOM. State changes in Enterprise Manager are reflected in SCOM. However, if you change the state of the alert in SCOM, the change is not reflected in Enterprise Manager.
The connector requires the installation of an Oracle SCOM agent on a Windows system with connectivity to the RMS server system. In addition to the agent, an Oracle SCOM Web Service must also be installed. The web service must be installed on a system that has connectivity to the system where the agent is installed and the Enterprise Manager server system. The web service is Java based and can be installed on any Windows or UNIX platform that supports Oracle JRE version 6.
This connector only supports SCOM 2012. There is a separate connector that must be used with versions of SCOM 2007.
Some configuration changes are required in SCOM to allow alerts to be created by Enterprise Manager. A management pack must be imported and an account must be set up that can be used to access the SCOM API.
Change Logs:
12.1.0.1.0
- Initial Release
]]></Readme>
<DependsOn/>
<ArchiveList>
<Archive Filename="scom_2012_connector.jar" IsMDS="false"/>
<Archive Filename="SCOM_webservices_adapter.jar" />
<Archive Filename="SCOM2012Agent.zip" />
<Archive Filename="SCOMNotification.zip" />
</ArchiveList>
<CustomData></CustomData>
</EntityInstance>
</EntityInstanceList>
