emeldi.com

1. April, 2012
1
Implementation of new Enterprise-Class
Portal Features for Liferay
Alistair Oldfield
Project Manager
Case Study: CSOB

2. Agenda
 The objective of this presentation is to:
 Summarize the goals & challenges of adopting portal
technology for use in an enterprise environment
 Illustrate some of the challenges in a case study of
implementation of portal platform in a bank
 Project Goals
 Challenges encountered on the way
 Implementation of features new to Liferay - without modifying
Liferay core (maintaining support from Liferay)
 Summary of realized benefits & lessons learned
2

3. Customer Background
3

4. ČSOB Group, Member of KBC Group
4
ČSOB:
Established in 1964
Diversified
bancassurance group
offering 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

5. Project Background
 Business transformation to:
 Transform into a customer-centric organization
 Simplicity and convenience through multi channel access and
cross channel distribution
 Extend the service offering
 Shorten time to market by introducing innovative approach to the
new services implementation
 Liferay was chosen as the portal standard
technology
 State-of-the-art in front-end layer and rich on features
 Easy integration with J2EE, group development standard
 Optimal fit into landscape and total cost of ownership
5

6. Project Overview
1. Migration from Legacy Portal to Liferay
2. Implementation of new Enterprise
Features for Liferay
• Legacy Links Management
• Reference Management
• Link Integrity Management
• Monitoring Portlet
• Google Analytics Framework
6

7. Migration from Existing Portal
 Legacy Portal: Microsoft SharePoint
 Roughly 50 web-part applications (.NET)
 highly customized behaviour
 Integrated to bank 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.
7

8. Migration from SharePoint to Liferay
approach
 Migration 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 webpart applications to
JSR-286 compliant portlets
8

9. Migration from SharePoint to Liferay
Result
 Fully automated SharePoint-to-
Liferay Content Migrations
 Repeatable across all environment
pillars
 Re-useable for future use in other
SharePoint-driven portals
9

10. New Features for Liferay
Challenge
 Implementation of features new to Liferay - without
modifying Liferay core thus maintaining support from
Liferay:
10
1. Legacy Links Management
2. Reference Management
3. Link Integrity Management
4. Monitoring Portlet
5. Google Analytics Framework

11. Legacy Links Management
Challenge:
 Allow to specify rules for resolving legacy addresses (or patterns) to
new Liferay site
 Must be administrate-able in real-time by business users in control
panel (not on the web server level i.e. using mod rewrite)
 Must potentially apply rules to ANY incoming request to portal
Solution:
 Creation of Request re-direction framework
 Rules may be defined as follows:
 Literal strings: /products/people/mortgage.aspx -> mortgage/calculator.aspx
 Pattern matched: /products/people/.*?{<args>.*) -> products/form.aspx?{args}
 May be configured as:
 PRE filter (before requests gets to Liferay)
 POST filter (after request gets to Liferay, and Liferay cannot resolve URL)
11

12. Link Redirection in Action
12
1. Before sending request to
Liferay, resolve against PRE
redirection rules, if a rule is
applied, then redirect.
2. Otherwise: Send request
to Liferay, if Liferay finds the
requested page, then return
contents (as normal).
3. If Liferay cannot find the
URL, resolve against POST
redirection rules, if a rule is
applied, then redirect.
4. If no rules applied: return
404 – page not found (as
normal).

13. Benefits
1. Maintain Legacy link integrity (incoming links which
existed years ago, can still point to a desired page)
2. Business users can define any URL(or set of URLs) to
point to any page or resource in portal (SEO benefits);
usually a task reserved for application server
administrators.
3. Business users can “alter” URLs of pages without
altering site structure
4. Business users can use patterns to define redirection
rules for large sets of URLs (e.g. /people/.* -> /people.aspx)
13

14. Reference Management
There are many entities in a Liferay portal, however
relationships and references between these entities is not
always clear:
 Which other articles/pages in my portal have links to a given page?
 Which articles/pages hold references to a given document?
 Which pages contain a given portlet?
Not knowing these references poses administrative
challenges to site integrity, and administrative productivity in
general:
When I delete a document, how do I know I haven’t created 100s of
broken links throughout my portal?
14

15. Reference Management
To overcome these challenges, a reference management
framework was developed.
This framework allows for defining of any reference
between any 2 entities in the Liferay data model as a 1-n
listing:
• For a given URL, list all articles which reference it
• For a given portlet, list all pages which contain it
• For a given search text, list all articles or pages which contain it
• For a given portlet property, list all portlets which define it
• …
Framework defines the reference (how it is modeled as a
query), and provides a UI for listing the references
15

16. Implementation Challenges
Performance Challenges:
 How to query references quickly, even on non-indexed
(optimized) data?
 How to reference “non-structured” data (HTML, text,
properties) which are not stored in relational format?
 How to do this without modifying Liferay core API or
services?
16
Solution:
Create a separate DB
schema for indexing data in
a normalized format.

17. Implementation Solution
Each DB operation (create/update/delete) which takes place on a table
which contains “referenced” data fires a trigger to copy the data change
into the indexing schema
Indexing schema proceeds to index the data into a well-defined
relational data model using pre-defined functions (e.g.):
• Portlet preferences XML-> relational (DB) format
• HTML -> Stripped text throughout site / list of links throughout site
• etc…
17
Performance impact not an issue;
data copy is tiny (one row) and is
only executed on rare operations
(administration actions) into a
different schema:
no impact to Liferay.

18. Benefits
1. Significant increase to web content administrators’
productivity when executing changes to the site
2. Ease of use; provides a full overview of how and where
a change will be propagated throughout the site; info which
is currently not so clear to administrators
3. Highly extensible framework which allows for many
interesting features not currently available on Liferay (all
without any core modifications):
• Automated portal-wide link updating: automatically maintain
link integrity throughout your site when moving or deleting
pages/resources
• Link Integrity Management (Broken Links): next slides.
18

19. Link Integrity Management
broken-links
19
With 1000s of pages and articles containing internal and
external links, ensuring the complete absence of broken-
links throughout the portal is a daunting challenge:
Challenges:
•How to ensure the site is entirely
broken-links-free?
•How to handle when an link
pointing to an external sites?
•How to locate existing broken-
links so they may be fixed?

20. Link Integrity Management (2)
broken-links
Solution: Broken Links Reporting Portlet
Leverage data stored by Reference Management (previous
slides) to quickly retrieve a list of all links within the site (all
are now indexed)
Implement a simple administration portlet which checks
links (send requests and checks for 404, etc…) and
provides a report:
• Which link failed
• Which pages contain these failed links
• Response codes returned from all links
20

21. Benefits
1. Ensures your site remains impervious to both internally
and externally pointing broken-links
2. Quickly detects and locates which pages and articles
contain broken links (in real-time) so they may be corrected
immediately
3. Provides comprehensive reports on the entire site’s link
integrity
4. Service can be configured to be run as a scheduled job
with configured warnings and notifications
21

22. Monitoring Portlet
With enterprise monitoring applications in place, operational staff are
able to quickly determine availability of resources within the integrated
architecture:
 Which databases are running
 Which back-ends are responding
 Memory usage is within tolerated thresholds
 etc…
However, there is a motivation to also make some monitoring data
quickly available to portal business users (even in some cases,
information which is not readily available to monitoring applications):
 Is connectivity to databases available from the portal?
 Is connectivity to back-ends available from the portal?
22

23. Monitoring Portlet
Solution:
 Create a control panel
Monitoring Portlet which invokes
back-ends from the portal to
check for resource availability
23
Benefits:
1. Assures and reports on network availability and
response times of all external resources to portal
2. Enables for rapid trouble shooting of potential
backend outages or unavailability to portal

24. Google Analytics
framework
Challenge:
 After migration of legacy site, we were faced
with the challenge of fully integrating legacy
mark-up with Google Analytics.
24
Requirement was to provide technically-capable
business users the ability to track clicks & events on
the site
With 1000s of pages & articles, direct editing of
article mark-up was not a viable option:
•too many existing pages to alter
•too difficult to manage in future
•too messy of a solution

25. Google Analytics (2)
framework
Solution:
4-tier architecture: create an additional “virtual tier” – the
Analytics Layer – which sits on top of the presentation layer
to handle injecting all analytics mark-up
Uses jQuery to alter the mark-up after the page is
rendered and “wraps” with Google Analytics code.
25

26. Google Analytics (3)
framework
Framework allows for injections of pre-defined Google
Analytics code snippets anywhere into mark-up (event
tracks)
Very loose coupling between Presentation Layer and
Analytics Layer
Benefits:
1. Easy for business users to define, manage, and propagate new
tracking events throughout site in one place.
2. Framework maintains a centralized, easily extendible library of
snippets, allowing for re-use without complete site mark-up re-factoring
26

27. Summary (1)
Migration from SharePoint
Having entered into Gartner’s magic quadrant, Liferay has
proven itself as a viable alternative product for enterprise
portals
Migration from SharePoint has reinforced this notion and
also demonstrated Liferay as a viable option for replacing
old, legacy portal solutions
Liferay offers a similar set of functionality as found in other
commercial products on the market
With an automated and repeatable SharePoint-to-Liferay
migration engine, the potential exists for further applications
to be ported to Liferay
27

28. Summary (2)
creating the enterprise portal
While Liferay comes packaged with a wide range of useful
out-of-the-box functionality, no product can satisfy all
business requirements:
1. Legacy Links Management: complemented the motivation of migrating
from a legacy site by providing continuity to its existing online presence
2. Reference Management: mechanism for carrier-grade usability from the
business user perspective through facilitated navigation between portal entities
3. Link Integrity Management: Critical feature for any tier-1 portal
4. Monitoring Portlet: Additional layer of monitoring and simplified trouble
shooting of portal integration to a SOA environment
5. Google Analytics Framework: Allows to track events without having to
trawl through portal code and write any extra mark up
28

29. Thank you for your attention
For questions about this case study please contact:
Emeldi Group
Alistair Oldfield alistair.oldfield@emeldi.com
United Kingdom:
Emeldi Ltd, UK, http://www.emeldi.com
Czech Republic:
Emeldi Software Services s.r.o., http://www.emeldi.com
Emeldi Technologies s.r.o. http://www.emeldi.cz
Slovakia
Emeldi Software Service Slovakia s.r.o. http://www.emeldi.sk
29