EMC Documentum Site Caching Services

Transcription

1 EMC Documentum Site Caching Services Version 6.5 User Guide P/N A01 EMC Corporation Corporate Headquarters: Hopkinton, MA

2 Copyright EMC Corporation. All rights reserved. Published July 2008 EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. All other trademarks used herein are the property of their respective owners.

3 Table of Contents Preface... 9 Chapter 1 Introducing Site Caching Services Site Caching Services overview What Site Caching Services does Creating the publishing folders Creating documents for publication Defining publication details Publication overview Publication process Types of publishable objects Publishing multifile renditions Publishing multimedia renditions Types of publishing operations Performing additional actions at publication Publishing attributes to a database Chapter 2 Publishing Documents Introducing the site publishing configuration Identifying documents to be published Selecting documents by version Selecting documents by format Excluding content files by format Publishing HTML documents Selecting documents by date Excluding content files in particular folders from publishing operations Publishing attributes Publishing to an RDBMS database Publishing to an XML Store (Standalone) database Global publishing under Web Publisher Using scripts to perform additional actions Scripts run before or after the website update Where to specify pre- and post-sync scripts Pre- and post-sync script execution order Passing arguments to pre- and post-sync scripts Arguments in pre_sync_script Arguments in post_sync_script Sample pre- and post-sync scripts Scripts run before or after the webroot switch Where to specify pre- and post-webroot switch scripts Pre- and post-webroot script execution order Passing arguments to pre- and post-webroot switch scripts Pre-webroot switch arguments EMC Documentum Site Caching Services Version 6.5 User Guide 3

4 Table of Contents Post-webroot switch arguments Creating a site publishing configuration Testing a configuration Using the end-to-end tester Setting the end-to-end tester timeout interval Duplicating a site publishing configuration Modifying a site publishing configuration Modifying which attributes are published Invoking publication Timing publishing operations Using online synchronization Modifying a publishing job Publishing with the HTTP_POST method Method syntax Argument descriptions Chapter 3 Customizing Site Caching Services Modifying Site Caching Services publication behavior Modifying Site Caching Services behavior in DA Backing up content files and database tables during a full refresh Determining which file format extensions to use Requiring the.txt extension for text documents Excluding particular formats from a publishing operation Replacing illegal Windows characters in file names Setting the connection timeout interval Controlling the lock object Unlocking locked configurations Publishing contentless documents Publishing the r_version_label attribute as a repeating attribute Minimizing the size of the export data set Running synchronization operations when no new data is published Using the global publishing feature Resolving links correctly under Web Publisher Page Builder Enabling notification of publish status Using the agent.ini file to modify Site Caching Services behavior Modifying the database user Modifying the XML Store (Standalone) database name Modifying the XML Store (Standalone) database location Modifying the authentication domain (Windows only) Modifying the path to the password checking program Modifying the transfer directory Modifying the XML Store (Standalone) file filter Modifying the XML Store (Standalone) library Modifying the port number where Site Caching Services listens Indicating whether Site Caching Services listens on a secure or non-secure port Modifying attributes at export time Retrying publishing when target files are locked The use_repeating_index key Supporting XML format files in XML Store (Standalone) Unlocking a locked configuration Retaining files and permissions in the target root directory during a full refresh Publishing documents automatically EMC Documentum Site Caching Services Version 6.5 User Guide

5 Table of Contents Using attributes to enhance your website Exporting relation objects Additional relation information in the Web Publisher taxonomy.xml file Modifying or deleting a relation object Constructing a URL from the database Inserting attributes into HTML tags Adding META tags to other file formats Avoiding META tag corruption Documentum branding Search engines and Site Caching Services Publishing Media Transformation Services attributes Chapter 4 Maintaining Site Caching Services Viewing Site Caching Services source status Viewing Site Caching Services error messages Modifying the Site Caching Services target after installation Deleting documents from a repository Dropping the repeating attribute table Starting and stopping Site Caching Services Starting and stopping on UNIX and Linux Determining whether the source software is running Determining whether the target program is running Starting a particular target instance on UNIX or Linux Stopping a particular target instance on UNIX or Linux Stopping all running targets on UNIX or Linux Starting and stopping on Windows Starting or stopping the SCS source on Windows Starting or stopping a particular target instance on Windows Stopping all running target instances on Windows Improving the performance of Site Caching Services Using file compression Using database views Using Site Caching Services with Site Deployment Services Database replication feature Maintaining Site Caching Services log files Publishing log storage locations Removing temporary files Cleaning up the export directory Cleaning up the transfer directory Cleaning up log files Maintaining Site Caching Services security Content file security RDBMS database table security Site Caching Services initialization file security Transfer user Modifying the transfer user s password Storing the transfer user s password Allowing the appearance of passwords in log files Forcing authentication of the transfer user on the target Requiring authentication for SCS shutdown Encryption Recovering from a publishing failure EMC Documentum Site Caching Services Version 6.5 User Guide 5

6 Table of Contents List of Figures Figure 1. SCS Administration web page EMC Documentum Site Caching Services Version 6.5 User Guide

7 Table of Contents List of Tables Table 1. Using effective labels Table 2. Locations of sync scripts Table 3. Locations of webroot switch scripts Table 4. Publishing arguments for HTTP_POST Table 5. Additional target database fields when global publishing is enabled Table 6. Settings for notifications Table 7. Attributes in propdb_s table Table 8. Schema for propdb_l table Table 9. Relation table example Table 10. Media Transformation Services attributes of dmr_content and dm_format objects Table 11. Media Transformation Services attribute values Table 12. Schema for views Table 13. Schema for testtablekeywords view Table 14. Schema for testtableauthors Table 15. View map table schema Table 16. Schema for view map table EMC Documentum Site Caching Services Version 6.5 User Guide 7

8 Table of Contents 8 EMC Documentum Site Caching Services Version 6.5 User Guide

9 Preface This manual describes how to publish documents from a Documentum repository to a website using Documentum Site Caching Services (SCS). The manual includes instructions for creating site publishing configurations, selecting documents to be published, and performing publishing jobs. The manual also describes how to maintain and customize SCS. Intended audience This manual is primarily intended for people who create site publishing configurations and maintain SCS. Revision history The following changes have been made to this document: Revision history Date July 2008 Description Initial publication. EMC Documentum Site Caching Services Version 6.5 User Guide 9

10 Preface 10 EMC Documentum Site Caching Services Version 6.5 User Guide

11 Introducing Site Caching Services Chapter 1 Documentum Site Caching Services allows you to publish documents directly from a repository to a website. You can publish an entire website and update it as documents are revised in the repository. You can specify particular document versions and formats to publish. You can specify when to publish a document and when to remove it from the website. Publication can occur on demand or automatically, on a schedule. This chapter provides an overview of SCS publishing and contains the following information: Site Caching Services overview, page 11 What Site Caching Services does, page 12 Publication overview, page 14 Types of publishable objects, page 15 Types of publishing operations, page 17 Performing additional actions at publication, page 18 Publishing attributes to a database, page 18 Site Caching Services overview Documentum Site Caching Services publishes documents from a Documentum repository directly to a website, allowing you to combine the versioning, workflow, document lifecycle, and other content management capabilities of Documentum with the accessibility of a website. SCS allows you to identify groups of documents to publish to the Web, which version and format to publish, and when to publish the documents. This ensures that content on your website is accurate and timely. SCS also allows you to export document attributes to a database on the Web server. You can use the exported attributes to customize the documents you publish by inserting attributes into HTML META tags and to control the content made available to users of the website. For example, a website for music lovers might classify documents by type of EMC Documentum Site Caching Services Version 6.5 User Guide 11

12 Introducing Site Caching Services music. Classical music lovers see content related to symphony orchestras, while country music fans see content related to country singers and groups. You can use SCS by itself or with custom applications you develop. Application servers such as BEA WebLogic and IBM WebSphere can access the repository of documents and attributes created by SCS (called an SCS repository) and provide application and personalization services based on this data. Refer to documentation for Documentum Content Services for BEA WebLogic and Documentum econnector for IBM WebSphere for information on how to integrate these application servers with Documentum. SCS is also a prerequisite for using Documentum Web Publisher. What Site Caching Services does SCS publishes documents directly from a repository to a website. Documents are developed using Documentum client products, such as Web Publisher, and controlled and maintained using Content Server and a repository. When it is appropriate to transfer documents to the website, use SCS for publishing. You do not need to transfer documents manually or manage them outside of a repository. SCS is installed on two hosts. The SCS source software is installed on the Content Server host. The SCS target software is installed on the Web server host, or target host. You can publish documents from an existing repository. The repository can include whatever cabinets and folders your business processes require. There are no special repository configuration requirements other than installing SCS. You do not need to define additional objects to support SCS. SCS can publish any document whose object type is a subtype of dm_sysobject, including custom objects and objects with no associated content file. In addition to publishing documents, SCS can publish the attribute values of the published documents from the repository to a database instance that is available from the website host. Applications you create can then use these values to customize content for individual visitors to the site. SCS optionally publishes all relation objects (dm_relation objects) that are associated with the documents published. Relation objects describe an instance of a particular type of relationship between repository objects. Relationships are commonly used to categorize documents or otherwise associate documents with other documents. On the target site, relation objects are published to their own database table, which your Web applications can then query. SCS optionally publishes attributes of the dmr_content object and dm_format object. The dmr_content object and dm_format object contain attributes that describe different renditions of multimedia documents. If you publish multimedia documents, publishing 12 EMC Documentum Site Caching Services Version 6.5 User Guide

13 Introducing Site Caching Services the dmr_content and dm_format attributes provides more flexibility in querying and displaying documents on your website. For more information, refer to Publishing Media Transformation Services attributes, page 66. Before publishing documents, plan your website. You must decide what kinds of documents the website requires, whether to use an application server or create custom applications, whether to use document attributes to personalize the content served to individual users, and how to structure the website. After the website is planned, create the publishing folders in the repository and the documents to publish. You then define the publishing details and publish the documents. Creating the publishing folders SCS publishes only documents that are stored in or linked to repository cabinets or folders called publishing folders. (Documentum Web Publisher refers to publishing folders as delivery cabinets.) Each publishing folder can include as many subfolders as necessary. On Windows, the length of the repository path to an object to be published, plus the length of the object name, plus the length of the export directory on the Content Server host is limited to 255 characters. On UNIX and Linux, there is no length limitation unless the target is on a Windows host. In such cases, the 255 character length applies. When you publish, the hierarchy of a publishing folder is duplicated exactly on the Web server host. The publishing folder hierarchy in the repository must match the structure planned for the website. Creating documents for publication Content providers can create a document for publication using any appropriate tool. The content can be in any format. SCS can also publish documents with which there are no associated content files. Documents can be checked in to the repository using any Documentum client or application. They must be checked in or linked to a publishing folder in order to be published. De ning publication details The details of publication are stored in site publishing configurations. You can create multiple site publishing configurations to cover multiple publication scenarios. EMC Documentum Site Caching Services Version 6.5 User Guide 13

14 Introducing Site Caching Services A site publishing configuration contains the information SCS needs for a single publishing operation. The publishing operation can be performed manually or a job can be created to publish automatically at scheduled intervals. For example, some website content, such as press releases, might be updated daily. Other content, such as event calendars, might be updated monthly. The publishing operation can be performed multiple times. The site publishing configuration is primarily stored in three objects in the repository: dm_webc_config, dm_webc_target, and scs_admin_config. The agent.ini initialization file also contains information used by SCS during a publishing operation. A site publishing configuration includes information such as which document formats and versions to publish and whether to export document attributes. Site publishing configurations are created using Documentum Administrator or using IAPI. For information on creating site publishing configurations, refer to Introducing the site publishing configuration, page 19 and Creating a site publishing configuration, page 34. Publication overview Publication from a repository to a website is a three-step process that takes place after the website s content files are created and checked in to the repository: 1. A site publishing configuration is created. 2. Documents to be published are linked to the publishing folder. 3. The documents are published. Publication process The publication process begins with the creation of a site publishing configuration. The publishing folder is identified in the site publishing configuration. An export directory on the Content Server host s file system is also identified in the site publishing configuration. When the publishing operation is initiated, documents to be published are exported from the repository to the designated export directory. If document attributes are also exported, the attribute values and field names are placed in an XML file (the properties.xml file) in the export directory. The document content files and properties.xml file are together called the export data set. After documents and attributes are exported from the repository, SCS connects to the Web server host as the transfer user. The transfer user is specified in the site publishing 14 EMC Documentum Site Caching Services Version 6.5 User Guide

15 Introducing Site Caching Services configuration and can be any user whom SCS is able to authenticate as valid. You do not need to create a special transfer user. SCS can transfer data using the HTTP protocol, which does not encrypt data, or the HTTPS protocol, which encrypts data and is more secure. If a publishing operation is initiated, but the export data set contains no content files or metadata (nothing has changed in the publishing folder), SCS does not transfer the export data set, perform synchronization or database updates on the target, or run pre- and post-synchronization scripts. This behavior can be overridden with the sync_on_zero_updates argument, which can be added to the site publishing configuration in Documentum Administrator. For more information, refer to Running synchronization operations when no new data is published, page 50. When the connection to the Web server host is established, SCS transfers the export data set to a directory on the Web server host called the data transfer directory. This directory is specified when SCS is installed on the target host. Transferring the export data set to a website creates a target repository on the target machine. The SCS repository consists of the content files and any attributes transferred to the target host. From the data transfer directory, the export data set is moved to the target root directory, or webroot. The target root directory is the root directory of the website. It corresponds to the repository publishing folder. If the publishing folder has subfolders, SCS creates subdirectories under the target root directory that correspond to the subfolders. In other words, the website directory structure corresponds to the structure of the publishing folder structure in the repository. The target root directory must be in the hierarchy of the Web server s document root. When the export data set is moved to the target root directory (webroot), the previous contents of the target root directory are deleted on initial publication and any time the entire SCS repository is republished. The XML file is used to update the attributes in the database tables for the data set on the Web server. If you are publishing to a live website, use an online synchronization directory to minimize the risk of the website appearing inconsistent to users. For more information on online synchronization directories, refer to Using online synchronization, page 38. You can schedule publishing operations to meet the business needs of the website. Types of publishable objects The following objects can be published by SCS: Any object that is a subtype of dm_sysobject. EMC Documentum Site Caching Services Version 6.5 User Guide 15

16 Introducing Site Caching Services Documents and other objects containing multi-byte characters. All file transfers during publishing are binary. Documents without associated content files. Only the attributes of such documents are published. If you publish documents without associated content files, you can also publish the attributes of a folder. The attributes are used at the website for content personalization or searching. Publishing multi le renditions Document Transformation Services can create multifile renditions of some document formats. Multifile renditions are identified in the repository by formats prefixed with zip_ and are stored as ZIP files. During publishing, SCS extracts zip_ formatted multifile renditions from the ZIP archive. It tracks each file to assure proper updating if the repository object is replaced or removed. Use ZIP programs such as pk zip or WinZip to read zip_ format renditions. Publishing multimedia renditions When Media Transformation Services is installed, a repository is rich media enabled and can be used to store and manipulate image, video, audio, and other media files. When a file in a rich media format is checked in to the repository, Media Transformation Services creates specialized renditions of the file in the repository, depending on which media plug-ins are installed. For most image formats, low-resolution and thumbnail renditions are created. For video, PowerPoint, and PDF formats, low-resolution, thumbnail, and storyboard renditions are created. The low-resolution and thumbnail renditions are assigned the same name as the primary rendition and are distinguished from the primary rendition by their attribute values. When SCS publishes the primary, low-resolution, and thumbnail renditions, it assigns a special publishing name to the low-resolution and thumbnail renditions, so that the different renditions do not overwrite each other on the SCS target host: Publishing names for low-resolution renditions take the format filename_lres.extension, where filename is the name of the primary rendition and extension is the extension defined in the format object for the format. Publishing names for thumbnail renditions take the format filename_th.extension, where filename is the name of the primary rendition and extension is the extension defined in the format object for the format. 16 EMC Documentum Site Caching Services Version 6.5 User Guide

17 Introducing Site Caching Services For example, if a JPEG file called switchback.jpg is published, the low-resolution rendition is called switchback_lres.jpg and the thumbnail rendition is called switchback_th.jpg on the SCS target host. Multipage renditions, such as storyboards, are not supported. For a complete list of the formats that Media Transformation Services supports, refer to the Media Transformation Services Release Notes. For more information on designating documents to be published, refer to Identifying documents to be published, page 20. Types of publishing operations Use Documentum Administrator or server API methods to publish documents. A publishing operation can be a full refresh publishing operation, an update property schema publishing operation, an incremental publishing operation, a force refresh publishing operation, or a single-object publishing operation. A full refresh publishing operation deletes all published objects and attributes, then republishes every document in the publishing configuration that meets the criteria defined in the publishing configuration. The entire contents of the target root directory (webroot) are deleted during a full refresh. If the site publishing configuration exports attributes, the attribute information is deleted from the database tables and republished. You can optionally choose to destroy and recreate the database tables rather than having the data deleted. You can also optionally choose to back up the content files and database tables before the target is synchronized. The first time the objects designated by a particular site publishing configuration are published, SCS automatically performs a full refresh. An update property schema publishing operation updates the database schema but does not republish all content files and metadata. An incremental publishing operation publishes objects that are new or changed since the previous publishing operation. A force refresh publishing operation republishes the entire export data set and overwrites all published objects and attributes. A single-object publishing operation publishes only one designated document. If you modify the attributes to be published, you must choose between a full refresh publishing operation or an update to the database schema. For more information, refer to Modifying which attributes are published, page 36. For more information on types of publishing operations, refer to Invoking publication, page 37. EMC Documentum Site Caching Services Version 6.5 User Guide 17

18 Introducing Site Caching Services Performing additional actions at publication Use scripts to perform any arbitrary action before or after a website is updated by the publishing operation, and before or after the webroot is switched when the online synchronization option is used. For example, the site might require that ASP or JSP pages be installed in a particular directory before the website is updated, or you might want the site to refuse browser requests during update. Use a script run before the update to ensure that these actions take place as required. Another script that runs after the update could ensure that the site accepts browser requests again. Publishing attributes to a database You can publish document attributes as well as content files to your Web server host. To publish attributes, a database instance must be accessible from the Web server. If you use Media Transformation Services, you can publish attributes from the dmr_content object and dm_format object that are associated with rich media documents that you publish. These attributes can be used by browsers, phones, smartphones, and other mobile devices to render content according to their screen sizes and other resource constraints. Publish attributes if your applications query the database or if you dynamically personalize site content by creating Web pages programmatically. For example, publish attributes if your website is fully dynamic, with targeting rules based on content metadata and navigation based on user profiles. Publishing attributes adds to system overhead and requires maintaining a database without providing significant advantages in the following situations: On fully static websites containing HTML and other content with fixed navigation and no user input or searching. On partially dynamic websites containing HTML and other content mixed with some personalized navigation based on full-text queries or on attributes contained in the content files. Refer to Publishing attributes, page 24 and Using attributes to enhance your website, page 59 for more information on exporting document attributes. 18 EMC Documentum Site Caching Services Version 6.5 User Guide

19 Chapter 2 Publishing Documents This chapter contains the following information: Introducing the site publishing configuration, page 19 Identifying documents to be published, page 20 Publishing attributes, page 24 Global publishing under Web Publisher, page 27 Using scripts to perform additional actions, page 27 Creating a site publishing configuration, page 34 Invoking publication, page 37 Introducing the site publishing con guration A site publishing configuration defines the documents to be published and the target site to which the documents are published by a particular publishing operation. This information is stored primarily in three repository objects: the webc config object (dm_webc_config), the webc target config object (dm_webc_target), and the admin config object (scs_admin_config). For a full description of these objects, refer to the Documentum Content Server Object Reference Manual. The objects contain information such as: Where to find the documents to publish (the publishing folder) Which document formats and versions to publish Whether to export document attributes Which document attributes to publish What directories to use during the publication process The website host Whether to use a secure or non-secure connection to connect to the website host Whether to run any scripts before or after publication, and which scripts to run EMC Documentum Site Caching Services Version 6.5 User Guide 19

20 Publishing Documents What account to use to publish the documents Use Documentum Administration or server API methods to create site publishing configurations. If you create site publishing configurations using the server API, ensure the transfer_user_password (an attribute of dm_webc_target object) is set correctly. You must have Superuser privileges in the source repository to create site publishing configurations. A fourth object, the webc lock object, locks Web publishing configurations during publishing operations. The agent.ini initialization file also contains information used by SCS during a publishing operation. The agent.ini file is stored on the SCS target host, and contains database connection information used by SCS during a publish operation. For more information on the initialization file, refer to Appendix A, Site Caching Services Attributes and Keys, in the Site Caching Services Installation Guide. There are no restrictions on how many site publishing configurations you can create in a particular source repository or on how many websites to which you can publish. If you publish to multiple targets from a single source repository, review Controlling the lock object, page 48 for related information. SCS is certified for high availability environments under Microsoft Cluster Services. SCS is not supported in repository federations, distributed configurations, or when replication is used. Identifying documents to be published All documents to be published must be linked in the repository to the publishing folder or to a subfolder of the publishing folder. You can link documents to the publishing folder before or after you create the publishing configuration. Use any Documentum client product to link the documents, or create the links with DQL. If you link a document to multiple folders under the publishing folder, the document is published multiple times. To publish all components of a virtual document, you must link each individual component to the publishing folder or one of its subfolders. When the virtual document is published, it is not reassembled on the target host and the structure is not retained. Annotations, assemblies, and other objects associated with a document to be published are published only if you link them to the publishing folder. If a publishing folder contains multiple documents with the same name, only one of the documents is published. 20 EMC Documentum Site Caching Services Version 6.5 User Guide

21 Publishing Documents A published document s name on the file system is its object name in the repository, with some exceptions related to extensions. For more information on this, refer to Determining which file format extensions to use, page 45. You must determine which document version and which document formats to publish and specify these in the site publishing configuration. To exclude folders containing documents that would otherwise be published, see Excluding content files in particular folders from publishing operations, page 24. Selecting documents by version When you create a site publishing configuration, you can specify which document version to publish. If you do not specify a version, the CURRENT version is published by default. The document version you request for publication must be linked to the publishing folder or to a subfolder of the publishing folder. For example, if you link the CURRENT version only and you then specify in the publication parameters that version 1.6 is to be published, the document is published only if the CURRENT version happens to be version 1.6. If the version you specify in the publication parameters is not linked to the publishing folder, no version of the document is published. You can publish only one document version from a particular version tree. Specify the correct version to publish when you create the site publishing configuration, and ensure that you link the correct version to the publishing folder. For example, if you specify the CURRENT version for publication and you previously published version 1.4 when it was CURRENT, then version 1.4 is overwritten when you publish version 1.5, CURRENT. Version labels are case-sensitive. When you specify a document version to publish, the case in the site publishing configuration must match the case of the version in the repository. For example, if the version is DRAFT, nothing is published if you specify draft or Draft in the site publishing configuration. If you want to publish documents that do not all have the same version label, specify ANY VERSION when you create a site publishing configuration. Use ANY VERSION only when your application or business process links one and only one version of a particular document to the publishing folder. If you link multiple versions of the same object to a publishing folder and you specify ANY VERSION as the version to publish, different versions may be published at different times. If different versions are published, they overwrite each other at the target website. For example, if five versions of a document are linked to the same folder, all five versions are exported from the repository and SCS attempts to publish them all. Four versions are overwritten and it is not possible to predict which of the five appears at EMC Documentum Site Caching Services Version 6.5 User Guide 21

22 Publishing Documents the target. Therefore, if you specify ANY VERSION, link only the version you want to publish to the publishing folder. Do not use ANY VERSION when multiple versions of a document are linked to the same publishing folder. In such cases, ensure that you identify the correct version label to use (WIP or CURRENT, for example). Selecting documents by format When a document exists in multiple formats, only the formats you specify are published. Specify the correct formats to publish when you set up the site publishing configuration. If a document has renditions in multiple formats and the formats have the same file extension, the last format published overwrites any previously published formats with the same extension when you try to publish more than one format. A rendition is a document differing from the original in format only; for example, DOS, Macintosh, UNIX, and Linux text files all use the extension.txt. If you try to publish three such renditions of the same document, the second rendition published overwrites the first, and the third rendition published overwrites the second. Caution: If you have multiple documents linked to the same publishing folder which have the same base name and repository format but different extensions, the files may overwrite each other when they are exported and published. For example, you might have three Microsoft Word files with these object names linked to a publishing folder: eenymeeny.doc eenymeeny.ftp eenymeeny.telnet When SCS publishes these documents, the extensions (.doc,.ftp, and.telnet) are stripped off and replaced with.doc, the specified extension for the repository format Microsoft Word. Which of the three files is published is indeterministic. HTML-type documents, with extensions htm, html, jhtml, shtml, and phtml, are not affected. In other words, if you have files eenymeeny.jhtml and eenymeeny.shtml, they are published with those extensions rather than both being published as eenymeeny.htm. The extensions jpeg and mpeg are also not affected. 22 EMC Documentum Site Caching Services Version 6.5 User Guide

23 Publishing Documents Excluding content les by format You can exclude content files present in a publishing folder by designating particular file formats to be excluded. For complete information, refer to Excluding particular formats from a publishing operation, page 47. Publishing HTML documents SCS and Web Publisher support a special HTML publishing option, the pub_html format. Multiple HTML renditions of a document can exist in the repository if the HTML format and the pub_html format are used. When SCS finds a document with both an HTML rendition and a pub_html rendition, and both renditions meet the specifications for publishing, it publishes the pub_html rendition. Selecting documents by date You can use effective labels to enable SCS to determine which documents to publish based on effective and expiration dates. The effective label specified in a site publishing configuration allows SCS to determine when to publish a particular document and when to delete it from the website. SCS does this by examining the repeating attributes a_effective_label, a_effective_date, and a_expiration_date, which are attributes of the dm_sysobject type. These attributes are inherited by all subtypes of dm_sysobject. Each a_effective_label corresponds to a matching a_effective_date and a_expiration_date. Because these are repeating attributes, you can specify multiple effective labels, effective dates, and expiration dates for each document. SCS looks for the effective and expiration dates matching a particular effective label, and uses the dates to determine when to publish a document and when to withdraw the document from the website. For example, a document might have the effective label, effective date, and expiration date attributes set as follows: Table 1. Using effective labels a_effective_label a_effective_date a_expiration_date DRAFT 03/05/08 03/15/08 REVIEW 03/16/08 03/26/08 EMC Documentum Site Caching Services Version 6.5 User Guide 23

24 Publishing Documents a_effective_label a_effective_date a_expiration_date COMMENT 03/27/08 04/10/08 APPROVED 04/10/08 04/10/09 Setting the document s effective label to REVIEW means that the document will be published on March 16, 2008 and removed from the website on March 26, Setting the effective label to APPROVED means that the document will be published on April 10, 2008 and withdrawn on April 10, Documents whose effective label does not match the effective label set in the site publishing configuration are published regardless of the values set for effective date and expiration date. Excluding content les in particular folders from publishing operations The exclude_folders argument allows you to exclude the content files in particular folders from publishing operations. The syntax for the parameter is exclude_folders=list_of_folder_paths where list_of_folder_paths is a semicolon-separated list of absolute repository paths from the publishing folder. For example, a publishing folder might be called /acme.com, with subfolders /images, /subdir, /jsp, and /html. To exclude the /images and /subdir folders, enter the following on the Extra Arguments tab in DA: exclude_folders=/acme.com/images;/acme.com/subdir Publishing attributes When a site publishing configuration directs SCS to publish document attributes, the attributes become part of the export data set. The attributes are transferred from the Content Server host to the target host in the properties.xml file, and then imported into the database instance used by the SCS target software. The available configuration modes depend on the type of database being used. This section describes the publishing functionality for RDBMS and XML Store (Standalone) databases. 24 EMC Documentum Site Caching Services Version 6.5 User Guide

25 Publishing Documents Refer to Using attributes to enhance your website, page 59 for additional information on exporting document attributes. Consult the Site Caching Services Installation Guide for information about database requirements and installation. Publishing to an RDBMS database If SCS is publishing to a relational database (RDBMS), content files are published to the file system on the target, while the properties.xml file containing the associated metadata is imported to the target s database. When attributes are published, the object id, chronicle id, object name, format, and version label of the source document s content file are exported by default. The r_object_id of each exported document is used to populate the content_id column of the target database. Additionally, an attribute is created in the database called a_webc_url, which is a partial URL to the document s location on the website. In addition to the default metadata, you can specify other attributes for a site publishing configuration using Documentum Administrator. You can optionally publish attributes of the dmr_content object associated with a document s content file and the dm_format object describing the content file s format. Three tables are created in the database, with the following default names: propdb_id_s The propdb_id_s table contains any single-valued attributes that you export. propdb_id_r The propdb_id_r table contains any repeating-valued attributes that you export. propdb_id_l The propdb_id_l table contains the relations of documents that are published. If you are using Site Caching Services with Site Deployment Services, a fourth table is created. The propdb_id_m table records state information on publishing events for use by Site Deployment Services. In each of these cases, propdb is the name assigned to the database tables and id is the last eight characters of the webc target config object s object ID. When the r_content_size attribute is published, the value published depends on whether you are publishing the primary content or a rendition of the document: If the primary content is published, the value of r_content_size in dm_sysobject itself is published. If a nonprimary rendition is published, the value of the actual file size on the file system is published. EMC Documentum Site Caching Services Version 6.5 User Guide 25

26 Publishing Documents Publishing to an XML Store (Standalone) database Site Caching Services offers the option of publishing to an XML Store (Standalone) database rather than an RBDMS. An XML Store (Standalone) database offers certain advantages over other databases; for example, the metadata in XML Store (Standalone) can be indexed, and xquery searching is available. Also, more publishing modes are possible when an XML Store (Standalone) is the target. When using XML Store (Standalone) as the target, these publishing modes are available: Publish both content files and metadata to the database. Publish content files to the file system, and metadata to the database. Publish filtered content files and metadata to the database. Unfiltered content is published to the file system. Publish only content files to the database. You are prompted to input these parameters when you install SCS on the target host. These parameters are then stored as keys in the agent.ini file. You can change them by modifying the agent.ini file after installation; ensure that you shut down and restart the SCS target so that any changes are captured. Consult Appendix A in the Site Caching Services Installation Guide for more details about XML Store (Standalone) parameters in the agent.ini file. XML Store (Standalone) stores the content files and metadata in specific catalogs within the xhive_content_subscription_library: Content files are copied to the xhive_content_subscription_library/collection catalog. The metadata associated with the content files is copied to the xhive_content_ subscription_library/collectionmetadata catalog. The metadata resides in XML files that share the same name as the content files to which they relate. By default, SCS publishes all metadata on each publish. However, if you set source_attrs_only to TRUE in the site publishing configuration, only the default metadata and any user-defined attributes are captured. Default metadata includes: r_object_id object_name i_chronicle_id r_version_label content_id i_full_format r_folder_path You can specify other attributes for a site publishing configuration using Documentum Administrator. 26 EMC Documentum Site Caching Services Version 6.5 User Guide

27 Publishing Documents Global publishing under Web Publisher SCS can sort published documents at the website based on the locale of the document. When Web Publisher s globalization feature is enabled and a document is checked in to a repository using Web Publisher, the user designates a locale (or language code) for the document. (If globalization is not enabled, documents can be created without a user-designated locale.) At publishing time, if these arguments are set in the site publishing configuration, SCS publishes documents of designated locales and sorts the documents at the target by locale. Use this feature in portal environments where applications refer to user preferences to determine the language of the content that is displayed, and when publishing content in multiple languages would otherwise require maintaining a very large number of publishing configurations. For more information on enabling the global publishing feature, refer to Using the global publishing feature, page 50. Using scripts to perform additional actions You can use scripts to perform any arbitrary action before or after a website is updated by the publishing operation, and before or after the webroot is switched when the online synchronization option is enabled. For more information about how to use online synchronization, see Using online synchronization, page 38. Scripts run before or after the website update The scripts used before or after the website is updated are the pre_sync_script and the post_sync_script. The pre_sync_script is executed before SCS updates the site, and the post_sync_script is executed after SCS updates the site. For example, if your website includes ASP or JSP pages that must be installed in a specific directory on the Web server in order to be processed, the post_sync_script could be used to move any updated JSP or ASP pages to the proper location. Similarly, if your site uses components such as COM controls or Java classes that need to be registered, the post_sync_script can be used to register them. You can also use these scripts to allow the Web server to refuse requests from browsers while the update is in progress, and to accept requests again once the update is complete. You can implement a pre_sync_script without a post_sync_script, or a post_sync_script without a pre_sync_script. EMC Documentum Site Caching Services Version 6.5 User Guide 27

28 Publishing Documents When a script executes successfully, it returns a 0 (zero) value to SCS. This allows SCS to complete the publishing event. If a script returns a nonzero value to SCS, the publishing event fails. If online synchronization is enabled, the pre_sync_script runs before online synchronization takes place and the post_sync_script runs after online synchronization takes place. SCS single-item publishes run simultaneously unless you set the force_serialized argument. If you use a post_sync_script to invoke a particular process or application, your application is invoked multiple times by the single-item publishes. The application must be able to handle multiple simultaneous calls. Where to specify pre- and post-sync scripts You can invoke these scripts in a site publishing configuration (in the webc target config object), in the agent.ini file, or in both. Table 2, page 28 provides details regarding these two approaches. Table 2. Locations of sync scripts Details Script location on target host Restrictions Execution Scripts specified in site publishing configuration In scs_install/product/bin directory. The name of the script plus any arguments you pass must not exceed 48 characters in length. Script names and any arguments you pass cannot contain spaces. Script is executed only for that publishing configuration s publishing operations. Scripts specified in agent.ini In or under scs_install/ product/bin directory. Provide full path to the script in agent.ini.* There is no limit to the length of the arguments you pass. Script names, the path to the script, and any arguments you pass cannot contain spaces. Script is executed for every publishing operation (in other words, for all publishing configurations). * Before a script is run, SCS checks whether the script path specified is absolute or relative. If the path is absolute, no changes are made. If the path is relative, /bin is added to the path. 28 EMC Documentum Site Caching Services Version 6.5 User Guide