In the Export to Disk publishing context, a page is typically an HTML file that is exported to a disk. (The file is not to be confused with a Page asset type.) Each exported page is represented by a page.

A publish key (or pubkey) is strictly a publish-time term. A pubkey represents an atomic publishing unit, which in the case of Export to Disk publishing is an exported file, equivalent to a page, not to be confused with a Page asset type).

A pubkey is defined by two constructs: an asset, and a publish-time template (not to be confused with an approval template).

The initial pubkeys in Export to Disk publishing are the starting points defined by the user who initiates the publishing session. All other pubkeys are discovered and logged during publishing.

A publish queue is a list of pubkeys awaiting publication. For a pubkey to be added to the publish queue, its primary asset must be approved.

The primary asset participates in the definition of a pubkey. In layman's terms, its ID and type become the cid and c parameters for the template. A primary asset must be approved before its page or pages can be exported.

Approval in Export to Disk publishing allows the developer to define dependencies that ensure the correct content is published and that it is published intact.

Compared to mirror publishing, in which asset dependencies in both the approval stage and publishing stage are determined by the asset model, Export to Disk publishing is entirely template-oriented. As a result, approval behavior (and publish-time behavior) is defined by the developer who writes the approval templates (and the publish-time templates). WebCenter Sites then uses the approval template to discover an asset's dependencies. If an asset is published against the approval template, its approval dependencies are likely to be the same as its compositional dependencies. For more information, see Working with Compositional Dependencies.

Approval templates are assigned by use of the Set Default Templates feature in the Publishing Destination form.

• If a default template is not explicitly chosen, the approval system will choose the asset's default template.

• If neither the approval nor default template is specified, the asset will be approved without an approval template (that is, it will have no approval dependencies).

If the approval template is shared among sites, the approval system will choose the site entry corresponding to the current site.

The approval queue handles asset modification events to keep approval tables up to date. For example, if an asset is approved for publication, but you then change it, the approval queue will handle this by unapproving the asset—rejecting it from the publish queue.

You never work directly with the approval queue. The queue runs every five minutes by default. However, if you call a feature that uses approval functionality (such as the Publishing tab), the approval queue is forced to run before it is rendered to keep approval information up to date.

When you approve an asset, its approval template (see Using the Approval Template) is used to determine its approval dependencies. The following tags create approval dependencies:

• <asset:load>

• <asset:loadall>

• <assetset:setasset>

• <assetset:setlistedassets>

• <render:logdep>

• <render:getpageurl>

• <render:gettemplateurl>

• <render:gettemplateurlparameters>

If you approve asset A whose template (or any element called by the template) references asset B using a tag listed above, an approval dependency is created from A to B. This typically means that when you want to approve A, you must also approve B.

Types of Approval Dependencies

Approval dependencies are created and used at approval-time, not to be confused with publish-time dependencies (even though they can be the same). Approval for Export to Disk publishing involves two types of approval dependencies:

• Template dependencies

• Reference dependencies

Template dependencies are created when an asset's approval template uses another asset to define the content. For example, if asset A's approval template loads asset B, then A has a template dependency on B. In more practical terms, if you have an approval template for a Page asset that shows an Article asset, the Article asset is used on the Page, so the dependency is of a template kind. The following tags generate template dependencies:

• <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>

Template dependencies (in Export to Disk publishing) are by default exact dependencies — to approve 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. In that case, no approval dependency at all is created by that tag. This means no record is created for it during approval; in all other contexts, such as Export to Disk publishing and live sites, the deptype attribute is ignored.

The purpose of the publish-time template is to render content as files. Typically, publish-time templates are identical to the approval templates. When they differ, content can be published without first being approved. Bypassing the approval system requires the developer to provide a means for publishable content to be validated.

The starting point is the pubkey (or pubkeys) where export begins, which is at publish-time. Typically, starting points are selected to link to most if not all the pages on your site. (The page is not necessarily the home page. For example, it could be a sidebar with many links.) The Export to Disk publishing system crawls your site, beginning with the starting points, and logs new pubkeys as it discovers them.

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 Working with the Publish-Time Template. Compositional dependencies dictate what is rendered on the exported page as prescribed by the template, completely ignoring any deptype attributes. The same tags that created template and reference dependencies in the approval template also create compositional dependencies at publish-time. The tags are listed in Using Approval Dependencies.

Setup: Page P asset uses Ttemplate for both approval and publishing. Ttemplate loads HelloArticle A, therefore establishing a template dependency.

Starting Point: P+Ttemplate

Pubkeys (exported files): P+Ttemplate

Approval Dependencies: Page P has template dependencies on Ttemplate because of <render:logdep>, and on HelloArticle A because of <asset:load>. Because Ttemplate does not create any links, there are no reference dependencies.

Publish Dependencies: Starting Point is the only pubkey; therefore only one file is exported.

Note that the exported page does not have any publish-time compositional dependencies because it is never actually used by the template. There is only reason why P had to be approved—P is the exported page's primary asset. So, the only compositional dependencies determined at publish-time are the exported page's dependencies on A and Ttemplate.

Setup: Page P asset uses Rtemplate for both approval and publishing. Rtemplate references HelloArticle A, which is in turn rendered by dummyTemplate.

Starting Point: P+Rtemplate

Pubkeys (exported files): P+Rtemplate, A+dummyTemplate

Approval Dependencies: Page P has the routine <render:logdep> template dependency on its Rtemplate. In addition, it establishes a reference dependency on A because of <render:getpageurl> (but not on dummyTemplate, because dependencies between pages are logged only between their primary assets). Note that dummyTemplate does not participate in an approval dependency because it is not referenced by any tags.

Publish Dependencies: The relevant tags are <render:logdep> and <render:getpageurl>. These dictate the publish-time compositional dependencies as Rtemplate and A. As before, note that Page P does not have a compositional dependency because it is not used by any of the templates. When export encounters <render:getpageurl>, it detects that another page is involved, so it creates the A+dummyTemplate pubkey on-the-fly, and runs dummyTemplate to generate its contents. Note that dummyTemplate does not officially have a compositional dependency because it is not used by any tags—it participates only as a pubkey member; so, if dummyTemplate is changed, the approval/publishing cycle will not recognize the change. For this reason, we advise not altering <render:logdep>, which opens on every newly created template.

Asset A uses T1 for approval. T1 does not reference any assets. Asset A uses T2 for publishing. T2 references asset B using <asset:load>. T2 loads asset B, which was never approved, but B will nevertheless be on the exported A+T2 page.

Does this mean you can publish assets that were never approved?

Yes! Some users prefer this, only to avoid approving assets before publishing. Approval can be a taxing operation because exact dependencies cause primary assets to be given Held status if the dependent assets change. As a result, pages of those primary assets cannot be exported. However, a better way to handle such situations is to make good use of the deptype attribute with exists or none values to avoid unwanted approval dependencies.

Now, what happens after asset B is published and then we change B? In this case, there is no approval dependency between asset A and asset B, but there is a compositional dependency. Whenever asset B is changed, the affected pages are automatically re-published. (Because there are no dependencies, the automatic refresh option is chosen). So, A+T2 are placed in the publish queue automatically as soon as asset B is saved—not approved. For information about republication options, see Frequently Asked Questions About the Export to Disk Publishing Process.

Asset A uses T1 for approval. T1 references asset B using <asset:load> under an exact dependency. Asset A uses T2 for publishing. T2 does not reference asset B.

In this case, there is an approval dependency between asset A and asset B, but there is no compositional dependency. Whenever asset B is changed, asset B has to be approved before asset A can be approved, even though the published page does not make any use of asset B.

Asset A uses T1 for approval. T1 does not reference any assets. Asset A uses T2 for publishing. T2 references asset B using <asset:getpageurl>.

In this case, there are no approval dependencies, so A is the only approved asset. During publishing of A+T2, we realize there is another page to be created, with B as the primary asset. Now, remember that primary assets must be approved before their page is exported. However, B is not approved, so its page is not exported. A+T2 is exported, but has a broken link.

Unknown dependencies and Export to Disk publishing. Situations become complicated when you start using <render:unknowndeps>. This tag removes compositional dependencies, and it records unknown dependencies to the pubkey. Assets thus remain in the publish queue permanently (meaning they are refreshed with every publish cycle). This behavior is expected, because if unknown dependencies exist (that is, dependencies may change at any moment, such as query results), the system cannot determine which assets a given asset depends on. To be on the safe side, the system always republishes the assets.

Many exact dependencies. While this is not always avoidable, keep in mind that when a primary asset has exact dependencies on other assets, a change to any of the dependent assets will cause the approval system to change the primary asset's status to Held. The primary asset's page is not publishable unless approved again. If the modified asset is used by many pages, they will all require re-approval. Consider setting the deptype to exists, and make the dependent pages automatically publishable—but the modified asset must be ready when the publishing session begins.

<render:getbloburl blobtable='MungoBlobs' 
   blobcol='urldata' blobkey='id' 
   blobwhere='1088466917821'  outstr='pagelogoURL' 
   csblobid='1088466917821'>

<render:argument name='PREFERREDFILE' 
   value='myBlob.out'/>
<render:argument name='PREFERREDDIR' value='myDir'/>
</render:getbloburl>

Export path variables are defined as follows:

• <cs.pgexportfolder> defines the root directory for all exported files. <cs.pgexportfolder> is the value of the cs.pgexportfolder property in the wcs_properties.json file. It is a required value and applies to all Export to Disk publishing destinations.

  Typically, <cs.pgexportfolder> names a testing location (a file system where the exported files are verified) rather than a location directly on the delivery system.

• <DIR> is the value of the publishing argument DIR, which is used to create subdirectories of the root directory (specified by cs.pageportfolder). When <DIR> is specified, WebCenter Sites creates <cs.pgexportfolder>/<DIR>.

  Note:

  The DIR publishing argument is available to administrators as the Base Directory field in the Add New Destination form (see Configuring an Export Destination). Throughout this section, we use <DIR> to mean Base Directory.

  This argument is typically used to organize the contents of the root export directory when multiple export destinations exist for your sites.

  Note:

  The directory specified by <cs.pgexportfolder> or <cs.pgexportfolder>/<DIR> is called the destination directory.

• <file_dir> takes a value listed below, depending on whether the exported asset is a page asset and whether path information is available. <file_dir> is determined hierarchically, as WebCenter Sites looks for the values listed below, in the order shown. It is assumed that SIMPLEDIR=false.

  Table 45-3 Possible File_Dir values

  Possible <file_dir> Values	Description
  <ForDestination:Path>	Value of the For Destination: Path field (the field is shown in the Specify Path/Filename for Destination form for a specific destination). Setting a value in the ForDestination: Path field forces the asset to take the specified path when the asset is exported to the specified destination. If <ForDestination:Path> is not set, WebCenter Sites uses <parent_page's_path>.
  <parent_page's_path>	Value of the Path field for the exported asset's parent page. Note for Page Assets: When exported, a page asset takes the path that is set for its parent page, not the one set for itself. (As a rule, a page asset's Path is applied only to child assets.) If <parent_page's_path> is not set, WebCenter Sites uses <ID_of_parent_page>.
  <asset's_path>	Value of the exported asset's Path field. Note: <asset's_path> is used only for assets that are not page assets. If <asset's_path> is not set, WebCenter Sites uses <ID_of_parent_page> as the value of <file_dir>. If both <parent_page's_path> and <asset's_path> are not set, WebCenter Sites uses <ID_of_parent_page>.
  <ID_of_parent_page>	ID of the asset's parent page. This value is used if <parent_page's_path> and <asset's_path> are unknown.

• SIMPLEDIR. Although this publishing argument is not explicitly part of the export path, it determines whether <file_dir> is used when path information is unavailable. That is:

  • If SIMPLEDIR is set to true and path information is unavailable, <file_dir> is omitted from the export path. Setting a path overrides SIMPLEDIR.

  • If SIMPLEDIR is set to false and path information is unavailable, <file_dir> takes <ID_of_parent_page> as its valuė.

    Note:

    The SIMPLEDIR publishing argument is available to administrators as the Use simple directory naming check box in the Add New Destination form (see Configuring an Export Destination).

This section summarizes the export paths that WebCenter Sites can construct using the convention:

<cs.pgexportfolder>/<DIR>/<file_dir>

Note that only <file_dir> varies in all the examples below

This section covers the following topics:.

• Using a Forced Export Path

• Using an Export Path for Page Assets

• Using an Export Path for Assets Other than Page

• Using Sample Export Paths

URLs in links for HREFs within the exported files do not include the values that specify the destination directory (<cs.pgexportfolder>/<DIR>). Instead, they begin within the destination directory and are relative to that directory.

The URL Prefix field on the Destination Configuration form is used to resolve URLs by specifying the location of those files on the delivery system. That is, URLs for links within the exported files are created like this:

<URLPREFIX>/<path_of_parent_page>

The value for URL Prefix must match the value of the web alias that identifies the directory where the files are found. If you are using only cs.pgexportfolder to create the destination directory, the web alias that the URL Prefix represents must point to that location. And if you have set the Base Directory field on the Destination Configuration form to add a subdirectory to the root directory specified by cs.pgexportfolder, be sure that the web root or the web alias represented by URL Prefix points to this directory.

How WebCenter Sites names an exported file depends on whether a file name is provided by the asset (in the Inspect form) and whether Use Simple File Naming is selected on the Destination Configuration form. For more information about this setting, see Configuring Your System for Export to Disk Publishing. Possible file names are shown in the following table. The naming convention is explained after the table.

• <pagename> is the name of the SiteCatalog page entry of the template that is used to render the asset. (All template assets have SiteCatalog page entries.)

  Note:

  <pagename> is dropped when the Use Simple File Naming parameter is selected in the Destination Configuration form. Use the Use Simple File Naming option selectively. If your assets are rendered by multiple templates, do not select Use Simple File Naming.

• <packedargs(if any)> are passed in from the page entry's root element. If any packed arguments are passed in from the root element of the asset's rendering template, the values of those arguments are also included in the name of the file generated for the asset.

  For information about packed arguments and how they relate to URLs, see Using the referURL Variable in the Developing with Oracle WebCenter Sites.

• <filename> is the value of the asset's Filename field. If the Filename field is empty, WebCenter Sites uses the asset_ID specified in the asset.

  Note:

  A file name set for an asset for a specific destination in the Specify Path/Filename for Destination form supersedes the file name provided in the Filename field on the asset's New or Edit form when the asset is exported to that destination.

• <asset_ID> is the ID that is specified in the asset. <asset_ID> is used if the asset's Filename field is empty or if the following note applies.

  Note:

  WebCenter Sites requires both the asset's ID and type to determine whether a file name is provided for the asset. If the identity of the asset's type is not provided, the file name cannot be used. In such a case, WebCenter Sites uses the asset's object ID in place of its file name.

• <SUFFIX> is a destination configuration option that specifies the extension of the file name..

The following table provides examples of how file names are created during Export to Disk publishing. In the examples given, Use Simple File Names is not selected in the destination configuration.

The Export to Disk publishing method cannot begin rendering files unless it knows where to start. You tell it where to start by designating at least one starting point: that is, a page asset and the template that should be used to render it. WebCenter Sites calls the root element of the template's page name, and begins rendering every approved asset that is connected to that export starting point  — assets connected through an association, a link, a navigation bar, a query, and so on.

This procedure must be performed only one time on each source system, regardless of the number and types of publishing destinations you are configuring.

If you have not done so, create the batch user account. For instructions, see Creating the Batch User Account (If One Does Not Exist).

If an account exists for your installation, skip to Specifying the Root Export Directory.

The purpose of creating a batch user account is two-fold:

• Configure a batch user account for the publishing system on the source to use.

• Specify where the publish logs should be stored.

The procedures in this section require you to set several properties in the wcs_properties.json file. Additional properties are also available to you for fine-tuning your system configuration. For a complete list of properties, see Oracle WebCenter Sites JSON Property File in the Property Files Reference for Oracle WebCenter Sites.

1. In the Admin interface, open the Property Management Tool. (For instructions on accessing the Property Management Tool, see Overview of the Property Management Tool in the Property Files Reference for Oracle WebCenter Sites.)
2. In the Name field, enter cs.pgexportfolder.
3. Click Search.
4. In the Properties section of the form, select the name of the property. Set the value to the file directory (location) to which all files should be exported.

   This is a global setting for the system. If you have multiple destinations and want the files published to those destinations to be stored in separate subdirectories within this directory, enter a value in the Base Directory field when you configure those destinations (in Configuring an Export Destination).

   For more information about export directories, see Working with the Path Naming Convention.

5. Click Save.
6. Restart the application server.

1. Log in to the Admin interface on the source WebCenter Sites system.
2. In the General Admin tree, expand the Admin node, expand the Publishing node, expand the Destinations node, and then double-click Add New.

   The Add New Destination form opens.

3. Fill in the fields on the Add New Destination form as follows:

   • In the Name field, enter a unique name for the destination.

     Note:

     The following characters are not allowed in the Name field: single quote ('), double quote ("), semicolon (;), colon (:), less-than sign (<), greater-than sign (>), percent (%), and question mark (?). Additionally, the name cannot end with a backslash (\).

   • In the Delivery Type drop-down list, select Export to Disk: Export Web Files to Disk. The available fields on the form will change slightly.

   • Base Directory: Enter a subdirectory name for the files published to this export destination. The base directory is created as a child directory of the root directory that is specified by the cs.pgexportfolder property.

     When you enter a value in this field, the export path for the publishing destination is as follows:

     <cs.pgexportfolder>/<DIR>
     

     where <DIR> is the base directory.

     Note:

     URLs that are contained in exported files do not include this destination directory path in the URL. Exported files have URLs that begin below this level, inside the destination directory. Therefore, if you enter a value in this field and you enter a value in the URL Prefix field as well, be sure that the web root or the web alias represented by the URL Prefix field points to this directory.

     This parameter is typically used to organize the contents of the root export directory when there are multiple export destinations for your sites.

   • URL Prefix: Enter the prefix that the export process will add to the beginning of the URLs that are used as links (HREFs) within the exported files. The names of the generated files do not include this prefix , only the links within the files use it.

     Specify the web server alias of your delivery system in the URLs so that the links in the HTML files can be resolved when the files are moved to that system. If you leave this field blank, URLs are relative.

     Be sure that the name of the web alias on the testing system is the same as the name of the web alias on the delivery system.

   • Suffix: In this text box, specify the file suffix to use for the generated files when the Filename field for the asset is not used or it does not specify a suffix. The default is html.

   • Use simple file naming: If this parameter is selected, WebCenter Sites overrides the normal file-naming conventions by ignoring the SiteCatalog page entry of the template that is used to render the asset and uses only the value entered in the asset's Filename field as the file name. If the asset does not have a filename, WebCenter Sites uses the asset's ID, instead. See Working with File Naming Conventions.

     There is one exception to this rule: assets with upload fields (assets that are blobs) will always receive a standard (long) file name, even when this value is set to true.

     Caution:

     The Use simple file naming parameter must be used with caution. If your site is designed such that individual assets are rendered by multiple templates, you must not use this parameter. Without the SiteCatalog page entries used in the file name, file names cannot be guaranteed to be unique when an asset is rendered by multiple templates.

   • Use simple directory naming: When selected, this parameter overrides the normal directory-naming convention. See Working with the Path Naming Convention.

     When Use simple directory naming is selected, WebCenter Sites puts the rendered HTML file directly into the default export directory when there is no path information available from the parent asset. (Normally, WebCenter Sites uses the page asset's ID when there is no path information.) If there is a value in the Path parameter of the asset's parent page asset, this selection is ignored.

   • Old Template: Select this parameter to use the rendering methodology that was standard in 3.5 and earlier versions of the product.

     Note:

     If the online site that you present on your delivery system was designed for the rendering model used in WebCenter Sites versions before 3.6 and it has not yet been redesigned for the 3.6 rendering model, you must select this parameter.

     If you select this parameter, do not set an export starting point for your site. The export starting point is determined by the templates themselves.

   • Send Email on Failure: If publishing fails and email notices to that effect are required, select this option. Additional fields appear.

     • Email Addresses: Enter the recipient's email address, and click Add. (This field is shown only when Send Email on Failure is selected). All email addresses that will receive an email on failure are shown.

   • Verbose Output: Activates detailed error logging during the publishing process. When selected, messages in addition to error messages are written to the PubMessage table. Because additional information lengthens the publishing process, be sure to select this option only for troubleshooting.

   • More Arguments: No additional arguments can be specified at this time.

   • Sites: Select the sites whose assets can be approved for and published to this destination.

   • Roles (Approve for Publish): Select the roles to which you are assigning approval privileges. All users assigned these roles can approve assets.

4. Click Add New Destination.

   The Publish Destination form opens. The new destination is shown on the form.

   Figure 45-10 Publish Destination Form

   
   Description of "Figure 45-10 Publish Destination Form"
5. Repeat steps 2–4 for each additional export destination.

To make your exported content available to the public at its final destination (your delivery system), you must configure your web server to map a URL path prefix to the place where the files will reside so that URLs can resolve.

See the vendor documentation for your web server for information about the appropriate procedure for mapping URL prefixes on your web server. Remember that the name you specify for this prefix must match the name that you specified with the URL Prefix destination configuration parameter for the destination. If you enter a URL Prefix, be sure that the web root or alias includes the directory you entered.

To perform a simple test of your configuration, select the export starting point with the fewest number of dependent assets and approve each of those assets.

To complete a test publish of your entire site, approve all the assets for the site. See Approving Multiple Assets.

1. In the Admin interface on the source system, click Publishing in the button bar.
2. In the Publish Console, select your destination from the drop-down list and click Select Destination.

   WebCenter Sites shows information about the assets that are ready to be published to this destination. (If you have not yet created an export starting point for this destination, the form states this fact. You must create at least one export starting point before the publishing session can begin.)

3. Click Publish.

   A confirmation message opens. Click Yes to proceed with publishing.

   The publishing system exports all the approved assets for this destination into files.

4. In the Publish Console Active tab you can observe that the session is running.
5. When the session completes, click the History tab to view the session summary for this session.

   Mouse over the session information to view summary information;

6. In the Publish Console History tab, select the link to the publishing destination.

   A session summary shows a list of all the files that were created during the export process.

7. Click the Preview (binoculars) icon next to the file representing the top-level page in your site.

   The page opens in a new browser window.

8. Scan the page for errors and test all the links. Make sure to test links to all of the other files that were generated.
9. Test the results by directly entering the URL of the rendered home page into your browser and navigating the entire site. To do this, you must first set up a web server root on the WebCenter Sites management system that points to the export directory.
10. If you decide that the files are ready for delivery, copy them to your delivery system.

1. Create scheduled publish events for the destination. For help with this step, see Scheduling a Publish Event.
2. Plan how you will copy the generated files to your web servers, for both the testing area and the delivery system. For example, you can set up a script that automatically copies the files by FTP to a testing area after a publishing session completes.

In addition to the batch user account on the source system that a publish event uses to process a publishing session, the Mirror to Server publishing method requires another user account: the mirror user account, which is located on the destination server. This is the user account that the publishing system uses to unpack the mirror queue on the destination system.

When you set up a Mirror to Server publishing destination, you must create the mirror user account on the destination system that the destination represents.

The CacheManager is a WebCenter Sites servlet that maintains the page cache on any dynamic WebCenter Sites system, including the management system.

CacheManager is important because it locks the appropriate assets on the destination during a mirror publishing session and ensures the integrity of the page cache both before and after a mirror publishing session.

See About the CacheManager in Developing with Oracle WebCenter Sites.

The Mirror to Server publishing method copies information for approved assets from one WebCenter Sites database to another. This information must be configured for the mirror destination. Configuring a mirror destination involves two steps: initializing the destination, and configuring the data for the destination.

Whenever you create a new mirror destination, you must initialize it before you can publish to it. To initialize a mirror destination, you specify the following information:

• The sites. Based on the sites that you select, the appropriate rows from the Publication, SitePlanTree, and PublicationTree tables are mirrored to the destination.

• Any custom table that supports or is directly related to your asset types. In other words, a table for assets that was not created by either AssetMaker or Flex Family Maker. Examples of these are Source and Mimetype. These tables are called auxiliary tables.

Mirror destination configuration is the process of indicating which data (for example, assets types, associations, and start menu items) is mirrored to the target destination. Mirror destination configuration moves configuration data and rows from auxiliary tables—which are non-asset database tables that are used for the dynamic display of the assets—from one WebCenter Sites database to another.

You use Mirror Destination Configuration in several situations:

• To set up a new mirror destination.

• To move configuration items that support asset types (start menu items, associations, and so on) from a development system to a management system or to a delivery system.

• To move workflow configuration data from a development system to a management system.

• If you or your developers add any additional sites, asset types, or auxiliary tables to your system.

• If you or your developers add any additional categories or subtypes for existing asset types.

• When you must troubleshoot your configuration. If you can successfully initialize a mirror destination, that means that the source and the destination systems are communicating.

This procedure must be performed only one time on each source system, regardless of the number and types of publishing destinations you are configuring.

If you have not done so, create the batch user account. For instructions, see Creating the Batch User Account (If One Does Not Exist).

If a batch user account exists on your source system, skip to Setting Up the Destination System.

1. If you have any custom support tables—a lookup table for a field in an asset type, for example— create those tables on the destination system.
2. On the destination system, create the mirror user.

   Note:

   The mirror user has the same privileges as the RealTime user configured for RealTime publishing. If a RealTime user is configured for RealTime publishing, the same user may serve as the mirror user.

   • This user must have the following ACLs:

     • Browser

     • ElementEditor

     • PageEditor

     • TableEditor

     • Visitor

     • VisitorAdmin

     • xceladmin

     • xceleditor

   • Because the mirror user account is used by the CacheManager to regenerate the page cache after a publishing session, the mirror user must have sufficient privileges to regenerate all the pages in the cache. Therefore, the mirror user account must be given to all ACLs which are assigned to page entries in the SiteCatalog table or database tables that are holding data to be rendered.

     Note:

     If any of the sample sites are installed on the destination system, a user named mirroruser exists. For security, if you decide to keep this user as your mirror user, be sure to change the password for this user; or if you decide to create a different mirror user, be sure to delete the sample site mirroruser.

   • If you require help with creating the mirror user, see Creating a User in the Admin Interface.

1. In the Admin interface, open the Property Management Tool. (For instructions on accessing the Property Management Tool, see Accessing the Property Management Tool in the Property Files Reference for Oracle WebCenter Sites.)
2. In the Category drop-down menu, select Publish.
3. Click Search.
4. Set values for and save the following properties:

   • cs.mirroruser

     Set this property to the name of the user that you created on the destination system in the preceding procedure.

   • cs.mirrorpassword

     Set this property to the password of the user that you created on the destination system in the preceding procedure.

5. Complete either:

   • If there is a firewall separating your source system from the destination system, go to Identifying the Local Proxy Server to the Source System (If One Exists).

   • If there is no firewall separating your source and destination systems, stop and restart the application server. Then go to Creating a Mirror Destination.

1. In the Admin interface, open the Property Management Tool. (For instructions on accessing the Property Management Tool, see Accessing the Property Management Tool in the Property Files Reference for Oracle WebCenter Sites.
2. In the Category drop-down menu, select Publish.
3. Click Search.
4. Set values for and save the following properties:

   • cs.mirrorproxyserver

     Set this property to either the name or the IP address of the local proxy server.

   • cs.mirrorproxyserverport

     Set this property to the port number of the local proxy server.

5. Restart the application server.

1. Log in to the Admin interface on the source WebCenter Sites system.
2. In the General Admin tree, expand the Admin node, expand the Publishing node, and then expand the Destinations node.
3. Under the Destinations node, double-click Add New.

   The Add New Destination form opens.

   Figure 45-15 Add New Destination Form

   
   Description of "Figure 45-15 Add New Destination Form"
4. Configure the fields on this form as follows:

   • Name: Enter a unique name for the destination.

     Note:

     The following characters are not allowed in the Name field: single quote ('), double quote ("), semicolon (;), colon (:), less-than sign (<), greater-than sign (>), percent (%), and question mark (?). Additionally, the name cannot end with a backslash (\).

   • Delivery Type: Select Mirror to Server: Copy database rows to remote server.

   • Destination Address: Enter the URL of the remote server in the format shown. For <targetserver:port>, enter the host name or IP address of the target system and the port to be used by the destination. A slash is required after the URL because this URL is appended dynamically.

   • Remote User: Enter the name of the mirror user created in Setting Up the Destination System. This user is called by the publishing system to unpack the mirror queue on the target system.

   • Remote Password: Enter the password of the mirror user.

   • Send Email on Failure: If publishing fails and email notices to that effect are required, select the check box.

     • Email Addresses: Enter the recipient's email address. (This field is available only when Send Email on Failure is selected.)

   • Verbose Output: Select this option to activate detailed error logging during the publishing process. When selected, messages in addition to error messages are written to the PubMessage table. Because additional information lengthens the publishing process, select this parameter only for troubleshooting.

   • More Arguments: This parameter is reserved for future use; no additional arguments can be specified at this time.

   • Sites: Select the sites whose assets can be approved for and published to this destination.

   • Roles (Approve for Publish): Select the roles to which you are assigning approval privileges. All users who are assigned these roles are allowed to approve assets.

   • Roles (Publish): Select the roles to which you are assigning publish privileges. All users assigned these roles can publish.

5. Click Add New Destination.

   WebCenter Sites opens the Publish Destination form.

   Figure 45-16 Publish Destination Form

   
   Description of "Figure 45-16 Publish Destination Form"
6. If you are ready to initialize this destination system (you must initialize the destination system before you can publish to it), click the Initialize Mirror Destination button in the Publish Destination form, then proceed to Initializing the Destination for detailed instructions (begin at step 4 of that procedure).

   If you must create more mirror destinations, repeat steps 1 through 5 for each additional mirror destination that you must create for your source system.

1. In the General Admin tree, expand the Admin node, expand the Sites node, and then double-click the site whose data you want to publish on the target destination.
2. In the Publish Destinations field (near the bottom of the form), click Mirror site configuration for destination (dynamic), where destination is the target destination.

   The Mirror Site Configuration form opens.

   Figure 45-17 Mirror Site Configuration Form

   
   Description of "Figure 45-17 Mirror Site Configuration Form"

   Select the data you wish to make available on the target destination:

   • Asset Types: Select the asset types to make available on the target destination.

     If your asset types have subtypes and categories, choose the appropriate options from the list in the Asset Types section and select the corresponding check boxes. For example, the AssocNamed table contains information about associations for asset types. The table is mirrored only if you select Asset associations for selected asset types and then the relevant asset types.

   • Start Menu Items: Select any start menu items that you or the developers designed for your content providers to use.

   • Workflow Processes: If there are workflow processes for your asset types, select these processes and the appropriate workflow items.

   • Workflow Groups: Select any workflow groups that you or the developers designed for your content providers to use.

   • Tree Tabs: Select the tree tabs to make available on the target destination.

     Note:

     If any of the following tree tabs exist on the target destination, mirroring the tree tabs will fail and potentially corrupt the tree tabs on the destination: Site Plan, Admin, Site Admin, Workflow, Bookmarks.

     It is not recommended to mirror tree tabs that exist on the target destination.

   • Saved Searches: Select any saved searches that you or the developers designed for your content providers to use.

   • Roles: Select the roles you want to exist on the target destination.

3. Click Mirror.

   Based on which asset type configuration options you selected in step 1, appropriate rows from the AssocNamed, AssocNamed_Subtypes, and Category tables are copied to the destination.

   If you selected Start Menu Items or Saved Searches, appropriate rows from the tables that implement those features are copied to the destination.

   Based on which workflow configuration options you selected in step 1, appropriate rows from the workflow tables are copied to the destination.

4. Repeat steps 1 through 3 for each site whose assets you want to publish on the target destination.

To test your published site, you must approve and publish all the assets for the site. See Approving Multiple Assets for help with approving many assets at one time.

To perform a simple test of your configuration, temporarily create a home page asset with only a few dependents.

1. On the source system, click Publishing in the button bar.
2. In the Publish Console, select your mirror destination from the list and click Select Destination.

   WebCenter Sites displays information about the assets that are ready to be published to this destination.

3. If for some reason the target destination has not yet been initialized, it must be initialized now or the publishing session will fail. To initialize the destination, click Create Site on Target in the Publish Console. This creates the basic site information about the destination system.
4. Click Publish.

   A confirmation message opens. Click Yes to proceed with the publish.

   The publishing system mirrors all the approved assets for this destination to the WebCenter Sites database on the destination system.

5. In the Publish Console Active tab you can observe that the session is running.
6. When the session completes, click the History tab to view the session summary for this session.

   Mouse over the session information to view summary information; click View Log to view the session log files. For information about configuring the logs to view destination information, see Retrieving Logs From Delivery WebCenter Sites Systems.

1. In the Admin interface, open the Property Management Tool. (For instructions on accessing the Property Management Tool, see Accessing the Property Management Tool in the Property Files Reference for Oracle WebCenter Sites.)
2. In the Category drop-down menu, select Core.
3. Click Search.
4. Write down the values of the following properties:

   • ft.cgipath

   • ft.approot

5. Open a text editor. Enter the server name, a slash (/), and then the cgipath. Precede the server name with the proper protocol—http:// or https://—as in the following example:

   Example for Oracle WebLogic Server and IBM WebSphere:

   http://bigfatsun.example.com:8080/servlet/

6. After the string, type a slash, and then add the following text:

   ContentServer?pagename=your_home_page
   

   Now the URL should look similar to the following examples:

   Example for Oracle WebLogic Server and IBM WebSphere:

   http://bigfatsun.example.com:8080/servlet/
      ContentServer?pagename=ExampleSite/Page/Home
   

7. Point your browser to the URL you assembled.
8. Scan the page for errors and test all links to ensure they work.

   Note:

   It is recommended that you conduct a complete test of the system under peak load conditions after you have mirrored the entire site for the first time, and at regular points thereafter.

1. Create scheduled publish events for the destination. For help with this step, see Troubleshooting.
2. If you are using images that are not assets in the design of your site — that is, your site designers want to store all images on the web server rather than manage them as assets — plan how you will move the image files from the web server for the management system to the web server for the delivery system. For example, you can set up a regular FTP transfer.
3. If you are using elements and SiteCatalog page entries that are not CSElement and SiteEntry assets, you must use the CatalogMover tool to mirror them to the destination system. For help with CatalogMover, see CatalogMover in Developing with Oracle WebCenter Sites.

1. In the Admin interface, open the Property Management Tool. (For instructions about accessing the Property Management Tool, see the Accessing the Property Management Tool in the Property Files Reference for Oracle WebCenter Sites.)
2. In the Name field, enter xcelerate.publishinvalidate.
3. Click Search.
4. Select the name of the property. In the Value field, set its value to false.
5. Click Save.

The output from Export Assets to XML is well-formed XML that describes an asset object in terms of its field values. Fields are described as attributes.

For each of the asset's fields, there is a name/value pair. The statement of the value includes the data type of the field. For example, the Name field holds characters. So the name/value pair for an asset's Name field would appear as follows in the output:

<attribute name="Name">
   <string value="nameOfAsset"/>
</attribute>

Flex attributes serve as the fields for flex assets. In the output XML for a flex asset, the flex attribute values are prepended with Attribute_. Here's an example of an attribute value for the price of a sample site product asset:

<attribute name="Attribute_price">
   <decimal value="5.9"/>
</attribute>

Note that the XML output uses the column names rather than the field name of each field/attribute and that column names and field names can be different.

The following is a description of the XML file created by this publishing method, presented as a pseudo-dtd file:

<!-- ASSET:
-- ASSET defines an asset object
-- an asset is made up of attributes
-->
<!ELEMENT ASSET (ATTRIBUTE)*>
<!ATTLIST ASSET TYPE CDATA #REQUIRED>
<!ATTLIST ASSET ID CDATA #IMPLIED>
<!ATTLIST ASSET SUBTYPE CDATA #IMPLIED>

<!ELEMENT ATTRIBUTE (STRING | DATE | INTEGER | DECIMAL | BINARY | FILE | ASSETREFERENCE | ARRAY | STRUCT | LIST)>
<!ATTLIST ATTRIBUTE NAME CDATA #REQUIRED>

<!ELEMENT STRING>
<!ATTLIST STRING VALUE CDATA #REQUIRED>

<!ELEMENT DATE>
<!ATTLIST DATE VALUE CDATA #REQUIRED>

<!ELEMENT INTEGER>
<!ATTLIST INTEGER VALUE CDATA #REQUIRED>

<!ELEMENT DECIMAL>
<!ATTLIST DECIMAL VALUE CDATA #REQUIRED>

<!ELEMENT BINARY>
<!ATTLIST BINARY VALUE CDATA #REQUIRED>

<!ELEMENT FILE (CDATA) >
<!ATTLIST FILE NAME CDATA #REQUIRED>

<!ELEMENT FILE>
<!ATTLIST FILE NAME CDATA #REQUIRED>

<!ELEMENT ASSETREFERENCE>
<!ATTLIST ASSETREFERENCE TYPE CDATA #REQUIRED>
<!ATTLIST ASSETREFERENCE VALUE CDATA #REQUIRED>

<!ELEMENT ARRAY (STRING | DATE | INTEGER | DECIMAL | BINARY | FILE | ASSETREFERENCE | ARRAY | STRUCT | LIST)+>

<!ELEMENT STRUCT (FIELD)+>

<!ELEMENT FIELD (STRING | DATE | INTEGER | DECIMAL | BINARY | FILE | ASSETREFERENCE | ARRAY | STRUCT | LIST)+>
<!ATTLIST FIELD NAME CDATA #REQUIRED>

<!ELEMENT LIST (ROW)+>

<!ELEMENT ROW (COLUMN)+>

<!ELEMENT COLUMN ( STRING | INTEGER | DECIMAL | DATE | ASSETREFERNCE)>
<!ATTLIST COLUMN NAME CDATA #REQUIRED>

Exported XML files are named according to the following convention:

assetID.xml

For example, if the asset ID is 3344556677, the file name for the asset's XML file is:

3344556677.xml

The Export Assets to XML publishing method does not use any information that is entered in an asset's Path or Filename field.

Creating a batch user account is required before any type of publishing can take place. This procedure must be performed only one time, regardless of the number and types of publishing destinations you are creating.

If you have not done so, create the batch user account. For instructions, see Creating the Batch User Account (If One Does Not Exist).

If a batch user account exists for your installation, skip to Specifying the Root Export Directory.

1. In the Admin interface, open the Property Management Tool. (For instructions, see Accessing the Property Management Tool in the Property Files Reference for Oracle WebCenter Sites.)
2. In the Name field, enter cs.pgexportfolder.
3. Click Search.
4. Select the name of the property. In the Value field, set its value to the full path of the directory to which files should be exported. This is a global setting for the system.
5. Click Save.
6. Restart the application server.

   Note:

   Before you run an Export to XML publishing session, ensure this destination directory exists and that it has enough space for the XML files that will be created there.

1. In the General Admin tree, expand the Admin node, expand the Publishingnode, and then expand the Destinations node.
2. Double-click Add New.

   The Add New Destination form opens.

   Fill in the fields as described:

   • Name: Enter a unique name for the destination.

     Note:

     The following characters are not allowed in the Name field: single quote ('), double quote ("), semicolon (;), colon (:), less-than sign (<), greater-than sign (>), percent (%), and question mark (?). Additionally, the name cannot end with a backslash (\).

   • Delivery Type: Select Export Assets to XML: Export XML file for each asset.

   • Sites: Select the sites whose assets can be approved for and published to this destination.

   • Roles (Approve for Publish): Select the roles to which you are assigning asset approval privileges. All users who are assigned these roles can approve assets.

   • Roles (Publish): Select the roles to which you are assigning publish privileges. All users assigned these roles can publish.

3. Repeat step 1 for each additional export destination that you must configure for your source system.

To perform a simple test of your configuration, select an asset and approve it and any of its dependent assets.

To complete a test publish of your entire site, approve all the assets for the site. See Approving Multiple Assets for help with approving many assets at one time.

1. On the source WebCenter Sites system, click Publishing in the button bar.
2. In the Publish Console, select your destination from the drop-down list and then click Select Destination.

   WebCenter Sites displays information about the assets that are ready to be published to this destination.

3. Click Publish.

   A confirmation message opens. Click Yes to proceed with the publish.

   WebCenter Sites exports all assets approved for this destination to files. The files are stored in the directory you specified earlier.

4. In the Publish Console Active tab you can observe that the session is running.
5. When the session completes, click the History tab to view the session summary for this session.

   Mouse over the session information to view summary information; click Log to view the session log files.

6. The log file displays a list of all the resulting XML files; verify that the files are correct.

1. Create scheduled publish events for the destination. For help with this step, see Troubleshooting.
2. Plan how you will move the generated files to your external, non-WebCenter Sites systems. For example, you can set up a regular FTP transfer that automatically moves files to a testing area after a publishing session completes.

1. Log in to the Admin interface on the management (destination) system as the fwadmin user.
2. If you have any custom support tables—a lookup table for a field in an asset type, for example—create those tables on the management (destination) system.
3. On the management system, create all the users.
4. On the source system, log in to the WebCenter Sites interface.
5. Create a Publishing Destination for the destination system that uses the RealTime publishing method.

   For help with this step and the following two steps, see Configuring Your System for RealTime Publishing.

6. Initialize the publishing destination.
7. Configure the publishing destination.
8. On the destination (management) system, configure the users for the site. For help with this step, see Granting Users Access to a Site (Assigning Roles to Users).
9. If you created a flex family, log back in to the source system. Approve and then publish all of the data structure flex assets to the management (destination) system.

   You can either approve each asset individually or use the Approve Multiple Assets feature on the Admin tab. For information about this feature, see Approving Multiple Assets.

10. Approve and then publish all of the rest of the appropriate assets for the destination system: template, page, collection, query, CSElement, and SiteEntry assets, and so on.
11. If there are any elements or page entries in the SiteCatalog table that are not CSElement or SiteEntry assets, use CatalogMover to mirror those items to the management system. For help with CatalogMover, see CatalogMover in Developing with Oracle WebCenter Sites.

1. Log in to the Admin interface on the delivery (destination) system as the fwadmin user.
2. If you have any custom support tables—a lookup table for a field in an asset type, for example—create those tables on the delivery (destination) system.
3. On the source system, log in to the WebCenter Sites interface.
4. Create a Publishing Destination for the destination system that uses the Mirror to Server publishing method.

   For help with this step, see Creating a Mirror Destination.

5. Initialize the mirror destination.

   For help with this step, see Initializing the Destination.

6. Configure the mirror destination.

   For help with this step, see Configuring the Mirror Destination.

   Do not select start menu items, saved searches, or any of the workflow options.

7. If you created a flex family, log back in to the source system. Approve and then publish all of the data structure flex assets to the management (destination) system.

   You can either approve each asset individually or use the Approve Multiple Assets feature in the General Admin tree. For information about this feature, see Approving Multiple Assets.

8. Approve and then publish all of the rest of the appropriate assets to the destination (delivery) system: template, page, collection, query, CSElement, and SiteEntry assets, and so on.
9. If there are any elements or page entries in the SiteCatalog table that are not CSElement or SiteEntry assets, use CatalogMover to mirror those items to the management system. For help with CatalogMover, see CatalogMover in Developing with Oracle WebCenter Sites.
10. If there are any images in the online site that are not assets, be sure to copy them to the delivery system.