Implementation of new

Enterprise-Class Portal

Features for Liferay

Alistair Oldfield Project Manager

Case Study: CSOB

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 and 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

ČSOB Group, Member of KBC Group

Č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

Program 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

Presentation 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

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.

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

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

New Features for Liferay

Challenge

Implementation of features new to Liferay - without

modifying Liferay core thus maintaining support from

Liferay:

1. Legacy Links Management

2. Reference Management

3. Link Integrity Management

4. Monitoring Portlet

5. Google Analytics Framework

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)

Link Redirection in Action

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

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)

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?

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

Implementation Challenges

Performance Challenges:

1. How to query references quickly, even on non-indexed

(optimized) data?

2. How to reference “non-structured” data (HTML, text,

properties) which are not stored in relational format?

3. How to do this without modifying Liferay core API or

services?

Solution:

Create a separate DB

schema for indexing data in

a normalized format.

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…

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.

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.

Link Integrity Management broken-links

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?

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

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

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?

Monitoring Portlet

Solution:

Create a control panel

Monitoring Portlet which invokes

back-ends from the portal to

check for resource availability

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

Google Analytics framework

Challenge:

After migration of legacy site, we were faced

with the challenge of fully integrating legacy

mark-up with Google Analytics.

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

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.

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

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

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

Thank you for your attention

For questions about this case study please contact:

CSOB

www.csob.cz Petr Černohorský

pcernohorsky@csob.cz

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