OpenText TeamSite 16.4 Architecture Guide

OpenTextTM

Web Content Management Architecture GuideRelease 16.4

OpenTextTM Web Content Management Architecture GuideRev.: May 2018

This documentation has been created for software version 16.4.It is also valid for subsequent software versions as long as no new document version is shipped with the product or is published at https://mysupport.opentext.com.

Open Text Corporation275 Frank Tompa Drive, Waterloo, Ontario, Canada, N2L 0A1 Tel: +1-519-888-7111 Toll Free Canada/USA: 1-800-499-6544 International: +800-4996-5440 Fax: +1-519-888-0677 Support: https://mysupport.opentext.com For more information, visit https://www.opentext.com

Copyright © 2018 Open Text. All Rights Reserved.

Trademarks owned by Open Text.

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.

https://knowledge.opentext.com/

https://support.opentext.com/

https://www.opentext.com/

Table of Contents

Chapter 1 Introduction 5

Architecture Overview 5

Chapter 2 Authoring 7

TeamSite Server 7

Content Organization and Data Model 8

Workflow 9

Interfaces 10

Metadata Capture 10

Content Contribution Applications 11

FormsPublisher 11

SitePublisher 12

Targeting 14

Preview 15

Chapter 3 Publishing 17

Publish with OpenDeploy 17

Chapter 4 Runtime 19

LiveSite 19

LiveSite Content Services 20

Rules Engine 21

LiveSite Display Services 22

3

4

Chapter 1 Introduction

Chapter 1

Introduction

This section provides an overview of the OpenText TeamSite (OpenText TeamSite) architecture. It includes the following topic: l Architecture Overview

Architecture OverviewThe Web solution architecture has two distinct, decoupled parts. An authoring part, where content and metadata are created and managed, and a runtime part that powers the live Web site. Changes in one environment are reflected in the other only through an established and controlled business process.

The authoring part of the solution is powered by TeamSite. TeamSite facilitates the creation, management and versioning of persuasive content and Web pages. Both structured and unstructured content can be edited in context, managed, versioned, enriched, and distributed. Using constructs like branches, editions and workareas, users can organize and collaborate on content. Content can be created using Web-based forms or through WYSIWYG page authoring tools. These are part of the TeamSite user interface. In addition, unstructured content can be created using any tools of the user’s choice and can be saved into TeamSite using the file system interface.

A big component of a dynamic Web site is rich media assets such as images and video. OpenText MediaBin is a rich media asset server that is used alongside TeamSite to author dynamic Web sites. TeamSite MediaBin connector is used to retrieve images from MediaBin and add them to the Web pages authored in TeamSite.

This newly-created content is then routed to an approver through a user-defined workflow. The approver then determines whether the content is appropriate or needs further modifications. If approved, the content is then archived and ready for publishing to the live Web site. As part of the workflow the content is then published to the live Web site using OpenDeploy.

Using OpenDeploy, content is sent from the Content Management System to the server(s) in the live environment. OpenDeploy allows the use of transactional, secure distribution of content (or any other files) to an arbitrary number of servers in a portal, intranet, or Internet setup. OpenDeploy publishes content (CMS content, file system content, application code, and so on) incremental, encrypted (up to 168-bit SSL), and transactional. Both multi-tier and fan-out deployments can be defined as a transaction, and can be rolled back. OpenDeploy can be fully automated and can be integrated into TeamSite workflows.

OpenTextTM Web Content Management Architecture Guide 5

Chapter 1 Introduction

6 OpenTextTM Web Content Management Architecture Guide

The runtime part of the architecture is powered by LiveSite. LiveSite consists of two main components. l LiveSite Content Services. LiveSite Content Services is a schema-less metadata and

content repository. Content and associated metadata can be stored in the repository and retrieved using REST-oriented interfaces. Content can be retrieved by querying for it (metadata or full text) or specifying a content ID. The REST API is neutral with respect to both programming languages and display technologies, which allows solution developers to use and mix languages and technologies such as Java, C#, PHP, AJAX, Flash, Silverlight, Ruby, JSP, ASP and any other technology that supports HTTP.

l LiveSite Display Services. LiveSite Display Services is the dynamic page rendering engine. The pages are created in the authoring environment and are stored as XML files. When a page is requested, the rendering engine reads the page definition and applies XML/XSL transforms to render the Web page.

A core part of the OpenText TeamSite platform is integration (through its connector technology) with an external SolrCloud service, which enhances the platform by providing metadata and content search.

Chapter 2 Authoring

Chapter 2

Authoring

This section describes the OpenText TeamSite authoring process. It includes the following topics: l TeamSite Server l Workflow l Interfaces l Metadata Capture l Content Contribution Applications l Targeting l Preview

TeamSite ServerTeamSite server is a versioning file system. It supports basic CRUD operations on assets along with versioning. Content can be accessed directly through a path-based lookup or by searching. TeamSite leverages the search server to provide search functionality. An embedded workflow engine provides the capability to automate many business processes.

In addition to the core functionality, TeamSite server has additional services such as reporting and event notification.


Chapter 2 Authoring


Content Organization and Data Model

TeamSite supports a simple and flexible data model. Content assets are stored as files and can be organized into folders. Each content asset or file is associated with some pre-defined system metadata. In addition to this system-level metadata, users can add their own metadata as simple name-value pairs. The name is always a string and value can be any data type. Internally, the server stores them as simple binary data. This simple yet flexible model makes it easy for users to define different content types.

In addition to the content assets themselves, the TeamSite data model has some higher-level organization constructs that facilitate parallel development of Web sites. The constructs are: l Branch. A TeamSite branch is a collection of all assets that define a site. The assets are

all organized in a hierarchical manner using files and folders. Branches have Editions, Staging areas and Workareas, which are views into the hierarchy.

l Editions. TeamSite editions are read-only snapshots of a collection of content assets. Editions are branch specific, that is, they are created on a per-branch basis. Content items in editions cannot be modified directly. A branch can have multiple editions.

l Staging Area. Every branch is associated with a Staging Area, a special type of edition where content can be modified but only through a submission process. Typically, new or modified content is routed through a workflow for approval and once approved, is

Chapter 2 Authoring

submitted to Staging. The process of submitting content makes a unique version of the content item and that version is read-only.

l Workareas. Workareas are sandboxes where users can create, modify and remove content. In a typical scenario, users create content in a workarea, test the changes, and then submit the content into staging. TeamSite supports multiple workareas per branch, thereby allowing multiple users to modify content concurrently and keeping their changes isolated from the rest of the system.

WorkflowTeamSite server has an embedded workflow engine that is used to drive business process automation. TeamSite workflow is a task-oriented workflow. Each workflow job is composed of a set of tasks. The job transitions from task to task until all tasks are complete.

There are a set of pre-defined workflow tasks that map to TeamSite operations. Some examples of tasks are: l Submit Task. A submit task submits files in a work area. l User Task. A user task assigns a task to a user. l Group Task. Similar to a user task, this assigns a task to a pre-defined group. Anyone

in the group can take ownership of the task. l External Task. An external task is a way to enhance the functionality of the workflow

engine. An external task can invoke a script or a URL. Customers can write their own functionality as external programs or servlets and invoke them using external tasks.


Chapter 2 Authoring


Workflow jobs are defined using XML. The engine accepts an XML job specification file as input. The XML job specification can be created using a Web form-based UI, which accepts user input, applies the input to a PERL template and generates the job specification.

The Workflow modeler can also be used to define a workflow. Workflow modeler is a desktop application that generates XML job specifications. Using the workflow modeler, users can also monitor the current status of the workflow in a WYSIWYG manner.

InterfacesTeamSite users access the system through two primary interfaces: a Java API called Content Services SDK, and a file system interface. The Java API is an easy way to integrate TeamSite functionality into other external enterprise software systems.

The file system interface is an easy way to integrate TeamSite server with third-party tools and systems. Any tool or system capable of interacting with a file system can seamlessly interact with TeamSite using the file system interface.

In addition, there is a graphical user interface called ContentCenter Professional. ContentCenter Professional is a Java-based Web application that runs in a Java servlet container. It uses the Content Services SDK to connect to TeamSite. This interface is primarily used by administrators and editors. Content is accessed by browsing through a hierarchy of files and folders.

Metadata CaptureContent assets created within TeamSite can have additional metadata set on them. This additional metadata can be used to access content through search or for navigation and targeting purposes. At the server, TeamSite does not impose any restrictions on the structure or type of metadata that can be set.

The metadata capture framework allows administration to give some structure to the metadata. Using XML configuration, a schema can be defined for metadata. The configuration mechanism provides flexibility in applying the schema to specific branches and/or content types. This framework enables corporations to define a common vocabulary with which to define and categorize content.

The metadata schema can be easily changed by modifying the XML configuration. The new changes are applied to content assets created after the update. Data migration is not mandatory or required.

Metadata capture is done by invoking a common data capture framework. The data capture framework is a Java-based engine that reads an XML configuration file and displays a Web form. Data capture in the Web form can then be validated using a programmable API (called FormAPI) and then saved into TeamSite. This common data capture framework is used for metadata capture, content authoring as well as workflow configuration.

Metadata can be added to content items in two ways:

Chapter 2 Authoring

l Manually add metadata at content authoring time. l Use the search server to analyze the content and suggest appropriate metadata for the

content item. This is a common way to categorize and classify content items.

Content Contribution ApplicationsThe ContentCenter Professional interface houses two applications that are primarily used to contribute content to TeamSite. FormsPublisher, a Web form-based authoring tool, and SitePublisher, a WYSIWYG editor for static or dynamic Web pages.

FormsPublisher

FormsPublisher is a TeamSite application that provides a highly configurable way to capture, edit, and store data input from content contributors. In addition, users can also define the appearance of the displayed data through presentation templates. This architecture allows for unlimited reuse of data after the data is captured and stored; it also lets you define different appearances and behaviors for the same data based on how, when, where, or to whom the data is displayed. The decoupled nature of content and presentation makes FormsPublisher a powerful tool for publishing in a multi-channel environment.

The main elements of FormsPublisher are: l Data Capture Templates. New content types are defined in TeamSite using data

capture templates. These templates are stored as XML files. Once a content type is defined it can then be made available for use within the TeamSite authoring environment through configuration. These templates are stored as XML files within TeamSite.

l Data Capture Records. A data capture record is a unit of data. It is based on a content template and is a content item. The data capture record is just the content and does not have any presentation logic associated with it.

l Presentation Templates. Presentation templates are used to encapsulate the presentation logic. The templates are agnostic of the content itself and can be applied to any data capture record. Legacy presentation templates were defined using PERL. With versions of TeamSite starting with TS6.5, the focus has been on using XSL to define presentation templates.

l Generated Files. Generated files are the result of applying a presentation template to a data content record. The generated file is typically an HTML file or any other format that can be consumed by a client.


Chapter 2 Authoring


FormsPublisher forms capabilities can be extended using FormAPI. FormAPI is a Javascript-based API that enable forms to dynamically respond to user actions and other external events. With FormAPI, browser forms are no longer simple static forms. They can be responsive, interactive and highly customizable.

Some of the things that can be done using FormAPI include: l Automatically compute the value of one field based on the value of another field. l Make a field entry appear or disappear as needed. l Automatically set field values or validate the user input.

SitePublisher

SitePublisher is a WYSIWYG site authoring tool. It is designed to enable front-line users to create dynamic Web sites without having to know HTML or other Web technologies. It is also designed to do this while allowing IT departments to keep strict control of brand and other site attributes.

Typically, two types of users interact with the SitePublisher application. l Developers. These users create components, page templates and prototype sites. l Content Contributors. These users use the components, page templates and

prototype sites to build Web sites.

Chapter 2 Authoring

The building blocks of SitePublisher-created Web sites are: l Components. Components are discrete pieces of functionality in a site, such as

navigation menus, areas of dynamic or static content, Web applications, and so on. They are the building blocks from which pages are created. A wide variety of components ship out of the box.

Every component is associated with content and appearance. The content can be source either from TeamSite DCRs or another external system using pre-built or custom-built code. The appearance of the components is controlled through XSL for complex cases and tokenized HTML for simple cases, along with CSS.

l Pages. A SitePublisher page is created by assembling a set of components. The page itself represents a Web page on the site.

l Sites. A Site is a collection of pages. l Page Templates. Templates are pre-defined pages or page fragments. A developer or

system administrator can create page templates for the rapid development of pages in a site. For example, it is useful to create a template containing the C-clamp used on every page in a site. Then page editors who create new pages can create the page using this template, and inherit the C-clamp with no additional effort. Updates to templates can be applied to the pages that use the template.

Within TeamSite, SitePublisher stores all of the above constructs as XML files and associated metadata. The pages authored through SitePublisher can be deployed to the runtime engine (LiveSite), where they are rendered dynamically, or if the site is entirely static in nature, the site can be generated and then the static pages can be deployed.

SitePublisher also supports Site Maps. A site map is a hierarchical structure of nodes that lets you set and represent navigation-specific information about your site. SitePublisher pages and external URLs can be referenced in a site map.


Chapter 2 Authoring


TargetingTargeting is an add-on module that works with TeamSite SitePublisher and the LiveSite Content Services Authoring service. Using Targeting, you can target content and offers to specific customers, resulting in a more relevant, contextual online experience. Targeting gives you the ability to tailor a visitor’s Web site experience. This includes showing custom content and navigational flow. All of this is intended to drive better user experience and increased attach rates to your site.

SitePublisher uses two mechanisms for Targeting: segmentation and targeted content. Segmentation categorizes visitors into customer segments. Customer segments are used to divide your customers or site visitors into groups of individuals or segments that have similar attributes, such as age, gender, and site activity. A segment can also consist of customers with similar Web site activity, for example geographic location, demographics, spending habits, or psychographics. Each segment can have either a shared or unique navigation structure, using the Site Map. For more information about site maps, refer to the TeamSite SitePublisher User’s Guide.

Segment-specific navigation is achieved using segment-specific site maps, which allow visitors matching a segment definition to experience a different page flow, or totally different pages, than a visitor who matches a different segment or does not match any segment. For example, you can filter out areas of the site that are irrelevant to a visitor that belongs to a given segment (visitors in a certain cell phone plan segment would only see

Chapter 2 Authoring

phones available for that plan). Targeted content allows you to show specific data (for example, documents, images, links) based on segment and also on additional visitor attributes.

Both segments and content targeting are driven by rules. The rules are defined as XML and stored as regular files in the TeamSite server. As part of the publishing process, the rules are then deployed into a runtime engine that evaluates the rules and delivers targeted content.

A rule is composed of Conditions (including various system and user-input Values) as well as Actions. A typical rule execution process would involve the evaluation of a condition and based on the result an appropriate action would be executed. There are a number of condition and actions that are defined out of the box. It is also possible to customize the rules engine by defining and adding more conditions and action types. This is done by writing XML-based verbalizations.

PreviewPrior to deploying any authored content, users would like to preview their changes. TeamSite supports the ability to preview static content authored in FormsPublisher as well as the more dynamic Web pages authored in SitePublisher.

TeamSite has a bundled HTTP server called iwWebd and a proxy server called iwproxy. Both of these processes work in conjunction to allow preview of static Web pages. Any HTTP access to the TeamSite server is first intercepted by iwWebd and then is processed according to rules defined in the server configuration file. Using proxy remap rules (which are basically regular expression strings), URLs can be redirected to content located in TeamSite branches and workareas. For more details on remap rules, refer to the TeamSite Administration Guide.

Preview of SitePublisher pages, which are inherently more dynamic in nature, is supported by running an instance of LiveSite in the authoring environment. The preview instance of LiveSite is invoked any time a SitePublisher page is accessed.

The preview instance is also used to power the in-context editing capabilities of TeamSite. Instead of having to edit content by browsing the file system and locating the content item, users can start from the presentation of the content (on a SitePublisher page) and then edit the content in place. It is mapped back to the correct content item in the TeamSite system. This makes the interface friendly and intuitive.


Chapter 2 Authoring


Chapter 3 Publishing

Chapter 3

Publishing

This section describes the OpenText TeamSite publishing process. It includes the following topic: l Publish with OpenDeploy

Publish with OpenDeployUsing OpenDeploy, content is sent from the Content Management System to the server(s) in the live environment. OpenDeploy allows you to create a transactional, secure distribution of content (or any other files) to an arbitrary number of servers in a portal, intranet, or Internet setup.

OpenDeploy publishes content (CMS content, file system content, application code, etc.) incremental, encrypted (up to 168-bit SSL), and transactional. Both multi-tier and fan-out deployments can be defined as a transaction, and can be rolled back. OpenDeploy can be fully automated and can be integrated into TeamSite workflows.

OpenDeploy consists of a suite of interlocking services that create the OpenDeploy environment. Within the OpenDeploy environment are the following components: l Base server software. Enables the OpenDeploy server to start deployments to other

servers, as well as to receive files deployed from other OpenDeploy servers. l Receiver software. Enables the OpenDeploy server only to receive deployed files l Administration package. Manages the following OpenDeploy functions:

n Generation of browser-based user interface. n Reporting through the reporting server. n Access to OpenDeploy servers, features, and functions, based on user and

administration roles.

The OpenDeploy source server processes deployment configurations or scenarios. These configurations determine the type of deployment being performed as well as what other functions and features OpenDeploy performs in the course of the deployment. The deployment configuration also specifies which target servers receive the deployed files. These configuration allow for a reproducible deployment and can be administered using the Web-based OpenDeploy GUI.


Chapter 3 Publishing


Chapter 4 Runtime

Chapter 4

Runtime

This section describes the OpenText TeamSite runtime solution. It includes the following topics: l LiveSite l LiveSite Content Services l LiveSite Display Services

LiveSiteThe OpenText TeamSite runtime solution is powered by the LiveSite product. LiveSite supports content access through REST-based services, delivery of targeted content and the dynamic rendering of pages authored in the development environment.

LiveSite can be divided into two categories:

LiveSite Content Service. The content repository for LiveSite. LiveSite Content Services provides a REST-based API, through which content can be retrieved by ID, path or a metadata search.

LiveSite Display Services. The dynamic page-rendering engine. Static or dynamic pages that are authored in SitePublisher are processed by LiveSite Display Services and rendered in the browser. LiveSite Display Services supports caching at a page and component level to increase performance and scalability.


Chapter 4 Runtime


LiveSite Content ServicesLiveSite Content Services is a flexible metadata plus content repository and a rules engine. It supports the efficient storage and retrieval of content assets, and rules execution through REST APIs. The content items can be accessed through named paths or IDs. LiveSite Content Services integrates with SolrCloud and supports search. Assets can be searched by metadata or full text content.

Content items can be associated with an arbitrary number of metadata items in the form of key-value pair. There is no fixed schema to the repository. This flexibility can be used to create new content types by specifying different metadata. No complex schema upgrade is necessary.

Content assets can be grouped into a logical collection called Projects. Each project is an independent logical entity. One way to use projects is to map all content associated with a site to a project. In most scenarios, projects have a one-to-one mapping with TeamSite branches. Content is deployed into LiveSite Content Services through a publish process from TeamSite. LiveSite Content Services also supports deployment from other external sources. There is a published format in which content can be created and then imported into the engine.

Content is deployed into LiveSite Content Services in two phases. The first phase of the deployment is an import process. In this phase, content is added to the repository and the search indexes are updated. The second stage of the import can either be a commit or a

Chapter 4 Runtime

rollback. A commit ensures that the new content is committed and available for consumption whereas a rollback removes the new content. While the content is being deployed, ongoing requests are still serviced and users do not see any of the new content unless it is committed. This functionality is supported because the engine implements a form of the “multi-version concurrency control” pattern.

The two-phase commit feature enables users to set up transactional deployments across multiple data centers hosting LiveSite. Content is first staged across all the different data centers using OpenDeploy’s farm-out deployment and when that deployment is successful, it is committed at the different data centers. The LiveSite Content Services engine supports an eventually consistent model, where there might be a brief period of time where multiple data centers do not show the same content. Eventually, however, all the data centers will have the same data, either the newly committed content or the previous version of the content.

In a distributed environment, out of consistency, availability and partition-tolerance, only two can be achieved. LiveSite Content Services does not impose any restrictions on the choice and it is up to the solution implementer to determine what their preference is.

Rules Engine

The OpenText TeamSite rules execution engine is part of LiveSite Content Services. Rules, which are authored in SitePublisher/TeamSite, are stored in the LiveSite Content Services repository as XML.


Chapter 4 Runtime


Rules are invoked using the REST API. A typical rule invocation involves asking the engine for the input values it needs (for example, it may reply that the rule needs to know the age of the user), building the rule input as XML, invoking the rule engine execute function with the rule input, and processing the engine’s XML result. The output of a rule is a list of Action elements. There are a set of actions defined out of the box, such as content retrieval. In addition to the out-of-the-box actions, it is also possible for customers to define their own actions.

LiveSite Display ServicesLiveSite Display Services is the page rendering engine of LiveSite. Pages, generated by SitePublisher in the authoring environment, are processed by the runtime engine and browser-consumable pages are generated.

Documents

OpenText TeamSite 16.4 Architecture Guide