Originally published: 5/11/2005; 1:29:01 PM
There are three main components to Documentum’s Web Content Management offering: Web Publisher, Site Caching Services (SCS), and Site Deployment Services (SDS). Somewhat confusingly, the latter two products are often bundled as Site Delivery Services (SDS). In the rest of this article I’ll use “SDS” to mean Site Deployment Services (the specific product) not Site Delivery Services (the product bundle).
I’m often asked to explain what each of these components are and how they work together. You can obviously get this information from Documentum’s web site, but I’m hoping this article provides a more succinct, hype-free explanation.
Web Publisher
Web Publisher is a web-based application that helps web masters and content authors manage web site content. Users can create, search for, view, and approve content, manage versions, translations, and renditions of content, and submit content into workflows.
Web Publisher Templating
Web Publisher supports templating through Web Publisher Editor. The Web Publisher Editor is a Java applet that enables non-technical users to contribute content to the repository. The content can be stored in a presentation-independent format and submitted into a Documentum workflow for approval prior to publishing.
A Web Publisher template is pretty straightforward to define, although it does require basic XML and XSLT knowledge. Documentum queries can be executed from within XSLT stylesheets to incorporate metadata or other XML chunks from other objects in the repository. (Documentum’s query language is called “DQL”. When DQL queries are used to return XML it is referred to as “xDQL”).
The Web Publisher Editor works great for most templates. But, when your templates start to get large, or if your data structure is complex, you may want to consider a structured authoring tool. The Web Publisher Editor can get pretty sluggish as the size of the template increases. There are several third-party structured authoring tools that integrate with Documentum and Web Publisher.
Managing the Process: Workflows, security, and other library services
Workflows, security, versioning, renditions, and translations can all be managed through the Web Publisher interface. The functionality is provided by the underlying Documentum Content Server. Out-of-the-box, Web Publisher includes a few standard workflows and basic security, but most people will create their own to suit their needs.
Documentum Developers new to Web Publisher will need to learn a couple of small Web Publisher-specific nuances, but for the most part, the techniques and tools used to configure Web Publisher workflows and security are the same as those used in other Documentum-based solutions.
SCS
Site Caching Services is used to extract content and metadata from the repository and deliver it to a file system. The file system can be any file system on any accessible host–it doesn’t have to be a web server.
In addition to moving the actual content, SCS can move the metadata to a target relational database. The database can then be used for personalization.
SCS has two pieces: a source and a target. The source runs on the same host as the content server. The target can run any platform supported by Documentum. The source and target are Java processes that communicate with each other over a configurable port.
At any given time, a piece of Web Publisher content is in one or more of at least three states. The out-of-the-box states are WIP, Staging, and Active. SCS can be used to deliver the content to a web server specific to each state. Obviously, the Active web server is your live web site. The WIP and Staging web servers are used in the production creation and approval process to test and review content.
Content can be published manually and on a schedule. Scheduled publish actions are managed by a Documentum job and executed by the Documentum method server. Manual publishes can be initiated through the Web Publisher user interface or in Documentum Administrator.
Of the three components discussed here, SCS is the piece that takes the most care and feeding. From time-to-time, publish jobs will fail or the SCS source/target processes will need to be restarted. The administrators are notified when this happens and the logs are sometimes (though not always!) helpful as to the root cause.
When is SCS not enough?
Most large production sites are served by multiple web servers. When a web server farm is involved, SCS should be used to deliver the content to a staging server instead of the live site. Another product is needed to keep the web server farm in sync. That’s where SDS comes in.
SDS
SDS is used to move a file system from one place to another in a “smart” and efficient manner. I call this process smart because, unlike SCS (at least in the current version), SDS keeps track of the files it delivers instead of simply blowing away the target directory. It is helpful to note that SDS is not natively Documentum aware–it can be used to move anything anywhere and does not connect to the Documentum repository.
Marimba, the company that makes ContentCaster which Documentum OEM’s as SDS, is essentially in the business of content distribution. Their tools can be used for all sorts of things beyond just moving web content. This creates a certain amount of complexity in the user interface and configuration. Many users find SDS somewhat daunting to get set up and running for the first time. My advice is to take the time up front to get your head around their tuner-subscription-transmitter-channel metaphor. And, as always, read the documentation! Recent releases have improved the SDS documentation greatly. If you take this advice, and once you get that first configuration set up, subsequent configurations will be a snap.
As mentioned, the software is somewhat complex, but I’ll offer a rough primer on the SDS model. Each node in the configuration is called a Tuner. Tuners are Java processes that talk to each other over configurable ports. So, in a simple case of a staging server and a web server you will have a Tuner on the staging server and a tuner on the web server.
Tuners–just like TV tuners–have Channels. A Channel could be an executable program or it might be content. For example, there are pieces of SDS that are distributed as Channels. Don’t let this confuse you, though. They are just executable programs–they aren’t magic.
Tuners get their Channels from a Transmitter. When a Channel is updated the Transmitter sends out the update to all of the Tuners that have subscribed to that Channel.
What does this Tuner-Channel-Transmitter stuff have to do with your web site? When you publish your web site content with SDS what happens is SDS picks up your content and publishes it to a Channel. SDS then tells the Tuner on each web server in your server farm that it needs to pick up the updated Channel (i.e., your content). Each Tuner downloads the updated Channel from the Transmitter. If anything fails along the way, SDS tells each Tuner to abort or roll back the change.
What is the difference between SCS and SDS?
SCS and SDS are used for two different but similar purposes and often work together. Here is a very high-level look at the differences to help you distinguish the two:
– SCS is Documentum repository-aware. SDS is not. So, when you need to get content out of the repository, you need SCS. When you want to move files from a source file system to one or more target file systems, you can use SDS.
– SDS is useful when you have multiple targets that you want to guarantee are in sync. SDS is transactional in the sense that you can set up targets that will get rolled back if another target fails. SCS doesn’t have this transactional concept.
– You could use SCS without SDS but you probably wouldn’t use SDS without SCS (unless you had some other process in place for exporting the data from the repository).
What I haven’t covered
Obviously there is a lot of detail I’ve left out particularly when you are talking about large intranet or portal WCM implementations. Your users will want to know about additional options for getting content into the repository such as WebDAV and FTP. Taxonomy, or how the content is organized, can be an involved topic. And, you’ll need to have an approach for converting the content, automating the processes, and training your users. (Navigator has a methodology we’ve developed that’s been used successfully in the past or you can come up with your own).
How to get help
You can get more details on all of Documentum’s products at their web site.
If you’d like help selecting a WCM vendor, implementing a WCM solution, or building an Enterprise Content Management competency in your company, you can get more information about our services at Navigator’s web site.
http://www.navigatorsystems.com.
Industry organizations like AIIM and CMPros have good resources to leverage if you are implementing on your own or if you’d like more general information on ECM.