ローカルチームおよび共有チームの使用に関するベストプラクティス
ユーザーコミュニティを最も効率的に管理するには、サイトまたは組織レベルでのユーザーの最良の組織方法を分析する必要があります。可能な場合、サイトレベルまたは組織レベルでユーザー定義グループを作成し、組織レベルで共有チームを作成してから、アプリケーションコンテキストを作成する際にこれらのグループとチームを使用します。
共有チームおよびローカルチームで使用する役割を決定するときには、コンテキストチームの役割とチームテンプレートで使用される役割を適切に一致させることができるように、使用するチームテンプレートを必ず確認してください。
コンテキストチームの設計
最も効果的な形でビジネスデータへのアクセスをユーザーに提供するには、的確なアクセス制御だけでなく、最適なシステムパフォーマンスも目的として設計されたコンテキストチームを使用することが重要です。
数千もの製品、プロジェクト、ライブラリを配置することが予想されるサイトについては、コンテキストチームの構造を設計するにあたり、慎重を期して以下のガイドラインを遵守してください。すでに長期にわたって使用されているチーム設計についても、これらのガイドラインを通じて最適化の余地が見つかる可能性があります。規模が比較的小さいサイトの場合も、これらの最適化テクニックから利点を得られることがあります。
多くの場合、チーム構造の設計が最も容易なのは、完全にローカルチームを基準とすることです。ただし、ローカルチームは、メモリと処理能力を大量に消費するビジネスオブジェクトです。チームの構造を、入念かつきめ細かく練り上げるほど、以下のようなシステムリソースの需要も増大します。
• キャッシュ
• データベース照会
• 再計算キューなど、キューベースのプロセス
• システムでのサーチ、ユーザーによる一般的な対話型の操作
きわめて規模が大きく複雑なチーム構造にした場合、そのチームを使用する数千もの製品およびコンテナと重ね合わせると、システムリソースの需要は膨大なものになる可能性があります。チーム構造が複雑な場合、チーム固有の機能の速度が低下しかねないほか、極端なケースでは、チームがもたらすシステムリソース需要によって、システム全体のパフォーマンスも低下するおそれがあります。したがって、ビジネス上のニーズに応え、パフォーマンスに悪影響を及ぼさない最適なチーム構造を設計するには、慎重な計画が重要です。
チーム構造を設計する上で主な動機となるのは、アプリケーションコンテキストでコンテンツにアクセスするさまざまなセグメントのユーザーコミュニティについて、アクセス許可に関するビジネス要件を満たすことです。チームを設計する過程では、以下のガイドラインに従ってください。
アクセス許可に関するニーズの分類
ユーザーのアクセス許可に関するニーズは、通常、2 つのカテゴリに分類されます。つまり、アクセス権をアプリケーションコンテキストにおけるユーザーの役割に基づかせるか、コンテキストにおけるユーザーの役割とは関係なく、ユーザーにアクセス権を付与するかです。この分類に従って、アクセス権をコンテキストから独立した参加者に付与するのか、コンテキスト固有の参加者に付与するのかを決定します。
コンテキストから独立した参加者
オブジェクトが存在するアプリケーションコンテキストのメンバーであるかどうかにかかわらず、そのオブジェクトへのアクセスを必要とする参加者には、ユーザー、ユーザー定義グループ、組織、または疑似役割を使用してアクセス制御規則を作成します。
たとえば、組織内のあらゆるパブリック製品のリリース済み状態の仕様書に対する読み取りアクセス許可が組織のすべてのユーザーに付与されている必要があるとします。これらのアクセス権は、組織の /Default/PDM ドメインで定義されている、リリース済み状態の仕様書タイプに対する読み取りアクセス許可を組織参加者に付与するポリシーアクセス制御規則を通じて適用します。
コンテキスト固有の参加者
アプリケーションコンテキスト内にあるオブジェクトに、コンテキストにおける役割に基づいてアクセスする必要のある参加者については、システムグループとダイナミック役割を使用してアクセス制御規則を作成します。役割のアクセス制御規則を作成する際には、その規則がダイナミック役割を対象としている必要があるか、その役割のアクセス許可に関するニーズがコンテキスト間で同じであるか、その役割のアクセス許可に関するニーズがアプリケーションコンテキスト間で変化する場合はその規則をシステムグループに対して作成する必要があるかを考慮します。
たとえば、製品の設計を担当するユーザーに、特定のタイプのデータに対する作成アクセス許可と修正アクセス許可が必要であるとします。このアクセス許可の適用対象は、ユーザーが設計作業を割り当てられている製品だけです。これらのアクセス許可は、共有チームまたはローカルチームの設計者に関連付けられているダイナミック役割を通じて適用します。
アプリケーションコンテキストを作成する際、チームの役割および役割の参加者が一連のコンテキスト間で同じである場合は、共有チームを使用することを検討してください。チームの役割または役割の参加者がアプリケーションコンテキスト間で変化する場合は、ローカルチームを使用します。アプリケーションコンテキスト間の変化が軽微である場合は、ローカルで拡張された共有チームを使用することを検討してください。
さまざまな対象をうまく組み合わせるという方法も、もちろんあり得ます。あらゆるケースでただ 1 つの方法にこだわる必要はありません。たとえば、ライブラリコンテキストに対しては共有チームを選択し、一部の製品およびプロジェクトコンテキストにはローカルチーム、その他の製品およびプロジェクトコンテキストにはローカルで拡張された共有チームを使用できます。
 |
広範なアクセス許可の要件に対応するには、コンテキストから独立した参加者を使用してください。これによってチームのサイズが最適なレベルに維持され、システムの処理リソースへの影響が小さくなります。アクセス許可に関するニーズがコンテキストによって異なる場合は、コンテキスト固有の参加者を使用します。
|
以下の表で、チームのアクセス許可を管理するためのさまざまなテクニックおよびパフォーマンスに及ぼされる影響を詳しく説明します。
|
システムリソースの効率
|
 |
|
使用に最適なケース
|
一定の参加者グループのアクセス許可要件が、アプリケーションコンテキストごとに変化しない場合。
|
|
使用方法
|
チームには、参加者を一切追加しません。代わりに、必要なアクセス許可をアクセス制御規則を通じて付与します。
|
|
例
|
例 1
組織内のあらゆるパブリック製品の特定タイプのデータに対する読み取りアクセスが組織全体に付与されている必要があります。この場合に考えられる選択肢の 1 つは、組織のすべてのユーザーを、あらゆる製品のゲスト役割に追加することです。これは、処理能力を大量に消費するアプローチになります。これに代えて、適切な管理ドメイン (組織の「/Default/PDM」ドメインなど) 内で、特定のオブジェクトタイプへの読み取りアクセスを、アクセスポリシー規則を通じてユーザーに提供するという方法があります。
例 2
特定のユーザーグループが、公開されているあらゆるアプリケーションコンテキストでコンプライアンスレビューの機能を実行します。コンプライアンスレビューの役割を確立し、グループに含まれているユーザーをあらゆるアプリケーションコンテキストのこの役割に追加すると、不要なオーバーヘッドが増大します。これに代えて、適切な管理ドメイン (サイトの / (ルート) ドメインなど) 内で、コンプライアンスレビューユーザー定義グループのアクセスポリシー規則を通じて、必要なアクセス許可をユーザーのグループに提供するという方法があります。
|
|
その他の検討事項
|
アプリケーションコンテキストチームのメンバーではないユーザーの場合、ユーザーインタフェースの製品、ライブラリ、プログラム、またはプロジェクトリストのページには、アプリケーションコンテキストが表示されません。ただし、ユーザーはアプリケーションコンテキストをサーチできます。適切なアクセス許可をユーザーが持っていれば、アプリケーションコンテキストが見つかります。アプリケーションコンテキストは、アクセスされるとナビゲータの「最近アクセス」リストにロードされ、以降に使用するときは、これらのリストで見つけることができます。
こういったユーザーが、チームメンバー以外には自動的に表示されない操作にアクセスする必要がある場合、チームの「役割の操作を設定」設定を使用すると、それらの操作がチームメンバー以外に表示されるようになります。このような規則は、コンテキストテンプレートを通じて新しいコンテキストに自動的に提供できます。ワークフローへの参加など、一部の操作も、チームメンバー以外のユーザー向けに別途でセットアップしなければならない場合があります。
アプリケーションコンテキストに含まれているさまざまなタイプのデータにナビゲートする、こうしたユーザーに関して必要になるアクセスポリシー規則は、ケースバイケースで異なります。それらのアクセス許可を特定して、適切に付与する必要があります。
|
|
関連情報
|
アクセス制御規則によるデータへのアクセスの管理を参照してください。
|
|
システムリソースの効率
|
 |
|
使用に最適なケース
|
• 参加者が、アプリケーションコンテキスト内にあるオブジェクトに、コンテキストにおける役割に基づいてアクセスする必要があります。
• 変更点がほとんどあるいはまったくない、互いに類似する多数のアプリケーションコンテキストに対しては、同一のチーム構造を適用できます。
• 同一のユーザーまたはグループが、それらのアプリケーションコンテキストすべてで同一の役割を担います。
• ローカルで拡張することにより、追加的なニーズに応えることができます (下記の「その他の検討事項」を参照)。
|
|
使用方法
|
• 共有チームは、汎用的な性質のアクセス許可がユーザーに提供されることから、多くの場合、ライブラリチームに使用されます。
• その他の場合は、複数の共有チームを作成することにより、一連の多様な製品やプロジェクトに対応できます。
|
|
その他の検討事項
|
共有チームは、ローカルで拡張されない場合に最も効率が高まります。チームをローカルで拡張することによって作成されるローカルチームインスタンスは、共有チームがもたらすと期待されている、パフォーマンス上の利点のいくつかを目減りさせるものになります。あらゆるローカルチームで共有チームがどの程度まで修正されているかによっては、共有チームの真価がまったく発揮されないこともあり得ます。
|
|
関連情報
|
チームメンバーシップによるデータアクセス管理を参照してください。
|
|
システムリソースの効率
|
 |
|
使用に最適なケース
|
• 参加者が、アプリケーションコンテキスト内にあるオブジェクトに、コンテキストにおける役割に基づいてアクセスする必要があります。
• チーム構造は、アプリケーションコンテキストごとに固有です。
• チーム役割で機能する参加者は、アプリケーションコンテキストごとに固有です。
|
|
使用方法
|
• 責任範囲に基づいて、概略的なユーザーグループを作成します。
• チームの特定の役割にグループを追加します。
• コンテキストごとにそれぞれ固有のユーザーグループを作成しないでください。再利用可能なユーザーグループの使用を検討します。
|
|
その他の検討事項
|
理想的には、ローカルチームに配置しなければならない参加者の数は、最適な数にします。
|
|
関連情報
|
チームメンバーシップによるデータアクセス管理を参照してください。
|
チームの設計にあたっては、避けるべき一般的な慣行がいくつか存在します。以下の表に、いくつかの慣行とその欠点を示します。
|
チームの設計に際しての非効率的な慣行
|
欠点
|
ベストプラクティス
|
|---|---|---|
|
あらゆるチームのゲスト役割 (またはその他の役割) に、組織内のあらゆるユーザーを追加することで、アプリケーションコンテキストのデータに対する読み取りアクセス許可を付与する。
|
チーム構造を非常に大きなものにすると、システムリソースの需要が大幅に増大します。
|
ポリシー規則を使用して、基本的なアクセス許可を提供します。チームに直接関連付けなければならないユーザーの数は、適正な数にします。
|
|
あらゆるチーム用に何百もの役割を作成することで、アクセス許可を非常にきめ細かく制御する。
|
チーム構造を非常に大きなものにすると、システムリソースの需要が大幅に増大します。
|
特殊な役割を数多く定義すると、パフォーマンス上のトレードオフとなることに留意してください。チームの役割の数は適正な数にします。
|
|
製品テンプレートまたはライブラリテンプレートを使用して、すべての製品またはライブラリ内のチーム役割に作成する必要がある同じポリシーアクセス制御規則を指定する。
|
この結果、あらゆる製品の同じ役割向けに、同じポリシーアクセス制御規則を作成するという不要な重複が生じます。
|
可能な場合、ポリシーアクセス制御規則は、あらゆるアプリケーションコンテキスト内で同じものを作成するのではなく、組織レベルでダイナミック役割を対象として作成します。詳細については、アクセス制御規則でのダイナミック役割の使用を参照してください。
|
|
製品の役割の割当用に、固有のユーザーグループをその場で作成する。グループは再利用されず、単一の製品に固有のものです。
|
参加者のメンバーシップが互いに類似した、多数のユーザーグループが作成される可能性があります。それに伴って、ユーザーグループの維持管理が複雑化し、LDAP に過大な負荷がかかります。
|
コンテキストごとに固有のユーザーグループを作成するのではなく、再利用可能なユーザーグループにユーザーを整理します。または、ユーザーグループを作成してそれらのグループを役割に関連付けるのではなく、ユーザーをチームに直接関連付けます。2 番目の方法は、最初の方法ほど効率的ではありません。
|
その他の最適化テクニック
チームに関連する有益なシステム最適化テクニックのいくつかを、以下に示します。
• コンテキストが使用終了の状態に達した後は、チームのメンバーを整理することを検討します。DeleteLocalTeamRoles ユーティリティを使用すると、ローカルチームの役割が、既存のアプリケーションコンテキストから削除されます。詳細については、ローカルチームの役割の削除を参照してください。
• ベストプラクティスのガイドラインに従って、PrincipalCache と RemoteObjectIdCache のキャッシュサイズを調整します。この調整によって、チーム構造に関するニーズにこれらのキャッシュで効果的に対応できることが保証されます。詳細については、以下の知識ベースのアーティクルを参照してください。
• PopulateConfirmedUsersInCache ユーティリティを使用して PrincipalCache 内のエントリに事前に値を取り込むことによって、システム起動時にキャッシュにデータが入っている状態にしてください。詳細については、以下の知識ベースのアーティクルを参照してください。https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS115189
• キャッシュが最適に利用されるためには、参加者のメンテナンスを定期的に実行して、切断された状態を解消してください。詳細については、切断された参加者の管理を参照してください。
• サイトについて wt.inf.team.wtusersUseAccessPolicyRules プロパティを true に設定することが適切であるかどうかを検討します。true に設定した場合、システムによって生成されるアドホック規則は、アプリケーションコンテキストがテンプレートから作成されるときに参加者に追加されません。詳細については、以下の知識ベースのアーティクルを参照してください。https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS180319.