OpenText Web Experience Management

Transcription

1 OpenText Web Experience Management Administration Guide This document outlines the procedures required to properly configure a Web Experience Management environment.

2 OpenText Web Experience Management Administration Guide Rev.: 2014-Nov-24 This documentation has been created for software version It is also valid for subsequent software versions as long as no new document version is shipped with the product or is published at Open Text SA 40 Avenue Monterey, Luxembourg, Luxembourg L-2163 Tel: Open Text Corporation 275 Frank Tompa Drive, Waterloo, Ontario, Canada, N2L 0A1 Tel: Toll Free Canada/USA: International: Fax: Support: For more information, visit Copyright 2014 Open Text SA and/or Open Text ULC. All Rights Reserved. Open Text is a trademark or registered trademark of Open Text SA and/or Open Text ULC. The list of trademarks is not exhaustive of other trademarks, registered trademarks, product names, company names, brands and service names mentioned herein are property of Open Text SA or other respective owners. Disclaimer No Warranties and Limitation of Liability Every effort has been made to ensure the accuracy of the features and techniques presented in this publication. However, Open Text Corporation and its affiliates accept no responsibility and offer no warranty whether expressed or implied, for the accuracy of this publication.

3 Table of Contents 1 Introduction to Administration Types of Administrators Administrative Tasks Using the Configuration Console Database Usage Data Sources Servers and Processes Required Servers and Processes Configuration Agents Verifying that a Configuration Agent is Running Starting or Stopping a Configuration Agent Deployment Agents Configuring WEM Managed Processes Administering Runtime Services Introduction to the Runtime Services Console Opening the Runtime Services Console (Browser) Opening the Runtime Services Console (Configuration Console) Accessing Technical Documentation Using the Runtime Services Console Managing Servers Manually Starting and Stopping Server-Related Processes Starting and Stopping the Administration Server Starting and Stopping the Node Manager Starting or Stopping a Content Management Server Starting or Stopping a Management-Side Cluster Automatically Restarting Servers and Processes Node Manager Administration Server Content Management Server Managed Server Viewing Server Logs Managing Resources Managing Data Sources and Their Connection Pools Viewing and Modifying Connection Pool Settings Connection Pool Testing Managing Threads Managing Heap Size and other JVM Settings Modifying the JTA Transaction Timeout Setting Administering Runtime Services Embedded LDAP Backing Up Directories and Files Used by the Administration Server.. 52 OpenText Web Experience Management Administration Guide iii

4 Table of Contents Configuration Information Security Data Automatic LDAP Backups: The ldap/backup Directory Manual LDAP Backups SerializedSystemIni.dat and Security Certificates Administering LDAP Introduction Naming Restrictions for Embedded and External Repositories Administering Embedded LDAP Changing the Embedded LDAP Credentials Viewing Embedded LDAP Server Contents from an LDAP Editor Exporting and Importing Information in the Embedded LDAP Server Managing Users and Groups Administering WEM for External LDAP Managing Users and Groups Changing Repository-Specific Information Changing the LDAP Connection Pool Timeout Enabling SSL LDAP Server Authentication Using a Certificate Authority Verifying that the Content Management Server is Communicating via SSL Adding Nodes to a Management-Side Cluster Migrating from One LDAP Server to Another Integrations with OpenText Application Infrastructure Integrating OpenText Directory Services with Web Experience Management Management-Side Clustering Introduction What Are the Benefits of Clustering? What Are the Key Capabilities of a Management-Side Cluster? Where Components Reside in a Management-Side Cluster Configuration Tools and Management-Side Clustering Connecting to the Content Management Server DNS Round-Robin Connections Host Name/IP Address and Port Number Connections Obtaining Status in the Configuration Console Load Balancing HttpClusterServlet and Load Balancing Hardware Load Balancing Load Balancing HTTP Sessions with an External Load Balancer iv OpenText Web Experience Management Administration Guide

5 Table of Contents 6.4 Failover and Replication How vgnvcmserver Detects Failures Failure Detection Using IP Sockets Replication and Failover for Content Management Server Web Applications HTTP Session State Replication Before You Set Up Management-Side Clustering Determining Your Cluster Architecture Choosing Machines for the Management-Side Cluster Identifying Names and Addresses Avoiding Listening Address Problems Making Sure that Node Names are Unique Identifying the Administration Server Address and Port Identifying Managed Server Addresses and Ports Setting the Cluster Address Shared File System Requirements for Management-Side Clusters Requirements for Windows Requirements for UNIX Changing the Behavior of the HttpClusterServlet Sample web.xml File Sample weblogic.xml File HttpClusterServlet Deployment Parameters Accessing Applications Via the HttpClusterServlet Managing Authorization Overview Capabilities Role-Based Capabilities Access Control List: Object-Based Capabilities ACL Inheritance and Propagation Roles Authorized Groups Authorized Group Inheritance and Propagation in Projects Authorized Group Inheritance and Propagation in Channels Examples of Authorized Group Usage The All Users Group Container-Based Security Unrestricted Access Restricting Access After a Project Has Been Created Extending Container-Based Security Effective Capabilities Tools and Actions OpenText Web Experience Management Administration Guide v

6 Table of Contents 7.2 Role Assignment Precedence Rules Understanding Default Roles and Capabilities Default Roles Application Administrator Authorization Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager Default Capabilities Capabilities Required to Perform Actions Configuration Console: Required Capabilities per Action Management Console and Content Workspaces: Required Capabilities per Action Command Line Utilities: Capabilities Required per Action Generated Capabilities for New Content Type Definitions Capabilities Required for Workflow Capabilities Required for Objects in a Publishing Job Creating and Editing Roles Accessing Roles, Users, and Groups Capabilities Provided with All Roles Additional Capabilities Required for User-Created Roles Managing Access to Objects Managing Authorization Efficiently Setting a Group's Role Synchronizing the Security Realm Managing Configuration Information Understanding Configuration Console Configuration Tables and Files Configuration Console Variables Configuration Terms Change Tracking Configuration Agents Using the Configuration Console Understanding Capabilities and Permissions Starting the Configuration Console Getting Help Creating, Changing, or Deleting Configuration Variables Performing Configuration Actions vi OpenText Web Experience Management Administration Guide

7 Table of Contents Changing and Testing Configuration Variables How Variables Get Values Testing Variable Changes Variable States Product Instance State Configuring Media Management Configuring Media Management using CLI commands Configuring Media Management Using the Configuration Console Removing the Media Management Configuration Removing the Media Management configuration using cfgaction Removing the Media Management configuration using the Configuration Console Creating Media Management Automations Batch Importing Assets from Media Management Understanding User Profile Integration Understanding the External Content Integration Framework and hybris Service Provider Installing the OpenText Web Experience Management Workflow Modeler Monitoring the WEM Software Introduction to Metrics Metric Types Metrics and Monitoring Viewing a Component's Metrics Viewing a Component's File Monitors Accessing Metrics with System Management Tools Using the URL Syntax Changing the Separator in Returned Character-Separated Values Using JMX Monitoring Content Management Server Configuration JMX Client Application Configuration XML Schema Definition for Monitoring (Tree View) XML Schema Definition for Monitoring (Data View) File Source Scans Introduction Scan Types Active Scans Passive Scans File Source Scan Parameters Calculating Values for the Parameters Limitations and Behavior OpenText Web Experience Management Administration Guide vii

8 Table of Contents 12 Content Scans Introduction Syntax Arguments Description XML Input File Parameters <scan-target>: Scan Target Parameters and Subparameters <content-type>: Content Types to Scan <project-path>: Where to Place Scanned Items <content-update-checker-class>: Checking Existing Content Instances <action>: Actions to Perform <approval>: Automatically Approving Content Instances <publish>: Publishing Created or Updated Content Instances <site>: Specifying the Site for Publishing <channel>: Specifying the Channel for Publishing <user>: Content Management Server User Name and Password <appsvcscfgdir>: App Services Configuration File Directory <chunksize>: Number of Rows to Process <sleepinterval>: Time between Chunk Processing <threadpoolsize>: How Many Threads? <log>: Logging Information Schema and Example XML Input File IcontentUpdateChecker Interface Logging Command-Line Utilities Introduction cfgaction Syntax Options Exit Values Description Example: System Extension Components Property Files Example: cfgaction Script Issues cfgedit Syntax Options Exit Values Description Understanding the Configuration Path Hierarchy viii OpenText Web Experience Management Administration Guide

9 Table of Contents Node Locating and Identifying Configuration Variables Specifying a Configuration Variable Valid Operations Connected to the Content Management Server Subcommands Examples cfgsync Syntax Parameters Description configp Syntax Options Exit Values Description vgnadmin Syntax Subcommands vgncontentindex Indexing New Content Instances or Static Files Reindexing Existing Content Instances or Static Files Syntax Options Example Details Constraint Unregistering and Registering Deployment-Related Listeners Output vgnpasswordchange Launching the Password Change Tool Syntax Usage Options Server Subcommands General Subcommands Tips for Using vgnpasswordchange CLI Options restartwemservices Exporting and Importing Objects Introduction Export Overview Import Overview OpenText Web Experience Management Administration Guide ix

10 Table of Contents 14.2 Identifying Data: Writing a Package Manifest Specifying Objects in the Package Manifest Specifying an Object by WEM ID Specifying an Object by Name and Type Referenced Objects Grouping Objects Package Manifest Example Migrating WEM Compatible Data Using the Export Command Option Combinations for Specific Export Instructions Using the Import Command Option Combinations for Specific Import Instructions Before You Run vgnimport Import Issues Using an Options File Interpreting the Results Modifying an Exported Package File Package File Structural Overview Editing packagebody.xml Removing an Object Entry Editing Content Entries Migrating Non-WEM Data Adding Content Files to the Package File Package Body Schema Basic Entry Syntax Required Sequence for Object Types Creating Delete Entries Creating Import Entries Defining a New Object Adding Objects that Reference Previous Entries Adding Objects that Reference Existing Objects Adding a Content Definition Adding File Associations Adding Access Restrictions Adding User Preferences Grouping Objects Validating the Package File Logs, Other Files, and Directories Log Files Installer/Uninstaller Log Files Setup Application Log File x OpenText Web Experience Management Administration Guide

11 Table of Contents Component Runtime Log Files Job Engine Log File Content Workspaces Log File Customizing Content Workspaces Logging Upgrade Issues javaproc, stderr, and stdout Log Files Command Line Utilities Log Files Default Log File Format Configuring the Logging Mechanism Changing the Logging Mechanism for Components Changing the Log Level for Command Line Utilities Changing the Default Log File Format Customizing the WEM Logging Configuration Files Enabling Third-Party Component Logging Other Commonly-Accessed Directories and Files Working Directory Configuration Files vgncfg.properties Files Special Directories Publishing and Deployment Introduction Archiving Published Content Publishing Policies Publish Status High Precision Medium Precision Low Precision No Publish Status Manually Publishing Content on Any Site Asset Eligibility for Publishing and Unpublishing Deployment and Jobs Enlistment-Based Jobs Manual Jobs Job Engine Publishing Policy Summary Notification and Reporting Mechanisms Customization Options Changing a Site Workflow Definition Creating New Program Activities Using the Publishing API Publishing Assets OpenText Web Experience Management Administration Guide xi

12 Table of Contents Manual Publishing and Unpublishing What Happens in Manual Publishing and Unpublishing Automatic Publishing What Happens in Automatic Publishing Scheduled Publishing and Unpublishing What Happens in Scheduled Publishing and Unpublishing Processing the Job: the Job Engine How Assets are Collected for a Publish Job How Assets are Collected for an Unpublish Job Eligibility Validation Strict Policy Moderate Policy Lenient Policy The Deployment System: How Content Is Deployed Stages Content Delivery Services (CDS's) Deployment Agents Endpoint Proxies, Endpoints, and Deployment Endpoint Proxy Modes Deployment Phases Endpoint Command Phases Endpoint Proxy States for Deployment Customizing and Tuning Publishing Configuring the Global Validation Policy Changing the Validation Property for a Single Job Changing the Snapshot Overwrite Policy Configuring Autoprune Increasing Java Memory for Deployment Agents Troubleshooting Publish Problems Introduction Troubleshooting Job Creation Troubleshooting Job Creation for Manual Publishing Troubleshooting Automatic/Scheduled Publishing Job Creation Troubleshooting Deployment Dealing with a Suspended Endpoint Resuming an Endpoint Skipping an Asset and Resuming the Endpoint Stopping the Endpoint Aborting the Job Using the Deployment Agent Log File xii OpenText Web Experience Management Administration Guide

13 Table of Contents Dealing with Consistency Issues Assets Published Successfully, But Never Arrived Assets Unpublished Successfully, But Were Never Removed The Job Console Using the Manage Jobs by Site Action Seeing Job Contents and Exclusions Viewing Subjob Details for a Job Using the View Management Stage Job Info Action Using the View Content In Job Queue Action Using the Manage Endpoints Action Retrieving Endpoint Information Using the View Job Resource Info Action Using the View Diagnostic Information Action Using Current System Alarms Action Customizing Deployment and Publishing Introduction Customizing Deployment Types Creating a Custom Deployment Type Assigning the Deployment Type to Content Configuring Handlers Adding a Resource Deployment Scripting Scripting Languages Master Scripts for Custom Handling Default Locations for Master Scripts Contents of a Custom Script Variables and Functions Available to Scripts Error Handling Language-Specific Scripting Information Windows Scripting Host Environment: VBScript and JScript Bourne Shell Scripting Environment Example Custom Scripts Custom VBScript Custom JScript Custom Bourne Shell Script Custom Bourne Shell Script Custom Perl Script Deploying and Configuring a Custom Script Configuring Alarms and Notifications Alarms Notifications OpenText Web Experience Management Administration Guide xiii

14 Table of Contents 18.7 Configuring Publishing to Autoprune Jobs Configuring Notifications Introduction Alarm Notification Enabling or Disabling Alarm Notification Changing Alarm Renderers Enlistment-Based Notification Workflow Notifications Enabling or Disabling Workflow Notification Changing Workflow Notification Renderers Creating Notification Renderers Managing Preferences for Content Workspaces Introduction Types of Preferences Precedence Required Authorization Capabilities Preference Specification Model Setting and Transferring Preferences Content Workspaces Preferences System-wide Preferences Content Workspaces Theme Number of Items in Lists Locale for Content Workspaces Time Zone for Content Workspaces System Objects Language and Translation Columns Exporting Preferences Identifying Preferences for Export Exporting Preferences Using vgnexport Exporting Preferences by Command-line Flags Exporting a single preference node Examples for exporting a single preference node Managing Productivity Features for Content Workspaces About Sharing Quick Actions, Shortcuts and Saved Searches Implementing Image and Video Transformations Miscellaneous Tasks Updating License Information Changing the Management Console Inactivity Timeout Enabling SSL Communication for Deployment Agents xiv OpenText Web Experience Management Administration Guide

15 Table of Contents 22.4 Changing SSL Certificates Purging Completed and Terminated Workflow Processes Reconfiguring the FileSource Web Application Access Control (filesource-config.xml) Configuration Schema (filesource-config.xsd) Packaging and Deployment Restarting the FileSource Web Application Messaging and Diagnostics When a Database Goes Down: Restarting Servers Which WEM Servers to Restart Database Tables OpenText Web Experience Management Administration Guide xv

16

17 Chapter 1 Introduction to Administration This chapter describes some typical system tasks. Before you begin this chapter, you may want to refer to the OpenText Web Experience Management - Planning and Installation Guide (WCMGT-IGD). 1.1 Types of Administrators This guide contains information for several types of administrators, based on the tasks each type must perform. The following paragraphs describe the different kinds of administrators briefly. Application Administrator An application administrator is skilled in the installation, configuration, operation, and maintenance of a specific application; for example: Java application server administrator Creates and configures the application server(s) for Web Experience Management administration, including application server security. Database administrator Creates and configures databases, maintains database security for the Web Experience Management software. Web Experience Management (WEM) administrator Creates WEM instances, configures WEM products. System Administrator A system administrator is skilled in the installation, configuration, operation, and maintenance of operating systems and computer hardware. This audience may also be responsible for installing the Web Experience Management software Network Administrator A network administrator is skilled in the installation, configuration, operation, and maintenance of network backbone devices, including hubs, switches, and routers. This audience also implements network security policies. Depending on the skill sets and the organization of people in your company, each type of administrator may be represented by one or more different user in your company. At the other end of the spectrum, a single user may have to perform the duties of all the different types of administrators. OpenText Web Experience Management Administration Guide 17

18 Chapter 1 Introduction to Administration 1.2 Administrative Tasks The following table lists typical Web Experience Management administrator tasks, and tells where to find out more information about them. Task Verifying that a Configuration Agent is running. Configuring Web Experience Management Managed Processes (VMPs) Starting and running the Runtime Services console, and performing the following administrative tasks: Managing Web Experience Management-related servers. Managing and cloning JDBC components for the Management stage content database. Tuning JVM heap size. Tuning the JTA transaction timeout setting. Configuring and maintaining LDAP, either the embedded version or an external repository Understand the Web Experience Management management-side clustering mechanism, including: Tips on what you must know and do before setting up a management-side cluster How client-side tools connect with management-side clustering How to check status of Web Experience Management components in a management-side cluster Changing the behavior of the HttpClusterServlet process Tuning and troubleshooting Understand the Web Experience Management authorization process. Assign roles to users and groups. Assign capabilities to roles. Create new roles. Specify authorized groups. Understand the basics of a configuration, including how information is stored in configuration files. Understand metrics supported by the Web Experience Management. Monitor product instances and their components. Access Web Experience Management metrics with other system management tools. For more information, see: Servers and Processes on page 23 Administering Runtime Services on page 29 Administering LDAP on page 57 Management-Side Clustering on page 81 Managing Authorization on page 105 Help for the Roles feature in the OpenText Web Experience Management - Management Console Online Help (WCMGT-H-ACM). Managing Configuration Information on page 169 Monitoring the WEM Software on page OpenText Web Experience Management Administration Guide

19 1.2. Administrative Tasks Task Understand how to bring a set of files that are created, deleted, and/or modified by a product that is not part of the Web Experience Management under control of the Content Management Server. Understand how to scan a Web Experience Management content database and make a list of all records that are not currently under Content Management Server control, but whose structures match one or more content types in the Content Management Server. You can then manipulate those records; for example, adding them to Content Management Server control, and so on. Understand the Web Experience Management configuration hierarchy. Manipulate the configuration hierarchy in the configuration tables or local configuration files. Fine tune your configuration by changing the value of configuration variables. Create scripts to install and configure your site. Package a project and copy it to another Content Management Server Create, stop, start Configuration Agents and Deployment Agents. Stop or start a WEM Managed Process. Exporting data currently under Content Management Server control and importing it to another Content Management Server. Importing data from non-web Experience Management sources to bring it under Content Management Server control. Read Web Experience Management log files. Modify the default log file format. Understand configuration files. Understand basic publishing and deployment concepts, including what happens to content from the time it is published, until it reaches its target endpoint (Deployment Agent/Endpoint Proxy pair). Troubleshooting publishing and deployment problems using the Job Console and other tools. For more information, see: File Source Scans on page 203 Content Scans on page 209 Command-Line Utilities on page 223 Exporting and Importing Objects on page 269 Logs, Other Files, and Directories on page 317 Publishing and Deployment on page 343 Troubleshooting Publish Problems on page 377 OpenText Web Experience Management Administration Guide 19

20 Chapter 1 Introduction to Administration Task Configuring additional features related to publishing and deployment, including: Customizing Deployment Types. Configuring handlers. Writing custom scripts. Adding resources. Perform workflow configuration tasks and code XML program tasks. Set new defaults for Content Workspaces preferences and/or transfer a set of preferences from one installation of Web Experience Management to another. Update license information. Perform database-related tasks. Configure WEM Managed Processes. View a list of WEM database tables (advanced users only) For more information, see: Customizing Deployment and Publishing on page 407 Configuring Notifications on page 433 Managing Preferences for Content Workspaces on page 441 Miscellaneous Tasks on page 459 Database Tables on page Using the Configuration Console The Configuration Console allows you to perform numerous tasks related to your Web Experience Management configuration. For example, you can add or delete components (stages, CDSs, Deployment Agents, and so on), change the values of configuration variables (for tuning or customizing the installation), and configure additional WEM products that you may have purchased. The Configuration Console is a web application that you access via a browser running on any supported Windows or UNIX machine. For information about how to start the Configuration Console, see Starting the Configuration Console on page 175. After you start the Configuration Console, you can access the OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT- H-ACC). This help provides detailed information on how to create connections that allow you to perform configuration-related administrative tasks. 20 OpenText Web Experience Management Administration Guide

21 1.4. Database Usage 1.4 Database Usage The Web Experience Management software creates database tables to store: Configuration information about installed, registered, and configured products and their subcomponents Mappings of users to roles and roles to capabilities Note: The Web Experience Management relies on an LDAP repository (either the embedded repository or an external one) for authentication of users and groups. You must map those users and groups to roles. Management information about all objects that the Web Experience Management manages, including projects, content instances, workflow definitions, taxonomies, and so on. Snapshot information These tables reside in various databases required for proper operation of the Web Experience Management software. Other databases can serve as content sources for the Content Management Server or as targets for deployment. See also: The Release Notes for supported databases and requirements OpenText Web Experience Management - Planning and Installation Guide (WCMGT- IGD) for a list of databases used in the Web Experience Management environment. Managing Authorization on page 105, for information on roles and capabilities. Database Tables on page 469, for lists of Web Experience Management database tables 1.5 Data Sources Content Delivery Services receives content from a content database, and sends event data to the Event Logging Service (ELS) OpenText Web Experience Management Administration Guide 21

22

23 Chapter 2 Servers and Processes This topic describes what servers and processes must be running for the WEM product to function properly. 2.1 Required Servers and Processes For the WEM product to function properly, a number of servers and processes must be running and accessible: Processes for prerequisite systems, such as: LDAP databases search module Application servers and related processes, for example: Node manager Administration server Managed servers (VgnVCMServer, stages, and so on) All Configuration Agents All Deployment Agents If you have just finished installing and configuring the WEM product, then most of the preceding processes will already be running. If you are running the Report Charting Service on a UNIX host, you must restart that process manually after a reboot. Windows-based hosts run the Report Charting Service as a service which is configured to start automatically on reboot. See also: For more information about starting and stopping WEM servers, see Managing Servers on page 31. For information about how to see if a Deployment Agent is running, see Deployment Agents on page 26. OpenText Web Experience Management Administration Guide 23

24 Chapter 2 Servers and Processes 2.2 Configuration Agents A Configuration Agent is a process used to communicate the configuration information you enter in the Configuration Console (or from the configuration command line utilities) to WEM components. Every host that contains a WEM component must have a Configuration Agent. If you have a firewall between the machine on which the Configuration Agent and the one from which you are running the Configuration Console, you must enable communication between the two machines. In addition, for the Configuration Console to communicate with a Configuration Agent, you must enable Internet Explorer for SSL communication on the machine where the Configuration Console is running. This enablement requires that you import a certificate. To enable Configuration Console (Internet Explorer) by importing a certificate: 1. On the machine from which you run the Configuration Console, open Internet Explorer. 2. In the Tools menu, choose the Internet Options menu item. 3. On the Content tab, click Certificates. 4. On the Certificates window, click Import. 5. On the first page of the Import Certificates wizard, click Next. 6. Browse to and select the VignetteIdentity.p12 file. The path to this file is as follows, where <WEMinstallDir> is the directory into which you installed the WEM software, and version is that software's version number (10.5 in this case): <WEMinstallDir>/Content/<version>/security/VignetteIdentity.p12 7. Click Next. Important Do not modify the default certificate supplied by OpenText. If the certificate provided does not meet your needs, you should configure the WEM software to use your own certificate. 8. On the Password panel, click Next to accept the defaults. 9. On the Certificate Store panel, click Next. 10. Click Finish. For more information on enabling SSL in the Web Experience Management, see the OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC). 24 OpenText Web Experience Management Administration Guide

25 2.2. Configuration Agents Verifying that a Configuration Agent is Running Assuming that the prerequisites in the preceding paragraphs are in place, perform the following steps to verify that a Configuration Agent is running. To verify that a Configuration Agent is running: 1. From a browser, open the following URL: where <host> is the name or IP address of the machine on which the Content Management Server is running, and <port> is the port number of the Content Management Server. 2. Log into the Configuration Console using the WEM administrator's ID and password. 3. In the Configuration Console's left pane, expand the following node: Configuration Console Configuration Agents Configuration Agent - <instancename> (<hostname>) > 4. Right-click on the agent's instance node and select Status. A new browser window opens. 5. In the new browser window, click the name of the Configuration Agent (for example, config.cfa-vgninst). The Configuration Agent's status displays in the right pane: If the status displays similar to the what is shown in the preceding figure, the Configuration Agent is running. If a Page Not Found error displays in the right pane, the Configuration Agent is not running. Note: If you receive a DNS error, be sure that you have imported a certificate into Internet Explorer as described in Configuration Agents on page 24. OpenText Web Experience Management Administration Guide 25

26 Chapter 2 Servers and Processes Starting or Stopping a Configuration Agent Use the Services application in the Control Panel (Windows-only) or the vgnadmin start or vgnadmin stop command (Windows or UNIX) to start or stop a Configuration Agent. For more information about vgnadmin, see vgnadmin on page Deployment Agents A Deployment Agent is the process that performs the actual deployment of content. For more information, see Deployment Agents on page 365. To verify that a Deployment Agent is running: 1. Open the Job Console in a browser. To do so, you must have WEM Admin privileges. If you have those privileges, the URL to open the Job Console is: where <host> is the host on which the Content Management Server is running, and <port> is the number of its listen port (usually 27110). 2. From the Job Console Actions menu, select Manage Endpoints. The Endpoint List window appears: 3. Together, the Deployment Agent and its associated Endpoint Proxy form an endpoint. Find the Deployment Agent's endpoint and look in its State column. The Deployment Agent is running if the state value is any of the following: Running The agent is running and its associated Endpoint Proxy is online. Standby The agent is running, but its associated Endpoint Proxy is offline. Suspended The agent is running, but its associated Endpoint Proxy is suspended. Note: The actual state is updated about once a minute; however, its value in the Endpoint List window does not refresh automatically. You should manually refresh the window in that timeframe to be sure that the current state is displayed. To start or stop a Deployment Agent: 1. Open the Job Console in a browser. To do so, you must have WEM Administrator privileges. If you have those privileges, the URL to open the Job Console is: 26 OpenText Web Experience Management Administration Guide

27 2.4. Configuring WEM Managed Processes where <host> is the host on which the Content Management Server is running, and <port> is the number of its listen port (usually 27110). 2. From the Job Console Actions menu, select Manage Endpoints. The Endpoint List window appears: 3. Under Endpoint Name, select the endpoint to which the Deployment Agent you want to stop belongs (for example, Appsvcs). The Endpoint Info window appears. 4. Select Start Endpoint or Stop Endpoint, as appropriate from the dropdown list of actions, then click Go. When you start or stop an endpoint, you are starting or stopping that endpoint s Deployment Agent. 5. Confirm the start/stop request when prompted. Note: If a Configuration Agent is running, it will start its associated Deployment Agent(s) automatically. 2.4 Configuring WEM Managed Processes A WEM Managed Process (VMP) is a process that is managed by a Configuration Agent. Currently, the only VMPs are Deployment Agents. Each Configuration Agent acts as a watchdog process for the Deployment Agents under its control, automatically restarting any Deployment Agent that dies. Note: If the Configuration Agent is shut down or dies, all of the Deployment Agents it watches are also shut down. Normally, any message generated by a Deployment Agent is sent to its own log file; however, if a Configuration Agent has problems starting or stopping a Deployment Agent, the messages related to the starting or stopping are sent to the log of the controlling Configuration Agent. If a certain number of restart attempts fail in a specified time, the Configuration Agent gives up trying to revive the downed Deployment Agent. The settable configuration variables related to VMPs are as follows: MAX_FAILURES Indicates how many times a Configuration Agent should attempt to revive a managed process that has stopped running before giving up revival attempts. A typical configuration hierarchy path for the variable would be: /vcm-vgninst/cdsvcs/stage-production/cds-production/ cdagents/cda-appsvcs/vgn/vmp/max_failures OpenText Web Experience Management Administration Guide 27

28 Chapter 2 Servers and Processes SHUTDOWN_INTERNAL On a shutdown request, the Configuration Agent waits for SHUTDOWN_INTERNAL milliseconds to allow all Deployment Agents to complete ongoing tasks before shutting them down. SHUTDOWN_INTERVAL If a managed process does not go down within the time specified by SHUTDOWN_INTERNAL, the Configuration Agent waits an additional SHUTDOWN_INTERVAL milliseconds, then forcibly kills the Deployment Agent. See also: vgnadmin vmpstart and vgnadmin vmpstop in vgnadmin on page 252 for specific information about starting and stopping Configuration Agents and/or Deployment Agents. Creating, Changing, or Deleting Configuration Variables on page OpenText Web Experience Management Administration Guide

29 Chapter 3 Administering Runtime Services This topic provides instructions for managing Runtime Services. 3.1 Introduction to the Runtime Services Console This chapter provides guidelines and instructions for using the Runtime Services Console. The Console is a Web browser-based, graphical user interface that lets you administer the J2EE components associated with the Content Management Server. The chapter addresses the following topics: Opening the Console Navigating the Console Managing servers Managing and cloning JDBC components for the Management stage database Tuning JVM heap size Tuning the JTA transaction timeout setting Configuring and managing the embedded LDAP component Note: Administering the embedded LDAP component is discussed in detail in Administering LDAP on page Opening the Runtime Services Console (Browser) To open the Runtime Services Console from a browser: 1. Open a browser. 2. Enter the following URL: where <hostname> is the name of the machine on which the Administration Server is running and <admin_server port> is the Administration Server's port number. (The default port is ) 3. Log into the Runtime Services Console using the WEM administrator username and password that you selected during the installation and setup process. OpenText Web Experience Management Administration Guide 29

30 Chapter 3 Administering Runtime Services Opening the Runtime Services Console (Configuration Console) To open the Runtime Services Console from the Configuration Console: 1. From a browser, open the following URL: where <host> is the name or IP address of the machine on which the Content Management Server is running, and <port> is the port number of the Content Management Server. 2. Log into the Configuration Console using the WEM administrator's ID and password. 3. Once connected, expand the following configuration tree nodes: Configuration Console Content Management Services 4. Right-click Management Services and select Runtime Services Console to launch the Runtime Services Console. 5. Log into the Runtime Services Console using the WEM administrator username and password that you selected during the installation and setup process. Refer to the OpenText Web Experience Management - Planning and Installation Guide (WCMGT-IGD) for more information Accessing Technical Documentation Follow these steps to access the documentation: 1. Go to the Open Text Knowledge Center at 2. Click the Open Text family of products. 3. Click Documentation. 4. Scroll to the WEM Management folder. 5. Navigate to the version, 10.5 documentation. 30 OpenText Web Experience Management Administration Guide

31 3.2. Managing Servers Using the Runtime Services Console To navigate the Runtime Services Console, first expand and/or select a node under Domain Structure in the left pane of the console. When you select a node, a list of links to objects appears in the right pane of the console. You can view information about an object or edit its value by clicking its link. When you click an object's link, the right pane refreshes and displays a tabbed interface (some tabs also contain sub-tabs). Clicking on a tab displays a subset of the object's configuration attributes, controls for administrative operations, or a display that you can use to monitor the current state of the object. To edit values in attribute fields that appear in the right pane, you must first click Lock & Edit under the Change Center in the left pane. After you make changes especially before you click on another tab click the Save button in the right pane. For your changes to take effect, click Activate Changes under the Change Center, and if prompted to do so, restart any servers or other resources. 3.2 Managing Servers Runtime Services consists of the following: The Administration Server, which provides a central point for managing vgndomain. You use the Administration Server through the Runtime Services Console to configure server instances and resources within vgndomain. One or more Content Management Servers (VgnVCMServer, VgnVCM2, VgnVCM3, and so on) which are managed servers. You control the Content Management Server(s) using the Runtime Services Administration Console. The Node Manager must also be running in order for you to start and control your managed servers. Node Manager,which is a Java program that resides on the same host as each Content Management Server. A Node Manager enables you to start, shut down, and monitor the Content Management Server on a particular host from the Runtime Services Console. You can run the Administration Server in a browser from any host on the same network as your configuration. Node manager is installed as a service only on Windows. The following subsections discuss procedures for starting and stopping the Administration Server, Node Manager, and VgnVCMServer in your WEM installation. In addition, this section documents ways in which you can use the Runtime Services Console to check server logs and to view and modify log level settings for each server. OpenText Web Experience Management Administration Guide 31

32 Chapter 3 Administering Runtime Services Manually Starting and Stopping Server-Related Processes For the WEM product to function properly, a number of processes must be running and accessible. The application server processes that must be running are the following: Node manager Administration server Content Management Server(s) You will need to restart the servers if you need to reboot the machines on which they are running or if you tune any of the connection pool or performance parameters discussed in this chapter. This section discusses how to manually start and stop the Administration Server, Node Manager, and the Content Management Server managed server(s) for Windows and UNIX systems. Automatically Restarting Servers and Processes on page 37, discusses how to set up your system so that servers and processes automatically restart. Note: Clustering functionality in the Runtime Services Console is not available in this release Starting and Stopping the Administration Server To start the Administration Server on Windows: 1. Select Start > Settings > Control Panel. 2. Double-click Administration Tools and open Services. 3. Right-click the vgn-admin-instance entry (for example, vgn admin vgninst) and select Start. To start the Administration Server on UNIX: 1. Change to the following directory: <WEMinstallDir>/Content/10_5/rtsvcs/domains/vgndomain/ 2. Run the startvgnadminserver.sh script. Note: If you are running remotely from an ssh or telnet session, use the following command syntax; otherwise when the ssh/telnet session is cancelled the service will die:./startvgnadminserver.sh> output 2>&1 & 32 OpenText Web Experience Management Administration Guide

33 3.2. Managing Servers To stop the Administration Server: 1. In the left pane of the Runtime Services Administration Console, under Domain Structure, click vgndomain. 2. In the right pane, click the Control tab. 3. Select the check box next to VgnAdminServer(admin). 4. From the dropdown menu for Shutdown, select one of the following: When work completes This command initiates a graceful shutdown, which gives Runtime Services subsystems time to complete certain application processing currently in progress. Force Shutdown Now This command initiates a forced shutdown, in which the server instructs subsystems to immediately drop in-work requests. 5. Click Yes to confirm and shut down the server. If you shut down the Administration Server, the Runtime Services Console is no longer active Starting and Stopping the Node Manager To start the Node Manager on Windows: 1. SelectStart >Settings > Control Panel 2. Double-click Administration Tools and open Services. 3. Right-click the vgn-node-instance entry and selectstart. To start the Node Manager on UNIX: 1. Change to the following directory: <WEMinstallDir>/Content/10_5/rtsvcs/nodemanager/ 2. Run the startvgnnodemanager.sh script. Note: If you are running remotely from an ssh or telnet session, use the following command syntax; otherwise when the ssh/telnet session is cancelled the service will die:./startvgnnodemanager.sh> output 2>&1 & To stop the Node Manager on Windows: 1. SelectStart >Settings > Control Panel. 2. Double-click the vgn-node-instance entry and select Stop. OpenText Web Experience Management Administration Guide 33

34 Chapter 3 Administering Runtime Services To stop the Node Manager on AIX: 1. Retrieve the java process ID for Runtime Services' Node Manager. For example: # ps -ef grep java grep rtsvcs grep NodeManager 2. Use that ID to kill the process. For example: # kill <nodemgrid> To stop the Node Manager on Solaris: 1. Retrieve the java process ID for Runtime Services' Node Manager. For example: # /usr/ucb/ps -auxwww grep java grep rtsvcs grep NodeManager 2. Use that ID to kill the process. For example: # kill <nodemgrid> Starting or Stopping a Content Management Server To start or stop a Content Management Server using the Runtime Services Console: Note: The Administration Server and Node Manager must be running in order to access a Content Management Server running on your configuration (VgnVCMServer, VgnVCM2, VgnVCM3, and so on). Refer to To stop a Content Management Server from the command line: on page 35 for information on manually restarting these servers. 1. In the left pane of the Runtime Services Administration Console, under Domain Structure, click vgndomain. 2. In the right pane, click the Control tab. 3. In the right pane, check the box next to a managed server; for example VgnVCMServer. 4. In the right pane, perform the desired action: To start the server, click Start. To stop the server, select one of the following from the dropdown menu for Shutdown: When work completes This command initiates a graceful shutdown, which gives Runtime Services subsystems time to complete certain application processing currently in progress. Force Shutdown Now This command initiates a forced shutdown, in which the server instructs subsystems to immediately drop in-work requests. 5. ClickYes to confirm. 34 OpenText Web Experience Management Administration Guide

35 3.2. Managing Servers 6. If necessary, refresh the browser window to update the State of the server. 7. When the Node Manager finishes its start sequence, the server's State should be RUNNING. When it finishes its stop sequence, the server's state should be SHUTDOWN. 8. To view messages that the Node Manager generated while starting the server, click the TASK COMPLETED link under the Status of Last Action column. To start a Content Management Server from the command line: 1. On the host where the Content Management Server resides, go to the command line and change to the WEM product's bin directory, which is located at: <WEMinstallDir>/Content/<version>/bin For example: Windows: C:\OpenText\WEM\Content\10_5\bin UNIX: /opt/opentext/wem/content/10_5/bin 2. Run the following command: Windows: managevcmserver.cmd START <server> <loginid> <password> UNIX:./manageVCMServer.sh START<server> <loginid> <pwd> where <server> is the name of the Content Management Server be started, <loginid> is the login ID of the WEM administrator, and <pwd> is that user's password. If you are running management-side clustering, the Administration node's instance of <server> is named VgnVCMServer. Default names for the other nodes take the form of VgnVCM <x>, where <x> is a node number. To stop a Content Management Server from the command line: 1. From a command line, change to the WEM bin directory, which is located at: <WEMinstallDir>/Content/<version>/bin 2. Run one of the following commands: Windows: managevcmserver.cmd SHUTDOWN<server> <loginid> <pwd> managevcmserver.cmd FORCESHUTDOWN<server> <loginid> <pwd> UNIX:./manageVCMServer.sh SHUTDOWN<server> <loginid> <pwd>./managevcmserver.sh FORCESHUTDOWN<server> <loginid> <pwd> where <server> is the name of the Content Management Server to be stopped, <loginid> is the login ID of the WEM administrator, and <pwd> is that user's password. If you are running management-side clustering, the Administration OpenText Web Experience Management Administration Guide 35

36 Chapter 3 Administering Runtime Services node's instance of <server> is named VgnVCMServer. Default names for the other nodes take the form of VgnVCM <x>, where <x> is a node number Starting or Stopping a Management-Side Cluster To start or stop the entire cluster from the Runtime Services Console: 1. Under Domain Structure in the left pane of the console, navigate to vgndomain >Environment > Clusters, and click the Clusters node. 2. In the right pane, click VgnCluster. 3. Click the Control tab. 4. Check the box to select all servers. 5. In the right pane, perform the desired action: To start all servers in the cluster, click Start. To stop all servers in the cluster, select one of the following from the dropdown menu for Shutdown: When work completes Initiates a graceful shutdown, which gives Runtime Services subsystems time to complete certain application processing currently in progress. Force Shutdown Now Initiates a forced shutdown, in which the each server in the cluster instructs subsystems to immediately drop in-work requests. 6. Click Yes to confirm. 7. If necessary, refresh the browser window to update the State of the cluster. 8. When the Node Manager finishes its start sequences, the state of the cluster's servers should be RUNNING. When it finishes its stop sequences, the state of the cluster's servers should be SHUTDOWN. To view messages that the Node Manager generated while starting or stopping the cluster, click the TASK COMPLETED link under the Status of Last Action column. To start the entire cluster from the command line: 1. From a command line, change to the WEM bin directory, which is located at: <WEMinstallDir>/Content/<version>/bin For example: Windows: C:\OpenText\WEM/Content\10_5\bin UNIX: /opt/opentext/wem/content/10_5/bin 2. Run the following command: Windows: managevgncluster.cmd START <loginid> <pwd> 36 OpenText Web Experience Management Administration Guide

37 3.2. Managing Servers UNIX:./manageVgnCluster.sh START <loginid> <pwd> where <loginid> is the login ID of the WEM administrator, and <pwd> is that user's password. To stop the entire cluster from the command line: 1. From a command line, change to the WEM bin directory, which is located at: <WEMinstallDir>/Content/<version>/bin For example: Windows: C:\OpenText\WEM\Content\10_5\bin UNIX: /opt/opentext/wem/content/10_5/bin 2. Run the following command: Windows:manageVgnCluster.cmd STOP <loginid> <pwd> UNIX:./manageVgnCluster.sh STOP <loginid> <pwd> where <loginid> is the login ID of the WEM administrator, and <pwd> is that user's password Automatically Restarting Servers and Processes You can set up your system to automatically restart the servers and processes associated with Runtime Services in the event that one or more hosts in your system go down. To do so, you must start those servers in the following order: Node Manager Administration Server Content Management Server(s) (managed servers) Node Manager If running on a Windows host, the Node Manager runs as a service, and so it starts automatically after a failure, because its Startup Type is set to Automatic by default. If running on UNIX, the Node Manager does not start automatically after a failure. To make it do so, you must create or modify an initialization file in your UNIX initialization directories (for example, init.d or rc0.d). In the initialization file: 1. Change to the following directory: <WEMinstallDir>/Content/10_5/rtsvcs/nodemanager/ 2. Run the startvgnnodemanager.sh script. OpenText Web Experience Management Administration Guide 37

38 Chapter 3 Administering Runtime Services Administration Server If running on a Windows host, the Administration Server runs as a service and will start automatically after a failure because its default Startup Type is set to Automatic by default. If running on UNIX, the Administration Server does not start automatically after a failure. To make it do so, you must create or modify an initialization file in your UNIX initialization directories (for example, init.d or rc0.d). In the initialization file: 1. Change to the following directory: <WEMinstallDir>/Content/10_5/rtsvcs/domains/vgndomain/ 2. Run the startvgnadminserver.sh script Content Management Server Managed Server If running on a Windows host, if the last known state of a Content Management Server managed server was Running, the Node Manager automatically restarts the Content Management Server in the event it goes down. Otherwise, you must start the server manually by calling the following startup script with the appropriate arguments (see Starting or Stopping a Content Management Server on page 34): <WEMinstallDir>\Content\10_5\bin\manageVCMServer.cmd If running on UNIX, the Content Management Server managed server does not start automatically after a failure. To make it do so, you must create or modify an initialization file in your UNIX initialization directories (for example, init.d or rc0.d). In the initialization file: 1. Change to the following directory: <WEMinstallDir>/Content/10_5/bin/ 2. Run the managevcmserver.sh script with the appropriate arguments (see Starting or Stopping a Content Management Server on page 34) Viewing Server Logs To keep a record of the messages that its subsystems generate, Runtime Services writes the messages to log files. The server log file is located on the computer that hosts the server instance. The server log records information about events such as the startup and shutdown of servers or the failure of one or more subsystems. The messages include information about the time and date of the event as well as the ID of the user who initiated the event. This information is helpful when trying to detect problems, track down the source of a fault, or track system performance, Use the Runtime Services Console to view the log files for the WEM Admin Server the Content Management Server(s). Use its filtering tools to limit the set of messages 38 OpenText Web Experience Management Administration Guide

39 3.3. Managing Resources that it displays. For example, you can use the filtering tools to view only the messages that the JDBC subsystem has generated. Note: Before you view (or attempt to customize) the server logs, click Lock & Edit under the Change Center in the left pane of the console. Similarly, once you finish, click Release Configuration under the Change Center. To view server logs using the Runtime Services Console: 1. Under Domain Structure in the left pane of the console, navigate to vgndomain >Diagnostics > Log Files, and click the Log Files node. 2. Under the Name column, find the ServerLog entry for the WEM server file you wish to view, and select its radio button: VgnAdminServer VgnVCMServer 3. Click View. A table representing a filtered view of the server's log appears in the right pane of the console. 4. Select the radio button next to any message and click View to see additional information about the message. This includes the probable cause and any actions to take (toward the bottom of the display). You can also filter messages, change log levels, specify which messages the server sends to standard out, change which message attributes the log viewer displays, and perform other log-related changes. For more information, click the Help button in the console's toolbar. 3.3 Managing Resources When you set up the WEM software, you are prompted to specify which resource mode your configuration should use: standard, high, or desktop. Based on which mode you specify, the WEM software sets default operating values for the following resources: Connection pools (see Managing Data Sources and Their Connection Pools on page 40) Queue threads (see Managing Threads on page 48) JVM settings (see Managing Heap Size and other JVM Settings on page 49) You may need to modify some of these settings; for example, if your database information or location change, or if you need to tune connection parameters to suit your environment, and so on. Caution Improper settings can degrade the performance of the Content Management Server and other applications on the same machine. OpenText Web Experience Management Administration Guide 39

40 Chapter 3 Administering Runtime Services Therefore, always test new settings on a sandbox system that is not connected to your production system Managing Data Sources and Their Connection Pools When you install and configure the WEM software, it automatically sets attributes for the WEM database; in particular for each of the following data sources (and each data source's associated connection pool): VgnNonTxDataSource JNDI name: vignette.jdbc.vgnnontxdatasource For backwards compatibility, the following JNDI names are also associated with this data source: vignette.jdbc.authnontxdatasource vignette.jdbc.confignontxdatasource Note: Future use of these last two JNDI names in your applications is strongly discouraged, as the names may be discontinued in future releases: VgnTxDataSource JNDI name: vignette.jdbc.vgntxdatasource ContentTxDataSource (if you have a split content database) JNDI name: vignette.jdbc.contenttxdatasource Connection pools use a JDBC driver to create physical database connections. The Content Management Server borrows a connection from the pool, uses it, and then returns it to the pool by closing it. Each data source object binds to the JNDI tree and points to its own associated connection pool. Applications look up the data source on the JNDI tree and then request a connection from the data source. The following paragraphs describe how to view, modify, and test connection pool and data source settings Viewing and Modifying Connection Pool Settings This section discusses procedures for viewing and/or modifying the connection pool settings for the VgnNonTxDataSource and VgnTxDataSource data sources. You may need to modify these attribute fields if you have changed values such as your database host machine, its listening port, or database user and password, or if you choose to tune connection pool parameters. Note: Running servers will not reflect changes you make to the following attributes until they are restarted; you may need to restart some servers in order for the new value to take effect. 40 OpenText Web Experience Management Administration Guide

41 3.3. Managing Resources To view or modify connection pool settings for WEM data sources: 1. In the Domain Structure area of the Runtime Services Console's left pane, expand vgndomain > Services > Data Sources, and click Data Sources. 2. In the right pane, click the VgnNonTxDataSource or VgnTxDataSource data source. The pane refreshes, showing the settings for that data source. 3. If it is not already selected, select the Configuration tab, and the Connection Pool subtab under it to view the following fields: Attribute Field URL Driver Classname Description The URL of the database to connect to. The format of the URL varies by JDBC driver. The JDBC driver class used to create the physical database connections the connection pool. This attribute field is prepopulated with the driver associated with your database. Properties (for Microsoft Server SQL) Properties (for DB2) Note: This value should not be modified. The list of properties passed to the JDBC driver. Each property=value pair must be listed on a separate line. servername= Name of the server on which the WEM database resides. user= Name of user WEM will use to access the WEM database. databasename= Name of the database that contains WEM tables. PortNumber= Port number for the server on which the WEM database resides. Modify these values if any of your database properties have changed. The list of properties passed to the JDBC driver. Each property=value pair must be listed on a separate line. user= Name of user WEM will use to access the WEM database. DatabaseName= Name of the database that contains WEM tables. Modify these values if any of your database properties have changed. OpenText Web Experience Management Administration Guide 41

42 Chapter 3 Administering Runtime Services Attribute Field Properties (for Oracle) Password Confirm Password Description The list of properties passed to the JDBC driver. Each property=value pair must be listed on a separate line. The following default value was derived from the database coordinate values you entered when using the Content Suite Setup: databasename= Name of the database that contains WEM tables. ServerName= Name of the server on which the WEM database resides. User= Name of user that WEM will use to access the WEM database. Portnumber= Port number for the server on which the WEM database resides. Modify these values if any of your database properties have changed. The database account password used in the physical database connection. Confirmation of the database account password Note: The following table shows default settings for the rest of the connection pool attributes. The values shown are recommended for most installations. However, if you wish to modify the maximum capacity setting, do so based on the expected number of users who will concurrently use your system (meaning concurrent hits to your system.) Attribute Field Initial Capacity Description The number of physical database connections. Minimum value for this field is 0. Maximum value is (the largest possible positive 32-bit integer). The value is not dynamic. Default Resource Mode Value Standard High Desktop OpenText Web Experience Management Administration Guide

43 3.3. Managing Resources Attribute Field Maximum Capacity Description The maximum number of physical database connections. Minimum value for this field is 1. Maximum value is (the largest possible positive 32-bit integer). The value is dynamic. Default Resource Mode Value Standard High Desktop Capacity Increment Statement Cache Type Statement Cache Size Note: The default settings shown to the right are optimal for most environments; however, should you need to tune this number, OpenText recommends that you do so based on the expected number of users who are concurrently using your system (meaning concurrent hits). The increment by which the capacity of the associated connection pools for the VgnNonTxDataSource and VgnTxDataSource data sources is expanded. Minimum value for this field is 1. Maximum value is (the largest possible positive 32-bit integer). The value is dynamic. The algorithm used for maintaining the prepared statements stored in the cache. LRU replaces the least recently used statements when new statements are used. The number of prepared and callable statements stored in the cache. The value is dynamic LRU LRU LRU Shrink Frequency (Advanced Option) The number of seconds to wait before shrinking a connection pool if that pool has been incremented to meet demand. 0 (disabled) 0 (disabled) Click Advanced to see other attributes. 5. To change any of the values: a. Click Lock & Edit in the Change Center area of the Runtime Services Console's left pane. b. Make the desired change. c. Click Save. OpenText Web Experience Management Administration Guide 43

44 Chapter 3 Administering Runtime Services d. Click Activate Changes under the Change Center. e. If necessary, stop and restart processes as described in Manually Starting and Stopping Server-Related Processes on page To test the changes: a. Select the Monitoring tab and the Testing subtab under it. b. Select the radio button next to the Server/State/data source Name for the connection pool where you made changes. c. Click Test Data Source. The results of the test appear in the Messages box at the top of the right pane. For more information, click the Help button in the console's toolbar Connection Pool Testing Using the procedures documented in this paragraph, you can configure your system so that when a connection is requested from a connection pool associated with one of the WEM data sources, the pool will test the connection before returning the connection. This way, the test can capture information about a bad connection, and discard/remake such a connection. Note: Because connection pool testing adds overhead and might adversely impact performance, you should enable it only after trying it on a sandbox system isolated from your production network. You can test the following types of connection pools: Database resources One you create, or one provided with WEM (such as the Application Services Database resources used by Deployment Agents). You can test these connections using either a test table or a SQL command. Runtime Services JDBC connection pools This refers to connection pools associated with the VgnNonTxDataSource and VgnTxDataSource data sources. Each of these data sources used by the Management stage contains its own associated connection pool. You can optionally enable connection pool testing for these connection pools, and/or for other connection pools used by the Management stage (such as the split content database connection pool ContentTxDataSource). The following paragraphs give specific details about how to test connection pools especially WEM-specific ones. See the following resources for more information about data source/connection pool testing: Configure testing options for a JDBC data source taskhelp/jdbc/jdbc_datasources/ ConfigureTestingOptionsForADataSource.html Test JDBC data sources 44 OpenText Web Experience Management Administration Guide

45 3.3. Managing Resources taskhelp/jdbc/jdbc_datasources/testdatasources.html JDBC Data Source: Configuration: Connection Pool pagehelp/ JDBCjdbcdatasourcesjdbcdatasourceconfigconnectionpooltitle.html Advanced Configuration Options pagehelp/ JDBCjdbcdatasourcesjdbcdatasourceconfigconnectionpooltitle.html#advan cedattributes Testing Database Resources This section discusses in detail how to enable connection pool testing for a Database resource. To enable connection pool testing for a Runtime Services JDBC connection pool, skip this section and see Testing Runtime Services JDBC Connection Pools on page 46. To enable connection pool testing for a Database resource: Note: The following procedure uses the Configuration Console to set a configuration variable. Alternately, you can use the configp command-line utility to do so. 1. From a browser, open the following URL: where <host> is the name or IP address of the machine on which the Content Management Server is running, and <port> is the port number of the Content Management Server. 2. Log into the Configuration Console using the WEM administrator's ID and password. 3. Navigate to the JDBC Settings node of the Database resource for which you want to configure connection pool testing. For example, if you have a delivery stage named Production: Configuration Console > Content > Delivery Services > Content Delivery Stage - Production > Resources > OpenText Web Experience Management Administration Guide 45

46 Chapter 3 Administering Runtime Services Resource Type - Databases > Resource - AppSvcs Resource > JDBC 4. In the right pane, scroll down and click the TEST_TABLE configuration variable. 5. In the TEST_TABLE Properties dialog box, enter one of the following in the Config Value field: The name of a small table to use in a query to test database connections. The table must exist in the schema, and it must be available to the database user for the connection. Also, be sure that the table is small (perhaps even with no rows); otherwise, performance can be negatively impacted. You might even consider creating your own table in the appropriate database schema (system or content database for the Management stage, or your delivery database for a delivery stage). The default SQL query used to test a connection follows: Example: select count(*) from <TestTableName> A database vendor-specific SQL query; for example: Database DB2 Oracle Default test query SQL SELECT 1 FROM SYSIBM.SYSDUMMY1 SQL SELECT 1 FROM DUAL SQL Server SQL SELECT 1 If you prefer to use a different query as a connection test, enter SQL followed by a space and the SQL code you want to use. 6. In the TEST_TABLE Properties dialog box, clicksave. 7. Push or commit the change to the configuration as discussed in the OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC). 8. Follow the prompts on your screen to restart the affected components. Testing Runtime Services JDBC Connection Pools This section discusses in detail how to enable connection pool testing for the WEM data sources. To enable connection pool testing for a Database resource, skip this section and see Testing Database Resources on page 45. The WEM data sources used by the Management stage (VgnNonTxDataSource and VgnTxDataSource) each contains its own associated connection pool. Note: OpenText strongly recommends implementing connection pool testing on a sandbox system removed from your production network before 46 OpenText Web Experience Management Administration Guide

47 3.3. Managing Resources attempting to use connection pool testing in a production system. This is especially true if you want to use testing on the heavily-used connection pools for the VgnNonTxDataSource and VgnTxDataSource data sources. You cannot create JDBC connection pools for the delivery stage in the Runtime Services Administration Console. To learn about options for enabling connection pool testing on a delivery stage, consult the documentation provided with your delivery stage application server. To enable connection pool testing for a Runtime Services JDBC connection pool: 1. Log in to the Runtime Services Administration Console as an administrator. 2. Click Lock & Edit in the Change Center area of the Runtime Services Console's left pane. 3. In the Domain Structure area of the Runtime Services Console's left pane, expand vgndomain > Services > JDBC > Data Sources, and click Data Sources. 4. In the right pane, click the VgnNonTxDataSource or VgnTxDataSource data source. The pane refreshes, showing the settings for that data source. 5. If it is not already selected, select the Configuration tab, and the Connection Pool subtab under it. 6. Scroll down and click Advanced. 7. Select one or more of the following options: Test Connections on Reserve Select this check box to have Runtime Services test the database connection before giving it to the client. Test Frequency: Enter a number representing the number of seconds that Runtime Services should pause between background connection tests. 8. In Test Table Name:, enter one of the following: The name of a small table to use in a query to test database connections. The table must exist in the schema, and it must be available to the database user for the connection. Also, be sure that the table is small (perhaps even with no rows); otherwise, performance can be negatively impacted. You might even consider creating your own table in the appropriate database schema (system or content database for the Management stage, or your delivery database for a delivery stage). The default SQL query used to test a connection follows: select count(*) from <TestTableName> A database vendor-specific SQL query; for example: Database DB2 Default test query SQL SELECT 1 FROM SYSIBM.SYSDUMMY1 OpenText Web Experience Management Administration Guide 47

48 Chapter 3 Administering Runtime Services Database Oracle Default test query SQL SELECT 1 FROM DUAL SQL Server SQL SELECT 1 If you prefer to use a different query as a connection test, enter SQL followed by a space and the SQL code you want to use. 9. Optional: In Seconds to Trust an Idle Pool Connection, enter how many seconds Runtime Services should wait before running the test. If an existing connection is used before the waiting period expires, Runtime Services will skip the connection test. This option can possibly improve performance by reducing the overhead of connection testing. 10. Click Save. 11. Click Activate Changes under the Change Center Managing Threads Note: Not all changes take effect immediately-some require a restart. The embedded application server for Runtime Services uses a single thread pool in which all work is executed. Work is prioritized according to rules defined by the WEM administrator, and on run-time metrics. The metrics include the actual time taken to execute a request, as well as the rate at which requests enter and leave the thread pool. The preceding functionality is implemented as a globalwork manager named VgnCluster.WorkManager. A work manager defines a set of request classes and thread constraints that manage work performed by the application server for Runtime Services. A global work manager is defined at the domain level. For additional information, see the following: VgnCluster.WorkManager is a self-tuning work manager. It is deployed to the Content Management Server cluster (VgnCluster) so any changes to its settings will affect the thread pool used by all the servers in the cluster. Work Manager pagehelp/corecoreworkmanagerstitle.html Understanding Work Managers self_tuned.html#wp Using Work Managers to Optimize Scheduled Work self_tuned.html 48 OpenText Web Experience Management Administration Guide

49 3.3. Managing Resources To view or modify work manager constraint and/or class settings: Caution Improper settings can degrade the performance of the Content Management Server and other applications on the same machine. Therefore, always test new settings on a sandbox system that is not connected to your production system. 1. Under Domain Structure in the left pane of the console, navigate to vgndomain > Environment > Work Managers, and click the Work Managers node. 2. In the right pane, click the work manager constraint or class for which you want to modify settings; for example: VgnCluster.WorkManager.capacity VgnCluster.WorkManager.max.threads VgnCluster.WorkManager.min.threads VgnCluster.WorkManager.response.time 3. To change any of the values: a. Click Lock & Edit in the Change Center area of the Runtime Services Console's left pane. b. Make the desired change. c. Click Save. d. Click Activate Changes under the Change Center. e. If necessary, stop and restart processes as described in Manually Starting and Stopping Server-Related Processes on page Managing Heap Size and other JVM Settings The JVM heap size determines how often and how long the JVM spends collecting garbage. An acceptable rate and duration for garbage collection is applicationspecific and should be adjusted after analyzing the actual time and frequency of garbage collections. Tuning heap size allows you to optimize the time that your JVM spends doing garbage collection while maximizing the number of clients that a server can handle at a given time. JVM Settings (OS=Operating System) on page 50 provides the default JVM settings that are used for each supported operating system when either Standard, High Resource or Desktop mode is selected during installation. OpenText Web Experience Management Administration Guide 49

50 Chapter 3 Administering Runtime Services Table 3-1: JVM Settings (OS=Operating System) OS Standard mode settings High resource mode settings AIX Linux -server -Xms1g -Xmx1g -Xcompressedrefs -server -Xnohup -Xgc:parallel -Xms1g -Xmx1g -XX:+UseNewHash Function Solaris -d64 -server -Xrs -Xms1g -Xmx1g -XX:+UseParallelGC - XX:MaxPermSize=300m -XX:+CMSClass UnloadingEnabled -XX:+CMSPermGen SweepingEnabled Window s -server -Xnohup -Xgc:parallel -Xms1g -Xmx1g -XX:+UseNewHash Function -server -Xms1g -Xmx2g -Xcompressedrefs -server -Xnohup -XXaggressive -d64 -server -Xrs -XX:+AggressiveHeap - XX:MaxPermSize=300m -server -Xnohup -XXaggressive Desktop resource mode settings -server -Xgcpolicy: optavgpause -Xms256m -Xmx1g -Xdisable excessivegc -Xcompressedrefs -Xnohup -Xgc:singlecon -Xms256m -Xmx1g -XX:+UseNewHash Function -d64 -server -Xrs -Xms256m -Xmx1g - XX:MaxPermSize=300m -XX:+CMSClass Unloading Enabled -XX:+CMSPermGen SweepingEnabled -Xnohup -Xgc:singlecon -Xms256m -Xmx1g -XX:+UseNewHash Function To modify heap size values using the Runtime Services Console: Caution Improper settings can degrade the performance of the Content Management Server and other applications on the same machine. Therefore, always test new settings on a sandbox system that is not connected to your production system. 1. Click Lock & Edit in the Change Center area of the Runtime Services Console's left pane. 50 OpenText Web Experience Management Administration Guide

51 3.4. Modifying the JTA Transaction Timeout Setting 2. Under Domain Structure in the left pane of the console, navigate to vgndomain > Environment > Servers, and click the Servers node. 3. In the right pane, click VgnVCMServer (or the Content Management Server for which you want to modify the heap size). The main window displays showing tabs associated with settings for the server. 4. Select the Server Start tab. 5. In the Arguments attribute field, modify the values as necessary for your environment. 6. Click Save to save your changes. 7. Under the Change Center in the left pane, click Activate Changes. 8. If you are running a management-side cluster, repeat the preceding steps for each node in the cluster. 3.4 Modifying the JTA Transaction Timeout Setting This section discusses how to view and/or modify the JTA timeout setting using the Runtime Services Console. The setting for JTA timeout is applicable at the domain level. This means that the setting applies to all servers within the WEM domain. The default Runtime Services setting for the vgndomain is 300 seconds. If the transaction is still in the "active" state after this time (counting from begin()), it is automatically rolled back. Once the transaction moves on to the prepared state, however, this timeout parameter does not apply; the transaction is retried until all the resources are committed. Important The default setting is optimal for most installations. If you are experiencing transaction timeout during publishing, you may wish to increase this default value. However, if you do increase the default value, you should also increase the database distributed transaction timeout (for Oracle) or the DB Lock (for DB2) to be a minute greater than the new JTA timeout. To view and/or modify the JTA Transaction Timeout setting: 1. Click Lock & Edit in the Change Center area of the Runtime Services Console's left pane. 2. In the left pane of the Console, select vgndomain (right below the word "Console"). 3. If not already selected, select the Configuration tab in the right pane. 4. Click the JTA subtab. 5. View and/or modify thetimeout Seconds attribute field, which shows a default setting of 300 seconds. OpenText Web Experience Management Administration Guide 51

52 Chapter 3 Administering Runtime Services 6. Click Save to save any changes you made. 7. Under the Change Center in the left pane, click Activate Changes. 8. If you are running a management-side cluster, repeat the preceding steps for each node in the cluster. 3.5 Administering Runtime Services Embedded LDAP See Administering Embedded LDAP on page 58, and Security Data on page Backing Up Directories and Files Used by the Administration Server The Administration Server requires access to the configuration and security data for the vgndomain domain. Some of that data is backed up automatically by the Administration Server, but some you will need to back up yourself. If you make Runtime Services configuration or security changes and those changes somehow damage the Administration Server such that you cannot restart the server, you can use the backups discussed in this section to restore the Administration Server Configuration Information When running, the Application Server uses the vgndomain's configuration information stored in the config.xml file. That file is located in the following directory: <WEMinstallDir>/Content/10_5/rtsvcs/domains/vgndomain/config/ Each time you change the Runtime Services configuration and save that change, the Administration Server creates an archive file named config-<#>.jar for the entire config directory. The directory that contains the archived versions of config- #<n>.jar is located at: <WEMinstallDir>/Content/10_5/rtsvcs/domains/vgndomain/configArchive/ The Administration Server backs up the configarchive directory automatically. The archived files are named with a version number extension, as follows: config-#<n>.jar For example: config-200.jar The higher the value of <n>, the newer the archived config file. 52 OpenText Web Experience Management Administration Guide

53 3.6. Backing Up Directories and Files Used by the Administration Server By default, the Administration Server keeps six versions of config.xml: one runtime version (in the vgndomain/config directory) and five archived versions of config-200.jar (in the vgndomain/configarchive directory). When a new archived file is added, the oldest archived file is deleted if necessary, so that there are never more than the four archived versions available at one time. You can change the number of archived files that the Administration Server saves. To configure how many copies of config.xml are archived: 1. Click Lock & Edit in the Change Center area of the Runtime Services Console's left pane. 2. In the left pane of the Runtime Services Console, click on vgndomain. 3. In the right pane, click the Configuration > General tab. 4. Click Advanced. 5. In the Archive Configuration Count box, enter the number of versions to save. The default value of 5 means that there is one runtime version of config.xml and five archived versions. 6. Click Save to save any changes you made. 7. Under the Change Center in the left pane, click Activate Changes. 8. If you are running a management-side cluster, repeat the preceding steps for each node in the cluster Security Data The Runtime Services Security service stores configuration data in config.xml. It also stores security-related data in your LDAP repository and other files. The preceding section discussed where to find archived copies of config.xml. The following paragraphs discuss where the other security-related data is archived Automatic LDAP Backups: The ldap/backup Directory Once a day, the Administration Server suspends write operations and creates its own backup of security-related LDAP data. It archives this backup in a ZIP file in the following directory: <WEMinstallDir>/Content/10_5/rtsvcs/domains/vgndomain/servers/ VgnAdminServer/data/ldap/backup/ Once the backup is complete, the Administration Server resumes write operations. OpenText Web Experience Management Administration Guide 53

54 Chapter 3 Administering Runtime Services Manual LDAP Backups If you plan to make potentially volatile changes to your Administration Server, consider backing up the data in your LDAP repository to be sure that you have the latest information. This caveat applies both to configurations using the WEM product's embedded LDAP repository and to configurations that use an external repository. The main directory that you should back up is: <WEMinstallDir>/Content/10_5/rtsvcs/domains/vgndomain/servers/ VgnAdminServer/data/ldap/ldapfiles/ Although each host in a clustered configuration contains its own version of the ldap directory, only back up the directory present on the Administration Server host. This is because the Administration Server stores all LDAP-related information directly in its own ldap directory, then propagates that information to the ldap directory on other hosts in the clustered configuration when a change is made. Note: You cannot change security data manually on hosts other than the Administration Server host. Additionally, you cannot modify security data when the Administration Server is unavailable. The following subdirectory contains the data files for the LDAP server: <WEMinstallDir>/Content/10_5/rtsvcs/domains/vgndomain/server/ VgnAdminServer/data/ldap/ldapfiles/ ldapfiles also contains information about users, groups, group memberships, policies, and roles. Other subdirectories under ldap contain LDAP server message logs and data about replicated LDAP information. Note: Do not update the configuration of a security provider while a backup of LDAP data is in progress. If a change is made while an LDAP backup is in progress (for example, you add a user), the backup of the ldapfiles subdirectory may contain inconsistent data. If this happens, you may need to fall back on the daily automatic LDAP backup. The data in the automatic backup will be consistent, although it may not be as up-to-date as the information currently in the ldap directory. 54 OpenText Web Experience Management Administration Guide

55 3.6. Backing Up Directories and Files Used by the Administration Server SerializedSystemIni.dat and Security Certificates Hosts on which the Administration Server, or a managed server runs, create a file named SerializedSystemIni.dat. Each version of the file contains encrypted security data that must be present in order for the appropriate server to boot. The files are located in one of the following directory: <WEMinstallDir>/Content/10_5/rtsvcs/domains/vgndomain/security Note: These files are not backed up automatically. You must back them up manually. You must also back up all security certificates and keys. The location of these files is under the following directory: <WEMinstallDir>/Content/10_5/security/ OpenText Web Experience Management Administration Guide 55

56

57 Chapter 4 Administering LDAP This chapter discusses the following administration tasks: During installation of the WEM product, if you chose to use the Runtime Services embedded LDAP repository, this chapter provides information about administering that repository. If you chose to use an external LDAP repository, this chapter tells what you must reconfigure in the WEM product when you make changes to that external repository (so that the suite will recognize your changes). 4.1 Introduction The WEM software allows you to use either of the following LDAP repositories to manage the users and groups that will access your WEM installation: The LDAP repository embedded as part of the WEM software An existing external LDAP repository In addition, this section provides information on how to integrate Web Experience Management with OpenText Directory Services. 4.2 Naming Restrictions for Embedded and External Repositories Whether you use the embedded LDAP repository or an external repository, you must keep in mind the following restrictions when adding new users or groups to that repository: User and group names must be unique. Names are case-sensitive. Duplicate user names or group names are not allowed. The following characters are not allowed in names: spaces, tabs, commas, or any of the following: <> # &? ( ) { } For more information about naming restrictions, see: security/defineusers.html security/definegroups.html OpenText Web Experience Management Administration Guide 57

58 Chapter 4 Administering LDAP 4.3 Administering Embedded LDAP This topic discusses how to complete configuration and user/group management tasks within the Runtime Services embedded LDAP component Changing the Embedded LDAP Credentials In order to enable full capabilities for administering the embedded LDAP component, you must change the embedded LDAP credentials using the following procedure. To change the embedded LDAP credentials: 1. In the Change Center at the top of the left pane of the Runtime Services Console, click Lock & Edit. 2. In Domain Structure, click vgndomain. 3. In the right pane, select the Security tab, and then click its Embedded LDAP sub-tab. 4. Change the Credential attribute that connects you to the embedded LDAP server. You will need to use this Credential later when connecting to embedded LDAP from an external LDAP editor. 5. Click Save. 6. In the left pane, click Activate Changes. 7. Restart your Runtime Services processes as outlined in Manually Starting and Stopping Server-Related Processes on page Viewing Embedded LDAP Server Contents from an LDAP Editor This section provides general instructions for connecting to an external LDAP editor. This allows you to view the contents of your embedded LDAP repository and to complete some necessary tasks outlined in this chapter. Ensure that you have changed your embedded LDAP credentials as described in Changing the Embedded LDAP Credentials on page 58. To connect to the embedded LDAP server through an LDAP editor: 1. Download an external LDAP editor of your choice, following the provider's documentation. Note: See Knowledge Base item 9174 for a list of external LDAP editors. 2. Start the LDAP editor according to the provider's instructions. 3. Configure a new connection in the LDAP editor. Depending on the editor, you may need to enter the following values: 58 OpenText Web Experience Management Administration Guide

59 4.3. Administering Embedded LDAP a. Set the Host field to local_ host_name. b. Set the Port field to the Administration server port number. c. Set the Version field to 3. d. Set the Base DN field to dc=vgndomain. e. Uncheck the Anonymous Bind option. f. Set theuser DN field to cn=admin. g. Set the Password field to the password to the Credentials you specified in the Changing the Embedded LDAP Credentials on page Click the new connection. 5. Use the LDAP editor to navigate the hierarchy of the embedded LDAP server Exporting and Importing Information in the Embedded LDAP Server The Migration tab for the security provider can be used to import or export data from the embedded LDAP server. That tab is reached from the Runtime Services Console: 1. In the left pane under Domain Structure, click Security Realms. 2. In the right pane, click VgnLDAPRealm. 3. Select the Migration tab. Optionally, an LDAP editor can be used to export and import data stored in the embedded LDAP Server. The following table summarizes where data is stored in the hierarchy of the embedded LDAP server. Security Data Users Groups Security Roles Security Policies Embedded LDAP Server DN ou=people,ou=myrealm,dc=mydomain ou=groups,ou=myrealm,dc=mydomain ou=erole,ou=myrealm,dc=mydomain ou=eresource,ou=myrealm,dc=mydomain To export security data from the embedded LDAP server: 1. Start your LDAP editor as described in the provider's documentation and connect to embedded LDAP as described in Viewing Embedded LDAP Server Contents from an LDAP Editor on page Specify the data to be exported (for example, to export users specify ou=people,ou=vgnldaprealm,dc=vgndomain). 3. Select theldif > Export option. 4. SelectExport all children. OpenText Web Experience Management Administration Guide 59

60 Chapter 4 Administering LDAP 5. Specify the name of the file into which the data will be exported. To import security data from the embedded LDAP server: 1. Start your LDAP editor as described in the provider's documentation. 2. Specify the data to be imported (for example, to import users specify ou=people,ou=<myrealm>,dc=<mydomain>). 3. Select the LDIF > Import option. 4. Select Update/Add. 5. Specify the name of the file from which the data will be imported Managing Users and Groups The embedded LDAP component provides a default security realm, VgnLDAPRealm, through which you can manage users and groups. By default, VgnLDAPRealm includes an Administrators group. The WEM administrator that was created during the WEM installation and setup is a member of the Administrators group. (For more information, refer to the OpenText Web Experience Management - Planning and Installation Guide (WCMGT-IGD).) This section discusses how to define and manage users and groups using the Runtime Services Console. For convenience, you can add users and groups using the Runtime Services Console GUI; however, once you add a user to the repository and add that user to a group, you must also use an external LDAP editor to add the following: After creating a new user to the embedded LDAP repository, you must use your LDAP editor to add mail, first name, and last name attributes the new user's UID. After adding a user to a new group, you must add a uniquemember attribute to the group to which you have added the user. The following procedures include instructions for completing these tasks. To add a user: 1. Under Domain Structure in the left pane, click Security Realms. 2. In the right pane, click VgnLDAPRealm. 3. Select the Users and Groups tab, then select its Users sub-tab. A table displaying the names of all defined users appears. 4. Click New. The pane for configuring a new user opens. 5. Enter the name of the user. The name that you enter in this field is reflected as UID in an external LDAP editor. 6. Enter a password for the user. The minimum password length for a user is 8 characters. 60 OpenText Web Experience Management Administration Guide

61 4.3. Administering Embedded LDAP 7. Re-enter the password for the user in the Confirm Password field. 8. ClickOK to add the new user. Note: For more efficient management, OpenText recommends adding users to groups. To add name and mail attributes for the new user: Important You must complete this procedure in order for your users to have first name, last name, and attributes, which is required for notifications in the Content Suite. 1. Start your external LDAP editor and connect to the embedded LDAP repository. 2. Expand ou=vgnldaprealm >ou=people and locate the user you just added. For example, if you added bill, you would select uid=bill. 3. Select the add attribute option according to your editor's instructions. All added attributes must be of type string. 4. Add the following attributes to the selected user. sn (surname) givenname (first name) mail ( address) 5. Save changes according to your editor's instructions. Note: If the new user is logged in at the time you make these changes, the changes will not take effect for up to 10 minutes, which is the default value for the REFRESH_CACHE_INTERVAL configuration variable. You can change this value if you require a shorter time period. See Creating, Changing, or Deleting Configuration Variables on page 175 To change a user's password: Note: The minimum password length for is 8 characters. 1. Under Domain Structure in the left pane of the Runtime Services Console, click Security Realms. 2. In the right pane, click VgnLDAPRealm. 3. Click the Users and Groups tab, and then click its Users sub-tab. 4. Click the name of the user for which you want to change the password. 5. Click the Passwords tab. OpenText Web Experience Management Administration Guide 61

62 Chapter 4 Administering LDAP 6. Enter and confirm the new password. 7. Click Save. To delete a user: 1. Under Domain Structure in the left pane of the Runtime Services Console, click Security Realms. 2. In the right pane, click VgnLDAPRealm. 3. Click the Users and Groups tab, and then click its Users sub-tab. The Users table appears, listing the names of all defined users. 4. To delete a user, select the check box next to the user's name, then click Delete. 5. Click Yes to confirm the deletion. To add a group: Note: Group names must be unique. OpenText recommends using initial capitalization and plural names for groups; for example, Administrators. 1. Under Domain Structure in the left pane of the Runtime Services Console, click Security Realms. 2. In the right pane, click VgnLDAPRealm. 3. Click the Users and Groups tab, and then click its Groups subtab. The Groups table appears, listing the names of all defined groups. 4. Click New. The pane for configuring a new group opens. 5. Enter the name of the group, and if desired, a short description of the group (for example, Product Managers). 6. ClickOK to save your changes. To add existing groups to a group: 1. From the Groups tab, click the name of the group you want to add as a member of another group. The Settings for <groupname> pane appears. 2. Click the Membership tab. All available groups appear in the Available list under Parent Groups. All the parent groups to which <groupname> belongs appear in thechosen list. 3. To add <groupname> to another group, highlight the desired parent group name in the Available list and click the right arrow to move the parent group name to the Chosen list. 4. ClickSave. 62 OpenText Web Experience Management Administration Guide

63 4.3. Administering Embedded LDAP To add a user to a group: 1. Under Domain Structure in the left pane of the Runtime Services Console, click Security Realms. 2. Click VgnLDAPRealm. 3. Click theusers and Groups tab, and then its Users sub-tab. A table displaying the names of all users defined in VgnLDAPRealm appears. 4. Click the name of a user. The main window for configuring the user appears. 5. Click the Groups tab. 6. In the Parent Groups list box, click the name of a group to highlight it. 7. Click the right arrow to move the group to the Current Groups list box. 8. If required, repeat Step 6 and Step 7 on page 63 to add the user to multiple groups. 9. Click Save. Important After adding this user to an embedded LDAP group, you must use the LDAP editor to add a uniquemember attribute for the new user to that group. Use the following procedure to complete this task: To add a unique Member attribute to a group: 1. Start an external LDAP editor and connect to the embedded LDAP repository according to your editor's instructions and the instructions outlined in Viewing Embedded LDAP Server Contents from an LDAP Editor on page Expand ou=vgnldaprealm > ou=groups and locate the group to which you have just added the user in the Runtime Services Console. For example, if you just added bill to the Administrators group, you would selectcn=administrators. 3. Add a uniquemember attribute for the new user to the group using your editor's instructions. For example, uid=bill,ou=people,ou=vgnldaprealm,dc=vgndomain. Note: Users who are logged in when you change their LDAP settings may have to wait up to ten minutes before their login session recognizes those changes. This is because the Content Management Server caches their LDAP information when they log in, and waits for ten minutes before refreshing that cached information. If such waits are unacceptable, you can change the refresh cache interval to a lower value by modifying the REFRESH_CACHE_INTERVAL configuration variable. For information about changing the value of a configuration variable, see Creating, Changing, or Deleting Configuration Variables on page 175. OpenText Web Experience Management Administration Guide 63

64 Chapter 4 Administering LDAP To remove a user from a group: 1. Start your LDAP editor and connect to embedded LDAP. 2. Expand ou=vgnldaprealm> ou=groups and locate the group from which you want to remove the user. 3. Locate and remove the uniquemember entry for the user you want to remove. 4. Save your changes. Note: Users who are logged in when you change their LDAP settings may have to wait up to ten minutes before their login session recognizes those changes. This is because the Content Management Server caches their LDAP information when they log in, and waits for ten minutes before refreshing that cached information. If such waits are unacceptable, you can change the refresh cache interval to a lower value by modifying the REFRESH_CACHE_INTERVAL configuration variable. For information about changing the value of a configuration variable, see Creating, Changing, or Deleting Configuration Variables on page 175. To delete a group: 1. Under Domain Structure in the left pane of the Runtime Services Console, click Security Realms. 2. Click VgnLDAPRealm. 3. Click the Users and Groups tab, and then click its Groups sub-tab. A table appears, displaying the names of all groups that exist in VgnLDAPRealm. 4. To delete a group, check the box next to the name of the group to be deleted, then click Delete. 5. Click Yes to confirm the deletion. 4.4 Administering WEM for External LDAP This topic discusses configuration and user/group management tasks required to administer the WEM software for use with an external LDAP repository (including when changes are made to that repository). Most changes you make to your external LDAP repository after you have installed and set up your WEM configuration are recognized automatically by the configuration. Note: Users who are logged in when you change their LDAP settings may have to wait up to ten minutes before their login session recognizes those changes. This is because the Content Management Server caches their LDAP information when they log in, and waits for ten minutes before refreshing that cached information. If such waits are unacceptable, you can change the refresh cache interval to a lower value by modifying the REFRESH_CACHE_INTERVAL 64 OpenText Web Experience Management Administration Guide

65 4.4. Administering WEM for External LDAP configuration variable. For information about changing the value of a configuration variable, see Creating, Changing, or Deleting Configuration Variables on page Managing Users and Groups You can change any of the following in your external LDAP repository, and your changes will be recognized automatically (given the caveat in the preceding note): Add or delete users and groups Note: Before you remove a user or group from your external LDAP repository, be sure that you first remove all WEM roles associated with that user or group. If you do not, and later, if you create a new user or group using the deleted user/group's name, the new user/group automatically inherits the roles that were associated with the deleted user/group. User and/or group organizational units (OUs) You can modify, add, or delete these. Note: The Configuration Console lets you specify nine OUs for users and nine for groups. If you require additional OUs, you must configure the Configuration database manually to recognize the additional OU's. In addition, you can change the following from the Runtime Services Console: User and/or group scope User and/or group filters Changing Repository-Specific Information If you want to change anything concerning your external LDAP repository, such as the host name, port number, DN, password, and so on, you must perform the following steps: Note: If changing your external LDAP repository's password, be sure to perform all the steps in this section before changing the actual password in the repository. 1. If switching LDAP servers, be sure that all WEM users, groups, and group memberships in the old LDAP server exist in the new server. 2. Input the new information in the Runtime Services Console. 3. Using the Configuration Console, update the LDAP_PROPERTIES and LDAP_PASSWORD configuration variables, which are located at: Configuration Console > Subcomponents > Authorization > OpenText Web Experience Management Administration Guide 65

66 Chapter 4 Administering LDAP 4. Stop the following components/servers in the order shown: a. Configuration Agent b. Content Management Server c. Node Manager d. Administration Server 5. Start the following components/servers in the order shown: a. Administration Server b. Node Manager c. Content Management Server d. Configuration Agent Note: For more information about your external LDAP repository and its client tool(s), see your vendor's documentation Changing the LDAP Connection Pool Timeout The WEM maintains an LDAP connection pool for use in communication between the Content Management Server and an external LDAP repository. That connection pool exists for the number of milliseconds specified in the LDAP_CONN_POOL_TIMEOUT configuration variable. Each time the LDAP connection pool is accessed, the clock is reset to 0, which keeps the current connection pool active for another LDAP_CONN_POOL_TIMEOUT milliseconds. However, if the connection pool is not accessed within that number of milliseconds, the next time that the WEM accesses the pool, it destroys that pool and creates a new one. In certain situations, you may need to change the default LDAP connection pool timeout value. For example, consider a configuration that has a firewall between the Content Management Server and an LDAP repository. If the firewall times out its connections, it corrupts the existing LDAP connections in the pool, which can create an unacceptable delay before communication is restored. To avoid this type of problem, decrease the value of the LDAP_CONN_POOL_TIMEOUT configuration variable so that it is less than the firewall's timeout value. Doing so causes the LDAP connection pool to be replaced in a more timely fashion in relation to the firewall timeout. The LDAP_CONN_POOL_TIMEOUT configuration variable is located in the following node of the configuration tree: Configuration Console > Subcomponents > Authorization > The configuration variable's default value is 900,000 milliseconds (15 minutes). For information about changing the value of a configuration variable, see Creating, Changing, or Deleting Configuration Variables on page OpenText Web Experience Management Administration Guide

67 4.4. Administering WEM for External LDAP Enabling SSL LDAP Server Authentication This paragraph discusses how to use a Certificate Authority to enable the WEM software to communicate with an SSL-enabled external LDAP repository. Note: Although not documented here, another way to enable SSL LDAP server authentication would be to create a set of self-signed Java keystores that could be used for the Content Management Server and the external LDAP repository. You could implement this solution using OpenSSL or similar software Using a Certificate Authority The high-level steps for using a Certificate Authority to enable the WEM software to communicate with an SSL-enabled external LDAP repository are as follows: 1. Create an Identity keystore. 2. Generate a certificate request. 3. Submit the request to a Certificate Authority. The Certificate Authority, for a fee, returns a signed certificate and its own Trusted certificate. 4. When you receive the signed certificate, import it into your Identity keystore. 5. Create a Trust keystore using the Certificate Authority's Trusted certificate. 6. Modify the appropriate WEM configuration variables to point the WEM product to your new keystores. 7. Modify the settings in the Runtime Services Console to point to the new keystores. 8. Optionally, update your Node Manager properties file with your new keystore information. This is considered a best practice. 9. Stop and restart the appropriate WEM servers. If you have a previously existing LDAP repository, you may have already performed some of these steps. If so, skip whichever steps you have already performed. For example, if you already have a certificate and have imported it into your Identity keystore, you can skip those steps. The following paragraphs discuss how to accomplish certain of the preceding steps using keytool, a command line utility that is shipped with the WEM software. You may use any tool that lets you perform the same functions. Documentation for the keytool utility is available at the Sun Microsystems Java site. For example: keytool.html The keytool utility is located in the following directory: <WEMinstallDir>/Content/10_5/java/jre/bin OpenText Web Experience Management Administration Guide 67

68 Chapter 4 Administering LDAP Note: When running a keytool command, be sure to run it from the preceding directory or call it with a fully-qualified path. To create an identity keystore: 1. Run keystore -genkey, specifying your own values for the path to the new keystore, its type of encryption, and so on. For example: keytool -genkey -keystore c:\newldap\myidentity.jks -storetype JKS - keypass "IdenK3y" -storepass "Ident$t0r3" -keysize alias myvgn -validity 365 -keyalg RSA Standard types of encryption are supported. 2. Supply values as requested by the genkey prompts (name, organization, and so on). 3. Proceed to the next paragraph. To generate a certificate request: 1. Run keytool -certreq to generate a certificate request, specifying your Identity keystore as input. For example: keytool -certreq -alias myvgn -keystore c:\newldap\myidentity.jks - toretype JKS -storepass "Ident$t0r3" -keypass "IdenK3y" -file c: \NewLDAP\MyIdentity.csr 2. Proceed to the next paragraph. To obtain a signed certificate: 1. Give the generated certificate request to a Certificate Authority of your choosing (for example, Verisign or Thawte). 2. When the Certificate Authority returns the signed Identity certificate, save it to a file; for example: C:\NewLDAP\MyIdentity.cer 3. Proceed to the next paragraph. To import the signed certification into the identity keystore: 1. Get a copy of the Certificate Authority's trusted certificate and save it to a file. For example: C:\NewLDAP\CATrust.cer 2. Import the Certificate Authority's trusted certificate into your Identity keystore. (This is required so that the keytool utility will trust the certificate you will import in the next step.) For example: keytool -import -file C:\NewLDAP\CATrust.cer -keystore C:\NewLDAP \MyIdentity.jks -keypass "IdenK3y" -storepass "Ident$t0r3" - storetype JKS -trustcacerts -alias myvgntrusted 68 OpenText Web Experience Management Administration Guide

69 4.4. Administering WEM for External LDAP 3. Import the signed certificate that you received from your Certificate Authority (for example, MyIdentity.cer) into your Identity keystore: keytool -import -file C:\NewLDAP\MyIdentity.cer -alias myvgn - keystorec:\newldap\myidentity.jks -keypass "IdenK3y" - storepass"ident$t0r3" -storetype JKS 4. Delete the Certificate Authority's trusted certificate. (You no longer need it because it also resides inside the signed certificate you imported in the preceding step.) For example: keytool -delete -alias myvgntrusted -keystore C:\NewLDAP \MyIdentity.jks -storetype JKS -storepass "Ident$t0r3" 5. Proceed to the next paragraph. To create the trust keystore with the Certificate Authority s trusted certificate: 1. Run keytool -import to create your Trust keystore, and at the same time, import your Certificate Authority's trusted certificate into that Trust keystore. For example: keytool -import -file C:\NewLDAP\CATrust.cer -keystore C:\NewLDAP \MyTrust.jks -keypass "Tru$tK3y" -storepass "Tru$t$t0r3" -storetype JKS -trustcacerts -alias myvgntrust 2. Proceed to the next paragraph. To modify the WEM Configuration Variables: 1. Log into the Configuration Console using the existing WEM admin's password. 2. Go to the following location in the configuration tree: Configuration Console > Subcomponents > Authorization > 3. Change the value of the ENABLE_SSL configuration variable to true, and click Save. 4. Change the server.port setting in the LDAP_PROPERTIES configuration variable so that it points to the secure LDAP port. If you do not know which port number that is, ask your LDAP administrator. Note: Do not replace the entire contents of the LDAP_PROPERTIES variable. Only change the value associated with the server.port keyword. 5. Go to the following location in the configuration tree: Configuration Console > Subcomponents > Authorization > SSL > OpenText Web Experience Management Administration Guide 69

70 Chapter 4 Administering LDAP 6. Change the value of the any of the following configuration variables as needed to point the WEM product to your new SSL information. Click Save for each value you change. KEY_PASSWORD KEY_STORE_FILE KEY_STORE_PASSWORD KEY_STORE_TYPE KEY_MGR_ALGORITHM TRUST_STORE_FILE TRUST_STORE_PASSWORD TRUST_STORE_TYPE TRUST_MGR_ALGORITHM 7. Push or commit your changes. See Testing Variable Changes on page If prompted to do so, restart the Configuration Agent. However, do not restart the Content Management Server at this point. 9. Proceed to the next paragraph. To modify the Runtime Services settings: 1. Log into the Runtime Services Administration Console as the WEM administrator. 2. In the Change Center at the top of the left pane, click Lock & Edit. 3. In the Domain Structure area of the left pane, click Security Realms. 4. In the right pane, under Summary of Security Realms, click VgnLDAPRealm. 5. In the right pane, under Settings for VgnLDAPRealm, click the Providers tab. 6. If it is not already selected, click the Authentication sub-tab. 7. In the list of Authentication Providers, click on the authenticator for your configuration, for example, with a Sun Java System Server, that would be OpenLDAPAuthenticator. 8. Click the Provider Specific sub-tab for the OpenLDAPAuthenticator. 9. Scroll through the list of configuration values that appears, and: a. Change the port to your secure port. b. Check the SSL Enabled box. c. Click Save. 10. In the left pane, under the Change Center, click Activate Changes. 70 OpenText Web Experience Management Administration Guide

71 4.4. Administering WEM for External LDAP 11. If you changed the name and/or type of either the identity key store or the trust key store files, perform the following substeps: a. Under Change Center at the top of the left pane, click Lock & Edit. b. Under Domain Structure in the left pane, expand to the Servers level; for example: c. Click VgnAdminServer (admin). d. Click the Keystores tab, and change the values in the Settings pane to point to your new LDAP configuration: e. Click Save. f. Click the SSL tab, and change the values in the Settings pane to reflect the values for your new LDAP configuration. g. Click Save. h. In the left pane, under the Change Center, click Activate Changes. OpenText Web Experience Management Administration Guide 71

72 Chapter 4 Administering LDAP 12. Repeat all of Step 11 on page 71 for the VgnVCMServer: 13. If you have a management-side cluster, perform the same substeps (all of Step 11 on page 71) for all other managed servers: VgnVCM2, VgnVCM3, and so on. 14. Proceed to the next paragraph. To update the Node Manager properties file: 1. Open the nodemanager.properties file, which is located in the following directory: <WEMinstallDir>/Content/10_5/rtsvcs/nodemanager/ 2. In that file, change the values in the following name-value pairs to contain your new LDAP information: CustomIdentityAlias=<value> For example, set <value> to myvgn. CustomTrustKeyStoreFileName=<value> Set <value> to where your Trust Keystore is located (relative to the nodemanager directory). For example if your Trust Keystore is C:\NewLDAP \MyTrust.jks, <value> would be:../../../../../../newldap/mytrust.jks CustomIdentityKeyStoreFileName=<value> Set <value> to where your Identity Keystore is located (relative to the nodemanager directory). For example if your Identity Keystore is C: \NewLDAP\MyIdentity.jks, <value> would be:../../../../../../ NewLDAP/MyIdentity.jks CustomIdentityPrivateKeyPassPhrase=<value> Set <value> to the password for your Identity keystore. As you type it, the password appears in plain text; however, Runtime Services will encrypt it automatically. For example: IdenK3y CustomTrustKeyStorePassPhrase=<value> Set <value> to the password for your Trust keystore. As you type it, the password appears in plain text; however, Runtime Services will encrypt it automatically. For example: Tru$t$t0r3 CustomIdentityKeyStorePassPhrase=<value> Set <value> to the password for your Identity keystore. As you type it, the password appears in plain text; however, Runtime Services will encrypt it automatically. For example: Ident$t0r3 3. Proceed to the next paragraph. To stop and restart the Content Management Servers: 1. Stop the following WEM components in the order shown below. For information about stopping these components or a management-side cluster, see Manually Starting and Stopping Server-Related Processes on page OpenText Web Experience Management Administration Guide

73 4.4. Administering WEM for External LDAP a. If the Content Management Server (VgnVCMServer) is still running, stop it. If you have a management-side cluster, stop the entire cluster. b. The Runtime Services Node Manager. c. The Runtime Services Administration Server. 2. Start the following WEM components in the order shown below. For information about starting these components or a management-side cluster, see Manually Starting and Stopping Server-Related Processes on page 32. a. The Runtime Services Administration Server. b. The Runtime Services Node Manager. c. The Content Management Server (VgnVCMServer), or if running a management-side cluster, the entire cluster. If the Runtime Services Console does not start, your settings may be incorrect. To begin troubleshooting, look in the VgnAdminServer.log file; for example: C:\OpenText\WEM\Content\10_5\rtsvcs\domains\ vgndomain\servers\vgnadminserver\logs\vgnadminserver.log 3. Proceed to the next paragraph Verifying that the Content Management Server is Communicating via SSL Generally, if you open the Management Console, and it opens properly (all tabs visible), you can be fairly certain that your Content Management Server is now communicating with the LDAP repository using the SSL protocol. To be absolutely certain, though, perform the following steps: 1. Open your Content Management Server runtime log file. That file is located in a subdirectory under your working directory; for example: <WEMinstallDir>/vcm/inst-vgninst/logs/VgnVCM1-runtime.<x>.log 2. Search the file for the following string: LDAPConnection. You should find a line in the log similar to the following. In that line you should see the name of your LDAP server host and its secure port (as shown in boldface): :05:04,351 DEBUG uthz.server.impl.ldaprealmimpl releaseconnection() LDAPConnection {ldaps://myldap1.example.com: 7475 ldapversion:2 binddn:"uid=admin,ou=administrators,ou=topologymanagement, o=netscaperoot"}: Releasing LDAP connection [ExecuteThread: '19' for queue: 'weblogic.kernel.default'] [] OpenText Web Experience Management Administration Guide 73

74 Chapter 4 Administering LDAP Adding Nodes to a Management-Side Cluster If, after you have established SSL communication between your external LDAP repository and the Content Management Server, you add one or more nodes to a management-side cluster, you must modify the appropriate WEM configuration variables on each new node. See the preceding paragraph for more information. 4.5 Migrating from One LDAP Server to Another This section tells how to migrate from one type of LDAP server to another, including migrating from the WEM embedded LDAP server to an external LDAP repository. Before beginning the migration, be sure that the following prerequisites have been fulfilled: The target LDAP server contains all of the users and groups that are in your current LDAP server. The user name and password for the LDAP administrator is the same for your current LDAP server and for the target LDAP server. If they are not, change the name and password on the target server to match those on your current server, and do so before going any further in this section. Your target LDAP server has an Administrators group, and your WEM administrator's login name is a member of that group. To migrate from one LDAP server to another: 1. Back up the following items, in case you encounter problems with the migration: Your WEM database(s) Configuration files, specifically: cfs.cfg This file contains the authorization subcomponent that has the LDAP variables and is located in the following directory: <WEMinstallDir>/vcm/inst-vgninst/conf/ config.xml This file contains the LDAP configuration for Runtime Services and is located in the following directory: <WEMinstallDir>/ Content/10_5/rtsvcs/domains/vgndomain/config 2. In a command line window, change to the following directory: <WEMinstallDir>/Content/10_5/bin 3. Run the cfgedit utility, and connect to your Content Management Server: cfgedit -h <host>:<port> -u <vadminname> -p <vadminpwd> where <host> and <port> are the host name and port number of your Content Management Server, <vadminname> and <vadminpwd> are your WEM administrator's user name and password. 74 OpenText Web Experience Management Administration Guide

75 4.5. Migrating from One LDAP Server to Another 4. In cfgedit, navigate to the following level in your configuration. For example: cd /cs/cfs 5. Create the LDAP_SERVER_TYPE variable and supply it a value by using cfgedit's set command as follows: create LDAP_SERVER_TYPE <ldaptype> where <ldaptype> is one of these values: ldap.embedded ldap.activedirectory ldap.nds ldap.netscape ldap.secureway 6. While still in cfgedit, navigate to /cs/cfs/auth. 7. Run the following command: get -r LDAP_PROPERTIES 8. Copy the output of the preceding command and paste it into a temporary text file. Note: If it does not have one, add a blank line to the end of the text file. 9. Using a text editor, modify the properties in the temporary text file to the desired values for your target LDAP server. For example, to change which user will connect to the new server, set the value of the server.principal property. Modify all properties that are different for your new server. The best way to determine the correct value for that entry is to export it from another system that is using the same version of LDAP you are migrating to. Otherwise, refer to the documentation for that LDAP server. 10. Save the temporary text file, then import it back into the LDAP_PROPERTIES configuration variable as follows: set -f <tmptxtfile> /cs/cfs/auth/ldap_properties where <tmptxtfile> is the path to your temporary text file; for example: For example, /tmp/ldapprops or C:\TEMP\ldapprops.txt. 11. If necessary, set the USER_ID_ATTRIBUTE variable to a value appropriate for the attribute required by your external repository. The variable, located at the same level in the configuration tree (/cs/cfs/auth), is set to uid by default. Attributes used by various repositories include: cn, samaccountname, uid, and userprinciplename. For example: set USER_ID_ATTRIBUTE cn OpenText Web Experience Management Administration Guide 75

76 Chapter 4 Administering LDAP 12. Run the following cfgedit command to commit your changes: commit 13. In the Runtime Services Administration Console, navigate to the following location: vgndomain > Security Realms 14. Under Change Center at the top of the right pane, click Lock & Edit. 15. In the right pane, click VgnLDAPRealm. 16. Click the Providers tab. 17. Click the Authentication sub-tab. 18. Under Authentication Providers, click New. 19. Specify a name and the provider type as prompted. 20. Click Save. You are returned to the Authorization Providers pane. Your new provider should be listed there. 21. Click the name of your new provider. 22. Click the Provider Specific sub-tab. 23. Update the list of configuration values with the information required for accessing your target LDAP server. A subset of things you must change includes, but is not limited to: The Principal field Requires the value of the entrydn, as found in your LDAP client's console. For example: uid=myldapadmin,ou=administrators,ou=topologymanagement,o=nets caperoot The Credential field Requires the password or other information that authenticates the user identified in the preceding bullet. The Confirm Credential field Requires the same value as in the preceding bullet. The User Base DN field Requires the user name for accessing your target LDAP server. The Group Base DN field Requires the group name for accessing your target LDAP server. 24. Click Save. Note: Under all tabs, clear any field that contains Dynamic values. Dynamic values include dynamic groups and users. Like other dynamic values, these are not supported. Failure to clear all fields containing dynamic values can lead to unpredictable behavior. 76 OpenText Web Experience Management Administration Guide

77 4.5. Migrating from One LDAP Server to Another 25. In the left pane, under the Change Center, click Activate Changes. 26. Verify that you can see the users in the new LDAP Server: a. From the Domain Structure box in the left pane of the Runtime Services Console, click Security Realms. b. In the right pane, click VgnLDAPRealm. c. Click the Users and Groups tab and then click its Users sub-tab. The users should appear in the user list there. 27. From the list of users, click the name of your LDAP administrator, then click the Groups tab on the resulting page. 28. If it is not already there, add the Administrators group to the Chosen field and click Save. 29. Delete your old LDAP Authentication Provider. 30. Restart the Runtime Services Administration Server and the Content Management Server. For details, see Manually Starting and Stopping Server- Related Processes on page Log into the Management Console, and make sure that all menus are present and active. At this point, your migration should be complete. If, later, you make changes to the external LDAP repository, you may need to update the Content Management Server. See Administering WEM for External LDAP on page 64. OpenText Web Experience Management Administration Guide 77

78

79 Chapter 5 Integrations with OpenText Application Infrastructure The following integrations with OpenText Application Infrastructure are available for your Web Experience Management environment: OpenText Directory Services (OTDS), which allows you to use the single sign-on capability to sign into WEM and other OTDS configured applications such as OpenText Portal and OpenText Tempo Social. InfoFusion Search, which allows you to search across different repositories. 5.1 Integrating OpenText Directory Services with Web Experience Management The integration between WEM and OpenText Directory Services (OTDS) allows identity synchronization and single sign (SSO) between all OpenText components. If you are using an existing LDAP server for WEM development, you can easily configure OTDS to use it. For OTDS installation instructions, see OpenText Directory Services - Installation and Administration Guide - Using the OpenText Administration Client (OTDS-IGD). For OTDS configuration instructions with WEM, see OpenText Web Experience Management - Planning and Installation Guide (WCMGT-IGD). The integration between WEM and InfoFusion Search provides search services. Your Management stage must contain a configured search engine. As of version 10.5, Web Experience Management supports both Apache Solr, version and OpenText InfoFusion, version 10.4 (which includes Solr 4.6). While the search engine can be installed at any time, it is preferable to install it prior to running the WEM installer. For InfoFusion Search installation and configuration instructions, see OpenText Web Experience Management - Planning and Installation Guide (WCMGT-IGD). OpenText Web Experience Management Administration Guide 79

80

81 Chapter 6 Management-Side Clustering This topic provides conceptual information and administrative instructions about management-side clustering. 6.1 Introduction A WEM management-side cluster consists of multiple instances of the vgnvcmserver managed server running simultaneously and working together to provide increased reliability. The management-side cluster appears to clients to be a single instance of vgnvcmserver. The vgnvcmserver instances that constitute a management-side cluster run on different machines (horizontal clustering). You can increase the cluster's capacity by adding machines to the cluster and installing instances of vgnvcmserver on those new machines What Are the Benefits of Clustering? A management-side cluster provides these benefits: High-Availability In a management-side cluster, vgnvcmserver can continue processing even when one of its instances fails. Failover If an instance of vgnvcmserver fails while processing content, another instance can finish processing that content. Scalability The capacity of the vgnvcmserver managed server can be increased, depending on load and usage patterns What Are the Key Capabilities of a Management-Side Cluster? The key management-side clustering capabilities that enable high availability and scalability are as follows: Load Balancing Load balancing is the even distribution of content-management tasks and associated communications across the computing and networking resources in your environment. For load balancing to occur in a management-side cluster: There must be multiple vgnvcmserver instances that can do a particular content-management task. Information about the location and operational status of all vgnvcmserver instances must be available. Management-side clustering shares and maintains the availability and location of vgnvcmserver instances using multicast, IP sockets, and JNDI. OpenText Web Experience Management Administration Guide 81

82 Chapter 6 Management-Side Clustering Failover When a vgnvcmserver instance doing a particular content-management task becomes unavailable for any reason, one of the other vgnvcmserver instances can complete the task (depending on when the failure occurred in the task's life cycle). Management-side clustering is based on standards-based communication techniques and facilities multicast, IP sockets, and the Java Naming and Directory Interface (JNDI) to share and maintain information about the availability of vgnvcmserver instances in a cluster. These techniques allow a management-side cluster to determine that a vgnvcmserver instance stopped before finishing its content-management task, and where there is another vgnvcmserver instance to complete the task that was interrupted. Information about what has been done on a content-management task is called state. A management-side cluster maintains information about state using techniques called session replication and replica-aware stubs. When a particular object unexpectedly stops doing its task, replication techniques enable a copy of the object pick up where the failed object stopped, and finish the task Where Components Reside in a Management-Side Cluster When you create a management-side cluster, the host on which you first installed the WEM software contains the following items: The Administrative Console for Runtime Services (VgnAdminServer) A Configuration Agent A Deployment Agent for the Management stage. Runtime Services HttpClusterServlet (the proxy servlet, which is located within the VgnAdminServer) This host also contains the Management stage. The first vgnvcmserver instance installed becomes the Administration node of your cluster. That instance contains the VgnVCMServer managed server, Application Services, the EAR files associated with those services, and the Report Manager. The WEM software clones the Administration node's instance of vgnvcmserver and places a cloned instance on each subsequent node of the cluster. Each node therefore has an instance of the Content Management Server, Application Services, and so on, all cloned from the Administration node. For information about creating a horizontal cluster, see the OpenText Web Experience Management - Planning and Installation Guide (WCMGT-IGD). 82 OpenText Web Experience Management Administration Guide

83 6.2. Configuration Tools and Management-Side Clustering 6.2 Configuration Tools and Management-Side Clustering Configuration tools, such as the Configuration Console, the configp utility, and the Open Text Web Experience Management Workflow Modeler are not cluster-aware; however, the behavior of these tools is affected by the presence of a managementside cluster, as discussed in the following paragraphs Connecting to the Content Management Server When running the Configuration Console, configp, or the Open Text Web Experience Management Workflow Modeler, you can connect to the Content Management Server using either a DNS round-robin address for the management-side cluster or the <host>:<port> address of a particular node (where <host> is either the name of the host or its IP address, and <port> is the port number of the Content Management Server). Using a DNS round-robin address is preferable, especially in situations where the node you are connected to fails. The following paragraphs discuss both methods of connecting to the Content Management Server from a client tool DNS Round-Robin Connections If you have connected to the Configuration Console or the Open Text Web Experience Management Workflow Modeler using a DNS round-robin address, and the node to which you connected goes down, the following steps allow you to reconnect: 1. Close the box warning you that the connection has been lost. 2. Reconnect, using the same DNS round-robin address you used in your previous session Host Name/IP Address and Port Number Connections If you have connected to the Configuration Console or the Open Text Web Experience Management Workflow Modeler using a host name or IP address and Content Management Server port number, and the node to which you connected goes down, the following steps allow you to reconnect: 1. Close the box warning you that the connection has been lost. 2. Obtain the host name or IP address, and the Content Management Server port for a different node in the cluster. To do so, you can use the Runtime Services Console, or you can ask your WEM administrator. 3. Connect to the node with the new address. OpenText Web Experience Management Administration Guide 83

84 Chapter 6 Management-Side Clustering Obtaining Status in the Configuration Console When you click the Status icon in the Configuration Console, you receive status information from the primary node of the management-side cluster. To obtain status from other nodes: Open a browser and go to the following location: Where: <host> is either the name of the machine containing the node for which you want to obtain status, or its IP address <port> is the port number of the Content Management Server. For example: Load Balancing To load balance the Management Console, you can use the HttpClusterServlet provided as part of the WEM software, or you can use a hardware load-balancing solution. For a production environment, we recommend that you use hardware load balancing. Load balancing hardware provides you much more scalability. The rest of this section describes the load balancing support that Runtime Services provides, and related planning and configuration considerations for architects and administrators HttpClusterServlet and Load Balancing The WEM software uses the HttpClusterServlet as its default method of providing servlet and JSP HTTP session load balancing for the Management Console and its extensions. By default, the servlet uses the round-robin load-balancing algorithm. The HttpClusterServlet is installed automatically in the VgnAdminServer during installation, and there is no need to configure it. When you add a node to your management-side cluster, that node gets added automatically to the dynamic server list so that it joins in almost immediately in servlet and JSP load balancing. The HttpClusterServlet is also configured automatically when a node is added. If a node fails, it is removed automatically from the dynamic server list so that it receives no more load balancing duties. If you are having problems with a node that claims to be up, but is not operable, you can disable the dynamic server list and create your own static list of nodes to handle 84 OpenText Web Experience Management Administration Guide

85 6.3. Load Balancing load balancing. However, there are important drawbacks to disabling the dynamic server list: If one or more servers in your static list fail, HttpClusterServlet can waste time trying to connect to a dead server, resulting in decreased performance. If you add a new server to the cluster, HttpClusterServlet cannot proxy requests to the new server unless you update your static list. To disable the dynamic server list and set up a static list: 1. Edit the following file: <WEMinstallDir>/Content/10_5/deployedApps/ProxyWebApp.war/ WEB-INF/web.xml 2. Make the following changes to the file: a. Set the value of DynamicServerList to false: <init-param> <param-name>dynamicserverlist</param-name> <param-value>false</param-value> </init-param> b. Create a static list of nodes in the cluster by setting the value of WebLogicCluster to a comma-separated list of those nodes. Each node must be specified as a <host>:<port> value; for example: <init-param> <param-name>weblogiccluster</param-name> <param-value> myserver1:27110,myserver2:27110,myserver4:27110 </param-value> </init-param> 3. Save your changes. 4. Log into the Runtime Services Console. 5. Click Lock & Edit. 6. Under vgndomain > Deployments, select the ProxyWebApp web application module. 7. Click Update and then Finish to redeploy the application. 8. Click Activate Changes. OpenText Web Experience Management Administration Guide 85

86 Chapter 6 Management-Side Clustering 9. Click Release Configuration Hardware Load Balancing You can also load balance the servlets and JSPs used by the Management Console and its extensions by using separate load balancing hardware. Using a hardware load balancer directly with the management-side cluster provides several benefits over using HttpClusterServlet. First, using a load balancer requires no additional administration for client setup you do not need to set up and maintain a separate layer of HTTP servers. Using load balancing hardware provides more flexibility for defining load balancing algorithms that suit the capabilities of your system. You can use any load balancing strategy (for example, load-based policies) that your load balancing hardware supports. With the HttpClusterServlet, you are limited to a simple round-robin algorithm for clustered servlet requests. However, because the Management Console uses in-memory session state replication, using a third-party load balancer requires additional configuration. In this case, you must ensure that the load balancer maintains a sticky connection (affinity) between the client and its point-of-contact server, so that the client accesses the primary session state information. Additionally, a hardware load balancer must understand the structure of the cookies used by Runtime Services, as discussed in the following section Load Balancing HTTP Sessions with an External Load Balancer As your users enter information in the Management Console, or move from tab to tab, the data they enter and the navigational steps they take are stored as state information in their current HTTP session. An advantage of using a hardware load balancing solution for these HTTP sessions is that a hardware load balancer can use any load balancing algorithm supported by the hardware including advanced load-based balancing strategies that monitor the utilization of individual machines. Load Balancer Configuration Requirements Your load balancing hardware configuration must support a compatible passive or active cookie persistence mechanism, and SSL persistence. Passive Cookie Persistence Passive cookie persistence enables Runtime Services to write a cookie containing HTTP session parameter information through the load balancer to the client. For information about the session cookie and how a load balancer uses session parameter data to maintain the relationship between the client and the primary node hosting a session state, see Load Balancers and the HTTP Session Cookie on page 87. Active Cookie Persistence Certain active cookie persistence mechanisms can be used with the management-side cluster, provided the load balancer does not 86 OpenText Web Experience Management Administration Guide

87 6.3. Load Balancing modify the session cookie. The management-side cluster does not support active cookie persistence mechanisms that overwrite or modify the session cookie. If the load balancer's active cookie persistence mechanism works by adding its own cookie to the client session, no additional configuration is required to use the load balancer with the management-side cluster. SSL Persistence When SSL persistence is used, the load balancer performs all encryption and decryption of data between clients and the management-side cluster. The load balancer then uses the plain text cookie that Runtime Services inserts on the client to maintain an association between the client and a particular node in the cluster. Load Balancers and the HTTP Session Cookie A load balancer that uses passive cookie persistence uses a string in the session cookie to associate a client with the vgnvcmserver instance hosting its primary HTTP session state. The string uniquely identifies one of the vgnvcmserver instances in the management-side cluster as the primary managed server instance for the session. You must configure the load balancer with the offset and length of the string constant. The correct values for the offset and length depend on the format of the session cookie. The format of a session cookie is: sessionid!primary_server_id!secondary_server_id where: sessionid is a randomly generated identifier of the HTTP session. The length of the value is configured by the IDLength parameter in the <sessiondescriptor> element in the weblogic.xml file for an application. By default, the sessionid length is 52 bytes. primary_server_id and secondary_server_id are 10 character identifiers of the primary and secondary hosts for the session. To configure the load balancer to work with the management-side cluster, use the facilities of the load balancer to define the offset and length of the string constant. Assuming that the Session ID portion of the session cookie is the default length of 52 bytes, on the load balancer, set: String offset to 53 bytes, the default Random Session ID length plus 1 byte for the delimiter character. String length to 10 bytes If your application or environmental requirements dictate that you change the length of the Random Session ID from its default value of 52 bytes, set the string offset on the load balancer accordingly. The string offset must equal the length of the Session ID plus 1 byte for the delimiter character. OpenText Web Experience Management Administration Guide 87

88 Chapter 6 Management-Side Clustering 6.4 Failover and Replication In order for the management-side cluster to provide high availability it must be able to recover from service failures. The following sections describe how vgnvcmserver managed server instances detect failures in a management-side cluster: How vgnvcmserver Detects Failures vgnvcmserver instances in a management-side cluster detect failures of their peer instances by monitoring: Socket connections to a peer server Regular server heartbeat messages Failure Detection Using IP Sockets Runtime Services monitors the use of IP sockets between peer vgnvcmserver instances as an immediate method of detecting failures. If an instance connects to one of its peers in the cluster and begins transmitting data over a socket, an unexpected closure of that socket causes the peer instance to be marked as failed, and its associated services are removed Replication and Failover for Content Management Server Web Applications This section addresses replication and failover for Content Management Server web applications including Content Workspaces, Management Console, and the Configuration Console. The HttpClusterServlet or your load balancing hardware redirects client requests to any available vgnvcmserver instance in the management-side cluster. The cluster itself obtains the replica of the client's HTTP session state from a secondary vgnvcmserver instance in the cluster HTTP Session State Replication To support automatic failover for servlet and JSP HTTP session states, the clustering software replicates the session state in memory. It creates a primary session state on the vgnvcmserver instance to which the client first connects, and a secondary replica on another instance in the cluster. The replica is kept up-to-date so that it may be used if the instance that hosts the servlet fails. The process of copying a session state from one instance to another is called in-memory replication. To utilize in-memory replication for HTTP session states, you must access the management-side cluster using the HttpClusterServlet or load balancing hardware. Your choice of load balancing hardware must support a compatible passive or active cookie persistence mechanism, and SSL persistence. 88 OpenText Web Experience Management Administration Guide

89 6.5. Before You Set Up Management-Side Clustering 6.5 Before You Set Up Management-Side Clustering This section summarizes prerequisite tasks and information for setting up a management-side cluster Determining Your Cluster Architecture Based on the cluster architectures shown in the OpenText Web Experience Management - Planning and Installation Guide (WCMGT-IGD), determine which architecture best suits your needs. Key architectural decisions include: Should your cluster address be specified as a DNS round-robin address or as a comma-separated list of <host>:<port> pairs (one pair for each node in the cluster)? Should you define your Web applications De-Militarized Zone (DMZ) with one or more firewalls? The architecture you choose affects how you set up your management-side cluster. For example, we recommend that you do not use the HttpClusterServlet for load balancing on a production configuration. In that situation you need to implement a third-party load balancer. In addition, the architecture may require that you install or configure other resources, such as HTTP servers Choosing Machines for the Management-Side Cluster Identify the machine or machines that will be part of your management-side cluster throughout this section we refer to such machines as "hosts" and ensure that they have the resources required. Note: By default, the configuration created when you first install the WEM software is a single-node management-side cluster. This basic configuration is useful for demonstration or development environments. Do not use hosts for your management-side cluster if those hosts have dynamically assigned IP addresses. Also, make sure that all of your hosts are on the same subnet Identifying Names and Addresses When configuring the management-side cluster, you supply one of the following forms of addressing information for the cluster and its members: IP addresses and port numbers DNS names and port numbers When you set up the management-side cluster, you must provide location information for: Administration Server and port number OpenText Web Experience Management Administration Guide 89

90 Chapter 6 Management-Side Clustering Managed Servers (such as vgnvcmserver managed servers) and port numbers Multicast location and port number Read the sections that follow for an explanation of the information you must provide, and factors that influence the method you use to identify resources Avoiding Listening Address Problems As you configure the management-side cluster, you can specify address information for the cluster, and the vgnvcmserver managed server instances that comprise it, using either IP addresses or DNS names. For production environments, the use of DNS names is recommended. The use of IP addresses can result in translation errors if clients will connect to the management-side cluster through a firewall. IP addresses can be remapped when connecting through a firewall, which complicates administration and debugging. Therefore, avoid referencing production hosts by an IP address, since that address is likely to change Making Sure that Node Names are Unique Make sure that each node in your management-side cluster has a unique name Identifying the Administration Server Address and Port Identify the DNS name or IP address and Listen Port of the Administration Server you will use for the cluster. The Administration Server is the WebLogic Server instance used to configure and manage all the Managed Servers in its domain. When you start a Managed Server, you identify the host and port of its Administration Server Identifying Managed Server Addresses and Ports Identify the DNS name or IP address of each vgnvcmserver managed server instance planned for the management-side cluster. Each vgnvcmserver instance in the cluster must have a unique combination of address and Listen Port number. 90 OpenText Web Experience Management Administration Guide

91 6.5. Before You Set Up Management-Side Clustering Setting the Cluster Address When you configure a management-side cluster, you define a cluster address that identifies the vgnvcmserver managed server instances in the cluster. The cluster address is used in entity and stateless beans to construct the host name portion of URLs. If the cluster address is not set, EJB handles may not work properly. Cluster Address for a Production Environment In a production environment, specify the cluster address as a DNS name that maps to the IP addresses or DNS names of each vgnvcmserver instance in the management-side cluster. If you do not define the management-side cluster address as a DNS name that maps to the vgnvcmserver instances in the cluster, failover will not work for entity beans and EJB handles. If you define the management-side cluster address as a DNS name, the Listen Ports for the cluster members are not specified in the cluster address it is assumed that each vgnvcmserver instance in the cluster has the same Listen Port number. Because each instance must have a unique combination of address and Listen Port, if a cluster address is a DNS name, each of the instances in the cluster must have: A unique address and The same Listen Port number When clients obtain an initial JNDI context by supplying the cluster DNS name, Runtime Services obtains the list of all addresses that are mapped to the DNS name. This list is cached by each node in the management-side cluster, and new initial context requests are fulfilled using addresses in the cached list with a round-robin algorithm. If a node instance in the cached list is unavailable, it is removed from the list. The address list is refreshed from the DNS service only if the node is unable to reach any address in its cache. Using a cached list of addresses avoids certain problems with relying on DNS round-robin alone. For example, DNS round-robin continues using all addresses that have been mapped to the vgndomain domain name, regardless of whether or not the addresses are reachable. By caching the address list, Runtime Services can remove addresses that are unreachable, so that connection failures are not repeated with new initial context requests. Note: The Administration Server should not participate in a cluster. Ensure that the Administration Server's IP address is not included in the cluster-wide DNS name. Cluster Address for Development and Test Environments Use of a cluster DNS name for the cluster address, recommended for production environments in the previous section, is also recommended for development and test environments. OpenText Web Experience Management Administration Guide 91

92 Chapter 6 Management-Side Clustering Alternatively, you can define the cluster address as a list that contains the DNS name (or IP address) and Listen Port of each node in the management-side cluster, as shown in the examples below: DNSName1:port1,DNSName1:port2,DNSName1:port3 IPaddress1:port1,IPaddress2:port2;IPaddress3:port3 Note: Each cluster member has a unique address and port combination Shared File System Requirements for Management-Side Clusters The nodes in a management-side cluster must have both read and write access to the working directory. In order for nodes to access the working directory, the directory must reside on a shared file system. Note: For more information about the working directory, see Working Directory on page Requirements for Windows In a production environment, for nodes running Windows, you should provide a Universal Naming Convention (UNC) path or a drive letter supplied by a shared file system device one that appears to the operating system as a permanently-mounted disk in order for nodes to access the shared file system. Do not use mapped drives in a production environment. If a user logs off from a node that has a mapped drive for the shared file system, the mappings go away, meaning that the node can no longer access the working directory. Note: We do not recommend using mapped drives in a development environment either; however, you can do so if you are aware that access to the working directory can be lost if a user logs off of a node. Regardless of whether you use a UNC path or a drive letter supplied by a shared file system device, the shared path must be identical on all nodes. For example, if using a shared file system device and the file system path is E:\working, then all nodes should mount the file system as E:\working. 92 OpenText Web Experience Management Administration Guide

93 6.6. Changing the Behavior of the HttpClusterServlet Requirements for UNIX On nodes running UNIX, you can mount the shared file system on each node. If vgnvcmserver is running as root, then when you share or export the file system, you must ensure that its group ownership is set to root and not some other value. The root user is not the same from one system to another. Most of the time a request from root on an external host is treated as a request from anonymous or nobody. You must explicitly define what an external root means to a receiving system. If vgnvcmserver is running as a non-root user and if you use a local version of the / etc/passwd file on the nodes of your management-side cluster, you must ensure that the non-root user has the same UID on all nodes (hosts). Similarly, if local defined groups will be shared between nodes, their GIDs must also match. Make sure that the mounted path is the same on all nodes. For example, if the file system path is /usr/opts/working, then the nodes should mount the file system as /usr/opts/working. 6.6 Changing the Behavior of the HttpClusterServlet You can alter certain behaviors of the HttpClusterServlet. For example, if you suspect that the servlet is not functioning properly, you can turn on debugging. To change how HttpClusterServlet acts, you must change values in the servlet's web.xml file, which defines parameters that specify the location and behavior of HttpClusterServlet. Note: Page page 85 shows an example of how to change web.xml and what to do to get your changes to work. That example shows how to disable the dynamic server list and set up a static list Sample web.xml File Following is an example web.xml file: weblogic-web-app xmlns=" xmlns:j2ee=" xmlns:xsi=" xsi:schemalocation=" j2ee/web-app_2_4.xsd weblogic/920/weblogic-web-app.xsd <?xml version="1.0" encoding="utf-8"?> <weblogic-web-app OpenText Web Experience Management Administration Guide 93

94 Chapter 6 Management-Side Clustering xmlns=" xmlns:j2ee=" xmlns:xsi=" xsi:schemalocation=" java.sun.com/xml/ns/j2ee/web-app_2_4.xsd weblogic/90 <servlet> <servlet-name>httpclusterservlet</servlet-name> <servlet-class> weblogic.servlet.proxy.httpclusterservlet </servlet-class> <init-param> <param-name>weblogiccluster</param-name> <param-value>:27110</param-value> </init-param> <init-param> <param-name>debug</param-name> <param-value>false</param-value> </init-param> <init-param> <param-name>wllogfile</param-name> <param-value>./vgnadminserver/wlproxy.log</param-value> </init-param> <init-param> <param-name>debugconfiginfo</param-name> 94 OpenText Web Experience Management Administration Guide

95 6.6. Changing the Behavior of the HttpClusterServlet <param-value>false</param-value> </init-param> <init-param> <param-name>connecttimeoutsecs</param-name> <param-value>10</param-value> </init-param> <init-param> <param-name>connectretrysecs</param-name> <param-value>2</param-value> </init-param> <init-param> <param-name>secureproxy</param-name> <param-value>false</param-value> </init-param> <init-param> <param-name>wlproxyssl</param-name> <param-value>false</param-value> </init-param> <init-param> <param-name>connecttimeoutsecs</param-name> <param-value>10</param-value> </init-param> <init-param> <param-name>connectretrysecs</param-name> OpenText Web Experience Management Administration Guide 95

96 Chapter 6 Management-Side Clustering <param-value>2</param-value> </init-param> <init-param> <param-name>hungserverrecoversecs</param-name> <param-value>300</param-value> </init-param> <init-param> <param-name>cookiename</param-name> <param-value>jsessionid</param-value> </init-param> <init-param> <param-name>filecaching</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>keepalivesecs</param-name> <param-value>30</param-value> </init-param> <init-param> <param-name>keepaliveenabled</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>dynamicserverlist</param-name> 96 OpenText Web Experience Management Administration Guide

97 6.6. Changing the Behavior of the HttpClusterServlet <param-value>true</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>httpclusterservlet</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>httpclusterservlet</servlet-name> <url-pattern>*.jsp</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>httpclusterservlet</servlet-name> <url-pattern>*.htm</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>httpclusterservlet</servlet-name> <url-pattern>*.html</url-pattern> </servlet-mapping> </web-app> In the example file: The DOCTYPE stanza specifies the DTD used by Runtime Services to validate web.xml. OpenText Web Experience Management Administration Guide 97

98 Chapter 6 Management-Side Clustering The servlet stanza identifies the host name and listen port of each vgnvcmserver managed server instance in the management-side cluster, using the WebLogicCluster parameter. The three servlet-mapping stanzas specify that the servlet will proxy URLs that end in '/', 'htm', 'html', or 'jsp' to the management-side cluster. For parameter definitions see Table 6-1: HttpClusterServlet Deployment Parameters: on page Sample weblogic.xml File This section contains a sample weblogic.xml file. The <context root> deployment parameter is set to /. This makes the HttpClusterServlet the default web application for the proxy server. <web-app version="2.4" xmlns=" xmlns:xsi=" xsi:schemalocation=" java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> <context-root>/</context-root> </weblogic-web-app> HttpClusterServlet Deployment Parameters Key parameters for configuring the behavior of HttpClusterServlet in web.xml are listed in HttpClusterServlet Deployment Parameters: on page 99. For HttpClusterServlet, specify the parameters in web.xml, each in its own <init-param> stanza within the <servlet> stanza of web.xml. For example: <init-param> <param-name>parametername</param-name> <param-value>parametervalue</param-value> </init-param> 98 OpenText Web Experience Management Administration Guide

99 6.6. Changing the Behavior of the HttpClusterServlet Table 6-1: HttpClusterServlet Deployment Parameters: Parameter WebLogicCl uster Usage <init-param> <param-name>weblogiccluster</param-name> <param-value>vserver1:27110 vserver2:27110 </param-value> </init-param> Where vserver1 and vserver2 are the host names of servers in the cluster, and is the port number where the host is listening for HTTP requests. If you are using SSL between the HTTPClusterServlet and the servers, set the port number to the SSL listen port and set the SecureProxy parameter to ON. SecureProx y <init-param> <param-name>secureproxy</param-name> <param-value>parametervalue</param-value> </init-param> Valid values are ON and OFF. If you are using SSL between the HTTPClusterServlet and the servers, set the port number to the SSL listen port and set the SecureProxy parameter to ON. DebugConfi ginfo <init-param> <param-name>debugconfiginfo</param-name> <param-value>parametervalue</param-value> </init-param> Valid values are ON and OFF. If set to ON, you can query the HttpClusterServlet for debugging information by adding a request parameter of? WebLogicBridgeConfig to any request. (Note: There are two underscore ( _ ) characters after the?.) For security reasons, it is recommended that you set the DebugConfigInfo parameter to OFF in a production environment. OpenText Web Experience Management Administration Guide 99

100 Chapter 6 Management-Side Clustering Parameter ConnectRet rysecs Usage Interval in seconds that the servlet will sleep between attempts to connect to a server instance. Assign a value less than ConnectTimeoutSecs. The number of connection attempts the servlet makes before returning an HTTP 503/Service Unavailable response to the client is ConnectTimeoutSecs divided by ConnectRetrySecs. Syntax: <init-param> <param-name>connectretrysecs</param-name> <param-value>parametervalue</param-value> </init-param> ConnectTim eoutsecs Maximum time in seconds that the servlet will attempt to connect to a server instance. Assign a value greater than ConnectRetrySecs. If ConnectTimeoutSecs expires before a successful connection, an HTTP 503/Service Unavailable response is sent to the client. Syntax: <init-param> <param-name>connecttimeoutsecs</param-name> <param-value>parametervalue</param-value> </init-param> 100 OpenText Web Experience Management Administration Guide

101 6.6. Changing the Behavior of the HttpClusterServlet Parameter PathTrim Usage String trimmed by the HttpClusterServlet from the beginning of the original URL, before the request is forwarded to the cluster. Syntax: <init-param> <param-name>pathtrim</param-name> <param-value>parametervalue</param-value> </init-param> Example: If the URL is passed to the HttpClusterServlet for parsing and if PathTrim has been set to /wl the URL forwarded to Runtime Services is: TrimExt The file extension to be trimmed from the end of the URL. Syntax: <init-param> <param-name>trimext</param-name> <param-value>parametervalue</param-value> </init-param> OpenText Web Experience Management Administration Guide 101

102 Chapter 6 Management-Side Clustering Parameter clientcert Proxy Usage Specifies to trust client certificates in the WL-Proxy-Client-Cert header. Valid values are true and false. The default value is false. This setting is useful if user authentication is performed on the proxy server setting clientcertproxy to true causes the proxy server to pass on the certs to the cluster in a special header: WL-Proxy-Client-Cert The WL-Proxy-Client-Cert header can be used by any client with direct access to Runtime Services. Runtime Services never takes the certificate information from that header, trusting that is came from a secure source (the HttpClusterServlet) and uses that information to authenticate the user. For this reason, if you set clientcertproxy to true, use a connection filter to ensure that Runtime Services accepts connections only from the machine on which the HttpClusterServlet is running. PathPrepen d String that the servlet prepends to the original URL, after PathTrim is trimmed, before forwarding the URL to the cluster. <init-param> <param-name>pathprepend</param-name> <param-value>parametervalue</param-value> </init-param> 6.7 Accessing Applications Via the HttpClusterServlet Ensure that applications clients will access via the HttpClusterServlet are deployed to your cluster. Address client requests to the listen address and listen port of the HttpClusterServlet. If you have problems: Make sure all servers instances have unique address/port combinations Each of the server instances in the configuration must have a unique combination of Listen Address and Listen Port. Make sure that the HttpClusterServlet is the default application for the proxy server. If you get a page not found error when you try to your application, make sure that weblogic.xml is in \WEB-INF for the application and that it sets the context-root deployment parameter to /. 102 OpenText Web Experience Management Administration Guide

103 6.7. Accessing Applications Via the HttpClusterServlet When all else fails, restart If you are having problems try rebooting all your servers, some of the changes you made while configuring your setup may not have been persisted to the configuration file. Verify Your Configuration To verify the configuration of the HttpClusterServlet: 1. Set the DebugConfigInfo parameter in web.xml to ON. 2. Use a Web browser to access the following URL: WebLogicBridgeConfig Where: <server> is the Managed Server on the proxy machine where HttpClusterServlet runs, <port> is the port number on that server that is listening for HTTP requests, and placeholder.jsp is a file that does not exist on the server. HttpClusterServlet gathers configuration information and run-time statistics and returns the information to the browser. For more information, see HttpClusterServlet Deployment Parameters on page 98. OpenText Web Experience Management Administration Guide 103

104

105 Chapter 7 Managing Authorization This topic explains Web Experience Management authorization. 7.1 Overview The Web Experience Management security mechanism uses both authentication and authorization. This section introduces you to the concepts associated with authorization. Authorization is the act of verifying that a user has the capabilities (permissions) needed to perform a requested action on a selected object (site, channel, project, file, record, workflow, classification, package, and so on). Note: Authentication is the act of verifying that a user is who that user claims to be. The WEM software uses the authentication services of your application server s Lightweight Directory Access Protocol (LDAP) server. As part of the process of configuring the WEM software, the Configuration Console sets up an LDAP security realm on your application server. That realm defines the set of users and groups that can access WEM utilities and managed objects. The WEM Server, Content Workspaces, Management Console, and other parts of the WEM software use the information in the security realm to authenticate users and groups. Only users that are both authenticated and authorized can perform operations either in the system or on an object. For information on creating users and groups in the LDAP repository, see the OpenText Web Experience Management - Planning and Installation Guide (WCMGT- IGD) Capabilities Capabilities identify what operations a user can perform. Users must have specific capabilities before they can access any WEM tool, or feature. Web Experience Management provides a set of predefined capabilities. You cannot create new capabilities, nor can you delete or modify existing ones, the exception being for generated capabilities (see Generated Capabilities for New Content Type Definitions on page 161). A user obtains capabilities either directly, or indirectly through group membership via: Roles (see Role-Based Capabilities on page 106) OpenText Web Experience Management Administration Guide 105

106 Chapter 7 Managing Authorization An object's Access Control List (ACL). See Access Control List: Object-Based Capabilities on page Role-Based Capabilities Role-based capabilities (capabilities that are associated with a role) are inherited by a user when the role is assigned to that user (or to a group of which the user is a member). For more information about roles, see Roles on page 108. Role-based capabilities allow users who are members of an authorized group to create or modify objects managed by the WEM product. For more information, see Authorized Groups on page 110. Other role-based capabilities enable a user to run the Configuration Console, the Management Console, the Content Workspaces, and the WEM command line utilities. Users who have the necessary role-based capabilities can automatically perform any operation on WEM configuration components; that is, components that can be created or modified from the Configuration Console, such as: Content Management Server instance Content Delivery Services components Deployment Agents Stages CDSs Content Type definitions Deployment type definitions Services, handlers, and resources for the preceding components (where applicable) Access Control List: Object-Based Capabilities You can grant or deny a group or user access to individual instances of certain kinds of objects in the WEM product. These objects, which can be manipulated from the Management Console or Content Workspaces, include the following: Channels Categories Content Type definitions Content instances Files (referred to as static files in this document) File sources Projects (referred to as folders in Content Workspaces) Records 106 OpenText Web Experience Management Administration Guide

107 7.1. Overview Sites Workflows To grant or deny access to these objects, you modify the object's Access Control List (ACL) From the Management Console, you click the Advanced button on the Security tab on the appropriate object's Properties window in the Management Console. From Content Workspaces, you open the Security tab in the Properties palette and click the Advanced button. An object's ACL identifies: What operations the object allows to be performed on it (for example: read, modify, create, or delete) Which users can (or cannot) perform those operations The capabilities granted or denied by an object's ACL override capabilities granted by a group's or user's role assignments. If an object's ACL has a capability that explicitly denies a particular user permission to perform an operation, then that user cannot perform the operation even if the user's assigned roles contain the necessary capabilities to perform that operation. Each object grants or denies its own set of capabilities. For example, the channel object /Site/Ireland/Home might grant only user mgaines and members of the vgnadmin group permission to create a channel in it. The rest of the paragraphs in this section discuss ACL inheritance and propagation. The paragraphs use the following terms and concepts: Container A project (called a folder in Content Workspaces), subproject, site, channel, or subchannel. Leaf node (in a project or subproject) A static file or content instance. Leaf node (in a channel or subchannel) An association of a static file or content instance to the channel or subchannel. Containers can contain the following items: A top-level project can contain leaf nodes and subprojects. A subproject can contain leaf nodes and other subprojects. A site contains default channels. Channels (including a site's default channels) can contain subchannels or leaf nodes (associations). Subchannels can contain other subchannels or leaf nodes (associations). OpenText Web Experience Management Administration Guide 107

108 Chapter 7 Managing Authorization ACL Inheritance and Propagation ACL inheritance and propagation happens as follows: An ACL can only be propagated or inherited by containers of the same type; for example, from one channel to another channel, or from one project to another project: When you create a site, if you specify entries for the site's ACL as part of that site's creation, committing (clicking OK or Apply) causes the WEM software to create the site's default channels. Although it propagates the site's authorized groups to all the channels (assuming one or more authorized groups were specified when the site was created), it does not propagate the site's ACL entries to any channel's ACL. Even if, at some point after a particular site has been created, you modify the site's ACL entries, the site's default channels do not inherit the site ACL entries (or the changes, as the case may be). When you create a subcontainer (a channel or project), it will inherit the entries in the ACL of its parent container unless you specifically override those entries for the subcontainer's ACL when creating that subcontainer. Note: Eliminating the entries from any container's ACL can cause unexpected problems in accessing the container and its contents. Be sure that you really intend for a container to have no ACL entries before you actually remove those entries. Leaf nodes of a channel or project do not inherit ACL entries. You must set a leaf node's ACL entries explicitly. See also: Roles Roles on page 108 Authorized Groups on page 110, for information on how role-based capabilities are further restricted for managed objects Default Capabilities on page 135 You cannot assign capabilities directly to a user or a group. Instead, you assign roles to them. Note: Open Text strongly recommends that you assign roles to groups rather than to individual users. For brevity, the rest of this chapter refers to roles for users; however, it does so with the understanding that users should acquire capabilities only through their group memberships (and the roles assigned to those groups). A role is a collection of capabilities. A user with an assigned role automatically acquires the capabilities associated with that role. 108 OpenText Web Experience Management Administration Guide

109 7.1. Overview A user can have more than one role assigned. Each role adds its capabilities to the capabilities already possessed by that user. Each functional area of a Web Experience Management product provides default roles, each role having a default set of role-based capabilities. You can: Change which capabilities are associated with a role. For example, you can assign additional capabilities to a role. Remove capabilities that were previously assigned to the role; however, we recommend that you do not remove default capabilities from default roles. Create new roles and assign each role a set of role-based capabilities. When you add the new role to a user, that user acquires the role's capabilities. Delete roles that you create. Note: You can also delete default roles (except for Authorization Administrator), but we strongly recommend that you do not. As mentioned earlier, we strongly recommend that you assign roles to groups rather than to individual users. Assigning roles to users tends to create the need for more administrative interaction because you must synchronize your Authorization tables with your LDAP repository each time you add or remove a user, each time a user changes a password, and so on. You do not incur this extra overhead when adding or removing a user from a group in your LDAP repository. Note: Roles cannot be assigned to the logical group All Users. See Container- Based Security on page 115. The exception to this recommendation is when you identify your application server's system user name as part of configuring the WEM product, the configuration software automatically assigns the following roles to that user: CS Administrator Authorization Administrator WEM Administrator The specified user becomes, in effect, a super user. See also: OpenText Web Experience Management - Planning and Installation Guide (WCMGT- IGD), for information on preparing LDAP. Understanding Default Roles and Capabilities on page 123 Default Roles on page 124 OpenText Web Experience Management Administration Guide 109

110 Chapter 7 Managing Authorization Authorized Groups An authorized group is a group defined in the LDAP repository, to which a managed object has granted special permission to perform actions on itself. The actions that a member of the group can perform on the object are those granted to the user via the user's role-based capabilities (either from a direct assignment of the role to the user or via inheritance from a group that has been assigned such a role). In other words, members of any of an object's authorized groups have their rolebased capabilities enabled for that object. Conversely, unless a user is a member of an authorized group, that user's role-based capabilities are disabled for any action on a managed object. Note: Capabilities granted by an object (via the object's ACL) override the capabilities a user acquires through role assignment, regardless of any authorized group assignment. In fact, an object's ACL can specifically grant the capabilities a user needs to perform a specific action, even if the user does not belong to a prerequisite authorized group. Application Administrators are unaffected by managed object capabilities (ACL) or authorized group assignments. An object may specify up to six authorized groups. The rest of this paragraph describes inheritance and propagation rules, which control how authorized group specification happens and how those specifications are inherited and propagated. The rules are applied differently, depending on the objects involved Authorized Group Inheritance and Propagation in Projects A leaf node in a project automatically inherits the authorized groups of its parent project. When you create a project, it inherits the authorized groups of its parent project unless you explicitly override that value when creating the project. When you change a project's (or subproject's) previously existing authorized group assignments, you have an option to propagate those changes. If you choose that option, the changes are propagated to all of the project's subprojects, their subprojects, and so on for the entire set of descendants in the project hierarchy. Propagating overwrites the existing settings for the project's children. It does not merge those changes. Notes Leaf children of a project always have the same authorized group settings as their parent projects. Inherited ACLs behave differently in Content Workspaces. See Knowledge Base (KB) article number , Authorization Differences Between the 110 OpenText Web Experience Management Administration Guide

111 7.1. Overview VCM 8.0 Management Console and Content Workspaces ( knowledge.opentext.com/knowledge/llisapi.dll/open/ ).. For example, assume that you have the current settings: If you add Group C as an authorized group for Project 1 and choose to propagate that change, all of Project 1's children will have the same authorized groups as Project 1 (Group A and Group C): If you move one project (for example, Project 6) into another project (for example, Project 7), Project 6 becomes a subproject of Project 7. However, Project 6 retains its authorized group assignments. It does not inherit its parent project's assignments. OpenText Web Experience Management Administration Guide 111

112 Chapter 7 Managing Authorization Authorized Group Inheritance and Propagation in Channels A leaf node in a channel or subchannel has no authorized group, because a leaf node in a channel or subchannel is not a static file or content instance, only an association of one of those items to the channel. When you create a channel (or subchannel), it inherits the authorized groups of its parent channel unless you explicitly override that value when creating the channel. Leaf nodes are unaffected. When you change a channel/subchannel's previously-existing authorized group assignments, you have an option to propagate those changes. If you choose that option, the changes are propagated to all the channel's subchannels. Leaf nodes are unaffected. Propagating overwrites the existing settings for the channel's subchannels. It does not merge those changes. If you choose not to propagate the changes, the changes apply only to the affected channel. If you move channel C into channel D (that is, you make C a subchannel of D), channel C retains its authorized group assignments. It does not inherit its parent channel's assignments. Leaf nodes are unaffected. When you create a site, if you specify one or more authorized groups as part of the creation, when you commit (click Save or Save & Close), the WEM software creates the site's default channels, and propagates the site's authorized group assignments to all of those channels. When you change a site's previously existing authorized group assignments, you have an option to propagate those changes. If you choose that option, the changes are propagated to all the site's channels and subchannels. Leaf nodes are unaffected. If you choose not to propagate the changes, the changes apply only to the site Examples of Authorized Group Usage In the following examples, assume that your LDAP repository has a group called all_managers, which contains all of your company's management-level employees that are defined in that repository. Note: If you have configured the Dynamic Site or Dynamic Portal functionality, you can also create Presentation Manager and Presentation Contributor roles. For more information about these roles and setting up authorization, see OpenText Web Experience Management Dynamic Site and Portal - Configuration Guide (WCDPSM-ACC). Example 7-1: This example shows one way to handle security for a WEM installation. In this example, you could: 112 OpenText Web Experience Management Administration Guide

113 7.1. Overview 1. Create a single project, called Root under /Content in the Management Console, and allow no other projects to be created at that level (in other words, all other projects are children of Root). 2. Create the following groups and assign the roles shown in the following table: Group content_contributors content_supervisors developers knowledge_managers lob_managers Role to be Assigned Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager 3. Put your managerial users in the appropriate groups for their day-to-day WEMrelated work. 4. Designate content_contributors, content_supervisors, developers, knowledge_managers, and lob_managers as the authorized groups for Root, and specify that the authorized groups should be propagated to all children (including sub-projects). Note: If you had more than six groups that needed to be authorized groups for Root, you could perform the following substeps instead of Step 4: a. Create an all_roles group and make all of the groups you need to be authorized groups members of all_roles. b. Designate all_roles as the authorized group for Root and specify that the authorized group should be propagated to all children (including subprojects). With this configuration, all your company's people doing WEM-related work can perform any action that their roles allow on any content instance or static file. However, suppose that you have an object, such as a company report, that must only be modified by your company's Chief Financial Officer and that person's personal secretary. You could extend example 1 by modifying the ACL for the company report file to first deny all_roles the ability to modify the file, and then granting the CFO and secretary the ability to modify that file. That way, only those two people could actually modify the file. Example 7-2: This example provides an alternative to modifying the ACL in Example 7-1, on page 112. Instead you could do the following: OpenText Web Experience Management Administration Guide 113

114 Chapter 7 Managing Authorization 1. Create a group called cfo in your LDAP repository, with only the CFO and the personal secretary as members. 2. Assign the following roles to the cfo group: Content Contributor Content Supervisor 3. Create a child project under Root, called CompanyReport. 4. Designate cfo as the only authorized group for CompanyReport. 5. Store the company report in the CompanyReport project. With this configuration, only those two people will be able to perform any actions on the company report file. Example 7-3: This example shows a more complex way to handle security for a WEM installation. Consider the following configuration: The /Sites/Sports site has a channel named Home. The /Sites/Sports/Home channel has the AllWriters group as its only authorized group The /Sites/Sports/Home channel contains the Bicycling subchannel which inherits the AllWriters group from its parent. The /Sites/Sports/Home/Bicycling subchannel contains its own subchannel: the Tours subchannel. The Tours subchannel has the EuropeanWriters group as its only authorized group. In such a configuration, users in the AllWriters group can perform any operation (for which they have the prerequisite role-based capabilities) on both the / Sites/Sports/Home channel and its Bicycling subchannel; however, they cannot perform any operations on the /Sites/Sports/Home/Bicycling/Tours subchannel or its children. Users in the EuropeanWriters group can perform any operation (for which they have the prerequisite role-based capabilities) on the / Sites/Sports/Home/Bicycling/Tours subchannel and its children; however, they cannot perform any operations on the /Sites/Sports/Home channel or its Bicycling subchannel. For a user to be able to perform operations on the /Sites/Sports/Home channel, its Bicycling channel, and the Tours subchannel and its children, that user would need to be a member of both the AllWriters group and the EuropeanWriters group. 114 OpenText Web Experience Management Administration Guide

115 7.1. Overview Note: Inherited ACLs behave differently in Content Workspaces. See Knowledge Base (KB) article number , Authorization Differences Between the VCM 8.0 Management Console and Content Workspaces ( knowledge.opentext.com/knowledge/llisapi.dll/open/ ). For more information, see: Precedence Rules on page 122, for information on how administrative users are unaffected by capabilities or authorized groups Default Capabilities on page The All Users Group Every user and group in your WEM LDAP registry is a member of the All Users group. The All Users group is a logical group, and differs from the groups defined in your LDAP repository in that you cannot associate roles with All Users. In fact, All Users does not appear in the Role Manager's list of groups. However, it does appear in the following Management Console locations: The groups listed when you edit the ACL for a container object (such as a project, site, or channel) via the object's Access Control Settings The groups listed when you add an authorized group to a container object The list of groups returned when you search groups (regardless of what group you search for) Inheritance is not affected by the addition of the All Users logical group. For information about inheritance and propagation, see ACL inheritance on page page 108, and Authorized Group Inheritance and Propagation in Projects on page Container-Based Security If, when you create a root-level project, you assign an authorized group to that project, only members of the authorized group can see the project's contents (unless specifically denied by an entry in the project's ACL). The members of an authorized group can see the project's contents because all WEM default roles have the VCM:PROJECT_READ capability. Another way to restrict the ability to see a project's contents is to explicitly grant the VCM:PROJECT_READ capability to specific WEM users or groups in a root-level project's ACL at the time you create the project. Note: This more-restrictive behavior is an enhancement to the way projectlevel security worked in releases prior to 7.3. In earlier releases, every WEM user could see the contents of every project, regardless of a project's security settings. OpenText Web Experience Management Administration Guide 115

116 Chapter 7 Managing Authorization Unrestricted Access If you want all users to be able to see the contents of a project, you can set up your configuration to allow that kind of access. If, while creating a root-level project, you do not specify an authorized group, and you do not explicitly grant VCM:PROJECT_READ to one or more users or groups, the WEM software automatically creates an ACL for the project and includes an entry granting VCM:PROJECT_READ to the All Users logical group. By doing so, the WEM software allows any of its users to see the contents of the project. See The All Users Group on page Restricting Access After a Project Has Been Created You may want to restrict access to a project at some point after the project has been created. If the project was created so that All Users has been granted the VCM:PROJECT_READ capability, you will need to remove the ACL entry for All Users when you add your more restrictive ACL entry Extending Container-Based Security In the Management Console you can extend container-based security to additional types of objects; for example, sites, channels, and content items (content instances and/or static files). To extend container-based security: 1. On a machine accessible from your Content Management Server host, create and save an XML file containing the following code: <?xml version="1.0"?> <service-provider-asset-type-specification typename="<typename>"> <read-capability><objectreadcap></read-capability> </service-provider-asset-type-specification> Substitute the object WEM-internal name for <typename> (for example, WorkflowDefinition), and the object's READ capability for <objectreadcap> (for example VCM:WORKFLOW_DEF_READ). Following is an example of the code for an object type <?xml version="1.0"?> <service-provider-asset-type-specification typename="contentinstance"> <read-capability>vcm:content_instance_read</-capability> </service-provider-asset-type-specification> 2. From a browser, open the following URL: 116 OpenText Web Experience Management Administration Guide

117 7.1. Overview where <host> is the name or IP address of the machine on which the Content Management Server is running, and <port> is the port number of the Content Management Server. 3. Log into the Configuration Console using the WEM administrator's ID and password. 4. Expand the configuration tree as follows: Configuration Console > Management Services > Management Console > Service Provider Framework > Type Specification Registry > Registry Customer Extension Type Specification 5. Right-click the Customer Extension Type Specification Registry folder, and select Create Type Specification. The Register Type Specification dialog appears. 6. In the provided fields, enter a display name, the WEM system value for <typename> (from Step 1 on page 116), and the path to the file you created in that same step. 7. Click Next, and in the next dialog, click Finish. 8. Repeat the preceding steps for each object type you want to add to containerbased security. When you commit these changes in the Configuration Console, unauthorized users will no longer be able to access properties of these objects. If you have users who should be able to read objects that you just caused to be filtered by a container-based security extension, and those users do not currently have the required read capabilities to read those objects, you may have to grant them (or a group to which they belong) the required capabilities. Otherwise, you will prevent users who were intentionally allowed to view properties of objects and navigate into sites and channels, from being able to view and navigate after adding your security extension. Note: Currently it is not possible to grant VCM:SITE_READ and VCM:CHANNEL_READ directly to users or groups on sites and channels respectively. Instead, set up site and channel read authorization using authorized groups where these capabilities are granted through role associations. OpenText Web Experience Management Administration Guide 117

118 Chapter 7 Managing Authorization Effective Capabilities A user's effective capabilities dictate what actions that user can perform on a specific object. To calculate a user's effective capabilities for any given object, you must take into account the following: The user's complete set of role-based capabilities, including: Capabilities from roles assigned directly to the user Capabilities from roles that the user inherits from group membership For managed objects, the object's complete set of capabilities as they relate to: Operations permitted or denied to the user by the managed object Operations permitted or denied to a group (direct or nested) of which the user is a member For managed objects, the user's membership in an authorized group, including: Any group directly designated as an authorized group for the managed object in question Any group designated as an authorized group for an object related to the object in question, but which is higher in the path hierarchy. To know if a user can publish a channel, you would check the user's effective capabilities. For example, you might find the following: The user's role-based capabilities allow channel publication. The channel's capabilities neither permit nor deny the user the ability to publish, and neither do the capabilities of the site to which the channel belongs. The channel (as well as any channel in the hierarchy between that channel and the site) inherits an authorized group from the site, and that group contains the user as a member. In this example, the user has the effective capabilities necessary to publish the channel, because: The user's role-based capabilities allow channel publication. The channel's capabilities do not deny the user (or any group to which the user belongs) the ability to publish. The channel's authorized groups (inherited from its parent site) contain the user as a member. Closely related to the concept of effective capabilities, is the concept of precedence. See Precedence Rules on page OpenText Web Experience Management Administration Guide

119 7.1. Overview Tools and Actions To administer authentication and authorization, use these tools: Administrative task Associate a group (or user) with one or more roles. Edit existing roles or create new roles. Edit the list of product administrators. Assign or modify the ACL for an object. Tool Roles feature of the Management Console: Workbench > Roles Roles feature of the Management Console: Workbench > Roles Configuration Console Content Workspaces Properties palette > Security tab. For additional information, see the following: Action Create LDAP users and groups. Associate users with groups. Configure WEM software to access an LDAP repository. Understand WEM roles and capabilities. See Your LDAP documentation Your LDAP documentation OpenText Web Experience Management - Planning and Installation Guide (WCMGT-IGD) Understanding Default Roles and Capabilities on page 123 Modify a role's capabilities. Creating and Editing Roles on page 163 Help for the Roles feature in the OpenText Web Experience Management - Management Console Online Help (WCMGT-H-ACM). Assign a role to a user or group. Add or remove administrators for products. Modify the ACL for managed objects. Help for the Roles feature in the OpenText Web Experience Management - Management Console Online Help (WCMGT-H-ACM). OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) Section 20.4 Setting Authorized Access Groups and Assigning Capabilities in OpenText Web Experience Management - Content Workspaces Help (WCMGT-H-UGD). OpenText Web Experience Management Administration Guide 119

120 Chapter 7 Managing Authorization 7.2 Role Assignment When a user logs in to the Management Console or any other WEM tool with authentic credentials, the system matches the user with all WEM roles the user has obtained, in the following ways: Directly The role has been added to the user's name. By group membership The role has been added to one or more groups to which the user belongs. Figure 7-1 shows how role assignment to users and groups can be organized: Figure 7-1: Examples of Role Assignment Assigning a role to a single user is the least common method of role assignment, because it is harder to maintain for multiple users. Assigning roles to groups (as shown for User2) is easier to maintain. However, real-world configurations are more complex, and require some variation of the role assignments shown for User 3, 4, and 5. In fact, the complexity of most configurations will require that you nest groups; that is, that you make some groups members of other groups, as shown in Figure 7-2: 120 OpenText Web Experience Management Administration Guide

121 7.2. Role Assignment Figure 7-2: Further Example of Role Assignment Capabilities are cumulative. In Figure 7-2, User7 is directly assigned the capabilities for Role9. User7 acquires the capabilities associated with Roles 10, 11, 12, and 13 through group membership either directly (Group A and C) or through nested group membership (Group B, E, F, and G). User7 does not acquire the capabilities for Role 14, because Group D is not one of the groups nested in Group C. The following section explains the rules that apply to aggregating the granted capabilities of groups and roles to determine the user's effective capabilities. See also: Managing Authorization Efficiently on page 167 OpenText Web Experience Management Administration Guide 121

122 Chapter 7 Managing Authorization 7.3 Precedence Rules When a user tries to perform an operation, the WEM software uses a set of precedence rules to determine if the user can perform that operation. Precedence is required to determine a user's authorization in a given situation, because different authorizations can conflict. The WEM software checks the following rules in sequence. As soon as it finds a rule that applies to the user and object in question, it either permits or denies the requested operation based on the applicable rule. At that point, the WEM software ceases to check any further rules. The precedence rules are as follows: 1. The user has administrator capabilities for the scope of the operation: The user is allowed to perform the operation. 2. If the capabilities listed in an object's ACL deny the user permission to perform the operation: The user is not allowed to perform the operation. 3. If the capabilities listed in an object's ACL grant the user permission to perform the operation: The user is allowed to perform the operation. 4. If the capabilities listed in an object's ACL deny permission to perform the operation to a group of which the user is a direct member: The user is not allowed to perform the operation. 5. If the capabilities listed in an object's ACL deny permission to perform the operation to a nested group (a group which contains a group) of which the user is a direct member: The user is not allowed to perform the operation. 6. Repeat Step 5 for each additional layer of a user's indirect group membership. 7. If the capabilities listed in an object's ACL grant permission to perform the operation to a group of which the user is a member: The user is allowed to perform the operation. 8. If the capabilities listed in an object's ACL grant permission to perform the operation to a nested group (a group which contains a group) of which the user is a direct member: The user is allowed to perform the operation. 9. Repeat Step 8 for each additional layer of a user's indirect group membership. 10. If the user does not belong to a group (directly or indirectly) that is one of the authorized groups for the object: The user is not allowed to perform the operation. 11. The user has the effective capabilities to perform the operation: The user is allowed to perform the operation. 12. The user is not allowed to perform the operation. 122 OpenText Web Experience Management Administration Guide

123 7.4. Understanding Default Roles and Capabilities A user with the capabilities of the Application Administrator role can perform any operation on any object in the WEM product, regardless of the object's permissions. A user with the <*>:ADMINISTRATOR capability (where * is AUTH, PWS, or VCM) can perform any operation on any object within the designated scope (*). For example, a user with the PWS:ADMINISTRATOR capability can perform any applicable PWSrelated operation on the specified object. Notes The <*>:ADMINISTRATOR capability contains all the capabilities for the designated scope and you cannot revoke those capabilities. For example, the VCM:ADMINISTRATOR capability contains all the VCM:<*> capabilities and revoking the VCM:MODIFY capability for a role that has VCM:ADMINISTRATOR capability has no effect. Use the Roles feature of the Management Console to find which roles a user has. Use the Runtime Services Console or your external LDAP repository's client tool to see which groups a user belongs to. Based on that information, you can calculate the user's effective capabilities (see Effective Capabilities on page 118). To view an object's capabilities list, use the Management Console. 7.4 Understanding Default Roles and Capabilities You can create new roles or use default roles established by the WEM software. However, you cannot create or modify capabilities. Notes Each area of Web Experience Management comes with a defined set of capabilities that pertain to operations performed in that area or on that area's resources. Capability prefixes identify areas of the product suite, such as authorization (AUTH), (CS), and Content Management Server (VCM). If you have configured the Dynamic Site or Dynamic Portal functionality, you can also create Presentation Manager and Presentation Contributor roles. For more information about these roles and setting up authorization, see Section 12 Setting Up Authorization in OpenText Web Experience Management Dynamic Site and Portal - Configuration Guide (WCDPSM-ACC). OpenText Web Experience Management Administration Guide 123

124 Chapter 7 Managing Authorization Default Roles The default roles as they are shipped are shown in the following sections, along with a description of what tasks they can perform. However, the ability to perform each of those tasks is subject to precedence rules, described in Precedence Rules on page 122. Caution You can add or delete capabilities from the default roles (except that you should never delete capabilities from Administrator roles), and you can even change the names of default roles. However, any such changes can have unwanted effects especially if you upgrade your WEM software at some point after making those changes. For example: If you add capabilities to, or remove them from the default roles shipped with your WEM software and later upgrade, the upgrade will destroy your changes, re-adding deleted capabilities and removing capabilities that you added. After upgrading, you would need to remake your changes manually. If you rename the default roles and later upgrade, the upgrade will not remove your renamed roles; however, it will create a new set of default roles with the original default role names. The new set of default roles may contain a slightly different set of capabilities than your renamed default roles; for example, if the upgrade adds or removes capabilities. For compatibility, you would need to manually change your renamed default roles have the same capabilities as the new default roles (re)created by the upgrade. Caution Do not remove capabilities from Administrator roles. Administrator capabilities are required for maintaining the system Application Administrator Description: Default user: Overall administrator for a WEM configuration. Users or groups with the Application Administrator role can perform any WEM action. For example: Configure any underlying infrastructure required by the application such as assigning roles to users and groups, creating roles, managing all aspects of the Content Management Server, and so on. Support development and deployment of applications (either a custom application or an extension of a packaged application provided by OpenText). None 124 OpenText Web Experience Management Administration Guide

125 7.4. Understanding Default Roles and Capabilities Default granted capabilities: AUTH:ADMINISTRATOR PWS:ADMINISTRATOR VCM:ADMINISTRATOR Authorization Administrator Description: Manages the roles and capabilities for the selected WEM installation. Actions include: Assign capabilities to, or remove them from a role. Assign roles to users or groups. Create a new role. Note: For security reasons, you cannot delete the Authorization Administrator role Default user: Content Management Server administrator, prompted for during the WEM configuration: for example, system. Default granted capabilities: AUTH:ADMINISTRATOR Content Contributor Description: Default user: Creates actual content for the site. Users in this role are typically non-technical with a low level of knowledge about the system. Actions include: Assign content with a channel. Categorize content. Create a content instance. Submit static files to WEM control. Modify a workflow payload. Version content. Work on assigned tasks. None. OpenText Web Experience Management Administration Guide 125

126 Chapter 7 Managing Authorization Default granted capabilities: VCM:ADD VCM:CATEGORY_READ VCM:CHANNEL_READ VCM:CONTENT_READ VCM:CONTENT_TYPE_READ VCM:CREATE_RECORD VCM:CREATE_RECORD_SOURCE VCM:CREATE_STATIC_FILE VCM:CREATE_WF_PAYLOAD VCM:DELETE VCM:DEPLOY_AND_UNDEPLOY VCM:MANAGE_WF_ACTIVITY VCM:MANAGE_WF_PROCESS VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_CHANNEL_ASSOC VCM:MODIFY_TAX_ASSOCS VCM:MODIFY_WF_PAYLOAD VCM:PROJECT_READ VCM:PROMOTE_AND_DEMOTE VCM:READ VCM:SITE_READ VCM:SNAPSHOT_CONTENT VCM:STATIC_FILE_READ VCM:STATIC_FILE_WRITE VCM:VGNLINKDEFINITION_READ VCM:VGNLINKDEFINITION_WRITE VCM:VGNMEDIADEFINITION_READ VCM:VGNMEDIADEFINITION_WRITE VCM:VGNWINDOWFEATURES_READ VCM:VGNWINDOWFEATURES_WRITE Content Supervisor 126 OpenText Web Experience Management Administration Guide

127 7.4. Understanding Default Roles and Capabilities Description: Default user: Manages activities related to collecting, developing, and managing content. These activities may include editorial review, workflow routing (if explicitly applied), content classification, and classification review. The Content Supervisor may also review content categorization decisions made by a Content Contributor. Actions include: Assign content to a channel. Assign a workflow instance. Cancel a workflow. Categorize content. Create a content instance. Create a navigation hierarchy of channels. Create a project for content items (content instances and/or static files). Create a workflow process or a workflow instance. Create or modify a workflow payload. Define a report. Delete a content item. Import, review, and manage content objects. Manage a project for content items. Manage static files. Modify a content item s attributes or metadata. Modify a workflow timeout. Publish content. Publish a site. Reassign a workflow task. Run/review a report. Start a workflow. Submit a static file to WEM control. Version content. Work on assigned tasks. None. Default granted capabilities: VCM:ADD VCM:APPROVE VCM:CANCEL_WF_ACTIVITY VCM:CANCEL_WF_PROCESS VCM:CATEGORY_READ VCM:CHANNEL_DELETE VCM:CHANNEL_READ VCM:CHANNEL_WRITE VCM:CONTENT_READ VCM:CONTENT_TYPE_READ OpenText Web Experience Management Administration Guide 127

128 Chapter 7 Managing Authorization Default granted capabilities (continued for Content Supervisor): VCM:CREATE_PROJECT VCM:CREATE_RECORD VCM:CREATE_RECORD_SOURCE VCM:CREATE_ROOT_PROJECT VCM:CREATE_STATIC_FILE VCM:CREATE_WF_PAYLOAD VCM:DELETE VCM:DEPLOY_AND_UNDEPLOY VCM:MANAGE_WF_ACTIVITY VCM:MANAGE_WF_PROCESS VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_CHANNEL_ASSOC VCM:MODIFY_TAX_ASSOCS VCM:MODIFY_WF_PAYLOAD VCM:MODIFY_WF_TIMEOUT VCM:OBJECT_TYPE_READ VCM:PROJECT_DELETE VCM:PROJECT_READ VCM:PROJECT_WRITE VCM:PROMOTE_AND_DEMOTE VCM:READ VCM:REASSIGN_WF_ACTIVITY VCM:SITE_PUBLISH VCM:SITE_READ VCM:SNAPSHOT_CONTENT VCM:STATIC_FILE_DELETE VCM:STATIC_FILE_READ VCM:STATIC_FILE_WRITE VCM:WORKBENCH_READ VCM:WORKFLOW_DEF_READ VCM:WORKFLOW_SUPERVISOR Developer 128 OpenText Web Experience Management Administration Guide

129 7.4. Understanding Default Roles and Capabilities Description: Writes code to extend or customize any packaged application (such as the Management Console). Actions include: Add capabilities to, or remove them from, a role. Assign roles to users or groups. Cancel a workflow. Create and manage content type definitions. Create and manage projects for content items (content instances and/or static files). Create and manage workflow definitions. Create or modify a workflow payload. Generate and manage the Content Management Application (CMA) and the Content Delivery Application (CDA). Manage object type definitions. Manage roles. Reassign a workflow task. Run reports. OpenText Web Experience Management Administration Guide 129

130 Chapter 7 Managing Authorization Default user: None Default granted capabilities: AUTH:MANAGE_CAPABILITIES AUTH:MANAGE_ROLE VCM:ADD VCM:CANCEL_WF_ACTIVITY VCM:CANCEL_WF_PROCESS VCM:CATEGORY_READ VCM:CHANNEL_READ VCM:CONTENT_READ VCM:CONTENT_TYPE_DELETE VCM:CONTENT_TYPE_READ VCM:CONTENT_TYPE_WRITE VCM:CREATE_PROJECT VCM:CREATE_RECORD VCM:CREATE_RECORD_SOURCE VCM:CREATE_ROOT_PROJECT VCM:CREATE_STATIC_FILE VCM:CREATE_WF_PAYLOAD VCM:CREATE_WORKFLOW_DEFINITION VCM:DELETE VCM:DEPLOY_AND_UNDEPLOY VCM:IMPORT_WF_DEFINITION VCM:MANAGE_WF_ACTIVITY VCM:MANAGE_WF_PROCESS VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PAYLOAD VCM:MODIFY_WF_TIMEOUT VCM:OBJECT_TYPE_READ VCM:OBJECT_TYPE_WRITE VCM:PROJECT_DELETE VCM:PROJECT_READ VCM:PROJECT_WRITE VCM:PROMOTE_AND_DEMOTE VCM:READ VCM:REASSIGN_WF_ACTIVITY VCM:REGISTER_WF_PROGRAM VCM:ROLE_DELETE VCM:ROLE_READ VCM:ROLE_WRITE VCM:SITE_READ VCM:SNAPSHOT_CONTENT VCM:STATIC_FILE_READ 130 OpenText Web Experience Management Administration Guide

131 7.4. Understanding Default Roles and Capabilities VCM:WORKBENCH_READ VCM:WORKFLOW_DEF_DELETE VCM:WORKFLOW_DEF_READ VCM:WORKFLOW_DEF_WRIT VCM:WORKFLOW_SUPERVISOR Knowledge Manager Description: Default user: Designs and manages classification categories and information architectures. Actions include: Assign capabilities to user-created roles. Assign a workflow instance. Cancel a workflow. Create and manage classification categories. Create and manage content type definitions. Create and manage projects for content items (content instances/static files). Create or modify a workflow payload. Create a navigation hierarchy of channels. Create a workflow process or a workflow instance. Define and view a report. Reassign a workflow task. Review a report. Supervise workflow activities. Work on assigned tasks. None OpenText Web Experience Management Administration Guide 131

132 Chapter 7 Managing Authorization Default granted capabilities: AUTH:MANAGE_CAPABILITIES VCM:ADD VCM:CANCEL_WF_ACTIVITY VCM:CANCEL_WF_PROCESS VCM:CATEGORY_DELETE VCM:CATEGORY_READ VCM:CATEGORY_WRITE VCM:CHANNEL_DELETE VCM:CHANNEL_READ VCM:CHANNEL_WRITE VCM:CONTENT_READ VCM:CONTENT_TYPE_DELETE VCM:CONTENT_TYPE_READ VCM:CONTENT_TYPE_WRITE VCM:CREATE_PROJECT VCM:CREATE_RECORD VCM:CREATE_RECORD_SOURCE VCM:CREATE_ROOT_PROJECT VCM:CREATE_WF_PAYLOAD VCM:DELETE VCM:DEPLOY_AND_UNDEPLOY VCM:MANAGE_WF_ACTIVITY VCM:MANAGE_WF_PROCESS VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_CHANNEL_ASSOC VCM:MODIFY_TAX_ASSOCS VCM:MODIFY_WF_PAYLOAD VCM:MODIFY_WF_TIMEOUT VCM:PROJECT_DELETE VCM:PROJECT_READ VCM:PROJECT_WRITE VCM:PROMOTE_AND_DEMOTE VCM:READ VCM:REASSIGN_WF_ACTIVITY VCM:SITE_READ VCM:SNAPSHOT_CONTENT VCM:STATIC_FILE_READ VCM:WORKBENCH_READ VCM:WORKFLOW_DEF_READ VCM:WORKFLOW_SUPERVISOR 132 OpenText Web Experience Management Administration Guide

133 7.4. Understanding Default Roles and Capabilities Line of Business Manager Description: Default user: Manages activities related to site operations and content operations that affect the user experience. These activities may include decisions regarding content development and deployment on a site and its channels as well as analytics and reporting against site usage and content usage. Defines the business goals for the customer and the reports that will be used to measure those goals. Actions include: Assign content to a channel. Cancel a workflow. Categorize content. Create a channel. Create a content instance. Create a project for content items (content instances/ static files). Create a site. Create a workflow definition or instance. Create or modify a workflow payload. Create a navigation hierarchy of channels Define and view a report. Delete a content item. Manage channels and sites. Manage projects. Manage static files. Manage workflow definitions or instances. Modify a content item s attributes or metadata. Modify an object s ACL. Publish content. Reassign a workflow task. Run reports. Submit a static file to WEM control. Version content. Work on assigned tasks. None OpenText Web Experience Management Administration Guide 133

134 Chapter 7 Managing Authorization Default granted capabilities: VCM:ADD VCM:APPROVE VCM:CANCEL_WF_ACTIVITY VCM:CANCEL_WF_PROCESS VCM:CATEGORY_READ VCM:CHANNEL_DELETE VCM:CHANNEL_READ VCM:CHANNEL_WRITE VCM:CONTENT_READ VCM:CONTENT_TYPE_READ VCM:CREATE_PROJECT VCM:CREATE_RECORD VCM:CREATE_RECORD_SOURCE VCM:CREATE_ROOT_PROJECT VCM:CREATE_STATIC_FILE VCM:CREATE_WF_PAYLOAD VCM:DELETE VCM:DEPLOY_AND_UNDEPLOY VCM:MANAGE_WF_ACTIVITY VCM:MANAGE_WF_PROCESS VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_CHANNEL_ASSOC VCM:MODIFY_TAX_ASSOCS VCM:MODIFY_WF_PAYLOAD VCM:MODIFY_WF_TIMEOUT VCM:OBJECT_TYPE_READ VCM:PROJECT_DELETE VCM:PROJECT_READ VCM:PROJECT_WRITE VCM:PROMOTE_AND_DEMOTE VCM:READ VCM:REASSIGN_WF_ACTIVITY VCM:SECURITY_READ VCM:SECURITY_WRITE VCM:SITE_DELETE VCM:SITE_PUBLISH VCM:SITE_READ VCM:SITE_WRITE VCM:SNAPSHOT_CONTENT VCM:STATIC_FILE_DELETE VCM:STATIC_FILE_READ VCM:STATIC_FILE_WRITE 134 OpenText Web Experience Management Administration Guide

135 7.4. Understanding Default Roles and Capabilities VCM:WORKBENCH_READ VCM:WORKFLOW_DEF_READ VCM:WORKFLOW_SUPERVISOR Default Capabilities The WEM software establishes a default set of capabilities during configuration. Each capability has a prefix that indicates the area of the product suite to which it pertains. These prefixes are: AUTH (authorization), PWS (workflow), and VCM (Content Management Server). You cannot modify installed capabilities or create new ones. Description of Capabilities on page 135 lists each capability and provides a brief description of what it allows a user to do. Note: More than one capability may be required to perform the actions listed in the second column of Description of Capabilities on page 135. See Table 7-3: Management Console and Content Workspaces: Capabilities/Roles Per Action on page 141 for a full list of the capabilities needed to perform a specific action: Table 7-1: Description of Capabilities Capability AUTH:ADMINISTRATOR AUTH:DELEGATE_TO_ROLE AUTH:MANAGE_ATTRIBUTES AUTH:MANAGE_CAPABILITIES AUTH:MANAGE_ROLE PWS:ADMINISTRATOR VCM:ADD VCM:ADMINISTRATOR VCM:APPROVE VCM:CANCEL_WF_ACTIVITY VCM:CANCEL_WF_PROCESS A user with this capability can: Manage all authorization information for the selected Content Management Server. This capability contains all AUTH:* capabilities within itself. This capability may appear in an object's ACL, you cannot directly assign it. It gets assigned when you specify an authorized group. See Authorized Groups on page 110. Do not assign this capability. It is for OpenText internal use only. Do not assign this capability. It is for OpenText internal use only. Add, modify, or delete roles in the authorization tables. Assign roles. Manage all aspects of the Process Workflow Server. Add content to a project in the content repository. Manage all aspects of the Content Management Server This capability contains all VCM:* capabilities within itself. Approve content for publishing. Cancel a workflow activity. Cancel a workflow instance. OpenText Web Experience Management Administration Guide 135

136 Chapter 7 Managing Authorization Capability VCM:CATEGORY_DELETE VCM:CATEGORY_READ VCM:CATEGORY_WRITE VCM:CHANNEL_DELETE A user with this capability can: Delete a classification category. View the list of classification categories and their properties. Create, modify, or move classification categories. Delete a channel, its sub-channels, and the associations to each channel in the particular subtree. VCM:CHANNEL_READ VCM:CHANNEL_WRITE Note: Deleting a channel requires having VCM:MODIFY_CHANNEL_ASSOC on the channel and any of associated content items. Also, any capabilities required for modifying a content item will be required for making the updates to remove the channel association. View a channel, its properties, and its content associations. Create or move a channel. Order channels. VCM:CONTENT_READ View content in the content repository (Workbench > Content). VCM:CONTENT_TYPE_DELETE VCM:CONTENT_TYPE_READ VCM:CONTENT_TYPE_WRITE VCM:CREATE_FILE_SOURCE VCM:CREATE_OBJECT_GROUP VCM:CREATE_PACKAGE_FILE VCM:CREATE_PROJECT VCM:CREATE_RECORD VCM:CREATE_RECORD_SOURCE VCM:CREATE_ROOT_PROJECT VCM:CREATE_STATIC_FILE VCM:CREATE_TAXONOMY VCM:CREATE_WF_PAYLOAD VCM:CREATE_WORKFLOW_DEFI NITION VCM:DELETE Delete a content type definition. View the properties of any content type definition. Create, update, or move a content type definition. Add a file source to the selected Content Management Server. Add or modify an object group in the selected Content Management Server. Create a package file object. Exporting a package manifest creates a package file object. Add or modify a project in the content repository Add a managed object or content instance in the content repository. Add or modify a record source in the selected Content Management Server. Add a root (top-level) project in the content repository. Add a file in the content repository. Add a classification category. Add a payload to the workflow. Add a workflow definition. Delete an object. 136 OpenText Web Experience Management Administration Guide

137 7.4. Understanding Default Roles and Capabilities Capability VCM:DEPLOY_AND_UNDEPLOY VCM:EXPORT_PACKAGE VCM:IMPORT_PACKAGE VCM:IMPORT_WF_DEFINITION VCM:MANAGE_WF_ACTIVITY VCM:MANAGE_WF_PROCESS VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_CHANNEL_ASSOC VCM:MODIFY_DEPLOYMENT_TY PES VCM:MODIFY_TAX_ASSOCS VCM:MODIFY_WF_PAYLOAD VCM:MODIFY_WF_TIMEOUT VCM:OBJECT_TYPE_DELETE VCM:OBJECT_TYPE_READ VCM:OBJECT_TYPE_WRITE VCM:PROJECT_DELETE VCM:PROJECT_READ VCM:PROJECT_WRITE VCM:PROMOTE_AND_DEMOTE VCM:PURGE_AND_RESTORE A user with this capability can: Publish or unpublish an object. Export a package manifest (a list of WEM objects to be serialized). The exported manifest becomes a package file object. Import the.zip data file from a package file object (the file which contains serialized WEM objects and a list of objects to be deleted from a target Content Management Server). Import a workflow definition into the Content Management Server; workflow definition becomes a managed asset. Accept, open, or finish a workflow activity. Start, stop, pause, or resume a workflow instance. Modify an object (one of the objects listed in Access Control List: Object-Based Capabilities on page 106). Note: Must be granted explicitly any time that VCM:X_WRITE (for a content instance of type X), or VCM:SECURITY_WRITE is granted explicitly. Associate content (and other items) with a channel; move content or content containers between channels. Add or delete deployment types for the selected Content Management Server. Add or remove classification associations from a WEMobject. Add or remove content in a workflow payload. Modify an instance-level timeout value. Delete an object type definition View the properties of an object type definition. Create or update an object type definition. Delete a project container (and its contents). View the properties of a project container (including its contents). Create, update, or move a project container. Required for publishing or unpublishing. Remove or restore a logically deleted object in the selected Content Management Server. OpenText Web Experience Management Administration Guide 137

138 Chapter 7 Managing Authorization Capability VCM:READ VCM:REASSIGN_WF_ACTIVITY VCM:REGISTER_WF_PROGRAM VCM:ROLE_DELETE VCM:ROLE_READ VCM:ROLE_WRITE VCM:SECURITY_READ VCM:SECURITY_WRITE VCM:SITE_DELETE VCM:SITE_PUBLISH VCM:SITE_READ VCM:SITE_WRITE VCM:SNAPSHOT_CONTENT VCM:STATIC_FILE_DELETE VCM:STATIC_FILE_READ VCM:STATIC_FILE_WRITE VCM:SYSTEM_OPERATIONS VCM:WORKBENCH_READ VCM:WORKFLOW_DEF_DELETE A user with this capability can: When used with a type-specific read capability, for example, the system-defined capability VCM:CONTENT_TYPE_READ, or a capability created when you defined a custom content type such as VCM:ARTICLE_READ, VCM:READ allows you to view a system object or content instance in the content repository. Assign a workflow activity to another participant. Register a program with the Content Management Server as a candidate for association with an automated workflow activity. Delete a role. Access the Workbench > Roles feature of the Management Console. View the properties of a role, including what capabilities are assigned to that role. Create or modify a role. View an object's ACL. Modify an object's ACL. Delete a site container. Publish or unpublish a site or channel (and the objects that are associated with that site or channel). Publish individual objects in a site or channel. View any site (/Sites/...), a site's properties, and a site's associations. Clone a site in Management Console or create a site in Content Workspaces. Create or update a site. Define site cloning defaults. Add, modify, or delete a saved version of a content instance or a collection of items. Delete a static file (remove it from WEM control). View the properties of a static file Submit a static file to WEM control, update the file's properties (or move a static file from one project to another). Create file source scans, and mark file sources for deletion. Use the Management Console's workbench features (/Workbench/...) Delete a workflow definition. 138 OpenText Web Experience Management Administration Guide

139 7.4. Understanding Default Roles and Capabilities Capability VCM:WORKFLOW_DEF_READ VCM:WORKFLOW_DEF_WRITE VCM:WORKFLOW_SUPERVISOR AS_LOCALE_READ AS_LOCALE_WRITE AS_LOCALE_DELETE ARCHIVE: A user with this capability can: View the workflow definition properties for content items (content instances/static files). Start a workflow. View or update a workflow definition's properties. Move a workflow definition. Reassign or cancel a workflow. See a locale in the Locales workbench. Create or update a locale in the Locales workbench. Delete a locale in the Locales workbench. Archive published content (data). Note: Published content is archived automatically if the system is configured to use OpenText Archive Server. For more information on creating workflow definitions, see OpenText Web Experience Management - Workflow Modeler User Online Help (WCMGT-H-UWF) Capabilities Required to Perform Actions The following paragraphs tell what capabilities are needed for performing actions in the: Configuration Console Management Console and Content Workspaces (see Management Console and Content Workspaces: Required Capabilities per Action on page 140) Required capabilities are also listed in the OpenText Web Experience Management - Content Workspaces Help (WCMGT-H-UGD). Command Line Utilities, including cfgedit, configp, vgnexport, vgnimport, and so on (see Command Line Utilities: Capabilities Required per Action on page 141) Configuration Console: Required Capabilities per Action Configuration Console: Required Capabilities Per Action on page 140 shows what capabilities a user must have in order to perform specific actions from the Configuration Console. OpenText Web Experience Management Administration Guide 139

140 Chapter 7 Managing Authorization Table 7-2: Configuration Console: Required Capabilities Per Action Action Required Capabilities Role Having That Capability View configuration tree and its components (Content Management Server, stages, CDSs, Deployment Agents, and so on). Create, modify, or change components in the configuration tree No capabilities required. As long as you are logged in to theconfiguration Console with a user ID and password that are valid in your LDAP repository, you can view configuration settings. VCM:ADMINISTRATOR Not applicable. Application Administrator Note: Any user who has the Application Administrator role can automatically perform any VCM-related action that the Configuration Console allows (for example, create/delete a Content Management Server, a Deployment Agent, and so on) Management Console and Content Workspaces: Required Capabilities per Action Management Console and Content Workspaces: Capabilities/Roles Per Action on page 141 shows what capabilities a user must have in order to perform specific actions from the Management Console and/or Content Workspaces. In that table, some capabilities will not perform the action indicated by their name unless other implied capabilities are also available. In most cases, the implied capabilities are available, because they are automatically part of any role (see Capabilities Provided with All Roles on page 164). However, in other situations, you must be sure that implied capabilities are available. The middle column of Management Console and Content Workspaces: Capabilities/Roles Per Action on page 141 shows what capabilities (including implied capabilities) are required to perform a specific action. The far-right column shows which roles by default contain the WEM capabilities from the middle column. You may need to provide additional capabilities for custom content types (or content instances created from those types). These capabilities are probably not part of the roles listed in the far-right column of Management Console and Content Workspaces: Capabilities/Roles Per Action on page 141; however, they are listed in the middle column. For example, to perform some action on a content instance of type <X>, you might need to verify that the VCM:<X>_WRITE capability is available. 140 OpenText Web Experience Management Administration Guide

141 7.4. Understanding Default Roles and Capabilities Note: Content Workspaces refers to organization containers as folders, where the Management Console refers to these containers as projects Command Line Utilities: Capabilities Required per Action Table 7-3: Management Console and Content Workspaces: Capabilities/Roles Per Action Action Accept a task. (Content Workspaces only) Associate a content item (a content instance or static file) with a channel. (Content Workspaces only) Cancel a running workflow process. (Content Workspaces only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) No capabilities required. VCM:MODIFY_CHANNEL_AS SOC (on both the item and the channel) which also requires the implied capabilities VCM:MODIFY and VCM:<X>_WRITE VCM:WORKFLOW_SUPERVIS OR which also requires these implied capabilities: VCM:CANCEL_WF_PROCE SS VCM:MANAGE_WF_PROCE SS VCM:MODIFY_WF_PAYLO AD VCM:READ Roles that Have the Required Default WEM Capabilities (or their equivalent) Not applicable. Application Administrator Content Contributor Content Supervisor Knowledge Manager Line of Business Manager Application Administrator Content Supervisor Developer Knowledge Manager Line of Business Manager Create a category (classification category). VCM:CATEGORY_WRITE Application Administrator Knowledge Manager OpenText Web Experience Management Administration Guide 141

142 Chapter 7 Managing Authorization Action Create a channel (or subchannel). (Content Workspaces only) Create a content instance. (Content Workspaces only) Create a content type definition. (Management Console only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:CHANNEL_WRITE which also requires these implied capabilities: VCM:ADD VCM:CREATE_RECORD VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PAYLO AD VCM:ADD VCM:CREATE_RECORD In addition, for a content instance of type <X>, you must verify that the following capabilities are available VCM:MODIFY_ACL VCM: <X>_WRITE VCM:CONTENT_TYPE_WRIT E which also requires these implied capabilities: AUTH:MANAGE_CAPABIL ITIES VCM:ADD VCM:CREATE_RECORD VCM:CREATE_RECORD_S OURCE VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PAYLO AD Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Content Supervisor Knowledge Manager Line of Business Manager Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager Application Administrator Developer Knowledge Manager 142 OpenText Web Experience Management Administration Guide

143 7.4. Understanding Default Roles and Capabilities Action Create a managed object. Create an object type definition. (Management Console only) Create (export) a package file. (Management Console only) Create a program task definition. (Management Console only) Create a folder. (Content Workspaces) Create a project. (Management Console) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:ADD VCM:CREATE_RECORD In addition, for a content instance of type <X>, you must verify that the following capabilities are available VCM:MODIFY_ACL VCM:<X>_WRITE VCM:OBJECT_TYPE_WRITE which also requires these implied capabilities: AUTH:MANAGE_CAPABIL ITIES VCM:ADD VCM:CREATE_RECORD VCM:CREATE_RECORD_S OURCE VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PAYLO AD VCM:EXPORT_PACKAGE Also requires the appropriate READ capability for each type of object to be exported to the package file. VCM:CREATE_STATIC_FIL E VCM:REGISTER_WF_PROGR AM VCM:PROJECT_WRITE which also requires these implied capabilities: VCM:ADD VCM:CREATE_PROJECT VCM:CREATE_ROOT_PRO JECT Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager Application Administrator Developer Application Administrator Application Administrator Developer Application Administrator Content Supervisor Developer Knowledge Manager Line of Business Manager OpenText Web Experience Management Administration Guide 143

144 Chapter 7 Managing Authorization Action Create a role. (Management Console only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:ROLE_WRITE which also requires the implied capability AUTH:MANAGE_ROLE Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Developer Create or edit a site's cloning defaults. (Content Workspaces only) VCM:SITE_WRITE Application Administrator Line of Business Manager Create a site (Content Workspaces only) Clone a site (Content Workspaces only) VCM:SITE_READ which also require the implied capabilities to read all the content of the template site: VCM:CONTENT_READ VCM:PROJECT_READ VCM:STATIC_FILE_REA D This task is based on cloning from a template site. Site content to which user lacks read access will be skipped during clone process. VCM:SITE_READ which also requires these implied capabilities: VCM:CONTENT_READ VCM:PROJECT_READ VCM:STATIC_FILE_REA D Template site content to which the user lacks read access will be skipped during clone process. Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager Application Administrator Line of Business Manager 144 OpenText Web Experience Management Administration Guide

145 7.4. Understanding Default Roles and Capabilities Action Submit an instance of the Static File content type. (Content Workspaces only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:STATIC_FILE_WRITE which also requires these implied capabilities: VCM:ADD VCM:CREATE_RECORD VCM:CREATE_STATIC_F ILE VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PAYLO AD Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Content Supervisor Content Contributor Line of Business Manager Delete an application asset; that is, remove the association between a content item (content instance or static file) and the Application Assets channel. (Content Workspaces only) VCM:MODIFY_CHANNEL_AS SOC On the content item and the Application Assets channel. Also, any capabilities required to modify a content item will be required for making the updates to remove the channel association. Application Administrator Content Contributor Content Supervisor Knowledge Manager Line of Business Manager Delete a category. That capability also requires the implied capability VCM:MODIFY VCM:CATEGORY_DELETE VCM:DELETE Application Administrator Knowledge Manager OpenText Web Experience Management Administration Guide 145

146 Chapter 7 Managing Authorization Action Delete a channel. (Content Workspaces only) Delete a content instance (remove the instance from the content repository). (Content Workspaces only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:CHANNEL_DELETE VCM:DELETE When WEM deletes a channel, it also updates each content item associated with that channel by removing the channel association from the content item. Therefore, for a person or group to delete a channel, they must have VCM:MODIFY_CHANNEL_AS SOC on the channel, as well as on any associated content items. Also, any capabilities required to modify a content item will be required for making the updates to remove the channel association. VCM:DELETE In addition, for a: Content instance of type <X>: VCM:<X>_DELETE Static file: VCM:STATIC_FILE_DEL ETE (which also requires the implied capability VCM:DELETE) In addition, if an entire project is selected: VCM:PROJECT_DELETE Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Content Supervisor Knowledge Manager Line of Business Manager Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager 146 OpenText Web Experience Management Administration Guide

147 7.4. Understanding Default Roles and Capabilities Action Delete (remove) the association of the instance with a site or channel the actual instance is not deleted). (Content Workspaces only) Delete a content type definition. (Management Console only) Delete a file (delete a static file). (Content Workspaces only) Delete an object type definition (Management Console only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:MODIFY_CHANNEL_AS SOC That capability also requires the implied capability VCM:MODIFY VCM: <X>_WRITE On the content instance. That capability also requires these implied capabilities: VCM:ADD VCM:CREATE_RECORD VCM:CREATE_X VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PAYLO AD VCM:CONTENT_TYPE_DELE TE which also requires these implied capabilities: AUTH:MANAGE_CAPABIL ITIES VCM:DELETE In addition, if an entire project is selected: VCM:PROJECT_DELETE VCM:STATIC_FILE_DELET E which also requires the implied capability VCM:DELETE VCM:OBJECT_TYPE_DELET E which also requires the implied capability VCM:DELETE Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Content Contributor Content Supervisor Line of Business Manager Application Administrator Developer Knowledge Manager Application Administrator Content Contributor Content Supervisor Line of Business Manager Application Administrator Developer OpenText Web Experience Management Administration Guide 147

148 Chapter 7 Managing Authorization Action Delete a program task definition (Management Console only) Delete a folder (Content Workspaces) Delete a project (Management Console) Delete a role (Management Console only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:DELETE VCM:REGISTER_WF_PROGR AM VCM:MODIFY VCM:PROJECT_DELETE which also requires the implied capability VCM:DELETE In addition, if the project contains one or more: Content instances of type <X>: VCM:<X>_DELETE Static file(s): VCM:STATIC_FILE_DEL ETE (which also requires the implied capability VCM:DELETE) Bulk Delete for projects requires delete capabilities for all items in the project or the bulk delete will fail. VCM:ROLE_DELETE which also requires these implied capabilities: AUTH:MANAGE_ROLE VCM:DELETE Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Developer Application Administrator Content Supervisor Developer Knowledge Manager Line of Business Manager Application Administrator Developer 148 OpenText Web Experience Management Administration Guide

149 7.4. Understanding Default Roles and Capabilities Action Delete a site. (Management Console only) Delete a static file. (Content Workspaces only) Delete a workflow definition. (Management Console only) Deny a capability to a user or group in an object's ACL. (Content Workspaces only) Export (create) a package file (Management Console only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:CHANNEL_DELETE VCM:SITE_DELETE which also requires the implied capability VCM:DELETE Bulk Delete recursively deletes all items in a site. User must have delete capabilities for all items in the site. If the site contains objects from Dynamic Portal and Dynamic Site add-on products, this action requires the capabilities to delete these objects. VCM:STATIC_FILE_DELET E which also requires the implied capability VCM:DELETE VCM:WORKFLOW_DEF_DELE TE which also requires the implied capability VCM:DELETE VCM:SECURITY_WRITE which also requires the implied capability VCM:MODIFY_ACL VCM:EXPORT_PACKAGE Also requires the appropriate READ capability for each type of object to be exported to the package file. Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Line of Business Manager Application Administrator Content Supervisor Line of Business Manager Application Administrator Developer Application Administrator Line of Business Manager Application Administrator Find all references. No capabilities required. Not applicable. Filter items. No capabilities required. Not applicable. Finish a task. No capabilities required. Not applicable. OpenText Web Experience Management Administration Guide 149

150 Chapter 7 Managing Authorization Action Grant a capability to a user or group in an object's ACL. (Content Workspaces only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:SECURITY_WRITE which also requires the implied capability VCM:MODIFY_ACL Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Line of Business Manager Import a package file using vgnimport. VCM:IMPORT_PACKAGE Also requires the appropriate CREATE, UPDATE or DELETE capability for each type of object to be created, updated or deleted on import to the remote Content Management Server. Application Administrator Move a category. Move a channel to a different location in the site hierarchy. (Content Workspaces only) Move a channel's content to a different location in the site hierarchy. (Content Workspaces only) VCM:CATEGORY_WRITE VCM:MODIFY VCM:CHANNEL_WRITE which also requires these implied capabilities: VCM:ADD VCM:CREATE_RECORD VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PAYLO AD VCM:MODIFY_CHANNEL_AS SOC which also requires the implied capability VCM:MODIFY Application Administrator Knowledge Manager Application Administrator Content Supervisor Knowledge Manager Line of Business Manager Application Administrator Content Contributor Content Supervisor Knowledge Manager Line of Business Manager 150 OpenText Web Experience Management Administration Guide

151 7.4. Understanding Default Roles and Capabilities Action Move a content type definition (Management Console only) Move an object type definition. (Management Console only) Move a folder (Content Workspaces) or project (Management Console) to a different location in the content repository Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:CONTENT_TYPE_WRIT E which also requires these implied capabilities: AUTH:MANAGE_CAPABIL ITIES VCM:ADD VCM:CREATE_RECORD VCM:CREATE_RECORD_S OURCE VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PAYLO AD VCM:OBJECT_TYPE_WRITE which also requires these implied capabilities: AUTH:MANAGE_CAPABIL ITIES VCM:ADD VCM:CREATE_RECORD VCM:CREATE_RECORD_S OURCE VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PAYLO AD VCM:MODIFY VCM:PROJECT_WRITE which also requires these implied capabilities: VCM:ADD VCM:CREATE_PROJECT VCM:CREATE_ROOT_PRO JECT Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Developer Knowledge Manager Application Administrator Developer Application Administrator Content Supervisor Developer Knowledge Manager Line of Business Manager OpenText Web Experience Management Administration Guide 151

152 Chapter 7 Managing Authorization Action Move a folder's (Content Workspaces) content to a different location in the content repository. Move a workflow definition (Management Console only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:MODIFY VCM:PROJECT_WRITE which also requires these implied capabilities: VCM:ADD VCM:CREATE_PROJECT VCM:CREATE_ROOT_PRO JECT In addition, for a: Content instance of type <X>: VCM:MODIFY_ACL VCM:<X>_WRITE Static file: VCM:STATIC_FILE_WRI TE which also requires these implied capabilities: VCM:ADD VCM:CREATE_RECOR D VCM:CREATE_STATI C_FILE VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PA YLOAD VCM:WORKFLOW_DEF_WRIT E which also requires the implied capability VCM:READ Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Content Supervisor Developer Knowledge Manager Line of Business Manager Application Administrator Developer 152 OpenText Web Experience Management Administration Guide

153 7.4. Understanding Default Roles and Capabilities Action Order channels within a site. Order subchannels within a channel. (Content Workspaces only) Publish or unpublish a: Site Channel Content item from within a site or channel (including from within a site s default channels). (Content Workspaces only) Publish the classification. Reassign a task. (Content Workspaces only) Reject a task. (Content Workspaces only) Roll back a site cloning process. Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:CHANNEL_WRITE which also requires these implied capabilities: VCM:ADD VCM:CREATE_RECORD VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PAYLO AD VCM:SITE_PUBLISH which also requires these implied capabilities: VCM:DEPLOY_AND_UNDE PLOY VCM:PROMOTE_AND_DEM OTE VCM:SNAPSHOT_CONTEN T VCM:SITE_PUBLISH which also requires these implied capabilities: VCM:DEPLOY_AND_UNDE PLOY VCM:PROMOTE_AND_DEM OTE VCM:SNAPSHOT_CONTEN T VCM:REASSIGN_WF_ACTIV ITY which also requires the implied capability VCM:WORKFLOW_SUPERVIS OR No capabilities required. No capabilities required. Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Content Supervisor Knowledge Manager Line of Business Manager Application Administrator Content Supervisor Line of Business Manager Application Administrator Content Supervisor Line of Business Manager Application Administrator Content Supervisor Developer Knowledge Manager Line of Business Manager Not applicable. Not applicable. OpenText Web Experience Management Administration Guide 153

154 Chapter 7 Managing Authorization Action Start a workflow for a: Site or channel (Content Workspaces only) Project Content item (Content Workspaces only) Workflow definition Search (for content items, associated workflows, and so on). (Content Workspaces only) Submit a static file. (Content Workspaces only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:WORKFLOW_DEF_READ which also requires these implied capabilities: VCM:CREATE_WF_PAYLO AD VCM:READ No capabilities required. VCM:STATIC_FILE_WRITE which also requires these implied capabilities: VCM:ADD VCM:CREATE_RECORD VCM:CREATE_STATIC_F ILE VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PAYLO AD Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Content Supervisor Developer Knowledge Manager Line of Business Manager Not applicable. Application Administrator Content Contributor Content Supervisor Line of Business Manager View capabilities associated with a role (Management Console only) VCM:ROLE_READ Application Administrator Developer View categories VCM:CATEGORY_READ Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager 154 OpenText Web Experience Management Administration Guide

155 7.4. Understanding Default Roles and Capabilities Action Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) Roles that Have the Required Default WEM Capabilities (or their equivalent) View channels (a list of channels in a site or subchannels within a channel). (Content Workspaces only) View content type definitions. View a list of the content items in a folder/project and its subfolders VCM:SITE_READ Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager VCM:CONTENT_TYPE_READ Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager VCM:CONTENT_READ Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager View Help No capabilities required. Not applicable. View object type definitions. (Management Console only) VCM:OBJECT_TYPE_READ Application Administrator Content Supervisor Developer Line of Business Manager View program tasks (Management Console only) VCM:REGISTER_WF_PROGR AM Application Administrator Developer View the properties of an application asset. VCM:STATIC_FILE_READ Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager OpenText Web Experience Management Administration Guide 155

156 Chapter 7 Managing Authorization Action View the properties of a channel or subchannel (or a content instance of type X within either). (Content Workspaces only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:CHANNEL_READ VCM:X_READ or VCM:STATIC_FILE_READ as applicable Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager View the properties of a classification category. View properties of a contenttype definition. VCM:CATEGORY_READ Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager VCM:CONTENT_TYPE_READ Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager View the properties of a content instance of type X in a project. (Content Workspaces only) VCM:PROJECT_READ VCM:READ VCM: X_READ Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager View the properties of an object-type definition. (Content Workspaces only) VCM:OBJECT_TYPE_READ Application Administrator Content Supervisor Developer Line of Business Manager View the properties of a program task definition (Management Console only) VCM:MODIFY VCM:REGISTER_WF_PROGR AM Application Administrator Developer 156 OpenText Web Experience Management Administration Guide

157 7.4. Understanding Default Roles and Capabilities Action View the properties of a folder/project or a content item in a folder/project. (Content Workspaces only) Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) VCM:PROJECT_READ VCM:READ In addition, for a: Content instance of type X: VCM:X_READ Static file: VCM:STATIC_FILE_REA D Roles that Have the Required Default WEM Capabilities (or their equivalent) Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager View the properties of a role. (Management Console only) View the properties of a site. (Content Workspaces only) VCM:ROLE_READ Application Administrator Developer VCM:SITE_READ Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager View the properties of a static file in a folder/project. (Content Workspaces only) View the properties of a workflow definition. (Content Workspaces only) View the properties of a workflow instance (started, completed, cancelled, terminated) VCM:PROJECT_READ VCM:READ VCM:STATIC_FILE_READ VCM:WORKFLOW_DEF_READ which also requires these implied capabilities: VCM:CREATE_WF_PAYLO AD VCM:READ VCM:READ VCM:WORKFLOW_READ Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager Application Administrator Content Supervisor Developer Knowledge Manager Line of Business Manager Application Administrator Content Supervisor Developer Knowledge Manager Line of Business Manager OpenText Web Experience Management Administration Guide 157

158 Chapter 7 Managing Authorization Action Required Capabilities (both default WEM capabilities and capabilities associated with user-defined content instances) Roles that Have the Required Default WEM Capabilities (or their equivalent) View roles (Management Console only) View the security settings (ACL) of an object. View sites (or a list of sites). (Content Workspaces only) View the workbench (Management Console only) VCM:ROLE_READ Application Administrator Developer VCM:SECURITY_READ Application Administrator Line of Business Manager VCM:SITE_READ Application Administrator Content Contributor Content Supervisor Developer Knowledge Manager Line of Business Manager VCM:WORKBENCH_READ Application Administrator Content Supervisor Developer Knowledge Manager Line of Business Manager View workflow definitions (a list of workflow definitions) View a specific workflow definition View which workflow definition instances have been cancelled, completed, started, or terminated VCM:WORKBENCH_READ VCM:WORKFLOW_DEF_READ which also requires these implied capabilities: VCM:CREATE_WF_PAYLO AD VCM:READ Application Administrator Content Supervisor Developer Knowledge Manager Line of Business Manager Command Line Utilities: Required Capabilities/Roles Per Action on page 159 shows what capabilities a user must have in order to perform specific actions from the command line utilities: 158 OpenText Web Experience Management Administration Guide

159 7.4. Understanding Default Roles and Capabilities Table 7-4: Command Line Utilities: Required Capabilities/Roles Per Action Action Required Capabilities Roles that Have the Required Default WEM Capabilities (or their equivalent) Add a product administrator VCM:ADMINISTRATOR Application Administrator cfgedit: View the nodes and variables under a given node (list) cfgedit: View the nodes and variables found in a specified configuration hierarchy path or in the current directory (list) cfgedit:) View the configuration files affected by the pending set of changes (listchgs cfgedit: View the pending changes for a product instance (listchgs) cfgedit: View the product components that use a given variable (listuses) cfgedit: Set the value of a variable (set) No capabilities required. As long as you are logged in to the command line utility with a user ID and password that are valid in your LDAP repository, you can view the nodes and variables under a given node No capabilities required. As long as you are logged in to the command line utility with a user ID and password that are valid in your LDAP repository, you can view the nodes and variables under a given node No capabilities required. As long as you are logged in to the command line utility with a user ID and password that are valid in your LDAP repository, you can view the nodes and variables under a given node No capabilities required. As long as you are logged in to the command line utility with a user ID and password that are valid in your LDAP repository, you can view configuration settings. No capabilities required. As long as you are logged in to the command line utility with a user ID and password that are valid in your LDAP repository, you can view configuration settings. Not applicable. Not applicable. Not applicable. Not applicable. Not applicable. VCM:ADMINISTRATOR Application Administrator OpenText Web Experience Management Administration Guide 159

160 Chapter 7 Managing Authorization Action Required Capabilities Roles that Have the Required Default WEM Capabilities (or their equivalent) cfgedit: Set an override value for a variable for a particular product component (set) cfgedit: Revert current changes (revert) cfgedit: Push the current set of changes out to the affected configuration files (push) cfgedit : Commit the current set of changes for a product instance (commit) Commit configuration and Configuration Agent changes (commit) configp : Set the logging level to DEBUG VCM:ADMINISTRATOR Application Administrator VCM:ADMINISTRATOR Application Administrator VCM:ADMINISTRATOR Application Administrator VCM:ADMINISTRATOR Application Administrator VCM:ADMINISTRATOR Application Administrator VCM:ADMINISTRATOR Application Administrator Create a configuration agent VCM:ADMINISTRATOR Application Administrator Create a configuration file for a configuration agent vgnexport: Create (export) a package file VCM:ADMINISTRATOR Application Administrator VCM:CREATE_PACKAGE_FI LE Application Administrator Delete a configuration agent VCM:ADMINISTRATOR Application Administrator Export (create) a package file VCM:EXPORT_PACKAGE Application Administrator Import a package file VCM:IMPORT_PACKAGE Application Administrator Push configuration and Configuration Agent changes Remove a configuration agent Windows Service Restore a configuration file for a configuration agent Revert configuration and Configuration Agent changes VCM:ADMINISTRATOR Application Administrator VCM:ADMINISTRATOR Application Administrator VCM:ADMINISTRATOR Application Administrator VCM:ADMINISTRATOR Application Administrator 160 OpenText Web Experience Management Administration Guide

161 7.4. Understanding Default Roles and Capabilities Action Required Capabilities Roles that Have the Required Default WEM Capabilities (or their equivalent) Start or stop a configuration agent Start a Web Experience Management Managed Process (VMP) vgnexport: Create (export) a package file vgnimport: Import a package file View (list) configuration settings VCM:ADMINISTRATOR Application Administrator VCM:ADMINISTRATOR Application Administrator VCM:EXPORT_PACKAGE Also requires the appropriate READ capability for each type of object to be exported to the package file. VCM:IMPORT_PACKAGE Also requires the appropriate CREATE, UPDATE or DELETE capability for each type of object to be created, updated or deleted on import to the remote Content Management Server. No capabilities required. As long as you are logged in to the command line utility with a user ID and password that are valid in your LDAP repository, you can view configuration settings. Application Administrator Application Administrator Not applicable Generated Capabilities for New Content Type Definitions When you create a new content type definition, the WEM software automatically creates a new set of capabilities for it, basing the names of those capabilities on the XML name of the new content type definition. For example, if you create a new content type definition for an article and give it an XML name of Article, the WEM software creates a set of capabilities named VCM:Article_READ, VCM:Article_WRITE, and VCM:Article_DELETE for the new content type definition. The set of capabilities created is pre-determined and cannot be changed. Note: When you create a content type definition, be sure you update any affected roles with the new capabilities associated with the new definition. Otherwise, only the WEM administrator will be able to access content instances of the newly-created content type. OpenText Web Experience Management Administration Guide 161

162 Chapter 7 Managing Authorization When you create or import a content type definition, its generated capabilities are created on the current Content Management Server. Before you import a content instance on a different Content Management Server, you must create or import its corresponding content type definition Capabilities Required for Workflow Workflow tasks require the following capabilities: VCM:CANCEL_WF_ACTIVITY VCM:MANAGE_WF_ACTIVITY VCM:MODIFY VCM:MODIFY_WF_PAYLOAD VCM:READ VCM:REASSIGN_WF_ACTIVITY If a workflow must be started automatically when a content instance is created or updated, you must grant the workflow rights to the group, and also the appropriate create and update capabilities to your roles. There are two ways to grant the workflow rights to a group: Create a subproject of the Workflow Definitions project, put the workflow definition in the subproject, and then assign the appropriate group as the Authorized Group for that subproject. This is the preferred method. Use the advanced Access Control Settings (ACL settings) directly in the workflow definition properties to grant the group the required rights Capabilities Required for Objects in a Publishing Job For all objects that are explicitly or implicitly included in a publishing job, you must grant the following capabilities: VCM:DEPLOY_AND_UNDEPLOY VCM:PROMOTE_AND_DEMOTE VCM:SNAPSHOT_CONTENT If that job contains a content instance with a Content Type Definition that has not yet been published, the Content Type Definition will be included in the job automatically. Therefore, you must provide the necessary capabilities on the Content Type Definition before the job is published. Other objects, such as the Channel in which the item selected for publishing resides, may also be added to the job. Make sure that all the capabilities needed for the job have been provided. 162 OpenText Web Experience Management Administration Guide

163 7.5. Creating and Editing Roles 7.5 Creating and Editing Roles Before you begin: You must have the AUTH:ADMINISTRATOR capability (or AUTH:MANAGE_CAPABILITIES and AUTH:MANAGE_ROLE capabilities) to change capabilities for existing roles or to create custom roles with the Management Console's Roles feature. The Management Console's Roles feature allows authorized users to perform the following: View existing roles and capabilities Modify existing roles by assigning or deleting capabilities Modify existing roles by assigning or deleting other roles Create a new role and assign capabilities and other roles to it Search for a user name to see its effective capabilities Accessing Roles, Users, and Groups Use the Roles feature to access roles, users, and groups. The Roles feature allows you to approach management of roles, users and groups in two different ways. You can: Select a role, and manipulate the users and groups associated with that role. Select a user or group, and manipulate the roles granted to that user or group. The following paragraphs tell how to access the Roles feature in the Management Console, and give general instructions for taking each approach. See also: Note: For security reasons, the Management Console closes the user session after 30 minutes of inactivity. After that, you must log in again to continue working. Help for the Roles feature in the OpenText Web Experience Management - Management Console Online Help (WCMGT-H-ACM). Default Roles on page 124 Default Capabilities on page 135 To manipulate users and groups associated with a role: 1. Log in to the Management Console with a valid user name (and password). Note: If you want to create new roles or change existing role/capability assignments, you must log in with a user ID that has the Authorization Administrator role or the AUTH:ADMINISTRATOR capability. 2. In the Management Console, select Workbench > Roles. OpenText Web Experience Management Administration Guide 163

164 Chapter 7 Managing Authorization 3. Click on a role to open the role's Properties window. 4. Perform whatever roles-oriented actions that you need to. For information about how to perform specific actions, see the OpenText Web Experience Management - Management Console Online Help (WCMGT-H-ACM). 5. Close the Management Console when you complete your actions. To manipulate the roles granted to a user or group: 1. From the Management Console, select Workbench > Roles. 2. Click Find Users or Find Groups in the Tool Bar. 3. Supply the full or partial user or group name that you want to locate. You may also use wildcards in the User Name field. 4. Click on the selected user or group to open its Properties window. 5. Perform whatever roles-oriented actions that you need to. For information about how to perform specific actions, see the OpenText Web Experience Management - Management Console Online Help (WCMGT-H-ACM). See also: Help for the Roles feature in the OpenText Web Experience Management - Management Console Online Help (WCMGT-H-ACM), for information on how to perform specific role-oriented actions Default Roles on page 124 Default Capabilities on page Capabilities Provided with All Roles Any role, be it a default role or a role that you create, automatically contains the following capabilities: VCM:ADD VCM:CREATE_RECORD VCM:CREATE_RECORD_SOURCE VCM:CREATE_WF_PAYLOAD VCM:DELETE VCM:DEPLOY_AND_UNDEPLOY VCM:MANAGE_WF_PROCESS VCM:MODIFY VCM:MODIFY_ACL VCM:MODIFY_WF_PAYLOAD 164 OpenText Web Experience Management Administration Guide

165 7.5. Creating and Editing Roles VCM:PROMOTE_AND_DEMOTE VCM:READ VCM:SNAPSHOT_CONTENT Caution You can add other capabilities to any role; however, do not delete any of the preceding capabilities from any role (new or default). Doing so will cause the WEM software to function improperly. Even though all newly-created roles receive these capabilities, you must manually add the implied capabilities for each capability in the preceding list, based on what tasks the new role will allow a user or group to perform. To see the implied capabilities, see Table 7-5: Implied Capabilities Required for User-Created Roles on page Additional Capabilities Required for User-Created Roles When you create a new role, the role is granted the basic set of capabilities mentioned in Capabilities Provided with All Roles on page 164. You can grant the role additional capabilities. In fact, to work correctly, a capability that you add may require the role to have one or more other capabilities as well For example, if you grant the VCM:PROJECT_WRITE capability to a role, the role must also have these capabilities: VCM:ADD, VCM:CREATE_PROJECT, and VCM:CREATE_ROOT_PROJECT. That means you must grant the role the VCM:CREATE_PROJECT and VCM:CREATE_ROOT_PROJECT capabilities (the role will have the VCM:ADD capability by default). You can grant the additional capabilities with the Role Manager in the Management Console. Implied Capabilities Required for User-Created Roles on page 165 lists the additional (implied) capabilities. Table 7-5: Implied Capabilities Required for User-Created Roles If you add this capability to a role... VCM:CATEGORY_DELETE VCM:CHANNEL_DELETE VCM:CHANNEL_WRITE VCM:CONTENT_TYPE_DELETE You must also add these capabilities... VCM:DELETE VCM:DELETE VCM:ADD, VCM:CREATE_RECORD, VCM:MODIFY, VCM:MODIFY_ACL, VCM:MODIFY_WF_PAYLOAD VCM:DELETE, AUTH:MANAGE_CAPABILITIES OpenText Web Experience Management Administration Guide 165

166 Chapter 7 Managing Authorization If you add this capability to a role... VCM:CONTENT_TYPE_WRITE VCM:CONTENT_TYPE_<X>_DELETE CM:CONTENT_TYPE_<X>_WRITE VCM:MODIFY_CHANNEL_ASSOC VCM:OBJECT_TYPE_DELETE VCM:OBJECT_TYPE_WRITE VCM:PROJECT_WRITE VCM:ROLE_DELETE VCM:ROLE_WRITE VCM:SECURITY_WRITE VCM:SITE_DELETE VCM:SITE_PUBLISH VCM:SITE_WRITE VCM:STATIC_FILE_DELETE VCM:STATIC_FILE_WRITE VCM:WORKFLOW_DEF_DELETE VCM:WORKFLOW_DEF_READ VCM:WORKFLOW_DEF_WRITE VCM:WORKFLOW_SUPERVISOR You must also add these capabilities... VCM:ADD, VCM:CREATE_RECORD, VCM:MODIFY, VCM:MODIFY_ACL, VCM:MODIFY_WF_PAYLOAD, AUTH:MANAGE_CAPABILITIES, VCM:CREATE_RECORD_SOURCE VCM:DELETE VCM:ADD, VCM:CREATE_RECORD, VCM:MODIFY, VCM:MODIFY_ACL, VCM:MODIFY_WF_PAYLOAD VCM:MODIFY VCM:DELETE VCM:ADD, VCM:CREATE_RECORD, VCM:MODIFY, VCM:MODIFY_ACL, VCM:MODIFY_WF_PAYLOAD, VCM:CREATE_RECORD_SOURCE, AUTH:MANAGE_CAPABILITIES VCM:ADD, VCM:CREATE_PROJECT, VCM:CREATE_ROOT_PROJECT VCM:DELETE, AUTH:MANAGE_ROLE AUTH:MANAGE_ROLE VCM:MODIFY_ACL VCM:DELETE VCM:PROMOTE_AND_DEMOTE, VCM:DEPLOY_AND_UNDEPLOY, VCM:SNAPSHOT_CONTENT VCM:ADD, VCM:CREATE_RECORD, VCM:MODIFY, VCM:MODIFY_ACL, VCM:MODIFY_WF_PAYLOAD VCM:DELETE VCM:ADD, VCM:CREATE_RECORD, VCM:MODIFY, VCM:MODIFY_ACL, VCM:MODIFY_WF_PAYLOAD, VCM:CREATE_STATIC_FILE VCM:DELETE VCM:READ, VCM:CREATE_WF_PAYLOAD VCM:READ VCM:MODIFY_WF_PAYLOAD, VCM:CANCEL_WF_PROCESS, VCM:READ, VCM:MANAGE_WF_PROCESS 166 OpenText Web Experience Management Administration Guide

167 7.6. Managing Access to Objects 7.6 Managing Access to Objects As implied in the Precedence Rules on page 122, having the right roles and capabilities does not guarantee that you can perform a task: the security settings must allow the task. For example, before you can create a content instance, the permissions set at the project level must allow the content creation. For more information about the security settings, see the OpenText Web Experience Management - Management Console Online Help (WCMGT-H-ACM), specifically the Content Module section. There you will also find the steps to set permissions for projects, content items, workflow instances, and so on. 7.7 Managing Authorization Efficiently Before you begin: Understanding Default Roles and Capabilities on page 123 Precedence Rules on page 122 Topics include: Setting a Group's Role on page 167 Synchronizing the Security Realm on page 168 Roles are a collection of capabilities. Groups provide a mechanism for collecting not only users, but roles as well Setting a Group's Role While you can assign roles to individual users, it is more efficient to organize users into groups and assign roles to the groups instead. That way, when you need to change general access for one or more users, you can leave group-to-role associations in place and simply add or remove the users from the affected groups, instead of changing each individual's roles. To grant capabilities efficiently: 1. From your LDAP Server's administrative console, create a group of users. 2. Using the Roles feature of the Management Console, assign a role to the group. This grants the group's users all the capabilities granted to the role. To create a customized version of a default role: 1. Using the Roles feature of the Management Console, create a new role. 2. Assign the capabilities of the default role (the one you want to customize) to the new role. 3. Assign the additional capabilities you want the new role to have. OpenText Web Experience Management Administration Guide 167

168 Chapter 7 Managing Authorization See also: Your LDAP Server documentation, for information on modifying a user's attributes, including group membership Synchronizing the Security Realm If the LDAP information changes, you must edit the default security realm in the domain (VgnLDAPRealm) to update it to the current LDAP information. See also: Your LDAP documentation Administering LDAP on page OpenText Web Experience Management Administration Guide

169 Chapter 8 Managing Configuration Information This chapter describes how to manage configuration information in the WEM software perform the following configurations: Media Management which is used to import media content and automations for content using the Configuration Console. User Profile Integration which enables runtime evaluation of segments and the selection of content based on user profile attributes. External Content Integration Framework and hybris Service Provider which enables incorporating content from external systems into WEM managed web sites. 8.1 Understanding Configuration Console Programs such as the Configuration Console, configp, cfgedit, and cfgaction connect to the Content Management Server to make configuration changes. The Content Management Server, which manages the configuration information stored in the configuration tables of the WEM system database, communicates with a Configuration Agent on each product's host machine to carry out configuration changes and other tasks. You can modify a configuration by changing the values of the system configuration variables (settings) used to define its configuration information. Variables exist for each WEM component and its associated subcomponents and processes. For specific information about how to change the values of configuration variables, see the OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) Configuration Tables and Files Configuration variables are maintained in both the configuration tables and in component-specific configuration files. The configuration information for each component is contained in its corresponding component-level configuration file. For example, variables for Deployment Agent are located in the da.cfg file. The configuration tables are the repository of the configuration information stored in the configuration files. OpenText Web Experience Management Administration Guide 169

170 Chapter 8 Managing Configuration Information Configuration Console Variables Configuration variables and their values are stored in configuration files and also in configuration tables located in the WEM system database. You use the Configuration Console (preferred method) or the cfgedit utility to view and/or change the values for configuration variables. When you run the Configuration Console, you access configuration information by connecting to the Content Management Server. The Configuration Console presents the configuration information for that server in a graphical tree hierarchy that includes all configuration-related Web Experience Management products. For an explanation of the icons in the configuration tree, see OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC). The tree structure is organized roughly according to the following hierarchy: Configuration Console Product Instance (WEM) CDS Folder (Delivery Services) Component (Content Management Stage) Component (Content Delivery Services - mgmt) Folder (Deployment Agents) Process (Deployment Agent - mgmt) Folder (Custom Properties) Folder (Resources) Process (Application Services) Folder (Resources) Component (Content Delivery Stage - Production) Component (Content Delivery Services - Production) Folder (Deployment Agents) Process (Deployment Agent - Appsvcs) Folder (Custom Properties) Folder (Resources) Process (Application Services) Folder (Resources) 170 OpenText Web Experience Management Administration Guide

171 8.1. Understanding Configuration Console CMS Folder (Content Management Services) Component (Management Console) Process (WEM Server) Folder (Configuration Agents) Folder (Subcomponents) The Configuration Agents folder has configuration information for the Configuration Agents associated with a particular Content Management Server. The Subcomponents folder has configuration information for the Content Management Server (log, authorization, and communication variables, and so on). Click a particular component or process level in the tree to show in the right pane the configuration variables and values associated with that component or process. For specific information about the icons in the Configuration Console and about navigation, see the OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) Configuration Terms A number of terms are useful in discussing Configuration Console tree and configuration data. Term component component node configuration file Definition An identifiable unit of a product. A component may be: A process (for example, a Deployment Agent) A subcomponent of a process (for example, a logging subcomponent) A logical grouping of processes A node in the configuration tree that represents a component. A file that contains configuration data used by a component. OpenText Web Experience Management Administration Guide 171

172 Chapter 8 Managing Configuration Information Term configuration path Definition A simulated file system representation of the hierarchical arrangement of components and subcomponents in which configuration variables and their values are stored in the WEM system database. For example: /cs/cfs/cs_working_dir /vcm-vgninst/cdsvcs/stage-mgmt/cdsmgmt/version Used when viewing or changing variable values with the cfgedit utility. Also viewable as a property in the Configuration Console. configuration tree level node process node product node variable The left pane in the Configuration Console. Shows a graphical view of the hierarchical arrangement of components and subcomponents similar to a file system directory structure. A general placement within the configuration tree: at a registered product level, but not a specific product. An object that can contain other nodes and variables. Analogous to a directory in a file system. A node can represent a product, a component, or a process. A node in a configuration tree that represents a running process. For example, a Configuration Agent or a logging subcomponent. A node that represents the WEM product instance. A named unit of configuration data of interest to a component. For example: TEMP_DIR and LOG_LEVEL. Every variable has a parent node. You can optionally encrypt the value of a variable Change Tracking In the Configuration Console, you can edit a variable and push the change out to the configuration file(s) to test the change before committing the change to the WEM system database. If you decide not to make the change permanent by committing it, you can also revert to the previously committed value. The Configuration Console displays the state of variables and pending changes so that you know which changes require action and what they will affect. See also: Note: We recommend you use the Configuration Console for all configuration management tasks. Using the Configuration Console on page 174 cfgedit on page 235, for information on this editing command 172 OpenText Web Experience Management Administration Guide

173 8.1. Understanding Configuration Console cfgaction on page 223, for information on this batch-mode command Testing Variable Changes on page Configuration Agents The Content Management Server sends configuration information entered via the Configuration Console or configp to processes called Configuration Agents, which manage the configuration of WEM components. Every host that contains a WEM component must have a Configuration Agent. When creating a Configuration Agent, you must decide whether that agent must be connected or disconnected. A connected Configuration Agent is the type of Configuration Agent you create if you have no firewall that disallows communication from a remote host to your Content Management Server host (the remote host in this case being the one on which you are creating the Configuration Agent). A disconnected Configuration Agent is what you create when security requirements prevent you from creating a hole, even temporarily, in a firewall that prevents communication from a remote host to your Content Management Server host (the remote host in this case being the one on which you are creating the Configuration Agent). Normally, when you create a Configuration Agent on a remote host, that agent opens an initial connection to the Content Management Server and registers itself; that is, it sends its host name and port number to the Content Management Server. The Content Management Server requires that host/port information to send configuration information to the remote Configuration Agent. However, if you cannot open a hole in your firewall, a remote Configuration Agent cannot open an initial connection to the Content Management Server. To overcome this limitation, you create a disconnected Configuration Agent one that does not attempt to create the initial connection with the Content Management Server. After creating the disconnected agent, you go to the Content Management Server host and register the disconnected agent manually. Once registered, the Configuration Agent is connected; that is, the Content Management Server now has the host/port information necessary to send configuration information to the remote Configuration Agent. The Configuration Agent has no further need to send information back to the Content Management Server host; therefore, your firewall restrictions are left intact. See also: OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) To create a connected Configuration Agent: on page 225 To create a disconnected Configuration Agent: on page 225 OpenText Web Experience Management Administration Guide 173

174 Chapter 8 Managing Configuration Information To register a disconnected Configuration Agent: on page Using the Configuration Console Before you begin: To use the Configuration Console, you must be a valid WEM user and have the appropriate capabilities and permissions for performing various actions. The Configuration Console is a web application for managing configuration data for all WEM components. The Configuration Console lets you: Task Create a connection to the Content Management Server View products and components known to the Content Management Server View and edit configuration variables for product components For more information, see OpenText Web Experience Management - Planning and Installation Guide (WCMGT-IGD) OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) Creating, Changing, or Deleting Configuration Variables on page 175 Monitor product component status OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) Monitoring the WEM Software on page 189 Execute configuration actions for product components (Available actions depend on the selected component) Performing Configuration Actions on page Understanding Capabilities and Permissions To use the Configuration Console, you must be a valid WEM user and have the appropriate capabilities and permissions for performing various actions. Specifically, if you only want to view the configuration, you just need a valid user ID and password in your LDAP repository. However, if you need to add, modify or delete various components, you must also have the WEM Administrator role. 174 OpenText Web Experience Management Administration Guide

175 8.1. Understanding Configuration Console Starting the Configuration Console The following paragraphs tell how to start the Configuration Console. To start the Configuration Console: Open a browser and navigate to one of the following URLs: where <host> is the name or IP address of the host on which the Content Management Server is running, and <port> is the Content Management Server port number. By default, the HTTP port number is 27110, and the HTTPS (SSL) port number is See also: OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC), for information on navigating the Configuration Console Getting Help To open online help, Select Help > WEM Configuration Console Help from the browser menu bar. See also: Note: The Role Manager help is separate from the OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H- ACC). You access it from the Role Manager itself. Accessing Roles, Users, and Groups on page 163 OpenText Web Experience Management - Management Console Online Help (WCMGT- H-ACM), for more information on using the WEM Role Manager Creating, Changing, or Deleting Configuration Variables Each piece of a WEM configuration can have one or more variables associated with it. In the Configuration Console, variables for a level are displayed in the right-hand pane of the console. You create, delete, or make changes to the values of variables by clicking the variable and editing its value. You apply these changes (push, revert, or commit) at the WEM product instance level). Only the configuration files within the product instance that use the variable receive the change. To create a variable: 1. In the Configuration Console, select the component or node in the configuration tree. Previously existing variables for the node are shown in the right-hand pane. OpenText Web Experience Management Administration Guide 175

176 Chapter 8 Managing Configuration Information 2. Right-click in the Details pane and select New > Create Variable from the popup menu. 3. Provide the name and value in the Create Variable pop-up menu, and click Create. Alternately, you can click Browse and select a file whose contents the Configuration Console will read into the value of the new variable. At this point, you have set the Config Value for the variable, but you have not altered the configuration data that the component or process is actually using. To do so, you must push the new value to the component's configuration file. See To push, revert, or commit actions performed on a configuration variable: on page 176. To delete a variable: 1. In the Configuration Console, select the component or node in the configuration tree. Variables for the node are shown in the right-hand pane. 2. Right-click the variable to be deleted, and select Delete from the pop-up menu. 3. Click Yes to confirm your deletion. At this point, you have set the Config Value for the variable, but you have not altered the configuration data that the component or process is actually using. To do so, you must push the new value to the component's configuration file. See To push, revert, or commit actions performed on a configuration variable: on page 176. To change a variable: 1. In the Configuration Console, select the component or node in the configuration tree. The variables for the node are shown in the right-hand pane. 2. Select a variable to open its Properties window. Change the variable value, either by editing it directly or by clicking Browse and selecting a file whose contents the Configuration Console will read as the new value of the variable. 3. When you apply the change (by clicking Save, which closes the Properties window) at this level, you set the Config Value for the variable, but you have not altered the configuration data that the component or process is actually using. To do so, you must push the new value to the component's configuration file. See To push, revert, or commit actions performed on a configuration variable: on page 176. To push, revert, or commit actions performed on a configuration variable: 1. Browse to: Configuration Console > Content 2. Right click WEM and select Manage Configuration Changes and one of the operations shown in the following table. The following table lists the possible operations you can choose: 176 OpenText Web Experience Management Administration Guide

177 8.1. Understanding Configuration Console Operation What Description Push Configuration and Configuration Agent Changes Sends changes to Configuration Agents, which save those changes to affected configuration file(s); for example cs.cfg and cfa.cfg. Does NOT commit the change (the revert value is the same as the last committed value), but DOES change the run value. The change can be reverted. Product Changes Sends changes to the affected configuration file(s); for example, cms.cfg and da.cfg. Does NOT commit the change (the revert value is the same as the last committed value), but DOES change the run value. The change can be reverted. Revert Configuration and Configuration Agent Changes Alters the Run Value to the value last committed to the WEM system database. Pushes the revert value to the affected configuration file(s). Does NOT commit the change (the revert value is the same as the last committed value), but DOES change the run value. The change can be reverted. Product Changes Alters the Run Value to the value last committed to the WEM system database. Pushes the reverted value to the affected configuration file(s). Does NOT commit the change (the revert value is the same as the last committed value), but DOES change the run value. The change can be reverted. Commit Configuration and Configuration Agent Changes Alters the value in the WEM system database to the new value. Pushes the new value to the affected configuration file(s). Changes the Revert Value to empty. OpenText Web Experience Management Administration Guide 177

178 Chapter 8 Managing Configuration Information Operation What Description See also: Product Changes Alters the value in the WEM system database to the new value. Pushes the new value to the affected configuration file(s). Changes the Revert Value to empty. OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC), for more information on changing and applying variable values Performing Configuration Actions Configuration Actions on page 178 describes what configuration actions you can perform from the Configuration Console, and specifies from which configuration tree level the action must be performed. Table 8-1: Configuration Actions Configuration Tree Level Configuration Services level Content Management Server Component level Action Manage Configuration Settings Data Source Tasks File Source Tasks Create a Deployment Agent Where to Find More Information Creating, Changing, or Deleting Configuration Variables on page 175 OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) Deployment Agent level Add Content Subscriptions OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) Deployment Agent Tasks OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) 178 OpenText Web Experience Management Administration Guide

179 8.1. Understanding Configuration Console Configuration Tree Level Content Subscription Level Action Content Subscription Tasks Content Handler Configuration Tasks Remove Content Subscription Where to Find More Information OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) Changing and Testing Configuration Variables Before you modify a configuration variable, it helps to understand how the WEM components are related in a configuration. This information is explained in detail in the OpenText Web Experience Management - Planning and Installation Guide (WCMGT- IGD) How Variables Get Values Most variables have a default value set at initial configuration. How and where a variable is defined by default varies, depending on the type of information represented by the variable. The Content Management Server uses one of the following methods to define the default value of each configuration variable: Method Explanation How you access the variable At compone nt level By reference The variable is defined at the component or subcomponent level of the Configuration Console tree structure Some variables are defined so that the system looks at, or references, another variable for the value. Such relationships can be defined across components in the Configuration Console tree structure. A reference variable appears both at its origin point and at a reference point. You can determine a reference variable by the presence of a Set Override option in its Properties window. View and/or modify the variable at the component level View and/or modify the variable at the point of origin and push its value out to the reference point. View and/or modify the variable at the reference point and set an override. Note: If you set an override for a variable, its value does not change when the referenced value is changed. OpenText Web Experience Management Administration Guide 179

180 Chapter 8 Managing Configuration Information See also: OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC), for more information on the Configuration Console tree structure Testing Variable Changes When tuning a configuration, you can: 1. Change one or more configuration variables somewhere in a product instance's configuration information. Note: Some variables are for internal system use only and cannot be edited. 2. Push the changes to the appropriate configuration files for the product instance. Note: If you must restart a process to read the new configuration file values, the interface tells you. 3. Let the process run to test the result. 4. Choose one of the following options: Commit the change(s) to the WEM system database if you like the result of the new value(s). Change the value(s) and push the change(s) to the configuration file(s) again to test. Revert the value(s) to the last value(s) that were committed. Because changes to some variables require stopping and restarting a component and/or its processes, it is often more efficient to change several variables and push the changes all at once. To support this, the Content Management Server tracks the state of a product instance (committed, changed, or pushed) as well as the states of individual nodes and variables within that product instance. The Content Management Server likewise tracks the state of changes to its own configuration information and that of its agents and subcomponents. These states hold the action that should be performed when you commit the product instance changes. This change tracking allows you to amass a set of changes and apply them at once. Note: The Configuration Console displays the value of a given variable in its right pane when an object is selected (in the Config Value, Run Value, and Revert Value columns). Variable values also appear in the variable's Properties pane (in the text fields with these same labels) when you select the variable. It also tracks the variable's change state in the State column of the right pane. See Variable States on page 181, for more information on these values. 180 OpenText Web Experience Management Administration Guide

181 8.1. Understanding Configuration Console Variable States At any given time, a node or variable can be in one of these states: State Unchanged Changed Changed (Pushed) Node or variable is: Committed and has not been changed Changed but not committed Changed and pushed but not committed To support the Changed state, the Content Management Server tracks these value types for a variable (as labeled in each variable's Properties window and in the Configuration Console right pane): Value Config Value Default Value Run Value Revert Value Description If the variable is in the Changed state, the new value for the variable. Otherwise, the Config Value is empty. The value at install or configuration time. You can change to this value by using the Reset button in the Properties window. The value of the variable currently being used by the running process(es). The last committed value. When the variable is in the Changed state, the revert value is the value that will be used by running process(es) if the current change is reverted. Otherwise, the revert value equals the run value Product Instance State The product instance can be in one of the following states: State U (Unchanged) C (Changed) P (Pushed) The product instance is Committed and not changed Changed and not committed or pushed Changed and the changes have been pushed to the configuration file(s) See also: Creating, Changing, or Deleting Configuration Variables on page 175, for information on using the Configuration Console to apply changes OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC), for procedural information on applying, reverting, and committing variable changes OpenText Web Experience Management Administration Guide 181

182 Chapter 8 Managing Configuration Information 8.2 Configuring Media Management This section describes how to configure OpenText Media Management on both Management and Delivery stages, as well as creating Media Management automations. A full description of automations and their uses can be found in the OpenText Web Experience Management - Content Workspaces Help (WCMGT-H-UGD) Configuring Media Management using CLI commands Configure Media Management using the cfgaction command. To configure Media Management: 1. Create the property file: cfgaction -h <host>:<wemserverport> -u <user> -p <password> -l properties -a CONFIGURE_WMM -d <CDS-Application Services-Config Path> -o <properties-file-name> Example..\bin> cfgaction -h IN05501:7021 -u vgnadmin -p vgnadmin -l properties -a CONFIGURE_WMM -d /vcm-test/cdsvcs/stage-mgmt/cdsmgmt/as -o wmm.txt 2. Configure Media Management: cfgaction -h <host>:<wemserver_port> -u <user name> -p <password> -a CONFIGURE_WMM -d <CDS-Application Services-Config Path> -i <properties-file-name> -e Example..\bin> cfgaction -h IN05501:7021 -u vgnadmin -p vgnadmin -a CONFIGURE_WMM -d /vcm-test/cdsvcs/stage-mgmt/cds-mgmt/as -i wmm.txt -e Configuring Media Management Using the Configuration Console To configure Media Management on a Management Stage: 1. Log into the Configuration Console. 2. Navigate to Configuration Console Content Delivery Services Content Delivery Stage - <delivery stage name> Content Delivery Services - <delivery stage name> Application Services 3. Right-click Application Services. 182 OpenText Web Experience Management Administration Guide

183 8.2. Configuring Media Management 4. Navigate to Web Media Management Actions > Configure Web Media Management. 5. (If Split DB is configured only) Select one of your data sources from the Data sources list. The Web Media Management tables will be created in the Data source selected 6. Click Finish to configure Web Media Management. To configure Media Management on the Delivery Stage: 1. Log into the Configuration Console. 2. Navigate to Configuration Console Content Content Delivery Stage - <delivery stage name> Content Delivery Services - <delivery stage name> Application Services 3. Right-click Application Services. Note: The right-click menu is populated only when Web Media Management is configured on the Management stage. 4. Select Web Media Management Actions > Configure Web Media Management. 5. Click Finish. The Web Media Management tables are created in the AppSvcs Resource Data source of the Delivery Stage CDS Removing the Media Management Configuration This section describes how to remove the Media Management configuration using either the command line interface or the Configuration Console Removing the Media Management configuration using cfgaction To remove the Media Management configuration using cfgaction 1. In the command line, change to the <WEMinstallDir>/Content/10_5/bin directory. 2. Enter the following command: cfgaction -h <host>:<wemserver-port> -u <user> -p <password> -a UNCONFIGURE_WMM -d <CDS-Application Services-Config Path> -i wmm.txt -e Example OpenText Web Experience Management Administration Guide 183

184 Chapter 8 Managing Configuration Information..\bin cfgaction -h IN05501:7021 -u vgnadmin -p vgnadmin -a UNCONFIGURE_WMM -d /vcm-test/cdsvcs/stage-mgmt/cds-mgmt/as -i <properties-file-name> -e Removing the Media Management configuration using the Configuration Console This section describes how to remove the Media Management configuration using the Configuration Console. To remove the Media Management configuration on the Management Stage: 1. Log into Configuration Console. 2. Navigate to Configuration Console Content Delivery Services Content Management Stage - <delivery stage name> Content Delivery Services - <delivery stage name> Application Services 3. Right-click Application Services. 4. Navigate to Web Media Management Actions > Unconfigure Web Media Management. 5. Click Finish. To remove the Media Management configuration on the Delivery stage: 1. Log into the Configuration Console. 2. Navigate to Configuration Console Content Content Delivery Stage - <delivery stage name> Content Delivery Services - <delivery stage name> Application Services 3. Right-click Application Services. Note: The right-click menu is populated only when Web Media Management is configured on the Management stage. 4. Navigate to Web Media Management Actions > Unconfigure Web Media Management. 5. Click Finish. 184 OpenText Web Experience Management Administration Guide

185 8.2. Configuring Media Management Creating Media Management Automations Automations are scripts used to format media content while it is being imported to the Web Experience Management system. For a detailed discussion about automations and to use them, see Implementing Image and Video Transformations on page Batch Importing Assets from Media Management The batch importing utility is used to batch import assets from the External Content Sources. Media Management is the only external repository that is supported for importing content in the Bulk Import mode. When performing a batch import, the executable vgnbatchimport.bat(or.sh) file and the configuration file vgnbatchimport.properties, which define the VCM Connection details user/pwd/vcm_host are copied implicitly to the <WEMinstallDir>/Content/<version>/bin directory as part of installation. In addition, the following two files are copied to the <WORKING_DIR>/ext/batchimport implicitly when Extension Pack is configured: The sample query xml importquery.sample.xml, which defines the import criteria for selecting assets. The scheme xsd, which validates the import query. When performing the batch import, you must first configure the properties file and then execute the batch script. To perform the batch import: 1. Configure the vgnbatchimport.propertiesto provide the connection details 2. Create a query-xml file using the import.query.sample.xml file which is present at <WORKING_DIR>ext/bacth-import. 3. Execute the batch script either by providing the vgnbatchimport.properties or mentioning the properties explicitly. Usage : VgnBatchImport.bat [-h host:port] [-u username] [-p password] [-query queryxml] OR [-props propertiesfile] [-query queryxml] Alternately, the bulk import could be initiated through explicit REST call: <vcm host:port>/contentapi/importcontentinbatch/process.json? queryname=<query-xml> The progress/status of the initiated Batch Import Process could be viewed in the Background operations, under: <AppConsole/System Console/Background Operations>. The same instructions is located in the <WEMinstallDir>\vcm\inst-test\ext \batch-import\batch-import-readme file. OpenText Web Experience Management Administration Guide 185

186 Chapter 8 Managing Configuration Information 8.3 Understanding User Profile Integration The User Profile integration enables runtime evaluation of segments and the selection of content based on user profile attributes. These attributes are obtained from external user profile services and are used to tailor the content and presentation of WEM managed web sites for personalization or marketing campaigns. The User Profile integration must be configured in the Configuration Console. See Section 3 Integrations in OpenText Web Experience Management - Content Import and Integrations Guide (WCMGT-ACI) for detailed information. 8.4 Understanding the External Content Integration Framework and hybris Service Provider The External Content Integration framework provides the infrastructure and APIs which enable incorporating content from external systems into WEM managed web sites. The External Content Integration framework offers the extensible and pluggable interfaces for configuring and accessing remote content providers. Along with the OpenText Web Experience Management Dynamic Site and Portal components, the framework enables incorporating remote content into the web page design and presentation by using the following features: Pluggable Provider Interfaces External Presentation Components The preconfigured sample integration with hybris Service Provider demonstrates the example of ecommerce use case. The External Content Integration framework must be configured in the Configuration Console. See Section 3 Integrations in OpenText Web Experience Management - Content Import and Integrations Guide (WCMGT-ACI) for detailed information. 186 OpenText Web Experience Management Administration Guide

187 Chapter 9 Installing the OpenText Web Experience Management Workflow Modeler You can install the Process Workflow Modeler separately from the WEM software. The Process Workflow Modeler extends Microsoft Visio so that a workflow author can design workflow definitions, or modify the default workflow, to create repeatable processes for creating, managing, and deploying content. See also: Chapter 17 of the Section 17 Installing the OTWEM Workflow Modeler in OpenText Web Experience Management - Planning and Installation Guide (WCMGT- IGD), for information on installing the Process Workflow Modeler. OpenText Web Experience Management Administration Guide 187

188

189 Chapter 10 Monitoring the WEM Software This topic describes how to navigate the metrics tree and monitor WEM components. Audience: WEM administrators 10.1 Introduction to Metrics The WEM monitoring subsystem tracks metrics that characterize various behaviors of the WEM software. You can access these system metrics for WEM components from the Configuration Console. You can also access the metrics via HTTP or a browser in one of several output formats Metric Types Metrics involve measuring the behavior of a system. They can indicate something as simple as whether a component is up or down. Or, they can be more complex; for example, indicating how many locks exist per transaction, how many messages result from file creation, and so on. WEM metrics include: Metric Boolean Counter Datetime Duration File Description Indicates the health or status of an event or situation by true or false For example: The Content Management Server is up and running The last request was processed successfully Indicates how often an event or situation occurred For example: How many projects have been created to date? How many files have been deleted? Indicates when an event occurred on the process s host For example: When was the Content Management Server last started? When was certain configuration information last pushed? Shows how long an event took For example: How long did it take to retrieve an asset from the database? Shows the last <n> lines of a file that's being monitored for the process For example: the last 10 lines of a component's runtime.log file OpenText Web Experience Management Administration Guide 189

190 Chapter 10 Monitoring the WEM Software Metric Number String Description Shows the current quantity of a resource For example, the number of users currently connected to the Content Management Server Shows a text-string identifier For example: the name of a stage Metrics and Monitoring By default, the Configuration Console displays output from the monitors in an HTML page. As an alternative to viewing through the Configuration Console, administrators can supply URLs to a browser or other program that generates HTTP requests to have the server return information in HTML, XML, or simple character-separated format. See also: Viewing a Component's Metrics on page 190 Accessing Metrics with System Management Tools on page Viewing a Component's Metrics You can view the metrics for WEM base components through the Configuration Console. The results represent the status of the monitors at the time the data is returned. You can view information on each of these WEM software components: Configuration Agent Content Management Server Deployment Agent To view status of the monitors for a component: 1. Right-click the component in the Configuration Console and select Status from the pop-up menu. Another browser screen appears with a tree view of the monitor groups for the selected component in its left pane, and a data view in its right pane (see Figure 10-1). 2. Select an entry in the monitor tree view to see the results (data) for its monitors. 3. To update the view, select the entry again. 190 OpenText Web Experience Management Administration Guide

191 10.3. Viewing a Component's File Monitors Figure 10-1: Example of System Monitoring Console 10.3 Viewing a Component's File Monitors Web Experience Management provides monitors for a component's output files, such as a runtime.log. You can view the output through the Configuration Console. To view the last lines of a component's log file: 1. In the Configuration Console, right click the component and select Status. 2. Navigate the monitor group hierarchy and select the Log Messages entry in the component's monitors. The last lines of the log file display in the right pane. Note: The default number of lines may differ from component to component. You can also modify the number of lines to display more or fewer. To change the number of lines shown from the file monitors: 1. In the right pane of the Log Messages status, enter an integer in the Max Lines for File Monitors text field. 2. Click Refresh. The pane updates with the last <n> number of lines you specified. Note: If you specify -1, the pane displays the full output of the file monitors, up to 1M for each monitor. OpenText Web Experience Management Administration Guide 191

192 Chapter 10 Monitoring the WEM Software 10.4 Accessing Metrics with System Management Tools Administrators can supply URLs formatted to generate HTTP requests that return information in HTML, XML, or simple character-separated format Using the URL Syntax The URL syntax for retrieving monitors is: <port>/vgnstatus/<format>?<domain>:name=all Variables and options include the following: Variable <host>:<port> <format> <domain>:name Description The host name and port number of the component (Content Management Server, Deployment Agent, and so on) for which you want status. For the Content Management Server, this is the host and port of the Content Management Server managed server. For a Deployment Agent, this is the http listener. Specifies the format to return. Can be one of the following: frame html xml csv HTML frames view of the data, with the tree on the left and the data on the right. Use to view monitors with a standard browser. HTML data view with no tree XML data view with no tree Character-separated data formatted for easy import into Excel (optional) Specifies a fully qualified group name whose monitors you want to see. If not present, all the defined monitors for all groups are returned. Use this option to limit data collection to specific groups. For example, to retrieve only StaticFile-related monitors in HTML, the query would look like this: vcm-vcm<name>/vcms/staticfile:&name=all Note: You can use wildcards in the <domain> to specify all subgroups. Note: The frame views of the data present the monitor group hierarchy in the left frame and the monitors from the selected group in the right. Following are examples of such URLs for a host named redtail that has the Content Management Server located on port 27110: 192 OpenText Web Experience Management Administration Guide

193 10.4. Accessing Metrics with System Management Tools vcm-vgninst/cdsvcs/stage-devstage/\ cds-devcds/cdagents/cda-dagent1/staticfile:* vcm-vgninst/cdsvcs/stage-devstage/cds-devcds/cdagents/\ cda-dagent1/log+file+:* Changing the Separator in Returned Character- Separated Values By default, the vertical bar ( ) is the character used to separate character-separated values. You can change the separator to any other character, as long as you select one that is not a part of the returned data. For example, if the returned data uses semicolons, use something other than a semicolon as the separation character. To use a different character to separate return values: Enter the character along with the URL, using &sep=<char> in the http query string. For example: <port>/vgnstatus/csv?/opentext/vcm- <vcmname>/vcms/staticfile:&name=all&sep=^ This query returns all the static file monitors in text format where the fields are delimited with a carat (^) character Using JMX Monitoring With the support of JDK 6 in Web Experience Management version 10.5, the metrics provided by the WEM monitoring subsystem are now available via Java Management Extensions (JMX) monitoring. Following are instructions for enabling the Content Management Server for JMX monitoring and for connecting to the Content Management Server from a JMX client application Content Management Server Configuration To enable the Content Management Server for JMX monitoring, you must enable the JMX agent and configure its operation within the VgnVCMServer process. To do so, perform the following steps: 1. Open a browser and navigate to the Runtime Services Console at the following URL: where <hostname> is the name of the machine on which the Administration Server is running and <adminserverport> is the Administration Server's port number. (The default port is ) OpenText Web Experience Management Administration Guide 193

194 Chapter 10 Monitoring the WEM Software 2. Log into the Runtime Services Console using the WEM administrator username and password that you selected during the installation and setup process. 3. Click Lock & Edit in the Change Center area of the Runtime Services Console's left pane. 4. Under Domain Structure, navigate to vgndomain > Environment > Servers, and click the Servers node. 5. In the right pane, click VgnVCMServer (or the Content Management Server you want to configure). The main window displays showing tabs associated with settings for the server. 6. Select the Server Start tab. 7. Add the following system properties to the Arguments field: -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=<portnumber> where <portnumber> is the number of a free port to use for this purpose. 8. Set whatever additional system properties are required for the level of security your installation requires. In particular, see the sections on password authentication and SSL for JMX connections at: docs/technotes/guides/management/agent.html The following example value for an Arguments field would allow remote JMX client applications to connect without requiring authentication or using SSL: -Dweblogic.serverStart.allowQuotes=true -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9032 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Xrs -XX:+UseParallelGC -XX:MaxPermSize=192m -Xms512m -Xmx1024m -Dcom.vignette.jvmid=VgnVCM1 -Dcom.vignette.workingDir=C:/OpenText/WEM/vcm/inst-vgninst 194 OpenText Web Experience Management Administration Guide

195 10.4. Accessing Metrics with System Management Tools -Dcom.vignette.installDir=C:/OpenText/WEM/Content/ 10_5 - Dorg.apache.commons.logging.Log=com.vignette.logging.CommonsLogge r Warning This configuration is insecure. Any remote user who knows (or guesses) your JMX port number and host name will be able to monitor and control your Java application and platform. While it may be acceptable for development, it is strongly discouraged for production systems. 9. Click Save to save your changes. 10. Under the Change Center in the left pane, click Activate Changes. 11. If you are running a management-side cluster, repeat the preceding steps for each node in the cluster. 12. Stop and restart VgnVCMServer (or your cluster nodes). 13. Call your JMX client application as described in the following paragraph JMX Client Application Configuration To allow a JMX client application such as the Java Monitoring and Management Console (JConsole) to access the WEM monitor MBeans you must add the vgncommon.jar file from the following location to the client application's classpath: <WEMinstallDir>/Content/<version>/lib For example: C:\OpenText\WEM\Content\10_5\lib\vgncommon.jar Assuming you are calling JConsole from its bin directory, following is an example of how to call it in order to monitor a remote Content Management Server's JMX agent: jconsole J Djava.class.path=c:\Progra~1\java\jdk1.6.0_13\lib\ jconsole.jar;c:\progra~1\java\jdk1.6.0_13\lib\tools.jar;c:\opentext \WEM\Content\10_5\lib\vgncommon.jar\lib\vgncommon.jar Once you connect to the Local or Remote agent, click the MBeans tab. The client application's MBean tree will include WEM monitor beans whose names start with: /OpenText/vcm/ OpenText Web Experience Management Administration Guide 195

196 Chapter 10 Monitoring the WEM Software 10.5 XML Schema Definition for Monitoring (Tree View) The following XML schema definition (XSD) adheres to XML standards and describes the XML output format of the Status tree view in the Configuration Console: <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified"> <xs:complextype name="leveltype"> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="url" type="xs:string"/> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element name="level" type="leveltype"/> </xs:choice> </xs:sequence> </xs:complextype> <xs:element name="system"> <xs:complextype> <xs:sequence> <xs:element name="updatetime" type="xs:string"/> <xs:element name="protocolversion" type="xs:string"/> <xs:element name="nodename" type="xs:string"/> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element name="level" type="leveltype"/> </xs:choice> </xs:sequence> </xs:complextype> 196 OpenText Web Experience Management Administration Guide

197 10.6. XML Schema Definition for Monitoring (Data View) </xs:element> </xs:schema> 10.6 XML Schema Definition for Monitoring (Data View) The following XML schema definition (XSD) adheres to XML standards and describes the XML output format of the Status data view in the Configuration Console: <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified"> <xs:element name="desc" type="xs:string"/> <xs:complextype name="leveltype"> <xs:sequence> <xs:element ref="name"/> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element name="level" type="leveltype"/> <xs:element name="counter"> <xs:complextype> <xs:sequence> <xs:element ref="name"/> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element ref="desc"/> </xs:choice> <xs:element ref="value"/> </xs:sequence> </xs:complextype> </xs:element OpenText Web Experience Management Administration Guide 197

198 Chapter 10 Monitoring the WEM Software <xs:element name="boolean"> <xs:complextype> <xs:sequence> <xs:element ref="name"/> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element ref="desc"/> </xs:choice> <xs:element ref="value"/> </xs:sequence> </xs:complextype> </xs:element <xs:element name="datetime"> <xs:complextype> <xs:sequence> <xs:element ref="name"/> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element ref="desc"/> </xs:choice> <xs:element ref="value"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="number"> <xs:complextype> <xs:sequence> 198 OpenText Web Experience Management Administration Guide

199 10.6. XML Schema Definition for Monitoring (Data View) <xs:element ref="name"/> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element ref="desc"/> </xs:choice> <xs:element ref="value"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="duration"> <xs:complextype> <xs:sequence> <xs:element ref="name"/> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element ref="desc"/> </xs:choice> <xs:element name="minms" type="xs:string"/> <xs:element name="maxms" type="xs:string"/> <xs:element name="avgms" type="xs:string"/> <xs:element name="countvalue" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="string"> <xs:complextype> <xs:sequence> OpenText Web Experience Management Administration Guide 199

200 Chapter 10 Monitoring the WEM Software <xs:element ref="name"/> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element ref="desc"/> </xs:choice> <xs:element ref="value"/> </xs:sequence> </xs:complextype> </xs:element> </xs:choice> </xs:sequence> </xs:complextype> <xs:element name="log"> <xs:complextype> <xs:sequence> <xs:element ref="name"/> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element ref="desc"/> </xs:choice> <xs:element ref="value"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="name" type="xs:string"/> <xs:element name="system"> <xs:complextype> <xs:sequence> 200 OpenText Web Experience Management Administration Guide

201 10.6. XML Schema Definition for Monitoring (Data View) <xs:element name="updatetime" type="xs:string"/> <xs:element name="protocolversion" type="xs:string"/> <xs:element name="nodename" type="xs:string"/> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element name="level" type="leveltype"/> </xs:choice> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="value" type="xs:string"/> </xs:schema> OpenText Web Experience Management Administration Guide 201

202

203 Chapter 11 File Source Scans This topic provides conceptual information about bringing a set of files that are created, deleted, and/or modified by a product that is not part of the WEM product under control of the Content Management Server Introduction The WEM software allows you to create multiple file sources to manage your content. A file source defines a location within a known file system where the Content Management Server stores the static files that it manages. When you submit a file (such as a JPEG image or a text document), the Content Management Server copies that file to a directory in the file source and creates a static file managed object. You may have a set of files that are created, deleted, and/or modified by a product that is not part of the WEM product. However, you may want the WEM software to know about these files, so that you can use features such as workflow and deployment to manage the files' lifecycle, or define your own custom attributes for files attributes that can be indexed for searching. To bring such pre-existing files under Content Management Server management, you use the Configuration Console (or the configp utility) to create a file source based on the files' directory, and create a file source scan for that file source. A file source scan is a scheduled task that scans the contents of a file source directory for changes and updates the Content Management Server appropriately, for example, adding, updating, or deleting a managed object. See Scan Types on page 203 for more information. In addition, you can use the Configuration Console (or configp) to modify an existing WEM file source to create or delete a scan for that file source Scan Types There are two types of file source scans: active scans and passive scans. Note: No matter which scan type you use, the WEM software does not copy or modify scanned files; they continue to reside in the directory pointed to by the file source. However, the WEM software does create metadata for managing those files. Even though the WEM software does not modify scanned files, it must have write permission to the directory specified in the file source. That permission is required for saving versions (snapshots) of the static files that you publish. OpenText Web Experience Management Administration Guide 203

204 Chapter 11 File Source Scans Active Scans An active scan periodically scans the file system directory of its associated file source for new, updated, or deleted files. If the scan finds a new file, that is, a file not already represented as a static file managed object in the Content Management Server, it creates a static file object for the file in the Content Management Server. If the scan finds a file that has a corresponding managed object, but the modification date of the file is more recent than the modification date for has been modified in the file source directory at some point after the corresponding managed object's metadata was updated, the scan updates that metadata in the Content Management Server. If the Content Management Server has a managed object for a static file, but the scan fails to find the actual file in the file source directory, the scan deletes the managed object from the Content Management Server. When creating an active scan, you must specify a default root project, which is the base project for the managed objects created by the active scan. For example, if the file source directory is c:\mydocs, and you specify a default root project of / news/drafts/other, then an active scan which finds a new file named c:\mydocs \baseball\sea.doc would create a static file managed object with a project path of /news/drafts/other/baseball/sea.doc. Note: The placement paths of two files can never be the same since the WEM software does not allow you to create two file sources with conflicting mount points (directory names). For example: C:\mydocs\aaa and C:\mydocs\aaa Not allowed. Paths are the same. C:\mydocs and C:\mydocs\aaa Not allowed. One path contains the other. C:\mydocs\aaa and C:\mydocs\zzz Allowed. Paths are siblings and do not conflict. Similarly, the project paths of two files can never be the same. The WEM software requires all project items to have unique names, regardless of file source placement (in the case of static files). You can also specify a list of excluded paths and/or a list of excluded extensions when you create an active scan. Excluded paths indicate which files and/or directory paths (relative to the mount path of the file source) to ignore during a scan. Similarly, excluded extensions indicate which files (based on their filename extension) to ignore during a scan, for example, all files with the HTM or ZIP extension. The comparison of extensions is case-insensitive, so if you include HTM on an excluded extensions list, the file scan would ignore any file with a file name extension of HTM, htm, Htm, and so on (for example: index.htm). 204 OpenText Web Experience Management Administration Guide

205 11.3. File Source Scan Parameters Passive Scans A passive scan periodically scans the file system directory of its associated file source for modifications (updates only) of files that already have a corresponding static file managed object (that is, files which are already under control of the Content Management Server). If a passive scan determines that a file in the file source (one with a previously existing managed object) has been modified, it updates the metadata for the managed object. A passive scan never creates or deletes any managed objects File Source Scan Parameters Figure 11-1 shows the parts of a file source scan. In the figure, the parenthesized items represent the parameters that you must supply when you create a scan: Figure 11-1: Scan Timeline and Parameter Definitions The WEM software performs file scans (either active or passive) as one or more scantasks. You specify the number of files to be scanned per scantask in the filespertask parameter. If negative or zero, filespertask defaults to When determining the value for filespertask, consider that all files take the same amount of time to scan. File size has no effect on scan time. The set of scantasks required to completely scan once through a file source's directory is referred to as an iteration. The time allotted for one iteration of a scan to complete before the next iteration begins is called the period. Values for <period> are specified by the combination of an integer and a reserved keyword. The following example values are admissible for <period>: 1 YEAR A scan iteration starts once a year. 1 MONTH A scan iteration starts once a month. 12 HOUR A scan iteration starts every 12 hours. 15 SECOND A scan iteration starts every 15 seconds. OpenText Web Experience Management Administration Guide 205

206 Chapter 11 File Source Scans If the integer portion of the value for <period> is negative or zero, the scan ignores any keyword, and proceeds to perform a single scan. The time, in milliseconds, between scantasks is called the delay. If you set <delay> to a value less than 1000, the scan automatically resets it to 1000 (1000 milliseconds, that is, 1 second) Calculating Values for the Parameters For a file scan to function properly, you must set its parameters to values that are appropriate for the file source being scanned. To determine a reasonable scan period (in seconds), use the following formula: <period> = (<maxfiles>/<filespertask>) * (<filespertask>/<scanrate> + <delay>/1000) Where <period>, filespertask, and delay are defined earlier, and the other values are as follows: <maxfiles> Your estimate of the maximum number of files in the file source directory. <scanrate> Your estimate of the number of static file managed objects that can be created or updated by the Content Management Server per second. A conservative estimate is 5 static file objects per second. This number is influenced by a number of things: the number of CPUs, the speed of file system access, amount of physical memory, system load, and so on. Therefore, for a file source that contains about 100,000 files (<maxfiles>), assuming a scan rate of 5 files scanned per second (<scanrate>), scanning 500 files per scantask (<filespertask>), and a <delay> of 2000 milliseconds between scantasks, the formula would appear as follows: <period> = (100000/500) * (500/ /1000) Simplified, the formula becomes: <period> = (200) * ( ) This gives a value of seconds (or 340 minutes) for <period>. Scanning a file source directory and creating or updating static file managed objects can be I/O intensive. The values you supply for <filespertask> and <delay> allow you to throttle this I/O activity. For example, setting <filespertask> to 250, and <delay> to 5000 causes the scan to process 250 files at a time, pausing 5 seconds between each set of files. If I/O throughput is not a concern, you can have each scan iteration run without pausing between each set of files. To do so, you would set <filespertask> to your estimated <maxfiles> value. Note: An improper value for <period> can cause multiple iterations of the same scan to run concurrently, which can adversely affect performance. The 206 OpenText Web Experience Management Administration Guide

207 11.5. Limitations and Behavior implementation of file scan attempts to avoid this problem by checking to see if the most previous iteration of a scan has completed at the start of a new scan. If it has not, the current iteration is skipped. However, after one iteration is skipped, the next iteration of the scan will run unconditionally. For example, if iteration_1 is processing, and iteration_2 sees that iteration_1 has not completed, iteration_2 will be skipped. Regardless of iteration_1's completion status, iteration_3 will begin Limitations and Behavior Once a file source scan is created, you cannot modify its parameters. If you want to change any of the scan's parameters, or to change the scan type, you must remove the existing scan and create a new one. Note: Currently, there is no way to view the parameters of an existing file source scan. The only information you can retrieve is whether a file source has an existing scan associated with it or not. When you create a file source, you are asked if its contents are to be managed by the Content Management Server or by external software. If the Content Management Server manages the file source, any change to a static file managed object, its project, or the file source may affect the actual file. For example: Deleting a static file managed object causes the actual file to be deleted from the file source directory. Deleting the file source object causes all files and subdirectories in the file system directory to be deleted. Note: This information pertains to deleting a file source not a file source scan. Removing a scan from a file source has no effect on the file source's contents. If you set up a file source so that it and its contents are managed by external software, then changes as described in the preceding bulleted items will not affect files or directories in the file source directory. OpenText Web Experience Management Administration Guide 207

208

209 Chapter 12 Content Scans This topic provides conceptual information about the Content Scan utility, which allows you to manipulate Content Management Server-controlled records that exist in a database, but which are not currently under control of the Content Management Server Introduction The vgncontentscan command line utility scans a WEM content database and makes a list of all records that are not currently under Content Management Server control, but whose structures match one or more of the Content Management Server's content types that you specified when calling the command. It also makes a list of all content instances of the specified content types. Based on those lists, the utility then performs one of the following actions: If a record exists in the content database, but the Content Management Server has no corresponding content instance, the utility creates a new content instance based on the specified content type and adds that item to Content Management Server control. If a content instance exists under the Content Management Server, but the corresponding record no longer exists in the content database, the utility deletes the content instance from the Content Management Server. If the record exists and the Content Management Server contains a corresponding content instance, and if the record has been modified in the content database without the Content Management Server's knowledge since the last commit, the utility updates the content instance in the Content Management Server. It does this by triggering post-processing event listeners, thereby eliminating the need to commit the content instance beforehand. Note: If the project or channel hierarchy for a record does not exist on the target Content Management Server, vgncontentscan automatically creates that hierarchy. Additional parameters allow you to specify whether scanned items are approved and published. OpenText Web Experience Management Administration Guide 209

210 Chapter 12 Content Scans 12.2 Syntax vgncontentscan -x <xmlfilename> [-u <username>] [-w <password>] [-v] [-?] 12.3 Arguments Command line arguments for vgncontentscan include: Option Description -x <xmlfilepath> Identifies the full path to the XML input file. The XML input file contains required input parameters, including designated content types, the full path of the Application Services configuration properties file, and more. For more information, see XML Input File Parameters on page 211. <xmlfilepath> must be a fully-qualified path; for example: Windows c:\vgndata\contentscans\name_addr_ssn.xml UNIX /opt/opentext/contentscans/name_addr_ssn.xml -u <username> Specifies the user name for connecting to the Content Management Server (which is the same user name used when logging into the Management Console). You must specify this option either in the XML input file or on the command line. You also can specify it in both, although in such a case vgncontentscan uses the <username> specified on the command line and ignores the value specified in the XML input file. If putting a clear text user name and password is a security concern, only specify <username> and <password> on the command line. -w <password> Specifies the password for the Content Management Server user. You must specify this option either in the XML input file or on the command line. You also can specify it in both, although in such a case vgncontentscan uses the <password> specified on the command line and ignores the value specified in the XML input file. -v Optional. Displays which version of the vgncontentscan command you are running, which normally should have the same major and minor version number as the WEM software. -? Optional. Displays the usage statement, a brief explanation of the syntax for vgncontentscan. 210 OpenText Web Experience Management Administration Guide

211 12.4. Description 12.4 Description The vgncontentscan command is available as a batch file or shell script, which resides in the following directory: <WEMinstallDir>/Content/<version>/bin Note: You must run the vgncontentscan utility from its default directory. Do not copy it to another location and attempt to run it from there. Following are typical paths to the command, depending on where you installed the WEM software: Windows C:\OpenText\WEM\Content\10_5\bin\vgncontentscan.bat UNIX /opt/opentext/wem/content/10_5/bin/vgncontentscan Note: Before you attempt to perform a scan, be sure that all records that you want to scan from the content database have a corresponding content type defined in the Content Management Server, which matches their structure. The vgncontentscan utility has no scheduling capability (unlike the capability found with the File Scan utility). However, you can run vgncontentscan multiple times, even for the same content type, to synchronize your content instances. You can run multiple scans at the same time, each with a different set of content types specified within it. To do so, call vgncontentscan with a different XML input file for each of the scans. You can specify one or more <scan-target> elements in an XML input file. If you have more than one such element in the input file, they are executed sequentially. Inside each <scan-target> element, you can specify a single content type and project path. Therefore, you can specify multiple content types by using a separate <scan-target> element for each content type. vgncontentscan then processes the content types sequentially when it processes the <scan-target> element of each XML Input File Parameters When you call vgncontentscan, it parses the XML input file to obtain all parameters, and when it has all those parameters it begins the scan. The following paragraphs describe some of the common parameters. At a minimum, you must place the input parameters marked [Required] into the XML input file before calling vgncontentscan. Note: See Schema and Example XML Input File on page 220 to see the usage for each of the following elements and parameters. OpenText Web Experience Management Administration Guide 211

212 Chapter 12 Content Scans <scan-target>: Scan Target Parameters and Subparameters [Required] Some subelements of <scan-target> in the XML input file require you to specify information about the scanning target. Other <scan-target> subelements allow you to supply additional scanning target information. The following paragraphs discuss the <scan-target> subelements <content-type>: Content Types to Scan [Required] The values within the <content type> element tell vgncontentscan the name of the content type(s) to scan for. Note: vgncontentscan requires the value you specify in the <content-type> element to be the XML name, of the content type, not its display name <project-path>: Where to Place Scanned Items [Optional] The <project-path> element allows you to specify the project path where new content instances are placed in the target Content Management Server. If you do not specify a project path, vgncontentscan uses the default path of the specified content type <content-update-checker-class>: Checking Existing Content Instances [Optional] The <content-update-checker-class> allows you to specify a fully-qualified class name for the code you have written to check whether or not vgncontentscan should update an existing content instance for the specified content type(s). See IcontentUpdateChecker Interface on page 220 for details. If you do not supply a value for this field, vgncontentscan does not check existing content instances for update <action>: Actions to Perform [Optional] The <action> element allows you to specify a number of actions to be performed during a content scan. For example, you can specify which of the create, update, and delete actions to run during a particular scan. To specify one of these actions, you set its value to true in the XML input file. For example: <action create='true' update='true' delete='true'> The preceding line tells vgncontentscan to: 212 OpenText Web Experience Management Administration Guide

213 12.5. XML Input File Parameters Create a content instance in the Content Management Server if, while scanning the primary table of the source database for the specified Content Type, there is no previously-existing corresponding content instance. Update a content instance in the Content Management Server if: You have implemented and specified an IcontentUpdateChecker class. In this case, if the update checker determines that a record in the primary table of the content database has been changed, vgncontentscan updates the corresponding content instance. You have implemented and specified an update filter. In this case, vgncontentscan scans the content database's primary table using this filter, and for every row returned, it finds and updates the corresponding content instance in the Content Management Server. Delete a content instance in the Content Management Server if, while scanning the existing content instances in the Content Management Server, vgncontentscan finds no corresponding row in the primary table of the source database. vgncontentscan performs these actions in the following order: 1. Delete 2. Update 3. Create If you do not specify an <action> element (or if you do, but you do not specify a create/update/delete action), vgncontentscan assumes the following settings: create true update true, if <content-update-checker-class> is specified delete true The following paragraphs describe additional actions you can specify to be performed during a content scan. <non-diff-create>: Disable Checking for Previously-Existing Instances [Optional] vgncontentscan attempts to create a content instance for every row in your source database's primary table for the specified content type. By default, it first checks to see if a corresponding content instance already exists in the Content Management Server. You can, however, disable such checking, and run in non-diff create mode. When running in non-diff create mode, vgncontentscan still attempts to create a content instance for every row in your source database's primary table for the specified content type. However, it does so without first checking to see if a corresponding content instance already exists in the Content Management Server. OpenText Web Experience Management Administration Guide 213

214 Chapter 12 Content Scans Without having to check for pre-existing content instances, the scan completes much more quickly. Non-diff create mode is useful, especially when you know that no content instances of the specified content type exist in the Content Management Server. However, you can run vgncontentscan in non-diff mode even if you have existing content instances in the Content Management Server. Doing so does not overwrite existing content instances. If a content instance already exists, the creation attempt fails, and vgncontentscan logs an exception for the failed attempt to your log file. Note: When running in non-diff mode, vgncontentscan applies a Create filter if one exists and is specified in the XML input file. For more information, see Create Filter/Update Filter[Optional]. To run in non-diff create mode, set the <non-diff-create> element in your XML input file to true: <non-diff-create>true</non-diff-create> To disable non-diff create mode, reset < non-diff-create > to false. If you do not specify a value for the <non-diff-create> element, or if you do not specify an <action> element (or if you do specify an <action> element, but you do not specify a create/update/delete action), vgncontentscan assumes a value of false for <non diff create>, meaning that it will not run in non-diff create mode. <reference-check>: Disabling Reference Checking [Optional] By default, before vgncontentscan creates a content instance, it checks to see if that content instance references other content instances. If it does, vgncontentscan checks to see if the referenced item(s) exist on the target Content Management Server. If a referenced item does not exist on the Content Management Server, vgncontentscan does not create the scanned content instance on the target Content Management Server. You can disable reference checking. When reference checking is disabled, vgncontentscan does not check the target Content Management Server to see if referenced items exist there. It creates the scanned content instance on the target Content Management Server, regardless of whether referenced items already exist there. Disabling reference checking has the following advantages: Scanning performance is greatly enhanced. You can scan content instances that contain circular references. Unless reference checking is disabled, you cannot scan such items. Disabling reference checking has one disadvantage. After you have scanned a content instance that references items not on the target Content Management Server, that item will have dangling references which you must update at some point. 214 OpenText Web Experience Management Administration Guide

215 12.5. XML Input File Parameters Note: To update such references, run vgncontentscan in update mode; that is, define a <scan-target> with an action that sets update = true. In that same <scan-target> definition, provide an update filter that catches all content instances which need to be updated. For more information, see the example XML file on page Schema and Example XML Input File on page 220, as well as Create Filter/Update Filter[Optional]. Suppose you have a content type PAYROLL that references a number of content instances of type PERSONNEL, and you want to attach PAYROLL content instances without first creating the PERSONNEL content instances. To do this, you would: 1. Run vgncontentscan in create mode with reference checking turned off. 2. Create the various PAYROLL records and submit them to the Content Management Server (thereby creating the PAYROLL content instances). 3. Run vgncontentscan in update mode, using an update filter based on the create filter you used in Step 1. To disable reference checking, set the <reference-check> element in your XML input file to false: <reference-check>false</reference-check> To re-enable reference checking, reset <reference-check> to true. If you do not specify a value for the <reference-check> element, or if you do not specify an <action> element (or if you do specify an <action> element, but you do not specify a create/update/delete action), vgncontentscan assumes a value of true for <reference check>, meaning that it will perform reference checking. Create Filter/Update Filter [Optional] One way to limit the number of records to be scanned by vgncontentscan is to define a create filter and/or an update filter. You can define up to one each of these filters for each <scan target> in your XML input file. Filters simulate an SQL where clause. Use the following elements to create a filter: <create-filter><filter></create-filter> <update-filter><filter></update-filter> <table><tablename></table> <whereclause><sqlwhereclause></whereclause> In these elements, <filter> is the body of the filter, <tablename> is the name of a table in the content database that appears in the <whereclause> element, and <sqlwhereclause> is a valid where clause in an SQL SELECT statement. For example: OpenText Web Experience Management Administration Guide 215

216 Chapter 12 Content Scans <create-filter> <table>author</table> <whereclause>author.id < 1000</whereclause> </create-filter> <update-filter> <table>author</table> <whereclause>author.updated_flag = 1</whereclause> </update-filter> A table name that appears in the <whereclause> element must first be specified in the <table> element. You can have as many <table> elements as needed. When specifying a column in the <whereclause> element, be sure to fully specify that column name; for example: <tablename>.<columnname> Because XML prohibits certain character literals, you must replace those literals with valid XML entities, as shown in the following table: Literal Entity < < > > & ' & &apos; " " For example, an SQL condition such as: author.id < 100 would need to be specified in your XML input file as: author.id < 100 If you do not specify a value for the <create-filter> or <update filter> elements, or if you do not specify an <action> element (or if you do specify an <action> element, but you do not specify a create/update/delete action), vgncontentscan assumes a value of null for <create filter>/<update filter> meaning that it will not perform any filtering. 216 OpenText Web Experience Management Administration Guide

217 12.5. XML Input File Parameters <approval>: Automatically Approving Content Instances [Optional] The <approval> element allows you to specify whether vgncontentscan automatically marks all newly-created or updated content instances as approved. The default value is false (do not mark the items approved). Note: If you have set <approval> to true and you attempt to scan a content instance whose content type has not yet been approved, vgncontentscan fails immediately and sends the following message to the log: ContentType is not approved <publish>: Publishing Created or Updated Content Instances [Optional] The <publish> element allows you to specify whether or not vgncontentscan should automatically publish newly-created or updated content instances. The default value is false (do not publish). The <approval> element must be set to true if <publish> is set to true. If publish is set to true, you must specify values for the <site> and <channel> elements. The specified site and channel must already have been approved and published. If these conditions are met, vgncontentscan associates scanned content instances with the specified site and channel and also publishes those content instances. Regardless of whether <publish> is true or false, any content type(s) to be scanned must be already associated with the site <site>: Specifying the Site for Publishing [Can be Optional or Required] The value of the <site> element specifies the name of a site to be published. The site must be approved first. Also, the targeted content type(s) must be associated with this site. If you specify the <site> and <channel> elements, and <publish> is set to false, vgncontentscan associates scanned content instances with the specified site and channel; however, it does not publish the scanned content instances <channel>: Specifying the Channel for Publishing [Can be Optional or Required] The value of the <channel> element specifies the name of a channel to be published. The channel must be approved first. All newly-created or updated content instances will be associated with this channel. If you specify the <site> and <channel> elements, and <publish> is set to false, vgncontentscan associates scanned content instances with the specified site and channel; however, it does not publish the scanned content instances. OpenText Web Experience Management Administration Guide 217

218 Chapter 12 Content Scans <user>: Content Management Server User Name and Password [Optional] The <user> element in the XML input file allows you to specify the user name and password for connecting to the Content Management Server. If security is an issue and you cannot have an unencrypted password in the XML input file, specify the user and password on the vgncontentscan command line. A user name and password specified on the command line overrides those specified in the XML input file <appsvcscfgdir>: App Services Configuration File Directory [Required] You must specify the directory path to the Application Services configuration file (vgncfg.properties) in the XML input file's <appsvcscfgdir> element. This file is generally located in the following directory: <cfgagentworkingdir>/content <WEMinstname>/cdsvcs/stage <stagename>/cds <stagename>/as/conf/ where <cfgagentworkingdir> would have a value similar to the following: Windows: C:\OpenText\WEM\inst-<WEMinstname>\cfgagent UNIX: /opt/opentext/wem/inst-<vcminstname>/cfgagent and where <vcminstname> is the name of the Content Management Server instance (for example, vgninst) and <stagename> is the name of the stage (for example mgmt). Using the information in that vgncfg.properties file, vgncontentscan gets the Content Management Server instance coordinates and content database coordinates <chunksize>: Number of Rows to Process [Optional] The <chunk-size> element in the XML input file allows you to specify how many rows vgncontentscan will process before voluntarily relinquishing the CPU. The chunk size is also used for publishing if the publish parameter is set to true. In such a case, newly-created or updated content instances are published in chunks of the size specified by <chunk size>. The default value is 1. The <chunk size>, <sleep-interval>, and <thread pool size> elements allow you to control the load placed on the Content Management Server by vngcontentscan. The utility calls several operations that can cause substantial loading, not only on the Content Management Server, but on the content database 218 OpenText Web Experience Management Administration Guide

219 12.5. XML Input File Parameters server as well. Tweaking the values for the previously-mentioned elements can make the Content Management Server and content database server more responsive to other applications when vngcontentscan is running <sleepinterval>: Time between Chunk Processing [Optional] The <sleep-interval> element allows you to specify how many milliseconds vgncontentscan sleeps between processing chunks. The default value is 0. The <chunk size>, <sleep-interval>, and <thread pool size> elements allow you to control the load placed on the Content Management Server by vngcontentscan. The utility calls several operations that can cause substantial loading, not only on the Content Management Server, but on the content database server as well. Tweaking the values for the previously-mentioned elements can make the Content Management Server and content database server more responsive to other applications when vngcontentscan is running <threadpoolsize>: How Many Threads? [Optional] The <thread-pool-size> element allows you to specify how many threads vgncontentscan uses to perform parallel scanning operations. The default value is 1. The <chunk size>, <sleep-interval>, and <thread pool size> elements allow you to control the load placed on the Content Management Server by vngcontentscan. The utility calls several operations that can cause substantial loading, not only on the Content Management Server, but on the content database server as well. Tweaking the values for the previously-mentioned elements can make the Content Management Server and content database server more responsive to other applications when vngcontentscan is running <log>: Logging Information [Required] You must provide logging information by specifying values for the following parameters to the <log> element: <logdir> The directory where the log files will reside <logname> The name of the log file itself <loglevel> The log level <logtemplate> The path to the log template file <logsize> How large the log file can get <logbackupcount> How many copies of the log file to keep before overwriting an existing log file OpenText Web Experience Management Administration Guide 219

220 Chapter 12 Content Scans For more information, see Logging on page Schema and Example XML Input File The schema for the XML input file is located in the file named vgncontentscanoptions.xsd, which is located in the <WEMinstallDir>/ Content/10_5/adm/xmlschemas directory; for example: Windows: C:\OpenText\WEM\Content\10_5\adm\xmlschemas UNIX /opt/opentext/wem\content/10_5/adm/xmlschemas At the top of the XSD file is an example XML input file. To find where the sample file begins, search for the following string: sample xml options file 12.7 IcontentUpdateChecker Interface vgncontentscan has no way to programmatically identify which content instances had their associated database records modified without informing the Content Management Server via commit. Therefore, the utility allows you to implement a user-pluggable java class to perform that kind of checking. Perform the following steps to set up vgncontentscan update checking: 1. Write a java class that implements the following interface for each content type to be scanned for update: /** * IContentUpdateChecker defines the interface for a vgncontentscan update * checker. A vgncontentscan update checker can be specified when running * vgncontentscan to inform vgncontentscan which content instances need to be * updated due to modification of their user data (or content). * * In general,vgncontentscan alone can not detect which content instances need * to be updated if the user data has been modified directly in the database; * therefore, a update checker can be specified so vgncontentscan can * programmatically determine if the user data (or content) for a content * instance has been modified. * * All implementation classes must provide a default constructor. */ public interface IContentUpdateChecker { /** 220 OpenText Web Experience Management Administration Guide

221 12.7. IcontentUpdateChecker Interface * Initialization routine * * vgncontentscan will call this method once before processing any content * instances. Classes should add any required initialization or setup that * needs to be performed only once per the lifetime of the update checker in * the implementation of this method. An example of such initialization * would be creation of resources such as a database connection. * * Implementing classes should return true if this method is successful. If * the method encounters a failure, and return false, vgncontentscan will * terminate. * true if initialization is successful, false otherwise */ public boolean init(); /** * vgncontentscan will call this method to determine if the user data (or * content) of the specified ContentInstance object has been modified since * the last commit. * * Implementing classes should return true if the specified content instance * user data (or content) has been updated. * ci * an instance of ContentInstance true if the supporting contents of the given content instance * have been modified since last commit, false otherwise */ public boolean iscontentmodified(contentinstance ci); /** * Destroy routine * * vgncontentscan will call this method once after processing content * instances. Classes should add any required cleanup that needs to be * performed only once per the lifetime of the update checker in the * implementation of this method. An example of such cleanup OpenText Web Experience Management Administration Guide 221

222 Chapter 12 Content Scans would be * releasing resources such as a database connection. */ public void destroy(); } 2. Name step: Deploy the implementation. Deploy the JAR file using the configp utility. See the Roadmap chapter in the Open Text Web Experience Management Extensibility SDK Development Guide for information about deploying custom code using configp. 3. Specify the class name in the XML input file along with its targeted content type (and the other required parameters). When you call vgncontentscan, it loads the new class, initializes an instance of the class by calling the init() method, and calls the iscontentmodified() method for each existing content instance of the targeted content type. If iscontentmodified() returns true, vgncontentscan calls the touch() method on the content instance Logging Note: OpenText recommends to track data modifications using your schema. If you are not tracking data modifications using schema, you can return true from iscontentmodified for all CIs to force WEM to update them all. vgncontentscan uses standard WEM logging infrastructure based on log4j (see Log Files on page 317). It logs detailed processing information to a log file, including such information as which content instances have been created, deleted, updated, and so on. vgncontentscan picks up all parameters needed to initialize the logging manager (for example, the log file directory, log file name, log template, and so on) from the XML input file. vgncontentscan generates a report file for each targeted content type. The report file clearly indicates whether or not the scan process has finished successfully, and contains detailed information on each content instance that has been added (attached), or deleted (detached). That information includes the content instance's GUID and primary key value. The report file also summarizes the scan process, listing its start time, end time, duration, total number of content instances processed, and so on. The report files are located in the same directory as logging file. Each scan generates a separate report file, which is named according to the following file name convention: ContentScanReport_<contenttype>_<timestamp>.txt where <contenttype> is the targeted content type and <timestamp> is the time when the scan started. 222 OpenText Web Experience Management Administration Guide

223 Chapter 13 Command-Line Utilities This chapter provides syntax and descriptions for Web Experience Management command-line utilities Introduction This chapter provides syntax and options for the command-line utilities provided with the WEM software. See also: OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC), for information about procedures performed with the configp utilities cfgaction The cfgaction command-line tool lets you perform configuration actions in batch mode. Note: A new option -debug is added to some command line utilities (cfgaction, dfgedit, configp, vgncontentindex, vgndbmigratetool, vgnexport, vgnfurlmigrate, vgnimport, vgnlocalemigrate, vgnpasswordchange, vgnupdatepageassocs, restartwemservices) to set the log level to DEBUG, otherwise INFO by default. cfgaction has been enhanced to support deployment of both extensions and standalone extensions. Extensions are additional jar files or web applications added to the Web Experience Management enterprise application. Standalone extensions are web or enterprise applications deployed directly to the WEM cluster. For more information on WEM extensibility, see Open Text Web Experience Management Extensibility SDK Development Guide Note: As of Web Experience Management 8.5 and later, additional input properties are required for the cfgaction updatecsear action, which now supports both extensions and standalone extensions. The DeployType properties indicate if the extension is standalone. The StandaloneType property (for standalone extensions only) indicates if the extension is a jar or a war file. For more information, run cfgaction to generate a properties file template. OpenText Web Experience Management Administration Guide 223

224 Chapter 13 Command-Line Utilities Syntax The following items show the syntax to use for different calls to cfgaction. A full description of arguments appears following the list of syntax description. To list component types: cfgaction -h <host>:<port> [-u <userid> p <password>] -l components [-o <outputfile>] To list the actions that can be performed for a given component type: cfgaction -h <host>:<port> [-u <userid> -p <password>] -l actions -c <componenttype> [-o <outputfile>] To list the property template for the given component ID and action ID: cfgaction -h <host>:<port> [-u <userid> -p <password>] -l properties -a <actionid> -d <componentid> [-o <outputfile>] In the following syntax descriptions, you create a property file by specifying the list ( l properties) option in the call to cfgaction. Listing properties creates a property file. For some configuration actions that require you to create a properties file, you may need to edit that property file by adding component-specific information. In such cases, you must do so before verifying or executing the file. See the examples for details. If you need to specify a pathname in a property file, use forward slashes to separate components. For Windows pathnames, use protected forwarded slashes. For example: UNIX: /opt/mydir/myfile Windows: C://mydir//myfile.txt Windows: "C://my dir with spaces//myfile.txt" To update the Content Services EAR file: 1. Create the property file: cfgaction -updatecsear -h <host>:<port>[-u <userid> -p <password>] -l properties -o <outputfile> 2. Manually edit the <outputfile> and add the information required from Step 1 on page 224. <outputfile> is now your property file. 3. Verify the property file: 224 OpenText Web Experience Management Administration Guide

225 13.2. cfgaction cfgaction -updatecsear -h <host>:<port> [-u <userid> -p <password>] -i <propertyfile> -w 4. Execute the property file: cfgaction -updatecsear -h <host>:<port> [-u <userid> -p <password>] -i <propertyfile> -e To create a connected Configuration Agent: 1. Create the property file: cfgaction -createagent -h <host>:<port> -l properties 2. Verify the property file: [-u <userid> p <password>] [-o <outputfile>] cfgaction -createagent -h <host>:<port> -i <propertyfile> 3. Execute the property file: [-u <userid> -p <password>] -w cfgaction -createagent -h <host>:<port> -i <propertyfile> [-u <userid> -p <password>] -e Note: For information about the difference between connected and disconnected Configuration Agents, see Configuration Agents on page 173. To create a disconnected Configuration Agent: Note: For information about the difference between connected and disconnected Configuration Agents, see Configuration Agents on page Create the property file: cfgaction -createdisconnectedagent -l properties [-o <outputfile>] 2. Verify the property file: cfgaction -createdisconnectedagent -i <propertyfile> -w 3. Execute the property file: cfgaction -createdisconnectedagent -i <propertyfile> -e To register a disconnected Configuration Agent: 1. Create the property file: OpenText Web Experience Management Administration Guide 225

226 Chapter 13 Command-Line Utilities cfgaction -registeragent -h <host>:<port> -l properties 2. Verify the property file: [-u <userid> p <password>] [-o <outputfile>] cfgaction -registeragent -h <host>:<port> -i <propertyfile> 3. Execute the property file: [-u <userid> -p <password>] -w cfgaction -registeragent -h <host>:<port> -i <propertyfile> [-u <userid> -p <password>] -e To remove a connected Configuration Agent: 1. Create the property file: cfgaction -removeagent -h <host>:<port> -l properties 2. Verify the property file: [-u <userid> -p <password>] [-o <outputfile>] cfgaction -removeagent -h <host>:<port> -i <propertyfile> 3. Execute the property file: [-u <userid> -p <password>] -w cfgaction -removeagent -h <host>:<port> -i <propertyfile> [-u <userid> -p <password>] -e To remove a disconnected Configuration Agent: 1. Create the property file: cfgaction -removedisconnectedagent -l properties [-o <outputfile>] 2. Verify the property file: cfgaction -removedisconnectedagent -i <propertyfile> -w 3. Execute the property file: cfgaction -removedisconnectedagent -i <propertyfile> -e To create a type specification customer extension: 1. Create the property file: cfgaction -createtssysext -h <host>:<port> [-u <userid> p <password>] 226 OpenText Web Experience Management Administration Guide

227 13.2. cfgaction -l properties [-o <outputfile>] 2. After editing the property file to add component-specific information (see page page 231 ), verify the file: cfgaction -createtssysext -h <host>:<port> [-u <userid> -p <password>] d /vcm-<name>/cmsvcs/vmc/spf/tsr/cust -i <propertyfile> -w 3. Execute the property file: cfgaction -createtssysext -h <host>:<port> [-u <userid> -p <password>] d /vcm-<name>/cmsvcs/vmc/spf/tsr/cust -i <propertyfile> -e To create a view template customer extension: 1. Create the property file: cfgaction -createvtsysext -h <host>:<port> [-u <userid> p <password>] -l properties [-o <outputfile>] 2. After editing the property file to add component-specific information (see page page 231), verify the property file: cfgaction -createvtsysext -h <host>:<port> [-u <userid> -p <password>] d /vcm-<name>/cmsvcs/vmc/spf/vtr/cust -i <propertyfile> -w 3. Execute the property file: cfgaction -createvtsysext -h <host>:<port> [-u <userid> -p <password>] d /vcm-<name>/cmsvcs/vmc/spf/vtr/cust -i <propertyfile> -e To create a customer extension widget: 1. Create the property file: cfgaction -createwidgetsysext -h <host>:<port> [-u <userid> p <password>] OpenText Web Experience Management Administration Guide 227

228 Chapter 13 Command-Line Utilities Options -l properties [-o <outputfile>] 2. After editing the property file to add component-specific information (see page page 231), verify the property file: cfgaction -createwidgetsysext -h <host>:<port> [-u <userid> -p <password>] d /vcm-<name>/cmsvcs/vmc/wc/cust -i <propertyfile> -w 3. Execute the property file: cfgaction -createwidgetsysext -h <host>:<port> [-u <userid> -p <password>] Options for cfgaction are: d /vcm-<name>/cmsvcs/vmc/wc/cust -i <propertyfile> -e Option Description -a <actionid> Identifies an action by its action identifier. An <actionid> is unique within the context of a component type. A partial list of action identifiers includes: READ MODIFY CREATE To find a list of action IDs for a component type, use -l actions. Use a with the -d option. -c <componenttype> Specifies the component type. For example: -c cs.cfs -c vcm.stage -d <componentid> Specifies the configuration identifier of a component. For example: /vcm-<name> Specified in conjunction with the -w or -e options. (To find the component ID, select the component in the Configuration Console tool and find the value in the Path column of the right-hand pane.) 228 OpenText Web Experience Management Administration Guide

229 13.2. cfgaction Option Description -e Executes the action using the specified property file. Used in conjunction with the -aand -ioptions. The cfgaction command acquires a lock on the product instance when the -e option is used. Only one user can execute an action on a product instance at a time. -h <host>:<port> Specifies the host and port of the application server hosting the Content Management Server. -i <propertyfile> Specifies the file name of the property file to be used as input. The <propertyfile> variable is the path to the property file as appropriate for the operating system where you are running the command. -l actions Lists the action identifiers and action names for a component type. Use with the -c option. -l components Lists the defined component types. An example component: vcms -l configids Lists the configuration ID for the component. Use with the -c, and -i options. An example configuration ID: /vcm-vgninst -l properties Writes an empty property file to stdout. Use with the -d and -a options. -o <outputfile> Writes the results of cfgaction to an output file. If -o <outputfile> is not specified, the results go to stdout. -p <password> Specifies the password for the user identified in the -u option. -s Runs cfgaction in silent mode. Does not show progress messages. -u <userid> Specifies a user known to the Content Management Server. If -u is not specified, cfgaction prompts the user to enter a user ID and password. -w Runs batch validation against a property file. Use with the -i option. -? Displays this list of options. -? advanced Displays a series of syntax lines, similar to the Syntax paragraph for cfgaction in this document. -debug To set the log level to DEBUG. OpenText Web Experience Management Administration Guide 229

230 Chapter 13 Command-Line Utilities Exit Values Any output from cfgaction is printed to stdout. Error, warning, and information messages are printed to stderr. cfgaction returns: Value Meaning 0 (zero) Success Nonzero Failure In addition, cfgaction logs information to cfgaction.log. See Command Line Utilities Log Files on page Description The cfgaction command is available as a batch file or shell script, and resides in the following directory: <WEMinstallDir>/Content/<version>/bin For example: Windows: C:\OpenText\WEM\Content\10_5\bin\cfgaction.bat -debug UNIX: /opt/opentext/wem/content/10_5/bin/cfgaction Anyone can use cfgaction to view configuration information. However, to add, delete, or modify configuration information, you must have the VCM:ADMINISTRATOR capability. Most configuration actions that you perform in batch mode (for example, creating a Configuration Agent) require three separate calls to cfgaction: 1. In the first cfgaction call, you create a property file. The property file is used as input in a subsequent call to cfgaction. In the subsequent call, the property file defines a configuration action to be taken and contains information specific to the components involved. Note: Depending on what the configuration action is, you may need to edit the created property file at this point, and add the component-specific information. See the examples for details. You can obtain a property file directly by running cfgaction. However, you may find it easier and more powerful to obtain a property file from configp (using that command's p option), and then run that property file from cfgaction. 2. In the second cfgaction call, you must have cfgaction verify that the property file is syntactically correct. Failure to do so could cause cfgaction to 230 OpenText Web Experience Management Administration Guide

231 13.2. cfgaction perform an improper configuration action. This step is particularly important if you have edited the property file. 3. The third cfgaction call performs the actual configuration action based on the information in the now-verified property file. The following examples show these steps in real usage situations Example: System Extension Components Property Files Note: For more information about creating system extensions, see the Open Text Web Experience Management Extensibility SDK Development Guide. The following property-value setting shows what you might put in a property file in order to create a type specification system extension: TypeSpecificationDisplayName=MyTestTypeSpec TypeSpecificationTemplateName=MyTestTypeSpec TypeSpecificationXML=<?xml version="1.0"?> <service provider asset type specification type-name="projectext" base type name="project"><toolbar template>test_ts</toolbartemplate> </service-provider-asset-type-specification> Note: Although the TypeSpecificationXML setting appears broken across several lines, it must appear as a single line in your property file. The following lines show what you might put in a property file in order to create a view template system extension: ViewTemplateDisplayName=MyTestVT ViewTemplateTemplateName=MyTestVT ViewTemplateXML=<?xml version="1.0"?> <service-provider-asset-view-template type-name="projectext" base-type-name="project"><toolbar template>test_vt</toolbar template> </service-provider-asset-view-template> Note: Although the ViewTemplateXML setting appears broken across several lines, it must appear as a single line in your property file. The following lines show an example of what you might put in a property file in order to create a widget system extension: OpenText Web Experience Management Administration Guide 231

232 Chapter 13 Command-Line Utilities WidgetDisplayName=TestWidget WidgetClassName=VCMTestWidget WidgetPackageName=com.vignette.as.ui.TestWidget WidgetDataTypes=STRING,INT WidgetXSLT=<Your XSL code would go on a single line here. >WidgetConfigurationJsp=jsp WidgetJspContext=context WidgetAllowOnKey=key WidgetAllowOnNonNullable=false WidgetAllowOnExtensibleAttrs=false WidgetMinimumLength=-1 WidgetMaximumLength= Example: cfgaction Script The following partial code example shows how you could create a batch or script file containing a series of cfgaction commands that perform a complete configuration. Note: The example assumes that after each cfgaction call which creates a property file (calls with the -o option), you modify that property file (manually or programmatically) by adding values for the file's name-value pairs. While the code does not show any property file modification steps, you would have to modify the property files in order for your code to work. # Create a Configuration Agent cfgaction -createagent -u system -p ax5qy4 -h cfgsvr.example.com: o createagent.prop -l properties cfgaction -createagent -u system -p ax5qy4 -h cfgsvr.example.com: i createagent.prop -w cfgaction -createagent -u system -p ax5qy4 -h cfgsvr.example.com: i createagent.prop -e # Create a stage and Deployment Agent. 232 OpenText Web Experience Management Administration Guide

233 13.2. cfgaction cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs -a CREATE_STAGE -o createstage.prop -l properties cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs -a CREATE_STAGE -i createstage.prop -w cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs -a CREATE_STAGE -i createstage.prop -e # Create a Content Delivery Server in the stage. cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa -a CREATE_CDS -o createcds.prop -l properties cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa -a CREATE_CDS -i createcds.prop -w cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa -a CREATE_CDS -i createcds.prop -e # Create a resource for the Deployment Agent. cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa/cds cdsqa/cdagents/\ cda daqa/vgn/aglet1/da/resources -a ADD_EP_MAPPING -o createdaresource.prop -l properties cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa/cds-cdsqa/cdagents/\ cda-daqa/vgn/aglet1/da/resources -a ADD_EP_MAPPING -i createdaresource.prop -w OpenText Web Experience Management Administration Guide 233

234 Chapter 13 Command-Line Utilities cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa/cds-cdsqa/cdagents/\ cda-daqa/vgn/aglet1/da/resources -a ADD_EP_MAPPING -i createdaresource.prop -e # Create a resource alias for the Content Delivery Server. cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa/cds-cdsqa/resources -a ADD_EP_MAPPING -o createcdsresource.prop -l properties cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa/cds-cdsqa/resources -a ADD_EP_MAPPING -i createcdsresource.prop -w cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa/cds-cdsqa/resources -a ADD_EP_MAPPING -i createcdsresource.prop -e # Create a resource alias for the stage. cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa/resources -a ADD_EP_MAPPING -o createstageresource.prop -l properties cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa/resources -a ADD_EP_MAPPING -i createstageresource.prop -w cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa/resources -a ADD_EP_MAPPING -i createstageresource.prop -e # Add content subscriptions to the Content Delivery Agent. cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa/cds-cdsqa/\ cdagents/cda-daqa/vgn/aglet1/da -a ADD_CONTENT_TYPE 234 OpenText Web Experience Management Administration Guide

235 13.3. cfgedit Issues -o adddacontentsubscription.prop -l properties cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa/cds-cdsqa/\ cdagents/cda-daqa/vgn/aglet1/da -a ADD_CONTENT_TYPE -i adddacontentsubscription.prop -w cfgaction -u system -p ax5qy4 -h cfgsvr.example.com: d /vcm-vgninst/cdsvcs/stage-stageqa/cds-cdsqa/\ cdagents/cda-daqa/vgn/aglet1/da -a ADD_CONTENT_TYPE -i adddacontentsubscription.prop -e Configurations using DB2 on AIX or Solaris may experience database connectivity problems if you have not set the DB2INSTANCE_HOME variable, or if you have set incorrectly. This caveat applies on any host other than the one on which the Content Management Server will reside; if that host will contain a Deployment Agent, and if any of the Deployment Agents on that host will need to work with records in a content database or with Application Services, then you must add the DB2INSTANCE_HOME variable to the cfginfo.dat file. The value for that variable should be the same as the value of the UNIX environment variable $INSTHOME for DB2 as seen on that host. If, at first, you determine that you are not going to work with records on a remote Deployment Agent (and so you decide not to edit the cfginfo.dat file), but you change your mind later, you can add the DB2INSTANCE_HOME variable to the cfginfo.dat file at that time cfgedit Before you begin: Changing and Testing Configuration Variables on page 179 The cfgedit command-line utility lets an authorized user view and manipulate the configuration path hierarchy for a product instance (or set of product instances). This tool can manipulate the hierarchy stored in either the WEM system database or a configuration file, but not both in the same session. Note: We recommend that you use the Configuration Console whenever possible to change configuration information rather than the cfgedit utility, which should be reserved only for special cases, such as modifying a values in a local configuration file. OpenText Web Experience Management Administration Guide 235

236 Chapter 13 Command-Line Utilities Syntax To connect to the Content Management Server (the vgnvcmserver managed server): cfgedit -h <host>: <port> [-u <userid> -p <password>] [-s <scriptfile>] To run against a configuration file: cfgedit [-s <scriptfile>] F <configfile> To pull a configuration file: cfgedit -h <host>: <port >-u <userid> -p <password> -f <configfile > -i <configid> Options -m pullcfgfile Command line options for cfgedit include: Option <configfile> Description Specifies a file system path to the configuration file; for example: Windows C:\OpenText\WEM\vcm\inst vgninst\ conf\cfs.cfg Solaris /opt/opentext/wem/vcm/inst vgninst/conf/cfs.cfg 236 OpenText Web Experience Management Administration Guide

237 13.3. cfgedit Option Description -f <configfile> Specifies the full path where cfgedit will place the restored configuration file. For example: Windows C:\OpenText\WEM\vcm\inst vgninst\vcm\inst vgninst\ Solaris conf\cfs.cfg /opt/opentext/wem/vcm/inst vgninst/conf/cfs.cfg -F <configfile> Identified the configuration file to be edited. For example: Windows C:\OpenText\WEM\vcm\inst vgninst\ Solaris conf\cfs.cfg /opt/opentext/wem/vcm/inst vgninst/conf/cfs.cfg -h <host>:<port> Specifies the host and port of the Content Management Server to which you want to connect. -i <configid> Specifies which component requires a new configuration file. <configid> is the component's configuration tree path. For example: /vcm-vgninst/vcms Use with the -m option. -m pullcfgfile Indicates to cfgedit that it must extract a new configuration file from the Configuration database to replace the damaged configuration file specified by the other arguments in the call. Use with the -f and -i options. See the examples later in this section. -p <password> Specifies the password for the user name. Use with the -u<userid> option. -s <scriptfile> Specifies the full path name for a script that will run in batch mode. When running cfgedit in batch mode, use the ignore subcommand to control whether or not cfgedit will exit upon encountering an error condition produced by a command in the script. -u <userid> Specifies a user name known to the Content Management Server's application server domain. Use with the -p <password> option. If not specified, cfgedit will prompt for it. -debug To set the log level to DEBUG. OpenText Web Experience Management Administration Guide 237

238 Chapter 13 Command-Line Utilities Exit Values The output of cfgedit prints to stdout. Error, warning, and information messages print to stderr. cfgedit returns the status code of the last command executed: Value Meaning 0 (zero) Success Nonzero Description Failure The cfgedit utility is available as a batch file or shell script, and usually resides at the following locations, depending on where you installed the WEM software: Windows: C:\OpenText\WEM\Content\10_5\bin\cfgedit.bat UNIX: /opt/opentext/wem/content/10_5/bin/cfgedit Note: You must run the cfgedit utility from its default directory. Do not copy it to another location and attempt to run it from there. Any user can view the configuration path hierarchy; however, to manipulate the configuration path hierarchy (that is, to change the value of a configuration variable), you must have at minimum the capabilities associated with the CS Product Administrator role. An alternative method of calling cfgedit exists if you want to manipulate a Configuration Agent or Deployment Agent. This method has you launch cfgedit from the vgnadmin command. See vgnadmin on page Understanding the Configuration Path Hierarchy The WEM software organizes configuration information across a virtual configuration path hierarchy. The configuration path hierarchy is a representation of WEMcomponents. Because a component may have multiple instances, a hierarchical perspective is helpful to keep track of everything. Note: The configuration path hierarchy is different than the component structure shown in the Configuration Console tree view. 238 OpenText Web Experience Management Administration Guide

239 13.3. cfgedit Node When you consider the configuration path hierarchy as a tree structure, the term node is helpful; for example, refers to a particular component or process, for example, the vgninst product node or the cda node. Hierarchy only The configuration path hierarchy is not a file system, although the paths resemble a file system. (When you use the Configuration Console, you will see the configuration path for each variable in the Config Path column of the right-hand pane.) Note: it is important to remember that the configuration path hierarchy represents information stored both in a set of configuration files and in the configuration database Locating and Identifying Configuration Variables Configuration information is stored in <configuration variables>. The variables are located and identified according to where they are defined within the configuration path hierarchy. The WEM software assigns a unique configuration identifier to each component and process in an installation at the time of initial configuration. The identifier is essentially a component's or node's place in the configuration path hierarchy. You use these configuration identifiers to specify the component or process for which you want to modify configuration information. Note: You can also store a listing of all your system's configuration variables (along with their configuration paths) into a file. See Examples on page 246. The following table shows a few example configuration identifiers. Configuration Path (Identifier) /cs/cfs /cs/cfs/auth /cs/cfs/common.logging /cs/cfs/jndi /cs/cfs/wlas /cs/config.cfa-<name> /cs/config.cfa-<name>/http /vcm-<name> Identifies Subcomponents Authorization subcomponent Logging subcomponent Application server Java Naming and Directory Interface (JNDI) communication subcomponent WebLogic administrative server subcomponent Configuration Agent Configuration Agent's HTTP communication subcomponent WEM instance OpenText Web Experience Management Administration Guide 239

240 Chapter 13 Command-Line Utilities Configuration Path (Identifier) /vcm-<name>/cdsvcs /vcm-<name>/cdsvcs/stage-<name> /vcm-<name>/cdsvcs/stage-<name> /cds-<name> /vcm-<name>/cdsvcs/stage-<name>/ cds-<name>/cdagents/cda-<name> /vcm-<name>/cmsvcs /vcm-<name>/vcms /vcm-<name>/vcms/pws Identifies Content Delivery Services subcomponent Content Delivery Services stage subcomponent Stage's Content Delivery Server subcomponent Content Delivery Server's Deployment Agent WEMContent Management Services node Content Management Server component Content Management Server workflow subcomponent Note: When you initially configure some components, you are prompted to supply a value for <name>. This <name> is used as part of the configuration identifier. To determine the configuration identifier: 1. Open the Configuration Console. 2. Select the parent node of a component in the tree pane. 3. Look for the component and the value in its Config ID column in the Details pane Specifying a Configuration Variable You must use a configuration path to specify or locate a specific configuration variable because several components and processes share the same variable name. (The configuration path is the same as the identifier.) Use the following format to specify a configuration variable fully: <configurationpath>/<variable> where: Term <configurationpath> <variable> Definition Represents the configuration path for the component or process at which the variable is defined Is the name of the configuration variable For example, to specify the NAME variable for a WEMproduct instance: /vcm-vgninst/name To specify the RESOURCE_NAME variable for a Content Delivery Server's resource named text (specifying the following on one line): 240 OpenText Web Experience Management Administration Guide

241 13.3. cfgedit /vcm vgninst/cdsvcs/stage dev/cds dev/resources/directories/ text/resource_name The configuration path prevents ambiguities in the cases where there are multiple instances of a component, such as multiple Deployment Agents. For example: The following path/variable identifies the working directory for the cda dev Deployment Agent: /vcm vgninst/cdsvcs/stage dev/cds dev/cda dev/ WORKING_DIRECTORY The following path/variable identifies the working directory for the cda QA Deployment Agent: /vcm vgninst/cdsvcs/stage dev/cds dev/cda-qa/ WORKING_DIRECTORY Valid Operations Connected to the Content Management Server When cfgedit is connected to the Content Management Server, the administrator's authorization comes from the product instance(s) known to that Content Management Server instance. Only the nodes of product instances for which the administrator is authorized appear in selection lists. If the administrator has read permission only on a product instance, all other subcommands will fail within that product instance. When the administrator uses the cfgedit cd subcommand to change the path to one of the product instance nodes, he is then operating in the context of that product instance. The context is important for the commit, push, and revert subcommands that allow the administrator to commit (to the database), push (to configuration files), and revert changes made to the configuration path hierarchy for that product instance. If the administrator is not within the path of a product instance, commands that operate on product instances (commit, push, and revert) will fail with a product not in scope message. Invoked against a configuration file When cfgedit is invoked against a configuration file, authorization is controlled by the operating system access control list for that file: If the administrator does not have read access to the file, cfgedit will fail when invoked. If the administrator has read-only access to the file, invoking any subcommand that modifies the file will fail with an authorization error. When working with a configuration file, the administrator is manipulating only those nodes and variables defined within that configuration file. Only a subset of the cfgedit operations are available for operating against a configuration file. See also: OpenText Web Experience Management Administration Guide 241

242 Chapter 13 Command-Line Utilities Configuration Files on page 341, for information on the location of configuration files Content Management Server or configuration file The authorized user can use cfgedit to perform the following operations on the configuration path hierarchy when either connected to the Content Management Server or operating against a configuration file: Change path within the hierarchy Get the value of a variable Get a brief description of a variable Set the value of a variable List the nodes and variables under a given node List the product components that use a given variable Set an override value for a variable for a particular product component Content Management Server only The authorized user can use cfgedit to perform the following additional operations only when connected to a Content Management Server: Commit the current set of changes for a product instance List the pending changes for a product instance List the configuration files affected by the pending set of changes Revert the current changes Push the current set of changes out to the affected configuration files Subcommands The following subcommands are available within cfgedit. Subcommand cd <configpath> commit create <variablename><value> create -f <filename variablename> Description Changes directory to the directory specified by <configpath>. To go up a level, specify.. in the path. <configpath> can be specified as a relative or absolute path. Commit the current changes to the product currently in scope. Create a configuration variable at the current location in the configuration tree. Specify the name of the new variable in <variablename> and set the value of that variable either by specifying the value in <value> or in the file specified in <filename>. 242 OpenText Web Experience Management Administration Guide

243 13.3. cfgedit Subcommand describe <variablename> delete <variablename> exit get -c <variablename> get -d <variablename> get -p <variablename> get -r <variablename> get -s <variablename> get -v <variablename> get -c <variablename componentpath>get -r <variablename componentpath> get -v <variablename componentpath> getpstate help [<subcommand>] Description Displays a description of <variablename>. <variablename> can be specified as an absolute or relative path. If the variable does not exist at the specified path, describe will fail with a variable not found error. Deletes the configuration variable specified in <variablename>. Exit cfgedit. Returns the status code of the command executed before calling exit. Returns the requested attribute of <variablename>. If the result is assigned to a variable, it is not displayed; otherwise, the result is displayed to the user. If the variable does not exist at the specified path, get will fail with a variable not found error. The <variablename> <componentpath> form gets the value of the variable for that component. If an override is set, get returns the override value. -c Gets the configuration value -d Gets the default value -p Gets the absolute path where the variable is found. Includes the variable name in the returned path -r Gets the run value for the variable -s Gets the state of the variable. State can be C - Changed CP - Changed and pushed D - Deleted DP - Deleted and pushed N - New NP - New and pushed U - Unchanged -v Gets the revert value for the variable Content Management Server only. Get the state of the current product instance (committed, test, pushed). If the user is not currently in the context of a product instance, getpstate fails. Lists available subcommands. If subcommand is specified, prints help text for that subcommand. OpenText Web Experience Management Administration Guide 243

244 Chapter 13 Command-Line Utilities Subcommand ignore on ignore off Description Only applicable when running cfgedit with the -s <scriptfile> option. Determines whether or not cfgedit should exit from a script if a subcommand in the script produces an error. ignore off ignore on Default. cfgedit does NOT ignore errors when running a script and will exit with the status code of the failed subcommand when it encounters an error. cfgedit ignores errors produced by subcommands and continues processing subcommands in the script list ls [-f <filename>] [-n -p] [-r] [-l] [L] [<configpath>] Lists the variables and nodes found in <configpath>. If <configpath> is not specified, then list lists the variables and nodes in the current directory. list prints one line of output for each node or variable. Variables with multi-line values will only display the first line of the value. If you need to see the entire value, use the get command. -f <filename> Writes the listing to the file specified by filename -l Creates a long listing: prints the configuration path, state, and node type. -L Creates a long listing: For variables, prints the configuration value, run value, revert value, and flags (readonly characteristics of the variable, such as that it is encrypted, requires restart, and so on) For nodes, prints the configuration path, state, and node type -n Lists nodes only. -o Lists variables overridden for the component identified by <configpath>. If <configpath> is not a component or the component identified by <configpath> has no overridden values for any variables it uses, there is no output. -r Lists recursively. 244 OpenText Web Experience Management Administration Guide

245 13.3. cfgedit Subcommand listchgs listchgs -c listchgs -n listchgs -o listuses <variablename> push Description -u Lists the variables used by the specified node(s). -v Lists variables only. Content Management Server only. With no options, lists the node and variable changes for the current product instance. If the user is not currently in the context of a product instance, listchgs fails. -c Lists the configuration files affected by the pending changes. -n Lists the process nodes affected by the pending changes. -o Lists changes of variable overrides for the components of the product instance. Content Management Server only. Lists the process nodes that use <variablename>. Content Management Server only. Push current changes out to configuration files. If the user is not currently in the context of a product instance, push fails. quit revert set -f <filename> <variablename> set <variablename> <value> set +o <variablename> <componentpath> <value> set-o <variablename> <componentpath> set -v <variablename> Exit cfgedit. Returns the status code of the command executed before calling quit. Content Management Server only. Revert current changes for the current product instance. If the user is not currently in the context of a product instance, revert fails. Sets the value of <variablename>. -f <filename> <variablename> <variablename> <value> +o <variablename> <componentpath> <value> -o <variablename> <componentpath> Sets the value of <variablename> to the contents of the file specified by <filename>. Sets the value of <variablename> to the value specified by <value>. Sets the override value for <variablename> for <componentpath> to <value>. Removes the override from <variablename> for <componentpath>. OpenText Web Experience Management Administration Guide 245

246 Chapter 13 Command-Line Utilities Examples To store a listing of all your system's configuration variables (along with their configuration paths) into a file named lcvars.txt: 1. Create a script file named lcvars.script containing the following text: list -v -L -r -f C:\lcvars.txt 2. Connect to the Content Management Server (the VgnVCMServer managed server), and pass cfgedit the script you just created: cfgedit -h erin: u system -p 4&reA8v -s lcvars.script To re-establish a WEM component's corrupted or missing configuration file by connecting to the Content Management Server: 1. Connect to the Content Management Server (the VgnVCMServer managed server), that manages the component in question. For example: cfgedit -h devsvr: u system -p 4&reA8v 2. Change directories in the configuration path hierarchy to the component's product path. For example: cfgedit% cd /Content/ 3. Change the value for a variable in that path. (You can also type the same value as the current Run value.) For example: cfgedit% set NAME VCM 4. Push the changes from the product level. cfgedit% push 5. If you typed other than the same value, revert the change. cfgedit% revert 6. Exit from cfgedit. cfgedit% exit To re-establish a WEM component's corrupted or missing configuration file directly from the cfgedit command line: cfgedit -h devsvr: u system -p 4&reA8v -f c:\opentext\wem\vcm\inst vgninst\cfgagent1\ vcm vgninst\vcms\conf\cms.cfg -i /vcm-vgninst/vcms -m pullcfgfile 246 OpenText Web Experience Management Administration Guide

247 13.4. cfgsync 13.4 cfgsync Syntax On installations using delivery-side clustering, you must use the cfgsync command on each node of your cluster to enable the clustering features of the Application Services code. For more information about that code, see the Open Text Web Experience Management API Reference (Javadoc). cfgsync -h <host>: <port> -u <userid> -p <password> -i <configid> -d <workingdir> Parameters All parameters for cfgsync are required. Following is a description of each parameter and its argument: Parameter Description -d <workingdir> Specifies a working directory to be created on this node of the cluster. cfgsync will store the configuration file that it copies from the host running Application Services into this working directory. For example: -h <host>: <port> Windows: C:\vgncfg\as AIX: /opt/home/vgncfg/as Solaris: /usr/home/vgncfg/as Specifies the host and port of the Content Management Server (the VgnVCMServer managed server). -i <configid> Specifies the configuration identifier for the Application Services configuration file (as.cfg). For example: /vcm vgninst/cdsvcs/stage QA/cds QA/as -p <password> Specifies the password for the user identified in the -u option. -u <userid> Specifies a user known to the Content Management Server. -debug To set the log level to DEBUG. OpenText Web Experience Management Administration Guide 247

248 Chapter 13 Command-Line Utilities Description The cfgsync command is available as a batch file or shell script, and usually resides at the following locations, depending on where you installed the WEM software. Following are typical paths to the cfgsync command: Windows: C:\OpenText\WEM\Content\10_5\bin\cfgsync.bat UNIX: /opt/opentext/wem/content/10_5/bin/cfgsync The cfgsync command performs the following actions: Copies the Application Services configuration file (as.cfg) from the host on which you have Application Services running and stores the copy on the node from which you are running cfgsync. Creates the conf/logs subdirectory under the working directory. Modifies the logging component on the node to point to the logs subdirectory in the preceding bulleted item configp Run the configp utility to perform the following operations related to the WEM configuration: Note: Use the Configuration Console or the cfgedit utility rather than the configp utility to change configuration information. In WEM 8.5 and later, the configp command accepts relative paths to WAR, JAR or EAR files during deployment operations. Update a Web Experience Management application. Repair the WEM deployment (useful when the WEM instance is no longer running). Deploy or undeploy standalone WEM applications and extensions Detect context path conflicts during the deployment of extensions and standalone applications. Verify that the RTSVCS configuration is locked during operations. Manage a product instance Includes the following tasks, plus others: Manage Configuration Settings List Configuration Agents Register a Configuration Agent Manage Content Management Services: 248 OpenText Web Experience Management Administration Guide

249 13.5. configp Manage the Management Console (manage or synchronize mapping components and manage Service Provider Framework components) Manage Runtime Services Manage the Content Management Server (perform deployment type tasks, perform file source tasks such as creating or deleting a file source and creating a file source scan, update the license key, manage database connection settings) Manage Content Delivery Services Create or delete a delivery stage Perform Deployment Agent tasks Manage resources Create or delete a connected Configuration Agent. A connected Configuration Agent is one that the Content Management Server is aware of and can communicate with. configp can only delete a Configuration Agent when run on the host where that agent resides. Note: For information about the difference between connected and disconnected Configuration Agents, see Configuration Agents on page 173. Register a disconnected Configuration Agent. The agent must have been created previously using the Delivery Installer or cfgaction, and it must be running for you to register it. You must connect to the Content Management Server before you can register a disconnected Configuration Agent. Note: The prompts for registering a disconnected Configuration Agent agent are basically the same as for creating a regular (connected) Configuration Agent. The values you provide for registering the agent must match the values you supplied when you created it on the host outside the firewall. Delete a disconnected Configuration Agent from a host outside a firewall. Note: After deleting the disconnected Configuration Agent, you must start the Configuration Console and perform a Force Remove on the disconnected Configuration Agent. This last action is required to purge the agent's configuration space information. Manage Applications Includes the following tasks: Note: To manage applications, you must be running configp on the host where the Content Management Server resides. Register Product Extensions (one or more): Allows you to deploy or undeploy Extension Modules, EJBs, and Management Console Extension Web Applications (WARs). For a better description of product extensions, see the OpenText Web Experience Management Administration Guide 249

250 Chapter 13 Command-Line Utilities Open Text Web Experience Management Extensibility SDK Development Guide. The WEM software employs synchronous deployment for deploying extensions to a management-side cluster; therefore, if any of the cluster's nodes are down, deployment will fail. To deploy an extension to a management-side cluster, all nodes must be running. Update WEM Runtime Services: Allows you to deploy WEM updates to Runtime Services, including EAR files. Refer to the WEM update documentation for details. Register standalone applications. Deploy or undeploy standalone Web or EJB applications. See Open Text Web Experience Management Extensibility SDK Development Guide for detailed information. Repair Syntax Options List configuration settings configp [-a] [-p] [-debug] Options for configp include the following: Option Description -a Causes configp to display additional menu items for advanced usage. -p Causes configp to prompt you for the name of a file after each completed configuration action. This file will contain the configuration information from the action stored in WEM property file format which you can use as an input to the cfgaction command's -i option. -debug To set the log level to DEBUG. 250 OpenText Web Experience Management Administration Guide

251 13.5. configp Exit Values Any output from configp is printed to stdout. Error, warning, and information messages are printed to stderr. configp returns: Value Meaning 0 (zero) Success Nonzero Failure In addition, configp logs information to config.log. See Command Line Utilities Log Files on page Description The configp utility is available as a batch file or shell script, and usually resides at the following locations, depending on where you installed the WEM software. Following are typical paths to the configp command: Windows: C:\OpenText\WEM\Content\10_5\bin\configp.bat UNIX /opt/opentext/wem/content/10_5/bin/configp configp provides a series of menus that let you provide information interactively. The menus you see depend on what task you are attempting to perform. The first thing you must do after starting configp is to connect to the target Content Management Server. When running configp on a system that employs a management-side cluster, it is preferable to connect to the Content Management Server using a DNS round-robin address for the management-side cluster. Alternately, you can use the <host>:<port> address of a particular node (where host is either the name of the host or its IP address, and port is the port number of the Content Management Server). For information about reconnecting when a node in the management-side cluster goes down, see Connecting to the Content Management Server on page 83. Note: If you need to manage an application (for example, deploy or undeploy Extension Modules, EJBs, or Management Console Extension WARs), you must run configp on the primary node of the cluster (where Runtime Services is installed). On UNIX systems, you must run configp using the user ID that installed the WEM software. The user ID you use to connect from configp to the Content Management Server must have the Application Administrator role (or its equivalent capabilities). For more information about performing specific configuration tasks, see the OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC). OpenText Web Experience Management Administration Guide 251

252 Chapter 13 Command-Line Utilities 13.6 vgnadmin The vgnadmin command lets the WEM administrator perform administrative tasks from the command line on Configuration Agents and Deployment Agents. The directory from which you run vgnadmin determines the component acted on by the command. To run vgnadmin, you would run the command from the appropriate Content Management Server conf subdirectory. To run vgnadmin on a Configuration Agent, do so from the following path: <WEMinstallDir>/vcm/inst <name>/cfgagent/conf/vgnadmin.bat For example: Windows: C:\OpenText\WEM\vcm\inst vgninst\cfgagent\conf\vgnadmin.bat UNIX/opt/OpenText/WEM/vcm/inst vgninst/cfgagent/conf/vgnadmin To run vgnadmin on a Deployment Agent, do so from the following path: <WEMinstallDir>/vcm/inst <name>/cfgagent/vcm <name>/cdsvcs/ stage <name>/cds <name>/cda <name>/conf/vgnadmin.bat For example: Windows: C:\OpenText\WEM\vcm\inst vgninst\ cfgagent\vcm vgninst\cdsvcs\stage dev\cds dev\ cda dev\conf\vgnadmin.bat UNIX /opt/opentext/wem/vcm/inst vgninst/cfgagent/ vcm vgninst/cdsvcs/stage dev/cds dev1/cda dev/ conf/vgnadmin The vgnadmin administrative tasks are described in the following paragraphs. 252 OpenText Web Experience Management Administration Guide

253 13.6. vgnadmin Syntax vgnadmin cfgedit [-s <scriptfile>] <configfile> vgnadmin install vgnadmin pullcfgfile -h <host>:<port> -u <userid> -p <password> vgnadmin start vgnadmin stop vgnadmin uninstall vgnadmin vmpstart <configid> vgnadmin vmpstop <configid> Subcommands When you run vgnadmin, you call its subcommands at the same time. The following paragraphs describe each possible syntax line and the its arguments. vgnadmin cfgedit [-s <scriptfile>] <configfile> Invokes the cfgedit command against the configuration file specified as a file system path in <configfile>; for example: C:\OpenText\WEM\vcm\inst vgninst\conf\cfs.cfg. The optional -s <scriptfile> allows you to identify a script file to run; that is, a file containing commands that will be executed in batch mode. When running in batch mode, use cfgedit's ignore subcommand to control whether or not vgnadmin cfgedit will exit upon encountering an error condition produced by any command in a script. Note: Use the Configuration Console whenever possible to change configuration information rather than the cfgedit command, which should be reserved only for special cases, such as modifying a configuration file for a Deployment Agent outside a firewall For more information, see cfgedit on page 235. vgnadmin install Windows Installs a Configuration Agent as a Windows Service. This feature is not available for Deployment Agents or RMI Servers, or for UNIX systems. vgnadmin pullcfgfile -h <host>:<port> -u <userid> -p <password> Creates a new configuration file for a Configuration Agent. If you accidentally delete a Configuration Agent's configuration file, use this command to recreate it. For <host>:<port>, provide the host name and port number where the Content Management Server (VgnVCMServer managed server) is running. vgnadmin will OpenText Web Experience Management Administration Guide 253

254 Chapter 13 Command-Line Utilities retrieve a replacement configuration file from the Content Management Server running on that host. For <userid> and <password> specify a user name and corresponding password known to the VgnVCMServer managed server. If you fail to specify a user name or password, vgnadmin will prompt for you for one. vgnadmin start Starts a Deployment Agent. For example, the following command (which must be entered on a single line), would start the Production stage's Deployment Agent: C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\ vcm-vgninst\cdsvcs\stage-production\cds-production\ cda-appsvcs\conf>vgnadmin start /vcm-vgninst/cdsvcs/stage- Production/ cds-production/cdagents/cda-appsvcs vgnadmin stop Stops a Deployment Agent. For example, the following command (which must be entered on a single line), would stop the Production stage's Deployment Agent: C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\ vcm-vgninst\cdsvcs\stage-production\cds-production\ cda-appsvcs\conf>vgnadmin stop /vcm-vgninst/cdsvcs/stage- Production/ cds-production/cdagents/cda-appsvcs vgnadmin uninstall Windows Removes a Configuration Agent Windows Service. If the agent is running, vgnadmin uninstall stops it before uninstalling it. This feature is not available for Deployment Agents or RMI Servers, or for UNIX systems. vgnadmin vmpstart <configid> Starts the Configuration Agent (which is a WEM Managed Process VMP) identified by the configuration path specified in <configid>. For example, the following command (which must be entered on a single line), would start the Production stage's Configuration Agent: C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\conf>vgnadmin vmpstart / vcm vgninst/cdsvcs/stagegproduction/cds Production/cdagents/ cda-appsvcs/vgn Starting a Configuration Agent automatically starts the Deployment Agent associated with that Configuration Agent. 254 OpenText Web Experience Management Administration Guide

255 13.7. vgncontentindex If the Configuration Agent has been set up to run as a Service, you can start the Service from the Windows Services extension of the Control Panel. vgnadmin vmpstop <configid> For example, the following command (which must be entered on a single line), would stop the Production stage's Configuration Agent: C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\conf>vgnadmin vmpstop / vcm vgninst/cdsvcs/stagegproduction/cds Production/cdagents/ cda-appsvcs/vgn Stopping a Configuration Agent automatically stops the Deployment Agent associated with that Configuration Agent. If the Configuration Agent has been set up to run as a Service, you can stop the Service from the Windows Services extension of the Control Panel vgncontentindex If content existed on either the Management or delivery stage before you configured your search module for that stage, you need to index the content for that stage to make the content searchable. Note: Throughout the rest of this chapter content is referred to as content items. The term content items refers to a collection of content instances and/or static files. The vgncontentindex command indexes content items into the search module. You can use vgncontentindex to index new content items or to reindex existing content items based on a specific locale. For example, if you have content items on a stage, and that stage was not configured to use the search module, your content items are not searchable. To make them searchable, you would run vgncontentindex to index the stage's content items Indexing New Content Instances or Static Files If the search module is running when you scan content instances (vgncontentscan) or static files (from a file scan), or when you import (vgnimport) either or both, those instances and/or files are automatically indexed by the search module for future searches. The indexing occurs while the scan or import is ongoing. If a substantial number of instances or files need to be scanned or imported, the time it takes to do so can become an issue. However, you can lessen the amount of time required to complete the actual scan or import by turning off automatic indexing. After all the content items are in place, you can then run vgncontentindex to index the new content items in batch mode. If you divide scanning/importing and indexing into separate processes, the overall amount of time for completion is about the same as if you scanned/imported and let OpenText Web Experience Management Administration Guide 255

256 Chapter 13 Command-Line Utilities automatic indexing take place. However, by dividing the procedures, you get your content items under WEM control much more quickly. The general steps for performing a scan or import and then indexing later is as follows: 1. Temporarily unregister the search listener for the deployment events on the affected stage. See Unregistering and Registering Deployment-Related Listeners on page Scan or import your content items. 3. When the scan/import is complete, reregister the three deployment listeners from Step 1 on page 256. You should do this as soon as the new content items are in place. Again, see Unregistering and Registering Deployment-Related Listeners on page Run vgncontentindex to index any added content instances for the search module in batch mode. 5. Run vgncontentindex to index any added static files for the search module in batch mode Reindexing Existing Content Instances or Static Files Syntax You may need to reindex existing content items, for example, if you: Have installed a newer version of the search module. (Upgrading the search module does not require that existing content items be reindexed.) Need to perform disaster recovery for a corrupted search module. Need to modify parameters in the search module, and the search module requires you to reindex your files. In these situations, you only need to run vgncontentindex. The various syntaxes to use when running vgncontentindex are listed below. For an example how to index a combination of content instances and static files, see Example on page 261. To see the vgncontentindex usage statement: vgncontentindex -? To index all content instances of a particular content type: vgncontentindex -h <host>[: <port>] -u <uname> -p <password> -c <contenttypexmlname> -w<vpropfile> 256 OpenText Web Experience Management Administration Guide

257 13.7. vgncontentindex To index all static files: vgncontentindex -h <host>[: <port>] -u <uname> -p <password> -c StaticFile -w<vpropfile> To index all content instances of all content types and all static files: vgncontentindex -h <host>:<port> -u <username> -p <password> -a - w <workingdir> To list (recursively) the GUIDs for all content instances of a particular type: vgncontentindex -h <host>:<port> -u <username> -p <password> - c <ctxmlnam>-f <guidfileout>-w <WEMpropfile> To list (recursively) the GUIDs for all static files in a project path (Management stage): vgncontentindex -h <host>:<port>] -u <username> -p <password> - s <projectpath> -r -f <guidfileout> -w <WEMpropfile> To list (recursively) the GUIDs for all static files in a placement path (delivery stage): vgncontentindex -h <host>:<port> -u <username> -p <password> - s <placementpath> -r -f <guidfileout> -w <WEMpropfile> To list (recursively) all content instances of all content types and all static files: vgncontentindex -h <host>:<port> -u <username> -p <password> - c -a -r -w <WEMpropfile> To index a set of content instances identified by their GUIDs: vgncontentindex -h <host>:<port> -u <username> -p <password> - g <guidfilein> -w <WEMpropfile> To index a set of static files in a project path (Management stage): vgncontentindex -h <host>:<port> -u <username> -p <password> - s <projectpath> -w <WEMpropfile> To index a set of static files in a placement path (delivery stage): vgncontentindex -h <host>:<port> -u <username> -p <password> - s <placementpath> -w <WEMpropfile> To reset the search index and index all content instances of all content types and all static files: vgncontentindex -h <host>:<port> -u <username> -p <password> -q - w <workingdir> OpenText Web Experience Management Administration Guide 257

258 Chapter 13 Command-Line Utilities To index all content instances of all content types and all static files specific to a particular locale and language: Options vgncontentindex -h <host>:<port> -u <username> -p <password> -w <workingdir> -l <ISO_CODE of locale> Note: Options are case-sensitive. Option Description -? Displays the usage statement. -a Index all content instance of all content types and static files. -c <contenttypexmlnam e> Index all content instances that have at least one searchable attribute, and that are instances of the specified content type. In this situation, <contenttypexmlname> must be the XML name of a valid content type. -f <guidfileout> Specifies the output file into which vgncontentindex should place the returned GUIDs from a list operation. The value of <guidfileout> can be a relative or absolute path to the file. Note: If the file already exists, vgncontentindex overwrites the previously-existing contents of the file with the returned GUIDs. -g <guidfilein> Specifies an input file that contains a list of Globally Unique Identifiers (GUIDs) to be indexed. Each content item (content instance or static file) has its own unique GUID. The value of <guidfilein> must be a relative or absolute path to the file containing the GUID(s). The -g option also provides failover. When you specify the -g option, vgncontentindex creates a offset file in the GUID file's directory and uses that file to track how many content items it has processed. If the command fails or is interrupted, the next time you run vgncontentindex, it starts from where the offset file indicates processing left off. If you want to begin reindex from the beginning, you must first delete the offset file. -h <host>: <port> Partially Optional Specifies the host name and port number of the Content Management Server. The port number is optional. If no port number is specified, vgncontentindex assumes the default value of l <ISO_CODE of locale> Indexes all content instances and StaticFiles that belong to the specific language/locale. -p <vadminpwd> Specifies the WEM administrator's password, where <vadminpwd> is the value of that password. -q Resets the search index; then re-indexes all content instances of all content types and all static files. Removes any stale content that may be residing in the search engine, but incapacitates all search capabilities until the entire indexing process completes. 258 OpenText Web Experience Management Administration Guide

259 13.7. vgncontentindex Option Description -r Only for use on the Management stage, and is optional there: Specifies that the list or index operation should recurse through the subprojects under the project specified by the -a or -s option. See those options for more information. -s <projectpath> or -s <placementpath> -s <projectpath >On the Management stage, indexes the static files that reside in the project path specified in <projectpath>. To also index static files in the project path's subdirectories, use -r in conjunction with s. -s <placementpath >On a delivery stage, indexes the static files that reside in the placement path specified in <placementpath>. For example, say you have a static file abc.txt. That file resides in project /Test and its placement path is /TestFiles/abc.txt. To index the static file on the Management stage, use: -s "/Test" To index that same file on a delivery stage, use: -s "/TestFiles" Note: Indexing for placement paths is always recursive, therefore the -r flag has no effect when indexing static files on a delivery stage. The -s option cannot be used with the -a option. -u <vadmuid> Specifies the WEM administrator's login ID (username), where <vadmuid> is the value of that ID. OpenText Web Experience Management Administration Guide 259

260 Chapter 13 Command-Line Utilities Option Description -w <vworkingdir> Specifies the location of the WEM working directory the directory that contains the vgncfg.properties file. The value of <vworkingdir> should be the absolute path to that directory for the Deployment Agent that is responsible for deploying the content items in question. If you are indexing newly-scanned or imported content items, <vworkingdir> should point to the Management stage directory containing vgncfg.properties, for example: Windows: C:\OpenText\WEM\vcm\inst vgninst UNIX: /opt/home/opentext/vcm/inst vgninst If you are indexing content items on a delivery stage, <vworkingdir> should point to the corresponding as/conf directory, for example: Windows: C:\OpenText\WEM\Content\inst vgninst\ cfgagent\vcm-test\cdsvcs\stage-production\ cds-production\as\conf UNIX: /opt/home/opentext/vcm/inst vgninst/ cfgagent/vcm-test/cdsvcs/stage-production/ cds-production/as/conf -z <itemcnt> Optional Specifies how many content items (content instances and/ or static files) vgncontentindex reads from the database before indexing those items. The default value is 500 items. Generally, the fewer database calls required to obtain the content items, the faster vgncontentindex runs. However, if the number of items is sufficiently large, vgncontentindex may encounter problems. In this situation, you may need to specify the -z option on your call, and provide a smaller value for <itemcnt> until you find the optimal size for indexing the content items involved. -debug To set the log level to DEBUG. 260 OpenText Web Experience Management Administration Guide

261 13.7. vgncontentindex Example Assume that you have the following content in ProjectA on your Management stage: Content instances CI-1 and CI-2 (of content type CT-A) Static files SF-1 and SF-2 In addition, you have the following static files in ProjectB: Static files SF-3 and SF-4 In order to re-index all these items and files, you would need to run vgncontentindex three times: once with the -a option (to get all of the content instances), and then twice with the -s option; once to get the static files in ProjectA, and once to get the static files in ProjectB: vgncontentindex -h neptune: u vgnadmin -p w8r91d -a -w "C:\OpenText\WEM\vcm\inst vgninst" vgncontentindex -h neptune: u vgnadmin -p w8r91d -s /ProjectA -w "C:\OpenText\WEM\vcm\inst vgninst" vgncontentindex -h neptune: u vgnadmin -p w8r91d -s /ProjectB -w "C:\OpenText\WEM\vcm\inst vgninst" Details The vgncontentindex utility is available as a batch file or shell script, and resides in the following location directory: <WEMinstallDir>/Content/<version>/bin For example: Windows C:\OpenText\WEM\Content\10_5\bin\vgncontentindex.bat UNIX: /opt/opentext/wem/content/10_5/bin/vgncontentindex The three options that allow you to specify which content instances or static files you want vgncontentindex to index are -c, -g, and -s. These options are mutually exclusive. Even if vgncontentindex is running, a Deployment Agent can index content simultaneously (although there may be some delay in seeing the added content if the utility is busy indexing a large number of items or files in batch mode). OpenText Web Experience Management Administration Guide 261

262 Chapter 13 Command-Line Utilities If indexing fails, vgncontentindex continues indexing with the next content item (content instance or static file), if one is available Constraint When a content item is indexed through the usual deployment process (from the Deployment Agent through the Search listener), the following metadata is stored in the search module along with the item-specific data (such as the content of a static file, and so on): Creator CreationTime LastModifier LastModTime LastModComment LockOwner LockTime However, when you use vgncontentindex to re-index content items on a delivery stage, no metadata gets stored. Therefore, you cannot depend on such metadata for query purposes on a delivery stage Unregistering and Registering Deployment-Related Listeners To unregister the Deployment-related listeners: 1. Log into the Configuration Console as the WEM administrator. 2. Go to the following location in the configuration tree: Configuration Console Web Experience Management Delivery Services Content Delivery Stage <stagename> Content Delivery Services <stagename> Application Services Events 3. For each of the following events, remove the default WEM listener (com.vignette.as.server.event.assearchreglistener) and click Save for each value you change: Deployment.FileCreate Deployment.FileDelete Deployment.FileUpdate Deployment.ManagedObjectCreate Deployment.ManagedObjectDelete 262 OpenText Web Experience Management Administration Guide

263 13.8. vgnpasswordchange Output Deployment.ManagedObjectUpdate Note: If com.vignette.as.server.event.assearchreglistener is the only class listed, replace it with a comma and click Save. 4. Push or commit your changes. See Testing Variable Changes on page 180. vgncontentindexdisplays localized message(s) on the console providing a top-level view of the indexing status. Similar to all command line utilities, vgncontentindex also maintains a log4j-based log file which uses the same default format as the runtime log files. These log files are stored in the user's home directory under the WEM subdirectory. The only exception to where log information is sent is if there is an appropriate vgnlog.xml file in the same directory as the vgncontentindex batch file or script. In this situation, log information is placed in the appropriate file in that directory. The log file shows: Information about failures to establish a connection (in which case, vgncontentindex does not attempt to index any content). Result of each attempt to index a content instance or static file: whether the instance/file was indexed successfully or whether the attempt failed. In the case of content instances, the information is sorted by content types vgnpasswordchange The password change tool is a command line tool used to change and inspect the Web Experience Management administrator and bind passwords Launching the Password Change Tool To launch the password change tool: 1. In a command line, change to the <WEMinstallDir>/Content/10_5/bin directory. 2. Type vgnpasswordchange.bator.sh (according to your operating system). Note: To set the log level to DEBUG, -debug should be used as follows: vgnpasswordchange.bat/.sh -debug OpenText Web Experience Management Administration Guide 263

264 Chapter 13 Command-Line Utilities Syntax Usage When connected to the Content Management Server, use the following syntax: vgnpasswordchange -u adminuser -p adminpassword -h host:port serversubcommand Options When no server connection is available, use the following syntax: vgnpasswordchange u adminuser p adminpassword w workingdir subcommand Note: Options are case-sensitive. Options Description -? Displays the usage statement. h <host>:<port> Specifies the host name and port number of the Content Management Server. -i <property file name> Used to provide required arguments using a properties file. A sample properties file is provided in the same directory as the vgnpasswordchange script. newpassword <passwod> Specifies the new value that has to be assigned to the password. -p <vadminpwd> Specifies the WEM administrator s password, where <wadminpwd> is the value of that password. -u<vadmuid> Specifies the WEM administrator s login ID (username), where <vadmuid> is the value of that ID. -user<user> The user for whom the password has to be changed. This could be either the administrator or a bind user. -w<vworkingdir> Specifies the location of the WEM working directory that contains the vgncfg.properties file. For exple: Windows: C:\OpenText\WEM\vcm\inst-vgninst Unix: /opt/home/opentext/vcm/inst-vgninst 264 OpenText Web Experience Management Administration Guide

265 13.8. vgnpasswordchange Note: This option is used only when a server connection is not available. -waittime Used to provide a wait time in seconds for starting WEM components. Default wait time used by the tool is 180 seconds Server Subcommands When connected to the Content Management Server, use the following subcommands: change Used to change a WEM system admin user password when the system is running. Syntax to change password for admin user: vgnpasswordchange -u <adminuser> -p <adminpassword> -h <host>:<port> -change -user <admin user> -newpassword <adminnewpassword> Example vgnpasswordchange -u vgnadmin -p vignette -h : change -user vgnadmin -newpassword opentext123 Syntax to change password for bind user: vgnpasswordchange -u <adminuser> -p <adminpassword> -h <host>:<port> -change -user <bind user> -newpassword <bindnewpassword> validate Used to inspect the system configuration files for password information. Syntax vgnpasswordchange -u <adminuser> -p <adminpassword> -h <host>:<port> -validate Example vgnpasswordchange -u vgnadmin -p vignette -h : validate OpenText Web Experience Management Administration Guide 265

266 Chapter 13 Command-Line Utilities General Subcommands The following subcommands are used only when there is no connection to the Content Management Server. force Used to change a WEM system user s password throughout the system configuration files when the system is not running. Syntax to change password for admin user: vgnpasswordchange -u <adminuser> -p <adminpassword> -w <workingdir> - force -user <admin user> -newpassword <admin new password> Example vgnpasswordchange -u vgnadmin -p opentext -w c:\opentext\vcm -force - user vgnadmin -newpassword opentext123 Syntax to change password for bind user: vgnpasswordchange -u <adminuser> -p <adminpassword> -w <workingdir> - force -user <bind user> -newpassword <bind new password> snapshot <name> Used to create a snapshot of the system currently running. Syntax Note: If you do not provide the snapshot directory name, the utility will use the timestamp. For example: Mon_Jun_29_10_45_27_IST_2009. vgnpasswordchange -u <adminuser> -p <adminpassword> -w <workingdir> - snapshotdir <name> -snapshot <current> Example vgnpasswordchange -u vgnadmin -p opentext -w c:\opentext\vcm - snapshotdir c:\\snapshot\\temp -snapshot currentsnapshot last Used to show the most recent snapshot. Syntax - vgnpasswordchange u <adminuser> p adminpassword w workingdir - snapshotdir <name> -last Example vgnpasswordchange u vgnadmin p opentext w c:\opentext\vcm - snapshotdir c:\\snapshot\\temp -last 266 OpenText Web Experience Management Administration Guide

267 13.8. vgnpasswordchange Tips for Using vgnpasswordchange CLI Options Use -h (host:port) when the server is running and w (working directory) when it is not. The -last command will only work after -snapshot has been run. When running the -change command (the WEM system is running and connected), perform tasks in the following order: 1. The Node Manager must be running. 2. The configuration agent service must be running. 3. The VgnCluster must be running. 4. If your WEM system is configured with embedded LDAP, the vgnpasswordchange utility will run the following tasks: Change the password in both WEM and LDAP. Restart VCMSErver cluster and the VCMAdminServer automatically. 5. If your WEM system is configured with an external LDAP, the vgnpasswordchange utility run few of following tasks: Change the password in WEM Stop the VCMServer cluster and the VCMAdminServer A user is expected to perform the following tasks: Change the password manually on your external LDAP. Restart the VCMSErver and VCMAdminServer services manually. When running the force command (the WEM system is not connected), perform tasks in the following order: 1. Stop the admin and managed servers. 2. Change the password on the LDAP system. Caution You must perform this step before running the force command because the servers are stopped during the process and cannot be restarted after the password has changed. 3. Run the force command to change the password. The internal command forcestart picks up the changes from the file system CS and commits them to the live system CS. Note: This command is not applicable for embedded LDAP systems. The change command will only run when the system is fully operational and will update both embedded and external LDAP systems. OpenText Web Experience Management Administration Guide 267

268 Chapter 13 Command-Line Utilities restartwemservices The restartwemservices tool is a command line tool used to restart WEM Services such as Admin Server, Node Manger & Cluster. This script has to be run on Primary node only. When VCM is configured with a user not belonging to the Administrator group, restartwemservices.bat/.sh should run on the primary node after vgnsetup. Example: Note: The -debug option can be used to set log level to DEBUG, otherwise INFO by default. <WEMInstallDir>\Content\8_5\bin\reStartWEMServices.bat 268 OpenText Web Experience Management Administration Guide

269 Chapter 14 Exporting and Importing Objects This chapter explains how to import and export objects Introduction The Web Experience Management Export and Import features allow you to easily move data between compatible Content Management Server instances. You can: Export data from one Content Management Server and add it to another Content Management Server Export data from one Content Management Server to update the corresponding data on another Content Management Server Delete data from a target Content Management Server during import to avoid conflicts or remove deprecated data You can move data objects on an individual basis, such as single files, or you can move large bodies of data such as sites, channels, or projects as comprehensive units. The export and import functionality is available through a Command Line Interface (CLI). The CLI allows you to fine tune a number of aspects associated with the movement of your data, such as setting logging levels and dictating recursive processing of sub-projects or sub-channels. This chapter discusses the basic aspects of the export and import processes and provides conceptual and procedural information to aid in the use of this feature Export Overview Exporting in the WEM software is the act of identifying objects in a source Content Management Server and then generating a package file that contains all of the serialized data that defines those objects, as well as any additional objects they may reference. The package file is a ZIP compilation that includes an XML file that contains all the serialized object definitions, as well as the content files for any content object types. Note: The WEM software cannot import a package file greater than 2 Gigabytes in size. If you have a package file that exceeds this limit, you must split what you are exporting into more than one package file. The following checklist outlines the basic tasks involved in the export process: Identify objects to be exported using a package manifest. OpenText Web Experience Management Administration Guide 269

270 Chapter 14 Exporting and Importing Objects Use the package manifest to compile data from the source server into a package file. Alternatively, you can manually create a package file to migrate data objects that originate in a source other than a compatible Content Management Server, such as an earlier Content Management Server or a third-party content management tool. Refer to Migrating Non-WEM Data on page Import Overview Importing in the WEM software is the act of reading a package file to either add data objects to a target Content Management Server or update or delete existing data objects in a Content Management Server. The following checklist outlines the basic tasks involved in the import process: Optional :Run a resource survey (vgnimport-s option) to identify required resources. Note: This step will also validate manually created package files to ensure successful import. After running the survey, ensure that any resources required by objects identified in the package file already exist on the target Content Management Server. Import the package file Identifying Data: Writing a Package Manifest You identify data that you want to move between Content Management Servers by writing a package manifest. The package manifest is an XML file that specifies objects in the source Content Management Server and indicates what action to take for each of those objects upon import to the target Content Management Server. The XML file must conform to the packagemanifest.xsd schema definition located at: <WEMinstallDir>/Content/10_5/adm/xmlschemas/<version>/ packagemanifest.xsd In your package manifest, you identify objects to export based on whether you ultimately intend to import them into or delete them from the target Content Management Server. Therefore, those objects are identified as entries in either an <imports> or <deletes> element in the XML definition. For example: <?xml version="1.0" encoding="utf-8"?> <packagemanifest xmlns:xsi=" xmlns=" xsi:schemalocation=" 270 OpenText Web Experience Management Administration Guide

271 14.2. Identifying Data: Writing a Package Manifest importexport 8500/packageManifest.xsd"> <deletes> <<objecta>/> <<objectb>/> </deletes> <imports> <<object1>/> <<object2>/> <<object3>/> </imports> </packagemanifest> Note: There is a space in the xsi:schemalocation attribute between importexport and Objects identified as entries in the <imports> element will be marked for insertion in the target Content Management Server upon import and objects identified as entries in the <deletes> element will be marked for removal from the target Content Management Server during import. Note: During import, all <deletes> elements are executed before processing any <imports> elements (regardless of the order in which they appear in the package manifest file. The following Application Services objects cannot be exported or imported: Roles/Capabilities Classifications (Taxonomies) Note: Although neither of the WEM export and import commands transfer actual classification/taxonomy items, both commands do preserve the classification data for content items (which taxonomy categories they're associated with). If you create the classifications manually on the target environment before importing your content, when you import that content, its classification will be preserved. OpenText Web Experience Management Administration Guide 271

272 Chapter 14 Exporting and Importing Objects Specifying Objects in the Package Manifest To specify an object in the manifest, you use the object's WEM ID or a name/type pair reference. The object type may constrain which method you can use. How Objects can be Specified in the Package Manifest on page 272 shows which method(s) you can use to specify each object type in your package manifest: Table 14-1: How Objects can be Specified in the Package Manifest Object Type Can be Specified by: WEM ID Name/Type Channel Yes Yes Configuration node No Yes Content instance Yes No Content type definition Yes Yes Object type Yes Yes Preferences No Yes Program task Yes Yes Project Yes Yes Site Yes Yes Site content type Yes No Static file Yes Yes Workflow definition Yes Yes Note: Before you can import a site that is associated with one or more delivery stages, those same delivery stages must exist on the target Content Management Server. Otherwise, you will receive an error Specifying an Object by WEM ID When specifying an object in the package manifest using its WEM ID, use the following syntax: <object id="<wem_content_id>"/> For example: <object id="a7384c552f728f00vgnvcmserver arcrd"/> You can see an object's WEM ID by positioning the pointer over the object in the Management Console. In Content Workspaces the WEM ID displays in object s Properties. 272 OpenText Web Experience Management Administration Guide

273 14.2. Identifying Data: Writing a Package Manifest In Management Console, the object details appear in your browser's status bar, as shown in Figure Figure 14-1: Example of the WEM ID in the Management Console In Content Workspaces, you see WEM ID for the Channel, Content instance, Project, Site, Site content type, and Static file on the Overview tab in the Properties of each type, as shown in Figure Figure 14-2: Example of the WEM ID in Content Workspaces The WEM ID is typically the last element of the string. Copy the WEM ID to your clipboard and paste it into a field or other location on your computer. To copy the WEM ID from the Management Console to your clipboard: 1. Right-click the object's display name in the Management Console 2. Select Copy Link Location from the context menu. OpenText Web Experience Management Administration Guide 273

274 Chapter 14 Exporting and Importing Objects 3. Paste the copied link location into the location of your choosing. 4. Remove the extraneous status information to isolate the WEM ID. For example, the WEM ID shown in Figure 14-1 is isolated to: 0eaad3fe6bdaa310VgnVCM aRCRD Note: Alternatively, you can programmatically obtain the WEM ID by writing a program that calls the getcontentmanagementid method on the ManagedObject class. To copy the WEM ID from the Content Workspaces to your clipboard: 1. In Content Workspaces, open the editor for the object type. 2. In the editor, click Properties. 3. In the Properties window, on the Overview tab, copy the WEM ID and use it to specify an object in the package manifest Specifying an Object by Name and Type When specifying an object in the package manifest using its name and type, use the following syntax: <object name="<name>" type="<type>"/> Within this syntax, the value for the name attribute is defined differently depending on each object type. Each object type resides at some level in a specific default project. Depending on whether the object is restricted to the root of that default project or can reside multiple levels down from the root project, the object's name value may or may not need to include a path of parent projects. The following sections provide additional detail in constructing the name and type values for several object types. Site A site always exists at the root level of its default project. Therefore, since there can be no nested project path, when you specify a site as an object in your package manifest, the name value is the site name itself. The syntax for a site entry is: <object name="<sitename>" type="<site>"/> For example: <object name="<mysite>" type="<site>"/> Channel All sites automatically parent four root channels that are part of the site definition. You cannot delete these root channels, nor can you create a channel that is parallel to them, so any custom channels must be sub-channels of one of the default channels or 274 OpenText Web Experience Management Administration Guide

275 14.2. Identifying Data: Writing a Package Manifest of another custom channel. For example, you may have a site hierarchy that appears as follows: -mysite + Home =mychannela *mychannelb + Unassigned Content + Archived Content + Application Assets As the preceding example shows, you can only create new channels beginning with the level under the root channels. Since a channel exists as a child of a site, its default root project is the same as a site's. So, when specifying a channel as in your package manifest, the name value is the site name plus the default channel, plus any additional parent channels, plus your channel. The syntax for a channel entry is: <object name="<sitename>(/ <channelname>)+" type="channel"/> For example: <object name="mysite/home/mychannela" type="channel"/> <object name="mysite/home/mychannela/mychannelb" type="channel"/> If you want to include all of the channels for a given site, just specify the site itself and all the channels will be included by reference. Similarly, you can specify all the channels under a default channel by specifying that default channel. Project Note: Do not import root channels independently (for example, / mysite/home). The root channels are always included in a site entry and if you try to import one separately, if its parent site is not on the target Content Management Server, the import will succeed, but you will not be able to access the channel through the Management Console because its site does not exist. A project is a directory element in your content management structure. You can create multiple levels of nested projects. So, when you specify a project as an object in your package manifest, the name value is the entire path of parent projects. The syntax for a project entry is: <object name="(/ <projectname>)+" type="project"/> For example: <object name="/myprojecta" type="project"/> OpenText Web Experience Management Administration Guide 275

276 Chapter 14 Exporting and Importing Objects <object name="/myprojecta/myprojectb/myprojectc" type="project"/> Content Type Even though the definitions for content types can exist in nested projects levels within their default project, a content type name must be unique for the entire Content Management Server. When specifying a content type in your package manifest, use the XML name of the content type for the name value. The syntax for a content type is: <object name="<contenttypename>" type="contenttype"/> For example: <object name="myct" type="contenttype"/> Object Type Object types always exist in their default project, so there are no parent projects relative to that location. When specifying an object type in your package manifest, use the XML name of the object for the name value. The syntax for an object type is: <object name="<objecttypename>" type="objecttype"/> For example: <object name="site" type="objecttype"/> Configuration Node Configuration values are contained within a structure of nodes. You cannot specify a single configuration node as an object for export, so you must specify the node that contains it, as well as any parent nodes up to the node you want to capture, using the following syntax: <object name="(/ <nodename>)+" type="confignode" /> For example: <object name="/vcm-vgninst/cmsvcs" type="confignode" /> <object name="/vcm vgninst/cmsvcs/vmc/wc/system/ widget RadioButto" type="confignode" /> Program Tasks Program tasks reside at the root level of their default project, so their name value is just the program task name. The syntax for a program task is: <object name="<programtaskname>" type="programtask" /> For example: 276 OpenText Web Experience Management Administration Guide

277 14.2. Identifying Data: Writing a Package Manifest <object name="mytask" type="programtask" /> Workflow Definitions You can define nested projects levels within the default project for workflow definitions. So, for a workflow definition in your package manifest, the name value is any parent projects plus the workflow name. However, if there are no additional projects in the root, you can simply provide the workflow name. <object name="( <workflowproject>/)* <workflowname>" type="workflow"/> For example: <object name="myworkflow" type="workflow" /> <object name="workflowprojecta/workflowprojectb/myworkflow"type="workflow" /> Preferences Preferences are identified for export using the type specifier of preferences type specifier and a name value in the form of: <username>:<node_path> <username> can be a specific WEM user ID, or an asterisk (*) to indicate all users. If you omit <username>, that indicates that the preference is system-wide. <node_path> must be a path to the preference node you want to export. The node and all key-value pairs assigned to that node will be exported to the package file, along with all of the node's child nodes and their key-value pairs (and the child nodes' child nodes, and so on). If you do not want the child nodes to be exported, set the subpreferences option to false. Note: The value of <node_path> specifies a whole node to export. This will export the node and all of its key-value pairs. It is not possible to export just one key-value pair in a node. For more information and examples, see Managing Preferences for Content Workspaces on page 441. Note: When WEM imports preferences, it overwrites the entire portion of the preference tree you specified in your package manifest; it even ignores any values specified in the conflictpolicy option. OpenText Web Experience Management Administration Guide 277

278 Chapter 14 Exporting and Importing Objects Referenced Objects When you specify an object in your package manifest, that object may be linked to other objects in several ways. For example: Association A content item (a content instance or a static file) may be associated with one or more channels. Containment A project may contain other nested projects. Instantiation A content instance is an instance of a content type. These "linked" objects are called referenced objects. When an object is exported, all of its referenced objects are automatically exported with it. You can override this automatic inclusion by setting certain options during export. Refer to Option Combinations for Specific Export Instructions on page 287 for details. Referenced Objects by Type on page 278 lists the object types that automatically reference other object types. Table 14-2: Referenced Objects by Type Exported Object Type Channel Configuration node Content instance Content type Object type Program task definition Project Site Static File Workflow definitions Automatically Grouped Referenced Objects Contained sub-channels, associated content instances, associated static files Contained configuration nodes and values Content types from instantiation, referenced objects Associated content types, associated static files, associated workflows Associated workflows None Contained sub-projects, contained content types, contained content instances, contained static files, contained workflows, contained program tasks Contained sub-channels, associated content types, associated content instances, associated static files, associated workflows None Associated workflows Note: In a <delete> entry, the only referenced objects that will be automatically deleted with the specified object are contained objects (such as children of the specified object). For example, deleting a content type will not delete its associated workflows or static files. 278 OpenText Web Experience Management Administration Guide

279 14.2. Identifying Data: Writing a Package Manifest Grouping Objects Grouping allows you explicitly define dependencies among related objects. This enables you to expedite your import because if one of the objects in a group fails, the remaining objects in that group will be ignored for the rest of the import process. Some groups are assigned automatically, but you can assign groups manually, as well. Automatically Assigned Groups When you specify an object for export, that object and all of its referenced items are automatically assigned to a group during export. The group affiliation will be specified in the generated package file in the following naming convention: group="vgngrp_ <n>" Any given object can belong to multiple groups. Suppose you specify two sites as objects in your package manifest. Each site references many other objects such as channels, content instances, static files, and workflow definitions. During export, each site, along with all of its referenced objects, is assigned to a group. If the sites reference any of the same objects, those objects would belong to both groups. Figure 14-3 illustrates two site objects that reference the same workflow definition. Figure 14-3: Multiple Group Example In the example shown in Figure 14-3, the shared workflow definition, workflowa, would have two group assignments in the generated package file. Because the workflow definition belongs to both groups, if any of the objects in either group fails, workflowawill not be processed on import. Similarly, if workflowa is the object that fails, none of the remaining objects in either group will be processed for import. If there are objects that you would like to ensure are processed, you can add them to the package manifest individually, which would automatically assign the object to its own group. As long as the object in question is not the failing object, it can belong to multiple failed groups and as long as it belongs to at least one group without a failure, it will continue to be processed on import. OpenText Web Experience Management Administration Guide 279

280 Chapter 14 Exporting and Importing Objects Manually Assigned Groups If two objects are not referenced by one another, you can still create a dependency between them for import. For example, sites never reference each other, but if you want to make sure that they successfully import or fail together, you can manually assign them to the same group in their package manifest entries, using the following syntax: group=<groupname> For example: <object name="mysitea" type="site" group="group1"> <object name="mysiteb" type="site" group="group1"> Note that each object has the same group specification. Note: You can use any group name you wish when manually creating group assignments. However, you should avoid using the naming convention of automatically assigned groups (VGNGRP_ <n>) Package Manifest Example The following package manifest example illustrates the syntax required to specify objects for import and deletion by WEM ID and name/type values as well as to provide additional group specifications. <?xml version="1.0" encoding="utf-8"?> <packagemanifest xmlns:xsi=" xmlns=" xsi:schemalocation=" <imports> importexport 8500/packageManifest.xsd"> <object name="mysitea" type="site" group="sites"/> <object id=" af10vign aarcrd"/> <object name="mysiteb" type="site" group="sites"/> </imports> <deletes> <object name="/myprojecta/myfile.txt" type="staticfile"/> 280 OpenText Web Experience Management Administration Guide

281 14.3. Migrating WEM Compatible Data </deletes> </packagemanifest> 14.3 Migrating WEM Compatible Data The primary function of the Export/Import feature is to move data between two compatible Content Management Servers. WEM supplies an export command and an import command to facilitate the task Using the Export Command The command line utility for exporting from a Content Management Server is vgnexport. The command is available as a batch file and a shell script in the following locations: Windows <WEMinstallDir>\Content\10_5\bin\vgnexport.bat UNIX <WEMinstallDir>/Content/10_5/bin/vgnexport Note: By default, the log level for vgnexport.bat/.sh is INFO, however it can be changed to DEBUG by specifying the -debug option as follows: <WEMinstallDir>\Content\10_5\bin\vgnexport.bat -debug You can obtain general information about the vgnexport utility while not actually exporting objects by using the following options: -? Returns usage instructions and valid syntax information -v Returns the current version of the vgnexport utility You can export all of the objects in your package manifest file using the following syntax: vgnexport -m <manifestfile> [- <option1> <value1>] [- <option2> <value2>]... As a convenience, if you want to export a single object only, you can skip the use of a package manifest and identify the object directly in the command line. As when using a package manifest, you can identify an object by its WEM ID or by its name and type (depending on the object type). The command syntax for these options, respectively, is: vgnexport -i <WEMContentID> [- <option1> <value1>] [- <option2> <value2>]... vgnexport -n <objectname> -t <objecttype> [- <option1> <value1>] [- <option2> <value2>]... OpenText Web Experience Management Administration Guide 281

282 Chapter 14 Exporting and Importing Objects Note: Identifying an object directly in the command line has the following limitations compared to using a package manifest: You can identify only one object entry and you cannot add subsequent entries to the resulting package file. You cannot specify a <delete> entry directly in the command line. You can provide values for vgnexport options either directly through the command line or through an options file. vgnexport Valid Options Summary on page 282 provides a list of valid options (in alphabetical order) for vgnexport. Table 14-3: vgnexport Valid Options Summary Option Required Description -c <key>= <value> Applies the specified key to all objects for the current command statement. When this key is not specified for the current command, the default values for each key are applied to all objects. Valid control keys include: acls Specifies whether to include Access Control List (ACL) information for each object in the export. Acceptable values are true (the default), or false. channelassocs Specifies whether to export channel associations. Acceptable values are true (the default), or false. classifications (WEM version and later only.) Specifies whether to export each object's taxonomy classification information. Applies only to content instances and static files. Acceptable values are true (the default), or false. contenttyperefs Specifies whether to export content type references. Acceptable values are true (the default), or false. errorpolicy The action to take when an error occurs during processing. Acceptable values are: stop (the default) Abort the export completely. continue Continue exporting objects, but ignore associated objects in the same group as the failed object. projectcontent Specifies whether to export the contents of projects. Acceptable values are true (the default), or false. 282 OpenText Web Experience Management Administration Guide

283 14.3. Migrating WEM Compatible Data Option Required Description -c <key>= <value> (continued) resultslevel Specifies what level of status to display or log upon completion of export. Acceptable values are: all Returns all numerical tallies, as well as a list of which objects were successfully exported, which failed to export because of errors, and which were ignored due to a grouped object's failure. info (the default) Returns all numerical tallies, as well as a list of which objects failed to export because of errors, and which objects were ignored due to a grouped object's failure. error Returns all numerical tallies, as well as a list of which objects failed to export due to an error. none Returns only the numerical tallies. schedulingdates Specifies whether or not dates for scheduled publishing and unpublishing are exported. Applies only to content instances, static files, and channels. The default value (true) indicates that publishing and unpublishing dates are to be exported. Note: Channels do not have unpublishing dates. subchannels Specifies whether to export subchannels. Acceptable values are true (the default), or false. subpreferences Specifies whether to export the user preferences' sub-nodes. Acceptable values are true (the default), or false. For more information about user preferences, see Managing Preferences for Content Workspaces on page 441. subprojects Specifies whether to export subprojects. Acceptable values are true (the default), or false. suppressworkflows Specifies whether to suppress the processing of object workflows during import. Acceptable values are true (suppress workflows), or false (do not suppress workflows). The default is false. OpenText Web Experience Management Administration Guide 283

284 Chapter 14 Exporting and Importing Objects Option Required Description -c <key>= <value> (continued) -d <description> contenttypes Controls how content type objects are handled as package files are processed. Acceptable values are true and false, with true being the default. If the switch is set to true, any content instances exported to a package file will be automatically exported as well. Any content types referenced by other objects, including other content types, will be exported. If the switch is set to false, content types will generally be ignored. Any content types encountered by reference either from instances of a content type or through references from other objects, will not be included in an exported package file. This is also true for content types referenced by other content types even if the contenttyperefs switch is set to true. Even when the switch is set to false, if a content type is explicitly specified to vgnexport either on the command line or through a package manifest file, then that content type will still be included in the package file. contentreferences Controls how objects referenced by content items (content instances and static files) are handled. Acceptable values are true and false, with true being the default. If the switch is set to true, objects referenced by exported content items are automatically exported to the package file. When the switch is set to false, objects referenced by exported content items are ignored and not exported to the package file. sitesegmentprofiles Controls how SegmentProfile objects are handled. The SegmentProfile type is a system defined content type that can be associated with site objects. Acceptable values are true and false, with true being the default. If the switch is set to true, SegmentProfile associated with exported site objects will also be exported. When this switch is set to false, SegmentProfile objects associated with exported site objects will not be exported. Inserts a text description in the package file. The value of description must be a quote-enclosed string. For example: This package file imports two sites: europe and asia. 284 OpenText Web Experience Management Administration Guide

285 14.3. Migrating WEM Compatible Data Option Required Description -D <key>= <value> Sets the Java System class property identified by <key> to the value in <value>. You can specify this option multiple times to set multiple properties. -f <pkgpath> yes Specifies the location to generate the package file. For example: -h <host>: <port> yes Windows: C:\vgnpkgs\sites\euro.zip UNIX: /opt/vgnpkgs/sites/euro.zip If you specify an existing package file, it will be overwritten by the current output. Specifies the host name and port number of the source Content Management Server. -i <objectid> yes Specifies the WEM ID of a single object to be added to the package file. Note: This method only exports a single object for import. To export multiple objects for import or to delete objects, use the -m option in conjunction with a package manifest. -l <logfile> Generates a log file in the specified location. The value of <logfile> must be a fully-qualified path; for example: Windows: C:\vgnmanifests\export.log UNIX: /opt/vgnmanifests/export.log -m <manifest> \xfc * Specifies the location of the package manifest file to be used as the object data source. For example: Windows: C:\vgnmanifests\euro.xml UNIX: /opt/vgnmanifests/euro.xml -n <name> \xfc * Specifies the name of the single object to be added to the package file. Must be used in conjunction with -t. Note: You cannot add objects to an existing package file this way. To specify more than one object for inclusion in the package file, use the -m option in conjunction with a package manifest. -p <password> \xfc Password for logging into the Content Management Server (authenticating the user). If you do not supply a password, vgnexport prompts for one. OpenText Web Experience Management Administration Guide 285

286 Chapter 14 Exporting and Importing Objects Option Required Description -t <type> \xfc * Specifies the type of a single object to be added to the package file. Must be used in conjunction with -n. You cannot use the name/type pair for content items. You must use -i. Valid values include: site, channel, project, objecttype, contenttype, staticfile, workflow, programtask, confignode, preferences. Notes This method only exports a single object for import. To export multiple objects for import or to delete objects, use the -m option in conjunction with a package manifest. The preferences setting allows you to manage preferences for the Content Workspaces. For more information, see Managing Preferences for Content Workspaces on page u <username> \xfc Specifies an authorized user for vgnexport to log into the Content Management Server (authenticating the user). -x <optionsfile> Identifies an XML file that provides values for any of the options listed in this table. If an option is specified both in the options file and on the command line, the command line value will prevail. The value of <optionsfile> must be a fully-qualified path; for example: Windows: C:\vgnmoptions\export_opt.xml UNIX: /opt/vgnoptions/export_opt.xml The specified package options file must conform to the schema located at: <WEMinstallDir>/Content/10_5/adm/xmlschemas/ packageoptions.xsd -z <chunksize> Specifies the number of objects to export per internal server request. A message is displayed at the completion of each request. The default value is set within the vgnexport script file. -debug To set the log level to DEBUG. * If you are using a package file to identify objects for export, the -m option is required. If you are identifying a single object for export by WEM ID, the -i option is required. If you are identifying a single object for export by name/type, the -n and -t options are required. 286 OpenText Web Experience Management Administration Guide

287 14.3. Migrating WEM Compatible Data Option Combinations for Specific Export Instructions You can set different control keys to exclude referenced files that are normally grouped with specific object types that reference them. When you are exporting a channel or a site, set the control key subchannels=false, to exclude all sub-channels from the exported group. Set the channelassocs=false to exclude any associated content instances and static files from the exported group. When you are exporting a content type, set the control key contenttyperefs=false, to exclude any associated content types and workflows from the exported group. When you are exporting a project, set the control key subprojects=false, to exclude any sub-projects from the exported group. Set the projectcontent=false to exclude any contained objects other than other projects from the exported group Using the Import Command The command for importing a package file into a Content Management Server is vgnimport and is available as a batch file and a shell script in the following locations: Windows <WEMinstallDir>\Content\10_5\bin\vgnimport.bat UNIX <WEMinstallDir>/Content/10_5/bin/vgnimport Note: By default, the log level for vgnimport.bat/.sh is INFO, however it can be changed to DEBUG by specifying the -debug option as follows: <WEMinstallDir>\Content\10_5\bin\vgnimport.bat -debug You can obtain general information about the vgnimport utility while not actually importing objects by using the following options: -? Returns usage instructions and valid syntax information -v Returns the current version of the vgnimport utility The vgnimport command reads a package file into a target Content Management Server. You can import package files generated by vgnexport or manually created package files using the following syntax: vgnimport -f <packagefile> [- <option1><value1>] [- <option2> <value2>]... You can provide values for vgnimport options either directly through the command line or through an options file. vgnimport Valid Options Summary on page 288 provides a list of valid options (in alphabetical order) forvgnimport. OpenText Web Experience Management Administration Guide 287

288 Chapter 14 Exporting and Importing Objects Table 14-4: vgnimport Valid Options Summary Option Required Description -c <key>= <value> Applies the specified key to all objects for the current command statement. When this key is not specified for the current command, the default values for each key are applied to all objects. Valid control keys include: acls Specifies whether to import Access Control List (ACL) information for each object in the import. Acceptable values are true (the default), or false. classifications (WEM version and later only.) Specifies whether to import each object's taxonomy classification information. Applies only to content instances and static files. Acceptable values are true (the default), or false. conflictpolicy Specifies what action to take if an object already exists in the target Content Management Server. Acceptable values are: ignore Do not import the object overwrite Replace the existing object with the imported object. version (the default) Capture a version of the existing object on the target Content Management Server, then replace the object with the imported object. Note: overwrite is the default for configuration nodes and workflow definitions since they cannot be versioned. errorpolicy The action to take when an error occurs during processing. Acceptable values are: stop (the default) Abort the import completely. continue Continue importing objects, but ignore associated objects in the same group as the failed object. 288 OpenText Web Experience Management Administration Guide

289 14.3. Migrating WEM Compatible Data Option Required Description -c <key=value> (continued) ignoremissingchannels In cases where a specified channel cannot be found on the target Content Management Server, the value ofignoremissingchannels specifies whether the associations for that channel should be ignored (true) or whether they should trigger an error (false, the default). resultslevel Specifies what level of status to display or log upon completion of import. Acceptable values are: all Returns all numerical tallies, plus a list of objects that were successfully imported; failed to import because of errors; or were ignored due to a grouped object's failure. info (the default) Returns all numerical tallies plus a list of objects that failed to import because of errors or that were ignored due to a grouped object's failure. error Returns all numerical tallies, plus a list of objects that failed to import due to an error. none Returns only the numerical tallies. schedulingdates Specifies whether or not dates for scheduled publishing and unpublishing are imported. Applies only to content instances, static files, and channels. The default value (true) indicates that publishing and unpublishing dates are to be imported. Note: Channels do not have unpublishing dates. structuralchangesallowed In cases where the structure of a Content Type Definition (or Object Type Definition) to be imported differs from that of an existing definition in the target system, setting the value of structuralchangesallowed to true allows the existing definition to be overwritten. Not specifying a value for structuralchangesallowed (or setting that value to false), causes importation of a definition with a different structure to fail with an exception stating that structural changes are not allowed. In either case, if the import package contains no definitions, or if they do not constitute changes to existing ones, this key has no effect. OpenText Web Experience Management Administration Guide 289

290 Chapter 14 Exporting and Importing Objects Option Required Description -c <key=value> (continued) -c <key=value> (continued) contenttypes Controls how content type objects are handled as package files are processed. Acceptable values are true and false, with true being the default. If the switch is set to true, any content types encountered in an imported package file will be imported If the switch is set to false, content types encountered in an imported package file will be ignored. sitesegmentprofiles Controls how SegmentProfile objects are handled when importing a package file. Acceptable values are true and false, with true being the default. When this switch is set to true, any SegmentProfile objects encountered in a package file will be imported. When this switch is set to false, any SegmentProfile objects encountered in a package file will be ignored. toleratecontenterror Only relevant if errorpolicy is set to continue. If a content instance or static file fails, a setting of true (the default) allows other objects in the group to continue to be processed rather than being ignored. If set to false, the standard behavior of ignoring associated group objects will prevail. versioncomment Allows you to specify a comment when creating object versions. Relevant only if the conflictpolicy is set to version. If not specified, a default string is used. Comments with spaces must be surrounded with quotes. -D <key>= <value> Sets the Java System class property identified by key to the value in value. You can specify this option multiple times to set multiple properties. -f <pkgpath> \xfc Specifies the location of the package file to use as a source for the import. For example: Windows: C:\vgnpkgs\sites\euro.zip UNIX: /opt/vgnpkgs/sites/euro.zip -h <host>: <port> \xfc Specifies the host name and port number of the target Content Management Server. 290 OpenText Web Experience Management Administration Guide

291 14.3. Migrating WEM Compatible Data Option Required Description -l <logfile> Generates a log file in the specified location to which import status information will be written. The value of <logfile> must be a fully-qualified path; for example: Windows: C:\vgnmanifests\import.log UNIX: /opt/vgnmanifests/import.log -p <password> \xfc Password for logging into the Content Management Server (authenticating the user). If you do not supply a password, vgnimport prompts for one. -s Instead of performing the import, returns a resource survey displaying the file sources, data sources, widgets, and event listeners that must exist on the target Content Management Server prior to import. Output goes to your screen or a log file, if specified. Note: This option also validates the package file. -u <username> \xfc Specifies an authorized user for vgnimport to use when logging into the Content Management Server (authenticating the user). -x <optionsfile> Identifies an XML file that provides values for any of the options listed in this table. If an option is specified both in the options file and on the command line, the command line value will prevail. For example: Windows: C:\vgnmoptions\import_opt.xml UNIX: /opt/vgnoptions/import_opt.xml The specified options file must conform to the schema located at: <WEMinstallDir>/ Content/10_5/adm/xmlschemas/ <version>/ packageoptions.xsd where <version> identifies the schema version of the XSD file; for example, 7201 or z <chunksize> Specifies the number of objects to import per internal server request. A message is displayed at the completion of each request. The default value is set within the vgnimport script file. -debug To set the log level to DEBUG. OpenText Web Experience Management Administration Guide 291

292 Chapter 14 Exporting and Importing Objects Option Combinations for Specific Import Instructions Grouped Objects Behavior You can fine tune the way the import process behaves with respect to grouped objects. When you set the control key errorpolicy to continue, if an object that belongs to a group fails, the remaining objects in that group will be skipped for the duration of the import. By default, if the failing object is a static file or a content instance, the other objects in the group will continue to be processed. However, if you specify the toleratecontenterror=false control key, all objects in a group will be ignored upon error, even if the failing object is a static file or content instance. Run a Resource Survey Certain resources - such as file sources, data sources, widgets, event listeners, users, and so on, must exist on your target server before you can perform an import. You can use the -s option to examine the package file instead of importing it and return a list of required resources. To run a survey instead of importing a package file, use the vgnimport command with the -s option, as follows: vgnimport -s -f <packagefile> Before You Run vgnimport Consider running vgnimport with the survey (-s) option before attempting to actually import your content. The survey displays the file sources, data sources, widgets, and event listeners that must exist on the target Content Management Server before you import your content. Workbench projects (including projects for Content Type Definitions) are not created on import: you must create them on the target Content Management Server before running vgnimport. Neither vgnexport nor vgnimport transfer classification/taxonomy items; however, both commands preserve classification data for content items (which taxonomy categories those items are associated with). If you create the classifications manually on the target Content Management Server before importing your content, classifications will be preserved when you import your content. If any site you exported was associated with one or more delivery stages, you must ensure that those same delivery stages exist on your target Content Management Server. Failure to do so will cause vgnimport to return an error. 292 OpenText Web Experience Management Administration Guide

293 14.3. Migrating WEM Compatible Data Import Issues In the rare case where an Object Type uses an icon (the icon being a static file), a package file containing both objects may fail to import. This is because the Object Type will be processed before the icon. Since the Object Type references the icon which has not yet been processed, one or both objects will fail to import (depending on your import control flag settings). The easiest way to work around this issue is to import the package file containing these objects twice, specifying the control flag errorpolicy=continue. In this situation, the Object Type will fail to import on the first import; however, the icon will import successfully. On the second import, the Object Type will then import successfully Using an Options File You can specify any or all options in an options file rather than directly in the command line. The options file must conform to the package options file XML schema definition located at: <WEMinstallDir>/Content/10_5/adm/xmlschemas/<version>/ packageoptions.xsd Following is an example options file: <?xml version="1.0" encoding="utf-8"?> <packageoptions xmlns:xsi=" xmlns=" xsi:schemalocation=" importexport 8500/packageOptions.xsd"> <username>rserling</username> <password>tzone13</password> <host>coyote.wem.com:27110</host> <logfile>d:\temp\myvgnexport.log</logfile> <exportpkgcontrol resultslevel="all"/> <importpkgcontrol errorpolicy="continue" resultslevel="all"/> </packageoptions> Note: You should not supply the login password through an options file if access to the file is not secure. A more secure means to log into the Content Management Server is to let the vgnexport or vgnimport CLI prompt for the password. OpenText Web Experience Management Administration Guide 293

294 Chapter 14 Exporting and Importing Objects Interpreting the Results Upon completion of each entry of the vgnexport or vgnimport command, the results are output to your screen or to the log file specified in the -l <logfile> option. In addition, Command Line Results on page 294 defines the exit codes that can be returned. Table 14-5: Command Line Results Returned Value Definition 0 The command completed successfully. 1 The command was not processed due to a failure in the issuance of the command. For example, the command syntax may have contained an error or a file specified in an option could not be located, and so on. 2-n The command encountered errors during processing. The number returned is the number of errors encountered plus 1. For example, if the command encountered 3 errors, it returns 4. If the command encountered 300 errors, it returns Modifying an Exported Package File Sometimes, you may need to manually edit a package file created by vgnexport. For example, you would need to edit the package file manually if you wanted to: Import a channel or project in a different location in the target Content Management Server than it existed in the source Content Management Server (called re-parenting). This necessity can happen when you export a sub-channel and then want to import it to the target Content Management Server under a different parent channel. The parentchannelid value for the exported channel object needs to be updated to reflect the correct parent channel ID on the target server. Remove an object entry from the exported package file. This section will introduce various elements that make up a package file to familiarize you with the basic structure. This section also provides examples of some common modification use cases so you can identify which elements you must edit in order to accomplish a particular modification. 294 OpenText Web Experience Management Administration Guide

295 14.4. Modifying an Exported Package File Package File Structural Overview A package file is a ZIP file that contains all the files representing the metadata of objects exported from a Content Management Server. The bulk of the data is contained in a file named packagebody.xml, which contains the serialized content for each object that was exported from a Content Management Server using the vgnexport command. Each object in packagebody.xml is represented as an import or delete entry in the file. For example: <importcontenttype> <body of data for the content type object> </importcontenttype> For exported program tasks, static files, or workflow objects, the actual body of content for those objects is stored in the package file as separate files in the ZIP archive. The vgnexport utility names each content file according to the following convention: VGNCONTENTS_<n>, where <n> is a number that uniquely identifies the order in which the object is referenced in packagebody.xml. However, this naming convention is not required. You can use any convention, as long as the entry name is unique and it matches the corresponding <contents entry="<value>"/> entry in the packagebody.xml text. Lastly, the package file contains a file named exportstats.xml, which provides details about the export, including the number of total entries in the package file, control settings that were specified, and the time of the export. Figure 14-4 provides a graphical example of a package file name dmypkg.zip, which contains the required package Body.xml file as well as an exportstats.xml file. In addition, as illustrates, packagebody.xml references 3 objects whose content is contained in separate files external to the package Body.xml file, but included in mypkg.zip. OpenText Web Experience Management Administration Guide 295

296 Chapter 14 Exporting and Importing Objects Figure 14-4: Exported Package File Example Editing packagebody.xml If you need to edit your generated package file to specify a different target location (re-parent an object) or use an exported object to update an object on the target server with a different name or ID, you can do so by modifying specific element values within the packagebody.xml. Note: Element values can be edited, but as a rule, you should not edit attribute values because they typically represent unique identification properties that, if edited, can cause import failures. Within a content entry in packagebody.xml, you can recognize an attribute value vs. an element value by their respective syntaxes. An element value is offset by bracketed properties, for example: <name>myct</name> An attribute value, by contrast, is offset by quotation marks and is preceded by an equal sign, for example: <capability application="vcm" name="modify"/> To modify packagebody.xml to re-parent an object or replace an existing object of a different name in the target directory, you need to replace the appropriate ID element in the object's content entry with the correct ID from the target object or location. 296 OpenText Web Experience Management Administration Guide

297 14.4. Modifying an Exported Package File Note: If you manually look up the ID of the target object and replace the corresponding packagebody.xml ID with it, you must use the Application Services ID for all objects except projects, workflow definitions, and program tasks. These last three types of objects do not have Application Services IDs, so you must use their WEM ID instead. Rather than manually finding and inserting ID values, a more convenient and accurate method is to use the <getid> element to obtain the target object's ID when the package file is imported. Using <getid> ensures that the appropriate ID (Application Services versus Content Management Server) is used according to the object type. This method also allows you to import the same package file into different target Content Management Servers, something that cannot be done when you manually insert a specific ID value. Note: If the object specified in a <getid> element is not found on the target Content Management Server during import, the object will fail. To use the <getid> element, insert it in place of the existing ID value in packagebody.xml, specifying the values for the objecttype and objectname of the target object. For example: The following parentchannelid element in a package file: <parentchannelid>d8384c...28f00vgnvcmserver arcrd</ parentchannelid> becomes: <parentchannelid> <getid objecttype="channel" objectname="mysite/home" /> </parentchannelid> Note: The name and type values of the <getid> element follow the same conventions as entries in a package manifest (documented on page page 274). When you have completed your changes to packagebody.xml, you should validate the file to ensure your changes still conform to the schema located in the following directory: <WEMinstallDir>/Content/10_5/adm/xmlschemas/<version>/packageBody.xsd Alternatively, you can validate your changes by running a survey against the updated package file using the following command: vgnimport -s -f <packagefile> Note: If you extracted packagebody.xml to a temporary directory while you edited it, when you add it back into the package file.zip, be sure that it does not include a path. For example, a correct entry in the archive reads: packagebody.xml, not temp/packagebody.xml. OpenText Web Experience Management Administration Guide 297

298 Chapter 14 Exporting and Importing Objects Removing an Object Entry You can remove an object entry contained in an exported package file by editing the packagebody.xml and exportstat.xml files contained in your package file.zip. To remove an object entry from an exported package file: 1. Remove the entire <import Object> or <delete/> element from the package body file. For example, in the following excerpt from a package body file, the entire element in italics would be removed to delete the object entry: + <importsite name=mysiteref> + <importchannel> - <importstaticfile> - <staticfile vcmlogicalpath="/myproject" vcmname="mystaticfile.txt"> <deploymenttype>cmsnative</deploymenttype> <placementpath>/myproject/mystaticfile.txt</ placementpath> <description>sample static file</description> <filesourcename>vcm Default File Source</fileSourceName> </staticfile> <contents entry="vgncontents_3"/> </importstaticfile> 2. Decrement the imports= and/or deletes= values in exportstat.xml as appropriate. Note: If the object removed was a static file, workflow, or program task, you can also optionally remove its corresponding contents file (VGNCONTENTS_<n>) from the ZIP file. It is not required that you do so. 298 OpenText Web Experience Management Administration Guide

299 14.5. Migrating Non-WEM Data Editing Content Entries If you want to replace the content file of an exported program, static file, or workflow object in your package file, you can do so by replacing the object's VGNCONTENTS_<n> file in the.zip archive with the updated file and then editing the corresponding <contents> entry in packagebody.xml to reference the new file. For example, if you exchange VGNCONTENTS_1 in the package file with staticfile.txt, you would then need to edit the <content> entry as follows: <contents entry="vgncontents_1"/> becomes: <contents entry="staticfile.txt"/> 14.5 Migrating Non-WEM Data If you want to import data objects that originate in a source other than a compatible Content Management Server, such as an earlier Content Management Server or a third-party content management tool, you can create a package file manually and then use the vgnimport command. The following checklist outlines the basic tasks involved in creating a package file: Create a ZIP file archive using any compatible utility, such as WinZip or a JAR command. Add the content files for any static files, program tasks, and workflow definitions to the ZIP file. Create an empty packagebody.xml skeleton, using the packagebody.xsd schema definition as a model. Edit the packagebody.xml file to include the entries for all of the objects you wish to include in the import. Optionally validate your packagebody.xml file against the schema definition. Add packagebody.xml to the ZIP file. Optionally run a survey to validate the entire package file. OpenText Web Experience Management Administration Guide 299

300 Chapter 14 Exporting and Importing Objects Adding Content Files to the Package File When any of the objects you intend to import into the Content Management Server is a static file, program task, or workflow definition, the content body for that object is added to the package file as a separate file and referenced as a content entry in the object's import definition in the packagebody.xml file. Since the actual content of these object types can be quite large, including them as independent files keeps the size of the packagebody.xml file to a minimum and also allows you to preserve the content file in its original format. You can add contents files to your ZIP file one-by-one or you can add an entire directory of contents files to the ZIP file. When you create your packagebody.xml file, each import entry that represents one of objects for which there is a content file in the package file must include a contents entry value that identifies the corresponding contents file. Refer to Adding Objects that Reference Previous Entries on page 304 for more detail on referencing a content object in your package file Package Body Schema The package body file is an XML definition named packagebody.xml that contains the serialized representations for all objects to be created or deleted on import. The package body file is written in UTF-8 encoding and conforms to the schema definition located in the following location of your WEM installation directory: <WEMinstallDir>/Content/10_5/adm/xmlschemas/ <version>/ packagebody.xsd Note: The version folder indicates the Content Suite release version. The most current schema definition is located in the most recent version folder (for example, 7400). Every packagebody.xml file must contain the following header information provided at the beginning of the packagebody.xsd schema definition: <?xml version="1.0" encoding="utf-8"?> <packagebody xmlns:xsi=" xmlns=" xsi:schemalocation=" importexport 8500/packageBody.xsd"> A manually created package file can create objects that do not already exist on the target Content Management Server or delete objects that do. It should not be used to modify existing objects. If you want to modify objects that already exist on your target Content Management Server, export the objects first and then modify the generated package body file, as described in Modifying an Exported Package File on page OpenText Web Experience Management Administration Guide

301 14.5. Migrating Non-WEM Data Basic Entry Syntax An entry in the package body file uses the following syntax: < <actionobjecttype>> <object definition></actionobjecttype> For example: <deletechannel> <Channel definition></deletechannel> <importsite> <Site Definition></importSite> Required Sequence for Object Types Entries in packagebody.xml must be provided in a specific sequence in order to honor object type interdependencies. For example, a static file must have a project into which it will be imported, so projects must be created before static files. The following example packagebody.xml skeleton illustrates an outline of entry types, in the order that they must appear in your definition: <?xml version="1.0" encoding="utf-8"?> <packagebody xmlns:xsi=" xmlns=" xsi:schemalocation=" importexport 8500/packageBody.xsd"> <delete type="<objecttype>" name="<objectname>"/> <importconfignode><configuration Node Definition></ importconfignode> <importpreferences><user Preferences Definition></ importpreferences> <importproject><project Definition></importProject> <importprogramtask><program Task Definition></importProgramTask> <importworkflow><workflow Definition></importWorkflow> <importobjecttype><object Type Definition></importObjectType> <importsite><site Definition></importSite> <importchannel><channel Definition></importChannel> <importstaticfile><static File Definition></importStaticFile> <importcontenttype><content Type Definiton></importContentType> OpenText Web Experience Management Administration Guide 301

302 Chapter 14 Exporting and Importing Objects <importsitecontenttype><site Content Type Definition></ importsitecontenttype> <importcontentinstance><content Instance Definition></ importcontentinstance> </packagebody> The packagebody.xml definition can contain unlimited entries of each object type. For each entry type, parent objects must always be listed before their children objects. For example, parent channels must exist in the package body before their children channels Creating Delete Entries As noted in the previous section, delete entries must be included first in the package body file so they are subsequently processed first upon import. When you create a <delete> entry in the package body file, you do not need to provide the entire body of metadata for the entry. You only need to identify the object to delete. You can identify an object for deletion from the target Content Management Server by specifying its appropriate ID or the values for its name and type using the following syntax: <delete id=" <ObjectID>"/> <delete type=" <objecttype>" name=" <objectname>"/> For example: <delete type="workflow" name="myworkflowa" /> For more information about how to obtain an object's ID or construct an object's name and type values based on object type, refer to Specifying an Object by WEM ID on page 272 or Specifying an Object by Name and Type on page Creating Import Entries When you create an import entry in the package body file, you must provide all the metadata that corresponds to that object. The attributes and elements required and available to define an object vary by object type. The schema definition for packagebody.xml provides definition requirements for each of the supported object types. However, the best way to get an idea of what the object definition for a particular object type should include is to export a similar set of objects from your Content Management Server. You can then use the generated packagebody.xml as a model for creating entry definitions of the same object types in your package body file. Note: This section discusses and provides examples for many of the most common elements and corresponding attributes in an import object entry of a 302 OpenText Web Experience Management Administration Guide

303 14.5. Migrating Non-WEM Data package body file. It does not, however, provide a comprehensive list of elements and attributes available to define object entries Defining a New Object Remember, when you manually create a package body file, the objects you define for import will be created on the target Content Management Server. The vgnimport utility will generate new IDs for each of the objects it creates on import. Therefore, it is important that you do not supply mgmtid or vcmid values, either by looking up the ID in the data source or by making up a new one. The following example shows a basic site entry in a packagebody.xml file. Every site entry definition must define the site itself as well as the four default channels that always exist at the root level of any Content Management Server-managed site. Note that none of the entries specifies values for mgmtid or vcmid. - <importsite> - <site vcmname="demo"> <name>demo</name> <description>demo site</description> <template>false</template> <siteurl>demo</siteurl> <ttl/> <stalepagepolicy>true</stalepagepolicy> - <channel vcmname="home" channeltype="home"> <name>home</name> <active>true</active> <orderassibling>1</orderassibling> </channel> - <channel vcmname="unassigned Content" channeltype="unassignedcontent"> <name>unassigned Content</name> <active>true</active> <orderassibling>2</orderassibling> </channel> OpenText Web Experience Management Administration Guide 303

304 Chapter 14 Exporting and Importing Objects - <channel vcmname="archived Content" channeltype="archivedcontent"> <name>archived Content</name> <active>true</active> <orderassibling>3</orderassibling> </channel> - <channel vcmname="application Assets" channeltype="applicationassets"> </site> <name>application Assets</name> <active>true</active> <orderassibling>4</orderassibling> </channel> - <stageassociation> <stagename>production</stagename> <deploymentgroupname>production</deploymentgroupname> <ordering>0</ordering> </stageassociation> </importsite> Adding Objects that Reference Previous Entries When creating new objects, you may need to reference other objects defined in the same package body. For example, created channels cannot be added at the root level; they must be sub-channels to one of the four default root channels on the site or to other sub-channels. Therefore, a channel needs to reference its parent channel, meaning it must reference one of the default root channels from the site you have already defined in the package body. Note: This is one of the reasons that object sequence in a package body file is so important. The ID for the site or parent channel entry must be generated before it can be inserted as a parentchannelid value in a sub-channel entry. You can use the <getid> element to identify an object in a previous entry in the package body file. WEM provides a special ref attribute of the <getid> element for use when referencing an object entry in the same package body. Using the ref value 304 OpenText Web Experience Management Administration Guide

305 14.5. Migrating Non-WEM Data to identify the previously entered object instead of the name and type values enables you to ensure that the correct ID is obtained during import, even if the name of the referenced object changes. The ref attribute uses the following syntax: <getid ref=" <ObjectRef>"/> In order to use this syntax, you must have supplied a ref value for the previously entered object. You can add a ref value to any entry by including a name attribute within the <importobject> element definition using the following syntax: <import <ObjectType> name=" <ObjectRef>"/> The following example shows a ref value added to the definition for the site created on page page 303. In the interest of space, the rest of the site entry has been collapsed. <?xml version="1.0" encoding="utf-8"?> <packagebody xmlns:xsi=" xmlns=" xsi:schemalocation=" importexport 8000/packageBody.xsd"> + <importsite name="mysiteref"> </packagebody> Once you have added the ref attribute to the previous object entry, you can use the ref attribute of the <getid> element in subsequent import entries. Note: If you use the <getid> element to reference a previous object in the package body file and the referenced object fails on import, the <getid> instruction will fail also, as will import of the referring object. The following example shows a new import entry for a channel object. The channel uses the <getid> element to reference the earlier created site and its default Home channel as the parent directory. Again, the site entry is shown collapsed to save space: <?xml version="1.0" encoding="utf-8"?> <packagebody xmlns:xsi=" xmlns=" xsi:schemalocation=" importexport 8000/packageBody.xsd"> + <importsite name="mysiteref"> OpenText Web Experience Management Administration Guide 305

306 Chapter 14 Exporting and Importing Objects - <importchannel> <channel vcmname="mysubchannel" channeltype="subchannel"> <name>mysubchannel</name> <parentchannelid> <getid ref="mysiteref/home"/> </parentchannelid> <active>false</active> <orderassibling>0</orderassibling> </channel> </importchannel> </packagebody> Adding Objects that Reference Existing Objects You can also use the <getid> element to reference objects that already exist on the target Content Management Server. For example, you may have a content instance that references its content type, which already exists on the target Content Management Server. Similarly, you might have a site that references a workflow definition that already exists. For these cases, you can specify a name/type value pair as the attributes of the <getid> element using the following syntax: <getid ObjectType=" <ObjectType>" ObjectName=" <ObjectName>"/> /literal > The workflow reference added to the site definition in the following example illustrates this option. Note: For a description of the objecttype and objectname value conventions, see the package manifest section on identifying objects by name and type pairs on page page 274. <?xml version="1.0" encoding="utf-8"?> <packagebody xmlns:xsi=" xmlns=" xsi:schemalocation=" importexport 8500/packageBody.xsd"> 306 OpenText Web Experience Management Administration Guide

307 14.5. Migrating Non-WEM Data - <importsite name="mysiteref"> <site vcmname="mysite"> <name>mysite</name> <template>false</template> <siteurl> <workflowdeployid> <getid objecttype="workflow" objectname="vgnwfautoapprove"/> </workflowdeployid> <channel vcmname="home" channeltype="home">...</channel> <channel vcmname="unassigned Content" channeltype="unassignedcontent">... </channel> <channel vcmname="archived Content" channeltype="archivedcontent">... </channel> <channel vcmname="application Assets" channeltype="applicationassets">... </channel> <stageassociation>...</stageassociation> </site> </importsite> </packagebody> OpenText Web Experience Management Administration Guide 307

308 Chapter 14 Exporting and Importing Objects Adding a Content Definition Another type of import entry definition is one that references a content file. As discussed on page page 300, the content files for static files, program tasks, and workflow definitions are added to a package file as independent files in the ZIP file. Therefore, their import entry definitions must identify the file that contains their content as the value of the entry attribute of a <contents> element. For example: <contents entry="<full path of the contents file in the.zip>"/> Note: The name of the content file in the ZIP file and the name of the static file do not need to match. The following example shows the definition for a static file added to the ongoing example package body file. Note that the static file definition, in accordance with the sequence defined on page page 300, is added to the package body after the site and channel definitions: <?xml version="1.0" encoding="utf-8"?> <packagebody xmlns:xsi=" xmlns=" xsi:schemalocation=" importexport 8500/packageBody.xsd"> + <importsite name=mysiteref> + <importchannel> - <importstaticfile> <staticfile vcmname="mystaticfile.txt" vcmlogicalpath="/myproject"> <deploymenttype>cmsnative</deploymenttype> <placementpath>/myproject/mystaticfile.txt</placementpath> <description>sample static file</description> <filesourcename>vcm Default File Source</fileSourceName> </staticfile> <contents entry="mydir1/mydir2/mystaticfile.txt" /> </importstaticfile> </packagebody> 308 OpenText Web Experience Management Administration Guide

309 14.5. Migrating Non-WEM Data The vcmlogicalpath value indicates where the static file will be placed in the target Content Management Server. For most object types, the logical path is the path relative to the object's default root project. Each object type physically resides on the server in a default root project. Within that root project, the actual object may exist in a child project any number of levels down. The WEM software assigns an alias to the default root project, so when you view an object in the Management Console, the value that appears in the Path field is made up of the alias for the default root project plus any nested projects within that root up to the project that actually contains the object you are viewing. For most objects, the logical path is the entry in the Management Console minus the alias. The exception is the channel object type. Channels (and sites) always reside at the root level of their default project, even though the Management Console Path value shows a site/channel/sub-channel hierarchy for application clarity. Object Type Default Project Mappings on page 309 provides a map between the default root project for a given object type and the alias used for that default project in the Management Console. Table 14-6: Object Type Default Project Mappings Object Type Default Root Project Management Console Alias Site /System/AppSvcs/ObjectTypes/Site None Channel /System/AppSvcs/ObjectTypes/Channel None Project / None Static File None None Content Type / System/AppSvcs/ObjectTypes/ContentTy pe Content Instance Content instances do not have a system-defined default root project. However, content type definitions can have one. If a content type definition has a default root project, instances of that type are placed in that project if no project is specified for the instance when it is created. /Workbench/ Content Type Definitions None Object Type /System/AppSvcs/ObjectTypes /Workbench/Object Type Definitions Configuration Node N/A N/A Program Task /System/vgnworkflow/programs /Workbench/ ProgramTask Definitions Workflow Definitions /System/vgnworkflow/definitions /Workbench/ Workflow Definitions OpenText Web Experience Management Administration Guide 309

310 Chapter 14 Exporting and Importing Objects The logical path can often be constructed by removing the WEM software's alias from the Path field in the Management Console. In the preceding example (on page 308), mystaticfile will be placed in the project/myproject. The example assumes that /myproject already exists on the target server. In addition to a logical path, static file definitions include a placementpath value, which provides the path relative to the file_source directory, which is the default root location for static file content files (as opposed to their object definition). Most often, the placementpath and the vcmlogicalpath match each other, but they do not have to. You can always change the default root directory for content files to use a different directory structure on your computer, in which case, the placementpath for the content body would be different than the vcmlogicalpath of the static file definition Adding File Associations You can associate different objects with one another to allow access to one from the other. For example, you my want to associate a static file with a particular channel or a workflow definition with a particular site. However, when you create an association between objects in a package file, you must make sure that the association refers to an object that already exists. So, if your package body file contains a definition for a static file and a channel and you want to associate them, you must define the association within the static file definition because the channel will be created first. The following example shows an association defined within the static file entry of the ongoing package body example. Note: Since the static file association uses the <getid> element to reference the previous channel entry, the channel entry must include a ref attribute. <?xml version="1.0" encoding="utf-8"?> <packagebody xmlns:xsi=" xmlns=" xsi:schemalocation=" + <importsite name="mysiteref"> importexport 8500/packageBody.xsd"> + <importchannel name="mysubchannelref"> - <importstaticfile> <staticfile vcmname="mystaticfile.txt" vcmlogicalpath="/myproject"> 310 OpenText Web Experience Management Administration Guide

311 14.5. Migrating Non-WEM Data <deploymenttype>cmsnative</deploymenttype> <placementpath>"/myproject/mystaticfile.txt"</placementpath> <description>sample static file</description> <filesourcename>vcm Default File Source</fileSourceName> </staticfile> <channelassociation> <referenceid> <getid ref="mysubchannelref"/> <referenceid> </channelassociation> <contents entry="mydir1/mydir2/mystaticfile.txt" /> </importstaticfile> </packagebody> Adding Access Restrictions You can grant or revoke privileges to one or more users or groups for any object by including an <acl> element that defines the user to whom you are allowing or restricting access and the corresponding privileges. The following example shows an <acl> element added to the static file definition in the ongoing package body file example. <?xml version="1.0" encoding="utf-8"?> <packagebody xmlns:xsi=" xmlns=" xsi:schemalocation=" importexport 8500/packageBody.xsd"> <importsite name=mysiteref>...</importsite> <importchannel>...</importchannel> - <importstaticfile"> <staticfile vcmname="mystaticfile.txt" vcmlogicalpath="/myproject"> OpenText Web Experience Management Administration Guide 311

312 Chapter 14 Exporting and Importing Objects <deploymenttype>cmsnative</deploymenttype> <placementpath>/myproject/mystaticfile.txt</placementpath> <description>sample static file</description> <filesourcename>vcm Default File Source</fileSourceName> <acl> <entry name="memyselfi" type="user"> <grants> <capability application="vcm" name="static_file_read" /> name="static_file_write" /> name="workflow_def_read" /> <capability application="vcm" name="modify" /> <capability application="vcm" name="modify_acl" /> <capability application="vcm" name="delete" /> <capability application="vcm" <capability application="vcm" name="security_read" /> <capability application="vcm" name="security_write" /> <capability application="vcm" <capability application="vcm" name="static_file_delete" /> </grants> </entry> </acl> </staticfile> <contents entry="mydir1/mydir2/mystaticfile.txt" /> </importstaticfile> </packagebody> 312 OpenText Web Experience Management Administration Guide

313 14.5. Migrating Non-WEM Data Adding User Preferences Content Workspaces includes a mechanism for saving user-specific configuration information from user session to user session so that users are not forced to configure their preferences each time they log in. The same mechanism that records user preferences also allows system administrators to set system-wide preferences such as which modules display, how often to refresh modules with new information from the server, and so on. You can adjust these user preferences by editing the package file according to the information in Managing Preferences for Content Workspaces on page Grouping Objects You can create a dependency among objects in your package file by assigning them to one or more groups. Although group assignments are not required, if you would like to ensure that certain objects are imported successfully together or fail together, you may want to group those objects. For example, if a channel is dependent on a site and the site fails on import, if you have not grouped them, the channel can still be imported. But because the site does not exist on the server, the channel cannot be accessed. When an object in a group fails on import, the remaining objects in that group are skipped for import as well to avoid this kind of malfunction. Grouping Objects on page 279 discusses grouping behavior in greater detail. To assign an object to a group, add a <group> element to the object's entry definition, specifying a unique name for the group. The example below assigns the three objects in the ongoing package body example to a single group. <?xml version="1.0" encoding="utf-8"?> <packagebody xmlns:xsi=" xmlns=" xsi:schemalocation=" - <importsite name="mysiteref"> importexport 8500/packageBody.xsd"> <group name="mygroup"/> <site vcmname="mysite"> <name>mysite</name> <template>false</template> <siteurl> + <workflowdeployid> OpenText Web Experience Management Administration Guide 313

314 Chapter 14 Exporting and Importing Objects + <channel vcmname="home" channeltype="home"> + <channel vcmname="unassigned Content" channeltype="unassignedcontent"> + <channel vcmname="archived Content" channeltype="archivedcontent"> + <channel vcmname="application Assets" channeltype="applicationassets"> + <stageassociation> </site> </importsite> - <importchannel> <group name="mygroup" /> + <channel vcmname="mysubchannel" channeltype="subchannel"> </importchannel> - <importstaticfile"> <group name="mygroup"/> + <staticfile vcmname="mystaticfile.txt" vcmlogicalpath="/myproject"> <contents entry="mydir1/mydir2/mystaticfile.txt" /> </importstaticfile> </packagebody> 314 OpenText Web Experience Management Administration Guide

315 14.5. Migrating Non-WEM Data Validating the Package File Use the reference survey (-s) option of the vgnimport utility to validate your package file and its contained packagebody.xml file. For example: vgnimport -s -f "C:\mypkgfiles\Package.zip" where the -f option specifies the package file's location. If the package file is valid, the survey completes successfully; otherwise, an error message is displayed to help you track down the problem. OpenText Web Experience Management Administration Guide 315

316

317 Chapter 15 Logs, Other Files, and Directories 15.1 Log Files The WEM software produces log information for each WEM component and command line tool. By default, this log information is stored in log files, although the WEM software also writes logging information to the Windows Event Viewer and to a remote UNIX syslog daemon. Log file output complies with the log4j tool standards. With knowledge of those standards and various WEM configuration variables, you can configure the amount of information that a component logs for events, errors, and warnings, and you can write logging information to destinations other than the default log files, the Event Viewer, or the syslog daemon Installer/Uninstaller Log Files The WEM software creates various installer/uninstaller log files and other files, including the following: install_wem.log Content_Management_Services_Version_10_5_Install_<datestamp>.log Content_Management_Services_Version_10_5_Uninstall_<timestamp>.log Content_Delivery_Services_Version_10_5_Install_<timestamp>.log Content_Delivery_Services_Version_10_5_Uninstall_<timestamp>.log The following section describes those logs and tells where to find them. The WEM installer log file, install_wem.log, contains information from the beginning of the installation. If you uninstall the WEM product, this file also contains information about the uninstall. install_wem.log is located in the home directory of the person installing or uninstalling the WEM software (on the host where the installer/uninstaller is being run): <userhomedir>/opentext/install_wem.log For example, if user wsmith is performing the installation, install_wem.log would be located at: Windows C:\Users\wsmith\OpenText\install_wem.log OpenText Web Experience Management Administration Guide 317

318 Chapter 15 Logs, Other Files, and Directories UNIX /u/home/wsmith/opentext/install_wem.log The Content_Management_Services_Version_10.5_Install_<timestamp>.log file is created during the CMS installation: If the installation is successful for all operating systems, the log file is created in the <WEMinstallDir> directory, where <timestamp> is the date and time the log file was created and <username> is logged in the administrator account that is used during the installation. If the installation fails, for any reason, the log file is created at the following locations: Windows: <user_desktop> non-windows: <WEMinstallDir> During uninstallation, the Content_Delivery_Services,_Version_10.5_Uninstall_<timestamp>.log file is created in the <WEMinstallDir> directory. The install_wem.log file will be updated. The Content_Delivery_Services_Version_10.5_Install_<timestamp>.log file is created during the CDS installation: If the installation is successful for all operating systems, the log file is created in the <WEMinstallDir> directory. If the installation fails for any reason, the log file is created at the following locations: Windows: <user_desktop> non-windows: <WEMinstallDir> During uninstallation, the Content_Management_Services,_Version_10.5_Uninstall_<timestamp>.log file is created in the <WEMinstallDir> directory. The install_wem.log file will be updated. 318 OpenText Web Experience Management Administration Guide

319 15.1. Log Files Setup Application Log File The WEM setup application creates its own log file: vgnsetup.log. It places this file in the vgndomain subdirectory under your WEM installation directory: <WEMinstallDir>/Content/<version>/rtsvcs/domains/vgndomain For example: Windows C:\OpenText\WEM\Content\10_5\rtsvcs\domains\vgndomain\vgnsetup.log UNIX /opt/opentext/wem/content/10_5/rtsvcs/domains/ vgndomain/vgnsetup.log Component Runtime Log Files The WEM software creates a runtime log file named <cname> runtime.log for each installed component, where <cname> identifies the name specified for the component when it was created. The following components have runtime log files: Configuration Agents Content Management Server Deployment Agent Application Services You monitor the status of a component by reviewing the information in that component's runtime log file. Note: Errors that occur in applications which call WEM APIs are not logged to the server's runtime log files unless a vgnlog.xml file is present in the application's target directory. Instead log4j issues a single error message that reads: log4j:error No appenders could be found for category <category>. See Configuring the Logging Mechanism on page 329 for more information. The monitoring subsystem of the WEM software also allows you to view a portion of the runtime log through the Configuration Console. For details, see: Monitoring the WEM Software on page 189. Look for a component's runtime log file in the logs subdirectory under that component's working directory. By default, the main working directory is located in the vcm/inst vgninst subdirectory under your WEM installation directory; for example: Windows: C:\OpenText\WEM\vcm\inst-vgninst OpenText Web Experience Management Administration Guide 319

320 Chapter 15 Logs, Other Files, and Directories UNIX: /opt/opentext/wem/vcm/inst-vgninst Note: The actual location of the working directory is set during installation and setup. Following are examples of component configuration directories for a Windows host: Working directory for the Content Management Server: C:\OpenText\WEM\vcm\inst vgninst\logs Working directory for Configuration Agent cfgagent: C:\OpenText\WEM\vcm\inst vgninst\cfgagent\logs Following are example component configuration directories for an AIX or Solaris host: Working directory for the Content Management Server: /opt/opentext/wem/vcm/inst-vgninst/logs Working directory for Configuration Agent cfgagent: /opt/opentext/wem/vcm/inst-vgninst/cfgagent/logs Typical Paths to Runtime Log Files on page 320 shows typical paths to runtime log files: Table 15-1: Typical Paths to Runtime Log Files Component Application Services Example Path Windows: UNIX: Note: Delivery stages have a log directory for their associated Application Services component; for example: C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\vcmvgninst\vcms\logs\VgnVCMx-vcmruntime.log /opt/opentext/wem/vcm/inst-vgninst/cfgagent/vcmvgninst/vcms/logs/vgnvcmx-vcmruntime.log C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\vcmvgninst\stage-Production\cds-Production\as\logs However, this directory, which is used during installation and the initial configuration likely will not contain any log files until you have created and started running a Content Delivery Application (CDA) on your WEM installation. 320 OpenText Web Experience Management Administration Guide

321 15.1. Log Files Component Configuration Agent Example Path Windows: C:\OpenText\WEM\vcm\inst vgninst\cfgagent\logs \runtime.log UNIX: / opt/opentext/wem/vcm/inst vgninst/cfgagent/logs/runt ime.log Deployment Agents Note: The prefix on the log file name indicates the Deployment Agent type. Windows: C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\vcmvgninst\cdsvcs\stage-mgmt\cds-mgmt\cda-mgmt\logs \mgmt-runtime.log C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\vcm- vgninst\cdsvcs\stage-production\cds-production\cda- Appsvcs\logs\Appsvcs-runtime.log C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\vcm- vgninst\cdsvcs\stage-production\cds-production\cda- Datamart\logs\Datamart-runtime.log Solaris: /opt/opentext/wem/vcm/inst-vgninst/cfgagent/vcmvgninst/cdsvcs/stage-mgmt/cds-mgmt/cdamgmt/logs/mgmt-runtime.log /opt/opentext/wem/vcm/inst-vgninst/cfgagent/vcm- vgninst/cdsvcs/stage-production/cds-production/cda- Appsvcs/logs/Appsvcs-runtime.log /opt/opentext/wem/vcm/inst-vgninst/cfgagent/vcm- vgninst/cdsvcs/stage-production/cds-production/cda- Datamart/logs/Datamart-runtime.log Content Management Server Windows: C:\OpenText\vcm\inst vgninst\logs \VgnVCM<x> runtime.log UNIX: /opt/opentext/wem/vcm/instvgninst/logs/vgnvcm<x> runtime.log Some component log file names contain the characters VgnVCM<x> (where <x> is an integer). VgnVCM<x> identifies the node in a management-side cluster to which the log file belongs. A value of VgnVCM1 indicates the cluster's Administration node (see Management-Side Clustering on page 81). For example, the current Content Management Server log file for node 3 would be named: OpenText Web Experience Management Administration Guide 321

322 Chapter 15 Logs, Other Files, and Directories VgnVCM3-runtime.log When a log file reaches a certain size (specified in the LOG_SIZE configuration variable), the WEM software stops logging to it. The software backs up the filled log file by renaming it; specifically, by appending a backup ID to the file name. For example, the first time VgnVCM3-runtime.log fills up, the WEM software stops logging to it and renames it to VgnVCM3 runtime.1.log. The software then creates a new current log file with the original name; for example: VgnVCM3-runtime.log, and begins logging to the new file. The next time the current log file fills up, the WEM software would create VgnVCM3 runtime.2.log, and so on, until ten backup files exist (the number specified in the LOG_BACKUP_COUNT configuration variable). At that point, backups begin overwriting the existing backup files, starting with VgnVCM3 runtime.1.log Job Engine Log File Each WEM component also has its own Job Engine log file set for capturing runtime Job Engine activity. This file set uses the following naming convention: JE-VgnVCM<x>-runtime.log Job Engine log files reside in the same directory as their associated component's runtime log file. Job Engine log files also follow the same VgnVCM<x> naming convention, rollover strategy, and numbering pattern as the component runtime log file set, as well as the same default values for number of backup files, maximum file size, and log level. Note: Job Engine log entries are sent only to the Job Engine log files. They are not duplicated in the component runtime log file set Content Workspaces Log File Content Workspaces activity is logged to the Content Management Serverlog file identified in the components section Customizing Content Workspaces Logging As a WEM administrator, you can customize Content Workspaces logging. Input to the log file is controlled by settings in vgnlog.xml file. to configure the logging mechanism, you must edit the vgnlog.xml located in <WEMinstallDir>/ Content/10_5/adm/logging. Caution If you edit the vgnlog.xml file, do not change the default logging structure provided by the WEM software. Doing so can disable existing logging features. For example, in vgnlog.xml, do not modify the category, level, or formatting information for the runtime log files (under appender name="runtime"). 322 OpenText Web Experience Management Administration Guide

323 15.1. Log Files You can set the log levels to any of the standard log4j levels (such as DEBUG or ERROR). For example, add the following entry in the XML file for the area(s) you want to affect (api, ui, or cps). For example: <logger name="vcm"> <level value="error/"> </logger> Note: Before any changes to the log file can take effect, you must restart the Content Management Server. You can also add logging contexts to the log file in order to make logged information more granular. Content Workspaces Logging Contexts on page 323 shows these additional logging contexts: Table 15-2: Content Workspaces Logging Contexts Logging Context Contexts related to API: vcm.api.activity vcm.api.authoriza tion vcm.api.category vcm.api.channel vcm.api.contentin stance vcm.api.contentit em vcm.api.contentty pe vcm.api.deploymen t vcm.api.file vcm.api.filter vcm.api.folder vcm.api.group Controls Logging Level for this Content Workspaces Functionality Events related to Workflow activities. Events and activity associated with user authorization: the success or failure for all application access such as attempting to access or modify an object without the proper privileges. Events and activity related to categories (adding, deleting, associating with content) Events related to channels (association, creation, and so on). Events related to content instances (creation, deletion, association with channels, publishing, and so on). Events related to content items (creation, deletion, association with channels, publishing, and so on). Events related to content type definitions (creation, deletion, and so on). Events and activity related to the deployment and publishing. Events related to static file activities (creation, association with channels, publishing, and so on). Events and activities related to search and browse filters. Events related to folders (creation, deletion, and so on). Events and activity related to user groups (setting or removing from folders or channels, and so on). OpenText Web Experience Management Administration Guide 323

324 Chapter 15 Logs, Other Files, and Directories Logging Context vcm.api.jsp vcm.api.managedob ject vcm.api.mypage vcm.api.objecttyp e vcm.api.preferenc e vcm.api.process vcm.api.query vcm.api.quickacti on vcm.api.recentcon tent vcm.api.role vcm.api.search vcm.api.shortcut vcm.api.site vcm.api.system vcm.api.task vcm.api.user vcm.api.utility vcm.api.versionda ta vcm.api.workflow Controls Logging Level for this Content Workspaces Functionality Events and activity occurring in JSP templates. This context captures broad level failures in rendering the look and feel of the modules. Events and activity related to any manipulation of Content Type Definitions, content instances, sites, channels, and so on. Events related to the My Page module. Events related to object type definitions (creation, deletion, and so on). Events and activity related to user preferences (modifying). Events related to workflow processes (starting, editing, monitoring, and cancelling) Events and activities related to search queries. Events and activity related to the Quick Actions module. Events and activity related to the Recent Content module. Events and activity related to user roles. Events and activity related to the Search module. Events and activity related to the Shortcuts module. Events related to sites (creation, deletion, and so on). Events and activity related to login/logout activity Events related to task-related activities (assignment, acceptance, completion, and so on). Events and activity related to users. Events related to utilities. Contexts related to Content Workspaces: vcm.ui.editor vcm.ui.console vcm.ui.widget vcm.ui.workspace vcm.ui.jsp Events related to version data for content items. Events and activity related to the Workflow module (starting, editing, cancelling, and so on). Events and activity related to the editor. Events and activity related to the Management Console. Events and activity related to widgets. Events and activity related to Content Workspaces. Events and activities related to JSP templates. 324 OpenText Web Experience Management Administration Guide

325 15.1. Log Files Logging Context vcm.ui.util Controls Logging Level for this Content Workspaces Functionality Events and activities related to utilities. Contexts related to Dynamic Site and Dynamic Portal: cps.ui.preview cps.ui.presentati on Events and activities related to preview. Events and activities related to presentation. To set additional logging contexts: 1. Open the vgnlog.xml file in an editor. 2. Add the new logging contexts under the UI logging section. For example: <logger name="vcm"> <level value="info"/> </logger> <logger name="vcm.api.authorization"> <level value="all"/> </logger> <logger name="vcm.api.channel"> <level value="debug"/> </logger> <logger name="vcm.api.site"> <level value="debug/> </logger> 3. Save your changes and close the file. 4. Restart the Content Management Server. The example in Step 2 on page 325 shows vcm.ui context set to INFO. Because of this, all Content Workspaces logging levels are set to INFO except for the following logging contexts which have been added: vcm.api.authorization vcm.api.channel vcm.api.site The additional contexts override the top-level vcm level setting. For the example in Step 2 on page 325, that means that all authorization events and activities will logged, and all events and activities to do with sites or channels will be logged at the DEBUG level. After making changes to the Content Workspaces properties files, you must restart the Content Management Server. OpenText Web Experience Management Administration Guide 325

326 Chapter 15 Logs, Other Files, and Directories Upgrade Issues If you are upgrading from OpenText Web Experience Management version 8.5 software, any changes you made to the Content Workspaces log settings will be overwritten. You will need to restore them manually and then restart the Content Management Server javaproc, stderr, and stdout Log Files The WEM software also creates javaproc, stderr, and stdout log files for various WEM components. Some configuration actions spawn a java process to perform an action. These files contain information regarding those forked actions (such as database table creation, connection tests, and so on). Following are typical paths for these files on a Windows host: C:\OpenText\WEM\vcm\inst vgninst\cfgagent\ logs\javaproc.log C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\ vcm-vgninst\cdsvcs\stage-mgmt\cds-mgmt\ cda-mgmt\logs\stderr.log C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\ vcm-vgninst\cdsvcs\stage-production\cds-production\ cda-appsvcs\logs\stderr.log C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\ vcm-vgninst\cdsvcs\stage-production\cds-production\ cda-datamart\logs\stderr.log C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\ vcm-vgninst\cdsvcs\stage-mgmt\cds-mgmt\ cda-mgmt\logs\stdout.log C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\ vcm-vgninst\cdsvcs\stage-production\cds-production\ cda-appsvcs\logs\stdout.log C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\ vcm-vgninst\cdsvcs\stage-production\cds-production\ cda-datamart\logs\stdout.log 326 OpenText Web Experience Management Administration Guide

327 15.1. Log Files Following are typical paths for these files on a UNIX host: /opt/opentext/wem/vcm/inst vgninst/cfgagent\ logs/javaproc.log /opt/opentext/wem/vcm/inst-vgninst/cfgagent/ vcm-vgninst/cdsvcs/stage-mgmt/cds-mgmt/ cda-mgmt/logs/stderr.log /opt/opentext/wem/vcm/inst-vgninst/cfgagent/ vcm-vgninst/cdsvcs/stage-production/cds-production/ cda-appsvcs/logs/stderr.log /opt/opentext/wem/vcm/inst-vgninst/cfgagent/ vcm-vgninst/cdsvcs/stage-production/cds-production/ cda-datamart/logs/stderr.log /opt/wem/opentext/vcm/inst-vgninst/cfgagent/ vcm-vgninst/cdsvcs/stage-mgmt/cds-mgmt/ cda-mgmt/logs/stdout.log /opt/opentext/wem/vcm/inst-vgninst/cfgagent/ vcm-vgninst/cdsvcs/stage-production/cds-production/ cda-appsvcs/logs/stdout.log /opt/opentext/wem/vcm/inst-vgninst/cfgagent/ vcm-vgninst/cdsvcs/stage-production/cds-production/ cda-datamart/logs/stdout.log Command Line Utilities Log Files Each WEM command line utility also maintains a log4j-based log file which uses the same default format as the runtime log files. These log files are stored in the user's home directory under the WEM subdirectory. For example: Command cfgaction Example Path Windows: C:\Users\jsmith\OpenText\cfgaction.log UNIX: /u/jsmith/opentext/cfgaction.log OpenText Web Experience Management Administration Guide 327

328 Chapter 15 Logs, Other Files, and Directories Command cfgedit Example Path Windows: C:\Users\jsmith\OpenText\cfgedit.log UNIX: /u/jsmith/opentext/cfgedit.log configp Windows: C:\Users\jsmith\OpenText\config.log UNIX: /u/jsmith/opentext/config.log vgnupgrade Windows: C:\Users\jsmith\OpenText\upgrade.log Default Log File Format UNIX: /u/jsmith/opentext/upgrade.log Following is an example line from a runtime log file: :38:14,399 ERROR tte.logging.vgnloggedexception : Node /cs not found [Thread-5] [] Each message logged to a WEM log file contains the following information: Date (for example: ) Uses the ISO8601 format which is locale independent. The log4j mechanism does not support localization and/or timezones. Timestamp (for example: 15:38:14,399) Uses millisecond resolution (using local time). Message Level (for example: ERROR) The message's log4j level. By default, the WEM software reports the following levels of messages: ERROR, INFO, and WARN. Class path (possibly truncated) The log4j <category> information, including package (for example, the truncated value tte.logging, indicating the com.vignette.logging package) and the class (for example, VgnLoggedException). Note: By default, the method name is not included in the category information, nor is it included under a separate method field. You can modify the vgnlog.xml template to include method, file, and line number; however, doing so imposes significant performance penalties. Caution If you modify vgnlog.xml, do not change the default logging structure provided by Web Experience Management. Doing so can disable existing 328 OpenText Web Experience Management Administration Guide

329 15.1. Log Files logging features. You can, however, add appenders to the file for your customization needs. Message ID (for example: ) Not present in log lines at the DEBUG message level. Message (for example: Node /cs not found) Text message. Thread ID (if applicable; for example: Thread-5). Context The log4j Nested Diagnostic Context Configuring the Logging Mechanism The WEM software allows you to configure portions of its logging mechanism. For example, you can: Change the logging mechanism for a component, including that component's logging level, log file location, log file size, and so on. Change the logging level for one of the command line utilities. Change the default format of a log file for an installed component or for a command line utility Changing the Logging Mechanism for Components For each installed component, you can reconfigure the logging mechanism by using the Configuration Console to alter a component's configuration variables that control the following aspects of logging: Log Level Log Directory Log File Size and Backup Count Log File Definition Template See also: Creating, Changing, or Deleting Configuration Variables on page 175, for information on accessing and changing configuration variables OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) Log Level By default, a component's runtime log file contains ERROR, WARN, and INFO level log4j events. (It also contains all the changes made to the configuration values for your installation.) Note: By default, the WEM software writes only ERROR-level events to the Event Viewer or syslog. OpenText Web Experience Management Administration Guide 329

330 Chapter 15 Logs, Other Files, and Directories If you want to track DEBUG events for a particular installed component, you can change the value of the component's LOG_LEVEL configuration variable from INFO (the default) to DEBUG. Setting the value to DEBUG causes all level of events to be logged to a runtime log file ERROR, WARN, INFO, and DEBUG. Log Directory The LOG_DIR configuration variable controls the default location of the runtime log file for a particular component. The component will create its runtime log file in whatever directory you specify as the value for LOG_DIR. Note: The WEM software does not write Deployment Agent errors back to the Content Management Server runtime log file. Each Deployment Agent maintains its own runtime log file. Log Size and Count By default, the WEM software continues to add logging information to the runtime log file until it grows to 23.8 MB. At that point, it saves a copy of the runtime log file as <cname> runtime.1.log (in the same directory) and creates a new, empty <cname> runtime.log file. When the new file grows to 23.8 MB, the WEM software creates <cname> runtime.2.log, and so on. To change the maximum size for the log file, edit the LOG_SIZE configuration variable. You can also adjust the maximum number of log files that the WEM software saves by setting the LOG_BACKUP_COUNT configuration variable. The default is 10. When the total number of saved log files reaches the value in LOG_BACKUP_COUNT, the WEM software begins to overwrite the saved log files. Note: With the default values for log size and backup count, the WEM software maintains a maximum of 262 MB of logging information for each component: one active runtime log file and ten archived files. Log File Definition Template By default, the WEM software initializes logging for a component based on a structure definition found in the component's logging template file, named vgnlog.xml. You can specify an alternate template file by specifying the alternate file's name for the value of the component's LOG_TEMPLATE configuration variable. Caution If you specify an alternate template file, make sure that file maintains the basic logging structure provided by the WEM software. Failure to do so can disable existing logging features. For more information, see Changing the Default Log File Format on page OpenText Web Experience Management Administration Guide

331 15.1. Log Files Changing the Log Level for Command Line Utilities By default, the default logging level for all WEM command line utilities (cfgedit, cfgaction, configp, and so on) is set to the INFO level. You can change the logging level to DEBUG by specifying the -v option when you run one of the commands Changing the Default Log File Format The log4j tool reads configuration settings directly from vgnlog.xml. To further configure the logging mechanism, you can edit the vgnlog.xml file. Caution If you modify vgnlog.xml, do not change the default logging structure provided by the WEM software. Doing so can disable existing logging features. For example, in vgnlog.xml, do not modify the category, level, or formatting information for the runtime log files (under appender name="runtime"). The vgnlog.xml file resides in the following directory: <WEMinstallDir>/Content/10_5/adm/logging/ For example: Windows C:\OpenText\WEM\Content\10_5\adm\logging\ UNIX /opt/opentext/wem/content/10_5/adm/logging Note: While you may find other vgnlog.xml files on your system, only the one in the directory above is for changing the default log file format. The vgnlog.xml file is shared on a node for all components under the Configuration Agent. For example, a Configuration Agent, Content Management Server, and all Deployment Agents on the same host machine share the same vgnlog.xml file. If you want a different logging definition for a specific component, you must change the value of the LOG_TEMPLATE configuration variable for that component to point to a different file with its own log4j template definition. As cautioned previously, do not change the default logging structure provided by WEM. In addition to the default log file (<cname> runtime.log), you can use the log4j API to create custom logging appenders that specify where to log information, which fields to log, what order to log them, or any arbitrary formatting text to be intermixed with the log fields. Following are examples of custom appenders: <!-- XMLLayout to SocketAppender to Chainsaw --> <appender name="chainsaw" class="org.apache.log4j.net.socketappender"> OpenText Web Experience Management Administration Guide 331

332 Chapter 15 Logs, Other Files, and Directories <param name="remotehost" value=" "/> <param name="port" value="4445"/> <layout class="org.apache.log4j.xml.xmllayout"> <param name="locationinfo" value="true"/> </layout> </appender> <!-- XMLLayout to File --> <appender name="chainsaw1" class="com.vignette.logging.vgnrollingfileappender"> <param name="file" value="test.log"/> <param name="threshold" value="${com.vignette.loglevel}"/> <param name="maxfilesize" value="${com.vignette.logsize}" /> <param name="maxbackupindex" value="${com.vignette.logbackupcount}" /> <layout class="org.apache.log4j.xml.xmllayout"> <param name="locationinfo" value="true"/> </layout> </appender> <!-- NT Log Appender --> <appender name="ntappender" class="org.apache.log4j.nt.nteventlogappender"> <param name="threshold" value="error"/> </appender> <!-- SMTP Appender --> <appender name="smtpappender" class="org.apache.log4j.net.smtpappender"> <param name="threshold" value="error"/> 332 OpenText Web Experience Management Administration Guide

333 15.1. Log Files <param name="from" /> <param name="to" /> <param name="smtphost" value="smtp.opentext.com" /> <param name="subject" value="error" /> <param name="buffersize" value="1" /> <layout class="org.apache.log4j.simplelayout"> </layout> </appender> See also: The log4j documentation available from the Apache website Customizing the WEM Logging Configuration Files Each Web Experience Management process has its own configuration variable (LOG_TEMPLATE) that points to a logging configuration file. By default, they all point to the same file: <WEMinstallDir>/Content/10_5/adm/logging/vgnlog.xml This means that, by default, all WEM processes use the same WEM logging configuration file. However, you can create as many different WEM logging configuration files as needed, which allows you to customize the logging behavior of each WEM process. These files can have different names, different content, and even reside in different directories (pointed to by the particular processs LOG_TEMPLATE configuration variable). The Content Management Server LOG_TEMPLATE configuration variable is accessed through the WEM Configuration Console: Configuration Console Subcomponents Log Find LOG_TEMPLATE in the right-hand pane. Note: This LOG_TEMPLATE setting overrides the LOG_TEMPLATE value set in the CDS: Configuration Console Content OpenText Web Experience Management Administration Guide 333

334 Chapter 15 Logs, Other Files, and Directories Delivery Services Content Management Stage Content Delivery Services mgmt Application Services Log You do not need to set a LOG_TEMPLATE value for the Management stage Application Services log. Each delivery stage LOG_TEMPLATE configuration variable is located at: Content Delivery Services Content Delivery Stage - stagename Content Delivery Services cdsname Deployment Agents Deployment Agent Appsvcs Deployment Agent Configuration Log If the WEM Commons Logging implementation is specified and enabled (the default setting), all Jakarta Commons Logging events originating from within a WEM process are handled according to the WEM Logging configuration file for that process. This configuration includes all non-wem categories for priority INFO in the runtime log for the given WEM process. WEM logging Configuration files must conform to the log4j DTD. That DTD allows complex and expressive means to configure logging. See the manufacturer's documentation for details about log4j and a complete description of XML configuration syntax and semantics. For most applications, it is sufficient to know how to change the relative priorities for different logging categories. In summary, this is accomplished by adding category elements to the configuration file. Each category element specifies a class of loggers and the priority to apply to them. The following sample sets the priority to DEBUG for all categories (loggers) whose name prefix begins with com.vignette. <logger> <level value="debug"/> </logger> The following sample sets the priority to INFO for all categories whose name begins with org.apache. <logger> <level value="info"/> </ logger > The following sample further restricts org.apache.axis loggers to priority ERROR. 334 OpenText Web Experience Management Administration Guide

335 15.1. Log Files <logger > <level value="error"/> </ logger > The following sample sets my.custom.package loggers to priority INFO. < logger > <level value="debug"/> </ logger > As many category elements may be specified as needed Enabling Third-Party Component Logging By default, Web Experience Management logging uses a private logger hierarchy and logging for non-wem categories is disabled. This prevents verbose third-party packages from flooding the log files. In some cases, such as when you are troubleshooting a third-party library, it may be necessary to enable logging for non- WEM categories. To enable third-party component logging: 1. Open a browser and navigate to the Runtime Services Console at <host>:<adminserverport>/console where hostname is the name of the machine on which the administration server is running and adminserverport is the administration server port number. (The default port is ) 2. Log into the Runtime Services Console using the WEM administrator username and password that you se-lected during the installation and setup process. 3. Click Lock & Edit in the Change Center area of the Runtime Services Consoles left pane. 4. Under Domain Structure, navigate to vgndomain > Environment > Servers, and click the Servers node. 5. In the right pane, click VgnVCMServer (or the WEM Server you want to configure). The main window displays showing tabs associated with settings for the server. 6. Select the Server Start tab. 7. Add the following system properties to the Arguments field: -Dcom.vignette.logThirdparty=true 8. Click Save to save your changes. 9. Under the Change Center in the left pane, click Activate Changes. 10. If you are running a management-side cluster, repeat the preceding steps for each node in the cluster. 11. Stop and restart VgnVCMServer (or your cluster nodes). OpenText Web Experience Management Administration Guide 335

336 Chapter 15 Logs, Other Files, and Directories Caution Adjusting the way WEM manages third-party component logging so that HttpClient.Wire traffic enters the log stream can severely degrade content deployment performance. This is because HttpClient.Wire at the DEBUG level will log everything that passes between the WEM Server and the Deployment Agent(s), including content Other Commonly-Accessed Directories and Files This section describes additional files and directories important for WEM administration. Other Commonly Accessed Directories and Files on page 336 shows a list of the most commonly accessed directories and files: Table 15-3: Other Commonly Accessed Directories and Files Component(s) or Tool WEM software Content Management Server Configuration Agent File or Directory installation directory (<WEMinstallDir>) working directory working directory Example Path(s) Windows: C:\OpenText\WEM UNIX: /opt/opentext/wem Windows: C:\OpenText\WEM\vcm \inst-vgninst \cfgagent\contentvgninst\vcms UNIX: / opt/opentext/wem/vcm /instvgninst/cfgagent \Content-vgninst\vcms Windows: C:\OpenText\WEM\vcm \inst vgninst\cfgagent UNIX: / opt/opentext/wem/vcm /instvgninst/cfgagent 336 OpenText Web Experience Management Administration Guide

337 15.2. Other Commonly-Accessed Directories and Files Component(s) or Tool Deployment Agent File or Directory working directory Example Path(s) Windows: C:\OpenText\WEM\vcm\ inst-vgninst\cfgagent \vcm-vgninst\cdsvcs \stage-<name>\cds- <name>\ cda- <name> UNIX: / opt/opentext/wem/vcm /instvgninst/cfgagent/vcmvgninst/cdsvcs/stage- <name>/cds-<name>/ cda- <name> Application Services configuration file Windows: C:\OpenText\WEM\vcm \inst vgninst\cfgagent \vcm vgninst\cdsvcs \stage <name>\cds- <name>\as\conf\as.cfg UNIX: / opt/opentext/wem/vcm /inst vgninst/cfgagent /vcm vgninst/cdsvcs/st age <name>/cds <name>/ as/conf/as.cfg OpenText Web Experience Management Administration Guide 337

338 Chapter 15 Logs, Other Files, and Directories Component(s) or Tool Application Services File or Directory pointer files to Application Services configuration files Example Path(s) Windows: C:\OpenText\WEM\vcm \inst vgninst \vgncfg.properties C:\OpenText\WEM\vcm \inst vgninst\cfgagent \vcm-vgninst\cdsvcs \stage-<name> \cds <name>\as\conf \vgncfg.properties UNIX: /opt/opentext/wem/ vcm/inst vgninst/ vgncfg.properties / opt/opentext/wem/vcm /inst vgninst/ cfgagent/vcm- vgninst/cdsvcs/stage- <name>/cds <name>/ as/conf/vgncfg.proper ties Application Services Event Logging Windows: <workingdir>\cfgagent \vcm vgninst\cdsvcs \stage QA\cds QA\as \logs\events \vgnevt_<<guid>>_<<timest amp>>.log UNIX: <workingdir>/ cfgagent/vcm vgninst/c dsvcs/stage QA/cds QA /as/logs/events/vgnev t_<<guid>>_<<timestamp>>. log 338 OpenText Web Experience Management Administration Guide

339 15.2. Other Commonly-Accessed Directories and Files Component(s) or Tool File or Directory Example Path(s) Configuration Agent configuration file Windows: C:\OpenText\WEM\vcm \inst vgninst\cfgagent \conf\cfa.cfg UNIX: /opt/opentext/wem/ vcm/inst vgninst/ cfgagent/conf/cfa.cfg Configuration Subcomponents configuration file Windows: C:\OpenText\WEM\vcm \inst vgninst\conf \cfs.cfg UNIX: / opt/opentext/wem/vcm /inst vgninst/conf/cfs.cfg Deployment Agent admin script Windows: C:\OpenText\WEM\vcm \inst vgninst\cfgagent \vcm vgninst\cdsvcs \stage <name>\cds <name> \cda <name>\conf \vgnadmin.bat UNIX: / opt/opentext/wem/vcm /inst vgninst/cfgagent /vcm vgninst/cdsvcs/st age <name>/cds <name>/ cda <name>/ conf/vgnadmin OpenText Web Experience Management Administration Guide 339

340 Chapter 15 Logs, Other Files, and Directories Component(s) or Tool File or Directory configuration file Example Path(s) Windows: C:\OpenText\WEM\vcm \inst vgninst\cfgagent \vcm vgninst\cdsvcs \stage <name>\cds <name> \cda <name>\conf \cda.cfg UNIX: / opt/opentext/wem/vcm /inst vgninst/cfgagent /vcm vgninst/cdsvcs/st age <name>/cds <name>/ cda <name>/conf/cda.cfg WEM Management Server configuration file Windows: C:\OpenText\WEM\vcm \inst vgninst\cfgagent \vcm vgninst\vcms\conf \cms.cfg UNIX: / opt/opentext/wem/vcm /inst vgninst/cfgagent /vcm vgninst/vcms/conf /cms.cfg Working Directory The WEM software stores various types of files in the working directory. For example: Configuration files These files need to be shared so that when the Management stage Configuration Agent updates one of them, other nodes can see the changes. Snapshots XML versions of content instances File sources (including the default file source) These must be located in the working directory. A file source is a place to drop static files. Certain log files (though there is no sharing requirement due to that) Runtime Services Runtime Services starts in the working directory so that it can find the vgncfg.properties file. That file points to the WEM configuration files. 340 OpenText Web Experience Management Administration Guide

341 15.2. Other Commonly-Accessed Directories and Files Configuration Files WEM components rely on information in configuration files for connecting to various services, such as databases and other WEM components. These configuration files are copies of the component's configuration information stored in the configuration tables. In most cases, you should use the Configuration Console to perform configuration tasks. However, some situations prevent you from doing so. In such situations, you would need to use cfgedit to edit a component's configuration file, commit the changes to the configuration database, and then push those changes out to the other configuration files. Configuration files are UTF-8 encoded, XML-formatted files. You must have read/ write authorization to a configuration file before you can access it using cfgedit. A configuration file includes a representation of the configuration path hierarchy only for those configuration variables that affect its component. The master repository for all configuration information is the Content Management Server system database. Other Commonly Accessed Directories and Files on page 336 shows the name and location of the configuration files provided by the WEM product (along with other commonly-accessed directories and files). Note: We recommend that you use the Configuration Console to change most configuration variables. See Managing Configuration Information on page 169, for more information vgncfg.properties Files vgncfg.properties files are used internally by the WEM software in conjunction with Application Services code. Do not modify these files. For more information about the Application Services code, see the Open Text Web Experience Management API Reference (Javadoc) Special Directories You may need to know the locations and functions of certain special-use directories. For example, the various tools may need to reside in specific directories, and the same requirement applies to custom processing scripts. There are also directories specified for content that is waiting to be processed by custom processing scripts before going on to its final destination. See also: Customizing Deployment and Publishing on page 407 for information on managing master and custom script files for processing files on deployment OpenText Web Experience Management Administration Guide 341

342

343 Chapter 16 Publishing and Deployment This topic defines publishing and deployment and the components that make up each. Also describes their interrelationships in terms of what happens from the time you publish a site, channel, or content item until that object reaches a target endpoint Introduction Publishing is the process of making content available to a content delivery application (CDA) for access by the intended end users of that content. Publishing is site-oriented: it is configured, initiated, and executed in the context of a site. The publishing process transfers an asset (such as a site, channel, or content item) from the Management stage to one or more delivery stages associated with a site. A stage is a collection of delivery endpoints web servers, application servers, databases, or the like for a particular WEM environment (such as a Testing environment or a Production environment). Note: If your system is configured to use OpenText Enterprise Library your published content will be archived automatically. For more information, see Archiving Published Content on page 343. Unpublishing is the process of removing assets from delivery stages. Unpublishing does not delete assets from the Management stage, nor does it remove asset associations from sites. A number of methods are available for publishing and unpublishing your content. These methods correspond to publishing policies Archiving Published Content Integration with OpenText Enterprise Library allows automatic archiving of published web content. For more information, see Section 1 Enterprise Library basic information in OpenText Enterprise Library - Scenario and Configuration Guide (EL-GGD). The archived web content is stored in the archive server, where retention schedules and OpenText Records Management classifications can be defined for different content types. For more information about Records Management, see OpenText Records Management - Installation and Administration Guide (LLESRCM-IGD). When you publish a content item, the system simultaneously creates an archived instance of that content item and stores it in the archive server. When archived, metadata such as a publisher name, publishing date, publishing job name and rendition formats (HTML and XML) are captured. The captured metadata allows you to view the publishing history for that specific piece of content, as well as export it as a report in either CSV or XLS format. Text based renditions allow you to OpenText Web Experience Management Administration Guide 343

344 Chapter 16 Publishing and Deployment visually compare different editions of published content items. For more information, see Open Text Content Workspaces Online Help, which is available in Content Workspaces. You must configure the archiving capabilities using the WEM Configuration Console. Once the system is configured to use archiving, the Archives workspace appears in Content Workspaces. Use the Archives workspace to search for archived content, see properties or all archived editions, and compare different editions of archived published content items. For more information on how to configure archiving, see Open Text Configuration Console Online Help, which is available in the Configuration Console Publishing Policies Each site can have its own publishing policy. The policy that you select depends on your specific publishing and unpublishing requirements and strategies. Web Experience Management provides four publishing policies: Manual Publishing and unpublishing are initiated through Content Workspaces. You explicitly select assets and then click either the Publish or Unpublish button. You can use the manual publishing policy to publish any publishable assets: individual content items, channels and their content, the entire site and all of its channels and content, and the taxonomy (classification). You can also use the manual policy to unpublish any previously published assets. Automatic Publishing occurs automatically when either content or a channel is approved. Approving the site object itself does not result in the automatic publishing of that site; rather, the site is published when channels or content within it are published. The automatic policy is not available to sites having multiple delivery stages. In addition, the automatic policy does not apply to unpublishing within any context (site, channel, or content). Scheduled Publishing and unpublishing are automated processes that are driven by publish dates and unpublish dates that you assign to assets. The scheduled publishing policy can be used to publish channels and content; the site object itself is not scheduled for publishing, but rather (as with the automatic policy) is published when channels or content that it contains are published. The scheduled publishing policy can also be used to unpublish at the content level (but not to unpublish channels or the site). As with the automatic policy, you can use this policy only on sites that have a single delivery stage. Custom Publishing and/or unpublishing occur according to your organization's specific requirements. For example, you could configure a multi-stage site to use automatic publishing on one stage and scheduled publishing on the next stage. This particular configuration requires no programming (assuming that the assets are approved on the scheduled publishing stage as well). Developers can also create custom publishing/unpublishing solutions for example, to support other multi-stage scenarios or to redefine the criteria by which assets are selected for publishing and/or unpublishing. 344 OpenText Web Experience Management Administration Guide

345 16.1. Introduction Publish Status Publish status is presented in the WEM console in a variety of places. The underlying API support for publish status offers multiple options to calculate publish status. The options differ primarily by the level of precision provided by each calculation. There are four levels of precision for publish status: High Precision Medium Precision Low Precision No Precision You can specify the publish status precision level through a system property set for the underlying JVM. The system property com.vignette.pubstatlevel can be set with certain integer values representing each of the precision levels available for publish status calculation. Publish Status Option Settings on page 345 provides all valid values for the precision level selection. Table 16-1: Publish Status Option Settings Value Publish Status 0 No Publish Status 1 Medium Precision 2 High Precision 3 Low Precision High Precision The system calculates the High Precision publish status based on a specified site context and for an optionally specified stage. The calculation is based on actual deployment data produced by the publishing job engine as objects get deployed to delivery stages. The calculation also takes into consideration objects contained in jobs in the job queue, including jobs that have not started. The High Precision information includes indication of objects that are still in the process of being published or unpublished, as well as indication of publishing and unpublishing success or failure. While this calculation provides the most detailed and specific information available, it also is the most expensive to compute. In environments where there is a large amount of data, the cost of this calculation can result in significant degradation of UI performance. OpenText Web Experience Management Administration Guide 345

346 Chapter 16 Publishing and Deployment Medium Precision The system calculates Medium Precision publish status based on a specified site context and for an optionally specified stage. The calculation is equivalent to the High Precision publish status calculation, however, it only takes into consideration jobs that have started, meaning the job engine has reached that job in its queue, so it has been "planned" into sub-jobs (for each endpoint), and it is somewhere in the process of actual deployment. The status information provided by this variety of publish status is also equivalent to that provided by the High Precision publish status calculation, except that no in process indication is provided for jobs that have been created, but not yet started. This option provides a moderate performance improvement over the High Precision option, but with a moderate loss of information Low Precision The system calculates Low Precision publish status independently of any site or stage context and is based only on the managed object last publish date, last unpublish date, and last modification date, each of which are updated anytime an object is published, unpublished or modified, respectively. The Low Precision publish status information is very basic and only indicates if an object is either unpublished, published or stale. If there is no last publish date, or if the last unpublish date is more recent than the last publish date, then an object is considered to be unpublished. If the last publish date is more recent than the last modification date then an object is considered to be published. And if the last modification date is more recent than the last publish date then an object is considered to be stale. The Low Precision calculation does not require any site or stage context allowing the publish status in a variety of other contexts where there is no site or channel specified. This option provides significantly better performance over the other options, especially in environments with large amounts of data, but also may lose details that may be important to some users. However, it is expected that for most users this loss will be insignificant and therefore, this is the default option No Publish Status In certain situations it may be desirable to completely disable publish status calculation. This option was more relevant before the introduction of the Low Precision option as it completely spared users the cost of publish status calculation. However, as the Low Precision calculation is based only on managed object metadata that is typically retrieved and available in all cases, it eliminates nearly all overhead cost for the publish status calculation. 346 OpenText Web Experience Management Administration Guide

347 16.1. Introduction Manually Publishing Content on Any Site You can use the Content Workspaces Publish and Unpublish buttons to initiate publishing and unpublishing of content on any site not just one that uses the manual publishing policy. This feature provides you with additional publishing and unpublishing flexibility. For example, your sites might all use the scheduled or automatic policy for the bulk of your publishing and unpublishing, while you use explicit manual publish and unpublish actions to handle exceptional conditions as well as site- and channel-level unpublishing. When you manually publish assets on a site that uses the scheduled publishing policy, you are given the option of ignoring publish/unpublish dates. This option also appears if a site uses the custom publishing policy and that policy is sensitive to publish/unpublish dates. Also note that when you manually publish on a custom publishing site, custom eligibilities are applied. A site that uses the manual publishing policy ignores publish/unpublish dates on any of its assets. Note that the Publish and Unpublish buttons are the only way (other than direct use of the Publishing API) that publishing or unpublishing ever occurs on a site that uses the manual publishing policy. For the other publishing policies, these buttons provide an additional publishing/unpublishing option. In addition to these preconfigured manual publishing and unpublishing capabilities, developers can control manual publish and unpublish operations programmatically regardless of the publishing policy of the site, as explained in Using the Publishing API on page Asset Eligibility for Publishing and Unpublishing Before a content item, channel, or other asset can be published or unpublished, it must meet certain predefined criteria referred to as eligibilities. The standard, systemmanaged eligibilities are approval status, publish date, and unpublish date. As implemented by the standard (non-custom) publishing policies, these standard eligibilities cannot be scoped to stage; that is, they apply to all stages of a multi-stage site. The custom publishing policy does not restrict you to using the standard eligibilities. Rather, developers can define custom eligibilities that match your specific requirements. These custom eligibilities are in addition to (not instead of) the standard eligibilities. Furthermore, these custom eligibilities can optionally be stagescoped, enabling you to independently determine when content is published for each stage. As a result, custom publishing offers more advanced control over publishing behavior, especially for sites using multiple stages. Here are a few publishing/unpublishing examples that the custom publishing policy can support: Content items can have an approved status on a QA stage and simultaneously have an unapproved status on the Production stage. Content can be unpublished from the Production stage and published to an archive stage on a specified date. OpenText Web Experience Management Administration Guide 347

348 Chapter 16 Publishing and Deployment The standard approval eligibility can publish content to a QA stage, and a custom status of Ready can publish content to the Production stage. A single-stage site can implement custom eligibilities using status and/or date attributes on your content types. Content within one or more channels can be published automatically to a QA stage as soon as it is approved, and to the Production stage on a later publish date. (Note that this particular scenario does not require any custom development. The standard approved status can control publishing to the first stage, and the standard publish date can control publishing to the second stage assuming that the status remains approved on the second stage.) For more about developing custom eligibilities, see the Open Text Web Experience Management SDK Development Guide Deployment and Jobs Whereas publishing and unpublishing are complete, end-to-end processes, deployment is the piece of those processes that involves the physical movement of assets to endpoints or (in the case of unpublishing) removal of assets from endpoints. To optimize the efficiency of deployment, assets that are selected for publishing or unpublishing are grouped into jobs; a job is a container for all of the assets to be published or unpublished at one time. A job contains assets from only one site and of only one type (either publish or unpublish) Enlistment-Based Jobs For the scheduled, automatic, and custom publishing policies, a process known as enlistment determines how eligibilities get used. Assets are enlisted (that is, added to an enlistment table) differently for each of these policies: Automatic publishing Content and channels are enlisted as soon as they are approved, using the approval status standard eligibility. Sites are not enlisted for publishing; rather, they are published indirectly when their channels and content are published. Unpublishing does not apply to this policy. Scheduled publishing Channels and content are enlisted for publishing based on the publish date standard eligibility. Sites are published indirectly when their channels and content are published. Content is enlisted for unpublishing based on the unpublish date standard eligibility. Neither channels nor sites are enlisted for unpublishing. Custom publishing The type of enlistment is selected for each stage of a site. If Scheduled is selected, enlistment behaves the same as for scheduled publishing; if Automatic is selected, enlistment behaves the same as for automatic publishing; if Explicit is selected, content must be enlisted explicitly by using the Publishing API, either indirectly (through a custom deployment workflow) or directly. For enlistment-based jobs, a stage-specific background process referred to as an autopublisher runs at configurable intervals to cull from the enlistment table those 348 OpenText Web Experience Management Administration Guide

349 16.1. Introduction assets of a site that are ready for publishing and unpublishing. The autopublisher creates jobs from the ripe assets and hands the jobs off to the job engine Manual Jobs Note: Enlistment-based jobs do not handle publishing or unpublishing of the taxonomy (classification). Manual jobs are those that are explicitly created in either of these ways: Using the Content Workspaces Publish or Unpublish button, regardless of the publishing policy that is in effect Through a custom program that uses the manual publishing classes within the Publishing API A manual job does not use the enlistment and autopublishing processes. Rather, once created through a Content Workspaces action or the Publishing API, a manual job is handed off to the site's default deployment workflow. Every site including those configured for the automatic, scheduled, or custom publishing policy is assigned a default deployment workflow for use with manual jobs; this workflow hands manual jobs off to the job engine Job Engine Note: When you use manual publishing on a site that is configured for enlistment-based jobs, the enlistment and autopublishing processes are simply bypassed. In the case of a site that uses the custom publishing policy, however, manual publishing respects any stage-specific custom eligibilities that have been defined; if the site has multiple stages and you are publishing via the Management Console or Content Workspaces, you are prompted to specify the stage. The job engine is responsible for executing a job and deploying the assets listed in the job to Deployment Agents. This process is the same for all jobs, regardless of the publishing policy used to create them. During job creation, the job engine evaluates the eligibility of assets and rejects any ineligible assets. Note that this use of eligibilities applies to all jobs and is distinct from the use of eligibilities for enlistment (which does not apply to manual jobs). All assets must have a status of approved to be eligible for inclusion in a job. Depending upon the publishing policy, eligibility may also depend upon the publish/unpublish dates. For more about how assets are selected for inclusion in a job, see How Assets are Collected for a Publish Job on page 359. OpenText Web Experience Management Administration Guide 349

350 Chapter 16 Publishing and Deployment Publishing Policy Summary Publishing Policy Comparison on page 350 provides a comparison of the four preconfigured publishing policies. Table 16-2: Publishing Policy Comparison Feature Publishing Policy Automatic Scheduled Manual Custom Publish content X X X X Publish channels X X X X Publish sites X* X* X X* Unpublish content Unpublish channels Unpublish sites X Publish/ unpublish the classification Deploy to multiple delivery stages Build jobs through enlistment Build jobs and submit them to a deployment workflow X X X** X X X X X X X X *Site publishing under these policies occurs only indirectly, when site contents or channels are published. **Unpublishing under the custom policy depends upon the enlistment type selected for each stage: If Scheduled, unpublishing occurs according to unpublish dates (which can be customized); if Automatic or Explicit, no unpublishing occurs. 350 OpenText Web Experience Management Administration Guide

351 16.1. Introduction Notification and Reporting Mechanisms When manual publishing is initiated through Content Workspaces, a dialog box informs the job's initiator of any ineligible assets encountered during job construction. This dialog box identifies the ineligible assets and gives the user an opportunity to correct errors so that job construction can continue. For example, if a user tries to publish a channel but the channel includes unapproved content, the dialog box enables the user to approve the content and allow the job to be recreated. For unpublish jobs that are initiated manually, there is no interactive dialog box because there is no comparable error-checking of assets in these jobs. For sites that use enlistment-based publishing (the automatic, scheduled, or custom publishing policy), several configurable mechanisms provide feedback about the results of publishing and unpublishing jobs. Business users (such as content contributors, managers, or editors) can receive alarms on their role-based Management Console home page whenever errors occur involving their content. Alarms persist until the problems are resolved. In addition, content contributors can receive notification when enlistment-based publishing encounters errors involving their content as well as when any of their content is about to be unpublished. These notifications are configurable. See Configuring Notifications on page 433. For administrators, all alarms resulting from jobs appear on the role-based home page of the Management Console. If a configurable number of failures occur, a warning alarm appears; a separate (higher) threshold can be specified for an error alarm. Administrators can also receive notification of failures; these notifications are configurable (see Configuring Notifications on page 433). In addition, the Job Console provides administrators with a number of views into the status and results of jobs, enabling them to inspect endpoints, review lists of assets that were excluded from a job because they were ineligible, and perform other troubleshooting and system-wide monitoring steps Customization Options You can customize the preconfigured publishing and unpublishing features by changing the workflow definition used by a site, creating custom activities for use in workflow definitions, or using the Publishing API directly. Each of these customization options is described below. OpenText Web Experience Management Administration Guide 351

352 Chapter 16 Publishing and Deployment Changing a Site Workflow Definition Workflow definitions model business processes. The building blocks of workflow definitions are called activities, which are the repeatable units of work involved in creating, editing, managing, approving, publishing, and unpublishing content. An activity can be either a manual task requiring user action, or an automated process performed by a program. A deployment workflow definition determines how assets are published or unpublished. Note that only manual publishing uses deployment workflow to control publishing and unpublishing. Part of site configuration is to assign a deployment workflow to be used with any manual publishing or unpublishing job for that site. WEM includes default deployment workflow definitions as well as program activities that perform processes that are commonly automated. Using these preconfigured program activities and a graphical environment called the Process Workflow Modeler, designers can create custom workflow definitions without any programming. Details about designing workflows are available in the OpenText Web Experience Management - Workflow Modeler User Online Help (WCMGT-H-UWF) Creating New Program Activities Rather than limiting yourself to the preconfigured program activities, you can have developers create custom program activities for use with your approval or deployment workflow definitions. For example, you can use custom program activities to automate deployment for a multi-stage site. Program activities are defined in XML. The XML definition provides a level of abstraction above making calls to the Publishing API. Even so, the XML definition typically names an EJB method to be invoked when the program activity fires, and that method is written with calls to the Publishing API. More information about this level of customization is available in the Open Text Web Experience Management Extensibility SDK Development Guide Using the Publishing API The Publishing API can be used to perform the following custom publishing/ unpublishing operations: Develop a custom publishing policy that meets your organization's specific needs Programmatically perform manual publishing and unpublishing Customize the reporting and notifications behavior For discussion of the Publishing API, see the Open Text Web Experience Management SDK Development Guide as well as the Open Text Web Experience Management API Reference (Javadoc). 352 OpenText Web Experience Management Administration Guide

353 16.2. Publishing Assets 16.2 Publishing Assets WEM provides the following ways to publish or unpublish assets: Manual Automatic Scheduled The following paragraphs briefly describe the end-to-end steps involved in each way you publish or unpublish assets. You perform the initial set of steps for each publishing method, and the system completes the publishing process. Note: You need to create the appropriate sites and channels, and associate the content to be published with those channels. For more information, see the OpenText Web Experience Management - Management Console Online Help (WCMGT-H-ACM) or OpenText Web Experience Management - Content Workspaces Help (WCMGT-H-UGD) Manual Publishing and Unpublishing There are two ways to publish or unpublish assets manually. You can explicitly select assets from Content Workspaces and click Publish (or Unpublish), or you can write an application that makes calls from the Publishing API to publish or unpublish assets. To manual publishing items: 1. Approve the asset(s) to be published, as well as their containers (channels and site). You should approve them before attempting to publish the asset(s). Note: If you fail to approve assets, a Publishing Assistant appears, listing the unapproved assets. You can then approve the assets from there. However, it is a best practice to approve all assets before publishing them. 2. Select the assets to be published. 3. Click Publish. To manual unpublishing items: 1. Select the assets to be unpublished. 2. Click Unpublish. Manual publishing is available to all sites. Even if you designate a site as an automatic or schedule publishing site, you can still publish the site or any of its assets manually. In a site configured for scheduled Publishing, you can even designate whether manual publishing should honor or ignore publish and/or unpublish dates for assets in that site. OpenText Web Experience Management Administration Guide 353

354 Chapter 16 Publishing and Deployment Manual publishing is the only preconfigured publishing method that can be used with sites that have multiple stages What Happens in Manual Publishing and Unpublishing Manual publishing (and unpublishing) happens in the following sequence: 1. For publishing: you approve the asset to be published, as well as that asset's containers; that is, the asset's parent channel, the parent channel's parent channel, and so on, up to and including the site. 2. In Content Workspaces, select one or more assets, and then click Publish or Unpublish. Note: The WEM software creates a list of the content to be published or unpublished, based on how assets are collected for manual publishing, and attempts to create a job containing that list. For information about asset collection, see How Assets are Collected for a Publish Job on page 359. If you select assets to be published from within the Folders workspace, a list of containers (channels) to which the asset is associated appears and you would need to select the required channel or site. 3. Optional If you want to specify any additional information about the job (a description of the job, the type of validation, ignore publish or unpublish dates, and so on), use theadvance Publishing option from the More menu. 4. For publish jobs, if WEM encounters problems when creating a job for assets that you have manually selected for publishing, the Publishing Assistant appears. a. You must correct any failures shown in the Publishing Assistant, either click View Details to correct the issue, or Cancel, if you do not want to publish the job. b. The WEM software hands the publish job's ID to an instance of the site's deployment workflow (such as the default deployment workflow), and starts that workflow. For unpublish jobs, the WEM software builds the job and hands the job's ID directly to an instance of the site's deployment workflow, and starts the workflow. 5. The site's default workflow looks up the list of stage(s) associated with that site, and for each one, submits the job ID and the stage's name to the job engine. Note: If you have a custom deployment workflow, it may perform additional steps before handing the job to the job engine (or after doing so, or even between stages). What happens next is the same for all the publishing methods. See Processing the Job: the Job Engine on page OpenText Web Experience Management Administration Guide

355 16.2. Publishing Assets Automatic Publishing Automatic publishing is an automated process triggered when you approve an asset. In other words, when you approve an asset associated with a site that uses the Automatic publishing policy, that asset is automatically published. For automatic publishing to work: You must designate the site as an automatic publishing site, which you do by setting the publishing policy to Automatic in the Site editor in Content Workspaces. You must approve the container hierarchy (parent site and channels) for any content instances or static files you want to have published automatically. The following restrictions apply to automatic publishing: Sites cannot be published automatically. Approving a site does not cause it to be published. Channels can be published automatically, with certain caveats. By default, the job created for the channel will use the lenient validation policy for its dependents (see Lenient Policy on page 363). The lenient policy can result in incomplete publishing of the channel. You can view the publishing issues report if you click View Publishing Failures in the Publishing menu in the Sites drawer in Content Workspaces. The View Publishing Failures report helps you see publishing issues with one or more of dependences. For example, there you may find that although the channel was published successfully, one or more of its dependents were not re-published because the most recent versions are not eligible. For more information, see Eligibility on page 361. However, the channel was published anyway, because an older version of the dependents had been published already, based on the older (stale) versions. Assets cannot be unpublished automatically. Automatic publishing is only available for sites having a single delivery stage What Happens in Automatic Publishing Automatic publishing of an asset involves the following sequence of steps assuming that the asset's site has had its publishing policy set to Automatic publishing, and that the asset's site and parental channels have been approved: 1. You approve an asset. 2. If you approve a content instance or static file, the WEM software adds the asset's ID to an enlistment table. If you approve a channel, the WEM software adds the channel's ID to the enlistment table. The ID's for the channel's subchannels, content instances and static files are then added to the job by the normal job asset collection process. OpenText Web Experience Management Administration Guide 355

356 Chapter 16 Publishing and Deployment 3. The autopublisher runs at intervals, and: Collects whatever IDs are in the enlistment table. Creates a job. Stores the collected IDs in that job. When large amounts of content are being published automatically (either because channels are being published or because many assets have been approved in a short period of time), the autopublisher controls the amount of publishing work it initiates, limiting the size of each job, and creating as many jobs as required to publish all the assets in the enlistment table. This action may create some latency between the time approved content is committed and the time it actually arrives at a delivery stage. Regardless, no further action is required from you to get the asset published. For more information, see Enlistment-Based Jobs on page The autopublisher hands the job's ID and the name of the associated stage to the job engine. See Processing the Job: the Job Engine on page 358. Note: There is no way to unpublish content automatically. You must manually unpublish any asset that you want unpublished. What happens next is the same for all the publishing methods. See Processing the Job: the Job Engine on page Scheduled Publishing and Unpublishing With scheduled publishing, publishing and unpublishing are automated processes that are driven by publish dates and unpublish dates. For scheduled publishing to work, you must perform the following steps in Content Workspaces: 1. Designate the site as a scheduled publishing site, which you do by setting the publishing policy to Scheduled in the Site editor. This is a one time requirement; once you set the site's publishing policy, you need not set it again. 2. Approve the assets to be published. 3. Set the Publish date and time on the properties page for an asset. For scheduled unpublishing to work, you must set the Unpublish date and time on the properties page of each content instance or static file. You can use scheduled publishing to publish channels (with the same caveats as for automatic publishing), content instances, and/or static files. You cannot use scheduled publishing to publish or unpublish a site. Nor can you use it to unpublish a channel. These assets must be unpublished manually. Scheduled publishing and unpublishing is only available for sites having a single delivery stage. 356 OpenText Web Experience Management Administration Guide

357 16.2. Publishing Assets What Happens in Scheduled Publishing and Unpublishing Scheduled publishing of an asset involves the following sequence of steps assuming that the asset site has had its publishing policy set to Scheduled publishing, and that the asset site and parental channels have been approved. 1. You set or change the asset publish and/or unpublish date, in Content Workspaces, or from a program using the Publishing API. 2. The WEM software enlists the asset. 3. When the publish and/or unpublish date arrives, the autopublisher builds two jobs: A publish job for all enlisted objects whose publish date is now or in the past. An unpublish job for all enlisted objects whose unpublish date is now or in the past. 4. The autopublisher hands the job IDs and the name of the associated stage to the job engine. What happens next is the same for all the publishing methods. See Processing the Job: the Job Engine on page 358. If you are changing from manual publishing to scheduled publishing, previouslyexisting content and channel associations are not considered for scheduled publishing. This is true, even if the previously-existing content/associations contain scheduled dates. In order to have previously-existing content/associations considered for scheduled publishing, you must select the Enlist existing content for scheduled publishing check box. Doing so (and then clicking OK or Apply) causes the WEM publishing software to enlist all the assets that would have been enlisted either from the time the site was first created, or from when content was first added to the site. Note: After the WEM publishing software enlists the content and associations, it removes the check from the Enlist existing content... check box. OpenText Web Experience Management Administration Guide 357

358 Chapter 16 Publishing and Deployment 16.3 Processing the Job: the Job Engine Once a job has been successfully created, the deployment workflow (manual publishing) or the autopublisher (automatic and scheduled publishing) hands the job's ID and the name of the stage to which the job should be deployed. At this point, the job contains a list of all the eligible assets to be published on its associated site. This list is called the site roster. The job engine then performs the following sequence of transactional steps: 1. Queues a subjob for each endpoint (Endpoint Proxy/Deployment Agent pair) of the target stage. A subjob is a logical pairing of the job and an endpoint that allows the job engine to track the progress of the job at that endpoint. At this point, the subjobs are planned and ready for deployment, awaiting their turn to be processed. 2. The job engine selects the next group of subjobs from the queue for processing, and computes a stage roster from the site roster. A stage roster is computed one time for all subjobs. It contains the eligible assets to be published to that stage, less the assets that are still current on the stage. In other words, the stage roster lists all eligible, stale assets for a stage. At this point, the job engine transitions each subjob's endpoint from Ready phase to the P1 phase, and begins phased deployment (P1 through P3). For information about phased deployment, see Endpoint Proxies, Endpoints, and Deployment on page 367). 3. The job engine computes an endpoint roster from the stage roster for each subjob based on the endpoint's (or rather its Deployment Agent's) subscriptions. The endpoint roster includes only those assets from the stage roster in which endpoint is interested. The job engine then iterates over the endpoint roster, packaging assets and transmitting the packaged assets via HTTP to the Deployment Agent. The number of assets transmitted in a single package is limited to prevent overloading. Therefore, multiple packages of assets may be transmitted, until all assets have been sent to the Deployment Agent. 4. The job engine iterates until all of the job's contents have been sent to Deployment Agents. As assets arrive at a Deployment Agent, that agent's handlers process the assets according to content type. Usually, this entails sending the assets to a target web server, application server, or database. 358 OpenText Web Experience Management Administration Guide

359 16.3. Processing the Job: the Job Engine How Assets are Collected for a Publish Job Assets are collected in the following manner. First, you specify a set of assets to be published. You can do this manually by selecting the assets in Content Workspaces, or programmatically through calls from the Publishing API. Each of the specified assets is called a seed. At this point, the WEM software performs the following steps: 1. Lists the seeds in the job. As it lists each seed, it checks the eligibility of that seed, marking it eligible or ineligible as the case may be. 2. Finds the ancestors for the eligible seeds and lists them in the job. Ancestors are the parents of a seed. Ancestors are the assets on which seeds depend. For example, if the seed is a content item, then the channels and site that contain it are its ancestors. As it lists each ancestor, the WEM software checks the eligibility of the ancestor, marking it eligible or ineligible, as the case may be. While an ancestor is listed in a job, that ancestor's descendants are not. For example, say that the seed is a content item. The content item's parent channel is listed in the job. The channel is an ancestor of the content item because the content item depends on the channel. However, none of the other content items contained in the parent channel are listed, because the original content item (being the seed) does not depend on them. 3. Checks each ineligible seed and ancestor and determines if they invalidate the job, based on the job's validation policy. The first ineligible asset that violates the validation policy's publish requirement causes the job to be invalidated, and asset collection to stop immediately. 4. If no ineligible seed or ancestor causes the job to be invalidated, the WEM software finds the descendants for the eligible seeds and lists them in the job. For example, if the seed is a channel, then its subchannels, content items, and static files are its descendants. As it lists each descendant, the WEM checks the eligibility of the descendant, marking it eligible or ineligible, as the case may be. 5. Finds the assets referenced by the assets collected so far, and lists them in the job. For example, assume that the asset is an article (a content instance) that refers to an image (a static file). The article is the primary asset and has already been added to the job. The image to which the article refers is called a secondary asset and is automatically added to the job. 6. As it lists each referenced asset, the WEM software checks the eligibility of the asset, marking it eligible or ineligible, as the case may be. 7. Checks each ineligible descendant and referenced asset and determines if they invalidate the job, based on the job's validation policy. The first ineligible asset OpenText Web Experience Management Administration Guide 359

360 Chapter 16 Publishing and Deployment that violates the validation policy's publish requirement causes the job to be invalidated. With one exception, this sequence is the same for all publish jobs, regardless of a site's publishing policy; that exception being if the site uses the Scheduled publishing policy. In that case, the eligibility test also checks the publish/unpublish dates of the collected assets before listing them in the job. During manual publishing, all of the assets above are added to the job even if they are currently published. The currently published assets in a job are not republished (unless they are stale). However, you can force the WEM software to republish them on the Advanced Job Settings window. During a scheduled publishing job, assets that are currently published are not added to the job. Together, the seeds, ancestors, and descendants are called the primary assets of the job How Assets are Collected for an Unpublish Job Assets for unpublishing are collected in the following manner. First, you specify a set of assets to be unpublished (either manually by selecting the assets in the Management Console or Content Workspaces, or programmatically through calls from the Publishing API). These assets are the seeds for the unpublish job. At this point, the WEM software performs the following steps: 1. Lists the seeds in the job. 2. Finds the descendants for the seeds and lists them in the job. Notes No eligibility checks are made for unpublish jobs, nor are any validation checks run. Unlike with publish jobs, when the WEM software collects assets for an unpublished job, referenced assets will not be included. Only assets which are seeds and their descendants will be included in the job to be unpublished. 360 OpenText Web Experience Management Administration Guide

361 16.3. Processing the Job: the Job Engine Eligibility The primary rule of eligibility is that the WEM software never deploys an ineligible asset. This paragraph describes what makes an asset ineligible. Any time an asset in not approved, it is ineligible. This restriction holds true for any site, no matter what that site's publishing policy is. For example, say you have a site that has the automatic publishing policy set, and you try to publish an asset manually. As long as the asset is not approved, it is ineligible. However, for scheduled publishing sites, even if an asset is approved, it still may not be eligible. This is the case when the asset has a non-blank publish date that is in the future. Eligibility is not considered for unpublishing an asset. If the asset is added to the job, it will be unpublished. If the site has either the manual publishing policy or the automatic publishing policy set, the WEM software ignores an asset's publish and unpublish dates. To be eligible to be published on a scheduled publishing site, an object must be both approved and time-eligible. To be eligible to be published on a non-scheduled publishing site, an object must merely be approved; even if the object has non-blank publish or unpublish dates associated with it, those dates will be ignored. If the site's publishing policy is set to scheduled publishing, the WEM software tests the asset for publish and unpublish dates/times before including that asset in the list for the job it creates. If you attempt to manually publish a site or channel with assets that are not yet eligible for publish, you will get a Time-ineligible asset warning. You can override the publish and unpublish dates for all the assets in the channel when you publish the containing site or channel. To do so from the Job Creation window, click Advanced, then select the checkbox labelled Ignore publish and unpublish dates for content Validation Note: Eligibility does not affect unpublishing jobs. Whether the asset is a seed or one found by the WEM software's content pattern search, it is unpublished without regard to its eligibility. If an asset is ineligible, the validation policy determines whether the exclusion of the asset is fatal; that is, whether the job is incapable of being published without the asset. In the case of a fatal exclusion, the job is marked as unpublishable. The job still exists so that you can see which objects are ineligible. WEM offers three different validation policies: Strict Moderate OpenText Web Experience Management Administration Guide 361

362 Chapter 16 Publishing and Deployment Lenient By default, the moderate policy is in effect globally for your entire configuration. However, you can change the global setting. See Configuring the Global Validation Policy on page 372. You can also override the policy on a per-job basis. In any workspace, except Tasks, navigate the three until the item that you want to modify appears in the List view. Right-click the item, and then click Advanced Publish. In the Advanced Publishing editor, scroll down to the Override Validation Policy list and select the validation policy you want to be in effect for this job, and then click Publish Strict Policy The strict validation policy renders a job invalid if any ineligible assets are discovered while building the job. This policy is used less frequently because it is so restrictive. However, it is required in a situation where you must ensure that everything specified by a content pattern is definitely included in a job Moderate Policy The moderate validation policy allows a job to be valid even if the content pattern search finds ineligible descendant assets. Even though the ineligible descendant asset is excluded from the job, the job itself is not invalidated, and the content pattern search continues. However, if the content pattern search finds that a primary asset refers to an ineligible secondary asset, not only is the secondary asset excluded, the job also is invalidated. The main benefit of this policy is that it allows publishing a site or a channel without requiring that everything associated with the site or channel be approved or timeeligible, as the case may be. For example, if you publish a channel, any ineligible assets associated with the channel are excluded from the job. However, the job remains valid, and asset collection continues. Ineligible assets are excluded without examining the assets they reference. For example, an ineligible subchannel is excluded without examining any of the assets associated with that subchannel (regardless of whether those assets are eligible). 362 OpenText Web Experience Management Administration Guide

363 16.4. The Deployment System: How Content Is Deployed Lenient Policy The lenient validation policy provides a relatively-easy way to build valid jobs. The main use for this policy is with environments that contain highly-interconnected content items. For example, consider an e-publishing site in which every article includes links to related articles, and you have implemented the articles as content items that refer to one another. In such an implementation, it is possible for an object to indirectly reference many other objects (article A refers to articles B and C, which in turn refer to articles D, E, F, and G, and so on). In such a highly interconnected environment, having either the strict or moderate validation policy in effect would be almost guaranteed to prevent any job from being valid, since a job cannot be valid unless all of the directly and indirectly referenced objects are eligible. This is especially true where that set of objects is large, making it impractical (or even impossible) to ensure that all objects are eligible at the same time. The lenient validation policy addresses this situation by allowing references to ineligible secondary assets as long as those secondary assets are already published relative to the job's site. Otherwise, the job is marked invalid. For example, if article A refers to article B, both A and B must be eligible the first time A is published. However, as long as B remains published, it is possible to publish A even if B is ineligible. The resultant job would contain the new version of A, but it would not contain any version of B. When the new version of A is deployed to a delivery stage(s), its reference to B will resolve to whatever version of B happens to be deployed on that stage. Note: The WEM software does not check which version of B is on the delivery stage. As long as some version of B is available, the reference is honored The Deployment System: How Content Is Deployed The following paragraphs discuss the WEM components that handle assets once the job engine finishes building a job. This half of the WEM publishing implementation deals with deployment. Deployment is the delivery of content from the job engine to web servers, application servers, and/or databases for access by your customers via a Content Delivery Application. OpenText Web Experience Management Administration Guide 363

364 Chapter 16 Publishing and Deployment Stages Stages are logical containers by which you test and deliver the sites, channels, and content items that you have created. The WEM software has two kinds of stages: Management stage A single stage that manages user-created content. It is created automatically when you install and configure the WEM software, and appears in the Configuration Console. The Management stage cannot be deleted. Delivery stage You can create any number of delivery stages, which are then used for the deployment process. By default, the first delivery stage created in the Configuration Console will be named Production unless you specify another name. Each delivery stage can have multiple Deployment Agents for deploying content to multiple places. On the Management stage, you create and manage sites and their assets. You then create one or more delivery stages for further testing and for production (presentation to customers). Note: When you associate stages with a site, you establish the order in which assets move from stage to stage. A site's stages are logically ordered. The logical last stage is usually called the production (or live) stage, and is where your customers will access content. For detailed information about stages, see the OpenText Web Experience Management - Planning and Installation Guide (WCMGT-IGD). For procedures to create stages, CDS's, and Deployment Agents, see the OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) Content Delivery Services (CDS's) At least one instance of Content Delivery Services is associated with each stage. Each instance (called a CDS) is responsible for content delivery on the stage. When you create a delivery stage, a CDS is created for you. You can create additional CDS's in an existing delivery stage. A CDS is a logical container for one or more Deployment Agents. A CDS may contain multiple Deployment Agents. Those Deployment Agents could potentially reside on different hosts, therefore a CDS might span multiple hosts. The CDS synchronizes its various Deployment Agents' Endpoint Proxies. For detailed information about CDS's, see the OpenText Web Experience Management - Planning and Installation Guide (WCMGT-IGD). For procedures to create CDS's, and Deployment Agents, see the OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC). 364 OpenText Web Experience Management Administration Guide

365 16.4. The Deployment System: How Content Is Deployed Deployment Agents Each stage has one or more Deployment Agents that actually deploy content. Each Deployment Agent subscribes to any or all of three types of content: Static files Database records Taxonomies Note: When you create a delivery stage, a Deployment Agent is automatically created for that stage, and is automatically subscribed to static files, database records, and taxonomies. If you configure an additional Deployment Agent for an existing stage, you must explicitly subscribe that agent to files, records, taxonomy, or all of them. Within each of its content subscriptions, a Deployment Agent receives content based on deployment type. To limit the kinds of content it deals with, a Deployment Agent only subscribes to specific deployment types. For example, a Deployment Agent that deploys content to an image server might only subscribe to the static file content subscription with a deployment type of Image File. Deployment types allow a Deployment Agent to handle types of content in different ways, all in the same Deployment Agent instance. For example, static files that have different deployment types can be routed to different docroots. Or, static files of a specific deployment type can be configured to be deployed by user-written custom scripts (such as Perl or JScript). For more on custom scripting the deployment of static files, see Customizing Deployment and Publishing on page 407. When the Content Management Server sends a content request (create, modify, or delete) to a Deployment Agent, that agent calls a deployment handler based on its content subscriptions. The handler processes the request, based on the deployment type, and informs the Deployment Agent of the operation result. The Deployment Agent logs the operations. When a Deployment Agent receives a request to place a new file, it needs to know where to place that file and what, if any, special handling requirements are involved. For example, an executable file might need to be registered with an operating system before being placed in a destination directory. There are two types of handlers: Primary Handlers standard handlers that perform the actual physical deployment of content Non-Primary Handlers generally serve to notify other processes of the deployment event, or to record some aspect of the deployment event into a database, and so on. Each content subscription type has an associated standard handler, which is the default way of deploying that content. For example, the standard handler for static OpenText Web Experience Management Administration Guide 365

366 Chapter 16 Publishing and Deployment file simply copies the file to the specified directory, while the standard handler for a record copies content rows to the appropriate tables in the specified database. For each deployment type to which a Deployment Agent subscribes, that agent can be configured to run specific handlers. You can swap out a standard handler with another handler for performing specific tasks. For example, you may want the Deployment Agent to use a custom script file handler on static files rather than the standard file handler. This will allow the user to write scripts in a variety of scripting languages to customize the actual deployment of the file. See Customizing Deployment and Publishing on page 407. Handlers may be chained together, with zero or one primary handler at the head of the chain, and any number of non-primary trailing handlers. All content subscriptions have a default deployment configuration. If no configuration is explicitly specified for a given deployment type, it uses the default deployment configuration to deploy content. For example, assume that you have ten deployment types defined and you create a Deployment Agent that subscribes to all ten. For this agent, you want to use Standard deployment to one destination because no extra configuration is needed. All deployment types just use the handler and resource configured as the default. Now assume you need one of those ten deployment types to use a different handler (a custom script, for example). You cannot change the default handler, because doing so would change the handlers not only for that deployment type, but for the other nine as well. Instead, you configure that one deployment type to use a different handler than the default. You can configure different handlers to handle content defined with different deployment types. Most handlers need to be configured with resource objects that provide the handler with information specific to the Deployment Agent, Content Delivery Service instance, or stage in which the handler will run. For example, standard file handlers associate deployment types with directory resources; that way they can place files of one deployment type in one directory and files of another deployment type in another directory. Other handlers might use other resources, such as a database resource. Be aware that when you specify a handler or destination resource, this could be the same as what is configured as the default. The distinction is that when you modify the default, any deployment types using specific handlers or destination resources will not pick up that change they will continue to use the handler, resource, or both specifically configured for them. 366 OpenText Web Experience Management Administration Guide

367 16.4. The Deployment System: How Content Is Deployed Endpoint Proxies, Endpoints, and Deployment Each Deployment Agent has an associated Endpoint Proxy that runs in the Content Management Server. An Endpoint Proxy: Acts as the interface between its associated Deployment Agent and the Content Management Server Maintains information about deployment phases Coordinates with other Endpoint Proxies Together, an Endpoint Proxy and its associated Deployment Agent are called an endpoint. The Endpoint Proxy runs as a process in the Content Management Server, and the Deployment Agent runs on the delivery stage host. If either the Endpoint Proxy or the Deployment Agent is not functioning properly, publishing will be adversely affected. The following paragraphs describe publishing Endpoint Proxy modes and their deployment phases, and the deployment states that result from those modes and phases. Refer to Figure 16-1 while reading the paragraphs in this section: Figure 16-1: Online Deployment Phases and States Endpoint Proxy Modes As defined earlier, an Endpoint is made up of an Endpoint Proxy and a Deployment Agent. At any time, an Endpoint Proxy (and, by extension, the Deployment Agent associated with it) is in one of the following major modes: Online mode Online mode is the normal mode for an Endpoint Proxy. All online Endpoint Proxies in a Content Delivery Services (CDS) instance participate in the coordinated deployment of content when a job is published to that CDS. Offline mode When an Endpoint Proxy is in the Offline mode, publishing to that Endpoint Proxy is not attempted. Instead, any job destined for that endpoint is put in a queue of pending jobs to be picked up when the Endpoint Proxy is restarted. The fact that an Endpoint Proxy is offline does not prevent the other Endpoint Proxies in the CDS from proceeding with their work; all online OpenText Web Experience Management Administration Guide 367

368 Chapter 16 Publishing and Deployment Endpoint Proxies will continue to handle published jobs without waiting for the offline Endpoint Proxy(s). Cmd mode An Endpoint Proxy enters the Cmd mode when an external agent (such as the selection of an option in the Endpoint Info - Appsvcs window) starts a processor to run a series of endpoint commands. For this to happen, the Endpoint Proxy must already be in Offline mode. Therefore, you can think of Cmd mode as a submode of the Offline mode. Restart mode An Endpoint Proxy is in the Restart mode while it transitions from the Offline mode to the Online mode. While in this mode it acts on the jobs that accumulated while it was in Offline mode (or Resync mode). It stays in this mode until it catches up with all the Online Endpoint Proxies in its CDS. Resync mode An Endpoint Proxy enters the Resync mode when an external agent explicitly requests that the endpoint be resynchronized. In effect, resynchronization is treated as a single large job containing all of the assets to be (re-)deployed to the endpoint. After the resynchronization job completes, the Endpoint Proxy transitions to Offline mode. From there, you must restart it, When it reaches Online mode again, it catches up on jobs that may have been published in the interim. The Endpoint Proxy must be in Offline mode before you can resynchronize Deployment Phases The Online, Restart, and Resync modes operate in the following deployment phases: Ready phase This is the idle phase for Endpoint Proxies. An Endpoint Proxy moves from this phase to the P1 phase as part of a coordinated group transition. For example, an Endpoint Proxy in the OnlineReady state moves to the OnlineP1 state to start work on a new job. In this example, an imbedded component known as the Job Planner coordinates this group transition. Note: If a CDS has multiple Endpoint Proxies, the mode of those proxies affects how they transition between phases. If the proxies are in Online mode, they will transition between phases in a coordinated fashion. Specifically, in Online mode, even though they move from the Online/ Ready state to the Online/P1 state at different times, none of them will commence the P1 phase until all of them are in the P1 phase. Each time a phase transition occurs, no proxy in the Online mode will begin that new phase until its sibling proxies have arrived at the same phase. This phase transition restriction applies only to the Online mode. It does not apply to the Restart or Resync modes. P1 (transfer) phase The first phase that an Endpoint Proxy enters from the Ready phase. During the P1 phase, each Endpoint Proxy receives the subset of job content for which it is responsible. The Endpoint Proxies run independently during this phase, each sequentially sending its content items to its associated Deployment Agent. 368 OpenText Web Experience Management Administration Guide

369 16.4. The Deployment System: How Content Is Deployed Once the P1 phase has commenced, there is no further attempt to coordinate the activities of multiple proxies until the phase finishes. As each Endpoint Proxy finishes its P1 phase activity, it moves to the next phase (P2). P2 (Synchronization) phase When an Endpoint Proxy arrives at the P2 state, it starts the second phase of deployment: the synchronization phase. Note: With multiple Endpoint Proxies in a CDS, if the proxy mode is Online, no proxy commences the P2 phase until all are in P2 phase. In P2, each Endpoint Proxy sends a synchronization message to its Deployment Agent and awaits the response. A success reply causes the Endpoint Proxy to move to the P3 phase. A failure reply from, or a communication failure with the Deployment Agent causes the Endpoint Proxy to move to the X2 phase. P3 (Commit/Abort) phase When an Endpoint Proxy arrives at the P3 phase, it starts the third and final phase: the commit/abort phase, during which it sends a commit or abort message to its Deployment Agent. Note: With multiple Endpoint Proxies in a CDS, if the proxy mode is Online, no proxy commences the P3 phase until all are in P3 phase. After successfully sending its message to its Deployment Agent, an Endpoint Proxy in the P3 phase moves back to the Ready phase to await a new job, or to the Offline mode (if it has been targeted for shutdown). X1, X2, and X3 are the error phases for their P1, P2, and P3 counterparts. For example, an Endpoint Proxy in P1 phase will move to X1 phase if its Deployment Agent encounters a failure when responding to a request to deploy a particular content item, or if the Endpoint Proxy cannot communicate with the Deployment Agent for some reason. Once an Endpoint Proxy is in an error phase, you must manually intervene and determine an appropriate response to the problem. Perhaps the Deployment Agent encountered some temporary problem (for example, running out of disk space) that can be resolved, and simply resuming is the appropriate course of action. Or perhaps there is some more fundamental problem with the job, and a CDS-wide abort is called for Endpoint Command Phases The Cmd mode operates in the following phases: P1 (Proxy Execution) phase Takes care of actions to be performed on the Endpoint Proxy. P2 (Agent Execution) phase Takes care of actions to be performed on the Deployment Agent. Assuming that you have already placed affected endpoints in Standby mode, when you select certain options from the Endpoint Info - Appsvcs window (for example, Get Orphaned Object Report or Remove Orphaned Objects), the Job Console creates OpenText Web Experience Management Administration Guide 369

370 Chapter 16 Publishing and Deployment a processor for the option. The processor then moves the endpoint(s) through the P1 and P2 phases. This phased progression resembles how the job engine handles jobs, in that the work load is spread over multiple transactions where each phase is controlled by a JMS message. However, the state machine used for endpoint command execution much simpler than that a job's state machine: Offline > CmdP1 > CmdP2 > Offline The Endpoint Proxy can produce input that gets persisted at the end of CmdP1 and passed to the associated Deployment Agent in CmdP2. Using continuep1 and continuep2 respectively, both CmdP1 and CmdP2 can be repeated (each in a separate transaction) until their work is completed. When a command completes, whether it fails or succeeds, the Endpoint Proxy is returned to Offline so that the endpoint returns to Standby. At that point, the endpoint is ready for a subsequent command, or to be stopped or started. Note: An endpoint in a CmdP* state never suspends. If an endpoint command fails, it must be either repeated or forgotten. An endpoint command cannot be resumed Endpoint Proxy States for Deployment Each Endpoint Proxy has a Proxy State, which is viewed from the Job Console's Endpoint Diagnostics window. That state represents the combination of the proxy's mode (Online, Restart, Resync) and its phase (P1, P2, P3, X1, X2, X3); for example, OnlineP2. Comparison of States for Deployment on page 370 shows how the Job Console arrives at the value it displays for an endpoint's State: Table 16-3: Comparison of States for Deployment State of the Endpoint (as reported in the Job Console) State of the Endpoint Proxy State of the Deployme nt Agent Is there a Heartbeat? Is a Subjob Pending? Undefined Undefined do not care do not care do not care Stopped Offline Stopped do not care do not care Standby Offline Not stopped do not care do not care Disconnected Not offline Stopped do not care do not care Suspended Any suspended proxy state: OnlineX(1, 2, or 3) RestartX(1, 2, or 3) do not care do not care do not care Running do not care do not care Yes do not care 370 OpenText Web Experience Management Administration Guide

371 16.4. The Deployment System: How Content Is Deployed State of the Endpoint (as reported in the Job Console) State of the Endpoint Proxy State of the Deployme nt Agent Is there a Heartbeat? Is a Subjob Pending? Not responding Running Not responding Any running proxy state: OnlineP(1, 2, or 3) RestartP(1, 2, or 3) Any idle proxy state: OnlineReady RestartReady Any idle proxy state: OnlineReady RestartReady do not care No do not care do not care No No do not care No Yes Waiting Waiting on a sibling proxy (a proxy for another endpoint in the same CDS). If a job is coordinated across endpoints in a CDS, both proxies rendezvous at P1, P2, and P3 before continuing. When one proxy reaches P2 and is waiting for its sibling to finish P1, the combined state is marked as Waiting. do not care No Yes The value of the endpoint state (shown in the leftmost column) is determined from the first matching set of values in the succeeding columns in the row. For example, say that the columns in a particular row have the following values: Endpoint Proxy OnlineX1 Deployment Agent Not stopped Heartbeat Yes Subjob Yes This combination indicates that the endpoint is Suspended. Even though one of the possible sets of values for Running could match, the values for Suspended are the first set to match; therefore, the endpoint state is Suspended. The heartbeat is an internal mechanism for the WEM software to know if the endpoint proxy is responsive within a certain period of time. OpenText Web Experience Management Administration Guide 371

372 Chapter 16 Publishing and Deployment 16.5 Customizing and Tuning Publishing The following paragraph tell how to customize parts of the publishing process Configuring the Global Validation Policy When jobs are first created, they are assigned whichever validation policy is specified as the global validation policy. You can change the policy for the job after the initial assignment, if so desired. However, you can also change the global validation policy that gets assigned by default for each new job. To do so, you must change the value of the DEPLOYMENT_UNAPPROVED_CONTENT_POLICY configuration variable, which is located at: WEM Configuration Console Content Management Services Management Console Publishing DEPLOYMENT_UNAPPROVED_CONTENT_POLICY appears in the right-hand pane. Acceptable values are: STRICT Specifies that the strict policy is in effect. MODERATE Specifies that the moderate policy is in effect. This is the default policy for a new installation. LENIENT Specifies that the lenient policy is in effect. Note: These values must be specified using all uppercase characters. For information about how to change the value of a configuration variable, see Changing and Testing Configuration Variables on page Changing the Validation Property for a Single Job You can also override the validation policy on a per-job basis. In any workspace, except Tasks, navigate the tree until the item that you want to modify appears in the List view. Right-click the item, and then click Advanced Publish. In the Advanced Publishing editor, scroll down to the Override Validation Policy list and select the validation policy you want to be in effect for this job, and then click Publish. Similarly, from the API, you can override the global validation property by using the ApprovalPolicy.setUnapprovedDescendentAction method. For more information, see the Open Text Web Experience Management API Reference (Javadoc). 372 OpenText Web Experience Management Administration Guide

373 16.5. Customizing and Tuning Publishing Changing the Snapshot Overwrite Policy By default, the WEM publishing software allows older snapshots to overwrite newer snapshots. For example, say that you have a number of publishing jobs pending, and that content item A appears in more than one of those jobs. it is possible that those jobs each have a different snapshot version of content item A. In such a case, there's no way to guarantee which job will complete first. Therefore, a newer snapshot of content A could be deployed before an older snapshot of the object, meaning that when the older snapshot is deployed, it would overwrite the newer version. You can override the overwrite behavior in one of two ways: Change the value of the DEPLOYMENT_ALLOW_OVERWRITES configuration variable to false. Overwrite behavior is established on a per-job basis, therefore, you would need to change the variable before publishing if you change your mind about which behavior to use. Override the behavior via the WEM Publishing API when actually building a job. The override would apply only for the job being created. If not specified within the job being created, the behavior would default to that specified in the DEPLOYMENT_ALLOW_OVERWRITES configuration variable. The DEPLOYMENT_ALLOW_OVERWRITES configuration variable resides at the following location in the Configuration Console: Configuration Console Content Management Services Management Console Publishing For information about changing the values of configuration variables, see Changing and Testing Configuration Variables on page 179. Following is a partial example of how to set the overwrite behavior for a job using the Publishing API: DeploymentJobDefinition jobdef = new DeploymentJobDefinition... ("some name", JobType.PUBLISH); jobdef.setparameter (JobParamConst.PARAM_NAME_ALLOW_OVERWRITES, JobParamConst.PARAM_VALUE_DISALLOW_OVERWRITES); The example would prevent this job from overwriting newer snapshots. You can also specify PARAM_VALUE_ALLOW_OVERWRITES (instead of PARAM_VALUE_DISALLOW_OVERWRITES to allow the job to overwrite newer snapshots: DeploymentJobDefinition jobdef = new DeploymentJobDefinition OpenText Web Experience Management Administration Guide 373

374 Chapter 16 Publishing and Deployment... ("some name", JobType.PUBLISH); jobdef.setparameter (JobParamConst.PARAM_NAME_ALLOW_OVERWRITES, JobParamConst.PARAM_VALUE_ALLOW_OVERWRITES); You would use this API override if you prefer to have the value of the DEPLOYMENT_ALLOW_OVERWRITES configuration variable set to false by default. For more information, see the Open Text Web Experience Management API Reference (Javadoc) Configuring Autoprune You can have the WEM software automatically remove completed jobs by enabling the Autoprune feature. Doing so ensures that metadata for successfully completed jobs is not retained in your system. Note: If you need to keep jobs around for troubleshooting purposes, you should disable the Autoprune feature. Jobs that complete unsuccessfully will not be autopruned, even if autoprune is turned on. To enable the Autoprune feature: 1. Open the Configuration Console. See Using the Configuration Console on page 174 and the OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) for details on using the Configuration Console. 2. Navigate to the following location in the console: Content -> Management Services -> Management Console -> Publishing 3. Click DEPLOYMENT_AUTOPRUNE in the right-hand pane. 4. Set the configuration value to true (the default is false). Click Save. 5. Right-click the Content node. 6. Select Manage Configuration Changes >Commit Changes. 7. Restart the Content Management Server. See Managing Servers on page 31 for details on restarting the Content Management Server. 374 OpenText Web Experience Management Administration Guide

375 16.5. Customizing and Tuning Publishing Increasing Java Memory for Deployment Agents If a stage suspends with Java out of memory errors, you may need to increase the amount of Java memory available for use by the stage's Deployment Agent(s). To increase Java memory settings for a Deployment Agent: 1. Open the Configuration Console. See Using the Configuration Console on page 174 and the OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC) for details on using the Configuration Console. 2. Navigate to the following location in the console: Configuration Console Content Delivery Service Content Delivery Stage - <stagename> Content Delivery Services - <stagename> Deployment Agents Deployment Agent - <daname> Deployment Agent Configuration Managed Process 3. Click BINARY_ARGS in the right-hand pane. 4. Copy the value from the Run Value: field into a text editor, and make your changes to the -Xms and -Xmx parameters. 5. Copy the new value from the text editor and paste it into the Config Value: field of the BINARY_ARGS Properties dialog box. 6. Click Save. 7. Push or commit the change to the configuration as discussed in the OpenText Web Experience Management Configuration Console - Administration Online Help (WCMGT-H-ACC). 8. Follow the prompts on your screen to restart the affected components. For more information, see Changing and Testing Configuration Variables on page 179. OpenText Web Experience Management Administration Guide 375

376

377 Chapter 17 Troubleshooting Publish Problems This topic describes ways to troubleshoot publishing problems Introduction Although somewhat simplistic, it helps to think of the publishing process as being divided between job creation and deployment, especially when troubleshooting a publishing problem. Job creation must complete successfully before deployment begins; therefore, you should troubleshoot job creation first. If the job has been created successfully, then troubleshoot the deployment steps for your published job Troubleshooting Job Creation Job creation happens differently for each way assets are published (manually, automatically, or by scheduling) Troubleshooting Job Creation for Manual Publishing If the WEM software encounters problems when creating a job for assets that you have manually published, it opens the Publishing Assistant that contains one or more warnings and/or failures, similar to Figure 17-1: Figure 17-1: Publishing Assistant for Manually Published Assets At this point, you must correct any failures shown in the Publishing Assistant. You may also want to correct any warnings. However, not all warnings require action OpenText Web Experience Management Administration Guide 377

378 Chapter 17 Troubleshooting Publish Problems from you. For example, say you have a news site with numerous channels and thousands of articles. The articles all reference each other (for example: See related articles. ) It is practically impossible to keep all references between articles in sync. However, that may not be an issue. It may be that you only want to be sure that any unapproved referenced articles in a Publishing Assistant s warning are at least published, so that there is some version of each referenced article even if that version is not up-to-date. To correct a failure or warning, click View Details in the assistant as shown in Figure The details pane appears, describing the problem in more detail and providing ways to correct the problem such as approving an unapproved asset. You can select the asset and perform various actions on it, such as approving it or opening its properties (which might be useful if you want to approve the asset and to schedule it for publishing at a later date or time). After you correct the problem click Publish to try publishing your assets again, or you can continue by correcting other warnings/failures. Note: If the job was created successfully, but you received warnings, you might have the option of letting the WEM software exclude unapproved assets and publish the job without those assets (based on the validation policy currently in effect). You can do this by clicking Omit All. If you are a WEM administrator, and if the job was created successfully, you can go to the Management Console home page, and click the System Health status. From there, you can get a list of what is in the job and what was excluded. See Seeing Job Contents and Exclusions on page 396. Even after you have corrected the initial set of failures and warnings in the Publishing Assistant, you may receive additional failures and/or warnings when you recreate the job. This is because the WEM software presents assets that are most likely to create problems in a successful job creation. If correcting the listed issues with those assets does not allow the job to be created successfully, the next most likely problematic assets are presented in a new Publishing Assistant. When you have corrected all warnings and failures, the Publishing Assistant returns the current status of the issue. Click Publish to send the job to the deployment cycle. At this point, if you are a WEM administrator, you can go to the home page site or channel-list view and see the status of the asset you published in the Properties palette. 378 OpenText Web Experience Management Administration Guide

379 17.2. Troubleshooting Job Creation Troubleshooting Automatic/Scheduled Publishing Job Creation If the WEM software encounters problems when creating a job for assets that you have published automatically or by scheduling, it does not display a report window automatically. However, you can view a similar report window if you click View Publishing Failures in the Publishing menu in the Sites drawer in Content Workspaces. At this point you must correct any errors shown in the Publishing Failures Report. You may also want to correct any warnings. (As discussed in Troubleshooting Job Creation for Manual Publishing on page 377, you may not want to correct all warnings.) To correct a failure or warning, click on its error message (for example, Ineligible in the preceding figure). Another Publishing Failure Report appears, describing the problem in more detail (if possible), and providing ways to correct the problem such as approving an unapproved asset. You can select the asset and perform various actions on it, such as approving it or opening its property sheet. For example, you might want to approve the asset, but also to schedule (or reschedule) it for publishing at a later date and time. If your changes correct the problem, a Publishing Failure Report appears, informing you that there are no further failures or warnings to report, and providing Publish and Cancel buttons that allow you to continue publishing (sending the job to the deployment cycle) or to cancel. If your changes have not corrected all the problems preventing this job from being created, or if assets that have been excluded have versions already published, another Publishing Failure Report appears, providing further chances to correct problems before the job is created or cancelled. Note: If the job was created successfully, but you received warnings, you might have the option of letting the WEM software publish the job without the excluded assets (based on the validation policy currently in effect). If you are a WEM administrator, and if the job was created successfully, you can go to the Management Console home page, and click the Publish indicator. From there, you can get a list of what is in the job and what was excluded. See Seeing Job Contents and Exclusions on page 396. OpenText Web Experience Management Administration Guide 379

380 Chapter 17 Troubleshooting Publish Problems 17.3 Troubleshooting Deployment After a job has been created successfully, it is eventually handed to the job engine for deployment either by a deployment workflow (manual publishing) or the autopublisher (automatic and/or scheduled publishing). If you are a WEM administrator, you can see the Publish indicator in the Diagnostics region, located in the upper left-hand corner of the Management Console home page: If a problem occurs during deployment, the WEM software changes the Publish Indicator. There are three possible states for the publish indicator: Indicates that there are currently no known deployment-related problems that will interfere with the publishing process. Non-critical issues have been detected within the deployment subsystem. An example of this might be an endpoint going offline. This state does not necessarily require action, but you may wish to investigate further, and maybe even monitor its progress. Critical errors have been detected within the deployment subsystem. An example of this might be an endpoint (Endpoint Proxy/Deployment Agent pair) becoming suspended. This state requires remedial action. The Job Console is the main tool for troubleshooting deployment problems. The following steps tell how to start troubleshooting such problems from the Job Console. 1. Go to the Job Console, either by entering its URL (see The Job Console on page 392), or by clicking on the state displayed in the Management Console's Publish Indicator. 2. Look at the Current System Alarms box in the Job Console main page. For example: 380 OpenText Web Experience Management Administration Guide

381 17.3. Troubleshooting Deployment 3. Based on the alarm message shown, try to obtain information about the cause of the failure or warning. Use the job actions in the left pane of the Job Console to isolate the key possibilities Dealing with a Suspended Endpoint Very often, the problem has caused a suspended endpoint (Endpoint Proxy/ Deployment Agent pair), in which case the word Suspended appears in the Alarm Message (as shown in the preceding figure). A suspended endpoint usually indicates that the endpoint's Deployment Agent has encountered an error while processing a content instance or static file. In this situation, the Deployment Agent writes the error into its log file and reports the error back to the Endpoint Proxy in the Content Management Server. The Content Management Server responds by suspending the endpoint, meaning that the Content Management Server stops sending content to the affected endpoint until you fix the problem causing the suspension and resume the endpoint. An endpoint can be suspended for a number of reasons. For example: A database failure occurs. If the database is causing problems, ensure the database is up and running, and that the database resource is using the correct coordinates, user ID, password, and so forth. The target to which the content instance or static file is to be written does not give sufficient permission for writing. The disk is full. If so, provide more disk space. You are resyncing a Deployment Agent, and that Deployment Agent attempts to deploy a web application that has already been deployed. This could indicate that a custom deployment script is not checking to see if a web application has already been deployed in which case you should modify the script accordingly. For example: During a Create operation: If the web application is already deployed, redeploy it instead of simply deploying it. During an Update operation: If the web application does not already exist, deploy it instead of attempting to update it. During a Delete operation: Do not return an error if the web application does not exist. Changes in custom scripts are picked up immediately, so resuming the endpoint from the Endpoint Diagnostics window would try the failed action with your corrected script. You have the following options for dealing with a suspended endpoint: Fix the underlying problem and resume the endpoint. Skip a problematic asset and resume the endpoint. OpenText Web Experience Management Administration Guide 381

382 Chapter 17 Troubleshooting Publish Problems Stop the endpoint. Abort the job. If none of these actions corrects your endpoint problem, call your OpenText support representative Resuming an Endpoint If the problem is not with one of the published assets (for example, the database was temporarily unavailable), you can correct that issue and simply resume the endpoint. If the problem was not resolved, then resuming the endpoint will just cause content delivery to suspend again immediately. To resume an endpoint: 1. Open the Job Console in a browser (see The Job Console on page 392). 2. Click Manage Endpoints in the Job Console Actions window. This brings up the Endpoint List window. 3. Find which endpoint is suspended by looking at the State column. For example, the following figure shows that the Appsvcs endpoint for the Production stage is suspended: 4. Click Suspended. This action causes the Endpoint Diagnostic Info window to be displayed for the suspended endpoint. 5. Select Resume from the drop-down menu and the bottom of the Endpoint Diagnostics window, and click Go Skipping an Asset and Resuming the Endpoint By skipping a problematic asset, you allow all the endpoints in a job to finish publishing that job's assets with the one exception of the asset you skipped. If you then go to the Management Console and look at the asset you skipped (and possibly its channels or site), the state shown in the Publishing column will be Unknown. This state results from the fact that some of the assets that got published may depend on the asset you skipped; however, the Job Console has no way of determining if that's so. Mousing over the state will give you more information; for example: WARNING: A job failed on all endpoints. If you know that no dependencies exist for the problematic asset, skipping and resuming is a good way to allow the entire job to complete, after which you can repair or recreate the problematic asset and publish it at a later time. 382 OpenText Web Experience Management Administration Guide

383 17.3. Troubleshooting Deployment To skip an asset and resume: 1. Go to the Job Console. The Current System Alarms box should show that the affected endpoint is suspended. 2. Click Manage Endpoints in the Job Console Actions box. The Endpoint List window appears, showing Suspended in the State column for the affected endpoint. 3. Click Suspended. The Endpoint Diagnostics window appears. 4. From the dropdown menu at the bottom of that window, select Skip Item and Resume, then click Go. 5. Confirm that you want to perform the endpoint action Stopping the Endpoint By stopping an endpoint, you allow any other endpoints in the CDS to proceed in processing the assets in the job (that is, they can temporarily ignore the synchronize phase of deployment as described in Deployment Phases on page 368). In this situation, the stopped endpoint is rolled back (that is, its subjob is returned to its initial state). The advantage to this action is that assets for all the other endpoints in the CDS are deployed, and you have time to fix the problem with the affected asset. After you fix the problem, you can start the endpoint, and the publishing software will try to catch the endpoint up with its siblings and complete the job. The disadvantage of the action is that assets may be partially deployed when you stop the endpoint. This is not an issue if you can fix the problem and restart the endpoint so that it finishes processing the job successfully. However, if you end up aborting the job, you may need to clean up assets from the partial deployment. To stop an endpoint: 1. Go to the Job Console. The Current System Alarms box should show that the affected endpoint is suspended. 2. Click Manage Endpoints in the Job Console Actions box. The Endpoint List window appears, showing Suspended in the State column for the affected endpoint. 3. Click Suspended. The Endpoint Diagnostics window appears. 4. From the dropdown menu at the bottom of that window, select Stop Endpoint, then click Go. 5. Confirm that you want to perform the endpoint action. OpenText Web Experience Management Administration Guide 383

384 Chapter 17 Troubleshooting Publish Problems Aborting the Job If nothing has fixed the problem to this point, and you want to stop and restart the job, you can abort the job. To abort a job: 1. Go to the Job Console. The Current System Alarms box should show that the affected endpoint is suspended. 2. Click Manage Jobs By Site in the Job Console Actions box. The Site List window appears. 3. Click the name of the affected site. The Jobs for site "<sitename>" window appears. 4. Click the affected job's Job Name. The affected endpoint's subjobs window appears. Note: If you do not know the job's Job Name, you can look up the affected job's ID in the Endpoint Diagnostics Info window (see Using the Manage Endpoints Action on page 400), and then come back to the Jobs for Site sitename window, where you can see which job has that ID. 5. In the Subjob State column, you should see Suspended (abort). Click abort. Be aware that assets may be partially deployed before you abort the job, therefore, you may need to clean up assets from the partial deployment Using the Deployment Agent Log File You should go to the Job Console first when you encounter deployment problems; however, not all problems can be solved immediately from there. You may need to obtain additional system information from outside the Job Console. For example, if you have a stopped Configuration Agent on a remote delivery stage host, this can cause the relevant endpoint to stop functioning. If the Job Console did not provide sufficient information for understanding the problem, look for hints in the Deployment Agent's log file. There are two ways to view a Deployment Agent's log file: From the file system on the host where the Deployment Agent resides. From the Deployment Agent's status node in the Configuration Console. In the file system on the host where the Deployment Agent resides, the agent's log file is located at: <WEMinstallDir>/vcm/inst-<instname>/cfgagent/vcm-<instname>/cdsvcs/ stage-<stgname>/cds-<cdsname>/cda-<daname>/logs/<daname>-runtime.log Where: 384 OpenText Web Experience Management Administration Guide

385 17.3. Troubleshooting Deployment <WEMinstallDir> is the WEM installation directory. <instname> is the WEM instance name. <stagename> is the name of the stage. <cdsname> is the name of the CDS. <daname> is the name of the Deployment Agent. For example: C:\OpenText\WEM\vcm\inst-vgninst\cfgagent\vcm-vgninst\ cdsvcs\stage-production\cds-production\cda-appsvcs\logs\ Appsvcs-runtime.log For information about where particular Deployment Agent log files are located, see page. If you do not have access to the host on which the Deployment Agent resides (or if it is inconvenient), you can access the log file from the Configuration Console by viewing the agent's status. For example, for the Production stage's Deployment Agent, browse to the following location in the configuration tree: Configuration Console Content Delivery Services Content Delivery Stage - Production Content Delivery Services - Production Deployment Agents Deployment Agent - Appsvcs Then, right-click Deployment Agent - Appsvcs and select Status. Note: If an affected Deployment Agent resides on a machine outside your firewall, you must enable communication between that machine and the one with the browser from which you are running the Configuration Console. Also, if you have enabled SSL for the Deployment Agent, you must enable the browser from which you are running the Configuration Console for SSL communication with the agent. To enable the browser, see the OpenText Web Experience Management - Planning and Installation Guide (WCMGT-IGD). When you click Status, a list of nodes appears in the center pane of the window, representing objects in the configuration path. You can expand the pane to see the nodes more clearly. Note: The Record, StaticFile, and Taxonomy nodes in the center pane will only be present if the Deployment Agent has received at least one deployment message from the Content Management Server since starting. In the center pane, click Log File. When you do, the right pane of the Configuration Console displays the tail end of the Deployment Agent's log file at that instant. You OpenText Web Experience Management Administration Guide 385

386 Chapter 17 Troubleshooting Publish Problems can expand the pane to see the log file's contents more clearly. Depending on the maximum number of lines displayed for the log file, you may have to scroll down through the monitors to see the end of the file. If all of the lines are not displayed, either increase the number in Max Lines for File Monitors and click Refresh, or determine where the log file resides and make a copy of it. To determine where a problem originated by looking at the log file, try one of the following approaches: Look at the Current System Alarms section in the Job Console main page, and get the alarm message's timestamp (in the Time Last Reissued column). Look for that timestamp in the Deployment Agent log file. When you find that location in the file, look backwards for possible causes of the problem. Similarly, get the Job ID of the suspended job from the Endpoint Diagnostics window in the Job Console. Search for that ID in the log file to find the general region where information about the error is located. Because the Deployment Agent deals with one asset at a time, look through the log file for a stack trace. Starting at the bottom of the log file, scan backward for problems or issues. For example, search the second column for WARN or ERROR messages, and if you find them view their associated messages for details about what happened. Search for phrases like: Event received Initializing handler The deployment agent encountered a critical error... Sometimes an ERROR message is self-explanatory; for example, Disk Full. In such cases you can fix the problem yourself. Use what you find, along with the class names in the log file and the stack trace (if available) to fix the problem. More complex issues require consulting OpenText Support. Once you fix a problem, you must resume the Endpoint Proxy from the Job Console as described in Resuming an Endpoint on page OpenText Web Experience Management Administration Guide

387 17.3. Troubleshooting Deployment Dealing with Consistency Issues Due to the asynchronous nature of deployment, problems that occur during deployment can cause the information to get out of sync between your Content Management Server and its target endpoints (web servers, databases, application servers, and so on). Two such consistency issues exist: Assets that the Content Management Server thought were published successfully, but which never actually arrived at their intended target. Assets that the Content Management Server thought were unpublished successfully, but which were never removed from the target endpoint(s). The following paragraphs discuss these issues. Following those paragraphs is a more detailed explanation of the implementation for handling such issues Assets Published Successfully, But Never Arrived Occasionally, publishing problems can cause the Content Management Server to think that certain assets have been deployed to your web server, database, application server, and so on, when in fact, those assets never arrived at their intended target. This kind of problem is not reflected by the Publish Indicator in the upper left-hand corner of the Management Console home page. If only a few such assets have an unknown publishing status, you can frequently correct the problem by republishing the asset itself, or even a group of assets in the same site/channel structure. In fact, sometimes this problem gets corrected by such actions before you even notice that a problem exists. When the problem is more serious; that is, a large number of assets have an unknown publishing status, you may need to resynchronize a Deployment Agent. Resynchronization is definitely a last resort it resends everything currently under Content Management Server control for which the suspended endpoint is responsible. In this situation, if the endpoint's Deployment Agent is responsible for deploying thousands of content items (content instances and/or static files), it may take considerable time for everything to be redeployed. Resynchronizing a Deployment Agent can be useful in catastrophic situations, such as when the disk to which a Deployment Agent sends deployed static files has been destroyed (and you have to replace the destroyed disk), or the database tables to which a Deployment Agent sends deployed records have been truncated or wiped out and re-created (and you must recopy all the content to those tables again). Note: You can only resynchronize Deployment Agents that are associated with delivery stages. If a Deployment Agent is associated with the Management stage, you cannot resynchronize that agent. OpenText Web Experience Management Administration Guide 387

388 Chapter 17 Troubleshooting Publish Problems Before you try to resync a Deployment Agent, ensure that the affected endpoint is not suspended. To resynchronize a Deployment Agent: 1. Open the Job Console (see The Job Console on page 392). 2. Select Manage Endpoints from the Job Console Actions box. The Endpoint List window appears. 3. Click on a delivery stage's endpoint name under the Endpoint Name column (for example, Accsvcs). The Endpoint Info window appears. 4. Select Stop Endpoint from the dropdown menu and click Go. 5. Confirm that you want to perform this action. Eventually, the status of the endpoint in the Endpoint Info window shows Stopped. 6. Open the Configuration Console (see Starting the Configuration Console on page 175) and log in as the WEM admin. 7. Expand the configuration tree path to the Deployment Agent you want to resynchronize. For example, if you are resynchronizing the Production stage's Deployment Agent, that path might be: Configuration Console > Content Delivery Services Content Delivery Stage - Production Content Delivery Services - Production Deployment Agents Deployment Agent - Appsvcs 8. Right-click Deployment Agent - Appsvcs, and select Start Deployment Agent. 9. Click OK to confirm that you want to start the agent. 10. Go to the Job Console's Endpoint List window, and click Refresh occasionally until the state of the Appsvcs endpoint changes to Standby. When the endpoint goes to the Standby state, you are ready to resynchronize the stage's Deployment Agent. 11. Go to the Configuration Console, right-click Deployment Agent - Appsvcs, and select Resynchronize Deployment Agent. If the option is grayed-out, refresh the window. 12. Click Finish to confirm that you want to resynchronize the agent. When the resynchronization process completes, you are returned to the Configuration Console. 13. Go to the Management Console's home page to verify that no publishing errors occurred. At most the System Health should show one Publish warning: the endpoint for the Deployment Agent you just resynchronized is still in Standby state. 388 OpenText Web Experience Management Administration Guide

389 17.3. Troubleshooting Deployment 14. Correct errors and restart the endpoint: a. Go to the Job Console b. Click Manage Endpoint in the Job Console window. c. Click on Appsvcs in the Endpoint Name column. d. Select Start Endpoint from the Endpoint Info window's dropdown menu, and click Go. e. Confirm that you want to start the endpoint Assets Unpublished Successfully, But Were Never Removed Occasionally, when a deployment problem occurs, the Content Management Server may think that it has successfully unpublished one or more assets, when in fact those assets have not been removed from your web server, database, application server, and so on. Such assets are called orphaned objects, or simply orphans. You can see how many and which objects are orphaned in your configuration. However, the procedure for doing so can take quite a while, so you should only view and/or remove orphans when downtime has the least impact on your customers. Viewing or removing orphans requires that the stage's endpoints be placed in Standby mode, which makes content updates for that stage unavailable to your customer. Note: While you can place a single endpoint in Standby mode and view/ remove orphans while other endpoints in the same CDS (sibling endpoints) remain running, we strongly recommend that you do not do so. For more information, see Orphan Processing on page 391. Because the view and/or remove orphans options can take so long to complete, it is likely that your window will time out. This is not a problem though, because helper actions have been provided that let you start an option, then come back later after the window has timed out and retrieve the results. You can also use the actions to abort a running option. For more information, see Helper Actions on page 390. To see a list of the orphaned objects in your configuration: 1. Go to the Job Console (see The Job Console on page 392). 2. Select Manage Endpoints from the Job Console Actions box. The Endpoint List window appears. 3. Click the Appsvcs endpoint for your delivery stage. The Endpoint Info - Appsvcs window appears. 4. Select Change to Standby mode from the dropdown menu, click Go, then confirm your selection by clicking OK. 5. When the change operation completes (and the Status of the Appsvcs endpoint is Standby), select the Get Orphaned Object Report option from the dropdown menu, click Go, then confirm your selection by clicking OK. OpenText Web Experience Management Administration Guide 389

390 Chapter 17 Troubleshooting Publish Problems Note: Once the option is running, the Endpoint Info - Appsvcs window uses a one minute wait with a refresh every five seconds. For a long running option, the window will time out before completion. Therefore, a number of helper actions are available for retrieving results, aborting, and so on. See Helper Actions on page If the operation does not find any orphans, restart your endpoint. To do so, select Start Endpoint from the dropdown menu, click Go, and click OK to confirm your selection. 7. If the operation does find orphans, the lines just above the drop down menu will show how many orphans were found, and a link will be provided to let you see the report, which is a list of the actual orphaned objects. Close the report window when you are through looking at the list, and return to the Endpoint Info - Appsvcs window. To remove orphaned objects from your configuration: 1. From the Endpoint Info - Appsvcs window for your delivery stage, select the Remove Orphaned Objects option from the dropdown menu, click Go, and click OK to confirm your selection. If you choose to remove orphans, the Job Console will attempt to remove all orphans. You cannot remove some and leave others in place. Note: Once the option is running, the Endpoint Info - Appsvcs window uses a one minute wait with a refresh every five seconds. For a long running option, the window will time out before completion. Therefore, a number of helper actions are available for retrieving results, aborting, and so on. See Helper Actions on page 390. When the operation completes, the Endpoint Info - Appsvcs window is refreshed to show how many orphaned objects were deleted and also any warnings that may have been returned by the operation. 2. Assuming you are ready to resume normal operation, restart your endpoint. To do so, select Start Endpoint in the list menu, click Go, and click OK to confirm your selection. Helper Actions The following helper actions are available to perform various actions while a view/ remove option is still running or has completed: Get Command Progress If a view/remove option is currently running, you can select this action to refresh the Endpoint Info - Appsvcs window so that it will show a percent complete value for the option. This allows you to perform periodic checks on a long running option. You cannot launch another view/remove option until the currently running option completes. Accordingly, the view/remove options do not appear in the drop-down list until the current option completes. 390 OpenText Web Experience Management Administration Guide

391 17.3. Troubleshooting Deployment Get Previous Command Result If a view/remove option has finished running and has results available, you can select this action to retrieve those results. While Get Previous Command Result is running, you cannot launch a view/ remove option. You must wait for it to complete first. until the currently running option completes. Accordingly, the view/remove options do not appear in the drop-down list until Get Previous Command Result completes. Abort Command If a view/remove option is currently running, you can select this action to stop that option. Orphan Processing In order for you to view and/or remove orphans, the options Get Orphaned Object Report and Remove Orphaned Objects both transfer a copy of the delivery stage manifest to the endpoint Deployment Agent(s). A stage manifest contains the list of objects that the Content Management Server thinks have been published successfully to that stage. Once on the Deployment Agent, the manifest copy's list is compared with the objects that are actually on the Deployment Agent's target web servers, database tables, and so on. Any objects on the target servers/databases that do not appear in the manifest copy are labeled orphans. Therefore, if you place one endpoint in Standby mode, but allow its siblings to remain running, the Content Management Server will continue to make changes to its manifest as content continues to be published. In effect, the original manifest and its copies are no longer in sync, and this situation can result in objects being labeled as orphans, when in fact they are not. Note: The size of your delivery stage's manifest is a major determinant of how much time is required to view/remove orphans. A stage's manifest can be very large. For reasons of scalability, both options (Get Orphaned Object Report and Remove Orphaned Objects) transfer the manifest copy in chunks. The chunks accumulate (and are persisted) on the Deployment Agent. Note: The delete operation entails taking the GUID of the orphan and reconstituting the object from the database. Because of this, orphan removal is limited to endpoints where Appsvcs is available. StaticFile-only endpoints are not supported. Orphaned Objects Reports Endpoint command mode can generate and remove orphaned object reports. There is a series of five endpoint command definitions (ECD) that support these commands: Deployment Manifest Initialize (DMI) Deployment Manifest Update/Upload (DMU) Deployment Manifest Close (DMC) Generate Orphan Report (GOR) OpenText Web Experience Management Administration Guide 391

392 Chapter 17 Troubleshooting Publish Problems Remove Orphan Objects (RMO) Each endpoint command definition is a subject to a timeout. The retry system and the values governing endpoint command definition have been up hard-coded. In 8.5 and later the following values can be configured: ENDPOINT_COMMAND_DEFINITION_POLLING_INTERVAL (default 2) DMI_ENDPOINT_COMMAND_DEFINITION_TIMEOUT (default 20) DMU_ENDPOINT_COMMAND_DEFINITION_TIMEOUT (default 120) DMC_ENDPOINT_COMMAND_DEFINITION_TIMEOUT (default 20) GOR_ENDPOINT_COMMAND_DEFINITION_TIMEOUT (default 120) RMO_ENDPOINT_COMMAND_DEFINITION_TIMEOUT (default 300) Note: All timeout values are in seconds. When creating configuration variables they must be defined at the /vcm-<foo>/ vcms component level. If you have issues running the orphan report or removing orphaned objects, try the following: Create configuration variables. Set the DMI timeout higher. During the timeout phase the deployment manifest is created in the VGNEPPUBASSETMANIFEST table. This process takes long time if multiple items are published to the stage associated with the endpoint The Job Console The Job Console is a browser-based diagnostic and management tool embedded in the Content Management Server that allows you to view and manage elements of the publishing process. Assuming you are an administrative user, you can reach the Job Console by entering the following URL in a browser: where <host> is the name of the machine on which the Content Management Server (VgnVCMServer) is running, and <port> is the Content Management Server's port number. (The default port number is ) You can also reach the Job Console by clicking on the Publish status link in the System Health box located in the upper left-hand corner of your Management Console home page. There are six main actions shown in the Job Console. Five of these appear in a submenu called Job Console Actions, as shown in Figure 17-2: 392 OpenText Web Experience Management Administration Guide

393 17.4. The Job Console Figure 17-2: The Job Console The actions are as follows: Manage Jobs By Site Allows you to view and manage jobs that currently exist as part of the WEM deployment. View Content In Job Queue Allows you to see a list of the content currently in queue for publishing View Management Stage Job Info Allows you to view and manage the automatic jobs created on the Management stage when content is created, updated or deleted. Manage Endpoints Allows you to view and manage the status of endpoints registered with the system. View Job Resource Info Allows you to view the system-wide job resource usage information. View Diagnostic Info Allows you to generate an HTML report of low-level system information. View Publishing Failures Allows you to view Publishing Failure Reports, which lets you see information about problems with job creation, and even fix those problems in many cases. It also lets you republish the affected assets. The remaining section of the Job Console is displayed beside the Job Console Actions submenu. It is titled Current System Alarms. It displays the current errors and warnings in the deployment subsystem. If there are no alarms or warnings it will indicate No current alarms. Which page of the Job Console you view depends on the alarms, warnings, or states you wish to investigate. Follow the guidelines in Introduction on page 377. Note: On some pages of the Job Console, there is a Refresh button at the top of the console panel. Click this button whenever you wish to refresh the view. The Job Console does not refresh dynamically. Clicking on any component names that appear as links will initiate further window(s) that contain more information or actions. OpenText Web Experience Management Administration Guide 393

394 Chapter 17 Troubleshooting Publish Problems Using the Manage Jobs by Site Action This action allows you to manage the publishing jobs that are designated for specific sites. You can list the details for a job, clean up (prune) the metadata associated with a completed job, or get the contents of a particular job by stage. Clicking onmanage Jobs by Site will take you to the Site List window: Figure 17-3: Site List The first page of this window lists all of your sites by name and provides the total number of jobs associated with each site. Also on this page are the following buttons: Refresh Click this button to refresh the view. The Job Console does not refresh dynamically. Clean Up Completed Jobs for Selected Site Cleaning up is the same as pruning. Click this button to prune completed or invalid jobs from the job list for the site. See Configuring Publishing to Autoprune Jobs on page 430 for related information. Resubmit site content for scheduled publish Click this self-explanatory button only after correcting the problem that prevented the content from being deployed in the first place. Note: Only click the Resubmit button if the site is a scheduled publishing site. By clicking on the name of a site that has a job count other than zero you will be forwarded to the Jobs for Site Page: Figure 17-4: Jobs for Site Page 394 OpenText Web Experience Management Administration Guide

395 17.4. The Job Console The information recorded in the Jobs for Site Page can be summarized as follows: Job Name Name given to the job at the time of job creation. ID A unique alpha-numeric identifier for the job. Type Displays whether the job type is Publish or Unpublish. State Current state of the job. For possible states and their meanings see Table 17-1 on page 395. Note: If the job state is DpSucceeded, DpCompleted, or DpFailed, a prune link appears next to the state name. Clicking the link will initiate the pruning process. If the job state is InProcess a cancel link appears next to the state name. An InProcess job is one that has not yet finished workflow. Clicking cancel will not cancel a job if that job has already started to deploy at a stage; however, it will prevent subsequent stages from receiving the job. Table 17-1: Job States Job State DpCompleted DpFailed DPSucceeded Initialized InProcess Invalid Open WfCompleted WfCancelled Description Deployment of the job was successful at one or more endpoints and failed at one or more endpoints. Deployment of this job has failed. Deployment of this job has succeeded. The job has been initialized. The job is in process; it has entered workflow. The job failed creation. The job has been opened and is waiting to be initialized. The relevant workflow for the job has been completed. The relevant workflow for the job has been cancelled. For more information on job states see Endpoint Proxies, Endpoints, and Deployment on page 367. Created Time and date the job was created. Completed Time and date the job was completed. Requestor Indicates the name of the agent that created the job. The system uses three pre-defined and one user-defined name: OpenText Web Experience Management Administration Guide 395

396 Chapter 17 Troubleshooting Publish Problems autodeploymentprocessor Indicates that the job was created automatically after content was created, deleted, or updated in the WEM (a Management stage job). autodeploymentjob Indicates that the job was created by the WEM when the autodeploymentjob program task was used. VgnAutoPublisher Indicates that the job was created by the scheduled publishing system. user defined If jobs are created by the API, then the requestor name is user defined. Force Indicates if content will be deployed to a particular stage regardless of whether the content exists or is considered stale by the system. Stale content on a stage varies in version from the content in the current job. The setting can be either true or false. If set to true, content will be deployed regardless of the state of the content on the target stage. If set to false, content will only be deployed if it does not exist on the stage or if the version already deployed at the stage differs from the version in the job. For information on how to set the Force variable, refer to the OpenText Web Experience Management - Management Console Online Help (WCMGT-H-ACM). Prune Indicates whether a job's metadata will remain in your system (database) after the job has completed. If set to true, then the metadata will be cleaned up (pruned) after the job has completed. If the job fails, it will not be pruned. This is so that analysis can be performed on the failed job. If set to false, then the metadata will remain in your system regardless of completion status. For details about prune settings, refer to Processing the Job: the Job Engine on page 358 and Configuring Publishing to Autoprune Jobs on page Seeing Job Contents and Exclusions Also on the Jobs for Site Page, you can select any site's radio button and then click one of two buttons: Get Job Contents Get Exclusion Report Clicking Get Job Contents allows you to either retrieve the contents of a given job by stage or across all stages. When you choose the by stage view, you see the content targeted at a specific stage. A window will pop up that lists the contents of the job and the associated IDs for this content. See Figure OpenText Web Experience Management Administration Guide

397 17.4. The Job Console Figure 17-5: Job Contents Window Clicking Get Exclusion Report allows you to retrieve a list of assets excluded from a given job Viewing Subjob Details for a Job When you click on a particular job name in the Site List column of the Jobs for Site page, you will be taken to the Subjob page for that job. For example, see Figure Figure 17-6: Subjob List Page The subjob page contains a list of subjobs for the job. A subjob contains the list of content destined for a particular endpoint (Endpoint Proxy/Deployment Agent pair). Each subjob row contains the following information: Stage Name The name of the stage to which to which the endpoint belongs. CDS Name The name of the instance of Content Delivery Services to which the endpoint belongs. Endpoint Name The name of the endpoint to which the subjob is deploying content. By clicking on the Endpoint Name you can initiate a pop-up window OpenText Web Experience Management Administration Guide 397

398 Chapter 17 Troubleshooting Publish Problems that displays information for the endpoint, including the relevant unique IDs and the status of the endpoint. For full details of the Endpoint Information window, refer to Using the Manage Endpoints Action on page 400. Endpoint Proxy State The current state of the endpoint proxy. Generally, the endpoint proxy states are internal states and used by OpenText Support only. Subjob State The current state of the subjob. For a description of subjobs, refer to Processing the Job: the Job Engine on page 358. Subjob States on page 398 displays the possible subjob states and describes what each state means: Table 17-2: Subjob States State Name Abandoned Aborted Cancelled Completed Ignored InProcess Killed NotStarted Planned Ready ResyncCancel Suspended Description The subjob has been abandoned. The system has ended the subjob's tasks in an orderly fashion, but with no Deployment Agent notification. The subjob has been aborted. The system has ended the subjob's tasks in an orderly fashion, with the relevant Deployment Agent being notified. This allows for appropriate action for any relevant listeners or handlers. The subjob has been cancelled. The subjob has been completed successfully. Internal system state. The subjob is being executed. The subjob has been terminated without proper notification. The subjob has not been started. Internal system state. The subjob is ready. The subjob has been cancelled. When an endpoint is resynced, all subjobs queued for that endpoint are cancelled. The subjob has been suspended. If an endpoint is suspended, the current job being worked on by the endpoint is suspended as well. For more information on subjob states refer to Endpoint Proxies, Endpoints, and Deployment on page 367. Started The time and date the subjob was started. Finished The time and date the subjob was finished. 398 OpenText Web Experience Management Administration Guide

399 17.4. The Job Console Using the View Management Stage Job Info Action This action, accessible from the main view of the Job Console, allows you to view and manage automatic jobs in the Content Management Server. When content is created, updated, or deleted in the Content Management Server, automatic deployment jobs are created and deployed to the Management stage. Management stage jobs are created and managed by the system. A Management stage job contains one content item and is automatically pruned when completed. When you click on the name of the action, a pop-up window appears that lists any jobs that fit this criterion. For example, see Figure 17-7: Figure 17-7: Management Job Information Window The window contains the number of Management stage jobs in each state. For example, from the window above, there are 47 Management stage jobs in a Ready state and 1 in a Suspended state. Note: If the job state is Suspended an abortlink appears next to the state name. Click this link to abort the Management stage job only if resuming the endpoint is not an option Using the View Content In Job Queue Action This action allows you to see the content currently in queue for publishing, The action shows a table that lists the content types in queue, and provides a count of how many instances of each type are in the queue. By clicking on the type name, you can see the following information for each instance: The name of the instance The type of job to be performed for that instance The name of the site OpenText Web Experience Management Administration Guide 399

400 Chapter 17 Troubleshooting Publish Problems The name of the job The job's state; for example, workflow completed (WfCompleted) The job queue is a very dynamic: what you see represents a snapshot in time, and changes even as you look at it. Accordingly, you can select one or more of the types and click Refresh to update the count for the selected types, or you can select one or more instances and click Refresh to update the preceding information for the selected instances Using the Manage Endpoints Action This action, accessible from the main view of the Job Console, allows you to display and manage the status of endpoints registered with the system. See Endpoint Proxies, Endpoints, and Deployment on page 367. The first page of this view is the Endpoint List. See Figure Figure 17-8: Endpoint List Page The Endpoint List page displays the following information: Endpoint Name The name of the endpoint registered with the system. Stage Name The name of the stage with which the endpoint is associated. The default name for the Management stage is mgmt. The names for delivery stages are user-defined through the Configuration Console. The WEM will use Production for the first delivery stage if you do not choose a different stage name. CDS Name The name of the relevant instance of Content Delivery Services. Refer to Stages on page 364 for a discussion of Content Delivery Services. State The state of the current endpoint. Endpoint States on page 400 shows the possible endpoint states and describes what each means: Table 17-3: Endpoint States State Name Stopped Description The Deployment Agent has stopped and the Endpoint Proxy is offline. 400 OpenText Web Experience Management Administration Guide

401 17.4. The Job Console State Name Standby Running Waiting Suspended Not responding Description The endpoint is in standby. The Deployment Agent is running and the Endpoint Proxy is offline. The endpoint is currently running. It is either working on a job or available to work on one. The endpoint is waiting. This only applies for an instance of CDS with more than one Deployment Agent. It implies at least one Endpoint Proxy is suspended. The endpoint is currently suspended. The endpoint is not responding. Contact OpenText for assistance. Avg Queue Time The average time, measured in milliseconds, that ready subjobs for the endpoint wait before being processed. Avg Process Time The average time, measured in milliseconds, that a subjob takes to process at a specific endpoint. Queue Length The number of subjobs that are ready to be processed at the endpoint Retrieving Endpoint Information There are two ways to retrieve information about a specific endpoint: Click on the endpoint's name. Click on the endpoint's state value (only available when the endpoint's state is not Running). Clicking on the Endpoint's Name When you click on the endpoint name (for example, AppSvcs), the WEM software displays a pop-up endpoint information window similar to the following: OpenText Web Experience Management Administration Guide 401

402 Chapter 17 Troubleshooting Publish Problems The endpoint information window displays the relevant information for a given endpoint. If the state of the endpoint is Suspended, the state name will appear as a link. See Clicking on the Endpoint's State Value on page 403. If the state of the endpoint is Not Responding, there is no action menu available. In this case, contact your OpenText Support representative. Additionally, you can perform endpoint operations using the pull-down menu at the bottom of the window. Available operations depend on the state of the endpoint. Operations are: View Endpoint Subscriptions Initiates a pop-up window that displays subscription information for this endpoint. A subscription refers to the kind of content that an endpoint is enabled to handle. Each subscription consists of an asset type and a deployment type. The view lists the following information: Asset Type Name Refers to the low-level asset category, for example RCRD for record, STFL for static file, and TAXO for taxonomy. Deployment Type Name Refers to the deployment type for a given asset type. The same asset type can have multiple deployment types. For example, a static file can have different deployment types for specific file types (PDF, JPG, text files, and so on). Reset Statistics Resets the statistics (average queue time and average process time) in the system for this endpoint. Start Endpoint Starts the endpoint. Stop Endpoint Stopping the endpoint stops the Deployment Agent. Stopping (and restarting) the Deployment Agent is sometimes required to fix a problem; for example, when troubleshooting a custom listener. Stopping the endpoint also provides a way to roll back the job currently being worked on by the suspended endpoint, so that when you restart that endpoint, the job is re-deployed.this action stops the endpoint. Change to Standby Mode Places the Endpoint Proxy in Standby Mode. When an endpoint is in Standby mode, no deployment activity takes place. Use this command when you need to perform maintenance operations; for example, to resync. Note: Resync can only be performed from the Configuration Console at this time; however, other maintenance operations can be performed from the Job Console. Get Orphaned Object Report Produces a list of objects that the Content Management Server thinks have been successfully unpublished, but which are still resident on the affect Deployment Agents' targets (web/application servers, 402 OpenText Web Experience Management Administration Guide

403 17.4. The Job Console and/or databases). See Assets Unpublished Successfully, But Were Never Removed on page 389. Remove Orphaned Objects Attempts to remove objects that the Content Management Server thinks have been successfully unpublished, but which are still resident on the affect Deployment Agents' targets (web/application servers, and/or databases). See Assets Unpublished Successfully, But Were Never Removed on page 389. Clicking on the Endpoint's State Value When you click on the endpoint's (non-running) state value (for example, Suspended), the WEM software displays a pop-up endpoint diagnostic window similar to the following: The Endpoint Diagnostic Info Window contains information describing the endpoint. It also shows the relevant details of the job currently being worked on by the endpoint. For more information on endpoint states refer to Endpoint Proxies, Endpoints, and Deployment on page 367. The action menu at the bottom of the window allows you to view failure info, resume, or stop the endpoint. View Failure Info Gives information such as the date and time of the failure, the reason for the failure, and so on. This is the first action you should perform. Resume Try to start the endpoint. Select this action only after you have fixed the actual problem. Something caused the endpoint to get in this undesired state. Resuming it without fixing the problem will merely cause the problem to reoccur. OpenText Web Experience Management Administration Guide 403

404 Chapter 17 Troubleshooting Publish Problems Skip Item and Resume If you can identify the asset causing the problem, and it is either unimportant, or you want to let the job finish publishing without that asset (to try to fix the problem after the rest of the assets in the job have been successfully deployed), select this action. Stop Endpoint Stopping the endpoint stops the Deployment Agent. Stopping (and restarting) the Deployment Agent is sometimes required to fix a problem; for example, when troubleshooting a custom listener. Stopping the endpoint also provides a way to roll back the job currently being worked on by the suspended endpoint, so that when you restart that endpoint, the job is re-deployed Using the View Job Resource Info Action This view displays system-wide information for job resource usage. Figure 17-9: System-Wide Job Resource Usage Page The system-wide job resource usage page displays the following information: Number of Existing Jobs The total number of jobs in the system. Number of Existing Job Items Total number of items contained within the existing jobs. Number of Existing Deployment Manifest Entries The number of entries in the deployment manifest; the deployment manifest is a record of all deployed objects across all stages. Number of Existing Deployment Snapshots Snapshots are essentially versions of objects. A snapshot is created every time a new version of an object is published, and the manifest records, for each object deployed to a stage, the snapshot used for the deployment. The button at the bottom of the pop-up window will allow you to remove obsolete snapshots that exist in the system. An obsolete deployment snapshot is a snapshot that references older versions of a content item for a particular stage. These older versions are not stored in the deployment manifest and can be removed periodically. 404 OpenText Web Experience Management Administration Guide

405 17.4. The Job Console Note: This operation removes a maximum of twenty obsolete snapshots at a time Using the View Diagnostic Information Action This action provides an HTML report on low-level system publishing variables. To generate the report, click on the action name. The report can be printed (or ed) in the event that you require low-level diagnostic support from OpenText Using Current System Alarms Action This action, which displays in the main page of the Job Console, provides information on the current errors and warnings within the deployment system. Figure 17-10: Current System Alarms Page The System Alarms section of the main Job Console page lists the following information: Severity The severity of the alarm; whether it is a warning (yellow) or an error (red). Refer to Troubleshooting Deployment on page 380 for more details on alarm states. Alarm Message The substance of the alarm; the message will indicate what is wrong and reference a unique ID for the component effected. The content of the message is configurable; for details on customizing alarm messages refer to Configuring Alarms and Notifications on page 429. Source The source of the alarm, for example, an endpoint. Time Last Reissued The time and date stamp from the last occasion the alarm state was issued within the system. OpenText Web Experience Management Administration Guide 405

406

407 Chapter 18 Customizing Deployment and Publishing This topic describes additional areas that you can configure to customize how deployment works in your WEM installation Introduction The Content Delivery Services (CDS) collects content from file systems and databases and distributes that content to multiple remote destinations by using stage management and Deployment Agents. This process is called deployment. A destination can be any program that uses content, such as a servlet engine, a web server, or a multimedia server. Because of the many default settings, you can deploy content with minimal configuration. The defaults help to quickly set up initial production and help during regular production cycles by minimizing the amount of information supplied for each content item. You can use the defaults, customize where needed, and then deploy content from the Content Management Server, knowing that the Deployment Agent has all the information it needs to place content items where they can be used Customizing Deployment Types A deployment type determines how a Deployment Agent handles content it receives. Deployment types are unique to content subscriptions (database records, static files, and taxonomies). Each content subscription type can have its own set of deployment types and can have deployment types of the same name they might not necessarily be related even if the names are the same. The default deployment types are: CmsNative for mapping all content items VgnScript for processing custom scripts OpenText Web Experience Management Administration Guide 407

408 Chapter 18 Customizing Deployment and Publishing Creating a Custom Deployment Type If your environment needs other deployment types, you can create new types and then assign them (by mapping them) to the content. To create a custom deployment type: 1. Right-click on the Content Management Server node instance and select: Deployment Type Tasks > Add Deployment Type. A wizard appears. 2. Specify the content subscription type. 3. Specify the name of the new deployment type Assigning the Deployment Type to Content You can adopt the correct deployment type when the content is added to the WEM. Do this by creating a default deployment type mapping in the Configuration Console. For example, you might want to assign (map) the Image File deployment type to files that have the.jpg file extension. You can then use the new deployment type to configure a Deployment Agent so that it deploys image files to a different directory (or server) than non-image files. Another common use would be to map custom Perl script files that have.pl file extension to the VgnScript deployment type. Custom scripts used in deployment must have the VgnScript deployment type. See Customizing Deployment and Publishing on page 407. Each file source has a list of entries that map that particular file source's filename extensions to one or more specific deployment types. Therefore, all files with a certain extension which are submitted to a file source will be mapped to the same deployment type(s). Therefore, if you want files with the same suffix to automatically map to different deployment types, those files must be submitted to different file sources whose deployment type mappings differ accordingly. To assign deployment types to content as it is submitted: 1. Right-click the instance of the Content Management Server node and select: Deployment Type Tasks > Add Default Deployment Type Mapping 2. In the wizard, specify the content subscription type that the new deployment type will apply to (database records, or static files). 3. Select the appropriate subscription type and click Next. 4. If the subscription type is for a static file: 408 OpenText Web Experience Management Administration Guide

409 18.3. Configuring Handlers a. Select the file source you want to map. Different file sources can have different mappings. b. Enter the file extension for mapping to a given deployment type. c. Select the deployment type. 5. If the subscription type is for database records: a. Select the data source you want to map. b. Select a deployment type. All records from the specified data source will then receive the associated deployment type. This allows you to control the deployment of records. Each deployment type can be routed to a different database resource destination Configuring Handlers You can configure Deployment Agents to subscribe to subsets of content. Those subsets are determined by content type (and possibly deployment type). For example, if a Deployment Agent is subscribed to the static file type but not to the record type, the Deployment Agent receives and process notices only about static files. During stage creation, a Deployment Agent is automatically created and is subscribed to files, records, and taxonomies. If you add another Deployment Agent for an existing stage, you must explicitly subscribe that agent to files, records, or taxonomies. A Deployment Agent's subscriptions can be further constrained by the deployment type it handles. When you set up a subscription, you can specify whether the Deployment Agent will handle one, more than one, or all deployment types specified for the content subscription type. You then specify how the Deployment Agent will handle each deployment type. To configure handlers: 1. In the Configuration Console tree, expand the Deployment Agents folder. 2. Depending on which level you want to modify, right-click one of the following: Top level node (Content Subscription - Static File). For example: OpenText Web Experience Management Administration Guide 409

410 Chapter 18 Customizing Deployment and Publishing Modifies handler configurations and destinations. You choose which deployment type to modify. If the Deployment Agent is subscribed to all content, but all deployment types are using the default, this is the only way to modify one of those deployment types to do something different from the default. If a deployment type is using the defaults for both destination and handler, no node is displayed. Deployment Configuration - Deployment Type. For example: Modifies the handlers directly. This has the exact same effect as clicking on the Content Subscription node, but does not prompt you for the deployment type. Default Deployment Configuration default. For example: Holds the defaults. Use it when no specific Deployment Configuration exists for a given deployment type, or when a specific handler or destination resource is configured to use the default. When new deployment types are added, a Deployment Agent that is subscribed to all deployment types automatically picks up the content with the new deployment type, and will automatically use the default handler and resource destination. This saves you from having to configure all of the Deployment Agents to handle the new deployment type in most cases. Deployment Configuration - * (All StaticFile). For example: 410 OpenText Web Experience Management Administration Guide