17 Understanding the Approval System

You can publish only those assets that you’ve approved for publishing.Assets of enterprise sites have complex interdependencies, To prevent broken links, approve assets along with their dependant assets.

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.

17.1 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 Approval System in Publishing Methods"

17.2 Understanding Dependency Analysis

When analyzing approved assets for broken links and inconsistent versions the approval system performs a dependency test:

  1. 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.

  2. 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 the wcs_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 follows
    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 follows
    Description of "Figure 17-3 Mirror to Server Publishing Methods and Approvals"
  3. 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."

17.3 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:

17.3.1 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.

17.3.2 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:

Figure 17-4 Conditional Approval

Description of Figure 17-4 follows
Description of "Figure 17-4 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 Encoded Dependencies and Approval Dependencies"

17.3.2.1 Examples of Approval Dependencies

This example supplements the previous section by illustrating in greater depth how approval dependencies are determined.

Figure 17-6 Encoded Dependencies

Description of Figure 17-6 follows
Description of "Figure 17-6 Encoded Dependencies"

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.

    Figure 17-7 Unsatisfied Dependencies

    Description of Figure 17-7 follows
    Description of "Figure 17-7 Unsatisfied Dependencies"

    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.

    Figure 17-8 Approval Dependencies

    Description of Figure 17-8 follows
    Description of "Figure 17-8 Approval Dependencies"

    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).

    Figure 17-9 No Approval Dependencies

    Description of Figure 17-9 follows
    Description of "Figure 17-9 No Approval Dependencies"

17.3.2.2 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.

17.3.3 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 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.

Figure 17-11 Simple Dependency Model

Description of Figure 17-11 follows
Description of "Figure 17-11 Simple Dependency Model"

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:

  1. 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 follows
    Description of "Figure 17-12 Approval System - All Approved"
  2. 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

    Figure 17-13 Dependency Model

    Description of Figure 17-13 follows
    Description of "Figure 17-13 Dependency Model"
  3. 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:

  4. 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

    Figure 17-15 Partial Approval State

    Description of Figure 17-15 follows
    Description of "Figure 17-15 Partial Approval State"
  5. 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 follows
    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.

      See Understanding Approval Dependencies.

17.4 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:

17.5 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.

    Figure 17-17 Parent-Child Relationships

    Description of Figure 17-17 follows
    Description of "Figure 17-17 Parent-Child Relationships "

    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.

Figure 17-18 Approval Dependencies

Description of Figure 17-18 follows
Description of "Figure 17-18 Approval Dependencies"
  • 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.

17.6 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:

17.6.1 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.

17.6.2 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.

17.7 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.

17.8 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 the wcs_properties.json file)—by setting the value of the property to exists or exact.

  • For Export to Disk publishing, it is specified by setting the deptype attribute in the relevant tags to exists, exact, or none (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.

Figure 17-19 Exists/Exact Dependencies

Description of Figure 17-19 follows
Description of "Figure 17-19 Exists/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.

17.9 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) sets exists dependencies.

  • A value of true sets exact dependencies.

    Note:

    When mwb.conservativedependencies is set to false (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.

17.10 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.

17.11 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:

17.11.1 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 exact

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 or exact 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 the SitePlanTree table).

Rules for embedded links:

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.

17.11.2 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.

17.11.3 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 an exact dependency on its flex filter, depending on how the flex filter is coded. The default flex filter is coded for an exists dependency. If the attribute is of type asset, the user can decide whether there is an exists or exact 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.

17.11.4 Understanding Dependency Rules for Engage Visitor Data Assets

The approval system uses the following rules to determine approval dependencies for the Engage 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).

17.12 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.

17.13 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.

  1. 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.

    Figure 17-20 User-Approved Asset

    Description of Figure 17-20 follows
    Description of "Figure 17-20 User-Approved Asset"
  2. 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).

    Figure 17-21 System Crawling Data Model

    Description of Figure 17-21 follows
    Description of "Figure 17-21 System Crawling Data Model"

    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.

  3. 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.

    Figure 17-22 System Creating Approval

    Description of Figure 17-22 follows
    Description of "Figure 17-22 System Creating Approval"
  4. 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 follows
    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.

  5. 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 follows
    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.)

  6. 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 follows
    Description of "Figure 17-25 User Approving Supporting Asset"
  7. 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 follows
    Description of "Figure 17-26 System Confirmation of User Approval"

17.14 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 exact dependency changes.

Approved and published. Asset version is the same as that on destination.

(Informational) An asset with an exact dependency has been published to this destination.

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:

  • Check in – The asset must be re-approved.

  • Undo Checkout – The asset remains approved and can be published.

  • Rollback – The asset must be re-approved.

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:

  • The asset was approved, but was then re-edited and has not yet been re-approved.

  • The asset has a child asset with an exact dependency, and that child asset is not approved.

  • The asset has a child asset with an exists dependency and that child asset has never been published.

  • The asset has a child asset with an exact dependency. The child asset has been published, but it has since been edited and is not yet approved.

  • The asset has an exact dependency on a child of another asset that was previously approved, but has since been edited and is not yet re-approved.

  • The asset is checked out (revision tracking).

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.