WCM Best Practices Setting Up the Infrastructure Paul O'Mahony Technical Marketing Manager WCM Edition DOCUMENTUM, INC. 2002
TABLE OF CONTENTS Introduction...3 Describing the Engine...3 econtent Server...4 WebCache...5 Content Caster...5 Developer Studio/DocApp Installer...5 AutoRender Pro...5 WebPublisher...5 Documentum Administrator (DA)...5 Workflow Manager...5 Content Personalization Services (CPS)...6 ftpintegrator...6 econnectors...6 Engagement Services...6 Building your Motor...7 Tiers Without Tears...7 Golden Rule...8 Conclusion...8 DOCUMENTUM, INC. 2002
Introduction Once all the site analysis is complete (see the Site Analysis paper on the Documentum Developer site, it's then time to begin the dirty work. Like any good solid vehicle, your system will only be as strong as the chassis that supports it. How far it will take you depends on the kind of engine you've got so it's important to build and maintain both well. This paper won't attempt to delve into the performance or sizing requirements for this foundation. It deals with the recommendations for the different parts and pieces and how they go together to make up a solid WCM foundation. Describing the Engine Before we go into setting everything up, we must first be aware of all the tools available to us, and also their function. The following is a list of all the pieces that go together to make up a WCM Enterprise Solution: econtent Server WebCache Content Caster Developer Studio/DocApp Installer AutoRender Pro WebPublisher Documentum Administrator Workflow Manager econnector for JDBC, BEA WebLogic, IBM WebSphere, ATG Dynamo Engagement Services Page 3 of 3
This is based on current 4.3 architecture as illustrated below. Retrieve Content & Metadata directly from Repository econnector (JDBC,IBM,ATG,B EA) F/S F/S econtent Server Rightsite RDBMS HTTP/APP Server Verity RDBMS WebCache Source Publish DA WebPublisher HTTP WebCache Target Documentum WebPublisher Client Engagement Services CPS AutoRender Pro Documentum Desktop Client, Developer Studio, Docapp Installer Deploy to Web Farm with Content Caster DCTM 4i WCM Architecture econtent Server This is our core server that interacts with a relational database and the file system for content storage. It is the engine that implements all of the core functionality and management of the system; workflow, lifecycles automation, jobs, and content storage areas. You can have a number of servers running in a single installation to gain performance benefits and for fallback, but in general one is sufficient, especially for initial projects. Through econtent Server, server administrators create a Docbase or repository where the web site content is stored. Users connect to the Docbase to manage their content using clients. Most users will use WebPublisher for this. They can also use standard clients such as DreamWeaver and Homesite through ftpintegrator. Page 4 of 4
WebCache WebCache is our high-speed delivery mechanism for content to be accessed through the Web. It provides a lifecycle-controlled snapshot of the content and metadata managed in the repository. Individual webcaches can be defined that allow for modeling of a site s lifecycle (WIP, Staging, and Active); renditions of a site (Internal, Partners, External); and different language translations of a site. Content Caster Through ContentCaster, content and metadata can be delivered from WebCache or a staging area to a server farm or a geographically distributed set of Web servers. ContentCaster is a more feature rich delivery mechanism than WebCache in that it supports byte-level differencing, check sum restart and site rollback among other features. Developer Studio/DocApp Installer Developer Studio allows developers to modify and create custom object types, lifecycles, ACLs, workflows and any other components associated with a Content Management deployment. The latest version (4.3) of Developer Studio allows for full migration of a Docapp from environment to environment and can include cabinets and their content. Docapp installer 4.3 has been modified to handle this kind of Docapp install. AutoRender Pro Using AutoRender Pro, content can be automatically converted into HTML and PDF renditions. The econtent Server can be set up to automatically queue the content to the AutoRender machine where it will be transformed and returned to the original content object as a rendition of that object. This is specifically useful in cases where PDF or HTML renditions of content are to appear on a Web site. Manuals and reports would be a good example. WebPublisher For Web site designers and content contributors, WebPublisher allows users who don t know HTML to enter content into a template and preview it in the Web site. It also includes a sophisticated tool for template development and design. In addition, WebPublisher is localized allowing your business users to enter content in an interface in their local language. Documentum Administrator (DA) DA allows you to administer the Content Management System from anywhere, as it's a Webbased UI. Everything from storage areas to methods, jobs can be checked from here. From a WCM perspective, the WebCache configurations can be created, edited and run manually from this client. It also offers a DQL and API interface for hardcore administrators. Most of the DA functionality can be launched from the WebPublishers admin tab from within the admin interface. Workflow Manager This client will be launched from Developer Studio if you double-click or choose to edit a workflow. It can also be launched from the Documentum program group. This is a GUI that enables developers to edit existing or create new workflows just by dragging and dropping activities into the workflow area and assigning users or methods to those activities. Each workflow template and its associated activities are stored as objects within the repository themselves so it is necessary to connect to the repository to open and edit existing workflows. Once created and/or edited, the workflows can be validated and installed through the UI. Page 5 of 5
Content Personalization Services (CPS) A Web site is made up of content and metadata. Contributors often only think about creating and managing content, but the metadata is frequently just as important. Through CPS, content is automatically interrogated and metadata values are assigned. By default, the author has the ability to request CPS processing and approve assigned metadata values. ftpintegrator For more Web savvy users, Documentum integrates with all industry standard Web authoring tools such as HomeSite, Dreamweaver, and others using our own FTP service. The repository is seen as a directory structure, just like a mapped drive or ftp interface. Content can be imported and checked in and out through the interface. This gives you a seamless interface into the repository allowing your users to use their existing interfaces and thus limit the need for full on training for a new client tool. econnectors When the Web site needs to be powered from a direct connection to the repository, Documentum provides an e-connector that allows industry-standard JDBC calls to be executed within any J2EE-compliant Web application server. Documentum provides econnectors for IBM WebSphere, BEA WebLogic and ATG Dynamo as well as a standard JDBC econnector. The econnector uses the same syntax against the WebCache or the econtent Server. Thus, the same code within your Web page can access the econtent Server inside the firewall and WebCache outside the firewall. This provides the ability to access content that is publicly available and also more secure content kept in the repository. Being J2EE compliant it enables you to pull content from many back-office systems and sources, providing a seamless experience to both private and public consumers but with the added security. Engagement Services A Web site is a collaborative project, comprised of a lot of different people with different skill sets and knowledge adding different things, which go together to make the site. Often content is sent out or received from different vendors. Engagement Server integrates seamlessly into the workflow process so to end-users, content is merely being routed. An example would be graphics, or new products for an online retailer. Or perhaps your Web site pages need to be reviewed before being published by a manager who is not necessarily a Documentum user. The biggest and most common use is in Global deployments where content can be sent for Translation via Engagement Server. With its tight integration to workflow and standard protocols such as HTTP and SMTP, Engagement Server is extremely flexible. In the Globalization example users can simply send their file on the next step of their workflow, which to them is say, Send For Translation. Unbeknownst to them, their content is being whisked away beyond the firewall via HTTP or in email format to an outside vendor for translation. Once the translation is done, the content is returned via email or HTTP to Engagement Services. It gracefully hooks it up to the workflow process it was sent from and the translated content appears in the users inbox, where they receive an email confirming the return of their translated content. They can continue with the process of working their content through its lifecycle, blissfully unaware that it has been sent outside their company and returned translated, until it is automatically published to its corresponding global web site. To them, it was merely the next step in the workflow. Page 6 of 6
Building your Motor Once we know all of the components and their functions then we need to decide what parts we need. For all WCM deployments no matter what size you're going to need: econtent Server WebPublisher or ftpintegrator Developer Studio/Workflow Manager Documentum Administrator WebCache Your back end Your clients Configuration & Docapp Install For maintenance & fine tuning Your Web site delivery mechanism This would work as a standard WCM basic deployment (CICO - content in, content out). However, there is more power in the other parts too, which in a sense adds more turbo or maybe a fuel injector to your deployment. These are the products and some examples why they make your deployment "humm". ftpintegrator CPS Content Caster AutoRender Pro econnectors Engagement Services Use this for migrating existing content and allowing your users who are familiar with WSYWIG HTML clients to produce their content and import it/edit it through a familiar interface. Use this for smart-tagging of your content - especially useful when dealing with the unstructured data within documents i.e. where the meat is. Enabling users to suggest values based on a pre-configured Domain Map, as opposed to allowing them to enter in their own values, which can increase the propensity for error, is extremely powerful. If you're deploying to a Web farm or a distributed server architecture this makes the most sense. Also offers more features than WebCache. Automatic rendering of documents into HTML and PDF on checkin. These renditions can then be published to the Web, allowing automatic renditioning of content. Also enables everyday authors to contribute to the Web site through a familiar interface such as Word, and PowerPoint. Depending on your architecture and intent, these may be useful in intranet and Internet sites, allowing access to content in the Docbase through simple configuration. If you're deploying global content to either inside or outside translations services, working with external partners or vendors or allowing the submission of content via HTTP (or secure HTTPS) or (SMTP), you need this piece of powerful software. It is often overlooked but can have many functions on both intranet and Internet levels. It also offers support for SSL & Digital Certificates. Tiers Without Tears Once we figure out the parts we're going to use then we need to figure out where they should go. Documentum supports a flexible n-tier architecture that scales with your load. In general a threetier approach is most common where the RDBMS and econtent server reside on one server, RightSite, WebPublisher and DA reside on another and then the client logs in through either their browser or Developer Studio from their machine, i.e. the third tier. Page 7 of 7
Depending on the scale of the deployment two or three servers will suffice, though for say, a proof of concept you could get by with one as a small installation. This, as a two-tier approach, is generally not recommended however, especially if it is the intent to scale it. On larger deployments, depending on resources, four tiers can be used where the RDBMS is on a single machine. This would be recommended in a global deployment situation, passing off the processing to the beefier RDBMS server. Additional machines are recommended where AutoRender Pro and CPS are used. Generally, these should be on dedicated machines. AutoRender itself runs only on NT and WIN2K. Engagement Services can be deployed on the econtent Server machine. The WebCache instance is comprised of a source and a target piece. The source piece sits on the econtent server machine. The target piece or pieces sit on the WIP, Staging and Active machines, assuming you're not using ContentCaster. Generally, a single target agent will do for WIP and staging, and a dedicated one will be used for the active Web site. If using a ContentCaster model, you would probably only need one WebCache target agent. Golden Rule Suppose we're building a car for the INDY 500 or Le Mans. We're going to put all of the bells and whistles on there, piece by piece and then as we do, test each piece before actually putting it in a race. Your WCM infrastructure is no different. It may be stating the obvious but with any install or upgrade of an existing system, before you make it available for public consumption where real content can be affected, you should test, test, and test. Documentum provides the Accelera Web site in Docapp format, which enables you to install some sample content and run it through its paces before opening the system up to your user community. It can be downloaded from the Documentum Developer site. Conclusion Once you've identified the different pieces to build your WCM engine, it's then a matter of seeing which pieces fit where and what pieces you need for your deployment. A number of factors impinge upon this - existing internal architecture, availability of hardware, platforms, and portability. This paper has given some standard guidelines, but is no substitute for Documentum Professional Services, a Systems Integrator or someone who is well experienced in Documentum deployments. It is important when deploying to not only think about the infrastructure, but when implementing ftpintegrator say, a good question to ask is will the user community adopt this, or are we just going to use it for migration of initial content and move to a different model? You should look at least one year ahead for your deployment too. An instance of this is, the Web site may not be ready to implement a global solution just yet, so there may be no need for Engagement Services. However, there could be a definite need one or two years from now. Looking ahead also comes into play with sizing requirements. That box you've got the econtent Server on now is sufficient, but when you get a year or two ahead and your content has quadrupled will it be enough to get you across the finish line? Otherwise, you might end up in the pits Page 8 of 8