2012.10 Oldfield
-
Upload
emeldi-group -
Category
Technology
-
view
41 -
download
0
Transcript of 2012.10 Oldfield
Approach and execution of migrating
an MS SharePoint site into Liferay
Alistair Oldfield – Emeldi Group - Official Liferay Partner
September 2012
A How-To Guide
Agenda
• Introduction• Summarize topic: Approach and execution of migrating an MS SharePoint
site into Liferay
• Description of Environment
• Illustrate some of the challenges
• Migration of a SharePoint site to Liferay• Migration of content
• Migration of functionality (Web parts -> Portlets)
• Evaluation of realized benefits• Automated
• Repeatable
• Re-Useable
Approach and execution of migrating an MS
SharePoint site into Liferay
SharePoint 2007
.NET
Web Parts
Liferay 6.0Java
Portlets
Source Environment
• Legacy Portal: Microsoft SharePoint 2007
– Roughly 50 web-part applications (.NET) • Highly customized behaviour
• Integrated to back-ends and other services (Google Maps, etc.)
– Thousands of pages, articles & documents
• Objective: The existing content must be integrated
(iframe, proxy portlet) with or migrated in the new Liferay
portal solution.
• Decision: Completely decommission legacy portal and
fully migrate (port) content and functionality into Liferay.
Different Technologies & Concepts
Many different approaches to dealing with various concepts
Cannot migrate “ALL” data kept within a MOSS database• Not necessary
• MOSS data doesn’t always map into Liferay concepts
Focus on what’s important for a site:• Pages & site map
• Layouts
• Articles / Content
• Documents
• Images
• Theme / style
• Web Parts
Requirements1-to-1 migration of a SharePoint site from visitor’s point of
view
Automated Migration• Huge site with 1000s of pages, manual content migration not viable option
Repeatable Migration• Repeated across DEV, ACC, PROD
• Can redo in case of we need to fix something
Re-useable• To be re-used for other MOSS-driven portals in other migration projects
Offline• Snap shot of MOSS DB can be stored in an export package which can be then used
as repeated input to imports at a later time
Approach
Requirements can be satisfied using an export/import
approach:
•Web Part attributes
•CMS
•Libraries
Inspect MOSS
•XML schema
•Export
•Content
•images & documents
Export data into package
Liferay Services &
API
Import to Liferay
Migration OverviewMigration of Content
• Full export of MOSS content
into XML package
• Implementation of importer
application using Liferay
services
Migration of Functionality
• Complete re-implementation
of .NET Web Part
applications to JSR-286
compliant portlets
Migration of Content - LayoutsMOSS Web Part Page• Page
• Layout
• Custom data (per page)
• Web Part Zones
• Web Parts
Liferay Portlet Page• Page
• Custom Fields (common for
all pages)
Liferay Layout• Layout (including drop
zones)
• Portlets
MOSS Content Structure
• Webs/sub-webs
• Default Page/Pages• Layout
• Content Type
• Web Parts
• Libraries
Implement Liferay “Importers”
1. LibraryImporter
2. WebImporter
3. PageImporter
4. LayoutImporter
5. WebPartImporter
Web
Default Page
Pages
LayoutContent
TypeWeb Parts
Web Libraries
Documents Images Lists Other Libs
How MOSS export/import worksExport MOSS into an export package:
Inspection application traverses MOSS structure and exports data to an XML &
media files into a ZIP package (also indexed in XML)
Each XML element is mapped to an importer class
Ex: <page> -> com.emeldi.moss.liferay.PageImporter
Import the export package into Liferay:
1) First Pass: Import libraries using Liferay API• Documents into Liferay Document Library
• Images into Liferay Image Gallery
• Remember URLs of all imported docs/images (needed later)
2) Second Pass: Depth-first recursion through
exported elements:• Invoke corresponding “importer” classes
Site is built from the bottom-up
• Child elements (webs, pages, etc.) first
• Parent elements last
WebImporter
Depth-first recursion through
exported elements:1. Invoke page importer for <default-page> element for
that web (next slide)
2. Recurse until leaf web is encountered
3. Invoke page importer for all <page> elements within
that web (next slide)
4. Return up the stack until root web is imported
PageImporter1. Using Liferay API create the page
2. From exported MOSS page data (from content-type, etc.) assign:• Title
• URL
• Custom fields
• Meta data
• Etc..
3. Remember the page URL for later
4. Based on exported MOSS page layout data, perform a look-up against a
Layout Importer mapping and invoke the resolved LayoutImporter (next slide)
Page
LayoutContent
TypeWeb Parts
• Layout X ImporterLayout X
• Layout Y ImporterLayout Y
• Layout Z ImporterLayout Z
LayoutImporters1. Specialized Importers based on a given page layout
2. assigns layouts to a page• Target Liferay layouts must be manually created prior to migration
• Approximations of MOSS layouts
• Similar MOSS layouts can use the same Liferay LayoutImporter
• WebPart X ImporterWebPart X
• WebPart Y ImporterWebPart Y
• WebPart Z ImporterWebPart Z
2. Identifies the MOSS web content and Web
Parts which are located in each drop zone.
3. For each drop zone:• performs a look-up against a Webpart Importer mapping
• places the corresponding Liferay portlet into the drop zone
(next slide)
• invokes the resolved WebPartImporter (next slide)
WebPartImporters1. Specialized Importers based on a given MOSS Web Part or web content
2. Each MOSS webpart must have a corresponding Liferay portlet (JSR
168/286) implemented prior to migration (java approximation):• MOSS Web content Liferay Web Content Display Portlet
• MOSS custom FAQ Web Part Custom implemented FAQ portlet
• etc..
Example 1) Importing of an FAQ Web Part:• MOSS inspection application knows which FAQ Web Part data is necessary to export
and exports it into XML package
• FAQImporter knows how to read this data and insert it into the target application
database and portlet preferences
• FAQ Display Portlet is created and placed into the Layout drop zone
Example 2) Importing of web content (administered HTML markup):• MOSS inspection application exports HTML markup
• Markup is filtered/re-written (next slide)
• WebContentImporter creates a journal article with filtered markup
• Web Content Display Portlet is created then placed into the Layout drop zone
Markup Filtering/Re-writing• Remember the first pass (storing of library URLs)?
• Remember the storing of page URLs (on page create)?
Here is why:• All migrated MOSS markup still has links to legacy MOSS pages and media
(library files)
• These URLs no longer exist in Liferay - now imported into Liferay sitemap,
Document Library, and Image Gallery
• Markup must be re-written before inserted into Journal Article:
<a href=“/Web/Library/doc1.pdf” /> <a href=“/documents/12034/doc1.pdf” />
String transformations performed for: <a>, <img>, <javascript>,
<object> tags
ChallengesSharePoint List imports• No such feature in Liferay which captures same functionality
• List data transformed into:• Liferay native data (journal articles)
• Custom application data
Non-automated portions of the migration• Theme & Layouts
• Custom Portlet implementation (porting of .NET into Java)
Content Issues:• Legacy style support (may consider manual cleaning)
• URL re-writing
• HTML tidy • Remove MS bloat from MOSS markup
• & (HTML correction)
Summary
SharePoint inspection application exports all needed data
into XML and ZIP packages
Liferay Import application imports packages into LR using
both Liferay and custom APIs
Custom SharePoint Web Part applications must be ported
into Liferay-deployable portlet applications
Legacy SharePoint URLs must be re-written during import
Result
• Fully automated SharePoint-to-Liferay
Content Migrations – re-useable for other
installations/ projects
• Repeatable across all environment pillars
• Re-useable for future use in other
SharePoint-driven portals
Benefits to the Liferay Community• Migration from SharePoint to Liferay an often recurring question
for organizations considering a move to Liferay
• We have demonstrated that a re-usable tool exists which allows
for: • Fully automated content migrations (pages, images, content, etc.)
• Establishing a foundation for introducing ported custom applications from
.NET into Java
• Emeldi has now opened the path allowing organizations to
transition from legacy SharePoint applications into Liferay:• Economically
• Quickly
Project Reference
ČSOB:
Established in 1964
Diversified
bancassurance groupoffering complete
product portfolio to all client segments
Long-term leader in
many segments, esp.
financing of housing needs and mutual
funds
Active in the Czech Republic
Member of KBC Group
Slovakia
ČSOB
ČSOB
Poisťovňa
Czech Republic
ČSOB
ČSOB Pojišťovna Hungary
K&H Bank
K&H Insurance
Belgium
KBC Bank
KBC
Insurance
Bulgaria
CI BANK
DZI Insurance
About the Emeldi Group
• Emeldi is an official Liferay
service partner in the UK,
Czech Republic, & Slovakia
• e-Commerce / Self-Service /
best practices
• Specialized expert team -
Liferay hands-on experience
• Flexible development
process & methodologies
• Innovation is one of the key
differentiators
2
2
• Specialized in delivering
large-scale portal
solutions to Tier 1
enterprises
Thank youOpen for Q&A
Alistair Oldfield – Project Manager Emeldi Group – Official Liferay Partner