| Oracle® Fusion Middleware WebCenter Sites管理者ガイド 11gリリース1 (11.1.1.8.0) E49682-01 |
|
 前 |
 次 |
この章では、WebCenter Sitesの承認システムの基本機能について説明します。ここでは、特定の操作を実行するための手順は説明しません。それよりも、管理者が承認システムのプロセスについて基本的な理解を得られるようにすることを目的としています。承認システムのプロセスは、特にディスクへのエクスポートのパブリッシュの場合、複雑で完全な対話型で行われるプロセスです。
この章の各項は、できるかぎり自己完結した形で記述され、概念を示す例を多数掲載しています。これらの項は、順番に読んで理解できるように編成されています。リファレンスとして使用する場合は、必要な項を参照してください。この章は、まず初歩的な内容(特に承認システムの用語と定義)について説明し、それに基づいて話を進めながら、最終的に承認システムがその機能を実行する仕組みを包括的に理解できるように構成されています。
この章は、次の項で構成されています。
パブリッシュ・セッションを開始するには、パブリッシュの宛先に対してアセットを承認する必要があります。これは、想像以上に複雑なタスクです。企業サイトでは膨大な数のアセットがホストされているので、依存性によって相互に関連付けられていて、パブリッシュするために一緒に承認する必要があるアセットをユーザーが追跡することは不可能です。その結果、ユーザーは通常、承認を必要とするアセットの一部しか承認していません。非承認アセットが存在すると、アセット間のリンクが機能しなくなるため、承認アセットの整合性が失われる恐れがあります。そこで、この部分を承認システムで処理します。
承認システムの最終目的は、パブリッシュされたコンテンツの整合性を保護することです。この目的を達成するために、承認システムはユーザー承認済アセットのパブリケーションを機械的には許可しません。かわりに、本当にパブリケーションの準備ができているのかを判断するために、ユーザー承認済アセットの状態を評価します。必要であれば、承認システムは、ユーザーによるサポート・アセットの承認を支援します。
承認システムの運用中は、テンプレートまたはデータ・モデルでエンコードされているアセットの依存性が承認済アセットの間で維持されることが保証されます。したがって、アセットがパブリッシュされた場合、パブリッシュの宛先でそれらの依存性を再現できます。承認済の一連のアセットに機能しないリンクが存在しない場合、パブリッシュされた一連のアセットにも機能しないリンクは存在しないと考えられます。承認済の一連のアセットのバージョンの一致が維持される場合、パブリッシュされた一連のアセットでもバージョンの一致が維持されると考えられます。
承認システムは、承認済アセットの機能しないリンクおよびバージョンの不一致を分析する際、依存性テストを実行します。
承認システムは、ユーザー承認済アセット間の依存性が、テンプレート・コードまたはデータ・モデルのどちらかで指定されている依存性と一致するかどうかを、パブリッシュ方法を考慮しながら判断します。図13-2および図13-3を参照してください。
ディスクへのエクスポートのパブリッシュの場合、承認システムはテンプレート・コードに基づいて(承認済アセット間の)依存性をテストします。テンプレートのコードを評価して、依存性を判断します。特定のタイプのアセットにデフォルト・テンプレートが割り当てられている場合は、そのテンプレートを使用して依存性を判断します。デフォルトのテンプレートがない場合、承認システムでは特定のアセットに指定されるテンプレートが使用されます。承認およびディスクへのエクスポートのパブリッシュの詳細は、第14章「ディスクへのエクスポートのパブリッシュの様々なトピックおよび承認プロセス」を参照してください。
サーバーへのミラーリングのパブリッシュおよびXMLへのエクスポートの場合、承認システムはデータ・モデルに基づいて(承認済アセット間の)依存性をテストします。
ユーザー承認済アセットに十分な依存性があることを検出した場合、アセットをパブリッシュすることを許可し、パブリッシュ・システムにリリースすることによって次回のパブリッシュ・セッションの処理対象にします。
一方、依存性が不十分なことを検出した場合は、それらの依存性がパブリケーション時に十分になるようなパブリッシュされたアセットを探し、パブリッシュされたコンテンツを参照します。PublishedAssets表をスキャンして、ターゲット宛先に何がパブリッシュされているかを調べます。
承認を必要とするアセットがターゲット宛先に(該当する場合は正しいバージョンで)存在しない場合、ユーザーにアセットを承認するように要求します。
承認を必要とするアセットがすでにターゲット宛先に(該当する場合は正しいバージョンで)存在する場合、このアセットによりパブリケーション時に依存性が十分になるので、このアセットを承認(および再パブリケーション)する必要はありません。
|
注意: バージョンの一致は、WebCenter Sites管理者が要求できます。その場合、(existsおよびexactと呼ばれる)依存性基準を満たすには、ユーザー承認済アセットのバージョンがパブリッシュされているアセットのバージョンと一致する必要があります。 バージョンの一致は、サーバーへのミラーリングのパブリッシュの場合は、gator.iniのmwb.conservativedependenciesプロパティで指定します。ディスクへのエクスポートのパブリッシュの場合は、テンプレート・コードで指定します。詳細は、第13.8項「コンテンツのバージョンの一致の保証」を参照してください。 |
承認システムは、すべてのユーザー承認済アセットの分析を完了すると、特定のアセットのパブリッシュを承認または禁止します。
承認システムは、パブリッシュを一括して承認または禁止するのではなく、分割してパブリッシュする方法をサポートします。依存性テストに合格したアセットはパブリッシュ・システムにリリースされ、次回のパブリッシュ・セッションの処理対象になります。依存性テストで不合格だったアセットはパブリッシュ・システムで保留され、承認を必要とするアセットが追加されたことがユーザーに通知されます。このように、承認済アセット間の依存性は、パブリッシュ・セッションの処理量が想定より少なくなる原因になります。
承認済アセット間の依存性には、固有の処理および名前(承認依存性)があり、どちらも承認システムの動作を理解するために重要です。この章の残りの部分では、主に承認依存性について説明します。承認依存性は、同様に重要な用語である承認および承認状態とともに、第13.3項「用語と定義」で説明しています。承認プロセスの概要は、第13.13項「包括的なシナリオ」を参照してください。
承認、承認依存性および承認状態は、WebCenter Sitesパブリッシュ・モデルで特に重要な用語です。これらは、承認システムの動作を理解する上で重要な依存性に関連しています。このガイド全体で、さらにWebCenter Sitesパブリッシュ・インタフェースでも、使用されています。これらの用語とその定義およびそれらを説明する例について、十分に理解してください。
この項は、次のトピックで構成されています。
アセットをパブリッシュするには、まずユーザーが承認し、次に承認システムが承認する必要があります。承認のタイプを区別するために、ここではユーザー承認とシステム承認という用語を使用します。
アセットのユーザー承認とアセットのシステム承認は、次の点で異なります。
アセットのユーザー承認は、ユーザーがアセットをパブリッシュする意図を示します。一方、アセットのシステム承認は、アセットをパブリッシュする権限をパブリッシュ・システムに付与します。
アセットのユーザー承認は、依存性テストを実行するためにアセットを承認システムに送信することと同等です。ユーザー承認済アセットに対するシステム承認は、(1)ユーザー承認済アセットが依存性テストに合格していることを確認し、(2)次回のパブリッシュ・セッションでパブリケーションするためにアセットをパブリッシュ・システムにリリースすることと同等です。
ユーザーがアセットを承認する機会を得る前に、そのアセットを承認システムが承認することは決してありません。
アセットがシステム承認済であるということは、ユーザーはすでにそのアセットを承認済であるということです。
ユーザーがアセットを承認する場合、常に特定のパブリッシュの宛先が対象になります。
アセットがユーザー承認済であるという場合、パブリッシュの宛先はわかっています(必要であれば明示的に特定されます)。
システム承認は条件付きです。
ユーザーがアセットを承認する際、「承認済」状態をアセットに割り当てることができます。承認システムはこれを仮の承認として扱い、確認を必要とする状態として対応します。承認システムは、依存性テストを完了して「承認済」状態が有効であることを確認したときにのみ、アセットのパブリケーションを承認(リリース)します。
しかし、「承認済」状態を確認できない場合は、その状態を却下し、アセットに独自の承認状態を割り当て、一緒に承認する必要があるサポート・アセットに関してユーザーに通知します。さらに、ユーザーがサポート・アセットを承認できるまで、現在のユーザー承認済アセットのパブリケーションを保留します。このように、ユーザー承認済アセットのシステム承認は、ユーザーがサポート・アセットも一緒に承認することを条件としています。条件付き承認は、承認依存性によって生じます。これについては、次の項で説明します。
承認システムは、アセットを非承認にできます。
承認システムは、承認表を最新の状態に維持する方法の1つとして、アセット変更イベントを処理する承認キューをサポートしています。たとえば、アセットがパブリケーションを承認された後に変更された場合、承認キューでアセットを非承認にする、すなわちパブリッシュ・キューから拒否することによってこの変更を処理します。
ユーザーは承認キューにアクセスできません。承認キューは、デフォルトでは5分間隔で実行されます。ただし、承認機能を使用する機能(「パブリッシュ」タブなど)を起動すると、承認情報を最新の状態に維持するために、画面がレンダリングされる前に承認キューが強制的に実行されます。
|
注意: この項を読む前に、ユーザー承認とシステム承認の2つの用語の違いを理解していることを確認してください。詳細は、第13.3.1項「承認: パブリッシュする意図とパブリッシュする権限の対比」を参照してください。 |
承認依存性は条件付き依存性であり、これによる結果は条件付き承認となります。
条件1. 承認依存性は、コンテンツ用に別のアセットを参照するアセットをユーザーが承認した場合に作成されます。
条件2. 承認依存性が作成されている場合、参照元アセットのシステム承認は、承認先アセットが承認されることが条件になります。つまり、参照先アセットも承認されている場合のみ、承認システムは、参照元アセットを承認できます。このとき、参照元アセットは、参照先アセットに対する承認依存性があるといいます。
|
注意: ここからは、参照元アセットを親アセットと定義します。参照先アセットは子アセットです。わかりやすくするために、親アセットは親としてのみ定義され、子アセットは子としてのみ定義されているとします。 |
承認依存性には、次のような重要な意味合いがあります。
承認依存性は2つのソース(データ・モデルまたはテンプレート・コード)のどちらかで作成されますが、承認依存性の数は必ずしもソースの依存性の数に等しいわけではありません。ソースに依存性が存在する場合、承認の際に、不十分な承認依存性、十分な承認依存性または承認依存性なしのいずれかになる可能性があります。どれになるかは、次の2つの要因によって決まります。
ユーザーが承認済のアセット。
承認システムによる承認依存性の処理方法。承認システムは、特定のアセットのペアに対して依存性が存在すると単純に判断するわけではありません。承認済アセットが親または子のどちらであるかをテストすることによって、依存性の方向を明確に決定します。親アセットが承認されていると判断した場合、承認依存性を記録します。子アセットが承認されていると判断した場合、承認依存性を記録しません。
承認依存性の判断方法の詳細な例は、第13.3.2.1項「承認依存性の例」を参照してください。
この項は、次のトピックで構成されています。
前の項を補足するために、この例では承認依存性の判断方法を詳細に示します。
この例では、2つのアセットが存在するデータ・モデルを使用します。アセットA1はコンテンツ用にアセットA2を参照します。データ・モデルで指定されている依存性は1つですが、ユーザーがアセットを承認する方法は3つあり、したがって、それぞれ異なる承認依存性が作成されます。
不十分な承認依存性
この例では、ユーザーは親アセット(A1)を承認していますが、その子(A2)を承認していません。承認システムは、データ・モデルを(承認済アセットをシードとして)クロールし、A1→A2依存性を検出します。(ユーザーがA1のみ承認していることから)この依存性は不十分であると判断すると、それを不十分な承認依存性として分類します。さらに、A1の「承認済」状態を却下し、ユーザーがA2も承認するまでA1のパブリケーションを禁止し、ユーザーにA2を承認する必要があることを通知します。
この例では、A1のシステム承認は、A2のユーザー承認が条件になります。A1は、A2に対する承認依存性があるといいます。(承認依存性が不十分なので承認システムがユーザーに通知します。)
十分な承認依存性
この例では、ユーザーは親アセットとその子の両方を承認しています。承認システムは、データ・モデルの依存性が(ユーザーがA1とA2の両方を承認していることから)十分であることを検出して、依存性を十分な承認依存性として分類します。さらに、「承認済」状態であることを確認し、次回のパブリッシュ・セッションの開始時のA1とA2の両方のパブリケーションを許可します。
前の例と同じように、A1のシステム承認は、A2のユーザー承認が条件になります。ただし、この例では、承認依存性は十分です。ユーザーには何も通知されません。アセットは、次回のパブリッシュ・セッションでパブリッシュされます。
承認依存性なし
この例では、ユーザーは子アセット(A2)を承認していますが、その親(A1)を承認していません。この場合、(A2がA1に対して依存性がないので)承認システムは、承認依存性を認識しません。承認システムは、ユーザーの「承認済」状態を確認します。その結果、A2はパブリッシュされます(A1はパブリッシュされません)。
データ・モデルとテンプレート・コードでは指定する依存性のタイプが区別されますが(たとえば、アソシエーションと推奨アソシエーション)、承認システムはそれらの依存性を親子承認依存性として処理することによって単純化します。親は参照元アセットであり、コンテンツをその子に依存しています。
このルール(および依存性分析に関する他のルール)の詳細は、この章で後述しています。第13.4項「依存性分析のルール」を参照してください。
データ・モデル依存性とテンプレート依存性は、開発者がどのアセットがコンテンツ用にどのアセットをどのように参照するかを指定するために作成しますが、承認依存性は、アセットを承認するユーザーが作成します。承認依存性は、承認システムによって分析され、どのユーザー承認済アセットがパブリケーションのためにリリース可能であり、どのユーザー承認済アセットがパブリケーションを保留する必要があるのか、どのアセットがまだユーザーによって承認されていないのか、どのアセットがパブリッシュ済なのか、などを示すために使用されます。
データ・モデル依存性とテンプレート・コード依存性は、特定のデータ・モデルおよびテンプレートに対して固定されています。承認依存性は、一連のアセットおよび特定のパブリッシュの宛先が固定されていたとしても、変動する可能性があります。これは、承認するアセットの組合せが、承認のたびに異なるからです。
承認システムは、承認依存性を検出すると、アセットごとにユーザーが設定した「承認済」ラベルを確認するか、またはアセットに独自の承認状態を設定するか、どちらかを実行する必要があります。承認状態は、承認システムによってユーザー承認済アセットに割り当てられたラベルであり、その承認ステータス、すなわちなぜ承認済アセットをパブリッシュできないのか、アセットは承認されてパブリッシュされているのか、アセットはパブリッシュ可能(承認済だがパブリッシュ・セッションがまだ開始されていないのでパブリッシュされていない)なのか、などを示します。承認状態の完全なリストは、表13-4「承認システムにより割り当てられる承認状態」を参照してください。
たとえば、ユーザーがアセットA1を「承認済」とマークしているとします。しかし、システムはこれを仮の承認として扱います。システムは、依存性分析の後で、A1が(たとえ承認済であっても)A2に対する不十分な承認依存性があり、(A2も承認されるまで)パブリケーションを保留する必要があると判断します。
システムはA1に「保留」という承認状態を割り当てることによって、ユーザーによるA1の承認をオーバーライドします。A2には「承認が必要」状態を割り当てます。
承認状態シナリオ
一連のアセットおよび特定のパブリッシュの宛先が固定されていたとしても、承認状態のリストは承認のたびに異なる可能性があります(通常は異なります)。これは、ユーザーによって承認されるアセットの組合せが、承認のたびに異なる傾向があるからです。説明のために、単純な依存性モデルと3つの承認シナリオを使用します。どのシナリオも同一のユーザーが実行します。
それぞれの矢印が承認依存性を表します。4つのアセットがすべてパブリッシュされるには、パブリケーション時に4つの承認依存性が十分である必要があります。
A1→A2
A2→A3
A2→A4
A3→A4
(どのアセットも一度もパブリッシュされていません。)
ここで、ユーザーが承認するアセットの組合せが異なる3つのシナリオについて考えます。
最初の(そして理想的な)シナリオでは、ユーザーが4つのアセットをすべて承認することによって、同時に4つの十分な承認依存性が成立しています。このシナリオでは、システムは、4つの承認依存性を記録し、それらが十分な承認依存性があると判断します。アセットが承認済であることを確認し、次回のパブリッシュ・セッションが開始されたときにパブリケーションすることを許可します。
2番目のシナリオでは、ユーザーはA1とA2の2つのアセットを承認し、これにより4つの承認依存性のうち1つが十分になります。次の3つの承認依存性は不十分なままです。
A2→A3
A2→A4
A3→A4
承認システムは3つの不十分な承認依存性を記録します。すべてのアセットについてパブリケーションの準備ができていないと判断し、すべてのアセットに独自の承認状態を割り当てて、次のリストをユーザーに返します。
A3およびA4、「承認が必要」状態
A1およびA2、「保留」状態。これらのアセットはA3とA4が承認されるまでパブリッシュできません。
3番目のシナリオでは、ユーザーは同じように2つのアセットを承認しますが、今回はA1とA3なので、次の4つの承認依存性はどれも不十分になります。
A1→A2
A2→A3
A2→A4
A3→A4
承認システムは、4つの不十分な承認依存性を記録し、すべてのアセットについてパブリケーションの準備ができていないと判断します。シナリオ2のリストとは異なるアセットと承認状態のリストを返します。
今回のリストは次のとおりです。
A2およびA4、「承認が必要」状態
A1およびA3、「保留」状態
|
注意: ユーザーが承認するアセットの組合せが異なると、システムが判断する承認依存性が異なり、したがって関連するアセットに割り当てる承認状態も異なります。
承認依存性の判断方法の詳細は、第13.3.2項「承認依存性」を参照してください。 |
この機能を実行するために、承認システムは様々なルールに従います。この項ではそれらのルールの概要を示し、その後の項で詳細に説明します。
承認システムは、すべての承認依存性を親子関係として処理することによって単純化します。詳細は、第13.5項「承認依存性と親子関係」を参照してください。
ディスクへのエクスポートのパブリッシュの場合、承認システムはテンプレート・コードに基づいて承認依存性をテストします。詳細は、第13.6項「ディスクへのエクスポートのパブリッシュ」を参照してください。
サーバーへのミラーリングのパブリッシュおよびXMLへのエクスポートの場合、承認システムはデータ・モデルに基づいて承認依存性をテストします。詳細は、第13.7項「サーバーへのミラーリングのパブリッシュおよびXMLへのエクスポート」を参照してください。
バージョンの一致を制御する必要がある場合、管理者は、exists、exactまたはnoneのいずれかの依存性を設定して、バージョンの一致を強制または取り消すことができます。詳細は、第13.8項「コンテンツのバージョンの一致の保証」を参照してください。
不十分な承認依存性があると判断すると、冗長な承認を回避するため、承認システムはパブリッシュされたコンテンツを検索します。詳細は、第13.12項「パブリッシュされたコンテンツの評価」を参照してください。
承認システムは、データ・モデルとテンプレート・コードで指定されている様々なタイプの依存性(たとえば、アソシエーションと推奨アソシエーション)を単純化します。その由来やタイプに関係なく、すべての承認依存性を親子関係として分類し、次のルールに従います。
別のアセットを参照するアセットは常に親アセットになります。参照されるアセットは子アセットになります。図13-17「親子関係」に、親子関係の例を示します。この例では、親としてのみ定義されるアセットが1つと子としてのみ定義されるアセットが1つあり、それ以外は親としても子としても定義されます。
親アセットは、コンテンツを子アセットに依存しています。
承認システムは、子アセットがユーザー承認済であるか、またはすでにパブリッシュの宛先に存在する場合にのみ、親アセットを承認します。
子アセットが親でもある場合、その子アセットを承認する必要があり(または宛先に存在する必要があり)、以下同様に繰り返されます。
パブリッシュ方法がサーバーへのミラーリングまたはXMLへのアセットのエクスポートの場合、バージョンの一致を要件にできます(WebCenter Sites管理者の裁量によります)。その場合、承認システムは、アセットのバージョンをチェックします。バージョンの一致の詳細は、第13.11項「Exists/Exact依存性ルール」を参照してください。
承認システムは、親アセットに関係なく、子アセットのパブリケーションを承認します。ライブ・サイトでは、親から子へのリンクが機能しないようには見えません。単に表示されないだけです。(この点で、親データが不注意でライブ・サイトから削除される可能性があります。)
図13-18「承認依存性」に、4つのアセット間の階層依存性を示し、同時に承認する必要があるアセット(承認依存性の結果として)および単独で承認できるアセットを示します。
ディスクへのエクスポートのパブリッシュの場合、承認システムはテンプレート・コードに基づいて承認依存性をテストします。
|
注意: 承認テンプレートは、ディスクへのエクスポートのパブリッシュに対する開発者の承認方針を表します。ディスクへのエクスポートのパブリッシュの承認は複雑なので、第14章「ディスクへのエクスポートのパブリッシュの様々なトピックおよび承認プロセス」で別途説明します。 |
この項は、次のトピックで構成されています。
ディスクへのエクスポートを使用してパブリッシュされるフレックス・アセットとベーシック・アセットの場合、どちらにもテンプレートと参照の2つのタイプの承認依存性があります。
テンプレート依存性は、データ・モデルから厳密に独立しており、データ・モデルでアセットがどのように関連付けられているか(またはアセットが関連付けられているかどうか)には無関係です。たとえば、データ・モデルでは、記事とイメージのアソシエーションを指定できます。サーバーへのミラーリングのパブリッシュでは、記事はコンテンツをイメージに依存しており、イメージなしではパブリッシュできません。しかし、ディスクへのエクスポートのパブリッシュでは、アセットをレンダリングするために選択されているテンプレートで、独自の依存性が定義されます。この場合、次の可能性が考えられます。
承認テンプレート・コードで記事とイメージのアソシエーションを依存性として再作成し、それによってデータ・モデルに既存の関係をパブリッシュされたページに作成します。
承認テンプレート・コードでさらに別のアセット(オーディオ・ファイルなど)に対する依存性を作成し、それによってデータ・モデルには存在しないけれどもパブリッシュされたページには存在する関係を作成します。
承認テンプレート・コードでは2つのアセット間に依存性を作成しません。したがって、パブリッシュされたページでも関係を作成しません。それらのアセットは、データ・モデルでアソシエーションが指定されていたとしても、スタンドアロン・コンテンツとして処理され、互いに独立してパブリッシュされます。
テンプレート依存性を生成するタグは次のとおりです。
<asset:load>
<asset:loadall>
<assetset:setasset>
<assetset:setlistedassets>
<render:logdep>
参照依存性は、あるページから別のページへのリンクが作成される際に生成されます。これらは、2つのページのプライマリ・アセット間の参照依存性として登録されます。たとえば、アセットAの承認テンプレートから、アセットBがプライマリ・アセットであるページへのハイパーリンクを作成した場合、承認システムはこれをアセットAのBに対する参照依存性として登録します。このような依存性を生成するタグは次のとおりです。
<render:getpageurl>
<render:gettemplateurl>
<render:gettemplateurlparameters>
ディスクへのエクスポートのパブリッシュの承認依存性は、複雑なトピックです。承認依存性の詳細は、第14章「ディスクへのエクスポートのパブリッシュの様々なトピックおよび承認プロセス」を参照してください。
アセットがディスクへのエクスポートのパブリッシュの宛先に対してユーザー承認済である場合、承認システムは、アセットに割り当てられているテンプレートのコードを評価することによって、そのアセットの承認依存性を判断します。また、コンテンツがパブリッシュされる際に明示される構成依存性のテンプレート・コードを評価するテスト・レンダリングも実行します。
構成依存性は、アセットを使用して生成されたページのアセットに対する依存性です。これらはページのテンプレートのロジックによって決まります。テンプレートを作成し、承認時に承認依存性を作成するタグと同じタグで、パブリケーション時の構成依存性も作成します。
そのタイプのアセットにデフォルト・テンプレートが割り当てられている場合、承認システムはそのテンプレートを使用して依存性を判断します。デフォルトのテンプレートがない場合、承認システムでは特定のアセットに指定されるテンプレートが使用されます。
開発者がアセット・タイプのデフォルト・テンプレートを作成するのは、ディスクへのエクスポートのパブリッシュ方法で実際にアセットをパブリッシュする場合、必ずしもそのアセットに割り当てられているテンプレートが使用されるわけではなく、別のエレメントのコードによって、状況によっては別のテンプレートでそのアセットをレンダリングすることが決定される可能性があるからです。オンライン・サイトでそのような状況になる場合、テンプレートを作成した開発者が、承認システムが承認依存性を決定する際に使用するデフォルト・テンプレートも設計していることが考えられます。
管理者またはサイト・デザイナは、アセット・タイプごとおよびパブリッシュの宛先ごとにデフォルト承認テンプレートを設定できます。第18.11項「承認テンプレートまたはプレビュー・テンプレートの割当て」を参照してください。
サーバーへのミラーリングおよびXMLへのエクスポートのパブリッシュ方法では、承認システムはデータ・モデルに基づいて承認依存性をテストします。
|
注意: サーバーへのミラーリングのパブリッシュおよびXMLへのエクスポートの場合、ライブ・サイトに不十分な構成依存性が存在する可能性があります。これは、サーバーへのミラーリングおよびXMLへのエクスポートのパブリッシュの際、ページをレンダリングするテンプレートは評価されないからです。 構成依存性は、動的ページをアセンブルしたときに現れます。構成依存性には、ページを生成するために使用する一連のアセットが含まれます。構成依存性の詳細は、第13.6.2項「テスト・レンダリング」および第14章「ディスクへのエクスポートのパブリッシュの様々なトピックおよび承認プロセス」を参照してください。 |
管理者が親アセットと子アセットのバージョンの一致を要求することによって、あらゆるパブリッシュ・セッション(たとえば図13-18「承認依存性」のもの)の条件を厳しくして、それによって自己矛盾のないコンテンツを保証できます。バージョンに対する依存性は、データ・モデルまたはテンプレート・コードのどちらにもエンコードされません。
サーバーへのミラーリングおよびXMLへのエクスポートのパブリッシュの場合は、WebCenter Sitesのmwb.conservativedependenciesプロパティ(gator.iniファイル)をexistsまたはexactに設定することによって指定します。
ディスクへのエクスポートのパブリッシュの場合は、該当するタグのdeptype属性をexists、exactまたはnoneに設定することによって指定します(タグのリストは第13.6.1項「承認依存性の評価」を参照)。
バージョンに対する依存性は、exists、exactまたはnoneの用語で修飾されます。
exists依存性は、バージョンの一致を必要としません。親をパブリッシュするには、単純に、その子アセットが承認済アセットまたはパブリッシュの宛先のパブリッシュされたアセットのいずれかとして存在する必要があります。親アセットのバージョンは、その子アセットのどのバージョンとも一致する必要はありません。
exact依存性は、バージョンの一致を必要とします。この依存性は、親のバージョンがその子アセットのバージョンと一致する必要がある(これはその依存性に関連するすべてのアセットのバージョンが互いに一致する必要があることを意味します)という点を除けば、exists依存性と同じです。
none依存性の場合、それを使用しているタグでは承認依存性が指定されません。
exists依存性とexact依存性について図13-19にまとめ、説明します。
フレックス・アセットのサーバーへのミラーリングおよびXMLへのエクスポートのパブリッシュの場合、existsまたはexactのどちらの依存性が有効なのかは、gator.iniプロパティ・ファイルのmwb.conservativedependenciesプロパティの値によって決まります。
デフォルト値(false)は、exists依存性を示します。
値trueは、exact依存性を示します。
|
注意: mwb.conservativedependenciesがfalse (exists)に設定され、属性を使用している場合、その属性の「値タイプ」、「ストレージ・スタイル」、「外部ID」、「外部表」および「外部列」の各フィールドはロックされ、変更できません。 mwb.conservativedependenciesの値を変更した場合、その変更の影響を受けるアセットを再承認する必要があります。 |
ディスクへのエクスポートのパブリッシュの場合、開発者は、getpageurlおよびassetloadといった適用可能なタグのdeptype属性を使用して、exists、exactまたはnoneに設定します。(タグのリストは、第13.6.2項「テスト・レンダリング」を参照してください)。
テンプレート依存性は、exact依存性がデフォルトです。アセットBが変更されている場合、アセットAを承認するにはアセットBを承認する必要があります。参照依存性は、常にexists依存性です。Bを一度承認してパブリッシュした場合、Aを再パブリッシュするためにBを再承認する必要はありません。
いずれかのタグでdeptype="none"が設定されている場合は例外です。その結果、タグによって承認依存性は一切作成されません。このことは、承認中に依存性のレコードが作成されないことを意味します。ディスクへのエクスポートのパブリッシュおよびライブ・サイトなど、他のすべてのコンテキストでは、deptype属性は無視されます。
サーバーへのミラーリングまたはXMLへのアセットのエクスポートの宛先に対してアセットが承認されている場合、承認システムはデータ・モデルに基づいて承認依存性を判断します。
|
注意: この項を読む場合、承認依存性のコンテキストでは、依存アセットという用語は親アセットと同等であるという点に留意してください。承認依存性の親子関係を管理するルールの詳細は、第13.5項「承認依存性と親子関係」を参照してください。 |
この項は、次のトピックで構成されています。
ベーシック・アセットの場合、承認システムは次の依存性ルールに従います。
表13-1 アセットの関係と依存性
| 承認済アセットとの関係 | 依存性 - Exists | 依存性 - Exact |
|---|---|---|
|
アソシエーション |
あり - |
該当なし |
|
ページ・アセットのみの場合: サイト・プランの下位レベルの別のページ・アセット |
あり |
該当なし |
|
埋込みリンク |
あり |
該当なし |
|
埋込みページレット |
該当なし |
あり |
アソシエーションのルール:
アセット・アソシエーションの設計方法に応じて、承認済アセットは、名前付きアセット・アソシエーションを通じて参照しているアセットに対して、exists依存性またはexact依存性があります。
ページ・アセットのルール:
承認済ページ・アセットは、サイト・プランの階層(SitePlanTree表に反映されます)でそれ自体より下位にあるページ・アセットに対して、exists依存性があります。
埋込みリンクのルール:
承認済アセットは、埋込みリンクによって参照しているアセットに対して、exists依存性があります。埋込みリンクの詳細は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。
埋込みページレットのルール:
承認済アセットは、埋込みページレットとして参照しているアセットに対して、exact依存性があります。埋込みページレットの詳細は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。
SiteEntryアセットのルート・エレメントは、CSElementアセットにより表されます。次のルールが適用されます。
承認済SiteEntryアセットは、参照しているCSElementに対して、exists依存性があります。
フレックス・ファミリ・メンバーの場合、承認システムは次の依存性ルールに従います。
表13-2 フレックス・ファミリの依存性ルール
| 承認済アセット | フレックス親定義 | フレックス親 | フレックス定義 | フレックス属性 | フレックス・フィルタ | 属性エディタ | テンプレート |
|---|---|---|---|---|---|---|---|
|
フレックス親定義 |
exists |
該当なし |
該当なし |
exists |
該当なし |
該当なし |
該当なし |
|
フレックス親 |
exists |
exists |
該当なし |
exists |
該当なし |
該当なし |
該当なし |
|
フレックス定義 |
exists |
該当なし |
該当なし |
exists |
該当なし |
該当なし |
該当なし |
|
フレックス・アセット |
該当なし |
exists |
exists |
exists |
該当なし |
該当なし |
exists |
|
フレックス属性 |
該当なし |
該当なし |
該当なし |
該当なし |
exists (デフォルト) |
exists |
該当なし |
フレックス親定義のルール:
承認済フレックス親定義は、そのフレックス親定義およびフレックス属性に対して、exists依存性があります。
フレックス親のルール:
承認済フレックス親は、そのフレックス親定義、フレックス親およびフレックス属性に対して、exists依存性があります。
フレックス定義のルール:
承認済フレックス定義は、そのフレックス親定義、フレックス親およびフレックス属性に対して、exists依存性があります。
フレックス・アセットのルール:
承認済フレックス・アセットは、そのフレックス親、フレックス・アセット定義、フレックス属性およびテンプレートに対して、exists依存性があります。
フレックス属性のルール:
承認済フレックス属性は、フレックス・フィルタに対して、そのコード化方法に応じて、exists依存性またはexact依存性があります。デフォルト・フレックス・フィルタは、exists依存性用にコード化されています。属性のタイプがアセットの場合、そのアセットに対してexists依存性またはexact依存性のどちらがあるかは、ユーザーが決定できます。
承認済フレックス属性は、(属性エディタが割り当てられている場合)その属性エディタに対して、exists依存性があります。
フレックス・ファミリ・メンバー間のexists依存性とexact依存性の詳細は、第13.11.3項「フレックス・ファミリ」を参照してください。フレックス・ファミリ・メンバーの機能の詳細は、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。
承認システムは、次のルールを使用して、Engage訪問者データ・アセット・タイプの承認依存性を判断します。
表13-3 Engage訪問者データ・アセットの承認依存性
| 承認済アセット | 履歴定義 | 履歴属性 | 訪問者属性 | 推奨 | 関連フレックス・アセット |
|---|---|---|---|---|---|
|
履歴定義 |
該当なし |
exact |
該当なし |
該当なし |
該当なし |
|
セグメント |
exists |
該当なし |
exists |
該当なし |
該当なし |
|
推奨 |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
|
プロモーション |
該当なし |
該当なし |
該当なし |
exists |
該当なし |
|
フレックス・アセット |
該当なし |
該当なし |
該当なし |
該当なし |
exists |
履歴定義は、その履歴属性に対して、exact依存性があります。
セグメントは、使用している履歴定義および訪問者属性に対して、exists依存性があります。
プロモーションは、オーバーライドする推奨アセットに対して、exists依存性があります。
フレックス・アセットは、関連アイテムとして指定されている任意のアセットに対して、exists依存性があります(関連アイテム推奨の場合)。
不十分な承認依存性があると判断すると、冗長な承認を回避するため、承認システムはパブリッシュされたコンテンツを検索します。
具体的に言うと、承認システムは、PublishedAssets表を読み取ります。現在承認を必要とするアセットが、特定の宛先にパブリッシュ済としてリストされている場合、承認システムは、バージョンの一致は要求されていないと想定して、同じアセットを承認(および再パブリッシュ)する必要はないと見なします。exact依存性がデータ・モデルまたはテンプレート・コードで指定されている場合は、承認システムは、パブリッシュされているアセットのバージョンをチェックします。コンテンツのバージョンの一致の強制の詳細は、第13.8項「コンテンツのバージョンの一致の保証」を参照してください。
この項には、承認システムの仕組みを包括的に説明するシナリオが示されています。このシナリオでは、まずユーザーがアセットを承認し、次に承認システムが依存性を分析し、最後に承認システムから対応する様子を示します。その際、サーバーへのミラーリングのパブリッシュの例およびexists依存性を使用して、この章でこれまでに説明したすべての概念、すなわち承認、承認依存性および承認状態に言及します。
このシナリオでは、(使用可能な4つのアセットのうち)アセットA2を編集し、exists依存性に従って動的にパブリッシュすることを承認します。ターゲット宛先にはA4のみがすでにパブリッシュされています。
ユーザーがパブリッシュしようとすると、承認システムはデータ・モデルをクロールして、エンコードされている依存性(図で矢印で表示)を判断します。
承認システムは、承認済アセットをシードとして使用して、データ・モデルでアセットのリンクをたどってリンク元またはリンク先の他のアセットに移動し、さらにそのアセットのリンクをたどってリンク元またはリンク先のまた別のアセットに移動するということを、シードの依存性ネットワークの境界が特定されてそれ以上依存性が検出されなくなるまで、繰り返します。
手順1の結果に基づいて、承認システムは、承認ランドスケープを構成します。承認ランドスケープでは、相互に依存するすべてのアセットおよびそれらの間の関係が特定されます。
承認システムは、承認依存性およびパブリッシュ・セッションに対するそれらの影響をテストします。この例では、承認システムは次のことを判断します。
A1は、その子の承認済アセットA2が独立してパブリッシュ可能なので、承認を必要としません。ただし、A2は親アセットでもあり、その子アセット(A3およびA4)のステータスが決定されるまではパブリッシュできません。承認システムは、今度はすでにパブリッシュされているアセットを検索します。PublishedAsset表を参照し、次のことを判断します。
A3はターゲット宛先には一度もパブリッシュされていません。A2→A3に十分な依存性があるためには、A3を承認する必要があります。
A4はターゲット宛先にすでにパブリッシュされているので、その再承認(および再パブリッシュ)は必要ありません。A2およびA3のA4に対する依存性は、パブリケーション時に十分な依存性になります。
手順4より、承認システムは、承認済アセットをパブリッシュするために3つの承認依存性が十分である必要があると結論付けて、それに基づいてアセットに独自の承認状態を割り当てます。
A2→A3承認依存性を(ユーザーがA3を承認することで)十分にする必要があります。A3に「承認が必要」状態を割り当て、A2に「保留」状態を割り当てます。
A3→A4を(すでに「承認が必要」状態が割り当てられているA3をユーザーが承認することで)十分にする必要があります。
A2→A4は、A4がすでにパブリケーションされているので、自動的に十分になります(現在「承認済かつパブリッシュ済」状態が割り当てられています)。
(承認状態の完全なリストは、表13-4「承認システムにより割り当てられる承認状態」を参照してください。)
最後に、承認システムは、アセットおよびその承認状態(図13-24で表示)のリストを表示します。ユーザーは、リストに基づいて、「承認が必要」状態が割り当てられているアセット(A3)を承認します。
承認システムは、承認プロセスを実行するために、A2の承認状態を「承認済」に更新し、A2とA3の両方を次回のパブリッシュ・セッションでのパブリケーションのためにパブリッシュ・システムにリリースします。
表13-4「承認システムにより割り当てられる承認状態」に、承認システムによって承認依存性のアセットに割り当てられ、ユーザーに表示される可能性がある承認状態を示します。
|
注意: 表13-4を参照する場合、承認依存性のコンテキストでは、依存アセットという用語は親アセットと同等であるという点に留意してください。承認依存性の親子関係を管理するルールの詳細は、第13.5項「承認依存性と親子関係」を参照してください。 |
表13-4 承認システムにより割り当てられる承認状態
| 承認状態 | 説明 |
|---|---|
|
承認済。宛先に対するパブリッシュが承認済で準備ができています。 |
(情報)このアセットは、アセットが変更されるか、または |
|
承認済かつパブリッシュ済。アセットのバージョンが宛先のアセットのバージョンと一致しています。 |
(情報) |
|
現在チェックアウトされています。宛先にはパブリッシュされません。 |
(アクションが必要な可能性あり)アセットはリビジョン追跡でチェックアウトされています。承認済ですが、リビジョン追跡が次のいずれかの方法で制御を放棄するまでパブリッシュできません。
|
|
宛先に対してエクスポートされるページでリンクとして承認されています。 |
(情報)このアセットは、エクスポートされるページからリンクされている場合、ディスクへのエクスポートのパブリッシュを承認されています。 |
|
アセットは宛先に対するパブリッシュの承認後に修正されています。 |
(アクションが必要)アセットを再承認する必要があります。 |
|
承認されましたが、宛先に対するパブリッシュの承認は、存在しない子アセットのバージョンに基づいています。 |
(アクションが必要)アセットは、そのバージョンがその子アセットのバージョンと一致するように、再承認する必要があります。 |
|
保留。承認されましたが、子アセットが宛先に対するパブリッシュを承認されていません。 |
(アクションが必要)アセットは、次のいずれかの条件が成立する場合、パブリッシュ・セッションで保留されます。
|
|
承認が必要。宛先に対するパブリッシュはまだ承認されていません。 |
(アクションが必要)アセットを承認する必要があります。 |
|
このアセットは、参照しているアセットが承認されるまでパブリッシュできません。 |
(アクションが必要)このアセットをパブリッシュできるようにするには、参照先アセットを承認する必要があります。保留されている関連アセットもリストされ、承認が必要な場合があります。 |
