この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章は次のトピックで構成されています。
Catalog Deployer は、サービス設計者、カタログ発行者、財務管理者、および組織構築リソースが開発サイト、テスト サイト、および本番サイト間でアプリケーション エンティティを移行するためのコンテンツ展開と構成管理に使用できます。
また、Catalog Deployer は変更管理プロセスと変更履歴を顧客に提供することによって、コンテンツの変更や Service Catalog のすべてのモジュールで使用される組織エンティティの変更に対する信頼性の高い制御を可能にします。
Catalog Deployer では、シスコによりブランド化コンテンツ ライブラリ内にパッケージされた事前設定サービスの展開もサポートされています。 このようなサービスは、そのままの状態で、または組織要件に対してサービス定義をカスタマイズするためのテンプレートとして使用できるため、実行可能なサービス カタログの実装に必要な時間と労力が大幅に削減されます。
Catalog Deployer には 2 つのコンテンツ展開方法が用意されています。
他のすべての Service Catalog モジュールと同様に、Catalog Deployer は使用のための権限を付与できます。 ユーザには、展開履歴の表示、展開パッケージの作成と組み立て、特定のサイトへのパッケージのインポートや展開を行う権限、またはこれらをユーザの責務に最適になるように組み合わせた権限を持たせることができます。 このような機能はすべて、Organization Designer モジュール内の標準ロールまたはカスタム ロール経由で割り当てることができます。
主な機能は次のとおりです。
Catalog Deployer は、カスタマイズされたサービス カタログの基礎を形成するためのテンプレート コンテンツを提供する Service Catalog の試みの最初で使用することができます。 また、Catalog Deployer は開発作業のビルドおよびメンテナンスの段階で使用して、テスト済みコンテンツを開発から他の環境にプロモートしたり、複数の環境を同期させたりもできます。
以降の項で、Catalog Deployer を使用したリリースと構成の管理に関連した機能について説明します。
この章の次の項では、シスコ コンテンツ ライブラリをインストールしてサービス カタログやサービス ポートフォリオの基礎を提供するための Catalog Deployer の使用に関連する機能を説明します。
Catalog Deployer には、アプリケーションにある論理エンティティに基づいて編成された、データベース中立のデータ転送インフラストラクチャおよびインターフェイスがあります。 論理エンティティの例としては、サービス定義、データ ディクショナリ、人員、および組織単位などがあります。 完全なリストは、この項の最後にあります。 ただし、異なるデータベースやアプリケーション環境間のカスタム コンテンツのサポートは制限されています。 Catalog Deployer でサポートされないエンティティのリストについては、サポートされていないエンティティを参照してください。
実装、サイト、およびエンティティ ホームについては、表 1に説明があり、これらは Catalog Deployer の操作に不可欠です。
特に、論理エンティティのホーム サイトは Catalog Deployer での構成管理に欠かせない部分です。 Catalog Deployer ではオプションですが、論理エンティティに対してホーム サイトのシステムを作成することによって、サイト間の論理エンティティの参照整合性と、サイト間の設定情報の整合性の両方の管理が可能になります。
論理エンティティ ホーム サイトの背後にある概念は、特定のサイトは、他のサイトに比べ、論理エンティティ タイプについて、より信頼性の高いバージョンのデータを持っているというものです。 たとえば、ユーザ情報の認証および収集に自分の LDAP ディレクトリを使用しているカスタマーの場合、人員と組織単位について最も正確なデータがあるのは本番サイトということになります。 このため、本番サイトが、人員および組織単位のホーム サイト(記録のサイト)になります。 もし、本番サイト以外のサイトで人員の作成や組織単位の編集が可能な場合、このデータを他のシステムに展開すると、記録システムとの同期が失われ、実装におけるデータの品質が低下します。
そのため、アプリケーション フレームワークは、エンティティのホーム サイト以外のサイトでユーザがこれらのエンティティを修正することがないように、保護レベルを論理エンティティに割り当てることができるように設計されています。 サイト管理者は、Catalog Deployer の設定に説明されているように、4 つの設定から 1 つを選択することにより、論理エンティティに提供する保護のレベルを選択できます。
Catalog Deployer はエンティティの一部としてエンティティの権限を展開します。 権限がそのホーム サイトのエンティティから除去された場合、このアプリケーションは、Catalog Deployer がこの除去の複製のために使用できる削除スタブ(またはトランザクション ログ)を残しません。 たとえば、サービスをオーダーする権限がサービス定義の組織単位から除去されたとき、Service Catalog はこの事実を保持せず、権限を除去するだけです。
権限が変更されたサービスを展開すると、サービス定義とその権限の間のすべての関連付けが対象サイトにドロップされ、ソース サイトで有効な権限に従って再作成されます。 ただし、権限がカスタム ロールまたはグループに付与されている場合に、ロールまたはグループがソース サイトから削除されても、ロールまたはグループは対象サイトから削除されません。 Catalog Deployer はエンティティの削除をプロパゲートできません。
次の表は、Catalog Deployer によってサポートされているすべての論理エンティティと、それらに関連付けられたアプリケーション モジュールの一覧を示したものです。
Catalog Deployer は、上記のエンティティをソース サイトのデータベースからターゲット サイトのデータベースにコピーします。 Catalog Deployer は、ファイル システムに格納されている情報の移動、コピーは行いません。 Catalog Deployer は、JavaScript 関数に関連付けられたライブラリの定義をコピーします。
Catalog Deployer は、同じバージョンの Service Catalog を使用して実装されている 2 サイト間でトランザクション データベースに格納されている論理エンティティを移行します。 エンティティは .xml の形式でテキスト ストリームに抽出されます。これは展開用パッケージの一部であり、パッケージの作成に使用される仕様(任意)も含まれています。 そのパッケージは、バックアップ メカニズムとして、および別のサイトのターゲット データベースにエンティティ定義を展開するためのソースとして機能させるために、ソース データベースから抽出できます。 エンティティ定義は変更されずに対象環境に展開されます。
(注) |
Catalog Deployer は、.bmp 形式のイメージ(プレゼンテーション要素)の展開をサポートしていません。 Service Designer は現在、このようなイメージの指定ができないようになっています。 古い形式のイメージは、.jpg または .gif など、Web 上のプレゼンテーションに最適化された別の形式に変換する必要があります。 |
Catalog Deployer は論理エンティティ以外の Service Catalog のいずれのコンポーネントにも影響しません。 これらのコンポーネントのいくつかに対する変更は、Service Link によって処理される構成管理シナリオ(カスタマーが設計および構成した設定項目の実装間での同期)の一部でないため、これ以上ここでは検討する必要がありません。 次に例を示します。
ただし、追加の設定項目は、Catalog Deployer によって処理される論理エンティティに対する変更と組み合わせて展開しなければならない場合があります。 これらの詳細を、影響を受ける論理エンティティとともに、以下の表に示します。
設定項目 |
制御および移行する追加のアーティファクト |
---|---|
外部ディクショナリ |
データベースで実行される DML および DDL スクリプト |
データソース |
外部ディレクトリや、データ取得ルールで参照される SQL ベースのオプション リストまたはテーブルを参照するデータソースの指定 |
データ取得ルール |
ルールに直接入力される SQL ステートメント(異なるデータベース タイプ間では互換性がない場合がある) |
ISF スクリプト ライブラリ |
アプリケーション サーバに展開されるライブラリ(JavaScript)テキスト ファイル |
カスタム アダプタ |
Service Link の Adapter Development Kit(ADK)によって生成される展開ファイル |
重要なロールは次のように定義されます。
ロール |
定義 |
---|---|
Catalog Publisher |
サービス カタログの作成と管理、ランタイム アプリケーションへのカタログ コンテンツの展開、カタログのルック アンド フィールと構造の設定を行います。また、サービス定義と提供計画の変更に従って、展開されたカタログ コンテンツの継続的な更新を行います。 |
Service Designer |
カスタマー サイトでサービス定義を設計します。 サービス設計者は、カスタマー IT チームのカスタマーに提供されるサービスについて豊富な専門知識を持ち、Service Designer および Organization Designer の使用法に習熟しています。 サービス設計者は、技術的には中級ですが、一般的にはエンジニアというよりはビジネス アナリストです。 サービス設計者は、開発サイトでサービス定義を頻繁に作成したり変更したりしなければならない場合があります。 ステージング サイトまたは本番サイトへ作業をパブリッシュするために Catalog Deployer の使用が許可される人もいます。 |
Organization Builder |
カスタマー サイトで Organization Designer の組織エンティティを設計します。 組織ビルダーは、Service Catalog を正常に展開して使用するために必要な組織単位、グループ、およびロールの設定に関する組織のニーズについて豊富な専門知識を持っています。 組織ビルダーは、Organization Designer モジュールの使用法に習熟している必要があります。 組織ビルダーは、技術的に高度である必要はありませんが、アプリケーション管理の IT リソースである必要があります。 |
Site Administrator |
カスタマー サイトでアプリケーションの権限を管理します。 この担当者は、システムの最初のユーザになる場合があります。Global Configurations の設定など、アプリケーションのバック エンドのすべてにアクセスできます。言語や課金カテゴリなどのリストの管理も行います。 |
変更マネージャ |
カスタマー サイトで実装の変更要求を承認します。 この担当者は、通常、本番サイトの安定性に責任を負っています。本番サイトへの展開に先立ち、すべての変更内容を理解しておく必要があります。 このロールはオプションですが、正式な変更制御プロセスが確立されたカスタマー サイトで必要になります。 |
Finance Designer |
カスタマーのアカウントを作成し、各アカウントまたは OU のクォータを定義するための協定を設定し、サービス品目運用の課金料率を定義します。 カスタマーのサービス品目の消費と課金/チャージバックを管理します。 |
次の表は、Catalog Deployer モジュールに関して、システム定義のロールおよび各ロールに付与されるデフォルト機能を説明したものです。
定義済みの役割 |
機能 |
|||||
---|---|---|---|---|---|---|
基本サービス展開の管理 |
拡張サービス展開の管理 |
カスタム展開の管理 |
展開のインポート |
展開用パッケージの展開 |
ブランド コンテンツ ライブラリのパッケージング |
|
Catalog Designer and Administrator |
P |
P |
P |
|
|
|
Organization Designer |
|
|
P |
|
|
|
Site Administrator |
P |
P |
P |
P |
P |
P |
Catalog Publisher |
P |
P |
P |
P |
P |
|
Licensed Content Publisher |
P |
P |
P |
P |
P |
P |
この項では、Service Catalog の実装方法と、業界標準の構成(または変更)管理プラクティスをサポートする関連プロセスの設計方法を説明します。
以下では、一般的な方法と(Catalog Deployer 設定管理など)Service Catalog アプリケーションで使用可能な方法について説明し、両者を比較します。 初期開発からテスト、展開、およびメンテナンスまで、展開の段階に一致した、構成管理に対するさまざまなアプローチを説明します。
Catalog Deployer は、IT 業界標準の構成管理方法およびテクノロジーで採用されているベスト プラクティスを実装します。 そのため、これらのプラクティスを確認しておくと役に立ちます。
Service Catalog アプリケーションの場合は、開発されるソフトウェアの多くが、カテゴリ、グループ、タスク、チェックリストなどの関連要素を含むサービス定義です。
Catalog Deployer は、お客様が、サービス定義などのコンテンツや関連サービスを展開するために使用できます。
一般的な構成管理シナリオと Catalog Deployer が果たす役割には次のようなものがあります。
このシナリオは業界標準に従ったものです。業界標準では、開発環境においてのみ、サービス定義の変更が行われます。また、テスト環境および本番環境にソース コードの制御されたセットを展開するには、自動化されたプロセスが使用されます。
ただし、このシナリオは不完全です。 ほとんどの実装では、人員と事業単位(組織のタイプ)が、本番環境に動的に追加されたり、人員が初めて Service Catalog にログインしたときに彼らのためにサービスをオーダーしたり、審査または承認を実施するために割り当てられたりします。 したがって、Catalog Deployer は、これらのエンティティを本番サイトから開発に戻す移行のときも使用しなければなりません。それにより、まだ開発中のサービス定義または他の Service Catalog 設定項目(たとえば、承認)でそれらのエンティティを使用できます。 さらに、サービス定義は、電子メール テンプレート、グループ、キュー、サービス チーム組織、およびロールなどの関連エンティティを参照する場合があります。 これらのいずれかが対象環境に存在しない場合、足りないものを対象環境に展開しなければ、サービスの展開パッケージは正常に展開されません。
Catalog Deployer の設定には次の作業が含まれます。
(注) |
サービス パックを含むすべてのサイトで、同じ Service Catalog のバージョンを使用する必要があります。 |
(注) |
さまざまなデータベースからインポート(Catalog Deployer または REX を使用して)された「個人」と「エージェント」データのパスワードをターゲット データベースでリセットする必要があります。 これは、キー暗号キーが Prime Service Catalog データベースのインスタンスごとに異なるためです。 「個人」と「エージェント」のパスワードがリセットされなかった場合は、それらをターゲット データベースで正しく復号化できません。 |
Catalog Deployer によって生成される展開パッケージは、含まれるエンティティの圧縮された XML 表現を含みます。 Catalog Deployer はパッケージのファイルベース送信を使用します。その中で、パッケージ コンテンツは、パッケージのエクスポートおよびターゲット サイトへの以降のインポートにより、あるサイトから別のサイトへ転送されます。
このファイル ベースの転送をサポートするには、暗号化されたページをディスクに保存できるようユーザのブラウザを設定する必要があります。 次の手順を実行します。
ステップ 1 |
を選択します。 |
ステップ 2 | [暗号化されたページをディスクに保存しない(Do Not Save Encrypted Package to Disk)] チェック ボックスをオンにします。 |
ステップ 3 | [OK] をクリックします。 |
(注) |
すべての展開がサイト間の直接送信で行われている場合、この設定は不要です。 |
Catalog Deployer を使用する前に、開発インスタンスおよび本番インスタンスを使用して実装を設定する必要があります。 実装は、Catalog Deployer が Service Catalog サービス定義とその他の Service Catalog エンティティを移行するサイトを集めたものです。
実装とサイトの設定手順の概要は以下のとおりです。詳細は以降のセクションで説明します。
Catalog Deployer を使い始めるには、Administration モジュールで実装環境の設定を行う必要があります。 Administration で設定した値により、ソース サイトは対象サイトを認識できるようになります。
アプリケーション サーバ コンソールの JDBC データ ソースのページでデータ ソースを定義した後で、次の手順を実行する必要があります。
実装を設定するには、次の手順に従います。
ステップ 1 | Administration 特権を持ったユーザとして開発インスタンスにログインします。 | ||||||||||||
ステップ 2 | モジュールのドロップダウン メニューから、[管理(Administration)] を選択します。 | ||||||||||||
ステップ 3 |
[Settings(設定)] タブをクリックします。 |
||||||||||||
ステップ 4 |
右側のメニューから、[Entity Homes] を選択します。 [論理エンティティのホームの仕様(Logical Entity Home Specification)] ページが表示されます。 これらの設定は、Catalog Deployer と Service Designer モジュールおよび Organization Designer モジュールの動作に影響します。 設定が正しくないと、間違ったデータが本番サイトを含む Service Catalog アプリケーション サイトに書き込まれる可能性があります。 これらの設定の変更は、システム管理者だけが行うようにする必要があります。 |
||||||||||||
ステップ 5 | [実装サイト(Implementation Sites)] セクションのページ下部にあるテキスト フィールドに、サイト名を入力します(例:「Development」)。 | ||||||||||||
ステップ 6 |
[データソースの選択(Select a Data Source)] ドロップダウン メニューからデータ ソースを選択し、[新規追加(Add New)] をクリックします。 サイト名のリストにこのサイト名が追加されます。 |
||||||||||||
ステップ 7 | 他のサイトとして、本番サイトの名前を追加します。 | ||||||||||||
ステップ 8 | QA または Test など、Catalog Deployer でリフレッシュする必要のある他のサイトが実装に含まれる場合は、これらも追加します。 | ||||||||||||
ステップ 9 | ページ上部にある [実装名(Implementation Name)] フィールドに実装名を入力します(例:My Cloud や Data Center Management)。 | ||||||||||||
ステップ 10 | 現在のサイトを識別するために [このサイト(This Site is)] ドロップダウン メニューから開発サイトを選択し、[更新(Update)] をクリックします。 | ||||||||||||
ステップ 11 | エンティティの [ホームサイト(Home Site)] の割り当てを確認し、要件に合わないところを変更します。 完了したら、[更新(Update)] をクリックします。 | ||||||||||||
ステップ 12 |
定義した各サイトに適切な [サイト保護レベル(Site Protection Level)] を割り当てます。 完了したら、[更新(Update)] をクリックします。 これらの保護レベルは、対応する論理エンティティの保守を行う Service Designer、Organization Designer、および Administration のページの動作を変更します。
|
Catalog Deployer がパッケージを別のサイトに送信するためには、ターゲット サイトに対応する JDBC データ ソースがソース サイトと同じアプリケーション サーバ上で設定されている必要があります。 JDBC データ ソースを設定する手順は、『Cisco Prime Service Catalog Installation and Upgrade Guide』に記載されている RequestCenter データ ソースを設定する手順と同じです。
Service Catalog でデータ ソースを検出するには、同じ JNDI 名プレフィックスを使用する必要があります。 検出されたデータ ソースのリストが [管理(Administration)] > [設定(Settings)] > [データソースレジストリ(Data Source Registry)] に表示されます。
特定のデータ ソースは、レポートを作成する目的で使用され、Service Designer や Catalog Deployer のユーザに表示するためには使用されません。 データ ソースをこれらのユーザーに必要なものだけに制限するには、これらのデータ ソースの [エンティティホーム定義に使用(Use for Entity Home Definition)] チェックボックスをオンにしてから、[更新(Update)] をクリックします。
最初に、1 つのサイトを設定します。通常は、開発サイトから始めます。 開発サイトは、ソース サイトに表示される他のターゲット サイトに移行されたサービス定義のソース サイトです。 実装全体の構成に応じて、どのサイトでもソース サイトまたはターゲット サイトとして、あるいは潜在的に両方のサイトとして、設定できます。
たとえば、テスト サイトと本番サイトが見えるように開発サイトを設定、および開発サイトとテスト サイトが見えるように本番サイトを設定します。 このシナリオでは、まず開発からテストにエンティティを展開します。次にテストが成功したと仮定し、開発から本番にエンティティを展開します。 次に、組織情報を本番サイトから、テスト サイトと開発サイトの両方に移行します。
必要なデータ ソースの定義を含め、潜在的なターゲット サイトの設定をすべてのソース サイトで繰り返します。
設定が正しいことを確認するには、各サイトにログインして、Catalog Deployer に移動し、[アクション(Action)] ペインで [送信(Transmit)] をクリックすることによって、パッケージを、今設定したターゲット サイトの 1 つに送信します。ドロップダウン メニューに選択可能なターゲット サイトの 1 つとして自分のサイトが表示されます。
Catalog Deployer は、ソース サイトまたはターゲット サイトがオンラインで使用中の場合に実行する必要があります。 ただし、この使用には何らかの制限を設けることをお勧めします。
Catalog Deployer は、パッケージの組み立てや展開だけでなく、サービスのプレビューにも大量のメモリを消費します。 メモリ消費から生じる問題を避けるために、Catalog Deployer では、6 人以上のユーザが同時にパッケージの組み立て、インポート、またはプレビューを行うことができないようになっています。 6 人目のユーザがパッケージの組み立て、インポート、またはプレビューを行おうとすると、Catalog Deployer からその旨のアラートが表示され、後で再試行するようにユーザに通知されます。 通常、本番展開は 1 人の担当者が処理するため、このような状態が本番環境で発生する可能性はあまりありません。しかし、開発環境やテスト環境で、複数のサービス設計者がそれぞれのコンテンツを展開のためにパッケージ化している場合は、この状態が発生することがあります。
パッケージの組み立てまたは展開は、まだブラウザを介した操作と見なされています。 そのため、Administration モジュールで設定された非活動用のセッション タイムアウトで、大規模なパッケージの組み立てや展開がタイムアウトすることはありません。
Catalog Deployer は、エンティティが複数のプライマリ エンティティに必要な場合に、関連付けられたエンティティをパッケージ内で 1 回作成/更新するだけです。 たとえば、展開パッケージ内の 20 のサービスにディクショナリ「IT Software Configuration」が必要な場合、Catalog Deployer はそのディクショナリをターゲット サイトで 1 回作成/更新するだけです。 共通コンポーネントを持つサービスを同じパッケージにまとめることで、パッケージのサイズと、Catalog Deployer が行う必要のある冗長な作成/更新の数を減らすことができます。
大きいパッケージ(サイズによって定義)のパフォーマンスは時間がかかることが予想されます。 また、このようなパッケージのアセンブリや展開は失敗する可能性があることにも留意してください。 この場合、解決するには、パッケージをプライマリ エンティティの比較的小さいセットに分けます。たとえば、20 個のサービスで構成される 1 つのパッケージを作成する代わりに、各 10 個のサービスのパッケージを 2 個作成します。
原則として、Catalog Deployer は 1 回のデータベース トランザクションで完全なパッケージを展開できます。 その場合、1 つのコンポーネントの展開に失敗すると(たとえば、指定されたキューがターゲット内に存在しないために拡張パッケージ内のサービス定義を展開できない)、全体のパッケージ内容がロール バックされます。 対象サイトのリポジトリは、展開が開始する前と同じ状態で維持されます。
ただし、実際には、この全か無かという展開によって問題が発生することがあります。 一度エンティティが展開されると、完全なパッケージが展開され、データベース トランザクションがコミットされるまで、オンライン ユーザはこれを使用できません。 この間に、ユーザが進行中の展開によって更新されたサービスのオーダーを試みると、ユーザのセッションはハングし、サービス定義が使用可能になるまで待機することになります。 最終的に、エラー メッセージが表示されるか(最悪の場合)、遅延の後サービスをオーダーできるようになります(最良の場合)。 (このエラーが発生する可能性があるのは、ユーザが最初にサービスをオーダーする場合のみです。タスク実行者や承認者がこのサービスで作業する場合には発生しません)。
このシナリオを回避する確実な方法の 1 つは、公開システムが使用中は展開を許可しないことです。 これは、定期的にスケジュールされたメンテナンス期間に公開システムに対する更新を行うという、業界で受け入れられているベスト プラクティスに準拠しています。 ただし、定期メンテナンスが実行されるまで展開を待機させることができない場合もあります。 Service Catalog が稼働中に展開を実施しなければならない場合に問題が発生する可能性を最小限に抑えるために、サービスをより小さな論理パッケージにグループ化することをお勧めします。 サービス設計者は、関連するサービスを同じパッケージにグループ化することによって、共有コンポーネントの小さくなったパッケージ サイズの恩恵を受けることもできます。
ここでは、Catalog Deployer の機能を簡単に説明します。 展開パッケージ タイプ(基本サービス、拡張サービス、およびカスタム)には、展開可能なプライマリ エンティティと、関連エンティティの管理展開に使用可能なオプションに違いがあります。
基本サービス展開用パッケージは、Service Designer でのサービス定義のインポートと同様の機能を果たします。 ターゲット サイトで関連するエンティティ(キューや組織単位など)が見つからなかった場合は、それらのエンティティが展開で省略されるだけです。 基本パッケージにはバンドルされたサービスを含めることができません。
サービス展開用パッケージは標準とサービス項目も収集します。 ルックアップ Dynamic Data Retrieval(DDR)とサービス項目ベースのディクショナリで参照されたものが自動的にパッケージに含まれます。 標準エントリも展開するかどうかを制御する Administration グローバル設定があります(標準エントリは必ず収集され、制御は展開ターゲットにのみ適用されます)。
(注) |
Catalog Deployer で展開用のサービスを表示または選択するために Service Designer の権限は必要ありません。 |
基本サービス展開用パッケージの内容とその関連するエンティティを以下に示します。
コンテンツ タイプ |
操作 |
エンティティ タイプ/説明 |
---|---|---|
プライマリ エンティティ |
[サービスの内容(Services content)] タブ経由で選択される |
サービス定義:Service Designer の [サービスカタログ(Service Catalog)] オプションで定義されたサービス定義のすべての側面 |
コンポーネント エンティティ |
自動展開 |
サービス定義によって参照されるすべてのエンティティ: |
関連エンティティ |
展開では、ターゲット サイトに存在しないエンティティ関連付けが省略されます。 |
サービス定義によって参照されるすべてのエンティティ:
|
デフォルトで、Catalog Deployer は標準データと標準定義を展開します。 この動作を無効にするには、Administration 設定を [標準テーブルのエントリ(データ)の展開(Deploy Entries (data) in Standards Tables)] に設定します。 さまざまな環境でさまざまなデータ セットを使用しなければならない場合や、データが外部ソースからファイル インポートを介して提供される場合などにこの方法を選択します。
拡張サービス展開用パッケージは、指定したサービス定義とそのコンポーネントを展開します。 このパッケージ タイプでは、対象サイトでの展開中にサービス定義の関連エンティティを処理する方法のオプションを制御する機能が提供されます。
拡張サービス展開は、基本展開とは次の 2 つの点で大きく異なります。
関連付けられたエンティティがターゲット サイトに存在しないときの拡張サービス展開パッケージにおける Catalog Deployer の動作を制御するオプションについて次に要約を示します。
関連付けられた単位 |
使用可能なオプション |
結果 |
---|---|---|
エージェント(Agent) |
省略(Skip) |
エージェントの参照が、提供タスクまたは承認タスクから削除されます |
|
失敗(Fail) |
展開が失敗します |
Eメールテンプレート(Email Template) |
作成(Create) |
対象サイトに空のテンプレートが作成されます。 |
|
省略(Skip) |
テンプレートの参照が、提供タスクまたは承認タスクから削除されます |
|
失敗(Fail) |
展開が失敗します |
役職(Functional Position) |
省略(Skip) |
役職との関連付けが削除されます。割り当てはデフォルト サービス キューに入ります |
|
失敗(Fail) |
展開が失敗します |
グループ |
省略(Skip) |
グループとの関連付けが削除されます。割り当てはデフォルト サービス キューに入ります |
|
失敗(Fail) |
展開が失敗します |
組織 |
省略(Skip) |
タスクがデフォルト サービス キューに割り当てられます |
|
失敗(Fail) |
展開が失敗します |
人員(People) |
省略(Skip) |
タスクがデフォルト サービス キューに割り当てられます |
|
失敗(Fail) |
展開が失敗します |
キュー |
作成(Create) |
キューは、対象サイトにそのキューの組織が存在する場合のみ作成されます。存在しない場合、展開が失敗します |
|
省略(Skip) |
タスクがデフォルト サービス キューに割り当てられます |
|
失敗(Fail) |
展開が失敗します |
ロール |
省略(Skip) |
タスクがデフォルト サービス キューに割り当てられます |
|
失敗(Fail) |
展開が失敗します |
サービスの定義を実質的に変更するので、[省略(Skip)] オプションおよび [作成(Create)] オプション(選択したエンティティ タイプにのみ使用可能)は、「クイック アンド ダーティ」展開にのみ有用と見なすべきです。 サービスのフォーム コンポーネントはそのまま転送されますが、提供計画に大幅な変更をもたらす可能性があります。
カスタム展開用パッケージを使用すれば、展開中に、エンティティを個別に選択して、関連エンティティを処理する方法に関するオプションを制御することができます。 カスタム展開は、人員、キュー、ロール、組織単位、エージェント、サービス項目、標準、課金レート、アカウント定義、契約テンプレート、カテゴリ、グループなどの組織エンティティ、役職、電子メール テンプレートに使用されるのが一般的です。 カスタム パッケージにはサービスを含めることができません。
サービス項目と標準展開の振る舞いを制御するよりきめの細かいオプションが用意されています。 オプションで、サービス項目インスタンスと標準エントリを展開の一部として含めることができます。 ただし、このオプションはパッケージ内のすべてのサービス項目タイプと標準に適用されます。 一部の標準またはサービス項目のエントリだけを含めて他のエントリは含めないようにするには、それらを別々のパッケージに分離する必要があります。
インポート中に、[需要管理(Demand Management)] > [課金レート(Billing Rate)] > [課金レート定義(Billing Rate Definition)] で単位レート フラグが設定(ソース XML)された場合は、Catalog Deployer でカスタム パッケージを作成するときに請求レートとして「マージ」オプションが選択されます。 レート表がターゲット内に存在する場合は、「マージ」オプションが無視され、ターゲット内の既存のデータ レコードを削除することによって「上書き」として実行されます。
「単位レート」フラグが設定されたレート表に対して、次の検証を実施する必要があります。 これは、需要管理、NSAPI、および REX フローにも実施する必要があります。
カスタム展開を使用してカテゴリを展開すると、ソース サイトのカテゴリ構造のすべてまたは一部を、ターゲット サイトに再作成できます。 選択したカテゴリとそれらのサブカテゴリが展開され、カテゴリが関連付けられているサービスとカテゴリの関係が、ソース サイトでの関係と一致するように再確立されます。 これは、基本展開パッケージで提供される機能を補完します。基本展開パッケージでは、展開しているサービスに関連付けられているカテゴリのみがパッケージに含まれます。
1 つのパッケージには、エンティティ間に相互依存性がある 2 つ以上のエンティティ タイプを含めることができます。 たとえば、人員は既存の組織に関連付ける必要があります。 Catalog Deployer は正しい順序で自動的にエンティティを展開します。そのため、これらの相互依存関係は維持できます。
さらに、同じタイプのエンティティ間に相互依存関係が存在することもあり、ある人員が別の人員をスーパーバイザとして指名したり、組織階層が存在したりします。 このような場合も、Catalog Deployer によってエンティティは正しい順序で(たとえば、スーパーバイザ エンティティが最初に)展開されるため、関係を再設定できます。
展開する各エンティティ(役職以外)に対して、パッケージに含まれる新しい定義で対象サイトのエンティティ定義を上書きする、または展開を省略するオプションを選択できます。
Catalog Deployer はターゲット サイトにエンティティが存在するかどうかを調べるのみで、(たとえば、ソースがターゲットよりも新しいかどうかを確認するために)コンテンツの検査を行わないので、エンティティ展開をスキップすることは危険です。 [スキップ(Skip)] オプションは、すでに存在するエンティティの再インストールを行わないでパフォーマンスを最適化できますが、その使用は限定された状況(たとえば、エンティティが存在するか不明であるターゲット サイトに大きいパッケージを初めて展開する場合など)で行ってください。 いずれかの面で展開に失敗する(たとえば、ホーム OU がターゲット サイトと現在の展開パッケージに存在しない人を展開しようとした)場合は、その欠落を修正してパッケージを再展開できます。 まだターゲット サイトに存在しないパッケージ コンテンツのみが展開されます。
エンティティ タイプ(電子メール テンプレート、役職、およびエージェント以外)ごとに、ターゲット サイトの他の関連エンティティとの関係の再設定に関して Catalog Deployer の動作を指定するオプションもあります。
展開中にソース サイトからターゲット サイトにインポートされたデータもマージすることができます。 このオプションは、サービス項目定義、標準定義、課金レート定義、および同意テンプレートに使用できます。
(注) |
ポータル ページとポートレット権限はロールを使って展開できます。 展開は、ポータル ページとポートレットが Portal Designer 経由でインポートされてから実施する必要があります。 |
展開用パッケージは Catalog Deployer で次のフローに従います。
ステップ 1 | 展開用パッケージを作成します。 Catalog Deployer にアクセスして使用する権限を付与されたユーザは、展開用パッケージを作成し、パッケージに含めるエンティティを選択できます。 展開用パッケージの作成を参照してください。 |
ステップ 2 | パッケージをアセンブリします。 基盤となるコンテンツが展開準備完了と見なされると、[アクション(Action)] ペインの [パッケージのアセンブリ(Assemble Package)] ボタンをクリックすると、展開用パッケージがアセンブリされます。 この時点で、Catalog Deployer はコンテンツを抽出し、展開用パッケージの一部として保存されるコピーを作成します。 パッケージのアセンブリが行われると、パッケージに含まれるエンティティへの変更は、パッケージが再アセンブリされない限りキャプチャされません。 展開用パッケージの組み立てを参照してください。 |
ステップ 3 | パッケージを送信します。 アセンブリされたパッケージは、展開のために対象サイトに送信されます。 パッケージは、Catalog Deployer 経由で送信できます。または、ソース サイトおよびターゲット サイト間に直接接続がなければ、このステップをエクスポートおよびインポート プロセスを使用して「オフライン」で実行する場合があります。 展開用パッケージの送信を参照してください。 |
ステップ 4 | パッケージを展開します。 パッケージを展開する権限を持つ担当者は、対象サイトで受信されたパッケージを選択し、展開を実行します。 パッケージの展開を参照してください。 |
ステップ 5 | ビュー レコード ログ ファイルに、各サイトの Catalog Deployer 内で発生するすべてのアクティビティが記録されます。 ログ ファイルを参照してください。 |
ステップ 6 | 展開中にサポートされないエンティティについては、サポートされていないエンティティ を参照してください。 |
(注) |
パッケージ定義が変更された場合のみ、パッケージを保存する必要があります。 パッケージのコンテンツは自動的に保存されます。 |
展開用パッケージを作成するには、次の手順を実行します。
ステップ 1 | [表示と検索(View and Search)] ペインで を選択します。 |
ステップ 2 | [新規展開用パッケージ(New Deployment Package)] ウィンドウで、次の詳細情報を入力します。 |
ステップ 3 | [保存(Save)] をクリックします。 |
(注) |
|
パッケージにはその作成時にステータス [未送信(Not Transmitted)] が割り当てられます。 [表示と検索(View and Search)] ペイン内でこれをクリックすると、そのコンテンツが [内容(Contents)] ペインに表示されます。
コンテンツをパッケージに追加するには、次の手順を実行します。
ステップ 1 |
[内容(Content)]ペインで、[追加(Add)] ドロップダウン メニューをクリックし、そのパッケージのタイプで使用可能なエンティティのリストから、追加するエンティティ タイプを選択します。 [検索(Search)] ダイアログ ボックスが表示され、コンテンツを検索および選択できます。 |
ステップ 2 | チェック ボックスをオンにしてコンテンツを選択します。 |
ステップ 3 |
[追加(Add)] をクリックして、選択したコンテンツを追加します。 コンテンツが [内容(Content)] ペインに表示され、自動的に保存されます。 エンティティを削除する必要がある場合は、チェックボックスをオンにして、[削除(Remove)] と [はい(Yes)] を順にクリックします。 コンテンツは、パッケージが送信されるまで、いつでも追加および削除できます。 アセンブリされた後にコンテンツが変更された場合、パッケージを再アセンブリする必要があります。 |
基本および拡張サービス展開用パッケージでは、サービス定義のプレビューが可能です。
すでにパッケージに含まれているサービスの場合
パッケージの [内容(Content)] ペインに移動し、プレビューするサービスのチェックボックスをオンにして選択し、[プレビュー(Preview)] をクリックします。
サービスのプレビューはサービス定義の概要およびサービス フォームのレンダリングで構成されます。 すべてのエンティティ参照がプレビュー最後の [追加内容(Additional Content)] セクションにまとめられています。 これは、サービスを展開する前に対象環境にこれらのエンティティが存在することを確認するうえで役に立ちます。
[アクション(Action)] ペインで、[パッケージの組み立て(Assemble Package)] をクリックしてパッケージを組み立てます。 [OK] をクリックして、パッケージのアセンブリが成功したことを確認します。 パッケージを組み立てた後、そのステータスは [未送信(Not Transmitted)] のままです。 いずれかのコンポーネントの定義が変更された場合、または展開するエンティティの追加または削除を行った場合には再度組み立てることができます。 パッケージ組み立てのログ エントリには、指定されたプライマリ エンティティと一緒に展開されるコンポーネント エンティティの両方が含まれます。 [アクション(Action)] ペインの [履歴(History)] セクションで [ログの表示(View Log)] リンクをクリックすると、ログが表示されます。
コンテンツは、次の場合に別のサイトへ直接送信できます。
パッケージを送信するには、次の手順を実行します。
ステップ 1 | [表示と検索(View and Search)] ペインで、[表示(View)] ドロップダウン メニューを使用してステータスが [未送信(Not Transmitted)] のパッケージを表示します。 | ||
ステップ 2 | リストでパッケージを探します。 パッケージ名をクリックすると、そのパッケージの情報が他のペインに表示されます。 | ||
ステップ 3 | パッケージがアセンブリされていない場合、[アクション(Action)] ペインで、[パッケージのアセンブリ(Assemble Package)] をクリックします。 [OK] をクリックして、パッケージのアセンブリが成功したことを確認します。 | ||
ステップ 4 | [アクション(Action)] ペインで、[送信(Transmit)] をクリックします。 | ||
ステップ 5 |
ドロップダウン メニューからターゲット サイトを選択します。
|
||
ステップ 6 |
[今すぐ送信(Transmit Now)] をクリックします。 |
||
ステップ 7 |
[OK] をクリックして、送信が成功したことを確認します。 展開パッケージがターゲット サイトに送信されます。 ソース サイトの現在のパッケージのステータスは [送信済み(Transmitted)] に変更されます。 送信したパッケージは、他のサイトに送信したり、エクスポートしたりできます。 |
パッケージを送信する代わりに、パッケージをエクスポートすることができます。 パッケージをエクスポートすると、アセンブリされたパッケージのコンテンツで構成される XML ファイルが作成されます。 次に、エクスポート ファイルは、対象サイトにインポートされ展開されます。
パッケージをエクスポートすると、パッケージがテキストで表現されます。 エクスポートしたパッケージは、オフラインのアーカイブとして使用したり、会社のソース コード制御システムにチェック インしたりできます。
パッケージをエクスポートするには、次の手順を実行します。
ステップ 1 |
[表示と検索(View and Search)] ペインで、[表示(View)] ドロップダウン メニューを使用して [未送信(Not Transmitted)] または [送信済み(Transmitted)] ステータスのパッケージを表示します。
|
||
ステップ 2 | リストでパッケージを探します。 パッケージ名をクリックすると、そのパッケージの情報が他のペインに表示されます。 | ||
ステップ 3 | パッケージがアセンブリされていない場合、[アクション(Action)] ペインで、[パッケージのアセンブリ(Assemble Package)] をクリックします。 [OK] をクリックして、パッケージのアセンブリが成功したことを確認します。 | ||
ステップ 4 |
[アクション(Action)] ペインで、[エクスポート(Export)] をクリックします。 次の例に示されているように、[エクスポート(Export)] ダイアログボックスが表示されます。 |
||
ステップ 5 |
このダイアログボックスで、ファイル名のリンク(上記の例では、ファイル名のリンクは Basic Service Package02 です)をクリックします。 [ファイルのダウンロード(File Download)] ダイアログ ボックスが表示されます。 |
||
ステップ 6 |
[保存(Save)] をクリックします。 [名前を付けて保存(Save As)] ダイアログ ボックスが表示されます。 |
||
ステップ 7 |
必要に応じて、ファイルの名前を変更し、目的の宛先を選択します。 宛先は一般的には共有ドライブ上(Catalog Deployer の機能ですべてのユーザがアクセス可能)にします。 パッケージのトラッキングを円滑に行うには、ディレクトリの命名およびサブディレクトリの構造の標準を確立する必要があります。 たとえば、同じ変更要求の一部として展開されるすべてのパッケージに対して、新しいサブディレクトリを作成するなどです。 |
||
ステップ 8 | [保存(Save)] をクリックします。 | ||
ステップ 9 | [Close(閉じる)] をクリックして、[エクスポート(Export)] ダイアログボックスを閉じます。 |
セキュリティやその他の理由でソースから対象サイトへパッケージの直接送信が許可されていない場合、パッケージの送信の代わりにエクスポート/インポートを使用できます。 結果は同じです。つまり、パッケージは [展開用に受信(Received for Deployment)] ステータスでターゲット サイトに作成され、続いて展開できます。
エクスポートしたパッケージは、対象システムにインポートする必要があります。
パッケージをインポートするには、次の手順を実行します。
ステップ 1 |
[表示と検索(View and Search)] ペインで、[アクション(Action)] > [インポート(Import)] を選択します。 [インポート(Import)] ダイアログボックスが表示され、インポートするファイルを探すように求められます。 |
ステップ 2 | [参照(Browse)] をクリックします。 |
ステップ 3 | パッケージ ファイルを見つけて、選択します。 |
ステップ 4 | [開く(Open)] をクリックします。 |
ステップ 5 |
[インポート(Import)] をクリックします。 展開用パッケージがインポートされ、[展開用に受信(Received for Deployment)] ステータスが割り当てられて、開かれます。 これで展開できるようになりました。 |
ステップ 6 | [インポート(Import)] ダイアログボックスを閉じます。 |
(注) |
展開用パッケージを最初にエクスポートしたソース サイトに再インポートするには、まずソース サイトから同一のパッケージを削除する必要があります。 ファイル名が変更された場合でも、アプリケーションは重複ファイルを認識します。 |
対象サイトに送信またはインポートしたパッケージを展開するには、以下の手順を実行します。
ステップ 1 | [表示と検索(View and Search)] ペインで、[表示(View)] ドロップダウン メニューを使用して [展開用に受信(Received for Deployment)] ステータスのパッケージを表示します。 | ||
ステップ 2 |
リストでパッケージを探します。 パッケージ名をクリックすると、そのパッケージの情報が他のペインに表示されます。
|
||
ステップ 3 | [アクション(Action)] ペインで、[展開(Deploy)] をクリックします。 | ||
ステップ 4 | [OK] をクリックして、展開が正常に完了したことを確認します。 |
展開が正常に完了すると、パッケージのステータスは [展開済み(Deployed)] に変更されます。
展開するパッケージのアセンブリされたコンテンツは、対象サイトのリリース レベルと一致する必要があります。 Catalog Deployer は、パッケージがアセンブリされたアプリケーション バージョンを追跡し、異なるバージョン間での展開を許可しません。
基本または拡張サービス パッケージには、展開されるサービスで使用するすべてのコンポーネント設計要素が含まれます。 ただし、データベースに格納されていない設計コンポーネントは展開用パッケージに含まれず、別に展開する必要があります。 これらの要素には次のものが含まれます。
展開は、原則として、展開が行われたときにインフライトであった要求によって使用されるサービスおよびコンポーネントの定義に影響を与えません。 ただし、要求プロセスの動的性質により、以前に送信された要求は次のものによる影響を受けます。
展開スケジュールおよびサービスの設計者は、サービス定義の以前のバージョンに基づいたインフライトの要求が上記の要素の変更による影響を受けることを考慮する必要があります。
1 つの機能で複数のパッケージを送信して展開できます。 Catalog Deployer は順番に各パッケージを処理し、それぞれのステータスを提供します。 この手順により、わずかなユーザ操作で大量のパッケージを展開することが容易になります。
複数のパッケージを送信するには、次の手順を実行します。
ステップ 1 | [表示と検索(View and Search)] ペインで、 を選択します。 |
ステップ 2 | [送信するパッケージの追加(Add Packages to Transmit)] をクリックして [検索(Search)] ダイアログ ボックスを開きます。ここで、送信するパッケージを検索して選択できます。 [検索(Search)] ダイアログ ボックスでは、ステータスが [未送信(Not Transmitted)](組み立て済み)および [送信済み(Transmitted)] のパッケージのみを選択できます。 |
ステップ 3 | 必要なパッケージのチェック ボックスをオンにして選択します。 |
ステップ 4 |
[追加(Add)] をクリックして、選択したパッケージを追加します。 パッケージが [パッケージ(Packages)] フォルダの下にアルファベット順に表示されます。 選択したすべてのパッケージが送信されます。 パッケージを削除する必要がある場合は、そのチェック ボックスをオンにして、[削除(Remove)]、[はい(Yes)] の順にクリックします。 |
ステップ 5 | [ターゲットサイトを選択(Select a target site)] フォルダの下で、ターゲット サイトのチェック ボックスをオンにして選択します。 |
ステップ 6 |
[送信(Transmit)] をクリックして送信を開始します。 パッケージが一覧表示された順序(アルファベット順)で送信されます。 送信プロセスが完了すると、ステータス メッセージが表示され、各パッケージの送信の成否が示されます (送信失敗の最も一般的な理由は、ソース サイトとターゲット サイト間のバージョンの不一致です)。 各パッケージのログファイルも更新されます。 |
同様のインターフェイスを使用して複数のパッケージを展開できます。
ステップ 1 | [表示と検索(View and Search)] ペインで、 を選択します。 |
ステップ 2 | [複数パッケージの展開(Deploy Multiple Packages)] ウィンドウの [展開するパッケージの追加(Add Packages to Deploy)] をクリックして [検索(Search)] ダイアログ ボックスを開きます。ここで、展開するパッケージを検索して選択できます。 ステータスが [展開用に受信済み(Received for Deployment)] または [展開済み(Deployed)] の展開パッケージを選択できます。 |
ステップ 3 | 展開するパッケージのチェック ボックスをオンにして選択します。 |
ステップ 4 |
[追加(Add)] をクリックして、選択したパッケージを追加します。 パッケージが [パッケージ(Packages)] フォルダの下にアルファベット順に表示されます。 選択したすべてのパッケージが展開されます。 パッケージを削除する必要がある場合は、そのチェック ボックスをオンにして、[削除(Remove)]、[はい(Yes)] の順にクリックします。 |
ステップ 5 |
[展開(Deploy)] をクリックして展開を開始します。 パッケージが一覧表示された順序(アルファベット順)で展開されます。 複数送信と同様に、複数展開でも各パッケージの展開の成否が示されます。この情報は、パッケージのログ ファイルでも利用できます。 |
どの状態の展開用パッケージも、それが作成されたサイトの [表示と検索(View and Search)] ペインでそれをクリックして、[アクション(Action)] ペインで [クローズ済みとしてマーク(Mark as Closed)] をクリックすることによってクローズすることができます。パッケージをクローズすると、そのステータスが [クローズ(Closed)] に変わるだけで、そのパッケージは「クローズ」パッケージのビューにしか表示されなくなります。 これにより、探す対象のアクティブ パッケージが少なくなるため、他のパッケージでの作業が容易になります。
クローズしたパッケージはいつでも(他のサイトに送信する必要がある、またはコンテンツをエクスポートしたい場合など)再オープンすることができます。 パッケージを再オープンするには、[表示と検索(View and Search)] ペインでそれをクリックして、[アクション(Action)] ペインで [再オープン(Reopen)] をクリックします。
パッケージを削除するには、[表示と検索(View and Search)] ペインでそれをクリックして、[アクション(Action)] ペインで [削除(Delete)] をクリックします。 削除を確定するには、[はい(Yes)] をクリックします。 展開用パッケージを削除すると、パッケージと展開履歴が現在のサイトから完全に削除されます。 パッケージ内容は圧縮されますが、パッケージ コンポーネントを表すために必要な XML は非常に大きくなることがあります。 したがって、パッケージを削除すると、リポジトリ/データベースで使用可能なスペースを取り戻せます。 パッケージを過去にエクスポートしたことがある場合は、パッケージの内容を復旧できます。ただし、現在のサイトのパッケージの完全な展開履歴を復旧することはできません。
多くの場合、ビルド プロセスの一部として同じエンティティを複数回展開する必要があります。 たとえば、1 つ以上のサービスを開発環境からテスト環境に展開したとします。次に、修復が必要ないくつかの不具合をテスターが見つけると、開発環境でサービス定義が修復されて再展開されます。次に、本番環境に展開する前にテスト環境で修正が確認されます。
展開用パッケージのコピー機能はこのワーク フローを容易にします。 目的のコンテンツを持つ最初のパッケージが作成されたら、このパッケージをコピーできます。
パッケージをコピーするには、以下を実行します。
ステップ 1 | [表示と検索(View and Search)] ペインでパッケージを選択します。 |
ステップ 2 |
[アクション(Action)] ペインで、[コピー(Copy)] をクリックします。 [パッケージのコピー(Copy Package)] ダイアログボックスが表示されます。 |
ステップ 3 | パッケージの名前を変更します。 |
ステップ 4 | [パッケージのコピー(Copy Package)] をクリックします。 |
ステップ 5 |
[OK] をクリックします。 新しいパッケージが作成され、[未送信(Not transmitted)] のステータスで開かれます。このパッケージには、アセンブリされたパッケージ コンテンツではなく、[コンテンツ(Content)] ペインで指定されたエンティティが含まれます。 次に、必要に応じて、パッケージを再アセンブリできます。 |
[アクション(Action)] ペインの [履歴(History)] セクションの [ログの表示(View Log)] リンクに、Catalog Deployer によるアクションの詳細が表示されます。 [ログの表示(View Log)] リンクをクリックすると、[ログの表示(View Log)] タブが開いて、[ログの詳細(Log Details)] と [XML出力(XML Output)] というサブタブが表示されます。 ログには、パッケージが受けるすべてのアクティビティが記録されます。 アセンブリ ログには、パッケージに含まれるすべてのエンティティが表示されます。 展開ログには、ターゲット サイトで正常に抽出されたすべてのエンティティが表示されます。 パッケージの展開に失敗した場合、エラーも表示されます。
ログには、すべてのパッケージの詳細(名前、説明)、組み立てまたは展開の時刻の日時スタンプ、および含まれているすべてのエンティティが含まれます。
Catalog Deployer はエンティティの名前変更をサポートしていません。 ソース サイトでエンティティ名を変更し、そのエンティティを展開しようとしたり、名前を変更したエンティティを参照するサービスを展開したりすると、CatalogDeployer は正常に機能しません。 関連エンティティとの関連付けを設定(再設定)するために、Catalog Deployer はそのエンティティをターゲット サイトで名前により見つけようとします。 展開の目的上、エンティティ「名」は、人員(ログイン名によって識別)および組織(組織タイプと名前の組み合わせによって識別)を除くすべてのエンティティの名前属性です。 結果は次のようになります。
回避策は次のとおりです。
展開プロセスの間は、エンティティ名の変更状況を注意深くモニタリングし、前述の説明のように、ターゲット サイトにエンティティが適用されることを確認する必要があります。その後、ターゲット サイトへのエンティティの展開を試みます。
目標テーブルと課金レート テーブルで参照されている測定単位は展開パッケージで収集されません。 ターゲット サイトで Administration モジュールを介してサービスまたは課金レートに対して設定された新しい測定単位を作成してから、それらを参照するパッケージを展開する必要があります。
ここでは、頻繁に行われるいくつかの開発シナリオおよび展開シナリオで使用する推奨手順の詳細を示します。
新しい Service Catalog サイトを作成する必要があります。 1 つのオプションは、既存の Service Catalog データベースをサイトにコピーし、そのデータベースを使用するようにインストールおよび設定を調整する方法です (この手順については、このガイド(http://www.cisco.com/en/US/products/ps13206/prod_technical_reference_list.html)を参照してください)。また、データベースの初期設定を行い、Catalog Deployer を使用して新しいサイトの生成に必要なすべてのエンティティを展開する方法もあります。
Catalog Deployer は、Service Catalog の進展に伴い一般に変化しない Service Catalog の設定面は展開しません。 したがって、初期サイトに対して行ったように、これらの要素を定義する必要があります。
Organization Designer によって保守されるエンティティ(人員、組織、グループ、ロール、および役職)は、サービス定義がこれらのエンティティを参照できるように、その前にサイトに存在していなければなりません。 そのため、これらのエンティティはすべて、サービス カタログを展開する前に展開する必要があります。 また、これらのエンティティは、1 つ以上のカスタム展開パッケージに含める必要があります。
さらに、カスタム電子メール テンプレートをすべて展開する必要があります。 電子メール テンプレートは、それを使用するサービスが展開される前ならいつでも展開できます。
基盤エンティティを展開したら、サービスを展開できます。 初期展開では、パッケージ サイズを管理できるサイズにし(つまり、サービス グループごとにグループ化し)、ログを慎重に確認します。 すべての関連エンティティが事前に展開されているはずなので、基本展開を使用する必要があります。
これで 2 つ(以上の)サイトが稼働している状態です。 本番サイトのサービスはすべて、開発サイトのサービスと同一である必要があります。 (開発サイトには初期展開の一部である他のサービスが存在することもありますが、それは問題ありません。)どの環境で、グループ、ロール、および組織のエンティティ定義とメンバーシップを定義するのかが問題です。 すべてのケースにおいて、エンティティ保護レベルは、ホーム以外の環境にあるエンティティに対するメンテナンスは回避するように設定されます。
最も単純なアプローチは、サービス定義を構成するすべてのエンティティのホームを開発インスタンスにし、人と組織のすべての関連エンティティのホームを本番インスタンスにする方法です。
これによって、Catalog Deployer の使用およびそれが展開するエンティティの保守が非常に簡単になります。つまり、すべてのエンティティのすべての面が常に 1 つのサイトのみで保守されます。 ただし、ディレクトリ関連エンティティの作成およびテストのワーク フローは複雑になります。
このシナリオでは、ディレクトリ関連エンティティに関するすべての作業(サービス定義内での実際のエンティティ参照を除く)は 1 か所、つまり本番環境で行われます。 これは推奨されるプロセスです。つまり、すべての作業が 1 か所で行われるため、確認とモニタリングが容易になります。 ただし、このプロセスでは次のような不都合が生じることがあります。
代替アプローチは、サービス定義を構成するすべてのエンティティのホームを開発インスタンスにし(これは変更不可)、人員と組織の関連エンティティのホームを本番インスタンスと開発インスタンスの両方にする方法です。
組織、グループ、ロール、人員などのエンティティのホームを両方のインスタンスにすることには、次のような利点があります。
組織、グループ、ロール、人員などのエンティティのホームを両方のインスタンスにすることには、次のような欠点があります。
たとえば、メンバがさまざまな組織の人々で構成されるグループを作成しているとします。 次の項では、グループにメンバを割り当てる方法について説明します。
新しいキューを使用するには、新しいサービスを開発するか、既存のサービスを拡張する必要があります。 ベスト プラクティスに従って、キューは、そのホームになっている対応するサービス チーム組織を持つようにすべきです。
キューおよび組織の「ホーム」を設定した場所に応じて、ここでは 2 つのシナリオが考えられます。 それぞれに利点と欠点があります。 (これは前項の説明の特殊ケースですが非常に頻繁に起きます)。
これは、すべての作業を本番サイトの組織、人、キューに置く「クリーン」アプローチです。 2007 よりも前の Service Catalog バージョンにおいて実行可能な唯一のアプローチだったため、それらのバージョンからアップグレードする人はその使用を継続することを好む場合があります。
このシナリオでは、エンティティの定義のホームが開発サイトにあり、そのメンバーシップのホームが本番サイトにあります (もちろん、この分割は Entity Homes によって実施することはできません。したがって、Organization Designer によるメンテナンスを許可するために、両方のサイトがエンティティのホームとして指定されます)。
前述の両シナリオでは、初期展開後に初期のキューと OU に対して可能な変更について確認しました。
次の 2 つのパッケージが必要です。
カスタム パッケージが基本サービス パッケージの前に展開されている場合は、それぞれのパッケージが作成時の状態で展開されます。
特定のキューに割り当てられているタスクを含む、複数のサービスを展開後、キューの名前がサービス実施者に誤解を与えているため、名前を変更したいというフィードバックを受け取ることがあります。 または、会社組織が再編成されていて、組織(サービス チームを含む)の名前を新しい組織を反映したものに変更する必要がある場合があります。
これは既知のエラーおよび欠落で説明した「既知のエラーおよび欠落」と衝突します。 Catalog Deployer はサイト間でエンティティの名前を一致させて動作するため、名前変更されたエンティティとの一致は不可能です。 場合によっては(上述のように)、Catalog Deployer は失敗してエラーを報告します。 ただし、別のケースでは、Catalog Deployer はターゲットに新しいエンティティを作成します。 名前変更されたキューに関しては、以前に展開されたすべてのサービスが引き続き古いキューを使用します。 キューが名前変更され展開された後で展開されたサービスのみが新しいキューを参照します。 これは明らかに設計者の意図に反します。
この動作を防ぐ唯一の方法は、名前を変更する必要があるエンティティを注意深くモニタリングおよび制御するプロセスを整備することです。 このプロセスは、キューおよび組織のホームが本番サイトだけにあるか、本番サイトと開発サイトの両方にあるかに応じて若干異なりますが、いずれの場合も両方のサイトでエンティティの手動による名前変更(Organization Designer を介して)が必要です。
次のシナリオを考慮する必要があります。
カテゴリは、基本サービスまたは拡張サービスの展開の一環として、コンポーネント エンティティとして展開されます。 これは、主な目的が新規または修正したサービス定義を展開し、関連カテゴリも展開されるようにする場合には効果的な方法です。 ただし、カテゴリ階層またはカテゴリに関連付けられているイメージが変更されている場合には、サービス パッケージの使用は効果的ではありません。
カスタム展開パッケージには、階層を参照している可能性があるサービスとは無関係に、カテゴリ階層のすべてまたは一部を展開するためのオプションがあります。 カテゴリ構造がターゲット環境に展開されるときに、Catalog Deployer は各カテゴリおよびそのサービス間の関連付けを自動的に再設定します。
通常どおり、エンティティ名(このケースではカテゴリ)の単純な変更に対する警告が適用されます。 もう適用されないカテゴリがある場合は、そのカテゴリのサービスへの関連付けを削除し、新しいカテゴリを作成して、置き換える必要があります。 あるいは、ソースとすべての対象インスタンスでカテゴリの名前を変更します。
Service Designer は、アップグレード プロセスによって生成された固有な名前を持つエンティティを認識できます。
Service Designer は、少なくとも、アップグレード プロセスで作成されたアーティファクトの名前を、よりユーザにわかりやすい名前に変更したいと考えます (また、再使用を促進するためにフォーム コンポーネントの構造のリファクタリングも望む場合もありますが、それは別の問題です)。次に示すのは「標準的な」名前変更シナリオです。
開発サイトで OU に関連した役職を定義して、1 つまたは 2 つの組織に対してその役職を保持している個人を指定しています。 開発サイトのサービスを、その役職にタスクをルートするように変更しています。 この場合、次の手順で、新規および変更済みのエンティティを展開します。
Administration 設定で [ブラウザキャッシュ(Browser Cache)] 設定が有効になっている場合は、サービス カタログ プレゼンテーション内のアイコンと埋め込み画像に加えられる変更は、ブラウザ キャッシュが削除されるまで有効になりません。 アプリケーション ユーザにそれぞれのブラウザ キャッシュの削除を要求するには、このガイドの手順に従ってブラウザ キャッシュのバージョンを上げてください。
シスコでは、特定の製品リリースにおいてブランド化コンテンツ ライブラリの形でコンテンツを提供します。 ご使用のリリースに関してこのようなコンテンツ ライブラリが使用できるかどうかは、Cisco Technical Assistance Center(TAC)にお問い合わせください。 使用可能なライブラリ パッケージには次の 2 種類があります。
これらのライブラリ内のサービスは、エンド ユーザ管理、アクセス管理、データセンター管理、およびその他の領域で一般的に必要なサービス用のモデルを提供します。 ライブラリ コンテンツはプレビューすることができ、必要な項目を開発環境に展開することができます。 そのため、企業の要件に合わせたサービスの設計、設定、およびカスタマイズを迅速に行うことができます。
カスタム ライブラリには、サービス内で参照されるキューやサービス チーム(組織)などのエンティティが含まれています。 このライブラリは、オプションで、対応するサービス ライブラリと一緒にインストールできます。 カスタム ライブラリが展開されている場合は、サービスで事前定義の参照が使用されます。 カスタム ライブラリがインストールされていない場合は、必要に応じて、サービスで「デフォルト サービス キュー」が参照されたり、参照が削除されたりします。 サービス設計者には、タスク(提供)計画の設定を完成させる責任があります。
一般に、サイト管理者はブランド化ライブラリのコンテンツを管理および展開する責任があります。 必要に応じて、ブランド化コンテンツ ライブラリを展開する権限を持つカスタム ロールを作成できます。 ロールの作成と割り当ての詳細については、組織の構築またはオンライン ヘルプを参照してください。
以下の手順を使用して、ブランド化ライブラリを展開します。
ステップ 1 | ライブラリを入手します。 ライブラリと対応するユーザ マニュアルはシスコのソフトウェア サイトからダウンロードできます。 |
ステップ 2 | ライブラリをインストールします。 ライブラリは、クライアント ワークステーションがアクセス可能なディレクトリ(Catalog Deployer がそこから実行されます)にインストールする必要があります。 共有のネットワーク ドライブをライブラリの中心のストレージにできます。 |
ステップ 3 | ライブラリ コンテンツの展開を担当するユーザが、この機能を含むロールを持っていることを確認します。 |
ステップ 4 | ライブラリをインポートします。 ライブラリを Catalog Deployer にインポートします。 ライブラリ パッケージのインポートを参照してください。 |
ステップ 5 |
ライブラリ コンテンツを確認します。 ライブラリ パッケージを展開する権限を持っているユーザが、対象サイトで受け取ったパッケージを選択し、状況に応じて、ライブラリ コンテンツ(サービス)をプレビューします。 ライブラリ コンテンツをプレビューするには、プレビューするサービスのチェックボックスをオンにして選択し、[プレビュー(Preview)] をクリックします。 |
ステップ 6 | 選択したライブラリ コンテンツを展開します。 受信するパッケージを選択し、展開するパッケージ コンテンツを選択して、展開を実行します。 ライブラリの展開を参照してください。 |
ステップ 7 | 展開ログを確認します。 ライブラリ コンテンツを展開すると、エンティティ定義の作成または更新に関する、すべての展開アクティビティの詳細なログが生成されます。 |
サイト管理者とカタログ パブリッシャのロールには、ブランド化コンテンツ ライブラリから内容をインポート、プレビュー、または展開するための [展開のインポート(Import Deployments)] および [展開用パッケージの展開(Deploy Deployment Package)] 機能が含まれます。
ライブラリ パッケージのインポートは、展開用パッケージのインポートと似ています。
ステップ 1 |
[表示と検索(View and Search)] ペインで、[アクション(Action)] > [インポート(Import)] を選択します (そのオプションが使用不可の場合は、現在のユーザに、「ブランド化ライブラリ コンテンツの展開」機能を含むロールがありません)。 [インポート(Import)] ダイアログボックスが表示され、インポートするライブラリ ファイルを参照するように求められます。 |
ステップ 2 | [参照(Browse)] をクリックします。 |
ステップ 3 | ライブラリ ファイルを見つけて、選択します。 |
ステップ 4 | [開く(Open)] をクリックします。 |
ステップ 5 |
[インポート(Import)] をクリックします。 ライブラリがインポートされ、[展開用に受信(Received for Deployment)] ステータスが割り当てられて、開かれます。 |
ステップ 6 | [インポート(Import)] ダイアログボックスを閉じます。 |
ライブラリ パッケージにはライブラリを識別し、その展開の詳細がわかる属性があります。
属性 |
説明 |
---|---|
[パッケージ名(Package Name)] と [説明(Description)] |
ライブラリの名前とそのコンテンツの簡潔な説明。 |
ライブラリ バージョン(Library Version) |
ベンダーがリリースしたライブラリのバージョン。 |
ベンダー名 |
シスコ、またはコンテンツ提供者の名前。 |
アプリケーション バージョン(Application Version) |
ライブラリの展開がサポートされているデータベースのバージョン。 ライブラリは特定バージョンの Service Catalog に合わせてカスタマイズされています。 |
画像 |
ライブラリに関連付けられたイメージ アイコン。 |
パッケージタイプ(Package Type) |
サービス ライブラリまたはカスタム ライブラリ。 |
Status |
ライブラリの現在のステータス。 [受信済み(Received)] または [展開済み(Deployed)] のいずれか。 |
[作成日(Created On)]/[作成者(Created By)] [変更日(Modified On)]/[変更者(Modified By)] |
Catalog Deployer は、このサイトのライブラリを作成した(つまり、ライブラリをインポートした)人と、最新の展開アクティビティの日付とそれを実行した人を自動的に追跡します。 |
履歴(History) |
このサイトのライブラリに対して実行されたすべての展開アクティビティの簡潔なログ。展開の詳細を見るためのより詳細なログへのリンクが付いています。 |
適切なロールを持っているライセンスされたユーザは、[表示と検索(View and Search)] ペインで [アクション(Action)] > [新しいライブラリパッケージ(New Library Package)] を選択することによって、新しいライブラリを作成できます。
手順は、次の例外を除いて、展開パッケージの作成手順(展開用パッケージの作成を参照)と同じです。
オレンジ色のボール アイコン がデフォルトで新しいライブラリに関連付けられ、[表示と検索(View and Search)] ペインの最初の列に表示されます。 ライブラリ パッケージが保存されたら、[アクション(Action)] ペインで [イメージのアップロード(Upload Image)] をクリックすることによって、カスタム イメージ アイコンも使用できます。 イメージは JPG、PNG、または GIF 形式にすることができます。 これらは 16 ピクセルの幅と 16 ピクセルの高さで表示されるため、この縦横比を維持するように作成する必要があります。 イメージのサイズが正しくない場合は、ブラウザによってサイズが変更され、ぼやけたり、ノイズが入ったりすることがあります。
ライブラリはシスコから顧客サイトへ配布される新しいコンテンツの伝達手段です。 ライブラリは開発サイトにのみ展開する必要があります。 Catalog Deployer は、顧客の要件に合わせて以前にカスタマイズされた可能性のある既存のコンテンツを混乱させたり上書きしたりすることなくライブラリを展開できるように設計されています。 そのため、ライブラリ パッケージを展開するためのオプションは、ライブラリ コンテンツが、対象サイトに同じ名前で作成されているコンテンツを置き換えるのではなく、補完できるように設定されています。
サポート エンティティ(キューや組織単位など)を含んでいるライブラリのコンテンツ全体は、同時に展開する必要があります。 逆に、Catalog Deployer を使用すれば、展開するサービス ライブラリの内容を選択することができます。 各サービスは、別々のトランザクションに展開されます。 展開に失敗すると、現在のトランザクションがロールバックされます。
すべてのインポート アクションと展開アクションがライブラリ パッケージ用に記録されます。 [履歴(History)] セクションの [ログの表示(View Log)] リンクに、Catalog Deployer によるアクションが詳しく表示されます。 既知のエラーおよび欠落を参照してください。
用語 |
定義 |
---|---|
パッケージのアセンブリ |
コンテンツをパッケージに追加します。 パッケージを組み立てると、パッケージに含まれているオブジェクトの現行定義がリポジトリから抽出され、パッケージに書き込まれます。 これらのオブジェクトに対してアセンブリ以降に加えられた変更は、アセンブリされたパッケージに反映されません。 |
関連付けられた単位 |
プライマリ エンティティに関連するエンティティです。対象サイトで展開を成功させるために必要です。 たとえば、サービス定義(プライマリ エンティティ)は、タスクが割り当てられているいくつかの組織、サービス チームを参照する可能性があります(組織単位は、関連エンティティです)。 |
Catalog Deployer |
あるサイトから別のサイトへのカタログ コンテンツおよびディレクトリの展開を担当する Service Catalog モジュール。 |
コンポーネント エンティティ |
サービスを展開する際に自動的に展開されるエンティティです。 サービス コンポーネント エンティティには、カテゴリ、プレゼンテーション要素、ディクショナリ、ディクショナリ グループ、サービス グループ、キーワード、および目的が含まれます。 |
データ ソース(Data Source) |
アプリケーション サーバ コンソールの JDBC データ ソース ページで定義されるデータ ソース。Catalog Deployer による直接のサイト間展開の対象となるサイトすべての接続情報を指定します。 |
展開用パッケージ |
Catalog Deployer によって管理されるプライマリ オブジェクト。 展開用パッケージには、選択された、展開予定のエンティティ(サービス定義、キュー、グループなど)、および展開アクティビティ履歴が含まれます。 展開用パッケージは、コンテンツを対象サイトに展開するために他のサイトに送信またはエクスポート/インポートすることができます。 展開パッケージには、それが「組み立て」られ、その時点で含まれるデータがソース サイトから抽出されるまで、エンティティ コンテンツは含まれません。 |
エンティティ(Entity) |
Service Catalog ソフトウェア内で作成され保守されるオブジェクトの 1 つ。 例:組織単位、サービス定義、キュー、および電子メール テンプレート。 |
エンティティ ホーム(Entity Home) |
いずれのサイトが、サポートされる各エンティティ タイプの正式サイトであるかを管理者が指定する、Administration モジュールの設定のページ。 |
パッケージのエクスポート |
すでにアセンブリされたパッケージのコンテンツを含む XML ファイルを作成し、そのファイルをファイル システムに書き込みます。 ソース サイトから対象サイトへのパッケージのエクスポートは、パッケージ送信の代替手段です。 |
実装 |
直接または間接に接続されている 1 つ以上の Service Catalog サイトのグループ。 |
パッケージのインポート |
以前にエクスポートされた XML 展開用パッケージを対象サイトにインポートすることにより、パッケージを作成します。 パッケージはステータス [展開用に受信(Received for Deployment)] で作成されます。 |
ライブラリ パッケージ |
事前に組み立てられた、ファイル インポートとして使用可能なシスコのパッケージ。 パッケージ内容は、サービス カタログの基礎を提供するために使用できるテンプレート サービス、または関連エンティティで構成されています。 展開用パッケージと異なり、ライブラリの選択されたコンテンツは展開することができます。 |
プライマリ エンティティ |
Catalog Deployer パッケージに含めるために選択できるエンティティ。 |
サイト |
データベースおよび http アドレスを共有する 1 つ以上のコンピュータ システム(単一のコンピュータまたはクラスタ)の集合で、機能によって分類できます。 たとえば、開発サイト、テスト サイト、および本番サイトです。 |
ソース サイト |
パッケージが作成されるサイトです。 他のサイト上で展開するパッケージを送信またはエクスポートします。 |
対象サイト |
パッケージが展開されるサイトです。 送信またはインポートを使用してパッケージを受信します。 |
送信 |
データベース接続を使用して、あるサイトから別のサイトにパッケージを送信します。 ジョブを送信すると、ソース サイトでそのジョブの編集(再アセンブリやコンテンツ変更)はできません。 ターゲット サイトは Catalog Deployer 経由で送信を受信します。 |
目次
この章は次のトピックで構成されています。
Catalog Deployer は、サービス設計者、カタログ発行者、財務管理者、および組織構築リソースが開発サイト、テスト サイト、および本番サイト間でアプリケーション エンティティを移行するためのコンテンツ展開と構成管理に使用できます。
また、Catalog Deployer は変更管理プロセスと変更履歴を顧客に提供することによって、コンテンツの変更や Service Catalog のすべてのモジュールで使用される組織エンティティの変更に対する信頼性の高い制御を可能にします。
Catalog Deployer では、シスコによりブランド化コンテンツ ライブラリ内にパッケージされた事前設定サービスの展開もサポートされています。 このようなサービスは、そのままの状態で、または組織要件に対してサービス定義をカスタマイズするためのテンプレートとして使用できるため、実行可能なサービス カタログの実装に必要な時間と労力が大幅に削減されます。
Catalog Deployer には 2 つのコンテンツ展開方法が用意されています。
他のすべての Service Catalog モジュールと同様に、Catalog Deployer は使用のための権限を付与できます。 ユーザには、展開履歴の表示、展開パッケージの作成と組み立て、特定のサイトへのパッケージのインポートや展開を行う権限、またはこれらをユーザの責務に最適になるように組み合わせた権限を持たせることができます。 このような機能はすべて、Organization Designer モジュール内の標準ロールまたはカスタム ロール経由で割り当てることができます。
主な機能は次のとおりです。
Catalog Deployer は、カスタマイズされたサービス カタログの基礎を形成するためのテンプレート コンテンツを提供する Service Catalog の試みの最初で使用することができます。 また、Catalog Deployer は開発作業のビルドおよびメンテナンスの段階で使用して、テスト済みコンテンツを開発から他の環境にプロモートしたり、複数の環境を同期させたりもできます。
この章の次の項では、シスコ コンテンツ ライブラリをインストールしてサービス カタログやサービス ポートフォリオの基礎を提供するための Catalog Deployer の使用に関連する機能を説明します。
Catalog Deployer には、アプリケーションにある論理エンティティに基づいて編成された、データベース中立のデータ転送インフラストラクチャおよびインターフェイスがあります。 論理エンティティの例としては、サービス定義、データ ディクショナリ、人員、および組織単位などがあります。 完全なリストは、この項の最後にあります。 ただし、異なるデータベースやアプリケーション環境間のカスタム コンテンツのサポートは制限されています。 Catalog Deployer でサポートされないエンティティのリストについては、サポートされていないエンティティを参照してください。
実装、サイト、およびエンティティ ホームについては、表 1に説明があり、これらは Catalog Deployer の操作に不可欠です。
特に、論理エンティティのホーム サイトは Catalog Deployer での構成管理に欠かせない部分です。 Catalog Deployer ではオプションですが、論理エンティティに対してホーム サイトのシステムを作成することによって、サイト間の論理エンティティの参照整合性と、サイト間の設定情報の整合性の両方の管理が可能になります。
論理エンティティ ホーム サイトの背後にある概念は、特定のサイトは、他のサイトに比べ、論理エンティティ タイプについて、より信頼性の高いバージョンのデータを持っているというものです。 たとえば、ユーザ情報の認証および収集に自分の LDAP ディレクトリを使用しているカスタマーの場合、人員と組織単位について最も正確なデータがあるのは本番サイトということになります。 このため、本番サイトが、人員および組織単位のホーム サイト(記録のサイト)になります。 もし、本番サイト以外のサイトで人員の作成や組織単位の編集が可能な場合、このデータを他のシステムに展開すると、記録システムとの同期が失われ、実装におけるデータの品質が低下します。
そのため、アプリケーション フレームワークは、エンティティのホーム サイト以外のサイトでユーザがこれらのエンティティを修正することがないように、保護レベルを論理エンティティに割り当てることができるように設計されています。 サイト管理者は、Catalog Deployer の設定に説明されているように、4 つの設定から 1 つを選択することにより、論理エンティティに提供する保護のレベルを選択できます。
Catalog Deployer はエンティティの一部としてエンティティの権限を展開します。 権限がそのホーム サイトのエンティティから除去された場合、このアプリケーションは、Catalog Deployer がこの除去の複製のために使用できる削除スタブ(またはトランザクション ログ)を残しません。 たとえば、サービスをオーダーする権限がサービス定義の組織単位から除去されたとき、Service Catalog はこの事実を保持せず、権限を除去するだけです。
権限が変更されたサービスを展開すると、サービス定義とその権限の間のすべての関連付けが対象サイトにドロップされ、ソース サイトで有効な権限に従って再作成されます。 ただし、権限がカスタム ロールまたはグループに付与されている場合に、ロールまたはグループがソース サイトから削除されても、ロールまたはグループは対象サイトから削除されません。 Catalog Deployer はエンティティの削除をプロパゲートできません。
次の表は、Catalog Deployer によってサポートされているすべての論理エンティティと、それらに関連付けられたアプリケーション モジュールの一覧を示したものです。
モジュール |
サポートされているエンティティ |
---|---|
Service Designer |
サービス定義(提供、フォーム、フォーム セクション、計画、承認、権限) サービス定義とともに自動的に展開されるコンポーネント エンティティ。
サービス定義によって参照されるエンティティ。
|
サービス項目マネージャ(Service Item Manager) |
サービス定義とともに自動的に展開されるコンポーネント エンティティ。
|
Service Link |
|
Organization Designer |
|
管理(Administration) |
|
需要管理 |
|
Catalog Deployer は、上記のエンティティをソース サイトのデータベースからターゲット サイトのデータベースにコピーします。 Catalog Deployer は、ファイル システムに格納されている情報の移動、コピーは行いません。 Catalog Deployer は、JavaScript 関数に関連付けられたライブラリの定義をコピーします。
Catalog Deployer は、同じバージョンの Service Catalog を使用して実装されている 2 サイト間でトランザクション データベースに格納されている論理エンティティを移行します。 エンティティは .xml の形式でテキスト ストリームに抽出されます。これは展開用パッケージの一部であり、パッケージの作成に使用される仕様(任意)も含まれています。 そのパッケージは、バックアップ メカニズムとして、および別のサイトのターゲット データベースにエンティティ定義を展開するためのソースとして機能させるために、ソース データベースから抽出できます。 エンティティ定義は変更されずに対象環境に展開されます。
(注) |
Catalog Deployer は、.bmp 形式のイメージ(プレゼンテーション要素)の展開をサポートしていません。 Service Designer は現在、このようなイメージの指定ができないようになっています。 古い形式のイメージは、.jpg または .gif など、Web 上のプレゼンテーションに最適化された別の形式に変換する必要があります。 |
Catalog Deployer は論理エンティティ以外の Service Catalog のいずれのコンポーネントにも影響しません。 これらのコンポーネントのいくつかに対する変更は、Service Link によって処理される構成管理シナリオ(カスタマーが設計および構成した設定項目の実装間での同期)の一部でないため、これ以上ここでは検討する必要がありません。 次に例を示します。
ただし、追加の設定項目は、Catalog Deployer によって処理される論理エンティティに対する変更と組み合わせて展開しなければならない場合があります。 これらの詳細を、影響を受ける論理エンティティとともに、以下の表に示します。
設定項目 |
制御および移行する追加のアーティファクト |
---|---|
外部ディクショナリ |
データベースで実行される DML および DDL スクリプト |
データソース |
外部ディレクトリや、データ取得ルールで参照される SQL ベースのオプション リストまたはテーブルを参照するデータソースの指定 |
データ取得ルール |
ルールに直接入力される SQL ステートメント(異なるデータベース タイプ間では互換性がない場合がある) |
ISF スクリプト ライブラリ |
アプリケーション サーバに展開されるライブラリ(JavaScript)テキスト ファイル |
カスタム アダプタ |
Service Link の Adapter Development Kit(ADK)によって生成される展開ファイル |
重要なロールは次のように定義されます。
ロール |
定義 |
---|---|
Catalog Publisher |
サービス カタログの作成と管理、ランタイム アプリケーションへのカタログ コンテンツの展開、カタログのルック アンド フィールと構造の設定を行います。また、サービス定義と提供計画の変更に従って、展開されたカタログ コンテンツの継続的な更新を行います。 |
Service Designer |
カスタマー サイトでサービス定義を設計します。 サービス設計者は、カスタマー IT チームのカスタマーに提供されるサービスについて豊富な専門知識を持ち、Service Designer および Organization Designer の使用法に習熟しています。 サービス設計者は、技術的には中級ですが、一般的にはエンジニアというよりはビジネス アナリストです。 サービス設計者は、開発サイトでサービス定義を頻繁に作成したり変更したりしなければならない場合があります。 ステージング サイトまたは本番サイトへ作業をパブリッシュするために Catalog Deployer の使用が許可される人もいます。 |
Organization Builder |
カスタマー サイトで Organization Designer の組織エンティティを設計します。 組織ビルダーは、Service Catalog を正常に展開して使用するために必要な組織単位、グループ、およびロールの設定に関する組織のニーズについて豊富な専門知識を持っています。 組織ビルダーは、Organization Designer モジュールの使用法に習熟している必要があります。 組織ビルダーは、技術的に高度である必要はありませんが、アプリケーション管理の IT リソースである必要があります。 |
Site Administrator |
カスタマー サイトでアプリケーションの権限を管理します。 この担当者は、システムの最初のユーザになる場合があります。Global Configurations の設定など、アプリケーションのバック エンドのすべてにアクセスできます。言語や課金カテゴリなどのリストの管理も行います。 |
変更マネージャ |
カスタマー サイトで実装の変更要求を承認します。 この担当者は、通常、本番サイトの安定性に責任を負っています。本番サイトへの展開に先立ち、すべての変更内容を理解しておく必要があります。 このロールはオプションですが、正式な変更制御プロセスが確立されたカスタマー サイトで必要になります。 |
Finance Designer |
カスタマーのアカウントを作成し、各アカウントまたは OU のクォータを定義するための協定を設定し、サービス品目運用の課金料率を定義します。 カスタマーのサービス品目の消費と課金/チャージバックを管理します。 |
次の表は、Catalog Deployer モジュールに関して、システム定義のロールおよび各ロールに付与されるデフォルト機能を説明したものです。
定義済みの役割 |
機能 |
|||||
---|---|---|---|---|---|---|
基本サービス展開の管理 |
拡張サービス展開の管理 |
カスタム展開の管理 |
展開のインポート |
展開用パッケージの展開 |
ブランド コンテンツ ライブラリのパッケージング |
|
Catalog Designer and Administrator |
P |
P |
P |
|
|
|
Organization Designer |
|
|
P |
|
|
|
Site Administrator |
P |
P |
P |
P |
P |
P |
Catalog Publisher |
P |
P |
P |
P |
P |
|
Licensed Content Publisher |
P |
P |
P |
P |
P |
P |
この項では、Service Catalog の実装方法と、業界標準の構成(または変更)管理プラクティスをサポートする関連プロセスの設計方法を説明します。
以下では、一般的な方法と(Catalog Deployer 設定管理など)Service Catalog アプリケーションで使用可能な方法について説明し、両者を比較します。 初期開発からテスト、展開、およびメンテナンスまで、展開の段階に一致した、構成管理に対するさまざまなアプローチを説明します。
Catalog Deployer は、IT 業界標準の構成管理方法およびテクノロジーで採用されているベスト プラクティスを実装します。 そのため、これらのプラクティスを確認しておくと役に立ちます。
Service Catalog アプリケーションの場合は、開発されるソフトウェアの多くが、カテゴリ、グループ、タスク、チェックリストなどの関連要素を含むサービス定義です。
Catalog Deployer は、お客様が、サービス定義などのコンテンツや関連サービスを展開するために使用できます。
一般的な構成管理シナリオと Catalog Deployer が果たす役割には次のようなものがあります。
このシナリオは業界標準に従ったものです。業界標準では、開発環境においてのみ、サービス定義の変更が行われます。また、テスト環境および本番環境にソース コードの制御されたセットを展開するには、自動化されたプロセスが使用されます。
ただし、このシナリオは不完全です。 ほとんどの実装では、人員と事業単位(組織のタイプ)が、本番環境に動的に追加されたり、人員が初めて Service Catalog にログインしたときに彼らのためにサービスをオーダーしたり、審査または承認を実施するために割り当てられたりします。 したがって、Catalog Deployer は、これらのエンティティを本番サイトから開発に戻す移行のときも使用しなければなりません。それにより、まだ開発中のサービス定義または他の Service Catalog 設定項目(たとえば、承認)でそれらのエンティティを使用できます。 さらに、サービス定義は、電子メール テンプレート、グループ、キュー、サービス チーム組織、およびロールなどの関連エンティティを参照する場合があります。 これらのいずれかが対象環境に存在しない場合、足りないものを対象環境に展開しなければ、サービスの展開パッケージは正常に展開されません。
Catalog Deployer の設定には次の作業が含まれます。
(注) |
サービス パックを含むすべてのサイトで、同じ Service Catalog のバージョンを使用する必要があります。 |
(注) |
さまざまなデータベースからインポート(Catalog Deployer または REX を使用して)された「個人」と「エージェント」データのパスワードをターゲット データベースでリセットする必要があります。 これは、キー暗号キーが Prime Service Catalog データベースのインスタンスごとに異なるためです。 「個人」と「エージェント」のパスワードがリセットされなかった場合は、それらをターゲット データベースで正しく復号化できません。 |
Catalog Deployer によって生成される展開パッケージは、含まれるエンティティの圧縮された XML 表現を含みます。 Catalog Deployer はパッケージのファイルベース送信を使用します。その中で、パッケージ コンテンツは、パッケージのエクスポートおよびターゲット サイトへの以降のインポートにより、あるサイトから別のサイトへ転送されます。
このファイル ベースの転送をサポートするには、暗号化されたページをディスクに保存できるようユーザのブラウザを設定する必要があります。 次の手順を実行します。
ステップ 1 |
を選択します。 |
ステップ 2 | [暗号化されたページをディスクに保存しない(Do Not Save Encrypted Package to Disk)] チェック ボックスをオンにします。 |
ステップ 3 | [OK] をクリックします。 |
(注) |
すべての展開がサイト間の直接送信で行われている場合、この設定は不要です。 |
Catalog Deployer を使用する前に、開発インスタンスおよび本番インスタンスを使用して実装を設定する必要があります。 実装は、Catalog Deployer が Service Catalog サービス定義とその他の Service Catalog エンティティを移行するサイトを集めたものです。
実装とサイトの設定手順の概要は以下のとおりです。詳細は以降のセクションで説明します。
ステップ 1 | 実装に名前を割り当てます。 この名前は一般に会社やプロジェクトを表します。 この名前はマニュアル記載のみを目的とし、Catalog Deployer によって使用されることはありません。 | ||
ステップ 2 |
実装内のサイトに名前を付けます。 実装内では、各サイトに一意の名前を付ける必要があります。 Service Catalog は、エンティティの変更(追加、修正、削除)をユーザに許可する保護レベルを Service Designer および Organization Designer のページに割り当てるために、この固有の名前を使用してサイトを識別します。 通常、開発(DEV)と本番(PROD)の 2 つのサイトが必要です。 設定管理および移行計画で必要になった場合は、追加のサイト(STAGE、TEST、QA など)を使用できます。 |
||
ステップ 3 | 各論理エンティティのホーム サイトの指定 各論理エンティティにホーム サイトを(1 つ)指定します。 論理エンティティのホーム サイトを決定する際に、以下のルールが役立ちます。
|
||
ステップ 4 | 各サイトのデータ ソースの作成 Catalog Deployer でコンテンツをサイトに展開するためには、Service Catalog アプリケーションを実行しているアプリケーション サーバで、そのサイトの JDBC データ ソースを設定する必要があります。 たとえば、開発サイトで開発したサービスをテストおよび本番に展開するには、開発サイトは本番サイトおよびテスト サイトの両方のデータ ソースを含んでいなければなりません。本番サイトから開発に組織エンティティを展開するには、本番インスタンスは開発インスタンスのデータ ソースを含んでいなければなりません。 クラスタ化されたサイトの場合、サイトを構成する各ノードがデータ ソースにアクセスできる必要があります。 |
||
ステップ 5 | 各サイトでのプロセスの繰り返し 実装、サイト、および論理エンティティを指定するデータは、順番に、論理エンティティ内に格納されます。 これらの仕様は、実装を構成するすべての Service Catalog インスタンスに存在しなければなりません。 また、すべてのサイトで適切なデータ ソースを作成する必要があります。 |
Catalog Deployer を使い始めるには、Administration モジュールで実装環境の設定を行う必要があります。 Administration で設定した値により、ソース サイトは対象サイトを認識できるようになります。
アプリケーション サーバ コンソールの JDBC データ ソースのページでデータ ソースを定義した後で、次の手順を実行する必要があります。
実装を設定するには、次の手順に従います。
ステップ 1 | Administration 特権を持ったユーザとして開発インスタンスにログインします。 | ||||||||||||
ステップ 2 | モジュールのドロップダウン メニューから、[管理(Administration)] を選択します。 | ||||||||||||
ステップ 3 |
[Settings(設定)] タブをクリックします。 |
||||||||||||
ステップ 4 |
右側のメニューから、[Entity Homes] を選択します。 [論理エンティティのホームの仕様(Logical Entity Home Specification)] ページが表示されます。 これらの設定は、Catalog Deployer と Service Designer モジュールおよび Organization Designer モジュールの動作に影響します。 設定が正しくないと、間違ったデータが本番サイトを含む Service Catalog アプリケーション サイトに書き込まれる可能性があります。 これらの設定の変更は、システム管理者だけが行うようにする必要があります。 |
||||||||||||
ステップ 5 | [実装サイト(Implementation Sites)] セクションのページ下部にあるテキスト フィールドに、サイト名を入力します(例:「Development」)。 | ||||||||||||
ステップ 6 |
[データソースの選択(Select a Data Source)] ドロップダウン メニューからデータ ソースを選択し、[新規追加(Add New)] をクリックします。 サイト名のリストにこのサイト名が追加されます。 |
||||||||||||
ステップ 7 | 他のサイトとして、本番サイトの名前を追加します。 | ||||||||||||
ステップ 8 | QA または Test など、Catalog Deployer でリフレッシュする必要のある他のサイトが実装に含まれる場合は、これらも追加します。 | ||||||||||||
ステップ 9 | ページ上部にある [実装名(Implementation Name)] フィールドに実装名を入力します(例:My Cloud や Data Center Management)。 | ||||||||||||
ステップ 10 | 現在のサイトを識別するために [このサイト(This Site is)] ドロップダウン メニューから開発サイトを選択し、[更新(Update)] をクリックします。 | ||||||||||||
ステップ 11 | エンティティの [ホームサイト(Home Site)] の割り当てを確認し、要件に合わないところを変更します。 完了したら、[更新(Update)] をクリックします。 | ||||||||||||
ステップ 12 |
定義した各サイトに適切な [サイト保護レベル(Site Protection Level)] を割り当てます。 完了したら、[更新(Update)] をクリックします。 これらの保護レベルは、対応する論理エンティティの保守を行う Service Designer、Organization Designer、および Administration のページの動作を変更します。
|
Catalog Deployer がパッケージを別のサイトに送信するためには、ターゲット サイトに対応する JDBC データ ソースがソース サイトと同じアプリケーション サーバ上で設定されている必要があります。 JDBC データ ソースを設定する手順は、『Cisco Prime Service Catalog Installation and Upgrade Guide』に記載されている RequestCenter データ ソースを設定する手順と同じです。
Service Catalog でデータ ソースを検出するには、同じ JNDI 名プレフィックスを使用する必要があります。 検出されたデータ ソースのリストが [管理(Administration)] > [設定(Settings)] > [データソースレジストリ(Data Source Registry)] に表示されます。
特定のデータ ソースは、レポートを作成する目的で使用され、Service Designer や Catalog Deployer のユーザに表示するためには使用されません。 データ ソースをこれらのユーザーに必要なものだけに制限するには、これらのデータ ソースの [エンティティホーム定義に使用(Use for Entity Home Definition)] チェックボックスをオンにしてから、[更新(Update)] をクリックします。
最初に、1 つのサイトを設定します。通常は、開発サイトから始めます。 開発サイトは、ソース サイトに表示される他のターゲット サイトに移行されたサービス定義のソース サイトです。 実装全体の構成に応じて、どのサイトでもソース サイトまたはターゲット サイトとして、あるいは潜在的に両方のサイトとして、設定できます。
たとえば、テスト サイトと本番サイトが見えるように開発サイトを設定、および開発サイトとテスト サイトが見えるように本番サイトを設定します。 このシナリオでは、まず開発からテストにエンティティを展開します。次にテストが成功したと仮定し、開発から本番にエンティティを展開します。 次に、組織情報を本番サイトから、テスト サイトと開発サイトの両方に移行します。
必要なデータ ソースの定義を含め、潜在的なターゲット サイトの設定をすべてのソース サイトで繰り返します。
設定が正しいことを確認するには、各サイトにログインして、Catalog Deployer に移動し、[アクション(Action)] ペインで [送信(Transmit)] をクリックすることによって、パッケージを、今設定したターゲット サイトの 1 つに送信します。ドロップダウン メニューに選択可能なターゲット サイトの 1 つとして自分のサイトが表示されます。
Catalog Deployer は、ソース サイトまたはターゲット サイトがオンラインで使用中の場合に実行する必要があります。 ただし、この使用には何らかの制限を設けることをお勧めします。
Catalog Deployer は、パッケージの組み立てや展開だけでなく、サービスのプレビューにも大量のメモリを消費します。 メモリ消費から生じる問題を避けるために、Catalog Deployer では、6 人以上のユーザが同時にパッケージの組み立て、インポート、またはプレビューを行うことができないようになっています。 6 人目のユーザがパッケージの組み立て、インポート、またはプレビューを行おうとすると、Catalog Deployer からその旨のアラートが表示され、後で再試行するようにユーザに通知されます。 通常、本番展開は 1 人の担当者が処理するため、このような状態が本番環境で発生する可能性はあまりありません。しかし、開発環境やテスト環境で、複数のサービス設計者がそれぞれのコンテンツを展開のためにパッケージ化している場合は、この状態が発生することがあります。
パッケージの組み立てまたは展開は、まだブラウザを介した操作と見なされています。 そのため、Administration モジュールで設定された非活動用のセッション タイムアウトで、大規模なパッケージの組み立てや展開がタイムアウトすることはありません。
Catalog Deployer は、エンティティが複数のプライマリ エンティティに必要な場合に、関連付けられたエンティティをパッケージ内で 1 回作成/更新するだけです。 たとえば、展開パッケージ内の 20 のサービスにディクショナリ「IT Software Configuration」が必要な場合、Catalog Deployer はそのディクショナリをターゲット サイトで 1 回作成/更新するだけです。 共通コンポーネントを持つサービスを同じパッケージにまとめることで、パッケージのサイズと、Catalog Deployer が行う必要のある冗長な作成/更新の数を減らすことができます。
大きいパッケージ(サイズによって定義)のパフォーマンスは時間がかかることが予想されます。 また、このようなパッケージのアセンブリや展開は失敗する可能性があることにも留意してください。 この場合、解決するには、パッケージをプライマリ エンティティの比較的小さいセットに分けます。たとえば、20 個のサービスで構成される 1 つのパッケージを作成する代わりに、各 10 個のサービスのパッケージを 2 個作成します。
原則として、Catalog Deployer は 1 回のデータベース トランザクションで完全なパッケージを展開できます。 その場合、1 つのコンポーネントの展開に失敗すると(たとえば、指定されたキューがターゲット内に存在しないために拡張パッケージ内のサービス定義を展開できない)、全体のパッケージ内容がロール バックされます。 対象サイトのリポジトリは、展開が開始する前と同じ状態で維持されます。
ただし、実際には、この全か無かという展開によって問題が発生することがあります。 一度エンティティが展開されると、完全なパッケージが展開され、データベース トランザクションがコミットされるまで、オンライン ユーザはこれを使用できません。 この間に、ユーザが進行中の展開によって更新されたサービスのオーダーを試みると、ユーザのセッションはハングし、サービス定義が使用可能になるまで待機することになります。 最終的に、エラー メッセージが表示されるか(最悪の場合)、遅延の後サービスをオーダーできるようになります(最良の場合)。 (このエラーが発生する可能性があるのは、ユーザが最初にサービスをオーダーする場合のみです。タスク実行者や承認者がこのサービスで作業する場合には発生しません)。
このシナリオを回避する確実な方法の 1 つは、公開システムが使用中は展開を許可しないことです。 これは、定期的にスケジュールされたメンテナンス期間に公開システムに対する更新を行うという、業界で受け入れられているベスト プラクティスに準拠しています。 ただし、定期メンテナンスが実行されるまで展開を待機させることができない場合もあります。 Service Catalog が稼働中に展開を実施しなければならない場合に問題が発生する可能性を最小限に抑えるために、サービスをより小さな論理パッケージにグループ化することをお勧めします。 サービス設計者は、関連するサービスを同じパッケージにグループ化することによって、共有コンポーネントの小さくなったパッケージ サイズの恩恵を受けることもできます。
ここでは、Catalog Deployer の機能を簡単に説明します。 展開パッケージ タイプ(基本サービス、拡張サービス、およびカスタム)には、展開可能なプライマリ エンティティと、関連エンティティの管理展開に使用可能なオプションに違いがあります。
基本サービス展開用パッケージは、Service Designer でのサービス定義のインポートと同様の機能を果たします。 ターゲット サイトで関連するエンティティ(キューや組織単位など)が見つからなかった場合は、それらのエンティティが展開で省略されるだけです。 基本パッケージにはバンドルされたサービスを含めることができません。
サービス展開用パッケージは標準とサービス項目も収集します。 ルックアップ Dynamic Data Retrieval(DDR)とサービス項目ベースのディクショナリで参照されたものが自動的にパッケージに含まれます。 標準エントリも展開するかどうかを制御する Administration グローバル設定があります(標準エントリは必ず収集され、制御は展開ターゲットにのみ適用されます)。
(注) |
Catalog Deployer で展開用のサービスを表示または選択するために Service Designer の権限は必要ありません。 |
基本サービス展開用パッケージの内容とその関連するエンティティを以下に示します。
コンテンツ タイプ |
操作 |
エンティティ タイプ/説明 |
---|---|---|
プライマリ エンティティ |
[サービスの内容(Services content)] タブ経由で選択される |
サービス定義:Service Designer の [サービスカタログ(Service Catalog)] オプションで定義されたサービス定義のすべての側面 |
コンポーネント エンティティ |
自動展開 |
サービス定義によって参照されるすべてのエンティティ: |
関連エンティティ |
展開では、ターゲット サイトに存在しないエンティティ関連付けが省略されます。 |
サービス定義によって参照されるすべてのエンティティ:
|
デフォルトで、Catalog Deployer は標準データと標準定義を展開します。 この動作を無効にするには、Administration 設定を [標準テーブルのエントリ(データ)の展開(Deploy Entries (data) in Standards Tables)] に設定します。 さまざまな環境でさまざまなデータ セットを使用しなければならない場合や、データが外部ソースからファイル インポートを介して提供される場合などにこの方法を選択します。
拡張サービス展開用パッケージは、指定したサービス定義とそのコンポーネントを展開します。 このパッケージ タイプでは、対象サイトでの展開中にサービス定義の関連エンティティを処理する方法のオプションを制御する機能が提供されます。
拡張サービス展開は、基本展開とは次の 2 つの点で大きく異なります。
関連付けられたエンティティがターゲット サイトに存在しないときの拡張サービス展開パッケージにおける Catalog Deployer の動作を制御するオプションについて次に要約を示します。
関連付けられた単位 |
使用可能なオプション |
結果 |
---|---|---|
エージェント(Agent) |
省略(Skip) |
エージェントの参照が、提供タスクまたは承認タスクから削除されます |
|
失敗(Fail) |
展開が失敗します |
Eメールテンプレート(Email Template) |
作成(Create) |
対象サイトに空のテンプレートが作成されます。 |
|
省略(Skip) |
テンプレートの参照が、提供タスクまたは承認タスクから削除されます |
|
失敗(Fail) |
展開が失敗します |
役職(Functional Position) |
省略(Skip) |
役職との関連付けが削除されます。割り当てはデフォルト サービス キューに入ります |
|
失敗(Fail) |
展開が失敗します |
グループ |
省略(Skip) |
グループとの関連付けが削除されます。割り当てはデフォルト サービス キューに入ります |
|
失敗(Fail) |
展開が失敗します |
組織 |
省略(Skip) |
タスクがデフォルト サービス キューに割り当てられます |
|
失敗(Fail) |
展開が失敗します |
人員(People) |
省略(Skip) |
タスクがデフォルト サービス キューに割り当てられます |
|
失敗(Fail) |
展開が失敗します |
キュー |
作成(Create) |
キューは、対象サイトにそのキューの組織が存在する場合のみ作成されます。存在しない場合、展開が失敗します |
|
省略(Skip) |
タスクがデフォルト サービス キューに割り当てられます |
|
失敗(Fail) |
展開が失敗します |
ロール |
省略(Skip) |
タスクがデフォルト サービス キューに割り当てられます |
|
失敗(Fail) |
展開が失敗します |
サービスの定義を実質的に変更するので、[省略(Skip)] オプションおよび [作成(Create)] オプション(選択したエンティティ タイプにのみ使用可能)は、「クイック アンド ダーティ」展開にのみ有用と見なすべきです。 サービスのフォーム コンポーネントはそのまま転送されますが、提供計画に大幅な変更をもたらす可能性があります。
カスタム展開用パッケージを使用すれば、展開中に、エンティティを個別に選択して、関連エンティティを処理する方法に関するオプションを制御することができます。 カスタム展開は、人員、キュー、ロール、組織単位、エージェント、サービス項目、標準、課金レート、アカウント定義、契約テンプレート、カテゴリ、グループなどの組織エンティティ、役職、電子メール テンプレートに使用されるのが一般的です。 カスタム パッケージにはサービスを含めることができません。
サービス項目と標準展開の振る舞いを制御するよりきめの細かいオプションが用意されています。 オプションで、サービス項目インスタンスと標準エントリを展開の一部として含めることができます。 ただし、このオプションはパッケージ内のすべてのサービス項目タイプと標準に適用されます。 一部の標準またはサービス項目のエントリだけを含めて他のエントリは含めないようにするには、それらを別々のパッケージに分離する必要があります。
インポート中に、[需要管理(Demand Management)] > [課金レート(Billing Rate)] > [課金レート定義(Billing Rate Definition)] で単位レート フラグが設定(ソース XML)された場合は、Catalog Deployer でカスタム パッケージを作成するときに請求レートとして「マージ」オプションが選択されます。 レート表がターゲット内に存在する場合は、「マージ」オプションが無視され、ターゲット内の既存のデータ レコードを削除することによって「上書き」として実行されます。
「単位レート」フラグが設定されたレート表に対して、次の検証を実施する必要があります。 これは、需要管理、NSAPI、および REX フローにも実施する必要があります。
カスタム展開を使用してカテゴリを展開すると、ソース サイトのカテゴリ構造のすべてまたは一部を、ターゲット サイトに再作成できます。 選択したカテゴリとそれらのサブカテゴリが展開され、カテゴリが関連付けられているサービスとカテゴリの関係が、ソース サイトでの関係と一致するように再確立されます。 これは、基本展開パッケージで提供される機能を補完します。基本展開パッケージでは、展開しているサービスに関連付けられているカテゴリのみがパッケージに含まれます。
1 つのパッケージには、エンティティ間に相互依存性がある 2 つ以上のエンティティ タイプを含めることができます。 たとえば、人員は既存の組織に関連付ける必要があります。 Catalog Deployer は正しい順序で自動的にエンティティを展開します。そのため、これらの相互依存関係は維持できます。
さらに、同じタイプのエンティティ間に相互依存関係が存在することもあり、ある人員が別の人員をスーパーバイザとして指名したり、組織階層が存在したりします。 このような場合も、Catalog Deployer によってエンティティは正しい順序で(たとえば、スーパーバイザ エンティティが最初に)展開されるため、関係を再設定できます。
展開する各エンティティ(役職以外)に対して、パッケージに含まれる新しい定義で対象サイトのエンティティ定義を上書きする、または展開を省略するオプションを選択できます。
Catalog Deployer はターゲット サイトにエンティティが存在するかどうかを調べるのみで、(たとえば、ソースがターゲットよりも新しいかどうかを確認するために)コンテンツの検査を行わないので、エンティティ展開をスキップすることは危険です。 [スキップ(Skip)] オプションは、すでに存在するエンティティの再インストールを行わないでパフォーマンスを最適化できますが、その使用は限定された状況(たとえば、エンティティが存在するか不明であるターゲット サイトに大きいパッケージを初めて展開する場合など)で行ってください。 いずれかの面で展開に失敗する(たとえば、ホーム OU がターゲット サイトと現在の展開パッケージに存在しない人を展開しようとした)場合は、その欠落を修正してパッケージを再展開できます。 まだターゲット サイトに存在しないパッケージ コンテンツのみが展開されます。
エンティティ タイプ(電子メール テンプレート、役職、およびエージェント以外)ごとに、ターゲット サイトの他の関連エンティティとの関係の再設定に関して Catalog Deployer の動作を指定するオプションもあります。
展開中にソース サイトからターゲット サイトにインポートされたデータもマージすることができます。 このオプションは、サービス項目定義、標準定義、課金レート定義、および同意テンプレートに使用できます。
(注) |
ポータル ページとポートレット権限はロールを使って展開できます。 展開は、ポータル ページとポートレットが Portal Designer 経由でインポートされてから実施する必要があります。 |
ステップ 1 | 展開用パッケージを作成します。 Catalog Deployer にアクセスして使用する権限を付与されたユーザは、展開用パッケージを作成し、パッケージに含めるエンティティを選択できます。 展開用パッケージの作成を参照してください。 |
ステップ 2 | パッケージをアセンブリします。 基盤となるコンテンツが展開準備完了と見なされると、[アクション(Action)] ペインの [パッケージのアセンブリ(Assemble Package)] ボタンをクリックすると、展開用パッケージがアセンブリされます。 この時点で、Catalog Deployer はコンテンツを抽出し、展開用パッケージの一部として保存されるコピーを作成します。 パッケージのアセンブリが行われると、パッケージに含まれるエンティティへの変更は、パッケージが再アセンブリされない限りキャプチャされません。 展開用パッケージの組み立てを参照してください。 |
ステップ 3 | パッケージを送信します。 アセンブリされたパッケージは、展開のために対象サイトに送信されます。 パッケージは、Catalog Deployer 経由で送信できます。または、ソース サイトおよびターゲット サイト間に直接接続がなければ、このステップをエクスポートおよびインポート プロセスを使用して「オフライン」で実行する場合があります。 展開用パッケージの送信を参照してください。 |
ステップ 4 | パッケージを展開します。 パッケージを展開する権限を持つ担当者は、対象サイトで受信されたパッケージを選択し、展開を実行します。 パッケージの展開を参照してください。 |
ステップ 5 | ビュー レコード ログ ファイルに、各サイトの Catalog Deployer 内で発生するすべてのアクティビティが記録されます。 ログ ファイルを参照してください。 |
ステップ 6 | 展開中にサポートされないエンティティについては、サポートされていないエンティティ を参照してください。 |
(注) |
パッケージ定義が変更された場合のみ、パッケージを保存する必要があります。 パッケージのコンテンツは自動的に保存されます。 |
ステップ 1 | [表示と検索(View and Search)] ペインで を選択します。 |
ステップ 2 | [新規展開用パッケージ(New Deployment Package)] ウィンドウで、次の詳細情報を入力します。 |
ステップ 3 | [保存(Save)] をクリックします。 |
(注) |
|
パッケージにはその作成時にステータス [未送信(Not Transmitted)] が割り当てられます。 [表示と検索(View and Search)] ペイン内でこれをクリックすると、そのコンテンツが [内容(Contents)] ペインに表示されます。
コンテンツをパッケージに追加するには、次の手順を実行します。
ステップ 1 |
[内容(Content)]ペインで、[追加(Add)] ドロップダウン メニューをクリックし、そのパッケージのタイプで使用可能なエンティティのリストから、追加するエンティティ タイプを選択します。 [検索(Search)] ダイアログ ボックスが表示され、コンテンツを検索および選択できます。 |
ステップ 2 | チェック ボックスをオンにしてコンテンツを選択します。 |
ステップ 3 |
[追加(Add)] をクリックして、選択したコンテンツを追加します。 コンテンツが [内容(Content)] ペインに表示され、自動的に保存されます。 エンティティを削除する必要がある場合は、チェックボックスをオンにして、[削除(Remove)] と [はい(Yes)] を順にクリックします。 コンテンツは、パッケージが送信されるまで、いつでも追加および削除できます。 アセンブリされた後にコンテンツが変更された場合、パッケージを再アセンブリする必要があります。 |
基本および拡張サービス展開用パッケージでは、サービス定義のプレビューが可能です。
すでにパッケージに含まれているサービスの場合
パッケージの [内容(Content)] ペインに移動し、プレビューするサービスのチェックボックスをオンにして選択し、[プレビュー(Preview)] をクリックします。
サービスのプレビューはサービス定義の概要およびサービス フォームのレンダリングで構成されます。 すべてのエンティティ参照がプレビュー最後の [追加内容(Additional Content)] セクションにまとめられています。 これは、サービスを展開する前に対象環境にこれらのエンティティが存在することを確認するうえで役に立ちます。
[アクション(Action)] ペインで、[パッケージの組み立て(Assemble Package)] をクリックしてパッケージを組み立てます。 [OK] をクリックして、パッケージのアセンブリが成功したことを確認します。 パッケージを組み立てた後、そのステータスは [未送信(Not Transmitted)] のままです。 いずれかのコンポーネントの定義が変更された場合、または展開するエンティティの追加または削除を行った場合には再度組み立てることができます。 パッケージ組み立てのログ エントリには、指定されたプライマリ エンティティと一緒に展開されるコンポーネント エンティティの両方が含まれます。 [アクション(Action)] ペインの [履歴(History)] セクションで [ログの表示(View Log)] リンクをクリックすると、ログが表示されます。
コンテンツは、次の場合に別のサイトへ直接送信できます。
パッケージを送信するには、次の手順を実行します。
ステップ 1 | [表示と検索(View and Search)] ペインで、[表示(View)] ドロップダウン メニューを使用してステータスが [未送信(Not Transmitted)] のパッケージを表示します。 | ||
ステップ 2 | リストでパッケージを探します。 パッケージ名をクリックすると、そのパッケージの情報が他のペインに表示されます。 | ||
ステップ 3 | パッケージがアセンブリされていない場合、[アクション(Action)] ペインで、[パッケージのアセンブリ(Assemble Package)] をクリックします。 [OK] をクリックして、パッケージのアセンブリが成功したことを確認します。 | ||
ステップ 4 | [アクション(Action)] ペインで、[送信(Transmit)] をクリックします。 | ||
ステップ 5 |
ドロップダウン メニューからターゲット サイトを選択します。
|
||
ステップ 6 |
[今すぐ送信(Transmit Now)] をクリックします。 |
||
ステップ 7 |
[OK] をクリックして、送信が成功したことを確認します。 展開パッケージがターゲット サイトに送信されます。 ソース サイトの現在のパッケージのステータスは [送信済み(Transmitted)] に変更されます。 送信したパッケージは、他のサイトに送信したり、エクスポートしたりできます。 |
パッケージを送信する代わりに、パッケージをエクスポートすることができます。 パッケージをエクスポートすると、アセンブリされたパッケージのコンテンツで構成される XML ファイルが作成されます。 次に、エクスポート ファイルは、対象サイトにインポートされ展開されます。
パッケージをエクスポートすると、パッケージがテキストで表現されます。 エクスポートしたパッケージは、オフラインのアーカイブとして使用したり、会社のソース コード制御システムにチェック インしたりできます。
パッケージをエクスポートするには、次の手順を実行します。
ステップ 1 |
[表示と検索(View and Search)] ペインで、[表示(View)] ドロップダウン メニューを使用して [未送信(Not Transmitted)] または [送信済み(Transmitted)] ステータスのパッケージを表示します。
|
||
ステップ 2 | リストでパッケージを探します。 パッケージ名をクリックすると、そのパッケージの情報が他のペインに表示されます。 | ||
ステップ 3 | パッケージがアセンブリされていない場合、[アクション(Action)] ペインで、[パッケージのアセンブリ(Assemble Package)] をクリックします。 [OK] をクリックして、パッケージのアセンブリが成功したことを確認します。 | ||
ステップ 4 |
[アクション(Action)] ペインで、[エクスポート(Export)] をクリックします。 次の例に示されているように、[エクスポート(Export)] ダイアログボックスが表示されます。 |
||
ステップ 5 |
このダイアログボックスで、ファイル名のリンク(上記の例では、ファイル名のリンクは Basic Service Package02 です)をクリックします。 [ファイルのダウンロード(File Download)] ダイアログ ボックスが表示されます。 |
||
ステップ 6 |
[保存(Save)] をクリックします。 [名前を付けて保存(Save As)] ダイアログ ボックスが表示されます。 |
||
ステップ 7 |
必要に応じて、ファイルの名前を変更し、目的の宛先を選択します。 宛先は一般的には共有ドライブ上(Catalog Deployer の機能ですべてのユーザがアクセス可能)にします。 パッケージのトラッキングを円滑に行うには、ディレクトリの命名およびサブディレクトリの構造の標準を確立する必要があります。 たとえば、同じ変更要求の一部として展開されるすべてのパッケージに対して、新しいサブディレクトリを作成するなどです。 |
||
ステップ 8 | [保存(Save)] をクリックします。 | ||
ステップ 9 | [Close(閉じる)] をクリックして、[エクスポート(Export)] ダイアログボックスを閉じます。 |
セキュリティやその他の理由でソースから対象サイトへパッケージの直接送信が許可されていない場合、パッケージの送信の代わりにエクスポート/インポートを使用できます。 結果は同じです。つまり、パッケージは [展開用に受信(Received for Deployment)] ステータスでターゲット サイトに作成され、続いて展開できます。
ステップ 1 |
[表示と検索(View and Search)] ペインで、[アクション(Action)] > [インポート(Import)] を選択します。 [インポート(Import)] ダイアログボックスが表示され、インポートするファイルを探すように求められます。 |
ステップ 2 | [参照(Browse)] をクリックします。 |
ステップ 3 | パッケージ ファイルを見つけて、選択します。 |
ステップ 4 | [開く(Open)] をクリックします。 |
ステップ 5 |
[インポート(Import)] をクリックします。 展開用パッケージがインポートされ、[展開用に受信(Received for Deployment)] ステータスが割り当てられて、開かれます。 これで展開できるようになりました。 |
ステップ 6 | [インポート(Import)] ダイアログボックスを閉じます。 |
(注) |
展開用パッケージを最初にエクスポートしたソース サイトに再インポートするには、まずソース サイトから同一のパッケージを削除する必要があります。 ファイル名が変更された場合でも、アプリケーションは重複ファイルを認識します。 |
ステップ 1 | [表示と検索(View and Search)] ペインで、[表示(View)] ドロップダウン メニューを使用して [展開用に受信(Received for Deployment)] ステータスのパッケージを表示します。 | ||
ステップ 2 |
リストでパッケージを探します。 パッケージ名をクリックすると、そのパッケージの情報が他のペインに表示されます。
|
||
ステップ 3 | [アクション(Action)] ペインで、[展開(Deploy)] をクリックします。 | ||
ステップ 4 | [OK] をクリックして、展開が正常に完了したことを確認します。 |
展開が正常に完了すると、パッケージのステータスは [展開済み(Deployed)] に変更されます。
展開するパッケージのアセンブリされたコンテンツは、対象サイトのリリース レベルと一致する必要があります。 Catalog Deployer は、パッケージがアセンブリされたアプリケーション バージョンを追跡し、異なるバージョン間での展開を許可しません。
基本または拡張サービス パッケージには、展開されるサービスで使用するすべてのコンポーネント設計要素が含まれます。 ただし、データベースに格納されていない設計コンポーネントは展開用パッケージに含まれず、別に展開する必要があります。 これらの要素には次のものが含まれます。
展開は、原則として、展開が行われたときにインフライトであった要求によって使用されるサービスおよびコンポーネントの定義に影響を与えません。 ただし、要求プロセスの動的性質により、以前に送信された要求は次のものによる影響を受けます。
展開スケジュールおよびサービスの設計者は、サービス定義の以前のバージョンに基づいたインフライトの要求が上記の要素の変更による影響を受けることを考慮する必要があります。
1 つの機能で複数のパッケージを送信して展開できます。 Catalog Deployer は順番に各パッケージを処理し、それぞれのステータスを提供します。 この手順により、わずかなユーザ操作で大量のパッケージを展開することが容易になります。
複数のパッケージを送信するには、次の手順を実行します。
ステップ 1 | [表示と検索(View and Search)] ペインで、 を選択します。 |
ステップ 2 | [送信するパッケージの追加(Add Packages to Transmit)] をクリックして [検索(Search)] ダイアログ ボックスを開きます。ここで、送信するパッケージを検索して選択できます。 [検索(Search)] ダイアログ ボックスでは、ステータスが [未送信(Not Transmitted)](組み立て済み)および [送信済み(Transmitted)] のパッケージのみを選択できます。 |
ステップ 3 | 必要なパッケージのチェック ボックスをオンにして選択します。 |
ステップ 4 |
[追加(Add)] をクリックして、選択したパッケージを追加します。 パッケージが [パッケージ(Packages)] フォルダの下にアルファベット順に表示されます。 選択したすべてのパッケージが送信されます。 パッケージを削除する必要がある場合は、そのチェック ボックスをオンにして、[削除(Remove)]、[はい(Yes)] の順にクリックします。 |
ステップ 5 | [ターゲットサイトを選択(Select a target site)] フォルダの下で、ターゲット サイトのチェック ボックスをオンにして選択します。 |
ステップ 6 |
[送信(Transmit)] をクリックして送信を開始します。 パッケージが一覧表示された順序(アルファベット順)で送信されます。 送信プロセスが完了すると、ステータス メッセージが表示され、各パッケージの送信の成否が示されます (送信失敗の最も一般的な理由は、ソース サイトとターゲット サイト間のバージョンの不一致です)。 各パッケージのログファイルも更新されます。 |
ステップ 1 | [表示と検索(View and Search)] ペインで、 を選択します。 |
ステップ 2 | [複数パッケージの展開(Deploy Multiple Packages)] ウィンドウの [展開するパッケージの追加(Add Packages to Deploy)] をクリックして [検索(Search)] ダイアログ ボックスを開きます。ここで、展開するパッケージを検索して選択できます。 ステータスが [展開用に受信済み(Received for Deployment)] または [展開済み(Deployed)] の展開パッケージを選択できます。 |
ステップ 3 | 展開するパッケージのチェック ボックスをオンにして選択します。 |
ステップ 4 |
[追加(Add)] をクリックして、選択したパッケージを追加します。 パッケージが [パッケージ(Packages)] フォルダの下にアルファベット順に表示されます。 選択したすべてのパッケージが展開されます。 パッケージを削除する必要がある場合は、そのチェック ボックスをオンにして、[削除(Remove)]、[はい(Yes)] の順にクリックします。 |
ステップ 5 |
[展開(Deploy)] をクリックして展開を開始します。 パッケージが一覧表示された順序(アルファベット順)で展開されます。 複数送信と同様に、複数展開でも各パッケージの展開の成否が示されます。この情報は、パッケージのログ ファイルでも利用できます。 |
どの状態の展開用パッケージも、それが作成されたサイトの [表示と検索(View and Search)] ペインでそれをクリックして、[アクション(Action)] ペインで [クローズ済みとしてマーク(Mark as Closed)] をクリックすることによってクローズすることができます。パッケージをクローズすると、そのステータスが [クローズ(Closed)] に変わるだけで、そのパッケージは「クローズ」パッケージのビューにしか表示されなくなります。 これにより、探す対象のアクティブ パッケージが少なくなるため、他のパッケージでの作業が容易になります。
クローズしたパッケージはいつでも(他のサイトに送信する必要がある、またはコンテンツをエクスポートしたい場合など)再オープンすることができます。 パッケージを再オープンするには、[表示と検索(View and Search)] ペインでそれをクリックして、[アクション(Action)] ペインで [再オープン(Reopen)] をクリックします。
パッケージを削除するには、[表示と検索(View and Search)] ペインでそれをクリックして、[アクション(Action)] ペインで [削除(Delete)] をクリックします。 削除を確定するには、[はい(Yes)] をクリックします。 展開用パッケージを削除すると、パッケージと展開履歴が現在のサイトから完全に削除されます。 パッケージ内容は圧縮されますが、パッケージ コンポーネントを表すために必要な XML は非常に大きくなることがあります。 したがって、パッケージを削除すると、リポジトリ/データベースで使用可能なスペースを取り戻せます。 パッケージを過去にエクスポートしたことがある場合は、パッケージの内容を復旧できます。ただし、現在のサイトのパッケージの完全な展開履歴を復旧することはできません。
多くの場合、ビルド プロセスの一部として同じエンティティを複数回展開する必要があります。 たとえば、1 つ以上のサービスを開発環境からテスト環境に展開したとします。次に、修復が必要ないくつかの不具合をテスターが見つけると、開発環境でサービス定義が修復されて再展開されます。次に、本番環境に展開する前にテスト環境で修正が確認されます。
展開用パッケージのコピー機能はこのワーク フローを容易にします。 目的のコンテンツを持つ最初のパッケージが作成されたら、このパッケージをコピーできます。
パッケージをコピーするには、以下を実行します。
ステップ 1 | [表示と検索(View and Search)] ペインでパッケージを選択します。 |
ステップ 2 |
[アクション(Action)] ペインで、[コピー(Copy)] をクリックします。 [パッケージのコピー(Copy Package)] ダイアログボックスが表示されます。 |
ステップ 3 | パッケージの名前を変更します。 |
ステップ 4 | [パッケージのコピー(Copy Package)] をクリックします。 |
ステップ 5 |
[OK] をクリックします。 新しいパッケージが作成され、[未送信(Not transmitted)] のステータスで開かれます。このパッケージには、アセンブリされたパッケージ コンテンツではなく、[コンテンツ(Content)] ペインで指定されたエンティティが含まれます。 次に、必要に応じて、パッケージを再アセンブリできます。 |
[アクション(Action)] ペインの [履歴(History)] セクションの [ログの表示(View Log)] リンクに、Catalog Deployer によるアクションの詳細が表示されます。 [ログの表示(View Log)] リンクをクリックすると、[ログの表示(View Log)] タブが開いて、[ログの詳細(Log Details)] と [XML出力(XML Output)] というサブタブが表示されます。 ログには、パッケージが受けるすべてのアクティビティが記録されます。 アセンブリ ログには、パッケージに含まれるすべてのエンティティが表示されます。 展開ログには、ターゲット サイトで正常に抽出されたすべてのエンティティが表示されます。 パッケージの展開に失敗した場合、エラーも表示されます。
ログには、すべてのパッケージの詳細(名前、説明)、組み立てまたは展開の時刻の日時スタンプ、および含まれているすべてのエンティティが含まれます。
Catalog Deployer はエンティティの名前変更をサポートしていません。 ソース サイトでエンティティ名を変更し、そのエンティティを展開しようとしたり、名前を変更したエンティティを参照するサービスを展開したりすると、CatalogDeployer は正常に機能しません。 関連エンティティとの関連付けを設定(再設定)するために、Catalog Deployer はそのエンティティをターゲット サイトで名前により見つけようとします。 展開の目的上、エンティティ「名」は、人員(ログイン名によって識別)および組織(組織タイプと名前の組み合わせによって識別)を除くすべてのエンティティの名前属性です。 結果は次のようになります。
回避策は次のとおりです。
展開プロセスの間は、エンティティ名の変更状況を注意深くモニタリングし、前述の説明のように、ターゲット サイトにエンティティが適用されることを確認する必要があります。その後、ターゲット サイトへのエンティティの展開を試みます。
目標テーブルと課金レート テーブルで参照されている測定単位は展開パッケージで収集されません。 ターゲット サイトで Administration モジュールを介してサービスまたは課金レートに対して設定された新しい測定単位を作成してから、それらを参照するパッケージを展開する必要があります。
ここでは、頻繁に行われるいくつかの開発シナリオおよび展開シナリオで使用する推奨手順の詳細を示します。
新しい Service Catalog サイトを作成する必要があります。 1 つのオプションは、既存の Service Catalog データベースをサイトにコピーし、そのデータベースを使用するようにインストールおよび設定を調整する方法です (この手順については、このガイド(http://www.cisco.com/en/US/products/ps13206/prod_technical_reference_list.html)を参照してください)。また、データベースの初期設定を行い、Catalog Deployer を使用して新しいサイトの生成に必要なすべてのエンティティを展開する方法もあります。
Catalog Deployer は、Service Catalog の進展に伴い一般に変化しない Service Catalog の設定面は展開しません。 したがって、初期サイトに対して行ったように、これらの要素を定義する必要があります。
Organization Designer によって保守されるエンティティ(人員、組織、グループ、ロール、および役職)は、サービス定義がこれらのエンティティを参照できるように、その前にサイトに存在していなければなりません。 そのため、これらのエンティティはすべて、サービス カタログを展開する前に展開する必要があります。 また、これらのエンティティは、1 つ以上のカスタム展開パッケージに含める必要があります。
さらに、カスタム電子メール テンプレートをすべて展開する必要があります。 電子メール テンプレートは、それを使用するサービスが展開される前ならいつでも展開できます。
これで 2 つ(以上の)サイトが稼働している状態です。 本番サイトのサービスはすべて、開発サイトのサービスと同一である必要があります。 (開発サイトには初期展開の一部である他のサービスが存在することもありますが、それは問題ありません。)どの環境で、グループ、ロール、および組織のエンティティ定義とメンバーシップを定義するのかが問題です。 すべてのケースにおいて、エンティティ保護レベルは、ホーム以外の環境にあるエンティティに対するメンテナンスは回避するように設定されます。
最も単純なアプローチは、サービス定義を構成するすべてのエンティティのホームを開発インスタンスにし、人と組織のすべての関連エンティティのホームを本番インスタンスにする方法です。
これによって、Catalog Deployer の使用およびそれが展開するエンティティの保守が非常に簡単になります。つまり、すべてのエンティティのすべての面が常に 1 つのサイトのみで保守されます。 ただし、ディレクトリ関連エンティティの作成およびテストのワーク フローは複雑になります。
このシナリオでは、ディレクトリ関連エンティティに関するすべての作業(サービス定義内での実際のエンティティ参照を除く)は 1 か所、つまり本番環境で行われます。 これは推奨されるプロセスです。つまり、すべての作業が 1 か所で行われるため、確認とモニタリングが容易になります。 ただし、このプロセスでは次のような不都合が生じることがあります。
代替アプローチは、サービス定義を構成するすべてのエンティティのホームを開発インスタンスにし(これは変更不可)、人員と組織の関連エンティティのホームを本番インスタンスと開発インスタンスの両方にする方法です。
組織、グループ、ロール、人員などのエンティティのホームを両方のインスタンスにすることには、次のような利点があります。
組織、グループ、ロール、人員などのエンティティのホームを両方のインスタンスにすることには、次のような欠点があります。
たとえば、メンバがさまざまな組織の人々で構成されるグループを作成しているとします。 次の項では、グループにメンバを割り当てる方法について説明します。
新しいキューを使用するには、新しいサービスを開発するか、既存のサービスを拡張する必要があります。 ベスト プラクティスに従って、キューは、そのホームになっている対応するサービス チーム組織を持つようにすべきです。
キューおよび組織の「ホーム」を設定した場所に応じて、ここでは 2 つのシナリオが考えられます。 それぞれに利点と欠点があります。 (これは前項の説明の特殊ケースですが非常に頻繁に起きます)。
これは、すべての作業を本番サイトの組織、人、キューに置く「クリーン」アプローチです。 2007 よりも前の Service Catalog バージョンにおいて実行可能な唯一のアプローチだったため、それらのバージョンからアップグレードする人はその使用を継続することを好む場合があります。
このシナリオでは、エンティティの定義のホームが開発サイトにあり、そのメンバーシップのホームが本番サイトにあります (もちろん、この分割は Entity Homes によって実施することはできません。したがって、Organization Designer によるメンテナンスを許可するために、両方のサイトがエンティティのホームとして指定されます)。
前述の両シナリオでは、初期展開後に初期のキューと OU に対して可能な変更について確認しました。
次の 2 つのパッケージが必要です。
カスタム パッケージが基本サービス パッケージの前に展開されている場合は、それぞれのパッケージが作成時の状態で展開されます。
特定のキューに割り当てられているタスクを含む、複数のサービスを展開後、キューの名前がサービス実施者に誤解を与えているため、名前を変更したいというフィードバックを受け取ることがあります。 または、会社組織が再編成されていて、組織(サービス チームを含む)の名前を新しい組織を反映したものに変更する必要がある場合があります。
これは既知のエラーおよび欠落で説明した「既知のエラーおよび欠落」と衝突します。 Catalog Deployer はサイト間でエンティティの名前を一致させて動作するため、名前変更されたエンティティとの一致は不可能です。 場合によっては(上述のように)、Catalog Deployer は失敗してエラーを報告します。 ただし、別のケースでは、Catalog Deployer はターゲットに新しいエンティティを作成します。 名前変更されたキューに関しては、以前に展開されたすべてのサービスが引き続き古いキューを使用します。 キューが名前変更され展開された後で展開されたサービスのみが新しいキューを参照します。 これは明らかに設計者の意図に反します。
この動作を防ぐ唯一の方法は、名前を変更する必要があるエンティティを注意深くモニタリングおよび制御するプロセスを整備することです。 このプロセスは、キューおよび組織のホームが本番サイトだけにあるか、本番サイトと開発サイトの両方にあるかに応じて若干異なりますが、いずれの場合も両方のサイトでエンティティの手動による名前変更(Organization Designer を介して)が必要です。
次のシナリオを考慮する必要があります。
カテゴリは、基本サービスまたは拡張サービスの展開の一環として、コンポーネント エンティティとして展開されます。 これは、主な目的が新規または修正したサービス定義を展開し、関連カテゴリも展開されるようにする場合には効果的な方法です。 ただし、カテゴリ階層またはカテゴリに関連付けられているイメージが変更されている場合には、サービス パッケージの使用は効果的ではありません。
カスタム展開パッケージには、階層を参照している可能性があるサービスとは無関係に、カテゴリ階層のすべてまたは一部を展開するためのオプションがあります。 カテゴリ構造がターゲット環境に展開されるときに、Catalog Deployer は各カテゴリおよびそのサービス間の関連付けを自動的に再設定します。
通常どおり、エンティティ名(このケースではカテゴリ)の単純な変更に対する警告が適用されます。 もう適用されないカテゴリがある場合は、そのカテゴリのサービスへの関連付けを削除し、新しいカテゴリを作成して、置き換える必要があります。 あるいは、ソースとすべての対象インスタンスでカテゴリの名前を変更します。
Service Designer は、アップグレード プロセスによって生成された固有な名前を持つエンティティを認識できます。
Service Designer は、少なくとも、アップグレード プロセスで作成されたアーティファクトの名前を、よりユーザにわかりやすい名前に変更したいと考えます (また、再使用を促進するためにフォーム コンポーネントの構造のリファクタリングも望む場合もありますが、それは別の問題です)。次に示すのは「標準的な」名前変更シナリオです。
開発サイトで OU に関連した役職を定義して、1 つまたは 2 つの組織に対してその役職を保持している個人を指定しています。 開発サイトのサービスを、その役職にタスクをルートするように変更しています。 この場合、次の手順で、新規および変更済みのエンティティを展開します。
シスコでは、特定の製品リリースにおいてブランド化コンテンツ ライブラリの形でコンテンツを提供します。 ご使用のリリースに関してこのようなコンテンツ ライブラリが使用できるかどうかは、Cisco Technical Assistance Center(TAC)にお問い合わせください。 使用可能なライブラリ パッケージには次の 2 種類があります。
これらのライブラリ内のサービスは、エンド ユーザ管理、アクセス管理、データセンター管理、およびその他の領域で一般的に必要なサービス用のモデルを提供します。 ライブラリ コンテンツはプレビューすることができ、必要な項目を開発環境に展開することができます。 そのため、企業の要件に合わせたサービスの設計、設定、およびカスタマイズを迅速に行うことができます。
カスタム ライブラリには、サービス内で参照されるキューやサービス チーム(組織)などのエンティティが含まれています。 このライブラリは、オプションで、対応するサービス ライブラリと一緒にインストールできます。 カスタム ライブラリが展開されている場合は、サービスで事前定義の参照が使用されます。 カスタム ライブラリがインストールされていない場合は、必要に応じて、サービスで「デフォルト サービス キュー」が参照されたり、参照が削除されたりします。 サービス設計者には、タスク(提供)計画の設定を完成させる責任があります。
一般に、サイト管理者はブランド化ライブラリのコンテンツを管理および展開する責任があります。 必要に応じて、ブランド化コンテンツ ライブラリを展開する権限を持つカスタム ロールを作成できます。 ロールの作成と割り当ての詳細については、組織の構築またはオンライン ヘルプを参照してください。
以下の手順を使用して、ブランド化ライブラリを展開します。
ステップ 1 | ライブラリを入手します。 ライブラリと対応するユーザ マニュアルはシスコのソフトウェア サイトからダウンロードできます。 |
ステップ 2 | ライブラリをインストールします。 ライブラリは、クライアント ワークステーションがアクセス可能なディレクトリ(Catalog Deployer がそこから実行されます)にインストールする必要があります。 共有のネットワーク ドライブをライブラリの中心のストレージにできます。 |
ステップ 3 | ライブラリ コンテンツの展開を担当するユーザが、この機能を含むロールを持っていることを確認します。 |
ステップ 4 | ライブラリをインポートします。 ライブラリを Catalog Deployer にインポートします。 ライブラリ パッケージのインポートを参照してください。 |
ステップ 5 |
ライブラリ コンテンツを確認します。 ライブラリ パッケージを展開する権限を持っているユーザが、対象サイトで受け取ったパッケージを選択し、状況に応じて、ライブラリ コンテンツ(サービス)をプレビューします。 ライブラリ コンテンツをプレビューするには、プレビューするサービスのチェックボックスをオンにして選択し、[プレビュー(Preview)] をクリックします。 |
ステップ 6 | 選択したライブラリ コンテンツを展開します。 受信するパッケージを選択し、展開するパッケージ コンテンツを選択して、展開を実行します。 ライブラリの展開を参照してください。 |
ステップ 7 | 展開ログを確認します。 ライブラリ コンテンツを展開すると、エンティティ定義の作成または更新に関する、すべての展開アクティビティの詳細なログが生成されます。 |
サイト管理者とカタログ パブリッシャのロールには、ブランド化コンテンツ ライブラリから内容をインポート、プレビュー、または展開するための [展開のインポート(Import Deployments)] および [展開用パッケージの展開(Deploy Deployment Package)] 機能が含まれます。
ステップ 1 |
[表示と検索(View and Search)] ペインで、[アクション(Action)] > [インポート(Import)] を選択します (そのオプションが使用不可の場合は、現在のユーザに、「ブランド化ライブラリ コンテンツの展開」機能を含むロールがありません)。 [インポート(Import)] ダイアログボックスが表示され、インポートするライブラリ ファイルを参照するように求められます。 |
ステップ 2 | [参照(Browse)] をクリックします。 |
ステップ 3 | ライブラリ ファイルを見つけて、選択します。 |
ステップ 4 | [開く(Open)] をクリックします。 |
ステップ 5 |
[インポート(Import)] をクリックします。 ライブラリがインポートされ、[展開用に受信(Received for Deployment)] ステータスが割り当てられて、開かれます。 |
ステップ 6 | [インポート(Import)] ダイアログボックスを閉じます。 |
ライブラリ パッケージにはライブラリを識別し、その展開の詳細がわかる属性があります。
属性 |
説明 |
---|---|
[パッケージ名(Package Name)] と [説明(Description)] |
ライブラリの名前とそのコンテンツの簡潔な説明。 |
ライブラリ バージョン(Library Version) |
ベンダーがリリースしたライブラリのバージョン。 |
ベンダー名 |
シスコ、またはコンテンツ提供者の名前。 |
アプリケーション バージョン(Application Version) |
ライブラリの展開がサポートされているデータベースのバージョン。 ライブラリは特定バージョンの Service Catalog に合わせてカスタマイズされています。 |
画像 |
ライブラリに関連付けられたイメージ アイコン。 |
パッケージタイプ(Package Type) |
サービス ライブラリまたはカスタム ライブラリ。 |
Status |
ライブラリの現在のステータス。 [受信済み(Received)] または [展開済み(Deployed)] のいずれか。 |
[作成日(Created On)]/[作成者(Created By)] [変更日(Modified On)]/[変更者(Modified By)] |
Catalog Deployer は、このサイトのライブラリを作成した(つまり、ライブラリをインポートした)人と、最新の展開アクティビティの日付とそれを実行した人を自動的に追跡します。 |
履歴(History) |
このサイトのライブラリに対して実行されたすべての展開アクティビティの簡潔なログ。展開の詳細を見るためのより詳細なログへのリンクが付いています。 |
適切なロールを持っているライセンスされたユーザは、[表示と検索(View and Search)] ペインで [アクション(Action)] > [新しいライブラリパッケージ(New Library Package)] を選択することによって、新しいライブラリを作成できます。
手順は、次の例外を除いて、展開パッケージの作成手順(展開用パッケージの作成を参照)と同じです。
オレンジ色のボール アイコン がデフォルトで新しいライブラリに関連付けられ、[表示と検索(View and Search)] ペインの最初の列に表示されます。 ライブラリ パッケージが保存されたら、[アクション(Action)] ペインで [イメージのアップロード(Upload Image)] をクリックすることによって、カスタム イメージ アイコンも使用できます。 イメージは JPG、PNG、または GIF 形式にすることができます。 これらは 16 ピクセルの幅と 16 ピクセルの高さで表示されるため、この縦横比を維持するように作成する必要があります。 イメージのサイズが正しくない場合は、ブラウザによってサイズが変更され、ぼやけたり、ノイズが入ったりすることがあります。
ライブラリはシスコから顧客サイトへ配布される新しいコンテンツの伝達手段です。 ライブラリは開発サイトにのみ展開する必要があります。 Catalog Deployer は、顧客の要件に合わせて以前にカスタマイズされた可能性のある既存のコンテンツを混乱させたり上書きしたりすることなくライブラリを展開できるように設計されています。 そのため、ライブラリ パッケージを展開するためのオプションは、ライブラリ コンテンツが、対象サイトに同じ名前で作成されているコンテンツを置き換えるのではなく、補完できるように設定されています。
サポート エンティティ(キューや組織単位など)を含んでいるライブラリのコンテンツ全体は、同時に展開する必要があります。 逆に、Catalog Deployer を使用すれば、展開するサービス ライブラリの内容を選択することができます。 各サービスは、別々のトランザクションに展開されます。 展開に失敗すると、現在のトランザクションがロールバックされます。
すべてのインポート アクションと展開アクションがライブラリ パッケージ用に記録されます。 [履歴(History)] セクションの [ログの表示(View Log)] リンクに、Catalog Deployer によるアクションが詳しく表示されます。 既知のエラーおよび欠落を参照してください。
用語 |
定義 |
---|---|
パッケージのアセンブリ |
コンテンツをパッケージに追加します。 パッケージを組み立てると、パッケージに含まれているオブジェクトの現行定義がリポジトリから抽出され、パッケージに書き込まれます。 これらのオブジェクトに対してアセンブリ以降に加えられた変更は、アセンブリされたパッケージに反映されません。 |
関連付けられた単位 |
プライマリ エンティティに関連するエンティティです。対象サイトで展開を成功させるために必要です。 たとえば、サービス定義(プライマリ エンティティ)は、タスクが割り当てられているいくつかの組織、サービス チームを参照する可能性があります(組織単位は、関連エンティティです)。 |
Catalog Deployer |
あるサイトから別のサイトへのカタログ コンテンツおよびディレクトリの展開を担当する Service Catalog モジュール。 |
コンポーネント エンティティ |
サービスを展開する際に自動的に展開されるエンティティです。 サービス コンポーネント エンティティには、カテゴリ、プレゼンテーション要素、ディクショナリ、ディクショナリ グループ、サービス グループ、キーワード、および目的が含まれます。 |
データ ソース(Data Source) |
アプリケーション サーバ コンソールの JDBC データ ソース ページで定義されるデータ ソース。Catalog Deployer による直接のサイト間展開の対象となるサイトすべての接続情報を指定します。 |
展開用パッケージ |
Catalog Deployer によって管理されるプライマリ オブジェクト。 展開用パッケージには、選択された、展開予定のエンティティ(サービス定義、キュー、グループなど)、および展開アクティビティ履歴が含まれます。 展開用パッケージは、コンテンツを対象サイトに展開するために他のサイトに送信またはエクスポート/インポートすることができます。 展開パッケージには、それが「組み立て」られ、その時点で含まれるデータがソース サイトから抽出されるまで、エンティティ コンテンツは含まれません。 |
エンティティ(Entity) |
Service Catalog ソフトウェア内で作成され保守されるオブジェクトの 1 つ。 例:組織単位、サービス定義、キュー、および電子メール テンプレート。 |
エンティティ ホーム(Entity Home) |
いずれのサイトが、サポートされる各エンティティ タイプの正式サイトであるかを管理者が指定する、Administration モジュールの設定のページ。 |
パッケージのエクスポート |
すでにアセンブリされたパッケージのコンテンツを含む XML ファイルを作成し、そのファイルをファイル システムに書き込みます。 ソース サイトから対象サイトへのパッケージのエクスポートは、パッケージ送信の代替手段です。 |
実装 |
直接または間接に接続されている 1 つ以上の Service Catalog サイトのグループ。 |
パッケージのインポート |
以前にエクスポートされた XML 展開用パッケージを対象サイトにインポートすることにより、パッケージを作成します。 パッケージはステータス [展開用に受信(Received for Deployment)] で作成されます。 |
ライブラリ パッケージ |
事前に組み立てられた、ファイル インポートとして使用可能なシスコのパッケージ。 パッケージ内容は、サービス カタログの基礎を提供するために使用できるテンプレート サービス、または関連エンティティで構成されています。 展開用パッケージと異なり、ライブラリの選択されたコンテンツは展開することができます。 |
プライマリ エンティティ |
Catalog Deployer パッケージに含めるために選択できるエンティティ。 |
サイト |
データベースおよび http アドレスを共有する 1 つ以上のコンピュータ システム(単一のコンピュータまたはクラスタ)の集合で、機能によって分類できます。 たとえば、開発サイト、テスト サイト、および本番サイトです。 |
ソース サイト |
パッケージが作成されるサイトです。 他のサイト上で展開するパッケージを送信またはエクスポートします。 |
対象サイト |
パッケージが展開されるサイトです。 送信またはインポートを使用してパッケージを受信します。 |
送信 |
データベース接続を使用して、あるサイトから別のサイトにパッケージを送信します。 ジョブを送信すると、ソース サイトでそのジョブの編集(再アセンブリやコンテンツ変更)はできません。 ターゲット サイトは Catalog Deployer 経由で送信を受信します。 |