1 / 29

Integrating a Portal with a Content Management System

Integrating a Portal with a Content Management System. A case study using uPortal and eContent Katya Sadovsky University of California, Irvine katya@uci.edu. Overview.

sherrard
Download Presentation

Integrating a Portal with a Content Management System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Integrating a Portal with a Content Management System A case study using uPortal and eContent Katya Sadovsky University of California, Irvine katya@uci.edu

  2. Overview • Identify issues/questions we have encountered while planning the integration of uPortal with a Content Management System (CMS) • Possible solutions to these issues • Audience: institutions that have not yet looked at or are in the early stages of Portal+CMS integration

  3. Agenda • What is UC Irvine’s SNAP • Why we need a Content Management System • What we are trying to accomplish • What we have accomplished • Issues with CMS & portal integration and solution ideas • Q&A

  4. What is UC Irvine’s SNAP? • SNAP = Simple Navigational Administrative Portal • Objective: implement a Business Portal that “serves as the entry point for UC staff to access information, tools and training necessary to do their jobs” (UC 2010 New Business Architecture (NBA) initiative)

  5. Why we need CMS • Web based environment for subject matter experts to publish content • Distributed content management • Content version tracking • Access rights management (view, edit, etc.) • Edit mode lock/unlock

  6. What we are trying to accomplish • Seamless integration of uPortal and CMS: • Use uPortal as an entry point for content providers • Content providers should be able to access content editing with a button click

  7. An ideal process flow

  8. What we have accomplished • When SNAP user logs in, system retrieves a list of “editable” content resource ids • Each channel’s URL parameter is matched to a pattern URL to determine if it resides in eContent CMS (developed by jCorporate) • If channel’s content resides in eContent, SNAP adds an ‘Edit Content’ button to channel’s controls

  9. “Loosely Coupled”Portal & CMS Integration Case Study Using uPortal & eContent: Issues, Challenges, and Potential Solutions

  10. Portal & CMS Integration: Problem Areas • Authentication • Access rights: channels vs. content • Publishing/deleting content vs. channels • Creating a link to a channel • Creating a list of editable content resource ids • Flexibility/”Pluggability” of CMS code • Rendering • Search

  11. Authentication • Issue • Using backend URLs: session cookies and other authentication parameters are not passed along to CMS

  12. Authentication • Possible Solutions • Creating custom URL connection objects that pass along authentication information • Using SOAP-enabled interface to retrieve content (SOAP=Simple Object Access Protocol, used in Web Services) • Surface only world-viewable content in the portal (not passing any authentication parameters to CMS)

  13. Access Rights • Issue • Both CMS and portal have authorization facilities. • Do they need to be synchronized? • How can they be synchronized?

  14. Access Rights • Possible Solutions • Give everyone viewing rights to content and let portal channels manage authorization – content may still be viewed over a direct URL • Let CMS manage access rights – requires a meaningful message inside of a channel to let users know what is going on • Customize/configure portal & CMS to use the same authorization store (e.g. LDAP)

  15. Channels vs. Content Resources • Issues • What is the relationship between channels and content resources? • How do we map channels to content resources? • How do content/channel publishers reconcile the two ids?

  16. Channels vs. Content Resources • Possible Solutions • Store resource id as an attribute of a channel (or vice versa) • Create a mapping of content resources to channels (possibly, as a separate database table) • Rely on user training

  17. Publishing/deleting content vs. channels • Issues • How do content developers publish/delete content as opposed to channels? • Does deleting a channel delete its content as well?

  18. Publishing/deleting content vs. channels • Possible Solutions • Ideally, publishing/deleting functions could be tightly coupled in CMS and portal by using wizards or pre-defined worklflows • Currently, we have separate interfaces (URLs) for content developers to manage content and channels – content developers have to be trained to know content URLs when they publish channels

  19. Creating a list of editable content resource ids • Issue • Portal needs to know which content resource ids a user is allowed to edit

  20. Creating a list of editable content resource ids • Possible Solutions • Write a custom servlet that generates the necessary listing • Get the list via a Web Service: either create a custom Web Service or request one from the CMS vendor • Use a central authorization repository, such as LDAP

  21. CMS Flexibility/”Pluggability” • Issues • How easy is it to add custom functionality to a CMS? • How easy is it to send user to an edit mode with a click of a button from the portal?

  22. CMS Flexibility/”Pluggability” • What we found useful: • A system designed based on the Model-View-Controller architecture • Hence, ability to create custom “views” • Having a nice set of API's to extend

  23. Rendering • Issue • Which software package should render content: portal or CMS?

  24. Rendering • Ideas • Portal channels do the rendering • Pros: all rendering functions are contained within the portal • Cons: need to catch access-denied situations • CMS does the rendering (in the case of uPortal, use CWebProxy channel) • Pros: CMS itself will handle access-denied situations and present an error message • Cons: need to pass request information (e.g. browser info) from the portal to CMS

  25. Search • Issues • Which software is used to search: portal, CMS, or a third-party search package? • What URLs are indexed: channels or content resources in CMS? • What is the starting point for the search engine? • How are access rights taken into account when search results are displayed?

  26. Search • Ideas • Use an internal portal search channel – index portal channels • Use internal CMS search capabilities – index content resources inside of CMS • Use a third-party search engine – create a starting point that lists links to all content (channels or CMS resources)

  27. Summary • Loosely coupled integration • Adequate functionality attained at the expense of ease of use • Resource-intensive in both programming and coordination/planning

  28. Links • This presentation - http://quasar.adcom.uci.edu/Portal/Integrating-uPortal-eContent.ppt • SNAP - http://snap.uci.edu • UC New Business Architecture - http://uc2010.ucsd.edu/index1204.htm • UC Irvine’s portal docs - http://quasar.adcom.uci.edu/Portal/ • Functional Requirements - http://quasar.adcom.uci.edu/Portal/CMSUserStoryBook.html • CMS minimal customization required - http://quasar.adcom.uci.edu/Portal/CMS.html • CMS evaluation docs - http://quasar.adcom.uci.edu/Portal/contentManagementToolsEval.html • XML editor evaluation matrix - http://quasar.adcom.uci.edu/Portal/XmlEditorEval.xls

  29. Q & A

More Related