この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
• 「概要」
Catalog Deployer はコンテンツ展開および構成管理のツールで、サービス設計者、カタログ パブリッシャ、組織ビルディング リソースが使用して、開発、テスト、実稼働の各サイト間でアプリケーション エンティティを移行できます。
Catalog Deployer は変更管理プロセスと履歴をカスタマーに提供して、Request Center および Demand Center のコンテンツ変更や、Service Portal のすべてのモジュールによって使用される組織エンティティの変更に対する信頼性の高い制御を可能にします。
Catalog Deployer では、シスコによりブランド化コンテンツ ライブラリ内にパッケージされた事前設定サービスの展開もサポートされています。このようなサービスはそのまま使用することも、組織の要件に合わせてサービス定義をカスタマイズするためのテンプレートとして使用して、アクション可能なサービス カタログを実装するために必要な時間と労力を大幅に減らすこともできます。
Catalog Deployer には 2 つのコンテンツ展開方法が用意されています。ソース サイトは Catalog Deployer を使用して、ターゲット サイトへの送信やそこでの展開用にサービス定義やエンティティのパッケージを「抽出」したり組み立てたりできます。この場合、すべてのオペレーションを Catalog Deployer モジュール内で実行でき、外部プログラムは不要です。代わりに、または追加で、パッケージをエクスポート用に生成できます。エクスポートされたファイルは、Catalog Deployer 経由でターゲット サイトの Service Portal のインスタンスにインポートされます。これらはテキスト形式の XML ファイルであるため、構成管理システムまたはソース コード管理システムに格納できます。ブランド化コンテンツ ライブラリはエクスポート ファイルの形で配布されるため、標準的な Catalog Deployer 機能を使用して、ライブラリで使用可能なサービスをインポートしたり展開したりできます。
他のすべての Service Portal モジュールと同様に、Catalog Deployer は使用のための権限を付与できます。ユーザは展開履歴の表示、展開用のパッケージの組み立て、特定サイトへのパッケージのインポートまたは展開を行うことができ、またユーザの責任に最も合うように、これらの機能を組み合わせて実行することができます。このような機能はすべて標準ロールまたはカスタム ロールによって割り当てることができます。
• ユーザ インターフェイスによる使用が簡単。展開用のパッケージを作成し、そこにデータを取り込み、ターゲット サイトに送信したり、ファイル システムにエクスポートしたりできます。
• 2 つのコンテンツ転送方法。サイト間の XML パッケージ送信またはエクスポート/インポート機能によるファイルベース送信。
• 1 つ以上のターゲット サイトにおけるサービスと提供サービスの展開(関連エンティティを含む)。
• ターゲット サイトにおける組織展開(OU、グループ、キュー、ロール、人、役職)。
• ターゲット サイトにおける電子メール テンプレートおよび Service Link エージェントの展開。
• 変更管理サポート(コンテンツ開発者/管理者およびカタログ パブリッシャ間の責務の分離が選択可能)。
• ホット展開:このアプリケーションをユーザが使用可能なときにコンテンツを展開可能。
• ブランド化コンテンツ ライブラリからターゲット サイトへ展開する前に、サービス定義または提供サービスのプレビューが可能。
Catalog Deployer は、サービス カタログまたはポートフォリオの実装作業の最初に使用して、テンプレート コンテンツを提供し、カスタマイズされたサービス カタログまたはポートフォリオの基礎を形成できます。また、Catalog Deployer は開発作業のビルドおよびメンテナンスの段階で使用して、テスト済みコンテンツを開発から他の環境にプロモートしたり、複数の環境を同期させたりもできます。
この章の次の項では、リリースおよび構成管理ための Catalog Deployer の使用に関連する機能を説明します。
この章の次の項では、シスコ コンテンツ ライブラリをインストールしてサービス カタログやサービス ポートフォリオの基礎を提供するための Catalog Deployer の使用に関連する機能を説明します。
• 「Catalog Deployer の実行」(コンテンツのインポートおよび展開に関する項のみ)
この章で使用する主要な用語は次の 表 5-1 に定義されています。
|
|
Service Portal と関連するすべてのモジュール(Catalog Deployer を含む)をインストールするのに必要な要件および前提条件を説明します。 |
この項では、Service Portal の実装方法と、業界標準の構成(または変更)管理プラクティスをサポートする関連プロセスの設計方法を説明します。
一般的な方法を確認し、Catalog Deployer 構成管理を含む Service Portal アプリケーションに使用可能な方法と比較します。初期開発からテスト、展開、およびメンテナンスまで、展開の段階に一致した、構成管理に対するさまざまなアプローチを説明します。
Catalog Deployer は、IT 業界標準の構成管理方法およびテクノロジーが取り入れているベスト プラクティスを実装します。したがって、これらのプラクティスを確認することは役立ちます。
• ソフトウェア設定項目(つまり、IT アプリケーションを構成する個々のソフトウェア モジュールまたはコンポーネント)に対する変更は開発環境で行われます。
• 同じ(開発)環境において、変更されたソフトウェアは一般に予備テスト(単体テスト)を受けます。
• 単体テストにソフトウェアが合格すると、ソフトウェアの「ソース」のコピーがソース コード管理システムにチェックインされ、リリース候補のラベルが付けられます。「ソース」は、テキスト エディタで作成されて保守されるコードを含む、複数のタイプのアーティファクトで構成される場合や、あるいは、ますます一般的になりつつあるものとして、統合開発環境の一部になっているメタデータ リポジトリ内に、または XML ファイルに格納された仕様で構成される場合があります。
• 保存されたソースは、厳重に制御されたテスト環境に展開され、そこで厳しいテストが行われます。このテスト環境は、異なる実行での結果を比較できるように、テスト セットそれぞれの前に再初期化される場合があります。
• テスト実行者は、問題を見つける責任はありますが、それを診断または修正する責任はありません。すべての問題は開発チームに報告され、そこで開発環境を使用して問題の修正、コードの再実行、および改訂されたソースのコピーの保存を行います。
• 修正、抽出、展開、テストの各ステップは、ソフトウェアがすべてのテスト条件(これらはパフォーマンス対策または機能要件またはその組み合わせの場合があります)を満たすことをテスト チームが認定するまで繰り返されます。
Request Center などの Service Portal アプリケーションでは、開発されるソフトウェアは一般に、カテゴリ、グループ、タスク、およびチェックリストなどの関連要素を含むサービス定義です。一般的な構成管理シナリオおよびここで Catalog Deployer が果たす役割は次のようになります。
• 新規のサービス定義または拡張されたサービス定義を開発環境で開発して単体テストを行います。
• Catalog Deployer を使用して、開発環境から新規のサービス定義または更新されたサービス定義を抽出します。結果の展開パッケージは、必要ならば、エクスポートしてソース コードの制御下に置く場合があります。
• Service Portal データベースにない他のコード リソース(JavaScript ライブラリなど)もソース コードの制御下に置く場合があります。
• Catalog Deployer を使用して、テスト環境または品質管理(QA)環境にサービス定義を展開します。
• サービスをテストします。問題が見つかった場合は、サービスが指定要件を満たしたものと認定されるまで、前のステップを繰り返します。つまり、開発でコードを修正して、抽出し、テスト環境に再展開します。
• テスト環境で受け入れられると、サービスは、コードをテスト環境に最初に展開した同じ手順に従って実稼働環境に展開されます。
このシナリオは、開発環境だけがサービス定義に変更を加えられる場所である点、および自動化プロセスを使用してソース コードの制御セットをテスト環境および実稼働環境に展開する点で業界標準に従っています。
ただし、このシナリオは不完全です。ほとんどの実装において、人と事業部(一種の組織)は、Request Center または Demand Center に初めてログインするとき、自分のためにサービスをオーダーしたとき、あるいは承認または確認を実行するために割り当てられたときに、動的に実稼働環境に追加されます。したがって、Catalog Deployer は、これらのエンティティを実稼働サイトから開発に戻す移行のときも使用しなければなりません。それにより、まだ開発中のサービス定義または他の Request Center 設定項目(たとえば、承認)でそれらのエンティティを使用できます。さらに、サービス定義は電子メール テンプレート、グループ、キュー、サービス チーム組織、およびロールなどの関連エンティティを参照する場合があります。これらのエンティティのいずれかがターゲット環境に存在しなければ、サービスの展開パッケージを正常に展開できるように、その前にターゲット環境にエンティティを展開する必要があります。
Catalog Deployer は、上記のシナリオで説明したように、Request Center の顧客がサービス定義などのコンテンツを展開するため、および Demand Center の顧客が提供サービスと関連サービスを展開するための両方に使用できます。
Catalog Deployer には、アプリケーションにある論理エンティティに基づいて編成された、データベース中立のデータ転送インフラストラクチャおよびインターフェイスがあります。論理エンティティの例として、サービス定義、データ ディクショナリ、人および組織単位があります。完全なリストは、この項の最後にあります。ただし、異なるデータベースやアプリケーション環境間のカスタム コンテンツのサポートは制限されています。Catalog Deployer でサポートされないエンティティのリストについては、「Catalog Deployer が行わないこと」を参照してください。
実装、サイト、およびエンティティ ホームについては、表 5-1に説明があり、これらは Catalog Deployer のオペレーションに不可欠です。
特に、論理エンティティのホーム サイトは Catalog Deployer での構成管理に欠かせない部分です。Catalog Deployer ではオプションですが、論理エンティティに対してホーム サイトのシステムを作成することによって、サイト間の論理エンティティの参照整合性と、サイト間の設定情報の整合性の両方の管理が可能になります。
論理エンティティのホーム サイトの背後にある考え方は、他のサイトよりも特定のサイトに、論理エンティティ タイプに対しより権威のあるバージョンのデータを持たせることにあります。たとえば、LDAP ディレクトリを使用して認証を行いユーザに関する情報を収集するカスタマーの場合は、人および組織単位のデータが実稼働で最も正確になります。したがって、実稼働サイトは人および組織単位のホーム サイト、つまり正式サイトになります。実稼働以外のサイトで人を作成した場合、または組織単位を編集した場合、このデータを他のシステムに展開すると、マスター情報と同期しなくなり、実装全体でのデータの品質が低下します。
これらの問題を考慮して、アプリケーション フレームワークは、エンティティのホーム サイト以外のサイトでユーザがこれらのエンティティを修正することがないように、保護レベルを論理エンティティに割り当てるように設計されています。サイト管理者は、「Catalog Deployer の設定」に説明されているように、4 つの設定から 1 つを選択することにより、論理エンティティに提供する保護のレベルを選択できます。
Catalog Deployer はエンティティの一部としてエンティティの権限を展開します。権限がそのホーム サイトのエンティティから除去された場合、このアプリケーションは、Catalog Deployer がこの除去の複製のために使用できる削除スタブ(またはトランザクション ログ)を残しません。たとえば、サービスをオーダーする権限がサービス定義の組織単位から除去されたとき、Service Portal はこの事実を保持せず、権限を除去するだけです。
権限が変更されたサービスを展開すると、サービス定義およびその権限の間にあるすべての関連付けがターゲット サイトで削除され、ソース サイトで有効な権限に従って再作成されます。削除された権限はすべて反映されます。ただし、カスタム ロールまたはグループに権限が付与され、ソース サイトからそのロールまたはグループが削除された場合、そのロールまたはグループは引き続きターゲット サイトに存在します。Catalog Deployer はエンティティの削除をプロパゲートできません。
Catalog Deployer は、同じバージョンの Service Portal を使用して実装されている 2 サイト間でトランザクション データベースに格納されている論理エンティティを移行します。これらのエンティティは、.xml でフォーマットされたテキスト ストリームに抽出されます。このテキスト ストリームは展開パッケージの一部で、パッケージの作成に使用される仕様(オプション)も含みます。そのパッケージは、バックアップ メカニズムとして、および別のサイトのターゲット データベースにエンティティ定義を展開するためのソースとして機能させるために、ソース データベースから抽出できます。エンティティ定義は元のままターゲット環境に展開されます。
Catalog Deployer は論理エンティティ以外の Service Portal のいずれのコンポーネントにも影響しません。これらのコンポーネントのいくつかに対する変更は、Service Link によって処理される構成管理シナリオ(カスタマーが設計および構成した設定項目の実装間での同期)の一部でないため、これ以上ここでは検討する必要がありません。次に例を示します。
• ソフトウェア コンポーネントは Service Portal インストーラでインストールして設定する必要があります。
• データ マートおよびレポーティング テーブルのコンテンツは Service Portal インストーラで作成して Extract-Transform-Load(ETL)プロセスで入力する必要があります。
• スキーマは Service Portal のインストールの一部としてアップグレードされます。
• カスタマイズされたすべての Service Portal コンポーネント、または追加コンポーネントは Service Portal インストーラの [Customizations] オプションにより、『 Cisco Service Portal Configuration Guide 』に記載されている手順ですべてのサーバにインストールする必要があります。このようなカスタマイズには一般に、Advanced Services 組織によって提供される API や、ディレクトリ統合で使用されるカスタム マッピングのサポートが含まれます。
ただし、追加の設定項目は、Catalog Deployer によって処理される論理エンティティに対する変更と組み合わせて展開しなければならない場合があります。これらの要約を次の表に示し、影響を受ける論理エンティティと組み合わせてさらに詳細に説明します。
|
|
外部ディクショナリ、SQL ベース オプション リストまたはデータ取得ルールで参照されるテーブルを参照するためのデータ ソース仕様 |
|
(注) 現行バージョンの Catalog Deployer は、初期展開以後にそのソース サイトで名前変更されたエンティティの再展開をサポートしていません。エンティティの名前変更のガイドラインについては、「Service Portal のアップグレード後のエンティティの名前変更」を参照してください。
次の表は、Catalog Deployer によってサポートされているすべての論理エンティティと、それらに関連付けられたアプリケーション モジュールの一覧を示したものです。
|
|
サービス定義(オファー、フォーム、フォーム セクション、計画、承認、権限) サービス定義で自動的に展開される次のコンポーネント エンティティ • アクティブ フォーム コンポーネントおよびコンポーネント グループ |
|
サービス定義で自動的に展開される次のコンポーネント エンティティ |
|
提供サービス(原価作用因、事業目標、事業の構想および過程、分類) |
|
Catalog Deployer は、上記のエンティティをソース サイトのデータベースからターゲット サイトのデータベースにコピーします。Catalog Deployer は、ファイル システムに格納されている情報の移動、コピーは行いません。Catalog Deployer は、JavaScript 関数に関連付けられたライブラリの定義をコピーします。
(注) Catalog Deployer は、.bmp 形式のイメージ(プレゼンテーション要素)の展開をサポートしていません。Service Designer は現在、このようなイメージの指定ができないようになっています。従来のイメージはすべて、Web でのプレゼンテーション用に最適化された代替形式、たとえば、.jpg または .gif に変換してください。
Catalog Deployer の設定は次の作業からなります。
• Service Portal をインストールするための前提条件および Catalog Deployer をサポートするようにクライアント ワークステーションを設定するための前提条件を満たすこと。
• Catalog Deployer を含む Service Portal バージョンをインストールすること。
• 開発および実稼働の Service Portal インスタンス内で実装およびサイトを設定すること。
• ColdFusion のデータ ソースをソース サイトおよびターゲット サイトに設定すること。
• Administration モジュールおよび Organization Designer モジュールを使用して、実装での働きに適した Catalog Deployer 機能に担当者がアクセスできるようにすること。
Service Portal の前提条件については、『 Cisco Service Portal Installation Guide 』を参照してください。
Catalog Deployer はすべての Service Portal サイトの一部として自動的にインストールされます。
すべてのサイトに Service Pack を含み同じバージョンの Service Portal がインストールされている必要があります。
Catalog Deployer によって生成される展開パッケージは、含まれるエンティティの圧縮された XML 表現を含みます。Catalog Deployer はパッケージのファイルベース送信を使用します。その中で、パッケージ コンテンツは、パッケージのエクスポートおよびターゲット サイトへの以降のインポートにより、あるサイトから別のサイトへ転送されます。このモードの送信をサポートするには、次に示されているように([Internet Options] の [Advanced] の [Security] セクション)、暗号化ページをディスクへ保存できるようにユーザのブラウザを設定する必要があります。
Catalog Deployer を使用する前に、開発インスタンスおよび実稼働インスタンスを使用して実装を設定する必要があります。実装とは、Catalog Deployer が Request Center サービス定義および他の Service Portal エンティティをその間で移行するサイトの集合です。
実装に名前を割り当てます。この名前は一般に会社やプロジェクトを表します。この名前はマニュアル記載のみを目的とし、Catalog Deployer によって使用されることはありません。
実装内で、各サイトは固有の名前を持たなければなりません。Service Portal は、エンティティの変更(追加、修正、削除)をユーザに許可する保護レベルを Service Designer および Organization Designer のページに割り当てるために、この固有の名前を使用してサイトを識別します。
一般に開発(DEV)および実稼働(PROD)の 2 つのサイトが必要です。たとえば、STAGE、TEST、または QA などの追加サイトは、構成管理および移行の計画でこれらの使用が要求されたときに使用される場合があります。
各論理エンティティに(単一の)ホーム サイトを指定します。論理エンティティのホーム サイトに関して決定を行う際は、以下のようないくつかの経験則が役立ちます。
• 論理エンティティのホームは、一般に、1 つのサイトのみにすべきです。こうすると、エンティティ インスタンスに対する変更の管理がしやくすなります。
• サービスまたは提供サービスの定義に関係する論理エンティティのホームは、明らかに開発インスタンスにすべきです。
• システムの実稼働使用によって作成されるエンティティのホームは、実稼働サイトにすべきです。Import Person イベントを含むシングル サインオン(SSO)またはディレクトリ統合が有効な場合、実稼働の論理エンティティ ホームは人を含みます(したがって、同じテーブルにあるキューも含みます)。自動化されたユーザ作成機能によって組織単位が作成される場合は、組織単位のホームも実稼働サイトにすべきです。
(注) 論理エンティティのホームがテスト サイトまたはステージング サイトになることはほぼありません。その理由は、一般に、このようなサイトは実稼働データや新しく開発したテスト対象コードで再構築されるためです。
Catalog Deployer がコンテンツをサイトへ展開するためには、ColdFusion データ ソースをそのサイト用に設定する必要があります。たとえば、開発サイトで開発したサービスをテストおよび実稼働に展開するには、開発サイトは実稼働サイトおよびテスト サイトの両方のデータ ソースを含んでいなければなりません。実稼働サイトから開発に組織エンティティを展開するには、実稼働インスタンスは開発インスタンスのデータ ソースを含んでいなければなりません。
実装、サイト、および論理エンティティを指定するデータは、順に論理エンティティ内に格納されます。
Catalog Deployer を使い始めるには、Administration モジュールで実装環境の設定を行う必要があります。Administration で設定する値によって、サイトはターゲット サイトを認識できるようになります。
ここに示すステップは、ColdFusion 管理でデータ ソースの定義を行う前または後で実行できます。
ステップ 1 Administration 特権を持ったユーザとして開発インスタンスにログインします。
ステップ 2 次に示すように、[Module] ドロップダウン メニューで [Administration] を選択します。
右側のメニューを使用して、次に示すように、[Entity Homes] を選択します。
次に示すような、論理エンティティのホーム指定ページが表示されます。
これらの設定は、Catalog Deployer と Service Designer モジュールおよび Organization Designer モジュールの動作に影響します。設定が正しくないと、間違ったデータが実稼働を含む Service Portal アプリケーション サイトに書き込まれる可能性があります。このような設定の変更はシステム管理者のみが行ってください。
ステップ 4 ページ下部の [Implementation Sites] セクションの下にあるテキスト フィールドに 実装名 を入力して、[Add New] をクリックします。その名前がサイト名のリストに追加されます。
(注) 各サイトに指定した名前は、ColdFusion Administrator で対応するデータ ソースに割り当てられている名前と正確に一致する必要があります。名前では大文字と小文字が区別されます。
ステップ 5 実稼働サイトの名前を別のサイトとして追加します。
ステップ 6 QA または Test など、Catalog Deployer でリフレッシュする必要のある他のサイトがインスタンスに含まれる場合は、これらも追加します。
ステップ 7 [This Site is] ドロップダウン メニューで開発サイトを選択し、現行インスタンスを識別します。
ステップ 9 エンティティの [Home Site] の割り当てを確認し、要件に合わないものがあれば変更します。完了したら、[Update] をクリックします。
ステップ 10 定義した各サイトに適切な [Site Protection Level] を割り当てます。これらの保護レベルは、対応する論理エンティティの保守を行う Service Designer、Organization Designer、および Administration のページの動作を変更します。
|
|
同じサイト名、エンティティ ホーム設定、および保護レベルを実装のすべてのサイトに指定してください。これは、ユーザがエンティティを誤って間違ったサイト(そこでは、エンティティが「同じ」エンティティの次の展開によって上書きされ、異なるサイトで開発および保守される可能性があります)で作成または修正することを防止します。
開発 。保護レベル [none] は、実装の初期段階の開発サイトでのみ使用すべきです。この場合、適切なロールを持つユーザがサイト内ですべてのエンティティを作成、修正、削除できます。
テスト 。保護レベル [Create, Modify, Delete] は、一般にすべてのテスト、ステージング、または QA サイトに適用すべきです。これらのサイトは、通常、完全なデータベースを(たとえば、パフォーマンス テストまたはボリューム テストをサポートするために)実稼働からコピーすることによって、あるいは実稼働へのプロモーションの前に機能テストのために開発からサービスを展開することによってリフレッシュされます。
実稼働 。保護レベル [Create, Modify, Delete] は、一般に実稼働サイトに適用すべきです。保護レベル [Create only] では、エンティティ名の変更などのマイナー修正を保護エンティティに適用できます。
Catalog Deployer がパッケージを別のサイトへ送信するためには、そのサイト用の ColdFusion データ ソースを設定する必要があります。
(注) 次に示すステップは、Service Portal インストーラの実行のたびにやり直す必要があります。インストーラによって毎回すべての ColdFusion 設定が上書きされるためです。
ステップ 1 次のようにして、ColdFusion Administrator のページにナビゲートします。
Server Name>/RequestCenter/CFIDE/administrator/index.cfm
ステップ 3 [Data & Services] 見出しの下、左側にある [Data Sources] リンクをクリックします。
ステップ 4 データベース タイプとドライバおよび接続情報を指定することにより、データ ソースを追加してターゲット サイト用にそのデータ ソースを設定します。
データ ソースに割り当てる名前はメモしておいてください。この名前は、サイト定義時に Administration モジュールで、ここに表示されるように正確に再入力する必要があります。
ステップ 5 ターゲット サイトが非ラテン文字セットを使用する場合は、[Show Advanced Settings] をクリックし、[String Format] のチェックボックスをオンにしてデータ ソースの Unicode を有効にします。
ステップ 7 ターゲット サイトを正しく設定した場合、[datasource updated successfully] というメッセージを受け取ります。
ステップ 8 ColdFusion の管理ページからログアウトします。
上のステップでは、1 つのサイトの設定を案内しましたが、一般的には開発サイトから始めます。開発サイトは、ソース サイトに表示可能な、他のターゲット サイトへ移行する予定のサービス定義のソース サイトになります。全体的な実装の設定に応じて、いずれのサイトも、ソース サイトまたはターゲット サイトとして、あるいは場合によってはその両方として設定できます。
たとえば、テスト サイトおよび実稼働サイトを表示するように開発サイトを設定し、開発サイトおよびテスト サイトを表示するように実稼働サイトを設定する場合があります。このシナリオでは、テストが正常に行われたと仮定して、開発からテストへ、次に開発から実稼働へエンティティを展開します。実稼働からテスト サイトおよび開発サイトの両方に組織情報を移行します。
必要なデータ ソースの定義を含み、すべてのソース サイトで潜在的なターゲット サイトの設定を繰り返します。設定が正常であることを確認するには、各サイトでログインし、Catalog Deployer にナビゲートし、設定したターゲット サイトの 1 つにパッケージの送信を試みます。そのターゲット サイトが選択可能なターゲット サイトの 1 つとして、ドロップダウン リストに表示されるはずです。
(注) 設定したターゲット サイトの名前が ColdFusion のデータ ソースの名前と一致しない場合、または ColdFusion の設定が正しくない場合、ターゲット サイト名は赤で強調表示され、そのサイトへ送信できなくなります。
Service Portal では、Configuration Management ツールを使用するために Service Designer、Configuration Manager、Catalog Publisher、および Organization Builder が必要になります。これらの主要なロールは次のように定義されています。
次の表は、Catalog Deployer モジュールに関して、システム定義のロールおよび各ロールに付与されるデフォルト機能を説明したものです。
Catalog Publisher ロールおよび Licensed Content Publisher ロールは、Catalog Deployer モジュールに固有です。Catalog Publisher ロールによって、ユーザはアプリケーション サイト間で Service Catalog およびその他の組織変更の展開を管理したり、またシスコ提供コンテンツ ライブラリをパブリッシュしたりできるようになります。Licensed Content Publisher ロールは「ブランド化コンテンツ ライブラリをパッケージする」機能を含み、シスコのみの使用に予約されています。
Catalog Deployer は、ソース サイトまたはターゲット サイトがオンラインで使用中の場合に実行しなければなりません。ただし、この使用法にはいくつかの制限を適用するようにしてください。
Catalog Deployer は、パッケージの組み立てとインポートに大量のメモリを消費します。メモリ消費から生じる問題を避けるために、Catalog Deployer では、3 人以上のユーザが同時にパッケージの組み立てまたはインポートを行うことができないようになっています。 3 人目のユーザがパッケージの組み立てまたはインポートを行おうとすると、Catalog Deployer からその旨のアラートが表示され、後で再試行するようにユーザに知らせます。単独の人が実稼働の展開を処理することが多いため、実稼働環境では、このような状況は起きにくいシナリオですが、複数のサービス設計者がそれぞれのコンテンツを展開用にパッケージしている場合に、開発環境またはテスト環境で起きる可能性は十分にあります。
原則として、Catalog Deployer は 1 回のデータベース トランザクションで完全なパッケージを展開できます。このようなケースにおいて、いずれか 1 つのコンポーネントの展開に失敗すると(たとえば、指定されたキューがターゲットに存在しないため、基本パッケージのサービス定義を展開できないと)、結果として、パッケージのコンテンツ全体がロール バックされます。ターゲット サイトのリポジトリは、展開を開始する前の状態のままになります。
ただし、実際には、この展開方式(すべて行うか何も行わないか)が問題の原因になる場合があります。エンティティがいったん展開されると、完全なパッケージが展開されてデータベース トランザクションがコミットされるまで、オンライン ユーザはそのエンティティを使用できません。この時間枠中に、継続的な展開によって更新されたサービスをユーザがオーダーしようとすると、そのユーザ セッションはハングして、サービス定義が使用可能になるまで待機します。最終的に、ユーザは(最悪のケースでは)エラーを受け取るか、または遅延した後で、(最善のケースでは)サービスをオーダー可能になります(このエラーは、タスクの実行者または承認者がこのサービスを操作しているときではなく、ユーザが最初にサービスをオーダーしているときにのみ発生します)。
このシナリオを回避する確実な方法の 1 つは、実稼働システムの使用中に展開を許可しないことです。これは、定期スケジュール メンテナンス時間に実稼働システムに対して更新を実行するという業界認定のベスト プラクティスに従います。
ただし、メンテナンス時間になるまで展開を待機することは不可能な場合があります。Service Portal が動作可能なときに展開を実行しなければならないときに問題が発生する確率を最小限に抑えるために、Catalog Deployer では 3 つのパラメータをサポートして、トランザクションごとに処理する必要のあるプライマリ エンティティの数を制御しています。これらのパラメータのデフォルト値を次に示します。
|
|
基本パッケージまたは拡張パッケージでは、5 つのサービス(およびそのコンポーネント エンティティ)が単一のデータベース トランザクションで展開されます。カスタム パッケージでは、10 個のエンティティが展開されます(パッケージに含まれるエンティティのタイプは問いません)。
デフォルト値は、更新するパラメータに対応する CnfParams テーブルの行の作成または更新をデータベース管理者に依頼することによって上書きできます。テーブルの行は、名前と値のペアからなり、名前は値を変更する予定のパラメータを識別します。この変更は、展開パッケージを組み立てる前に、ソース データベースで行う必要があります。
これらの値を小さくして例外がユーザに起きる可能性を下げる場合は、次の注意事項を検討することが重要です。
• パッケージに複数のバッチ(バッチ サイズによって定義されます)が含まれる場合、単一のエラーが、展開パッケージ全体のロール バックの原因になることはありません。エラーが発生したときに展開対象のバッチのみがロール バックされます。
• Catalog Deployer は、エンティティが複数のプライマリ エンティティに必要な場合に、関連付けられたエンティティをバッチ内で 1 回作成/更新するだけです。たとえば、展開パッケージ内の 20 のサービスにディクショナリ「IT Software Configuration」が必要な場合、Catalog Deployer はそのディクショナリをターゲット サイトで 1 回作成/更新するだけです。ただし、展開パッケージがバッチに分かれている場合、Catalog Deployer は関連付けられたエンティティをバッチごとに 1 回作成/更新します。これは、パッケージに含まれる共有コンポーネントの数と複雑さと、Catalog Deployer が実行しなければならない冗長な作成/更新の数によっては、パフォーマンスに影響する場合があります。
Catalog Publisher ロールを持つ人が、バッチ サイズ パラメータの値を大きくしてパッケージ全体を 1 回のバッチで展開することを望む場合がありますが、これを行うのは、アプリケーションが使用中でないときのみにしてください。このアプローチは、展開パッケージの部分的なコミットまたはロールバックを減らすのに役立ちます。
パッケージの組み立てと展開に必要な時間およびメモリは、パッケージのサイズによって決まります。
パッケージのサイズは、そこに含まれるプライマリ エンティティの数から単純に得られるものではなく、これはコンポーネント エンティティおよび関連付けられたエンティティの数にも左右されます。ユーザは大きいパッケージ(そのサイズによって定義されます)のパフォーマンスの方が低下する予測できます。また、このようなパッケージの組み立てや展開が時には失敗する場合があることを認識する必要もあります。失敗したときの解決策は、単にパッケージをより小さいプライマリ エンティティ セットに分けることです。たとえば、20 のサービスからなる 1 つのパッケージの代わりに、それぞれが 10 のサービスからなる 2 つのパッケージを作成します。
Administration モジュールの [Settings] タブを使用して、設定可能な値にパッケージ サイズを制限できます。パッケージ サイズのデフォルト(かつ推奨される)最大値は 3000 KB です。同じ最大パッケージ サイズを実装内のすべてのサイトに設定してください。
パッケージを保存すると、Catalog Deployer はパッケージ コンテンツのサイズを見積もります。次に示すように、含まれるすべてのプライマリ エンティティにわたって配布される、パッケージ サイズの明細が表示されます。
見積もられたパッケージ サイズが、指定された制限を超える場合、パッケージを保存するにはエンティティを削除しなければなりません。
アプリケーション サーバで消費されるメモリの量は、最大パッケージ サイズを設定する際の制限要因になります。この設定のデフォルト値は、1 GB メモリが 32 ビット JVM に割り当てられる一般的なインストールをサポートします。そのデフォルト設定からアプリケーション サーバが著しく変動するときは、最大パッケージ サイズを大きくすることが可能な場合があります。ただし、こうした試みは、インストールが異なればメモリ使用量のパターンがさまざまに変わるため、試行錯誤によってはっきりする場合があります。
この項では、Catalog Deployer 機能の概要を説明します。詳細なユーザ ステップについては、Catalog Deployer オンライン ヘルプを参照してください。
基本サービス :基本サービス展開パッケージはサービス定義を移行するためのものです。サービスの作成時の構造を保持するために、すべての内部サービス要素が転送されます。基本パッケージには、初心者ユーザに「安全」と見なされる事前定義の展開オプションがあります。Catalog Deployer が必要な関連付けられたエンティティ(たとえば、キューまたは組織単位)をターゲット サイト上で見つけられなければ、展開は失敗します。基本パッケージに、バンドルされたサービスを含めることはできません。
(注) Service Designer でサービスを表示または編集する権限がなくても、Catalog Deployer で展開用のサービスを表示して選択できます。
拡張サービス :拡張サービス展開パッケージは、バンドルされたサービスを含むサービス定義を移行するためのものです。このパッケージ タイプでは、サービス定義の関連付けられたエンティティをターゲット サイトでの展開時にどのように処理するかをオプションで制御できるようになっています。
基本提供サービス :基本提供サービス展開パッケージは提供サービスを移行するためのものです。サービスの作成時の構造を保持するために、すべての内部サービス要素が転送されます。基本サービス パッケージと同様に、基本提供サービス パッケージは、関連付けられたエンティティがターゲット サイト上で見つからなければ失敗します。
拡張提供サービス :拡張提供サービス展開パッケージは、提供サービスを移行するためのものです。拡張サービス パッケージと同様に、このパッケージ タイプでは、提供サービスの関連付けられたエンティティをターゲット サイトでの展開時にどのように処理するかをオプションで制御できるようになっています。
カスタム :カスタム展開パッケージでは、エンティティを個別に選択し、関連付けられたエンティティを展開時にどのように処理するかをオプションで制御できるようになっています。カスタム展開は一般に、人、OU、およびグループなどの組織エンティティに使用されます。カスタム パッケージに、サービスまたは提供サービスを含めることはできません。
Catalog Deployer は Service Portal の 1 つのモジュールです。これは Catalog Deployer へのアクセスを許可するロールが(「アプリケーション ロールおよび機能」に指定されているように)付与されたすべてのユーザのドロップダウン メニューに表示されます。
Catalog Deployer のホーム ページからは次のすべてのオプションにアクセスできます。
|
|
|
|
|
• 表示/検索ペイン :ユーザは、指定されたステータスを持つすべてのパッケージを表示したり、名前でパッケージを検索、または指定した検索文字列に名前が一致するエンティティを含むパッケージを検索したりできます。
• コンテンツ タブ :表示/検索ペインで現在選択されているパッケージについての情報を表示します。すべてのパッケージに [Summary] タブがあります。他のコンテンツ タブは、パッケージに含めることができるエンティティのタイプによって異なります。
• アクション ボタン :Catalog Deployer のアクションを表示します。使用可能なアクションはパッケージのステータスによって異なります。現在選択されているパッケージに適用できるアクションのみが使用可能になります。
展開パッケージは Catalog Deployer で次のフローに従います。
• 展開パッケージを作成します。Catalog Deployer にアクセスして使用する権限を付与された人は、展開パッケージを作成し、パッケージに含めるエンティティを選択し、パッケージを保存できます。
• パッケージを組み立てます。基盤となるコンテンツが展開準備完了と見なされたときに、[Assemble Package] ボタンをクリックすると、展開パッケージが組み立てられます。この時点で、Catalog Deployer はコンテンツを抽出し、展開パッケージの一部として保存されるコピーを作成します。いったんパッケージの組み立てが行われたら、パッケージに含まれるエンティティに対する変更は、パッケージの再組み立てを行わない限り取り込まれません。
• パッケージを送信します。組み立てられたパッケージが展開用にターゲット サイトに送信されます。パッケージは、Catalog Deployer 経由で送信できます。または、ソース サイトおよびターゲット サイト間に直接接続がなければ、このステップをエクスポートおよびインポート プロセスを使用して「オフライン」で実行する場合があります。
• パッケージを展開します。パッケージを展開する権限を持つ人は、ターゲット サイトで受信パッケージを選択し、展開を実行します。
ログ ファイルに、各サイトの Catalog Deployer 内で発生するすべてのアクティビティが記録されます。
エンティティの追加または削除があるたびに、またはパッケージ定義が修正されるたびに、パッケージを毎回保存することが重要です。
表示/検索ペインのドロップダウン メニューで [New Deployment Package] オプションを選択して新しいパッケージを作成します。
展開パッケージの作成は、パッケージの名前と説明を指定してパッケージのタイプを指定することからなります。
• 名前からユーザがパッケージ コンテンツを推測できるようにするために、パッケージの命名標準を策定してください。たとえば、名前はパッケージのタイプの宛先、ソース サイト、コンテンツの説明、ビルド番号またはパッケージ作成日で構成することができます。
• パッケージの説明は必須です。パッケージの名前と説明は両方ともパッケージを作成した後で修正できます。
• パッケージ タイプはパッケージをいったん作成すると変更できません。
パッケージにはその作成時にステータス [Not Transmitted] が割り当てられます。表示/検索ペインから選択すると、その [Summary] タブのコンテンツが表示されます。追加するエンティティのタイプに対応するコンテンツ タブをクリックしてコンテンツを追加できます。パッケージが送信されるまで、コンテンツはいつでも追加および削除できます。パッケージを組み立てた後でコンテンツを変更した場合は、パッケージを再度組み立てる必要があります。
基本サービス展開パッケージおよび拡張サービス展開パッケージでは、サービスの定義をプレビューできます。
• すでにパッケージに含まれているサービスの場合は、そのパッケージのコンテンツ タブに移動し、プレビューするサービスを選択してから、[Preview] ボタンをクリックします。
• [Select Services] ポップアップ ウィンドウが表示されたら、プレビューするサービスの名前をクリックします。
サービスのプレビューは、サービス定義のサマリーと、サービス フォームのレンダリングからなります。すべてのエンティティ参照がプレビュー最後の [Additional Content] セクションにまとめられています。これを見て、これらのエンティティがターゲット環境にあるかサービスの展開前に確認できます。
(注) グリッドを持つサービスをプレビューした場合、グリッドは表示されず、グリッド ディクショナリのキャプションだけが表示されます。
パッケージを組み立てるには、[Assemble Package] ボタンをクリックします。パッケージを組み立てた後、そのステータスは [Not Transmitted] のままです。いずれかのコンポーネントの定義が変更された場合、または展開するエンティティの追加または削除を行った場合には再度組み立てることができます。パッケージ組み立てのログ エントリには、指定されたプライマリ エンティティと、やはり展開されるすべてのコンポーネント エンティティが含まれます。ログは、パッケージ履歴の [View log] リンクをクリックして表示できます。
• ターゲット サイトは [Administration] > [Settings] > [Entity Homes] で定義されています。
• ターゲット サイトに対応するデータ ソースは ColdFusion Administrator を使用して定義されています。
パッケージを送信するには、[Transmit] ボタンをクリックします。ポップアップ ウィンドウが表示され、ターゲット サイトの指定が求められます。
いずれかのサイトが赤で表示される場合、それは有効なデータ ソースがサイトに見つからなかったこと、またはデータ ソースの接続情報が正しくなかったことを意味します。
必要なサイトを選択して [Transmit Now] をクリックします。展開パッケージがターゲット サイトに送信されます。ソース サイトの現行パッケージのステータスは [Transmitted] に変わります。送信したパッケージは追加サイトへ送信したり、エクスポートしたりできます。
パッケージは、送信に加え、またはその代わりに、エクスポートできます。パッケージをエクスポートすると、組み立てたパッケージのコンテンツからなる XML ファイルが生成されます。エクスポート ファイルは、次にターゲット サイトにインポートして展開できます。
パッケージのエクスポートではパッケージのテキスト表現が提供されます。オフライン アーカイブとして使用することや、企業のソース コード管理システムにチェックインすることができます。
パッケージをエクスポートするには、[Export] ボタンをクリックします。ダイアログ ウィンドウが表示され、ファイル名の右クリックが求められます。
続いてファイルを希望の宛先に保存できます。宛先は一般的には共有ドライブ上(Catalog Deployer の機能ですべてのユーザがアクセス可能)にします。パッケージの追跡を容易にするために、ディレクトリの命名標準およびサブディレクトリの構成標準を定めてください。たとえば、同じ変更要求の一部として展開されるすべてのパッケージに対して新しいサブディレクトリを作成できます。
エクスポート/インポートは、セキュリティなどが心配でソース サイトからターゲット サイトへのパッケージの直接送信が許可されないようなケースでは、パッケージ送信の代わりに使用できます。結果は同じです。つまり、パッケージは [Received for Deployment] ステータスでターゲット サイトに作成され、続いて展開できます。
エクスポートされたパッケージは、ターゲット システムにインポートする必要があります。パッケージをインポートするには、表示/検索ペインの [New] ドロップダウン メニューで [Import...] オプションをクリックします。ダイアログボックスが表示され、インポートするファイルの参照が求められます。
ファイルが見つかったら、[Import] をクリックします。展開パッケージはステータス [Received for Deployment] で作成されます。
ターゲット サイトに送信またはインポートされたパッケージを展開するには、[Received for Deployment] ビューを使用して展開するパッケージを選択します。[Deploy] をクリックします。Catalog Deployer によってパッケージの展開が試みられます。すべての展開アクションが、パッケージ履歴でアクセス可能なログ ファイルに記録されます。履歴は、たとえば、エンティティがターゲット サイトで作成または更新されたかどうかを示します。展開の完了後、パッケージのステータスは [Deployed] に変わります。
展開に失敗した場合(たとえば、関連付けられたエンティティがターゲット サイトに存在しない場合)は、エラー メッセージが表示され、ログ ファイルに失敗が記録されます。問題を修正して(たとえば、見つからないエンティティを作成するか、あるいは、見つからないエンティティを含むカスタム展開パッケージを展開することによって)、同じパッケージを再び展開します。
展開するパッケージの組み立て済みコンテンツは、ターゲット サイトのリリース レベルに一致する必要があります。Catalog Deployer は、パッケージが組み立てられたアプリケーション バージョンを追跡し、異なるバージョン間での展開を許可しません。
基本サービス パッケージまたは拡張サービス パッケージは、展開するサービスが使用するすべてのコンポーネント設計要素を含みます。ただし、データベースに格納されていない設計コンポーネントは展開パッケージに含まれず、別に展開する必要があります。これらの要素には次のようなものがあります。
• 任意の ISF スクリプトによって参照される JavaScript ライブラリ
• 環境に追加され、データ取得ルールまたはオプション リストによって参照されるデータ ソース
完全なリストについては、『 Cisco Service Portal Configuration Guide 』を参照してください。
原則として、展開は、展開が行われたときのインフライト要求によって使用されるサービス定義とコンポーネント定義には影響しません。ただし、要求プロセスの性質は動的であるため、以前に送信された要求は次による影響を受けます。
• ルールまたは JavaScript 関数およびライブラリのコンテンツに対する変更
• 最終的な承認ステップにまだ合格していないサービス要求の提供計画に対する変更
展開スケジュールおよびサービスの設計者は、以前のバージョンのサービス定義に基づくインフライト要求が上記要素に対する変更による影響を受けることを考慮する必要があります。
複数のパッケージをバッチで送信および展開する場合があります。Catalog Deployer は順番にバッチの各パッケージを処理し、それぞれのステータスを提供します。この手順によって、ユーザ操作が制限されているときに多数のパッケージを展開することが非常に簡単になります。
複数のパッケージを送信するには、Catalog Deployer の [New] ドロップダウン メニューで [Transmit Multiple Packages] を選択します。
次にターゲット サイトを選択し、送信するパッケージを検索します。検索ウィンドウでは、ステータスが [Not Transmitted](組み立て済み)および [Transmitted] のパッケージを選択できます。
送信を開始するために [Transmit] をクリックします。送信プロセスの完了後、ステータス画面が表示され、パッケージごとに送信の成否が示されます(送信に失敗する最も一般的な理由は、ソース サイトおよびターゲット サイト間でバージョンが一致しないことです)。各パッケージのアクティビティ ログも更新されます。
複数のパッケージを 1 回のバッチで展開する場合にも同様のインターフェイスが使用可能です。[New] ドロップダウン メニューで [Deploy Multiple Packages] を選択します。
コンテンツ ペインに検索ウィンドウが表示され、展開するパッケージを選択できます。ステータスが [Received for Deployment] の展開パッケージはいずれも選択できます。パッケージはリストされている順序で展開されるため、一般にリストの上部にカスタム パッケージが表示されるようにしてください。バッチ送信と同様に、バッチ展開でも、パッケージごとに展開の成否が示され、この情報はパッケージのアクティビティ ログでも使用可能です。
いずれのステータスの展開パッケージも、それが作成されたサイトで閉じることができます。パッケージを閉じることは、そのステータスを [Closed] に変更するだけなので、それは他のビューではなく、[Closed] パッケージのビューにのみ表示されます。これにより、必要なパッケージを見つけるために検索するアクティブ パッケージの数が少なくなるため、他のパッケージの操作がより簡単になる場合があります。
閉じたパッケージは、たとえば、別のサイトに送信したり、そのコンテンツをエクスポートしたりする必要があれば、いつでも再び開くことができます。
展開パッケージを削除すると、パッケージとその展開履歴が現行サイトから永久的に取り除かれます。パッケージ コンテンツは圧縮されていますが、パッケージ コンポーネントを表すために必要な XML は非常に大きくなる場合があります。したがって、パッケージを削除すると、リポジトリ/データベースで使用可能なスペースを取り戻せます。パッケージ コンテンツは、パッケージを以前にエクスポートした場合に回復可能ですが、現行サイトでのパッケージの完全な展開履歴は回復できない可能性があります。
非常に幸運な場合を除いて、ビルド プロセスの一部として同じエンティティを複数回展開することが必要になります。たとえば、1 つ以上のサービスを開発環境からテスト環境に展開し、テスト実行者は修復の必要性がある欠陥をいくつか見つけ、サービス定義が開発で修復されて再展開されます。この修正は実稼働に展開される前にテストで検証できます。
展開パッケージをコピーできる機能があれば、この作業フローが簡単になります。必要なコンテンツを含む初期パッケージをいったん生成したら、そのパッケージをコピーできます。新しいパッケージはステータス [Not transmitted] で作成されます。これには組み立てたパッケージ コンテンツではなく、コンテンツ タブで指定されたリスト エンティティが含まれます。続いて必要に応じてパッケージを再度組み立てることができます。
展開パッケージ タイプ(基本サービス、拡張サービス、基本提供サービス、拡張提供サービス、カスタム)では、それぞれが展開可能なプライマリ エンティティと、関連付けられたエンティティの展開の管理に使用可能なオプションとが異なります。
基本サービス展開パッケージは指定されたサービス定義とそのコンポーネントを展開します。サービスに関連付けられたいずれかのエンティティがターゲット サイトに存在しなければ、展開は失敗します。
基本サービス展開パッケージとそれに関連付けられたエンティティのコンテンツの要約を次に示します。
|
|
|
サービス定義:Service Designer の [Service Catalog] オプションで定義されるサービス定義のすべての面 |
||
デフォルトでは、Catalog Deployer は標準データと標準定義を展開します。この動作は、Administration の [Deploy Entries (data) in Standards Tables] 設定を無効にすることによって上書きできます。たとえば、これは、異なる環境で異なるデータ セットを使用する必要があるときや、外部ソースからデータをファイル インポートで提供しているときに望ましい場合があります。
拡張サービス展開パッケージは指定されたサービス定義とそのコンポーネントを展開します。拡張サービス展開は基本展開とは主に次の 2 点が異なります。
• 親サービスを選択してそれがバンドルであることを示すことによって、バンドルを構成しているすべてのサービスを自動的に展開できます。
• ユーザは、関連付けられたエンティティが展開時にターゲット サイトに存在しないときに実行するアクションを指定できます。これは基本サービス展開の動作(関連付けられたいずれかのエンティティが存在しなければ自動的に失敗)を上書きします。
関連付けられたエンティティがターゲット サイトに存在しないときの拡張サービス展開パッケージにおける Catalog Deployer の動作を制御するオプションについて次に要約を示します。
|
|
|
サービスの定義を実質的に変更するので、[Skip] オプションおよび [Create] オプション(選択したエンティティ タイプにのみ使用可能)は、「クイック アンド ダーティ」展開にのみ有用と見なすべきです。サービスのフォーム コンポーネントは変更を加えずに転送されますが、場合によっては提供計画に重大な変更が加えられることがあります。
基本提供サービス展開パッケージは指定された提供サービスとそのコンポーネントを展開します。提供サービスに関連付けられたいずれかのエンティティがターゲット サイトに存在しなければ、展開は失敗します。
基本提供サービス展開パッケージとそれに関連付けられたエンティティのコンテンツの要約を次に示します。
|
|
|
拡張提供サービス展開パッケージは指定された提供サービスとそのコンポーネントを展開します。拡張提供サービス展開は基本展開とは主に次の 1 点が異なります。
• ユーザは、関連付けられたエンティティが展開時にターゲット サイトに存在しないときに実行するアクションを指定できます。これは基本提供サービス展開の動作(関連付けられたいずれかのエンティティが存在しなければ自動的に失敗)を上書きします。
関連付けられたエンティティがターゲット サイトに存在しないときの拡張提供サービス展開パッケージにおける Catalog Deployer の動作を制御するオプションについて次に要約を示します。
|
|
|
カスタム展開パッケージでは、サービス定義および提供サービス以外のエンティティを展開できます。カスタム展開パッケージに含めることができるエンティティは次のとおりです。
カスタム展開でカテゴリを展開すると、ターゲット サイトでソース サイトのカテゴリ構造の全部または一部を再作成できます。選択したカテゴリとそのサブカテゴリが展開され、カテゴリとそれが関連付けられたサービスとの関係が、ソース サイトにおける関係に合わせて再設定されます。これは基本展開パッケージ(展開対象のサービスに関連付けられたカテゴリのみがパッケージに含まれます)の機能を補うものです。
パッケージには、エンティティ間に相互依存関係がある複数のエンティティ タイプを含めることができます。たとえば、人は既存の組織に関連付ける必要があります。Catalog Deployer は正しい順序で自動的にエンティティを展開します。そのため、これらの相互依存関係は維持できます。
さらに、同じタイプのエンティティ間に相互依存関係が存在することもあり、ある人が別の人をスーパーバイザとして指名したり、組織階層が存在したりします。このような場合も、Catalog Deployer によってエンティティは正しい順序で(たとえば、スーパーバイザ エンティティが最初に)展開されるため、関係を再設定できます。
展開するエンティティごとに、ターゲット サイトのエンティティ定義を、パッケージに含まれる新しい定義で上書きするか、展開をスキップするかをオプションで選びます。このオプションをキューの場合で次に示します。
Catalog Deployer はターゲット サイトにエンティティが存在するかどうかを調べるのみで、(たとえば、ソースがターゲットよりも新しいかどうかを確認するために)コンテンツの検査を行わないので、エンティティ展開をスキップすることは危険です。[Skip] オプションは、すでに存在するエンティティの再インストールを行わないでパフォーマンスを最適化できますが、その使用は限定された状況(たとえば、エンティティが存在するか不明であるターゲット サイトに大きいパッケージを初めて展開する場合など)で行ってください。いずれかの面で展開に失敗する(たとえば、ホーム OU がターゲット サイトと現在の展開パッケージに存在しない人を展開しようとした)場合は、その欠落を修正してパッケージを再展開できます。まだターゲット サイトに存在しないパッケージ コンテンツのみが展開されます。
電子メール テンプレートを除いたエンティティ タイプごとに、ターゲット サイトの他の関連エンティティとの関係の再設定に関して Catalog Deployer の動作を指定するオプションもあります。
• ソース サイトの関係を複製せずにエンティティ定義に対する変更のみを展開するには、[Do not include] を使用します。これは、たとえば、新しい組織のみを展開し、この組織と多数の人々(一部の人がターゲット サイトに存在しないことがあります)の関係を展開しない場合に必要になります。
• 一般的にはソース サイトの関連付けを含めることは必要です。この場合、ソース サイトの関係がターゲット サイトに複製されます。[Skip] オプションを使用すると、一部の関連付けられたエンティティがターゲット サイトに存在しない場合に展開を続行できます。たとえば、まだ開発中で展開されていないサービスにキューを割り当てた場合などです。[Skip] オプションを使用する場合は、予想される関連付けがスキップされた状態にならないように、ログを注意深く読んでください。
表示/検索ペインでは、操作するパッケージのステータスを選択できるほか、特定のパッケージの検索もできます。
検索ダイアログを表示するには、[Search Packages] オプションを選択します。
検索は、パッケージ コンテンツ(パッケージに含まれる指定されたタイプのすべてのエンティティの名前)またはパッケージ名で行うことができます。検索によって、そのステータスに関係なく、指定された条件を満たすパッケージがすべて見つかり、表示ペインにパッケージ名の一覧が表示されます。これらを下にスクロールし、関心のあるパッケージを 1 つ選択し、コンテンツを吟味し、ステータスで許可されていれば、それらのコンテンツを更新できます。
ログはパッケージが受けるすべてのアクティビティを記録します。組み立てログには、パッケージに含まれるすべてのエンティティが一覧で表示されます。展開ログには、ターゲット サイトに正常に展開されたすべてのエンティティ、展開に使用されたバッチの数、およびエンティティが作成されたか更新されたかが一覧で表示されます。パッケージが展開に失敗した場合には、エラーも表示されます。
ログには、すべてのパッケージ詳細(名前、説明)、組み立てまたは展開の時間の時刻/日付スタンプ、および含まれるすべてのエンティティが記録されています。ログの例を次に示します。
Catalog Deployer はエンティティの名前変更をサポートしていません。ソース サイトでエンティティを名前変更してその展開を試みるか、名前変更されたエンティティを参照するサービスの展開を試みた場合、Catalog Deployer は正しく動作しません。関連エンティティとの関連付けを設定(再設定)するために、Catalog Deployer はそのエンティティをターゲット サイトで名前により見つけようとします。展開の目的上、エンティティ「名」は、人(ログイン名によって識別)および組織(組織タイプと名前の組み合わせによって識別)を除くすべてのエンティティの名前属性です。結果は次のようになります。
• サービス定義のコンポーネント エンティティ(ディクショナリ、フォーム コンポーネント)では、新しいエンティティが作成され、このエンティティとの関連付けが展開対象のサービスに設定されます。
• 展開対象のプライマリ エンティティでは、新しいエンティティが新しい名前で作成されます。
• 関連付けられた(ディレクトリ エンティティおよび電子メール テンプレート)エンティティでは、選択したパッケージ タイプおよび展開オプションに応じて、展開が失敗する場合、またはエンティティの関連付けがスキップされる場合があります。
• 該当する場合は、影響を受けるエンティティのサイト保護をターゲット サイトでオフにします。
• 名前がソース サイトの名前と一致するようにターゲット サイトのエンティティを名前変更します。
開発プロセス中は、エンティティ名の変更を注意深く追跡して、上記のように、エンティティをターゲット サイトに展開しようとする前に、こうした変更をターゲット サイトに適用できるようにしてください。
新しい Service Portal サイトを作成する必要があります。1 つのオプションは、既存の Service Portal データベースをサイトにコピーし、そのデータベースを使用するようにインストールおよび設定を調整することです(この手順については、『 Cisco Service Portal Configuration Guide 』に記載されています)。ただし、別のオプションとして、データベースの初期設定を実行し、次に Catalog Deployer を使用して新しいサイトに実装する必要のあるすべてのエンティティを展開することがあります。
Catalog Deployer は、Service Catalog の進展に伴い一般に変化しない Service Portal の設定面は展開しません。したがって、初期サイトに対して行ったように、これらの要素を定義する必要があります。
• ディレクトリ統合、承認、およびエンティティ ホームなど、Administration モジュールの設定を再入力します。これらの設定は開発の設定と同じにすべきですが、環境固有の設定項目は除きます(たとえば、開発とテストで LDAP ディレクトリが別の場合があります)。
• インストール手順にすべての Service Link カスタム アダプタが含まれていたこと、および Service Portal アダプタに加えたすべての変更が再度適用されることを確認します。
Organization Designer によって保守されるエンティティ(人、組織、グループ、ロール、および役職)は、サービス定義がこれらのエンティティを参照できるように、その前にサイトに存在していなければなりません。したがって、こうしたエンティティはすべて、サービス カタログの展開より前に展開する必要があります。
このようなエンティティは 1 つ以上のカスタム展開パッケージに含まれている必要があります。ターゲット サイトはまだ使用中でないため、カスタム展開パッケージのバッチ サイズを大きくして展開を最適化します。次のエンティティは、次の順序で展開する必要があります(この順序は、複数のエンティティ タイプが同じパッケージで展開される場合に自動的に使用されます)。
• グループ(カスタムのグループが作成された場合にのみ必要)
さらに、カスタムのすべての電子メール テンプレートを展開する必要があります。電子メール テンプレートは、それを使用するサービスが展開される前ならいつでも展開できます。
基本エンティティをいったん展開すると、サービスを展開できます。初期展開では、パッケージ サイズを管理しやすく(たとえば、グループの問題はサービス グループ別に)保ち、ログを注意深く確認するようにします。関連付けられたすべてのエンティティを先に展開しておく必要があるので、基本展開が使用でき、またそれを使用すべきです。カスタム展開パッケージに関しては、バッチ サイズを大きくして、共有コンポーネントを持つ多数のエンティティを展開するときのパフォーマンスを最適化できます。
これで 2 つ(以上の)サイトが稼働している状態です。実稼働のすべてのサービスは開発のサービスと同じである必要があります(初期展開の一部だった追加サービスが開発に存在する場合がありますが問題ありません)。いずれの環境でエンティティ定義とメンバーシップを(グループ、ロール、および組織に関して)保守しますか。すべてのケースで、エンティティ保護レベルはホーム以外の環境のエンティティに対するすべてのメンテナンスを防止するように設定されていると想定します。
最も直接的なアプローチは、サービス定義を構成するすべてのエンティティのホームを開発インスタンスに設定し、人および組織に関連するすべてのエンティティのホームを実稼働インスタンスに設定することです。
これによって、Catalog Deployer の使用およびそれが展開するエンティティの保守が非常に簡単になります。つまり、すべてのエンティティのすべての面が常に 1 つのサイトのみで保守されます。ただし、ディレクトリ関連エンティティの作成およびテストの作業フローが複雑になります。
1. 新しいサービスを開発する前に、サービスの提供計画または他の領域で参照されるキュー、組織、グループ、ロール、および役職のインベントリを作成します。
2. これらの関連付けられたエンティティのすべてがすでに開発インスタンスに存在する場合は、それらが実稼働にもすでに存在すること(それらのホームが実稼働になっているからです)を意味します。したがって、サービスの作成およびテストを続行できます。
3. これらのディレクトリ関連エンティティのいずれかがまだ存在しない場合は、実稼働インスタンスにログインしてそれらを作成します。エンティティ定義とそのメンバーシップおよびロールを設定します。
4. 実稼働にログインした状態で、新しいエンティティとそれに関連付けられたエンティティを含むカスタム展開パッケージを作成します。ターゲット インスタンスにまだ関連付けがないため、このパッケージでは新しいエンティティに対して [Use Source associations] オプションを使用する必要があります。
6. 展開した新しいエンティティを使用してサービスを作成します。
7. サービスがテスト準備完了になったら、そのサービスを含む基本サービス パッケージを作成します。
8. ディレクトリ エンティティを含むカスタム パッケージをテスト サイトに(この順序で)展開します。次に基本サービス パッケージを展開します。
9. サービスがテストに合格したら、同じ基本サービス パッケージを開発から実稼働に展開します。
このシナリオでは、ディレクトリ関連エンティティに関するすべての作業が(実際にはサービス定義でそれらを参照していることを除いて)1 箇所、つまり実稼働環境で行われます。すべての作業が 1 箇所で行われ確認およびモニタしやすいため、これは適しています。ただし、このプロセスには、潜在的に次のデメリットがあります。
• 開発プロセスにステップを追加することになります。エンティティ定義を最初に(または 2 度目あるいは 3 度目に)訂正しなかった場合は、実稼働に戻ってエンティティを修正し、再パッケージ、再展開および再テストを行わなければならなくなります。再パッケージを行う場合、プライマリ エンティティはターゲット サイトにのみ存在するサービスにすでに関連付けられているため、プライマリ エンティティに対して [Use Target Associations] オプションを使用する必要があります。
• 考えられる別の難点に、実稼働で広範な開発作業を行っている場合があり、これは一部の組織ではセキュリティ リスクと見なされます。
代替アプローチは、サービス定義を構成するすべてのエンティティのホームを開発インスタンスに設定し(これは決して変えるべきではありません)、人および組織に関連するのエンティティのホームを実稼働インスタンスと開発インスタンスの両方に設定することです。
組織、グループ、ロール、および人などのエンティティのホームを両方のインスタンスに設定することには、次の利点があります。
• これらのエンティティの定義を論理的な場所、つまり開発環境で操作できます。たとえば、適切なカスタム ロール定義を得るには、数段階かかる場合があります。開発、展開、およびテストを繰り返す必要はありません。単に開発およびテストを行って、終了したら展開するだけです。
• 論理的な場所、つまり実稼働環境の組織またはロールにメンバーを割り当てることができ、そこではすべての人情報がディレクトリ統合により自動的にリフレッシュされ、すべての Request Center ユーザが表現されることが保証されます。
組織、グループ、ロール、および人などのエンティティのホームを両方のインスタンスに設定することには、次のデメリットがあります。
• ロールベース アクセス コントロールは現在、ある特定のエンティティ タイプへのアクセスを許可します。それ以上の細分化はできません。たとえば、開発環境でグループ(およびそのロール)のみを定義することを設計者に許可できるのではなく、実稼働環境でのグループ メンバーシップの割り当てを許可するだけです。
• メンテナンスは複数の環境で発生しているため、パッケージの展開時には注意を払う必要があります。ソースやターゲットとエンティティとの適切な関連付けが確実に維持されるようにしなければなりません。
例として、さまざまなサービス チーム組織にまたがる人でメンバーが構成されているグループを開発していると想定します。メンバーをグループに割り当てるにはどのようにしますか。
• 開発でグループを作成し、グループ経由で付与される機能および権限が正しいことを検証するためにソース(テスト)メンバーを割り当てます。グループに必要なすべての人が開発環境にいるとは限らないため、メンバー リストは不完全で、場合によっては実稼働の人と互換性がありません(対応するエンティティが実稼働にない「テスト」の人が何人かいる場合)。
• カスタム展開パッケージを使用して、ソースの関連付けによってグループを実稼働に展開しますが、参照されるエンティティが存在しなければ関連付けをスキップします。
• Organization Designer を実稼働で使用して、適切な人をグループと関連付けます。両方のエンティティのホームが実稼働であり、[Create, Delete, Modify] 保護レベルでもエンティティを保守できるため、この関連付けは人またはグループのいずれか便利な方のページで行うことができます。
• グループのメンバーシップが変化した場合に必要なことは、実稼働環境で Organization Designer に進み、適切な変更を加えるだけです。さらに、ディレクトリ統合には、人がメンバーになっているグループのリストを動的に指定する機能があります。この機能が(企業ディレクトリに対する更新と対応するディレクトリ マッピングにより)有効になっている場合、手動更新は不要です。
新しいキューを使用するには、新しいサービスを開発するか、既存のサービスを拡張する必要があります。ベスト プラクティスに従って、キューは、そのホームになっている対応するサービス チーム組織を持つようにすべきです。
キューおよび組織の「ホーム」を設定した場所に応じて、ここでは 2 つのシナリオが考えられます。それぞれにプラス面とマイナス面があります(これは前項の説明の特殊ケースですが非常に頻繁に起きます)。
これは、すべての作業を実稼働の組織、人、キューに置く「クリーン」アプローチです。2007 よりも前の Service Portal バージョンにおいて実行可能な唯一のアプローチだったため、それらのバージョンからアップグレードする人はその使用を継続することを好む場合があります。
• このアプローチのデメリットは、手動作業を実稼働で行っている(キューおよび OU を作成している)ことで、一部の組織ではセキュリティ上の理由からこれは好まれない場合があります。
• このアプローチの利点は、キューおよび OU でのすべての作業(その定義だけでなく、メンバーの割り当て)が 1 箇所で行われることです。
1. OU およびキューを実稼働で作成して適切なロールを割り当てます。
3. 新しい OU およびキューを実稼働から開発に展開します。OU におけるすべてのサービス実行者を展開パッケージに含めます。既存の人をスキップするように人の展開を設定して、展開パフォーマンスを最適化する場合があります。
このシナリオでは、エンティティの定義のホームは開発ですが、そのメンバーシップのホームは実稼働であると見なします(もちろん、この分割はエンティティ ホームによって実施することはできません。したがって、Organization Designer によるメンテナンスを許可するために、両方のサイトがエンティティのホームとして指定されます)。
1. OU およびキューを開発で作成して適切なロールを割り当てます。新しい設定の徹底的なテストができるように十分なメンバーを割り当てます。
3. 新しい OU およびキューを開発から実稼働に展開する際にソースの関連付けを使用しますが、ターゲット サイトに存在しないものはすべてスキップします(「テスト」の人を除外するため)。
4. 実稼働サイトで Organization Designer を使用(またはディレクトリ統合に依存)してメンバーを OU に割り当てます。
上記の両方のシナリオにおいて、初期展開後に初期のキューおよび OU 設定に対して変更の可能性があることに直面します。
• OU のメンバーシップの変更は、初期展開に関して処理されます。つまり、OU メンバーシップは実稼働で保守されます。このような変更をすべて展開で開発に戻すことは不可欠ではなく、これを希望する場合に、OU と新規の人や影響を受ける人のカスタム展開パッケージを生成してソースの関連付けによって開発に展開できます。
• OU に割り当てられた権限の変更はエンティティ定義のホーム サイトで適用されます。次に、新しい OU 定義がターゲットの関連付けを使用して他のサイトに展開されます。
これは実際、かなり直接的な手順です。次のように 2 つのパッケージが必要になります。
1. 開発において、電子メール テンプレートを含むカスタム パッケージを作成します。デフォルトの展開オプション(既存エントリを置換)を使用します。
2. 開発において、改訂されたサービスを含む基本サービス パッケージを作成します。
4. 実際、多数のサービスがあり、それらが多くのコンポーネント(フォームまたはディクショナリなど)を共有し、かつピーク以外の時間に展開をスケジュールできる場合には、基本サービス展開バッチのサイズを増やすことを検討します。展開対象のエンティティがコンポーネント エンティティを共有する場合には、大きいサイズのバッチにパフォーマンス上の利点があります。
もちろん、各パッケージは、カスタム パッケージが基本サービス パッケージよりも前に展開されるという条件下なら、生成時に展開できます。
複数のサービス(特定のキューに割り当てられているタスクを含みます)が展開された後で、キュー名がサービス実行者(その変更を望んでいます)の誤解を招きやすいというフィードバックを受け取ります。あるいは、会社が再編成を行ったため新しい組織を反映するために組織(サービス チームを含む)の名前変更が必要です。
これは前述した「既知のエラーおよび欠落」と衝突します。Catalog Deployer はサイト間でエンティティの名前を一致させて動作するため、名前変更されたエンティティとの一致は不可能です。場合によっては(上述のように)、Catalog Deployer は失敗してエラーを報告します。ただし、別のケースでは、Catalog Deployer はターゲットに新しいエンティティを作成します。名前変更されたキューに関しては、以前に展開されたすべてのサービスが引き続き古いキューを使用します。キューが名前変更され展開された後で展開されたサービスのみが新しいキューを参照します。これは明らかに設計者の意図に反します。
この動作を防止する唯一の方法は、名前変更の必要があるエンティティを慎重にモニタして制御するプロセスを整備するすることです。このプロセスは、キューおよび組織のホームが実稼働だけであるか、実稼働と開発の両方であるかに応じて若干異なりますが、いずれの場合も両方のサイトでエンティティの手動による名前変更(Organization Designer を介して)が必要です。
1. 要件に応えて、Organization Designer は通常のメンテナンス手順によって開発インスタンスのキューおよびサービス チームを名前変更します。
2. 管理者は手動で(Organization Designer を介して)実稼働インスタンスのエンティティを名前変更します。エンティティのホームは両方のインスタンスであるため、エンティティ保護レベルは通常、このステップを許可します。
3. サービス設計者は名前変更されたキューおよびサービス チームを使用してサービスを操作します。このようなサービスは標準手順によって展開できます。
1. 要件に応えて、Organization Designer は通常のメンテナンス手順によって実稼働インスタンスのキューおよびサービス チームを名前変更します。
2. 管理者は開発インスタンスのエンティティ ホーム保護レベルを緩和します。これは、エンティティのホームが実稼働に設定されたので、またキュー定義またはメンバーシップに対する手動変更は一般に許可されないため必要です。
3. Organization Designer が開発サイトのエンティティを名前変更します。
4. 変更が適用された後で、管理者はエンティティ保護レベルをオンに戻します。
5. サービス設計者は名前変更されたキューおよびサービス チームを使用してサービスを操作します。このようなサービスは標準手順によって展開できます。
カテゴリは基本サービス展開または拡張サービス展開の一部でコンポーネント エンティティとして展開されます。これは主要目標が新しいサービス定義または改訂されたサービス定義を展開すること、および関連付けられたカテゴリ分けも展開されるようにすることであるときの効果的な戦略です。ただし、サービス パッケージの使用は、カテゴリに関連付けられたカテゴリ階層またはイメージが変更されたときには効果的でありません。
カスタム展開パッケージには、カテゴリ階層を参照するサービスがあってもそれとは別個に、カテゴリ階層の全部または一部を展開するオプションがあります。カテゴリ構造がターゲット環境に展開されるときに、Catalog Deployer は各カテゴリおよびそのサービス間の関連付けを自動的に再設定します。
いつもどおりに、エンティティ(この場合はカテゴリ)の名前変更だけに対する警告が適用されます。カテゴリがもう適用されない場合には、サービスに対するその関連付けを削除して新しい交換カテゴリを作成します。代替方法は、次のようにしてソース インスタンスとすべてのターゲット インスタンスのカテゴリを名前変更することです。
1. Catalog Designer が開発(カテゴリのホーム)のカテゴリを名前変更します。
2. 管理者は実稼働サイトのエンティティ保護をオフにします。
3. Organization Designer が実稼働サイトのカテゴリを名前変更します。
4. 変更が適用された後で、管理者はエンティティ保護レベルをオンに戻します。
5. サービス設計者は名前変更されたカテゴリを使用してサービスを操作します。このようなサービスは標準手順によって展開できます。
2008 よりも前の Service Portal のバージョンから 9.1 にアップグレードすると、サービス定義ごとに新しいエンティティ セットが生成されます。これらのエンティティには他と明確に区別できる名前が割り当てられるので、サービス設計者はアップグレード プロセスによって生成されたものとしてそれらを認識できます。
• すべてのサービス定義に対応するアクティブ フォーム コンポーネントがあります。アクティブ フォーム コンポーネントの名前は、「UPGD: Form」とその後に続くサービス名で構成されます。
• すべてのフォーム コンポーネントがフォーム コンポーネント グループに割り当てられます。グループの名前は、「UPGD: Form」とその後に続くサービス グループ(フォームに対応するサービス定義がある場所)の名前で構成されます。
サービス設計者はアップグレード プロセスによって生成されるアーティファクトの名前変更を最低でも望むので、名前はユーザがわかりやすいものになっています(また、再使用を促進するためにフォーム コンポーネントの構造のリファクタリングも望む場合もありますが、それは別の問題です)。次に示すのは「標準的な」名前変更シナリオです。
1. Service Designer がフォーム コンポーネントおよびフォーム コンポーネント グループを開発(これらのエンティティのホーム)で名前変更します。
2. 管理者は実稼働サイトのエンティティ保護をオフにします。
3. Organization Designer が実稼働サイトのフォーム コンポーネントおよびグループを名前変更します。
4. 変更が適用された後で、管理者はエンティティ保護レベルをオンに戻します。
5. サービス設計者は名前変更されたフォーム コンポーネントを使用してサービスを操作します。このようなサービスは標準手順によって展開できます。
役職を開発(OU に関連)で定義して、1 つまたは 2 つの組織にその役職を持つ人を指定しました。その役職にタスクをルーティングするように開発でサービスを変更しました。新しい変更されたエンティティを展開するにはどのようにしますか。
2. カスタム パッケージは、作成した役職とその役職に割り当てられている人を含みます。人の展開オプションではソースの関連付けを使用します。
ブラウザ キャッシュの設定が Administration の [Settings] で有効になっている場合、サービス カタログ/提供サービスのプレゼンテーションのアイコンと埋め込みイメージに加えられた変更は、ブラウザ キャッシュが削除されるまで有効になりません。アプリケーション ユーザにそのブラウザ キャッシュを削除するように求めるには、『 Cisco Service Portal Configuration Guide 』の手順に従ってブラウザ キャッシュのバージョンを上げてください。詳細については、このマニュアルを参照してください。
シスコでは、特定の製品リリースにおいてブランド化コンテンツ ライブラリの形でコンテンツを提供します。ご使用のリリースに関してこのようなコンテンツ ライブラリが使用できるかを知りたければ、Cisco Technical Assistance Center(TAC)にお問い合わせください。次の 3 タイプのライブラリ パッケージが使用可能です。
• サービス ライブラリ:サービス定義とそのコンポーネント エンティティを含みます。
• 提供サービス ライブラリ:提供サービスとそのコンポーネント エンティティを含みます。
• カスタム ライブラリ。サービス ライブラリまたは提供サービス ライブラリに関連付けられたエンティティを含みます。
これらのライブラリのサービスと提供サービスは、エンド ユーザ管理、アクセス管理、データセンター管理などの領域でよく必要になるサービスのモデルを提供します。ライブラリ コンテンツをプレビューして、希望する項目を開発環境に展開できます。このためサービスや提供サービスを企業要件に合わせて設計、設定、およびカスタマイズするのが一歩有利になります。
カスタム ライブラリには、キューやサービス チーム(組織)などのエンティティが含まれ、これらはサービスまたは提供サービスで参照されます。カスタム ライブラリは、場合によっては、対応するサービスまたは提供サービスのライブラリと組み合わせてインストールできます。カスタム ライブラリが展開されると、サービスまたは提供サービスは事前定義の参照を使用します。カスタム ライブラリがインストールされないと、サービスまたは提供サービスは適宜、「デフォルト サービス キュー」を参照するかその参照を除去します。サービス設計者はタスク(提供)計画または提供サービスの設定を完了する責任があります。
一般に、サイト管理者はブランド化ライブラリのコンテンツを管理して展開する責任があります。希望する場合は、ブランド化コンテンツ ライブラリを展開する機能を含むカスタム ロールを作成できます。ロールの作成および割り当ての詳細については、『 Cisco Service Portal Configuration Guide 』またはオンライン ヘルプを参照してください。
• ライブラリを入手します。ライブラリと対応するユーザ マニュアルはシスコのソフトウェア サイトからダウンロードできます。
• ライブラリをインストールします。ライブラリは、クライアント ワークステーションがアクセス可能なディレクトリ(Catalog Deployer がそこから実行されます)にインストールする必要があります。共有ネットワーク ドライブではライブラリの中央ストレージが可能になります。
• ライブラリ コンテンツの展開を担当するユーザが、この機能を含むロールを持っていることを確認します。
• ライブラリをインポートします。ライブラリを Catalog Deployer にインポートします。
• ライブラリ コンテンツを確認します。ライブラリ パッケージを展開する権限を持つ人が、ターゲット サイトで受信パッケージを選択し、場合によっては、ライブラリ コンテンツ(サービスまたは提供サービス)をプレビューします。
• 選択したライブラリ コンテンツを展開します。受信パッケージを選択し、展開するパッケージ コンテンツを選択して展開を実行します。
• 展開ログを確認します。ライブラリ コンテンツを展開すると、エンティティ定義の作成または更新に関して、すべての展開アクティビティの詳細を記録したログが生成されます。
ブランド化コンテンツ ライブラリのコンテンツをインポート、プレビュー、または展開するには、ユーザに「展開をインポートする」機能および「展開パッケージを展開する」機能を含むロールを付与する必要があります。これらの機能を含む事前定義のロールは次のとおりです。
ライブラリ パッケージのインポートは展開パッケージのインポートに似ています。
ステップ 1 ドロップダウン メニューで [New] > [Import] を選択します(そのオプションが使用不可の場合は、現在のユーザに、「ブランド化ライブラリ コンテンツを展開する」機能を含むロールがありません)。
ステップ 2 [Import Package] ウィンドウが表示されます。
ステップ 3 希望するライブラリを参照して選択し、[Import] をクリックします。
ステップ 4 ライブラリがインポートされ、ステータス [Received for Deployment] が割り当てられます。ライブラリの [Summary] ページが表示されます。
ライブラリ パッケージには、ライブラリを識別してその展開を案内する次の属性があります。
サービス ライブラリおよび提供サービス ライブラリでは、展開する前にサービスまたは提供サービスの定義をプレビューできます。ライブラリのコンテンツ タブで、プレビューするサービスを選択し、次に [Preview] ボタンをクリックします。サービスのプレビューは、サービス定義のサマリーと、サービス フォームのレンダリングからなります。提供サービスのプレビューでは、その提供サービスの定義の要約が示されます。
ライブラリはシスコから顧客サイトへ配布される新しいコンテンツの伝達手段です。ライブラリは開発サイトのみへ展開すべきです。Catalog Deployer は、顧客の要件に合わせて以前にカスタマイズされた可能性のある既存のコンテンツを混乱させたり上書きしたりすることなくライブラリを展開できるように設計されています。したがって、ライブラリ パッケージを展開するためのオプションは、ライブラリ コンテンツが、ターゲット サイトで同名の以前に作成されたすべてのコンテンツを(置換するのではなく)補足するように設定されます。
• パッケージのプライマリ エンティティ(カスタム パッケージのサービス、提供サービス、またはディレクトリ関連エンティティ)は、同名のエンティティがターゲット サイトで見つからない場合にのみ展開されます。ライブラリからの展開によって既存のコンテンツが置換されることは決してありません。
• サービス バンドルは常に親サービス定義とすべての子サービス定義を含みます。すべてのプライマリ エンティティの場合と同様に、同名のサービスがターゲット サイトにすでに存在すると、サービス定義は(展開されずに)スキップされます。
• コンポーネント エンティティは、プライマリ エンティティとともに自動的に展開されるエンティティです。たとえば、サービスを展開することは、そのサービスによって使用されるディクショナリ、アクティブ フォーム コンポーネント、カテゴリ、およびキーワードを展開することになります。このようなコンポーネント エンティティは、同名のエンティティがターゲット サイトにすでに存在すると展開されません。
• 関連付けられたエンティティは、プライマリ エンティティによって参照されるエンティティです。たとえば、キュー、人、および組織はサービス タスク計画によって参照することができ、またサービスの関連付けられたエンティティ タイプです。関連付けられたエンティティがプライマリ エンティティの展開時にターゲット サイトに存在すると、それらのエンティティ間に関係が設定されます。関連付けられたエンティティが存在しない場合にはデフォルトの関係(たとえば、「デフォルト サービス キュー」に対する)が設定されます。
サポート対象エンティティ(キューおよび組織単位など)を含むライブラリのコンテンツ全体は同時に展開する必要があります。反対に、Catalog Deployer では、展開するサービス ライブラリまたはサービス提供ライブラリのコンテンツを選択できます。各サービスまたは提供サービスは別個のバッチ(トランザクション)で展開されます。展開に失敗した場合は現行バッチがロールバ ックされます。
すべてのインポート アクションおよび展開アクションが、ライブラリ パッケージの [Summary] タブの [History] 領域に表示されるように記録されます。
[History] パネルの [View Log] リンクを使用すると、Catalog Deployer によるアクションが詳細に、具体的には、作成されたエンティティ、同名のエンティティがサイトにすでに存在するためスキップされたエンティティが表示されます。
展開ログの例を次に示します。この例では、1 つのサービス(パッケージに含まれる 54 の中から)が展開用に選択されて、正常に展開されました。
Catalog Deployer には検索機能があり、これを使用するとパッケージを名前で、またはコンポーネント エンティティの名前で検索できます。詳細については、「展開パッケージの検索」を参照してください。