17 Understanding the Approval System
The following topics describe the basic workings of the WebCenter Sites approval system. It does not contain procedures on performing specific operations. Rather, its purpose is to help the administrator gain a basic understanding of the approval system's process, which is both complex and highly interactive, especially in the case of Export to Disk publishing.
About the Approval System
Before a publishing session can begin, the user must approve assets for the publishing destination. This task is more intricate than it seems. Enterprise sites host vast numbers of assets, making it impossible for users to track which assets are bound to each other by dependencies and therefore must be approved together to be published. Unapproved assets compromise the integrity of approved assets by causing broken links among them. This is where the approval system takes over.
The ultimate purpose of the approval system is to protect the integrity of published content. The approval system does not automatically allow the publication of user-approved assets. Instead, it evaluates the condition of the user-approved assets to determine if they are ready for publication. If necessary, the approval system then assists the user in approving the supporting assets.
During its operation, the approval system ensures that asset dependencies (encoded in templates or the data model) are kept intact among approved assets. The dependencies are then reproduced on the publishing destination when the assets are published. If an approved set of assets is free of broken links, it is likely to be free of broken links when published. If an approved set of assets upholds version matching, it is likely to uphold version-matching when published.
Figure 17-1 Approval System in Publishing Methods
![Description of Figure 17-1 follows Description of Figure 17-1 follows](img/adminpubl_approvalsystem2.png)
Description of "Figure 17-1 Approval System in Publishing Methods"
Understanding Dependency Analysis
When analyzing approved assets for broken links and inconsistent versions the approval system performs a dependency test:
-
The approval system determines whether dependencies among user-approved assets match dependencies that are specified in either the template code or the data model, taking into consideration the publishing method. As shown in Figure 17-2 and Figure 17-3:
-
In Export to Disk publishing, the approval system tests dependencies (among approved assets) against template code. Dependencies are determined as the code in the template is evaluated. If a default template has been assigned to assets of a given type, the approval system uses that template to determine the dependencies. If there is no default template, the approval system uses the template that is specified for the given asset. See Evaluating Approval Dependencies.
-
In Mirror to Server publishing and Export to XML, the approval system tests dependencies (among approved assets) against the data model.
-
-
If the approval system finds that dependencies among user-approved assets are satisfied, it allows the assets to be published and releases them to the publishing system for inclusion in the next publishing session.
However, if it finds the dependencies to be breached, the approval system looks for published assets that will satisfy those dependencies at publication time and therefore turns to published content. The approval system scans the
PublishedAssets
table to determine what has been published to the target destination:-
If an asset requiring approval does not exist on the target destination (and in the correct version, if applicable), the approval system prompts the user to approve the asset.
-
If the asset requiring approval exists on the target destination (and in the correct version, if applicable), the asset will satisfy the dependency at publication time and therefore does not require approval (and re-publication).
Note:
Version matching can be imposed by the administrator. If so, user-approved assets must match the versions of published assets to satisfy the dependency criteria (which are called exists and exact).
For Mirror to Server publishing, version matching is specified in the
mwb.conservativedependencies
property, categorized under Oracle WebCenter Sites: Engage, in thewcs_properties.json
file. For Export to Disk publishing it is specified in the template code. See Ensuring Version-Matched Content.
Figure 17-2 Export to Disk Publishing Methods and Approvals
Description of "Figure 17-2 Export to Disk Publishing Methods and Approvals"Figure 17-3 Mirror to Server Publishing Methods and Approvals
Description of "Figure 17-3 Mirror to Server Publishing Methods and Approvals" -
-
On completing its analysis of all the user-approved assets, the approval system either approves or disallows the publishing of certain assets.
The approval system supports fractional publishing rather than "all or none" publishing. Assets that pass the dependency test are released to the publishing system for inclusion in the next publishing session. Assets that fail the dependency test are held back from the publishing system, and the user is informed as to which additional assets also require approval. Thus dependencies among approved assets are the cause of lighter-than-expected publishing sessions.
Dependencies among approved assets have a specific treatment and a name ("approval dependencies"), both of which are critical to the understanding of how the approval system works. Approval dependencies are described and explained in Understanding Publishing Terms and Definitions, along with the equally important terms, "approvals" and "approval states."
Understanding Publishing Terms and Definitions
Three especially important terms in the WebCenter Sites publishing model are "approval," "approval dependencies," and "approval states." These terms deal with dependencies that are critical to the understanding of how the approval system works. They are also used throughout this guide, and the WebCenter Sites publishing interface.
This section covers the following topics:
Understanding Approval: Intent to Publish vs. Permission to Publish
For an asset to be published, it requires approval first from the user, then from the approval system. To distinguish one type of approval from the other, we use the terms user-approval and system-approval.
-
The difference between user-approval of assets and system-approval of assets.
The user's approval of an asset signals the user's intent to publish the asset. The system's approval of the asset grants the publishing system permission to publish the asset.
The user's approval of an asset is equivalent to submitting the asset to the approval system for a dependency test. The system's approval of a user-approved asset is equivalent to (1) confirming that the user-approved assets pass the dependency test, and (2) releasing the asset to the publishing system for publication in the next publishing session.
-
The approval system never approves assets before the user has had a chance to do so.
When we say that an asset is system-approved, it is understood that the user has approved the asset.
-
When a user approves an asset, it is always to a given publishing destination.
When we say that an asset is user-approved, the publishing destination is understood (and explicitly identified, if necessary).
-
System-approvals are conditional.
When approving assets, the user can assign the Approved state. The approval system treats the approval as tentative and requiring verification. Only when the approval system completes the dependency test and confirms that the Approved state is valid does the system approve (release) the assets for publication.
If the approval system cannot confirm the Approved state, it rejects the state, assigns its own approval state to the assets, informs the user as to which supporting assets also require approval, and holds the current user-approved assets from publication until the user can approve the supporting assets. The system's approval of a user-approved asset is conditional on the user also approving the supporting assets. Conditional approvals are caused by approval dependencies.
-
The approval system can unapprove assets.
The approval system supports an approval queue to handle asset modification events as a way of keeping approval tables up to date. For example, if an asset is changed after it is approved for publication, the approval queue handles this change by unapproving the asset, rejecting it from the publishing queue.
The approval queue is not accessible to the user. It runs, by default, every 5 minutes. However, when you call a feature that uses approval functionality (such as the Publishing tab), the approval queue runs before the form is shown to keep approval information up to date.
Understanding Approval Dependencies
Before reading this topic, make sure you understand the distinction between the terms user-approval and system-approval. See Understanding Approval: Intent to Publish vs. Permission to Publish.
An approval dependency is a conditional dependency and results in a conditional approval:
Condition 1. An approval dependency is created if the user approves an asset that refers to another asset for content.
Condition 2. When an approval dependency is created, the system's approval of the referring asset is conditional on the approval of the referenced asset. The approval system can approve a referring asset only if the referenced asset is also approved. The referring asset is said to have an approval dependency on the referenced asset.
Note:
From this point forward, we define "referring asset" to be the parent asset. The "referenced asset" is the child asset. For simplicity, we also assume that parent assets are solely parents, and child assets are solely child assets.
An important implication of approval dependencies is the following:
While approval dependencies originate in one of two sources (the data model or template code), the number of approval dependencies is not necessarily equal to the number of dependencies in the source. The existence of a dependency in the source can lead to an unsatisfied approval dependency, a satisfied approval dependency, or no approval dependency at approval time. Which outcome is observed depends on two factors:
-
Which asset(s) the user has approved.
-
How the approval system treats approval dependencies. The approval system does not simply determine that a dependency exists for a given pair of assets. It explicitly accounts for the direction of the dependency by testing whether the approved asset is a parent or a child. If it determines that a parent asset has been approved, it logs an approval dependency. If it determines that a child asset has been approved, it does not log an approval dependency. See Examples of Approval Dependencies.
Figure 17-5 Encoded Dependencies and Approval Dependencies
![Description of Figure 17-5 follows Description of Figure 17-5 follows](img/encoded_possibledepend.png)
Description of "Figure 17-5 Encoded Dependencies and Approval Dependencies"
Examples of Approval Dependencies
This example supplements the previous section by illustrating in greater depth how approval dependencies are determined.
The preceding figure illustrates a two-asset data model. Asset A1 refers to asset A2 for content. While the data model specifies one dependency, the user has three different ways to approve the assets and, therefore, create different approval dependencies:
-
Unsatisfied Approval Dependency:
In this instance, the user approves the parent asset (A1), but not its child (A2). The approval system crawls the data model (using the approved asset as a seed), discovers the A1-to-A2 dependency, determines the dependency to be unsatisfied (by the user's approval of A1 alone), classifies the dependency to be an unsatisfied approval dependency, rejects the Approved state for A1, disallows the publication of A1 until A2 is also approved, and informs the user that A2 requires approval.
The preceding figure illustrates the system's approval of A1 as conditional on the user approving A2. A1 is said to have an approval dependency on A2. Because the approval dependency is unsatisfied, the approval system notifies the user.
-
Satisfied Approval Dependency:
In this instance, the user approves both the parent asset and its child. The approval system finds the data model dependency to be satisfied (by the user's approval of both A1 and A2), classifies the dependency to be a satisfied approval dependency, confirms the Approved states, and allows publication of both A1 and A2 when the next publishing session begins.
As in the previous instance, the system's approval of A1 is conditional on the user approving A2. This time, however, the approval dependency is satisfied. No notice is returned to the user. The asset is published in the next publishing session.
-
No Approval Dependency:
In this instance, the user approves the child asset (A2), but not its parent (A1). Here, the approval system does not recognize an approval dependency (because A2 has no dependency on A1). The approval system confirms the user's Approved state. As a result, A2 is published (but A1 will not).
Notes About Approval Dependencies
-
Data models and template code distinguish between the types of dependencies they specify (for example, associations and recommendation associations), the approval system simplifies these dependencies by treating them as parent-child approval dependencies. The parent is the referring asset and depends on its child for content. See Using Rules for Dependency Analysis.
-
Data model dependencies and template dependencies are created by the developer to specify how and which assets refer to each other for content; approval dependencies are created by users who approve assets. Approval dependencies are analyzed by the approval system and used to flag which user-approved assets can be released for publication and which must be held back from publication; which assets have yet to be approved by the user, which assets have been published, and so on.
-
Data model and template code dependencies are fixed for the given data model and template. Approval dependencies can vary, even for a fixed set of assets and a given publishing destination. This is because the combination of assets approved varies from one approval attempt to another.
Working with Approval States
When the approval system detects an approval dependency, it must either confirm the user's Approved label for each of the assets, or flag the assets with approval states of its own. An approval state is a label assigned to user-approved assets by the approval system to identify their approval status: why an approved asset cannot be published, whether the asset has been approved and published, whether an asset is eligible for publishing (that is, approved but not yet published because the publishing session has not yet been started), and so on. A complete listing of approval states is given in Table 17-4.
Figure 17-10 Approved and Unapproved Approval States
![Description of Figure 17-10 follows Description of Figure 17-10 follows](img/adminpubl_approvalsystem11.png)
Description of "Figure 17-10 Approved and Unapproved Approval States"
In Figure 17-10, the user marked asset A1 as Approved. However, the system treats the approval as tentative. Following a dependency analysis, the system determines that A1, even though approved, has an unsatisfied approval dependency on A2 and must be held from publication (until A2 is also approved).
The system overrides the user's approval of A1 by assigning A1 the Held approval state. It assigns A2 the Needs Approval state.
The list of approval states can (and typically does) vary from one approval attempt to another. This is because the combination of assets approved by the user usually varies from one approval attempt to another. The following figure illustrates a simple dependency model and three approval scenarios, all involving one and the same user.
Each arrow represents an approval dependency. For all four assets to be published, four approval dependencies must be satisfied at publication time:
A1-to-A2
A2-to-A3
A2-to-A4
A3-to-A4
(No assets have been previously published.)
Now, consider three scenarios in which the user approves different combinations of assets:
-
In the first (and ideal) attempt, the user approves all four assets, which satisfies all four approval dependencies at one time. In this scenario, the system logs four approval dependencies, determines they are satisfied, confirms the assets as approved, and allows their publication when the next publishing session begins. This is illustrated in the following figure.
Figure 17-12 Approval System - All Approved
Description of "Figure 17-12 Approval System - All Approved" -
In the second scenario (illustrated through the following figure), the user approves two assets—A1 and A2—which satisfies one of four approval dependencies. Three approval dependencies remain to be satisfied:
A2-to-A3
A2-to-A4
A3-to-A4
-
The following figure shows that the approval system logs three unsatisfied approval dependencies, determines that no assets are ready for publication, assigns its own approval states to all the assets, and returns to the user the following list:
-
A3 and A4, in the Needs Approval state.
-
A1 and A2, in the Held state; these assets cannot be published until A3 and A4 are approved.
Figure 17-14 Assets in Held State Waiting for Approval
Description of "Figure 17-14 Assets in Held State Waiting for Approval"
-
-
In the third scenario (illustrated through the following figure), the user also approves two assets—A1 and A3—but this time, satisfies no approval dependencies:
A1-to-A2
A2-to-A3
A2-to-A4
A3-to-A4
-
The approval system logs four unsatisfied approval dependencies, and determines that no assets are ready for publication (illustrated through the following figure). The approval system returns a list of assets and approval states different from the list in scenario 2.
Figure 17-16 Held Dependencies, Waiting for Approval
Description of "Figure 17-16 Held Dependencies, Waiting for Approval"The list identifies:
-
A2 and A4 in the Needs Approval state
-
A1 and A3 in the Held state
Note:
If the user had approved a different set of assets, the system would have determined different approval dependencies, and therefore different approval states for the participating assets:
-
If the user had approved A2, the approval system would have determined only three approval dependencies (A2-to-A3, A2-to-A4, and A3-to-A4), even though the data model in our example specifies four dependencies.
-
If A3 were approved, one approval dependency would have been determined (A3-to-A4).
-
If A4 were approved, no approval dependencies would have been determined.
-
-
Using Rules for Dependency Analysis
To perform its function, the approval system follows several rules, summarized below and covered in more detail in the sections that follow:
-
The approval system simplifies all approval dependencies by treating them as parent-child relationships. See Understanding Approval Dependencies and Parent-Child Relationships.
-
In Export to Disk publishing, the approval system tests approval dependencies against template code. See Working with Export to Disk Publishing.
-
In Mirror to Server publishing and Export to XML, the approval system tests approval dependencies against the data model. See Working with Mirror to Server Publishing and Export to XML.
-
If version matching must be controlled, the administrator can set an exists, exact, or none dependency to impose or cancel version matching. See Ensuring Version-Matched Content.
-
If the approval system determines the existence of an unsatisfied approval dependency, it searches for published content to avoid redundant approvals. See Evaluating Published Content.
Understanding Approval Dependencies and Parent-Child Relationships
The approval system simplifies the many types of dependencies that are specified in data models and template code (for example, associations and recommendation associations). Regardless of their origin and type, the approval system classifies all approval dependencies as parent-child relationships and adheres to the following rules.
-
An asset that refers to another asset is always the parent asset; the referenced asset is the child asset. The following figure shows an example of parent-child relationships, in which one asset is solely a parent asset, another is solely a child asset, and the rest are a mixture.
As with the previous illustrations, A1 is a parent asset, A2 is a child asset of A1 and a parent asset of both A3 and A4, A3 is a child asset of A2 and a parent asset of A4, and A4 is a child asset of A2 and A3.
-
A parent asset is dependent on the child asset for content.
-
The approval system approves parent assets only if the child assets are either user-approved or they exist on the publishing destination.
-
If the child assets are also parents, then their child assets must be approved (or must exist on the destination), and so on.
-
If the publishing method is Mirror to Server or Export Assets to XML, version matching can be a requirement (at the WebCenter Sites administrator's discretion), in which case the approval system checks assets for version. See Ensuring Version-Matched Content.
-
-
The approval system approves child assets for publication independently of their parent assets. On the live site, the link from parent to child does not appear to be broken; it simply does not appear. (In this respect, parent data can be inadvertently dropped from the live site.)
The following figure shows a hierarchical dependency among four assets to illustrate which assets must be approved concurrently (as a result of approval dependencies), and which can be approved alone.
-
For A1 to be system-approved, A2, A3 and A4 must exist as approved assets (or published assets on the destination).
-
For A2 to be system-approved, A3 and A4 must exist as approved assets (or published assets on the destination).
-
For A3 to be system-approved, A4 must exist as an approved asset (or published asset on the destination).
-
A4 can be published alone.
If an element has a child asset added to it, this causes the parent asset to be considered modified. In this instance, if the parent asset was previously approved, adding a child asset means the parent page is no longer approved. This can hold publishing of changes using the approved parent asset.
Working with Export to Disk Publishing
For Export to Disk publishing, the approval system tests approval dependencies against template code.
Note:
Approval templates represent the developer's approval strategy for Export to Disk publishing. Export to Disk publishing is described in Learning Export to Disk Publishing Terminology.
This section covers the following topics:
Evaluating Approval Dependencies
For both flex and basic assets that are published using Export to Disk, there are two types of approval dependencies: template and reference.
Template dependencies are independent of the data model, regardless of how (or whether) the assets are associated in the data model. For example, your data model can specify an article-image association. In Mirror to Server publishing, the article depends on the image for content, and cannot be published without the image. In Export to Disk publishing, however, the template chosen to render the asset defines its own dependencies. Some possibilities are:
-
The approval template code re-creates the article-image association as a dependency, thereby creating on the published page a relationship that exists in the data model.
-
The approval template code creates dependencies on yet other assets (such as audio files), thereby creating relationships that do not exist in the data model, but will exist on the published page.
-
The approval template code does not create any dependency between the two assets, thereby creating no relationship at all on the published page. The assets are treated as stand-alone content and published independently of each other, even though the data model specifies an association.
Tags that generate template dependencies are:
-
<asset:load>
-
<asset:loadall>
-
<assetset:setasset>
-
<assetset:setlistedassets>
-
<render:logdep>
Reference dependencies are generated when a link is created from one page to another. They are registered as reference dependencies between the primary assets of the two pages. For example, if we create a link from the approval template of asset A to a page where asset B is the primary asset, the approval system will register this as asset A's reference dependency on B. Tags that generate this kind of dependency are:
-
<render:getpageurl>
-
<render:gettemplateurl>
-
<render:gettemplateurlparameters>
Approval dependencies for Export to Disk publishing are a complex topic. Additional information about approval dependencies can be found in Learning Export to Disk Publishing Terminology.
Understanding Test Rendering
When an asset is user-approved to an Export to Disk publishing destination, the approval system determines approval dependencies for that asset by evaluating the code in the template that is assigned to the asset. The approval system also performs a test-render where it evaluates the template code for compositional dependencies, which are manifested when the content is published.
Compositional dependencies are the dependencies of a generated page on the assets that were used to generate that page. They are determined by the logic in that page's template. The same tags that create template and approval dependencies at approval time also create compositional dependencies at publication time.
If a default template has been assigned to assets of that type, the approval system uses it to determine the dependencies. If there is no default template, the approval system uses the template that is specified for the given asset.
Your developers create default templates for asset types because the Export to Disk publishing method actually publishes an asset, but it does not necessarily use the template that is assigned to the asset. The code in another element could determine that a different template renders that asset in certain cases. If this is the case for your site, it is likely that the developers who created the templates also designed default templates for the approval system to use when determining approval dependencies.
You or your site designers can set default approval templates for each asset type and for each publishing destination. See Assigning Approval or Preview Templates.
Working with Mirror to Server Publishing and Export to XML
For Mirror to Server and Export to XML publishing methods, the approval system tests approval dependencies against the data model.
Note:
Mirror to Server publishing and Export to XML allow for the possibility of unsatisfied compositional dependencies on the live site, because templates that render the page are not evaluated during Mirror to Server and Export to XML publishing.
Compositional dependencies appear when a dynamic page is assembled. They involve a set of assets that are used to generate the page. See Understanding Test Rendering and Working with Compositional Dependencies.
Ensuring Version-Matched Content
Any publishing session (such as the one in Figure 17-18) can be made more stringent by the administrator requiring parent assets to match child assets in terms of version. This requirement will ensure self-consistent content. Dependency on version is not encoded in either the data model or the template code:
-
For Mirror to Server and Export to XML publishing, it is specified in a property—
mwb.conservativedependencies
(in thewcs_properties.json
file)—by setting the value of the property toexists
orexact
. -
For Export to Disk publishing, it is specified by setting the
deptype
attribute in the relevant tags toexists
,exact
, ornone
(the tags are listed in Evaluating Approval Dependencies).
Dependency on version is qualified by the terms exists, exact, or none.
-
An exists dependency does not require version matching. For a parent to be published, its child assets must simply exist either as approved assets or as published assets on the publishing destination. The version of the parent asset must not match any versions of its child assets.
-
An exact dependency requires version matching. This dependency is identical to the
exists
dependency, except that the version of the parent must match the versions of its child assets (which means that all assets in the dependency must match each other's version). -
A none dependency causes the tag in which it is used to specify no approval dependency, at all.
The following figure summarizes and illustrates exists and exact dependencies.
Exists dependencies do not require version matching:
-
For A1 to be system-approved, A2, A3 and A4 must exist as approved assets (or published assets on the destination).
-
For A2 to be system-approved, A3 and A4 must exist as approved assets (or published assets on the destination).
-
For A3 to be system-approved, A4 must exist as an approved asset (or published asset on the destination).
-
A4 can be published alone.
Exact dependencies require version matching:
-
System approval of A1 is the same as an exists dependency, but the version of A1 must match the version of its child asset, A2.
-
System approval of A2 is the same as an exists dependency, but the version of A2 must match the version of its child assets A3 and A4.
-
System approval of A3 is the same as an exists dependency, but the version of A3 must match the version of its child asset A4.
-
A4 can be published alone.
Using Exists-Exact Dependencies in Mirror to Server and Export to XML Publishing
For Mirror to Server and Export to XML publishing of flex assets, whether the exists or exact dependency is in effect depends on the value of the property mwb.conservativedependencies
, in the wcs_properties.json
file.
-
The default value (
false
) setsexists
dependencies. -
A value of
true
setsexact
dependencies.Note:
When
mwb.conservativedependencies
is set tofalse
(exists) and an attribute is in use, the following fields of the attribute are locked and cannot be changed: Value Type, Storage Style, External ID, External Table, and External Column.If you change the value of
mwb.conservativedependencies
, you must re-approve the assets that were affected by the change.
Using Exists-Exact Dependencies in Export to Disk Publishing
For Export to Disk publishing, the developer sets exists, exact, or none dependencies using the deptype
attribute in applicable tags, such as getpageurl and assetload. (For a listing of the tags, see Understanding Test Rendering).
Template dependencies are by default exact dependencies. If you wish to approve asset A you must approve B if B has been changed. Reference dependencies are always exists dependencies. If you approved and published B one time, you are not required to approve it again to re-publish A.
The exception is when you set deptype="none"
on any of the tags. As a result, no approval dependency at all is created by the tag. This means no record is created for the dependency during approval. In all other contexts, such as Export to Disk publishing and live sites, the deptype
attribute is ignored.
Working with Exists/Exact Dependency Rules
When an asset is approved to a Mirror to Server or Export Assets to XML destination, the approval system determines approval dependencies against the data model.
Note:
When reading this section, bear in mind that in the context of an approval dependency, the term "dependent asset" is equivalent to the "parent asset." For rules governing parent-child relationships in approval dependencies, see Understanding Approval Dependencies and Parent-Child Relationships.
This section covers the following topics:
Understanding Dependency Rules for Basic Asset Types
For basic assets, the approval system follows the dependency rules described in the following table:.
Table 17-1 Asset Relationships and Dependencies
Relationship to Approved Asset | Dependency - Exists | Dependency - Exact |
---|---|---|
Association |
Yes by default, unless configured to be |
N/A |
For page asset only: another page asset at a lower level in site plan |
Yes |
N/A |
Embedded link |
Yes |
N/A |
Embedded pagelet |
N/A |
Yes |
Rules for associations:
-
Depending on how your asset associations are designed, an approved asset has either an
exists
orexact
dependency on assets that it references through named asset associations.
Rules for page assets:
-
An approved page asset has an
exists
dependency on page assets that are lower than itself in the hierarchy of the site plan (which is reflected in theSitePlanTree
table).
Rules for embedded links:
-
An approved asset has an
exists
dependency on assets that it references by an embedded link. See Basic Assets That Can Have Embedded Links in Developing with Oracle WebCenter Sites.
Rules for embedded pagelets:
-
An approved asset has an
exact
dependency on assets that it references as embedded pagelets. For information about embedded pagelets, see TEXTAREA in Developing with Oracle WebCenter Sites.
Understanding Dependency Rules for CSElement and SiteEntry Assets
The root element for a SiteEntry asset is represented by a CSElement asset. The following rule applies:
An approved SiteEntry asset has an exists
dependency on the CSElement that it references.
Understanding Dependency Rules for Flex Families
For flex family members, the approval system follows the dependency rules described in the following table:
Table 17-2 Flex Family Dependency Rules
Approved Asset | Flex Parent Definition | Flex Parent | Flex Definition | Flex Attributes | Flex Filter | Attribute Editor | Template |
---|---|---|---|---|---|---|---|
Flex Parent Definition |
exists |
N/A |
N/A |
exists |
N/A |
N/A |
N/A |
Flex Parent |
exists |
exists |
N/A |
exists |
N/A |
N/A |
N/A |
Flex Definition |
exists |
N/A |
N/A |
exists |
N/A |
N/A |
N/A |
Flex Asset |
N/A |
exists |
exists |
exists |
N/A |
N/A |
exists |
Flex Attribute |
N/A |
N/A |
N/A |
N/A |
exists (by default) |
exists |
N/A |
Rules for flex parent definitions:
-
An approved flex parent definition has an
exists
dependency on its flex parent definition(s) and flex attributes.
Rules for flex parents:
-
An approved flex parent has an
exists
dependency on its flex parent definition, flex parent, and flex attributes.
Rules for flex definitions:
-
An approved flex definition has an
exists
dependency on its flex parent definition, flex parent, and flex attributes.
Rules for flex assets:
-
An approved flex asset has an
exists
dependency on its flex parents, flex asset definitions, flex attributes, and template.
Rules for flex attributes:
-
An approved flex attribute has either an
exists
or anexact
dependency on its flex filter, depending on how the flex filter is coded. The default flex filter is coded for anexists
dependency. If the attribute is of type asset, the user can decide whether there is anexists
orexact
dependency on that asset.
An approved flex attribute has an exists
dependency on its attribute editor (if one is assigned).
For information regarding exists and exact dependencies among flex family members, see Understanding Dependency Rules for Flex Families. For more information about the functions of the flex family members, see The Flex Family in Developing with Oracle WebCenter Sites.
Understanding Dependency Rules for Engage Visitor Data Assets
The approval system uses the following rules to determine approval dependencies for the visitor data asset types:
Table 17-3 Engage Visitor Data Assert Approval Dependencies
Approved Asset | History Definition | History Attribute | Visitor Attribute | Recommendation | Related Flex Asset |
---|---|---|---|---|---|
History definition |
N/A |
exact |
N/A |
N/A |
N/A |
Segment |
exists |
N/A |
exists |
N/A |
N/A |
Recommendation |
N/A |
N/A |
N/A |
N/A |
N/A |
Promotion |
N/A |
N/A |
N/A |
exists |
N/A |
Flex Asset |
N/A |
N/A |
N/A |
N/A |
exists |
-
History definitions have
exact
dependencies on their history attributes. -
Segments have
exists
dependencies on the history definitions and visitor attributes used in them. -
Promotions have
exists
dependencies on the recommendation assets that they override. -
Flex assets have
exists
dependencies on any assets that are designated as related items (for Related Items recommendations).
Evaluating Published Content
If the approval system determines the existence of an unsatisfied approval dependency, it searches for published content to avoid redundant approvals.
Specifically, the approval system reads the PublishedAssets table. If assets requiring approval are listed as published to the given destination, the approval system considers it unnecessary to approve and re-publish the same assets, assuming version-matching is not a requirement. If an exact dependency is specified in the data model or template code, the approval system checks the versions of the published assets. For more information about enforcing version-matched content, see Ensuring Version-Matched Content.
Approval System Example
This section contains a scenario that provides a comprehensive illustration as to how the approval system works. The scenario begins with the user approving an asset, continues with the approval system's dependency analysis, and ends with the approval system's response. This scenario touches on all the concepts that were discussed throughout this chapter: approvals, approval dependencies, and approval states, using the Mirror to Server publishing example and an exists dependency.
-
In this scenario (illustrated in the following figure), a user edits and approves a single asset, A2 (out of a possible four), to be published dynamically under an
exists
dependency. Only A4 has been previously published to the target destination. -
When the user attempts to publish, the approval system crawls the data model to determine the encoded dependencies (represented by arrows in the following figure).
Using the approved asset as a seed, the approval system follows the asset's links to and from other assets in the data model, follows the remaining assets' links to and from still other assets, and so on until the system determines the boundaries of the seed's dependency network and no more dependencies remain to be detected.
-
From the results of step 1, the approval system constructs an approval landscape, (illustrated in the following figure) which identifies all the interdependent assets and relationships among them.
-
The approval system tests for approval dependencies and their impact on the publishing session. The following figure illustrates the approval system determination process.
Figure 17-23 System Analyzing Approval Dependencies
Description of "Figure 17-23 System Analyzing Approval Dependencies"In this example, the approval system determines the following:
-
A1 does not require approval because the approved asset A2, as its child, can be published independently. However, A2 is also a parent asset and cannot be published until the status of its child assets (A3 and A4) is determined. The approval system now searches for previously published assets. Referring to the
PublishedAsset
table, the approval system further determines: -
A3 has never been published to the target destination. A3 requires approval to satisfy the A2-to-A3 dependency.
-
Because A4 has been previously published to the target destination, its re-approval (and re-publication) is unnecessary. The dependency of A2 and A3 on A4 will be satisfied at publication time.
-
-
From step 4, the approval system concludes that three approval dependencies must be satisfied in order for the approved asset to be published, and assigns its own approval states to the assets. The following figure illustrates the system assigning approval states.
Figure 17-24 System Assigning Approval States
Description of "Figure 17-24 System Assigning Approval States"-
The A2-to-A3 approval dependency must be satisfied (by the user approving A3). The system assigns A3 the Needs Approval state and A2 the Held state.
-
A3-to-A4 must be satisfied (by the user approving A3, which is assigned the Needs Approval state).
-
A2-to-A4 is automatically satisfied by the pre-publication of A4, which is now assigned the Approved and Published state.
(A complete list of approval states is available in Table 17-4.)
-
-
Finally, the approval system shows the list of assets and their approval states (shown in the preceding figure). In response, the user approves the asset that was assigned the Needs Approval state (A3).
Figure 17-25 User Approving Supporting Asset
Description of "Figure 17-25 User Approving Supporting Asset" -
To complete the approval process, the approval system updates the approval state of A2 to Approved and releases both A2 and A3 to the publishing system (illustrated in the following figure) for publication in the next publishing session.
Figure 17-26 System Confirmation of User Approval
Description of "Figure 17-26 System Confirmation of User Approval"
Using Approval States: Reference
The following table lists the possible approval states that can be assigned by the approval system to assets in an approval dependency and shown to the user.
Note:
In the following table, bear in mind that in the context of an approval dependency, the term "dependent asset" is equivalent to the "parent asset." See Understanding Approval Dependencies and Parent-Child Relationships.
Table 17-4 Approval States Assigned by the Approval System
Approval State | Description |
---|---|
Approved. Approved and ready to publish to destination. |
(Informational) This asset will be published at the next publishing event to this destination, unless the asset is changed, or an |
Approved and published. Asset version is the same as that on destination. |
(Informational) An asset with an |
Currently checked out. Not published to destination. |
(Action may be required) The asset is checked out under revision tracking. Although approved, it cannot be published until revision tracking relinquishes control:
|
Approved for inclusion as a link in pages exported to destination. |
(Informational) This asset is approved for Export to Disk publishing, if it is linked to from the page that is being exported. |
Asset has been modified since approved for publish to destination. |
(Action required) The asset must be re-approved. |
Approved, but approval for publish to destination was based on versions of the child assets that no longer exist. |
(Action required) The asset must be re-approved so that its version matches the version of its child assets. |
Held. Approved, but child assets have not been approved for publish to destination. |
(Action required) The asset is held from a publishing session when any of the following conditions is true:
|
Needs Approval. Not yet approved for publish to destination. |
(Action required) The asset must be approved. |
This asset cannot be published until the assets it references have been approved. |
(Action required) A referenced asset must be approved before this asset can be published. Related assets that are held are also listed and may require approval. |