| Oracle® Enterprise Manager Connectors統合ガイド 13c リリース2 E94901-01 |
|
 前へ |
 次 |
この章の内容は、次のとおりです。
注意:
チケッティング・コネクタは、ヘルプ・デスク・コネクタと呼ばれることもあります。
Enterprise Manager Cloud Control 12cには、管理コネクタ・フレームワーク(コネクタ・フレームワークとも呼ばれる)が用意されており、開発者は、外部のチケッティング・アプリケーションでチケットまたはインシデントを作成/更新するチケッティング・コネクタを構築できます。概念的には、チケットとインシデントは同じです。混乱を避けるため、インシデントはEnterprise Managerでインシデントに言及する際に使用され、チケットは外部のチケッティング・アプリケーションでインシデントに言及する際に使用されます。
コネクタが外部のチケッティング・アプリケーションとデータを交換するには、Webサービスが使用可能で、コネクタがインシデント情報の取得、作成および更新のために起動できる必要があります。コネクタは、UIでのコネクタの表示方法および外部のチケッティング・アプリケーションに接続してデータを交換する方法を定義する一連のXMLとXSLTメタデータ・ファイルで構成されています。
チケッティング・コネクタは、次の2通りの方法で起動できます。
自動チケッティング
Enterprise Manager内でインシデントまたはイベントがトリガーされた場合は常に自動的にチケットをオープンまたは更新するように、コネクタを構成できます。チケットが作成または更新されるようにインシデント・ルールを指定できます。
手動チケッティング
Enterprise Manager内のオープンなインシデントまたはイベントに基づいて、Enterprise Managerコンソールから手動でチケットを作成できます。コネクタにより、インシデントおよびチケット・テンプレートに基づいて、チケットに詳細が移入されます。
ユーザー独自のヘルプ・デスク・システムまたはチケッティング・システムでこれらのチケッティング機能を使用するには、一連のメタデータ・ファイルを提供する必要があります。表1-1に、チケッティング・コネクタを構成するメタデータ・ファイルのカテゴリを示します。
表1-1 メタデータ・ファイルのカテゴリ
| カテゴリ | タイプ | 説明 |
|---|---|---|
コネクタ記述子 |
XML |
コネクタ記述子ファイルは、Enterprise Managerにコネクタを定義します。このファイルには、UIでのコネクタの表示方法、Webサービスの配置場所とそれに接続する方法、およびシステム間で送信されるデータの変換に使用するテンプレートに関する情報が含まれています。 |
チケット・リクエスト・テンプレート |
XMLまたはXSL |
これらのテンプレートは、チケットを取得、作成または更新するためにWebサービスに送信されるXMLリクエストを生成します。これらのテンプレートは、Enterprise Managerのインシデント・データ・フィールドを、Webサービスで想定されている形式に変換します。 |
レスポンス・テンプレート |
XSL |
レスポンス・テンプレートは、Webサービス・コールで返されたXMLレスポンスを、コネクタ・フレームワークで想定されている形式に変換します。 |
公開テンプレート |
XSL |
このオプションのテンプレートはチケット・ステータスを同期化します。このテンプレートは、外部のチケッティング・アプリケーションでチケットのステータスが変更されるたびに、Enterprise Managerのチケット・ステータスを更新します。 |
チケッティング・コネクタの作成方法を理解するには、それがどのように機能するかを理解する必要があります。connectorDeploy.xmlファイル(通常は、コネクタ記述子ファイルと表記)は、Enterprise Managerにコネクタを定義します。コネクタがインストールされると、Enterprise Managerではコネクタ記述子ファイルの内容が検証され、コネクタに必要なフィールドおよびWebサービスとのXMLメッセージの交換時に使用するテンプレートが決定されます。
次の各項では、チケッティング・コネクタの機能について説明します。
オペレータがコネクタを構成すると、コネクタ記述子ファイルの情報に基づいて構成ページが生成されます。通常、このページには、Webサービスへの接続時に使用するURLと資格証明が記載されたフィールドが含まれています。チケッティング・コネクタに必要なフィールドの1つが「チケットID」フィールドです。このフィールドを使用して、外部のチケッティング・アプリケーションへの接続を検証します。これは、外部のチケッティング・アプリケーションの既存インシデントの識別子に設定する必要があります。オペレータが構成ページの「Ok」ボタンをクリックすると、コネクタ・フレームワークではgetTicket操作が実行され、「チケットID」フィールドに指定したチケット識別子の情報が取得されます。コネクタ・フレームワークでは、コネクタに定義されているgetTicketリクエスト・テンプレートを使用して、チケット情報を取得するためにWebサービスに送信するXMLを生成します。Webサービスからレスポンスを取得する場合は、getTicketレスポンス・テンプレートを使用して、XMLをWebサービスからコネクタ・フレームワークで想定されている形式に変換します。チケット・データがWebサービスを介して取得された場合、コネクタは完了としてマークされ、使用する準備ができます。エラーが発生した場合、構成の変更は保存されますが、コネクタは完了としてマークされません。失敗した場合は、その理由を調査し、問題に対処する必要があります。問題に対処した後は、構成ページに戻って「OK」をクリックし、接続を再度テストできます。
コネクタが完了とマークされた後は、既存のインシデントを使用して、外部のチケッティング・アプリケーションでチケットを手動で作成したり、インシデント・ルールを設定して、特定イベントの発生時に、外部のチケッティング・アプリケーションでチケットを自動的に作成することができます。たとえば、データベースの表領域が指定されたしきい値を超えた場合にチケットをオープンするルールを設定できます。ルールを設定するときは、ルールを適用するターゲット、ルールのトリガーに使用する基準、起動するチケッティング・コネクタおよびそのコネクタに対して使用するテンプレートを指定します。
基準が満たされてルールが起動すると、コネクタ・フレームワークでは、チケッティング・コネクタを起動してチケットを作成します。チケットを作成する手順は、次のとおりです。
createTicketレスポンス・テンプレートを使用して、新しいインシデント識別子をコネクタ・フレームワークで想定されている形式に変換します。注意:
作成リクエストと更新リクエストには同じテンプレートが使用されます。テンプレートでは、TicketIDフィールドを使用して作成と更新を区別します。このフィールドにデータがある場合、テンプレートでは、実行されているのはupdateTicket操作であると認識し、データがない場合はcreateTicket操作であると認識します。
Enterprise Managerでインシデントの更新の原因となる状況が発生した場合、コネクタ・フレームワークでは、インシデント・ルールで指定されたテンプレートを使用して、Enterprise Managerのインシデント・データ形式を、Webサービスに送信するXML更新リクエストに変換します。Webサービスは、外部のチケッティング・アプリケーションでチケットを更新し、レスポンスを送信します。レスポンスを取得したコネクタ・フレームワークは、createTicketレスポンス・テンプレートを使用して、そのレスポンスを、コネクタ・フレームワークで想定されている形式に変換します。コネクタ・フレームワークは、このレスポンスを使用して、更新が正常に完了したことを確認します。
注意:
updateTicketレスポンス・テンプレートはありません。作成レスポンスと更新レスポンスは、createTicketサービス操作に定義されているテンプレートによって処理されます。
インシデントが解決され、クリア済ステータスになると、コネクタ・フレームワークはCLEARに設定されたSeverityCodeフィールドを使用して、通常のupdateTicket操作を実行します。
外部のチケッティング・アプリケーションで発生するチケット・ステータスの変更を同期化するオプション機能もあります。この機能では、Enterprise Managerで作成されたチケットのステータスが変更されるたびに、emcliをコールするように、外部のチケッティング・アプリケーションが構成されている必要があります。emcliのコールによって、新しいステータスがEnterprise Managerに送信され、Enterprise ManagerはpublishTicket操作としてリクエストを処理します。この作業を行うには、publishTicketリクエスト・テンプレートを定義して、データをemcliから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
表1-2に、抽出したスキーマ・ファイルの場所を示します。この表は、スキーマ・ファイルが説明されている様々な項で参照されます。
表1-2 スキーマ・ファイルの場所
| ファイル名 | 場所 |
|---|---|
connectorDeploy.xsd |
oracle/sysman/emSDK/core/connector/common |
createTicket_response.xsd |
oracle/sysman/emSDK/core/connector/ticketingConnector |
EMEvent.xsd |
oracle/sysman/emSDK/core/connector/eventConnector |
EMIncident.xsd |
oracle/sysman/emSDK/core/connector/ticketingConnector |
getTicket_response.xsd |
oracle/sysman/emSDK/core/connector/ticketingConnector |
publishTicket.xsd |
oracle/sysman/emSDK/core/connector/ticketingConnector |
SelfUpdateManifest.xsd |
oracle/sysman/emSDK/core/selfupdate/model |
これで、コネクタがどのように機能するかを理解し、チケッティング・コネクタの作成プロセスを開始する準備が整いました。コネクタを作成するには、次の各項で指定されている手順に従う必要があります。
コネクタを作成するには、要件を分析して、コネクタに含める機能を決定する必要があります。この項は、自分のチケッティング・コネクタに必要なテンプレートの決定に役立ちます。この項を終了すると、コネクタに対して実装する必要があるテンプレートのリストが手に入ります。
すべてのチケッティング・コネクタに含める必要がある、必須のテンプレートがいくつかあります。これらのテンプレートは、コネクタに含める以外の選択肢がありません。必要に応じてコネクタに含めることができる、オプションのテンプレートが他にあります。表1-3に、チケッティング・コネクタに対して定義可能なテンプレートを示します。この表の「説明」列では、テンプレートが提供する機能を説明します。オプションのテンプレートが提供する機能を分析し、コネクタに含めるものを決定する必要があります。この分析が完了した後は、提供する必要があるテンプレートのリストが手に入ります。リストは、必須のテンプレートと、含めるように選択したオプションのテンプレートで構成されます。
表1-3 定義可能なチケッティング・テンプレート
| テンプレート | 必須/オプション | 説明 |
|---|---|---|
|
必須 |
Webサービスからチケット情報を取得するリクエストを生成するために使用します。 |
|
必須 |
Webサービスからのレスポンスを、Enterprise Managerで想定されている形式に変換するために使用します。 |
デフォルト・テンプレート |
必須 |
Webサービスに送信するチケットを作成または更新するリクエストを生成するために使用します。少なくとも1つのデフォルト・テンプレートを定義する必要があります。 |
追加のデフォルト・テンプレート |
オプション |
コネクタの起動時にオペレータが選択できる、追加のテンプレートを定義できます。デフォルトの各テンプレートは、様々な機能を備えています。たとえば、あるテンプレートでは、Enterprise Managerでインシデントがクリアされると、チケットを自動的にクローズできます。別のテンプレートではチケットはクローズされませんが、履歴ログが更新されます。 |
|
オプション |
このテンプレートは、チケットを作成し、Enterprise Managerでのインシデント更新の発生時にそのチケットを更新するために実装します。このテンプレートを使用しない場合、作成したチケットの識別子はEnterprise Managerインシデントに保存されません。更新が発生するたびに、新しいチケットが作成されます。必須ではありませんが、このテンプレートを実装することをお薦めします。 |
|
オプション |
このテンプレートは、外部のチケッティング・アプリケーションで発生するチケットのステータス変更を取得するために使用します。外部のチケッティング・アプリケーションは、チケットのステータス変更が発生したときにemcliをコールし、そのステータス変更をEnterprise Managerに送信するように構成されている必要があります。このテンプレートは、リクエストを処理し、Enterprise Managerで想定されている形式に変換します。 |
また、各テンプレートに対して使用するファイル名を決定する必要があります。テンプレート・ファイル名に関する要件はありませんが、次の命名規則を使用することをお薦めします。
<methodName>_request.xml <methodName>_request.xsl <methodName>_response.xsl
表1-4に、推奨ネーミング規則に基づいて、異なるテンプレートに対して推奨されるファイル名を示します。
表1-4 推奨テンプレート・ファイル名
| テンプレート | 推奨ファイル名 |
|---|---|
|
|
|
|
デフォルト・テンプレート |
テンプレートの機能を表現するファイル名を選択します |
|
|
|
|
これで、提供する必要があるテンプレートを識別しました。次のステップは、テンプレート・ファイルを作成することです。テンプレート・ファイルの生成とテストには、XML/XSLTツールの使用をお薦めします。ファイルは標準のテキスト・エディタを使用して作成できますが、プロセスが非常に困難となり時間がかかります。Enterprise Managerでコネクタをパッケージ化してインストールする前に、ツールでは形式エラーが捕捉され、テンプレートをテストできます。これによって、インストールされているコネクタに対して実行する必要がある修正の数が大幅に削減されます。コネクタに対して実行する必要がある各修正では、古いコネクタをアンインストールし、新しいバージョンのコネクタを再パッケージ化して、再インストールする必要があります。
次の各項では、様々なテンプレート・ファイルを作成するために必要なステップについて説明します。使用するコネクタの対象とならないテンプレートを説明している項は無視できます。
getTicketリクエスト・テンプレートgetTicketリクエスト・テンプレートは、Webサービスからチケット情報を取得するために必要なXML形式を識別するXMLファイルです。チケット情報を取得するためにWebサービスで必要なXMLのサンプルがある場合は、それをテンプレート・ファイルにコピーできます。サンプルがない場合は、WSDLまたはWebサービスで必要な形式を定義するスキーマを参照する必要があります。ファイルを目で見てXML形式を決定できない場合は、WSDL/スキーマを確認し、サンプルのXMLファイルの生成に使用できるツールがあります。
テンプレートとして動作させるには、XMLファイル対して少なくとも1つの変更を加える必要があります。チケット識別子が存在している場所では、@TicketId@を使用して指定したすべての内容を置換する必要があります。これによって、コネクタ・フレームワークに対して、コネクタの構成時に入力したチケット識別子を置換するように指示します。
次の例1-1は、WSDLから生成されたXMLファイルのサンプルを示しており、例1-2は、対応するgetTicketリクエスト・テンプレートのコンテンツを示しています。サンプルには、SOAPエンベロープ情報が含まれているため、テンプレート・ファイルから削除されています。SOAPの情報は、Webサービスがコールされるたびにコネクタ・フレームワークによって追加されます。注意が必要なもう1つの点は、urn namespaceの定義が、削除されたSOAPエンベロープで定義されていたために移動されたことです。urn namespaceが移動されていなかった場合は、ネームスペースが定義されていないため、無効なリクエストになります。XML形式が有効であることを確認するためにツールを使用する以外に、このテンプレートで実行できる実際のテストはありません。スキーマと照合して検証できる場合は、さらに改善されます。
例1-1 XMLのチケット取得サンプル
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:HPD_IncidentInterface_Custom_WS">
<soapenv:Header/>
<soapenv:Body>
<urn:HelpDesk_Query_Service>
<urn:Incident_Number>?</urn:Incident_Number>
</urn:HelpDesk_Query_Service>
</soapenv:Body>
</soapenv:Envelope>
例1-2 getTicket_request.xml
<urn:HelpDesk_Query_Service xmlns:urn="urn:HPD_IncidentInterface_Custom_WS">
<urn:Incident_Number>@TicketId@</urn:Incident_Number>
</urn:HelpDesk_Query_Service>
getTicketレスポンス・テンプレートgetTicketレスポンス・テンプレートは、WebサービスからのレスポンスをEnterprise Managerで想定されている形式に変換するXSLTファイルです。WebサービスからのレスポンスXMLの形式は、WSDLまたはスキーマによって定義されている必要があります。Enterprise Managerで想定されている形式は、getTicket_response.xsdスキーマ・ファイルに指定されています。getTicket_response.xsdスキーマ・ファイルの場所は、「スキーマ・ファイルの抽出」の項の表1-2を参照してください。
例1-3は、Webサービスからのサンプル・レスポンス・ファイルを示しています。例1-4は、データをEnterprise Managerで想定されている形式に変換するために設計されたサンプルXSLTテンプレートを示しています。XSLTテンプレートでは、urn:HPD_IncidentInterface_Custom_WSというネームスペースを持つHelpDesk_Query_ServiceResponseという名前のルート要素が検索されます。http://xmlns.oracle.com/sysman/connector/ttというネームスペースを持つgetTicketResponseルート要素が作成され、TicketId子要素が作成されて、Incident_Number要素に指定されている識別子に設定されます。TicketId要素が空でない場合、Enterprise Managerでは、チケットが正常に取得されたことを認識します。例1-5は、XSL変換ツールを使用して変換を実行することによって生成されたXMLを示しています。
例1-3 Webサービスからの入力レスポンスXML
<?xml version='1.0' encoding='UTF-8'?> <urn:HelpDesk_Query_ServiceResponse xmlns:urn="urn:HPD_IncidentInterface_Custom_WS"> <urn:Incident_Number>TKT00001</urn:Incident_Number> </urn:HelpDesk_Query_ServiceResponse>
例1-4 サンプルXSLTテンプレート・ファイル
<?xml version='1.0' encoding='UTF-8'?>
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:urn="urn:HPD_IncidentInterface_Custom_WS"
xmlns="http://xmlns.oracle.com/sysman/connector/tt"
targetNamespace="http://xmlns.oracle.com/sysman/connector/tt"
elementFormDefault="qualified">
<xsl:template match="urn:HelpDesk_Query_ServiceResponse">
<getTicketResponse>
<TicketId><xsl:value-of select="urn:Incident_Number/text()"/></TicketId>
</getTicketResponse>
</xsl:template>
</xsl:transform>
例1-5 変換の結果生成されたファイル
<?xml version="1.0"?>
<getTicketResponse xmlns="http://xmlns.oracle.com/sysman/connector/tt"
xmlns:urn="urn:HPD_IncidentInterface_Custom_WS">
<TicketId>TKT00001</TicketId>
</getTicketResponse>
XSLTテンプレートを作成するときは、最初から開始する必要はありません。既存のテンプレートをコピーし、状況にあわせてカスタマイズするほうが簡単です。前述のテンプレートをカスタマイズする手順は、次のとおりです。
urn namespace定義を、Webサービスから生成されたXMLに指定されるネームスペースに置き換えます。
テンプレートのmatch属性を変更して、Webサービスから生成されたXMLのルート要素を参照するようにします。
TicketId要素の作成時にチケット識別子情報を取得する要素の名前を変更します。
ファイルを作成した後は、XSLTツールを実行して、サンプルXMLからのデータを変換することでテンプレートをテストし、正しいXML形式が生成されることを確認する必要があります。
デフォルト・テンプレートは、他のテンプレートよりも大きく複雑なため、作成が最も困難です。チケットが手動で作成されるか、またはチケッティング・コネクタを起動するインシデント・ルールが起動された場合、コネクタ・フレームワークでは、影響を受けたインシデントのデータを含む内部XMLドキュメントが生成されます。この生成されたXMLドキュメントは、選択したデフォルト・テンプレートに関係する変換の入力XMLとして使用されます。変換の結果生成されるXMLは、外部のチケッティング・アプリケーションでチケットを作成または更新するためにWebサービスに送信されるXMLです。
テンプレートを作成するには、外部のチケッティング・アプリケーションで作成/更新されるデータの形式およびEnterprise Managerから取得されるデータの形式を理解しておく必要があります。形式の理解には、使用可能なフィールドやそれらのフィールドに入力可能な値の識別が含まれます。
外部のチケッティング・システムでチケットを作成/更新するためには、指定されたデータの形式を理解しておく必要があります。手始めは、WSDLまたはデータの形式を定義するスキーマ・ファイルです。また、データの形式を設定する方法を確認するためにサンプルの作成/更新リクエストを参照する必要があります。サンプルを使用できない場合は、XMLクライアント・ツールを使用して既存のチケットのデータを手動で取得できるようにする必要があります。これによって、データがどのように表示されるかを把握できます。
外部のチケッティング・アプリケーションのデータを理解した後は、Enterprise Managerから取得したデータを調査し、理解する必要があります。Enterprise Managerのインシデント/イベント・データで使用できるフィールドは、2つのスキーマ・ファイル内で識別されます。EMIncident.xsdファイルは、インシデント・データの形式を定義し、EMEvent.xsdファイルは、インシデントをトリガーしたイベント・データの形式を定義します。EMIncident.xsdおよびEMEvent.xsdのスキーマ・ファイルの場所は、「スキーマ・ファイルの抽出」の項の表1-2を参照してください。スキーマ・ファイルはフィールドを識別し、それらのフィールドのデータのタイプを示しますが、実際に存在するデータの内容は把握していません。データがどのように表示されるかを理解するには、Enterprise Managerによって生成されたサンプルXMLファイルが必要です。「サンプル・インシデント・データ」では、Enterprise Managerによって生成されたサンプル・トランザクションを示しています。
データをよく理解した後は、必要なテンプレートの数と各テンプレートで実行するマッピングを決定する必要があります。これには、作成/更新リクエストに指定するフィールドと、それらのフィールドのデータ形式の決定が含まれます。データのソースに関する選択肢は2つのみです。データはハードコードするか、またはEnterprise Managerのインシデント/イベント・データから取得できます。マッピングは状況にあわせて複雑または単純にできます。最終的には、自分の環境に適したフィールドと設定を決定する必要があります。
テンプレートとそれぞれのマッピングを識別した後は、XSLTファイルの作成準備が整います。最初のテンプレートに着手するには、例1-6に示すXMLを、XSLTファイルを作成しているエディタにコピーします。これには、テンプレートの作成に必要な基本的なスケルトンが含まれています。スケルトンには、作成リクエスト用のセクションおよび更新リクエスト用の別のセクションがあります。適切なセクションにマッピングのロジックを追加する必要があります。複数のテンプレートを作成する場合、推奨されるアプローチは、最も簡単なテンプレートを最初に作成し、それを十分にテストすることです。これが機能することを確認した後は、そのテンプレートのコピーを作成して他のテンプレートのベースラインとして使用できます。
「デフォルト・テンプレートの例」では、デフォルト・テンプレートの作成方法を示す例を順を追って説明します。
例1-6 テンプレート・スケルトン
<?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:EMIncident">
<xsl:choose>
<xsl:when test="normalize-space(emcf:TicketID) = ''">
<!-- CREATE Request -->
<!-- Replace this comment with the mapping logic for create requests -->
</xsl:when>
<xsl:otherwise>
<!-- UPDATE Request -->
<!-- Replace this comment with the mapping logic for update requests -->
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>
createTicketレスポンス・テンプレートcreateTicketレスポンス・テンプレートは、WebサービスからのレスポンスをEnterprise Managerで想定されている形式に変換するXSLTファイルです。テンプレート名は作成レスポンスのみを意味しますが、更新レスポンスの処理にも使用されます。WebサービスからのレスポンスXMLの形式は、WSDLまたはスキーマによって定義されている必要があります。Enterprise Managerで想定されている形式は、createTicket_response.xsdスキーマ・ファイルに指定されています。createTicket_response.xsdスキーマ・ファイルの場所は、「スキーマ・ファイルの抽出」の項の表1-2を参照してください。
例1-7は、Webサービスからのサンプル・レスポンス・ファイルを示しています。例1-8は、データをEnterprise Managerで想定されている形式に変換するために設計されたサンプルXSLTテンプレートを示しています。XSLTテンプレートでは、urn:HPD_IncidentInterface_Create_WSというネームスペースを持つHelpDesk_Submit_ServiceResponseという名前のルート要素が検索されます。http://xmlns.oracle.com/sysman/connectorというネームスペースを持つCreateTicketResponseルート要素が作成され、TicketId子要素が作成されて、Incident_Number要素に指定されている識別子に設定されます。また、Incident_Number変数には、Incident_Number要素に指定されている識別子が移入されます。TicketId要素が空でない場合、Enterprise Managerでは、チケットが正常に作成されたことを認識します。例1-9は、XSLTツールを使用して変換を実行することによって生成されたXMLを示しています。
例1-7 Webサービスからの入力レスポンスXML
<?xml version='1.0' encoding='UTF-8'?> <urn:HelpDesk_Submit_ServiceResponse xmlns:urn="urn:HPD_IncidentInterface_Create_WS"> <urn:Incident_Number>TKT00001</urn:Incident_Number> </urn:HelpDesk_Submit_ServiceResponse>
例1-8 サンプルXSLTテンプレート・ファイル
<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:urn="urn:HPD_IncidentInterface_Create_WS"
xmlns="http://xmlns.oracle.com/sysman/connector">
<xsl:template match="urn:HelpDesk_Submit_ServiceResponse">
<CreateTicketResponse>
<TicketId>
<xsl:value-of select="urn:Incident_Number"/>
</TicketId>
<InstanceVariable>
<VariableName>Incident_Number</VariableName>
<VariableValue>
<xsl:value-of select="urn:Incident_Number"/>
</VariableValue>
</InstanceVariable>
</CreateTicketResponse>
</xsl:template>
</xsl:transform>
例1-9 変換の結果生成されたファイル
<?xml version="1.0" encoding="UTF-8"?>
<CreateTicketResponse xmlns="http://xmlns.oracle.com/sysman/connector" xmlns:urn="urn:HPD_IncidentInterface_Create_WS">
<TicketId>TKT00001</TicketId>
<InstanceVariable>
<VariableName>Incident_Number</VariableName>
<VariableValue>TKT00001</VariableValue>
</InstanceVariable>
</CreateTicketResponse>
XSLTテンプレートを作成する場合は常に、既存のテンプレートをコピーし、状況にあわせてカスタマイズするほうが簡単です。前述のテンプレートをカスタマイズする手順は、次のとおりです。
urn namespace定義を、Webサービスから生成されたXMLに指定されるネームスペースに置き換えます。
テンプレートのmatch属性を変更して、Webサービスから生成されたXMLのルート要素を参照するようにします。
TicketId要素の作成時にチケット識別子情報を取得する要素の名前を変更します。
ファイルを作成した後は、XSLTツールを実行して、サンプルXMLからのデータを変換することでテンプレートをテストし、正しいXML形式が生成されることを確認する必要があります。
publishTicketリクエスト・テンプレートpublishTicketリクエスト・テンプレートは、emcliによって送信されたステータス変更情報をEnterprise Managerで想定されている形式に変換するXSLTファイルです。Enterprise Managerで想定されている形式は、publishTicket.xsdスキーマ・ファイルに指定されています。publishTicket.xsdスキーマ・ファイルの場所は、「スキーマ・ファイルの抽出」の項の表1-2を参照してください。
ソース(emcli)と宛先(Enterprise Manager)のXML形式は、すべてのコネクタに対して同一であるため、定義されているテンプレートでは、コネクタ間の変更がほとんど、またはまったく必要ありません。変更が必要な唯一の部分は、ステータス・フィールドです。一部のアプリケーションには、考えられるそれぞれのステータスに対して定義された2つのステータス値があります。1つは内部的に使用され、もう1つはコンソールに表示される値です。たとえば、アプリケーションには、コンソールで文字列として表示される、数値の内部ステータスがある場合があります。emcliがステータスに渡す値が表示文字列である場合、そのステータスは変更を加えずにEnterprise Managerに直接受け渡すことができます。値が内部値として渡された場合は、その数値を対応する文字値に変換する必要があります。
例として、ステータスを表す数値を使用して内部的にステータスを追跡する、外部アプリケーションがあるとします。また、コンソールでは、ステータスがテキスト文字列として表示され、内部ステータスの2がコンソールで「進行中」と表示されるとします。emcliが内部ステータス値の2を渡した場合、テンプレートでは、2を「進行中」の値に変換して、ステータス・フィールドを「進行中」に設定する必要があります。emcliが「進行中」の表示ステータスを渡した場合は、値を変更せずに受け渡すことがきます。例1-10には、変更なしでステータスを受け渡すテンプレートが含まれており、例1-11には、ステータスを変換するテンプレートが含まれています。テンプレートは、状況に応じてコピーします。変換が不要な場合は、例1-10のテンプレートをコピーして、変更せずに使用できます。変換が必要な場合は、例1-11のテンプレートをコピーしますが、ステータス変換マッピングは、アプリケーションで定義された値を使用するために変更する必要があります。
例1-10 未変更ステータスを渡す公開テンプレート
<?xml version='1.0' encoding='UTF-8'?>
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:a="http://xmlns.oracle.com/sysman/connector"
targetNamespace="http://xmlns.oracle.com/sysman/connector"
elementFormDefault="qualified">
<xsl:template match="a:InboundData">
<InboundData>
<Operation><xsl:value-of select="a:Operation"/></Operation>
<PropertyList>
<ticket_guid><xsl:value-of select="a:PropertyList/a:ticket_guid"/></ticket_guid>
<status><xsl:value-of select="a:PropertyList/a:status/text()"/></status>
<connector_guid><xsl:value-of select="a:PropertyList/a:connector_guid"/></connector_guid>
<last_updated_date><xsl:value-of select="a:PropertyList/a:last_updated_date"/></last_updated_date>
</PropertyList>
</InboundData>
</xsl:template>
</xsl:transform>
例1-11 変換済ステータスを渡す公開テンプレート
<?xml version='1.0' encoding='UTF-8'?>
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:a="http://xmlns.oracle.com/sysman/connector"
targetNamespace="http://xmlns.oracle.com/sysman/connector"
elementFormDefault="qualified">
<xsl:template match="a:InboundData">
<InboundData>
<Operation><xsl:value-of select="a:Operation"/></Operation>
<PropertyList>
<ticket_guid><xsl:value-of select="a:PropertyList/a:ticket_guid"/></ticket_guid>
<status>
<xsl:choose>
<xsl:when test="(a:PropertyList/a:status/text() = '0')">New</xsl:when>
<xsl:when test="(a:PropertyList/a:status/text() = '1')">Assigned</xsl:when>
<xsl:when test="(a:PropertyList/a:status/text() = '2')">In Progress</xsl:when>
<xsl:when test="(a:PropertyList/a:status/text() = '3')">Pending</xsl:when>
<xsl:when test="(a:PropertyList/a:status/text() = '4')">Resolved</xsl:when>
<xsl:when test="(a:PropertyList/a:status/text() = '5')">Closed</xsl:when>
<xsl:when test="(a:PropertyList/a:status/text() = '6')">Cancelled</xsl:when>
</xsl:choose>
</status>
<connector_guid><xsl:value-of select="a:PropertyList/a:connector_guid"/></connector_guid>
<last_updated_date><xsl:value-of select="a:PropertyList/a:last_updated_date"/></last_updated_date>
</PropertyList>
</InboundData>
</xsl:template>
</xsl:transform>
これでテンプレートが作成され、今度は、Enterprise Managerでコネクタを定義するコネクタ記述子ファイルを作成します。コネクタ記述子XMLファイルには、コネクタ・メタデータおよびコネクタの構成プロパティ(Webサービス・エンドポイントおよび認証スキーマなど)が記述されています。
記述子を作成する際の重要な留意点は次のとおりです。
コネクタ記述子ファイル名は、connectorDeploy.xmlにする必要があります。
XMLファイルは、connectorDeploy.xsdスキーマ・ファイルに準拠する必要があります。
スキーマ・ファイルの場所の要約は、「スキーマ・ファイルの抽出」の項の表1-2を参照してください。
リファレンス実装は、「チケッティング・コネクタのサンプル」のサンプルconnectorDeploy.xmlを参照してください。
表1-5に、コネクタ記述子を構成するセクションと、各セクションが実行する内容の要約を示します。
表1-5 メタデータ・セクション
| メタデータ・セクション | 必須 | 説明 |
|---|---|---|
コネクタ情報 |
はい |
このセクションでは、UIに表示されるコネクタに関する情報を提供します。 |
認証 |
いいえ |
認証方式およびWebサービスへの接続に必要なパラメータを指定します。 |
接続テスト変数 |
はい |
このセクションで定義された変数は、接続を検証する初期構成ステップで使用されます。 |
外部URL |
いいえ |
このセクションでは、外部システム内のチケットのコンテンツを直接表示するリンクを提供するようにコネクタを構成できます。 |
サービス |
はい |
このセクションでは、様々なサービス操作のWebサービスへの接続に使用するURLを構成します。 |
テンプレート登録 |
はい |
このセクションでは、コネクタに対して使用するすべてのテンプレートを定義します。 |
次の各項では、コネクタ記述子のコンテンツの詳細について説明します。
コネクタ・デプロイメント・ファイルの各セクションには、コネクタに関する特定の情報を提供するフィールドが含まれています。次の各セクションには、使用可能なフィールドとこれらのフィールドの内容に関する詳細情報が含まれています。
コネクタ情報セクションでは、UIに表示される名前、バージョン、説明など、コネクタに関する情報を提供します。表1-6に、このセクションのフィールドの一覧を示し、各フィールドの説明を示します。
表1-6 コネクタ情報フィールド
| セクション/フィールド | 必須 | 説明 |
|---|---|---|
Name |
はい |
UIに表示されるコネクタ名。 |
Version |
はい |
UIに表示されるコネクタ・バージョン。 |
EMCompatibleVersion |
はい |
サポートされているEnterprise Managerの最も初期のバージョン。 |
Description |
はい |
UIに表示されるコネクタの説明。 |
Category |
はい |
可能な値は次のとおりです。 EventConnector TicketingConnector この場合、値は |
例1-12は、コネクタ情報セクションに含まれている情報のサンプルを示しています。このセクションのすべてのフィールドは、ManagementConnectorノードに含まれています。
例1-12 コネクタ情報セクションのサンプル
<Name>Remedy Service Desk 7.6 Connector</Name> <Version>12.1.0.2.0</Version> <EMCompatibleVersion>12.1.0.1.0</EMCompatibleVersion> <Description>Remedy Service Desk 7.6.04 Integration with Enterprise Manager</Description> <Category>TicketingConnector</Category>
認証セクションでは、認証方式およびWebサービスへの接続に必要な資格証明を指定します。構成可能な3種類の認証タイプがあります。認証セクションが指定されていない場合、コネクタがWebサービスに接続するときに認証は実行されません。表1-7に、3種類の認証セクションとそれぞれに含まれているフィールドを示します。
表1-7 認証フィールド
| セクション/フィールド | 必須 | 説明 | |
|---|---|---|---|
|
いいえ |
SOAPヘッダーの認証を使用したWebサービスへの接続に使用する資格証明を指定します。 |
|
*Username |
はい |
SOAPヘッダーに指定するユーザー名 |
|
*Password |
はい |
SOAPヘッダーに指定するパスワード |
|
*AuthVariable |
いいえ |
SOAPヘッダーで渡す最大20の他の変数 |
|
*SOAPHeader |
はい |
SOAPヘッダーのテンプレートとして機能する文字列。これは、指定の場所で上に定義され、HTTPリクエストとバインドされている変数をユーザー入力で置き換えることによって更新されます。 |
|
|
いいえ |
基本認証を使用したWebサービスへの接続に使用する資格証明を指定します。 |
|
*Username |
はい |
Webサービスをコールするときに指定するユーザー名 |
|
*Password |
はい |
Webサービスをコールするときに指定するパスワード |
|
|
いいえ |
ユーザー名トークン・プロファイルの認証を使用したWebサービスへの接続に使用する資格証明を指定します。 |
|
*Username |
はい |
指定するユーザー名 |
|
*Password |
はい |
指定するパスワード |
|
* アスタリスク付きのフィールドは、次のサブフィールドで構成されています。
VariableName: 定義されている変数の名前
DisplayName: UIでこのフィールドに関する情報を表示するときに使用する名前
"required"属性: フィールドが必須かどうかを指定します(未指定の場合は、falseにデフォルト設定されます)
例1-13は、認証セクションに含まれている情報を示しています。この例での認証方式は、SOAPヘッダーです。コネクタを構成する場合、オペレータは、Remedyユーザー名、Remedyパスワード、認証、ロケール、タイムゾーンの各値を指定する必要があります。オペレータが入力した値は、SOAPHeaderセクションにXMLを移入するために使用され、これは、Webサービスに送信されるリクエスト用のSOAPヘッダーで渡されます。
例1-13 認証セクションのサンプル
<SOAPHeaderAuthentication>
<Username required="true">
<VariableName>USERNAME</VariableName>
<DisplayName>Remedy Username</DisplayName>
</Username>
<Password>
<VariableName>PASSWORD</VariableName>
<DisplayName>Remedy Password</DisplayName>
</Password>
<AuthVariable>
<VariableName>AUTHENTICATION</VariableName>
<DisplayName>Authentication</DisplayName>
</AuthVariable>
<AuthVariable>
<VariableName>LOCALE</VariableName>
<DisplayName>Locale</DisplayName>
</AuthVariable>
<AuthVariable>
<VariableName>TIMEZONE</VariableName>
<DisplayName>Timezone</DisplayName>
</AuthVariable>
<SOAPHeader>
<![CDATA[
<urn:AuthenticationInfo xmlns:urn="urn:HelpDesk_Submit_Service">
<urn:userName>$USERNAME$</urn:userName>
<urn:password>$PASSWORD$</urn:password>
<urn:authentication>$AUTHENTICATION$</urn:authentication>
<urn:locale>$LOCALE$</urn:locale>
<urn:timeZone>$TIMEZONE$</urn:timeZone>
</urn:AuthenticationInfo>
]]>
</SOAPHeader>
</SOAPHeaderAuthentication>
このセクションでは、Webサービスとの接続性を検証するための初期構成ステップのgetTicketサービス操作で使用する変数を定義します。表1-8に、セクションのフィールドの一覧を示し、各フィールドの説明を示します。
表1-8 接続テスト変数フィールド
| セクション/フィールド | 必須 | 説明 | |
|---|---|---|---|
|
はい |
外部システムへの接続のテストに使用される変数を定義します。コネクタが構成されている場合、オペレータはインシデントの識別子を外部システムに指定します。 この変数は、オペレータが指定した値に設定され、getTicket操作を介してインシデントを取得するリクエストの生成に使用されます。 |
|
VariableName |
はい |
定義されている変数の名前。 「TICKET_ID」に設定します。 |
|
DisplayName |
はい |
UIで変数に関する情報を表示するときに使用する名前。 「チケットID」に設定します。 |
|
例1-14は、接続テスト変数セクションに含まれている情報を示しています。このセクションは、変更なしで使用できるようにする必要があります。
例1-14 接続テスト変数セクションのサンプル
<ConnectivityTestVariable>
<VariableName>TICKET_ID</VariableName>
<DisplayName>Ticket ID</DisplayName>
</ConnectivityTestVariable>
このセクションでは、外部システム内のチケットのコンテンツを直接表示するリンクを提供するようにコネクタを構成できます。チケッティング・アプリケーションでは、チケット情報に直接アクセスするためのリンクを提供する必要があります。表1-9に、セクションのフィールドの一覧を示し、各フィールドの説明を示します。
表1-9 外部URLフィールド
| セクション/フィールド | 必須 | 説明 | |
|---|---|---|---|
|
いいえ |
外部システム内のチケットにアクセスするURL。 |
|
Pattern |
はい |
外部URLを決定するために使用されるパターン。
|
|
ConfigVariable |
いいえ |
コネクタの構成時に、オペレータが指定する必要がある変数。 URLパターン文字列には、各ユーザー変数にユーザーが提供する値が適宜挿入されます。"X"というユーザー変数が存在する場合は、チケットURLが生成される際に、ユーザー入力値で"$X$"が置き換えられます。 最大50個の変数を指定できます。 |
|
VariableName |
はい |
定義されている変数の名前。 |
|
DisplayName |
はい |
UIでこのフィールドに関する情報を表示するときに使用する名前。 |
|
required属性 |
いいえ |
フィールドが必須かどうかを指定します - 未指定の場合は、falseにデフォルト設定されます。 |
|
例1-15は、外部URLセクションに含まれている情報を示しています。ConfigVariableセクションで定義された変数は構成ページの入力フィールドとして表示され、オペレータはこのフィールドに値を入力します。オペレータが入力した値は、Patternフィールドの($で囲まれた)変数名がリストされているURLにプラグインされます。また、@Incident_Number@は例1-9に示すcreateTicketレスポンス・テンプレートによって作成されたIncident_Number変数のコンテンツで置換されます。
例1-15 外部URLセクションのサンプル
<ExternalURL>
<Pattern>
<![CDATA[http://$WEB_SERVER$/arsys/forms/$ARSERVER_NAME$/$FORM_NAME$/?qual=%27Incident%20Number*%27=%22@Incident_Number@%22]]>
</Pattern>
<ConfigVariable required="true">
<VariableName>WEB_SERVER</VariableName>
<DisplayName>Web Server</DisplayName>
</ConfigVariable>
<ConfigVariable required="true">
<VariableName>FORM_NAME</VariableName>
<DisplayName>HelpDesk Case Form Name</DisplayName>
</ConfigVariable>
<ConfigVariable required="true">
<VariableName>ARSERVER_NAME</VariableName>
<DisplayName>ARServer Name</DisplayName>
</ConfigVariable>
</ExternalURL>
このセクションを使用して、様々なサービス操作のWebサービスに接続するURLを構成します。次の各操作について個別のサービス・セクションのエントリが必要です。
createTicket
外部システムでチケットを作成します。
updateTicket
インシデントの更新を外部システムに転送します。
getTicket
Enterprise Managerとのチケット・コネクタの接続を検証するサービス・メソッドです。
注意:
コネクタ記述子でのサービス名は、前述で定義した名前と完全に一致する必要があり、大/小文字を区別します。
表1-10に、セクションのフィールドの一覧を示し、各フィールドの説明を示します。
表1-10 サービス・フィールド
| セクション/フィールド | 必須 | 説明 | |
|---|---|---|---|
サービス |
はい |
このセクションで、チケッティング・システムWebサービス固有の構成を指定できます。 |
|
Method |
はい |
メソッドには、Enterprise Manager固有のサービス操作名の1つを定義します。 チケッティング・コネクタの場合は、次のいずれかの値に設定する必要があります。 getTicket createTicket updateTicket |
|
WebServiceEndpoint |
はい |
このフィールドでは、デフォルトのWebサービス・エンドポイント文字列が「管理コネクタ」ページの「Webサービス」セクションに表示されるように指定します。 |
|
SOAPAction |
いいえ |
Webサービスをコールするときに指定するSOAPAction |
|
SOAPBindingType |
いいえ |
可能な値は次のとおりです。 SOAP11HTTP_BINDING SOAP12HTTP_BINDING SOAP11HTTP_MTOM_BINDING SOAP12HTTP_MTOM_BINDING |
|
例1-16は、3つの必須サービス・セクションすべてを示しています。WebServiceEndpoint要素内のURLは、予約済XML文字との競合を避けるためにCDATAセクションに配置されます。大カッコ[]で囲まれた値は、オペレータが構成ページで置換する必要があります。たとえば、createTicket操作のデフォルトのURLは、次のとおりです。
http://[midtier_server]/arsys/services/ARService?server=[servername]&webService=HPD_IncidentInterface_Create_WS
この値はcreateTicket操作の横にある構成ページの「Webサービス・エンドポイント」セクションに表示されます。オペレータは、[midtier_server]を実際の中間層サーバーのIPアドレスまたはホスト名で置き換える必要があります。また、[servername]をサーバーのIPアドレスまたはホスト名で置き換える必要があります。
例1-16 サービス・セクションのサンプル
<Service>
<Method>createTicket</Method>
<WebServiceEndpoint>
<![CDATA[http://[midtier_server]/arsys/services/ARService?server=[servername]&webService=HPD_IncidentInterface_Create_WS]]>
</WebServiceEndpoint>
</Service>
<Service>
<Method>updateTicket</Method>
<WebServiceEndpoint>
<![CDATA[http://[midtier_server]/arsys/services/ARService?server=[servername]&webService=HPD_IncidentInterface_Custom_WS]]>
</WebServiceEndpoint>
</Service>
<Service>
<Method>getTicket</Method>
<WebServiceEndpoint>
<![CDATA[http://[midtier_server]/arsys/services/ARService?server=[servername]&webService=HPD_IncidentInterface_Custom_WS]]>
</WebServiceEndpoint>
</Service>
このセクションでは、前の章で作成されたすべてのテンプレートを定義します。表1-11に、セクションのフィールドの一覧を示し、各フィールドの説明を示します。
表1-11 テンプレート登録フィールド
| セクション/フィールド | 必須 | 説明 | |
|---|---|---|---|
TemplateRegistration |
はい |
このセクションでは、最大50のコネクタ・テンプレートを定義します。 「必要なテンプレート・ファイルの開発」で作成した各テンプレートは、ここで定義する必要があります。 |
|
FileName |
はい |
テンプレートを定義するファイルの名前。 |
|
InternalName |
はい |
内部テンプレート名。 サービス・メソッドに関連付けられているテンプレートの場合は、次のサービス・メソッド名のいずれかに設定する必要があります。大/小文字が区別されるため、サービス・メソッド名と一致する必要があります。 getTicket createTicket publishTicket デフォルト・テンプレートの場合、このフィールドは、次の制限に準拠している一意の名前に設定できます。
|
|
TemplateName |
はい |
このテンプレートを参照するときにUIで使用する名前。 |
|
TemplateType |
はい |
テンプレートには、次の2つのタイプがあります。1つはアウトバウンド、もう1つはインバウンドです。アウトバウンドでは外部Webサービスに送信されるXMLが生成され、インバウンドでは受信したXMLがEnterprise Managerで想定されている形式に変換されます。 アウトバウンドは、常に操作のリクエスト部分に関連付けられます。 インバウンドは、操作のレスポンスまたはリクエスト部分に関連付けることができます。 Enterprise Managerで生成されたリクエストの場合は、リクエストへのレスポンスを処理するためにインバウンド・テンプレートが使用されます。 Enterprise Managerの外部で作成されたリクエストの場合、インバウンド・テンプレートはリクエストとして登録されます。リクエストとして登録される唯一のインバウンド・テンプレートは、publishTicket操作です。 テンプレート・タイプに指定可能な値は次のとおりです。 InboundXSL OutboundXSL OutboundXML |
|
Description |
はい |
UIに表示されるテンプレートの説明。 |
|
例1-17は、様々なTemplateRegistrationセクションを示しています。
例1-17 テンプレート登録セクションのサンプル
<TemplateRegistration>
<FileName>getTicket_request.xml</FileName>
<InternalName>getTicket</InternalName>
<TemplateName>Get Ticket</TemplateName>
<TemplateType>OutboundXML</TemplateType>
<Description>This is the getTicket request template.</Description>
</TemplateRegistration>
<TemplateRegistration>
<FileName>getTicket_response.xsl</FileName>
<InternalName>getTicket</InternalName>
<TemplateName>Get Ticket</TemplateName>
<TemplateType>InboundXSL</TemplateType>
<Description>This is the getTicket response template.</Description>
</TemplateRegistration>
<TemplateRegistration>
<FileName>createTicket_response.xsl</FileName>
<InternalName>createTicket</InternalName>
<TemplateName>Create Ticket Response</TemplateName>
<TemplateType>InboundXSL</TemplateType>
<Description>This is the create ticket response template. </Description>
</TemplateRegistration>
<TemplateRegistration>
<FileName>templates/Remedy_DefaultCategory_AutoClose.xsl</FileName>
<InternalName>Remedy_DefaultCategory_AutoClose.xsl</InternalName>
<TemplateName>Remedy Default Category Auto Close</TemplateName>
<TemplateType>OutboundXSL</TemplateType>
<Description>This is the Remedy default template with auto close function. </Description>
</TemplateRegistration>
<TemplateRegistration>
<FileName>publishTicket_request.xsl</FileName>
<InternalName>publishTicket</InternalName>
<TemplateName>Publish Ticket Status</TemplateName>
<TemplateType>InboundXSL</TemplateType>
<Description>This is the publishTicket request template. </Description>
</TemplateRegistration>
「チケッティング・コネクタのサンプル」の例A-1は、前述のセクションで示したサンプルを含めた完全なコネクタ・デプロイメント・ファイルを示しています。図1-1は、「チケッティング・コネクタのサンプル」で示したサンプル・コネクタに対して表示されるコネクタ構成ページの例を示しています。このイメージには、デプロイメント・ファイル内でフィールドが定義された場所を示すラベルが付けられています。
図1-1 完全なコネクタ・デプロイメント・ページ
Enterprise Managerでは、自己更新機能を使用してコネクタをデプロイします。この機能はコンソールからアクセスできますが、Enterprise Manager環境にコネクタをインポートするための機能です。
コネクタをデプロイする手順は、次のとおりです。
コネクタjarファイルを準備します。
XMLおよびXSLTテンプレート・ファイルをすべて1つの.jarファイルとしてパッケージします。
<name>_connector.jar ---> connectorDeploy.xml --->template1.xml --->template2.xsl ….. ….. --->templateN.xsl
マニフェスト・ファイルを作成します。
SelfUpdateManifest.xsdスキーマ・ファイルは、マニフェスト・ファイルの形式を定義します。
SelfUpdateManifest.xsdスキーマ・ファイルの場所は、「スキーマ・ファイルの抽出」の項の表1-2を参照してください。
自己更新マニフェスト・ファイルのキー属性は次のとおりです。:
EntityType
値はcore_connectorです。
EntityTypeVersion
現行リリース・バージョンです。値は12.1.0.1.0です。
Version
コネクタのバージョン番号です。この値は、connectorDeploy.xmlファイルのManagementConnector/Versionノードに指定されている値に設定する必要があります。
Attribute @Name=connector_type
コネクタ・タイプ名です。この値は、connectorDeploy.xmlファイルのManagementConnector/Nameノードに指定されている値に設定する必要があります。
Attribute @Name=connector_category
カテゴリ・タイプは、TicketingConnectorまたはEventConnectorです。
ArchiveList
この要素には、コネクタ設定の一部であるアーカイブのリストが含まれます。一般に、コネクタjarは1つ存在しますが、特殊な実装の場合は追加のjar (アダプタまたはエージェント)が存在することがあります。このような場合、コネクタ固有のjarは定義リストの最初のjarである必要があります。これは必須要件です。
例1-18は、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"]
表1-12に、ユーティリティで使用可能なオプションを示します。
表1-12 自己更新ユーティリティのオプション
| オプション | 説明 |
|---|---|
|
更新が記述されている自己更新マニフェスト・ファイル。 |
|
マニフェスト・ファイルに指定されているアーカイブ・ファイルがあるディレクトリ。 |
|
自己更新アーカイブのディレクトリまたはファイル名。ディレクトリが指定されている場合、ファイル名は自動生成されます。 |
|
更新タイプxmlへのオプション・パス。 |
次の例では、マニフェスト・ファイル/u01/connector/connector_manifest.xmlに基づいて自己更新アーカイブを/u01/sarディレクトリに作成しています。connector_manifest.xmlで参照されるアーカイブは、ディレクトリ/u01/connector/archivesから取得されます。
edkutil prepare_update
-manifest /u01/connector/connector1_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にインポートされます。正常にインポートされると、更新が次のアクションを促す「ダウンロード」ステータスで自己更新ホームに表示されます。
表1-13に、このコマンドで使用可能なオプションを示します。
表1-13 コネクタ・アーカイブ・コマンドのオプション
| オプション | 説明 |
|---|---|
|
更新アーカイブ・ファイルの完全パス名 |
|
ファイルがOMSからアクセス可能であることを示すフラグ |
|
ファイルが使用可能なホスト・ターゲットのターゲット名 |
|
ホスト・ターゲットのリポジトリに格納されている優先資格証明のセット名。次のいずれかです。
|
|
リポジトリに格納されている名前付き資格証明の名前。このオプションは、-credential_ownerオプションとともに指定する必要があります。 |
|
リポジトリに格納されている名前付き資格証明の所有者。このオプションは、-credential_nameオプションとともに指定する必要があります。 |
emcliコマンドの使用例をいくつか次に示します。
例1
ファイルsample_connector.zipをインポートします。このファイルはOMSホストに存在する必要があります。複数のOMSが設定されている場合、リクエストは、どのOMSでも処理できます。そのため、ファイルは、リクエストを処理するOMSからアクセス可能である必要があります。通常、これは、すべてのOMSからアクセス可能な共有の場所にファイルを保存しておく必要があることを意味します。
emcli import_update -file=\ /u01/sar/sample_connector.zip -omslocal
例2
host1.example.comホストに存在するファイルsample_connector.zip.zipをインポートします。ホストは、Enterprise Managerの管理対象ホスト・ターゲットであり、このホストのエージェントは起動し実行中である必要があります。リモート・ファイルの取得には、ホストhost1.example.comの非特権優先資格証明が使用されます。
emcli import_update -file=\ /u01/sar/sample_connector.zip -host=\ host1.example.com\ -credential_set_name=\ HostCredsNormal\
例3
host1.example.comホストに存在するファイルsample_connector.zipをインポートします。ホストは、Enterprise Managerの管理対象ホスト・ターゲットであり、このホストのエージェントは起動し実行中である必要があります。リモート・ファイルの取得には、ユーザー\admin1\が所有する名前付き資格証明\host1_creds\が使用されます。
emcli import_update -file=\ /u01/sar/sample_connector.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>
例1-18 マニフェスト・ファイルのサンプル
<?xml version="1.0" encoding="UTF-8" ?>
<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[BMC Remedy 7.6.04 Service Desk Connector - 12.1.0.2.0]]></Description>
<AttributeList>
<Version>12.1.0.2.0</Version>
<Attribute Name="connector_type" Value="Remedy Service Desk 7.6 Connector" Label="Remedy Service Desk 7.6 Connector" />
<Attribute Name="connector_category" Value="TicketingConnector" Label="Ticketing Connector" />
</AttributeList>
<Readme><![CDATA[
Oracle Management Connector for Remedy Service Desk integrates Oracle Enterprise Manager Cloud Control's proactive alert detection and resolution features with BMC's Remedy 7.6.04 Service Desk capabilities to provide a seamless workflow for incident management and resolution.
Remedy Service Desk 7.6 Connector works with BMC Remedy ITSM 7.6.04 Incident Management Application.
Change Logs:
12.1.0.2.0
- Initial Release
]]></Readme>
<DependsOn>
</DependsOn>
<ArchiveList>
<Archive Filename="remedy_service_desk_connector_7_6.jar" Size="11406" ChecksumType="SHA1" ChecksumValue="e168c00d1f2bac7868034cb4ecacd100afae4651" IsMDS="false" />
<Archive Filename="HPD_IncidentInterface_Custom_WS.xml" Size="215299" ChecksumType="SHA1" ChecksumValue="ba20a8aa526e566da3c456630a866980342c874e" IsMDS="false" />
</ArchiveList>
<CustomData><![CDATA[]]></CustomData>
</EntityInstance>
