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