Related
Recommended

Portal Integration Scenarios and Considerations

Miguel Miguelez

The focus of this document is to discuss the delivery aspect of SDL Tridion, specifically to deploying content to portals. First, we will outline general integration principles around the Web Services that is true for all Portal deployments. We will then outline three portal deployment scenarios, discuss the pros and cons of each, and address typical portal integration concerns. Ultimately, the decision as to which is best will be based on specific business needs of the customer.

Goal/reasons for using a portal:

  • Ease of use of portal functionality for business users.
  • Single delivery environment for all sites and applications to reduce maintenance.
  • Leverage "portal" capabilities including social collaboration, access control/single sign-on, self-personalization.
  • Leverage existing portal applications for transactions.

Portal integration background:

SDL Tridion systems operate as a decoupled architecture.  This enables our customers to manage SDL Tridion protected behind security layers (i.e. firewalls) while providing the flexibility to deploy their managed content in different formats (i.e. HTML, XML) to multiple channels (websites, mobile, email, print) in any language.
The focus of this document is to discuss the delivery aspect of SDL Tridion, specifically to deploying content to portals.  First, we will outline general integration principles around the Web Services that is true for all Portal deployments.  We will then outline three portal deployment scenarios, discuss the pros and cons of each, and address typical portal integration concerns.  Ultimately, the decision as to which is best will be based on specific business needs of the customer.
The three scenarios are as follows:

  1. One (1) Portlet consuming SDL Tridion Page
  2. Multiple (n) Portlets consuming SDL Tridion Page
  3. Multiple (n) Portlets consuming SDL Tridion Content (no pages)

General Portal Integration Principles

  • SDL Tridion Content Manager is the single source of Content.
  • SDL Tridion publishes Content to standard Content Delivery repository.
  • Portal requests Pages and Content from Content Delivery application (J2EE or .NET) through SDL Tridion Web Services.
  • Preview is available through Staging Portal environment.
  • BluePrinting of content is fully supported as with any delivery environment.
  • Transactional functionality is supported across all Portal integrations.

Scenario 1: One Portlet consuming SDL Tridion Page

Scenario overview:

Used for pages/sites that need to deploy content through a Portal but do not need transactional behavior between SDL Tridion content.  This solution provides the ability the use other Portlets outside the scope of SDL Tridion (i.e. Calendars, wikis, etc).  The Portal maintains a single Portlet per page in which to deliver SDL Tridion content.

Points:

  • Page is fully constructed and managed in SDL Tridion.
  • A single Page in the Portlet can refer to n Pages in SDL Tridion, acting as a container.
  • Pages deployed as HTML/JSP/.NET.
  • Business users manage all content in SDL Tridion.
  • SiteEdit is fully available for content creation, content editing and drag-and-drop in context within the Page.
  • Navigation is recommended to be managed in SDL Tridion.  Example is to publish managed navigation to XML for Portal to render.
  • Portal can use other portlets surrounding the SDL Tridion portlet (unrelated to SDL Tridion).
  • Linking is handled by SDL Tridion.
  • Single Web Service request per Portal Page.

Pros:

  • Business users can modify content and pages in the context of the entire page.
  • Easy maintenance, ALL content management tasks are handled completely in SDL Tridion
  • Full SiteEdit capabilities (create, edit, drag-and-drop).
  • Can leverage other Portal widgets.
  • Supports transactional and inter-portlet behavior.
  • Single Web Service request per Portal page.
  • High performance due to single request per Page.

Cons:

  • Only one content-managed portlet on the page.

Scenario 2: Multiple Portlets consuming SDL Tridion Page

Scenario overview:
Portal pages will contain multiple portlets that will render SDL Tridion managed content and may require inter-portlet communication. This solution suggests a "metapage" managed within SDL Tridion that contains all the component presentation elements on a particular Portal page, while the Portal maintains multiple Portlets requesting the content elements from the "metapage".
Points

  • Page is used as content assembly object to maintain all the SDL Tridion component presentations that will be used on a particular Portal Page.
  • Pages are created in a 1:1 ratio in SDL Tridion and Portal. When Pages are created, SDL Tridion can be implemented to automatically create Pages in Portal Server (through Portal Server Web Service).
  • Pages deployed as XML or HTML snippets.
  • Portal Server governs the distribution of content to its portlets.
  • Business users manage all content in SDL Tridion.
  • SiteEdit is available only for Content Editing. The Portal Server controls where on the Page the component presentation elements render.
  • Navigation can be managed by SDL Tridion or defined by Portal.
  • Enabling Portal linking may require an extension of SDL Tridion standard linking.
  • Single Web Service request per Portal Page.

Pros:

  • Provides SiteEdit capabilities (create content, edit content).
  • Recommended for portal pages containing multiple content-managed portlets.
  • Supports transactional and inter-portlet behavior.
  • High performance due to single request per Page.

Cons:

  • Portal controls the page, so need to use two systems (no drag-and-drop in SiteEdit).

Pros & Cons Outline Chart