Service Manager のオーサリングでクラスをカスタマイズし、作成する
重要
このバージョンのService Managerはサポート終了に達しました。 Service Manager 2022 にアップグレードすることをお勧めします。
クラスは、Service Managerで使用されるオブジェクトを表すために使用されるメイン要素です。 クラスは、コンピューター、ユーザー、インシデント、フォームを表すことができます。
Service Manager機能など、より大きな要素を表すクラス定義は、多くの場合、グループ化されます。 クラス定義は、Service Manager機能を有効にするためにService Managerにインポートする必要がある管理パックに格納されます。
クラスの主な概念
Service Manager内のオブジェクトは、特定の基底クラスのインスタンスです。 基本クラスのすべてのインスタンスは、共通のプロパティ セットと共通の動作を持ちます。
すべての管理パック要素と同様、クラスは ID と 表示名 プロパティを持ちます。 このドキュメントでは、ID はオーサリング ツールでのみ表示されるクラスの一意の名前を参照し、Name と Display Name は、Service Manager コンソールに表示される言語固有の名前を参照します。
注意
クラスを作成するときは、常にクラス名が管理パック間で一意であることを確認します。 可能であれば、環境で意味が通るクラス名を使用します。 Service Manager作成ツールの [クラス ブラウザー] ウィンドウで検索機能を使用して、クラス名が既に存在するかどうかを確認できます。
プロパティ
特定のクラスのすべてのインスタンスは、共通のプロパティ セットを共有 します。 これらのプロパティの値はユーザーによりさまざまな方法で提供され、異なるインスタンスでさまざまな値を持ちます。 プロパティは、一意の名前、場所、ユーザーが必要な可能性があるか管理シナリオに必要なその他の詳細など、実際のオブジェクトの詳細を表すのに使用されます。
キーのプロパティ
キー プロパティ は、特定のクラスの各インスタンスを一意に特定します。 プロパティがキー プロパティとしてマークされている場合、クラスの各インスタンスにはそのプロパティの一意の値が必要であり、値を null にすることはできません。 ホストされるクラスの場合、値は、同じホスト親を持つクラスのすべてのインスタンスに対してのみ一意である必要があります。 ホストされていないクラスの場合、管理グループ内の クラスのすべてのインスタンスに対して一意である必要があります。 ホスト リレーションシップについては、このセクションの後で説明します。
クラスには必ずしもキー プロパティが必要なわけではありません。 キー プロパティは、1 つのクラスのインスタンスが、単一の親に対して複数予想される場合にのみ必要です。 1 つのインスタンスのみが必要な場合は、キー プロパティは必要ありませんが、引き続き定義できます。
たとえば、 SQL データベース エンジン は、キー プロパティ Instance Name を持ちます。なぜなら、1 台のコンピューターに、Microsoft SQL Server のインスタンスが複数インストールされる可能性があるからです。 SQL データ エンジンのプロパティが複数ある場合、異なるオブジェクトを明確に識別するために、各インスタンスは、 Instance Name に異なる値を持つ必要があります。 一方、 IIS Web Server クラスでは、どのコンピューターにも 1 つのインスタンスしかインストールできないため、キー プロパティは定義されません。
すべてのオブジェクトには、オブジェクトのキー プロパティまたはプロパティ、およびホストしている親または親のプロパティから計算される Path Name プロパティがあります。 ホストされていないオブジェクトについては、 Path Name がクラス自体のキー プロパティになります。 Path Name は、管理グループのクラスのインスタンスを一意に識別するために使用できます。
基底クラスと継承
すべてのクラスは 基本クラス を指定する必要があります。基本クラスは、新しいクラスが 特殊化する既存のクラスを識別します。 Service Managerに含まれる管理パック ライブラリには、管理パックのカスタム クラスのベースとして使用できるいくつかのクラスが含まれています。 管理パックは、通常、ライブラリ クラスを継承する少なくとも 1 つのクラスを持ち、同じ管理パックのクラスを継承する他のクラスを持つ可能性もあります。
基本クラスの概念は、Windows サーバー オペレーティングシステム管理パックを使用して説明できます。 管理パックには、コンピューターにインストールされている論理ディスクを表すクラスが含まれています。 次の図に、 Windows Server 2003 論理ディスク クラスと Windows Server 2008 論理ディスククラスを示します。 これらのクラスは両方とも、Microsoft.Windows.Server.Library 管理パック ファイルで定義されている 論理ディスク (サーバー) を基本にしています。 論理ディスク (サーバー) は、 論理ディスクに基づいており、それ自体は 論理デバイスに基づいており、 論理ハードウェア、 論理エンティティ、最後にエンティティを使用 します。 すべてのクラスは類似の継承パスをたどることができ、常に、クラス構造のルートである エンティティに行き着くのです。 これは基底クラスを持たない唯一のクラスであり、他のすべてのクラスは最終的にそれを継承します。
クラス間でのプロパティの継承
エンティティ には、 Display Name という名前の 1 つのプロパティがあります。 このプロパティは、 Entity から継承するすべてのクラスによって継承されます。 すべてのクラスは最終的に Entity から継承 されます。 そのため、すべてのクラスに Display Name プロパティがあります。 この例の他のクラスは、 論理デバイスが Name、 Description、および DeviceIDを定義するまでプロパティを持ちません。 DeviceID はキーのプロパティとして指定されます。 これらのプロパティは、 論理ディスク および 論理ディスク (サーバー)がすべて継承します。 論理ディスク (サーバー) では、 Sizeプロパティ、 Drive Typeプロパティ、 File Systemプロパティが追加されています。 最下位レベルのクラスは、オペレーティング システムのバージョンに固有であり、継承ツリーの上位のクラスが提供するプロパティ セット全体を継承します。
クラスの種類
ほとんどのクラスは、 具象クラスとして知られ、実際のインスタンスを 1 つあるいは複数持ちます。 抽象クラス と シングルトン クラス は、動作が異なる特殊な種類のクラスであり、特定のシナリオで使用されます。
抽象クラス
抽象クラスはインスタンスを持たず、他のクラスの基本クラスとして機能するために存在します。 抽象クラス レベルで定義されているすべてのプロパティとリレーションシップは、子クラスによって継承され、再度定義する必要はありません。 管理パック ライブラリで定義されているクラスのほとんどは抽象クラスです。これは、カスタム管理パックで定義されているクラスの基底クラスとしてのみ機能するように提供されているためです。
抽象クラスは、クラスのさらに特殊化全体で定義できるプロパティ、リレーションシップ、またはグループ化の共通セットがある場合に使用されます。 前の例では、Windows Server 2003 論理ディスクと Windows Server 2008 論理ディスクの上に示したすべてのクラスは抽象です。 それらは、より下位のクラスが継承するためだけに存在します。
シングルトン クラス
シングルトン クラス は、クラスのインスタンスが 1 つだけの場合に使用されます。 このクラス自体がインスタンスであり、常に存在します。 管理パックがインストールされると、単一インスタンスが作成されます。 同様に、キー プロパティは 1 つのインスタンスしか持たないため、シングルトン クラスには必要ありません。 管理グループ全体で必要なこのクラスのインスタンスは 1 つだけであるため、シングルトン クラスの一般的な用途は Groups クラスです。
クラス拡張機能
既存のクラス定義に新しいプロパティを追加することで、クラスを拡張できます。 新しいプロパティは、既に存在するクラスのすべてのインスタンスと、作成される新しいインスタンスに含まれるようになります。 抽象クラスを拡張することはできません。
リレーションシップ
リレーションシップ は、あるクラスの特定のインスタンスと、別のクラスの特定のインスタンスとの間の関連を示すために、クラスの間に定義されます。 リレーションシップには 3 種類あり、次のセクションで詳しく説明します。
ホスト リレーションシップ
含有リレーションシップ
参照リレーションシップ
クラスのリレーションシップは、次のようにオブジェクトに影響を与えます。
| リレーションシップの種類 | キー プロパティと存在 | 利用可能なプロパティ |
|---|---|---|
| Hosting | キー プロパティの値は、管理グループ内の クラスのすべてのインスタンスで一意である必要があります。 ただし、ホストされるクラスの場合、キー プロパティの値は、同じホスト親を持つすべてのオブジェクトに対してのみ一意である必要があります。 ホストされているオブジェクトを一意に識別するには、オブジェクトとオブジェクトの親の両方のキー プロパティが必要であり、ホストされるクラスのキーは、ホスティング クラスキープロパティとホストされたクラスキープロパティの両方の組み合わせになります。 ホストされたクラスの存在は、ホスト クラスの存在に依存します。 |
クラスを対象とするワークフローは、そのホスト親のプロパティに加えて、そのクラスのプロパティにアクセスできます。 たとえば、 SQL 2008 DB エンジン クラスをターゲットとして使用するワークフローのスクリプトで、SQL Server 2008 のインスタンスがインストールされているコンピューターの名前が必要であるとします。 オブジェクトは、ホストする親を 1 つしか持てないため、 SQL 2008 DB エンジン クラスの特定のインスタンスをホストするコンピューターがわかります。 ワークフロー スクリプトは、ターゲット オブジェクトのプロパティと、そのターゲットのホスト親のプロパティにアクセスできます。 |
| Containment | キー プロパティと存在は、コンテナー オブジェクトに依存しません。 | クラスを対象とするワークフローは、コンテナーの親のプロパティに加えて、そのクラスのプロパティにアクセスできます。 たとえば、インシデント クラスを対象とするワークフロー内のスクリプトは、コンテナー キューのクラスのプロパティにアクセスできます。 |
| リファレンス | キー プロパティと存在は、参照先オブジェクトに依存しません。 | クラスを対象とするワークフローは、そのクラスのプロパティにのみアクセスできます。 |
参照リレーションシップ
参照リレーションシップ は、最も一般的なリレーションシップの種類です。 参照リレーションシップは、親クラスと子クラスが相互に依存していない場合に使用されます。たとえば、データベースは、レプリケートしている別のデータベースを参照できます。 1 つのデータベースはもう一方のデータベースに依存せず、オブジェクトは個別に存在します。
含有リレーションシップ
含有リレーションシップ は、ホスト リレーションシップほど制限されない種類です。 1 つのクラスが別のクラスに関連付けられていることを宣言しますが、もう一方のクラスには必要ありません。 ホスト リレーションシップと違って、含有リレーションシップは多対多です。 これは、あるオブジェクトが複数のオブジェクトを含むことが可能で、単一オブジェクトが複数の他のオブジェクトに含まれることが可能であることを意味します。 たとえば、あるグループは複数のオブジェクトを含むことができ、単一オブジェクトは複数のグループのメンバーになることができます。
含有リレーションシップは、通常、グループ メンバーシップに使用されます。グループとメンバー オブジェクト間の含有リレーションシップを通じて、オブジェクトがグループに含まれます。
ホスト リレーションシップ
クラス間のリレーションシップの制限が最も厳しいのが ホスト リレーションシップです。 他のクラスにホストされているクラスは ホストされたクラスと呼ばれ、そのクラスのインスタンスは ホストされたオブジェクトと呼ばれます。 クラスが別のクラスによってホストされていない場合は、 ホストされていないクラスと呼ばれ、クラスのインスタンスは ホストされていないオブジェクトと呼ばれます。
あるオブジェクトが他からホストされると、そのオブジェクトの存在そのものが、ホストしている親に依存します。 ホストしている親が削除されると、ホストされた子も削除されます。 たとえば、論理ディスクは、インストールされているコンピューターがないと存在できません。
ホストされたオブジェクトは、ホストする親を 1 つのみ持てますが、1 つの親は複数の子をホストできます。 たとえば、ある特定のディスクは 1 台のコンピューターのみにインストールできますが、1 台のコンピューターには複数のディスクをインストールできます。
ホスト リレーションシップのもう 1 つの例として、SQL Server 管理パックがあります。 Windows コンピューター クラス、 SQL 2008 DB エンジン クラス、 SQL 2008 DB クラスの間のホスト リレーションシップをここに示します。
SQL Server 2008 クラスのホスト リレーションシップ
SQL 2008 DB エンジン クラスは、ある特定のコンピューターにインストールされた SQL Server 2008 のインスタンスを表します。 1 つのデータベースは、単一データベース エンジンにしかインストールできないので、 SQL 2008 DB エンジン クラスは、 SQL 2008 DB クラスをホストします。 管理グループには同じ名前を持つ複数のデータベースが存在できますが、 SQL Server クラスの特定のインスタンスにインストールされたデータベースは、一意の名前を持つ必要があります。 これに対して、データベース エンジンのホストは、 Windows コンピューター クラスです。 管理グループには同じ名前を持つ複数の SQL Server インスタンスが存在できます。 ある特定のコンピューター上では、それぞれが一意の名前を持つ必要があります。
ホスト リレーションシップが 2 つあるため、各データベースのパス名は、コンピューター名、インスタンス名、データベース名を続けたものになります。 次の図で、例を示します。
サンプル データベースのホスト リレーションシップ
クラスの一般的なガイドラインとベスト プラクティス
Service Manager作成ツールでクラスをカスタマイズする場合は、次のガイドラインとベスト プラクティスを使用します。
型定義の名前付け規則
Service Manager スキーマ モデルの名前付け規則は、.NET 名前空間の名前付け規則に基づいています。
基本的な名前付け規則
基本的な名前付け規則は、 CompanyName.TechnologyArea.ProductName.FunctionalityArea.Nameで、以下のように対応します。
ProductName はオプションです。定義が、特定の製品に依存しない場合に使用します。
FunctionalityArea はオプションです。定義を異なる領域に適用可能な場合に使用します。
Name は、継承階層ではなく、クラスの意味を反映します。
例: Microsoft.AD.Printer、 Microsoft.Windows.Computer、 System.Knowledge.Article、 System.WorkItem.Incident、 System.StarRating.Average
System 名前空間
System 名前空間は、Microsoft および Windows に依存しない定義を参照します。 これは通常、Windows アプリケーションまたは Unix アプリケーションが依存する基本定義に適用されます。 これらの基本定義は会社に依存しません。
System プレフィックスには、以下のガイドラインを使用してください。
System.Computer は任意の種類のコンピューターを表し、ベンダー固有ではありません。
System プレフィックスは、その名前空間の上にスキーマが定義されることが予期される場合に使用します。
Microsoft.Windows.Computer は System から始まらないことに注意してください。ただし、ほとんどの Windows アプリケーション (定義するベンダーに関係なく) はこの定義に依存します。
クラスの名前付けのベスト プラクティス
クラスに名前を付ける場合は、次のベスト プラクティスを使用します。
2 つのクラスの異なるオブジェクトに対して同じキー値が格納される 2 つの個別のクラス (2 つの異なる管理パック内にある場合でも) を作成しないでください。
クラスを拡張するときは、常にクラス拡張名が管理パック間で一意であることを確認してください。 可能な場合は、有意なクラス拡張名を使用します。
クラスを拡張するときは、そのクラスで既に使用されている ID を持つプロパティを定義しないでください。
カスタム クラスのプロパティの名前にピリオドを使用しないでください。
キューブを作成するときにカスタム名の付いた計算を追加する場合は、名前付き計算の名前の前に NC_ を追加します。 こうすることで、既に存在するプロパティの名前が使用される可能性が低くなります。
作成するクラスが多すぎないようにする
必要以上の数のクラスを作成すると、不必要な複雑性が生じるだけで、その価値はほとんどありません。 クラスの数を最小限に抑えることで、望ましい結果がもたらされます。 抽象クラス以外に、クラスがワークフローのターゲットではない場合や、データの格納に使用される場合は、作成しないでください。 また、2 つの類似するクラスがある場合は、違いを示す値を格納するプロパティなどの使用により、単一のクラスで対応することを検討してください。
頻繁に更新されるプロパティを使用しない
プロパティの値は、最初に設定された後にほとんど変更されません。 プロパティ値の変更が頻繁に発生する原因として考えられるのは、カスタム コネクタや、Service Manager データベースをプログラムによって更新するその他のカスタマイズです。 このようなシナリオの下では、プロパティ値が頻繁 (多数のオブジェクトに対し、10 ～ 15 分おきなど) に変更されることがあります。
プロパティ値が頻繁に変更されると、ワークフローのパフォーマンスが多少低下したり、その他のパフォーマンスに影響が生じることがあります。 その理由は、システムが変更をすべて履歴に記録するためです。 また、プロパティによっては、変更のたびに、データ ウェアハウスによる処理および保存を必要とする膨大量のデータが追加されることもあります。
抽象クラスを拡張しない
Service Managerでは、抽象クラスを拡張することはできません。 抽象クラスを拡張する必要がある場合は、次のいずれかの操作を行うことができます。
追加したいプロパティを使って新しいクラスを作成し、その後、新しいクラスと抽象クラスのリレーションシップを作成します。
抽象クラスから派生した、各具象クラスを拡張します。
作業項目クラスの簡単な検索を改善する
"System.WorkItem" クラスから派生したカスタム クラスを定義する場合は、そのクラスの DisplayName プロパティを次の形式で格納することをお勧めします: WorkItem.ID<SPACE>WorkItem.Title。
これにより、簡易検索が向上されます。 簡易検索では、 DisplayName プロパティのみが検索されます。明示的に Title プロパティ値と ID プロパティ値を DisplayName プロパティ値に含めることで、簡易検索の結果が向上します。 これは、ユーザーがタイトルに含まれる単語または ID により検索を実行できるためです。
オーサリング ツールでクラスを参照する
Service Manager作成ツールの [クラス ブラウザー] ウィンドウを使用して、クラスとそのプロパティを参照できます。 クラスを参照しているときに、[ クラス ブラウザー ] ウィンドウからオーサリング ウィンドウで作成されているフォームにプロパティをドラッグすることで、フォームにコントロールを追加できます。
[ クラス ブラウザー ] ウィンドウには、ライブラリ フォルダー内の管理パックと、オーサリング ツールで開かれた管理パックのクラスを表示できます。 クラスを選択すると、[ クラス ブラウザー ] ペインには、そのクラスに対して特に定義されているプロパティと、システムによって生成される内部プロパティが表示されます。 既定では、Library フォルダーは C:\Program Files (x86)\Microsoft System Center\Service Manager <バージョン> Authoring\Library にあります。
[ クラス ブラウザー ] ウィンドウで管理パックを選択すると、選択した管理パックのすべてのクラスが表示され、プロパティを表示するクラスを展開できます。 [すべての管理パック] を選択すると、[ライブラリ] フォルダー内のすべての管理パックのすべてのクラスが表示されます。 管理パックの選択を変更するたびに、[ クラス ブラウザー ] ウィンドウを更新する必要があります。
クラスを参照するには
[ クラス ブラウザー ] ウィンドウが作成ツールに表示されない場合は、[ 表示] を選択し、[ クラス ブラウザー] を選択します。
[ クラス ブラウザー ] ウィンドウの管理パックの一覧で、参照するクラスを含む管理パックを選択します。 たとえば、 システム ライブラリ 管理パックを選択します。
表示するクラス (Computer クラスなど ) を見つけて、次の操作を行います。
[説明] や [内部名] など、クラスの詳細を表示するには、クラスを右クリックし、[詳細] を選択します。
[表示名] や [資産の状態] などのクラス プロパティの一覧を表示するには、[クラス ブラウザー] ウィンドウでクラスを展開します。 プロパティの詳細をさらに表示するには、プロパティを右クリックし、[詳細] を選択 します。
クラスの定義を含む管理パックを開くには、クラスを右クリックし、[表示] を選択 します。
オーサリング ツールでクラスの詳細を編集する
Service Manager Authoring Tool を使用して、クラスのプロパティを表示し、クラスの名前や説明などの詳細を編集できます。
管理パック エクスプローラーでは、クラスを選択し、[詳細] ウィンドウでその詳細を表示できます。 封印されていない管理パックに定義されているクラスを選択した場合は、そのクラスの名前と説明を変更できます。
クラスの名前または説明を変更する
デスクトップで、[スタート] を選択 します。
[Service Manager作成ツール] を選択し、オーサリング ツールが開くのを待ちます。
[管理パック] エクスプローラーと [詳細] ウィンドウの両方が開かれていることを確認します。
[ ファイル] を選択し、[ 開く] を選択します。
[ ファイルを開く ] ダイアログで、変更するクラスを含む封印されていない管理パックを選択し、[ 開く] を選択します。 たとえば、サンプル管理パック \Samples\Woodgrove.AutomatedActivity.AddComputerToGroupMP.xml Authoring Tool インストール フォルダーを 開きます。
管理パック エクスプローラーで、変更するクラスを含む管理パックを展開します。
[ クラス] を展開し、変更するクラスを見つけて選択します。
Name プロパティまたは Description プロパティの値を選択し、新しい値を入力します。 変更できない値は使用できません。
管理パック エクスプローラーで、変更されたクラスを含む管理パックを右クリックし、[保存] を選択します。
オーサリング ツールで継承を使用してクラスを作成する
Service Manager Authoring Tool では、既存の基本クラスからプロパティと関係を継承するクラスを作成できます。 その後で、作成した新しいクラスのプロパティと関係を変更、追加できます。
クラスの継承を定義するには、まずプロパティと関係の継承元の基本クラスを選択します。 オーサリング ツールでは、次のいずれかの方法を使用して基本クラスを選択できます。
ショートカットを使用して基本構成アイテム クラスからプロパティと関係を継承する。
ショートカットを使用して基本作業アイテム クラスからプロパティと関係を継承する。
最初に基本クラスを選択してから継承の定義を開始する。
特定の基本クラスを選択せずに継承の定義を開始する。
次の手順では、オーサリング ツールでクラス継承を定義するためのすべてのメソッドについて説明します。
構成アイテム クラスまたは作業アイテム クラスを基本クラスとして定義を開始するには
管理パック エクスプローラーがオーサリング ツールに表示されない場合は、[表示] を選択し、[管理パック エクスプローラー] を選択します。
管理パック エクスプローラーで、任意の管理パックを選択して展開します。
[ クラス] を右クリックし、[ 構成項目クラスの作成] または [ 作業項目クラスの作成] を選択します。
封印された管理パックからクラスを作成する場合は、[ ターゲット管理パック ] ダイアログで、封印されていない管理パックを選択してクラスのカスタマイズを保存し、[ OK] を選択します。
注意
封印されていない管理パックからクラスを作成する場合、このクラスのカスタマイズは選択した管理パックに保存されます。
[ クラスの作成 ] ダイアログで、新しいクラスの内部名を指定し、[ 作成] を選択します。
これで、新しいクラスのプロパティの一覧を作成ウィンドウで表示できるようになります。 構成項目クラスを作成する場合は、構成項目クラスのすべてのプロパティが一覧表示されます。 作業項目クラスを作成する場合は、作業項目クラスのすべてのプロパティが表示されます。
[ プロパティの作成] または [リレーションシップの作成] を選択して、クラスの新しいプロパティと新しいリレーションシップを定義します。
基本クラスを選択してから定義を開始するには
管理パック エクスプローラーがオーサリング ツールに表示されない場合は、[表示] を選択し、[管理パック エクスプローラー] を選択します。
管理パック エクスプローラーで、新しいクラスがプロパティとリレーションシップを継承する基本クラスを見つけて右クリックします。 [ このクラスから継承する] を選択します。
[ 新しいクラスの継承 ] ダイアログで、クラスの内部名を入力します。
作成ウィンドウの [ クラスのプロパティとリレーションシップ ] リストに、基本クラスのプロパティが表示されます。
[ プロパティの作成 ] または [ リレーションシップの作成 ] を選択して、新しいクラスにプロパティまたはリレーションシップを追加できるようになりました。
基本クラスを選択せずに定義を開始するには
管理パック エクスプローラーがオーサリング ツールに表示されない場合は、[表示] を選択し、[管理パック エクスプローラー] を選択します。
管理パック エクスプローラーで、任意の管理パックを選択して展開します。
[ クラス] を右クリックし、[ 他のクラスの作成] を選択します。
[ 基本クラス ] ダイアログで、プロパティとリレーションシップを継承する基底クラスを選択します。
または、使用する基本クラスが定義されている管理パックがわかっている場合は、その管理パックをフィルターして、カスタマイズに使用する基本クラスを選択することもできます。
[OK] を選択します。
プロパティとリレーションシップの継承元として選択した基本クラスが封印された管理パック内にある場合は、[ ターゲット管理パック ] ダイアログで、封印されていない管理パックを選択してクラスのカスタマイズを保存し、[ OK] を選択します。
プロパティと関係の継承元として選択した基本クラスが含まれている管理パックが封印されていない場合は、カスタマイズしたクラスがその管理パックに保存されます。
[ クラスの作成 ] ダイアログで、このクラスの内部名を指定し、[ 作成] を選択します。
これで、新しいクラスのプロパティの一覧を作成ウィンドウで表示できるようになります。 この一覧には、選択した基本クラスのすべてのプロパティが表示されます。
オーサリング ツールでクラスを拡張する
Service Manager Authoring Tool では、クラスの定義にプロパティと関係を追加することでクラスを拡張することができます。 クラスを拡張すると、そのクラスのすべての既存のインスタンスに影響します。そのクラスのすべてのインスタンスは、新しいプロパティとリレーションシップを含むように更新されます。
クラスを拡張するには
[管理パック エクスプローラー] ウィンドウがオーサリング ツールに表示されない場合は、[表示] を選択し、[管理パック エクスプローラー] を選択します。
[管理パック エクスプローラー] ウィンドウで、拡張するクラスを見つけて右クリックし、[クラスの拡張] を選択します。
[ ターゲット管理パック ] ダイアログで、クラス拡張機能を格納する封印されていない管理パックを選択し、[ OK] を選択します。
作成ウィンドウの [クラスの拡張機能] タブの [クラスのプロパティとリレーションシップ] リストには、クラスのプロパティとリレーションシップが表示されます。 次の手順に従って、新しいプロパティと関係を作成します。
[ Create property]\(プロパティの作成\) を選択します[ プロパティの作成 ] ダイアログで、新しいプロパティの [内部名 ] に名前を入力します。を選択し、[作成] を選択 します。
[ リレーションシップの作成] を選択します。[ リレーションシップの作成 ] ダイアログで、新しいリレーションシップの [内部名 ] に名前を入力します。を選択し、[作成] を選択 します。
注意
クラスを拡張するときは、そのクラスで既に使用されている ID を持つプロパティを定義しないでください。
[クラスのプロパティとリレーションシップ] ボックスの一覧で新しい プロパティまたはリレーションシップ を見つけて選択し、必要に応じて [ 詳細 ] ペインでそのプロパティを変更します。
次の手順
- オブジェクトのプロパティを表示および編集するには、「 フォームのカスタマイズと作成」を参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示