Portal Integration Scenarios and Considerations

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)

 

Portal Integration - General

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.

 

Portal Integration - Scenario 1

 

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).

Portal Integration - Scenario 2

Scenario 3: Multiple Portlets consuming SDL Tridion Content (no pages)

Scenario overview:
Similar to Scenario 2, Portal pages will contain multiple portlets that will render SDL Tridion managed content, but instead of accessing a "metapage" for the content, the Portlets will request the content directly through Web Services.

Points:
  • Pages are only managed in Portal server.
  • Business users will have no context while creating new content.
  • Component presentations are directly retrieved through Web Services, not through a SDL Tridion Page.
  • Content requires custom metadata that is the lynchpin for reference by the Portlets.
  • SiteEdit would require customization.
  • Navigation can be managed by SDL Tridion or defined by Portal.
  • Enabling Portal linking may require an extension of SDL Tridion standard linking.
  • Multiple Web Service requests per Portal Page.
Pros:
  • Pages only defined in Portal.
  • Gives flexibility to Portal control.
Cons:
  • Pages only defined in Portal, so Business users have no context when creating new content in SDL Tridion.
  • SiteEdit functionality would require customization.
  • Content must be tagged with metadata or taxonomy keywords so it can be "found" by portlets.
  • Ongoing management is more complex, requiring well-trained business users to maintain.
  • Performance may be impacted as requests would increase.

Portal Integration - Scenario 3

Pros & Cons Outline Chart

 Portal Integration - Pros & Cons chart

About the Author
Greg Lowenthal
Senior Solutions Engineer

Greg Lowenthal is a Senior Solutions Engineer and is based in New York. 

He has been working with SDL Tridion since the beginning of 2011 and has been working in the WCM and surrounding space for over 8 years.

About the Author
Miguel Miguelez
Senior Technical Consultant

Miguel Miguelez is a SDL Tridion Senior Technical Consultant within SDL's Web Content Management Solutions Division (based in New York)
He has worked in different areas of the IT Industry since 1998. He started working in SDL Tridion in 2005.
Miguel Holds a Master's Degree in Physics and a Post Graduate in Information Technology.