The Forrester Wave report identifies that the proliferation of customer touchpoints, applications, and digital interactions demand a new technology architecture. Liferay’s newest release of its flagship product does just that and is aptly named the Liferay Digital Experience Platform (DXP). The DXP (What is a Digital Experience Platform?) lets you create and connect personalized digital experiences across web, mobile, and connected devices. With DXP, Liferay has provided a whole slew of new features to address business priorities and support customer campaigns, retention and loyalty, and digital transformation. You can read my favorite top 10 new features in Liferay DXP to learn more about these features. In this blog post, I have focused on the form-related capabilities of Liferay DXP, and identified the top 10 features of Liferay Forms.

1. Ease in publishing any form using the new Liferay Forms portlet

DXP has made it simple for Content Creators to create new forms on their sites. Publishing of the form on any of their sites is similar to publishing of web-content. Moreover, once the form is created and published on a site, the content creator or the business team can view the entries right in the form application. And, with the flexibility of exporting the form entries into spreadsheets, the new Liferay Forms application makes it easy for the business team to analyze the form entries. Details on how to setup a new form are available here.

2. Multi-Page Liferay Forms

The new Liferay Forms application supports multi-page forms providing the business team the flexibility to create complex forms that do not clutter up the presentation in one page. Adding a new page to the form is as simple as a click, launch the actions menu and click on ‘Add New Page’.

Figure 1: Add New Page to a Form

Step by Step instructions for creating multi-page forms can be found here.

3. Default Wizard Mode for easier navigation

With multiple pages option, the end user can get lost on where they are at during the form submission process. Liferay DXP has solved this problem by including a default wizard mode with multi-page form for easier navigation and providing user the visual cue on where they are at in the process.

Figure 2: Default Breadcrumb for a Multi-page, Form Wizard

4. Organize fields in advanced form layouts

Flexible form layouts make it easier for content creators to create a multi-column approach for fields in the forms which capitalizes on the real-estate available on the screen, and provides context clues for the end-users when they are filling out the forms. The form layouts are flexible and enable the content creators to use a mixed approach where each row can be broken down into different number of columns, while still ensuring a mobile responsive layout.

Figure 3: A complex form layout with variable number of fields per row

Details on how to setup the multi-column layouts can be found here.

5. Placeholder text and predefined values in form input fields

Providing placeholder text in form input fields brings down the errors that end-users will make during form entry, as you can give examples of “proper” values using placeholder text. Additionally, if a form field should have a default value, you can specify that too (this is designated as a predefined value).

Liferay DXP makes it easy for content creators to provide these placeholder values in the form input fields so as enhance the end-user experience and improve on the quality of form entries. You can find additional configuration details here.

Figure 4: A sample placeholder text

Note: There’s an important difference between Predefined Values and Placeholder Text. If a field is left untouched by the user, the predefined value will be submitted, while placeholder text is not submitted (it’s as if the user left the field blank).

6. Populating Select Fields with REST data providers

DXP makes it easy to integrate your forms with data options from external systems such as CRM, ERP, and others as long as that data is accessible via REST service calls. For example, Salesforce provides access to its different data entities via REST calls, and Liferay DXP provides an easy, no-coding mechanism for you to leverage such data in form select fields.

Figure 5: A Sample REST Data Provider

With easy to use menu options, a user can setup a data provider that can be reused in all the forms. Once the data provider is setup, DXP gives the user the option to source the data for the select fields from the data provider setup earlier. Step by step instructions for setup can be found here.

7. Field Visibility Control

Conditional visibility of fields based off values in other fields enables content creators to create an engaging and flexible form that goes beyond just the conventional web form. And to do this using just few clicks without relying on developers is icing on the cake. DXP has enhanced the forms application to provide the content creators the option of creating field visibility expressions to drive engagement. The field visibility expressions are flexible and provide multiple ways to define the visibility criteria, such as:

• between(FieldName,lower bound value, upper bound value): Check whether the entered value of the specified numeric field is between a lower and upper bound. If it is in the specified range, the field will appear on the form.
• equals(FieldName, value): Display your field only if the value entered into the specified field equals a specific numeric value (or if it equals the value of another field).
• sum(FieldName1, FieldName2, …): Add numeric fields together, usually for comparing to a given value using one of the operators covered below.
• min(value, FieldName1, FieldName2,…): Get the lowest numeric value in the list of parameters (you can use Field Names and/or values), usually for comparing to a given value using one of the operators below.
• contains(Field Name, value): Used to check a field for a specific string of text or the text entered in another field. The text value can be in the beginning, middle, or end of the field being checked.
• concat(Field Name, value): Concatenate a string of text with a given text value, usually used in constructing a larger expression.

Figure 6: A Sample Field Visibility Expression

Additional operators and instructions for setup of the field visibility control can be found here.

8. Strong field level validations

DXP provides the content creators to create robust field level validations for text input fields. This goes beyond just making fields required or optional. And since these validations are configurable by the content creators without relying on developers to implement, the turnaround for changing a validation is much faster for the content creator. Rules can be put in place to ensure that the entries have the values per the expectations of the content creators.

Figure 7: A Sample Field Validation

Comprehensive instructions for setting up the validations are available here.

9. Captcha in Liferay Forms

Enabling Captcha ensures that your web form does not get submissions from bots. DXP makes it easy to enable captcha for a form with a click of the option.

Figure 8: Enable Captcha in Form Settings Overlay

10. Liferay Forms Extensibility through Modular Design

With Liferay’s big push on OSGi with DXP, it is not a surprise that the form rendering, validation and field types are all OSGi modules. While the Forms application is a robust and feature rich portlet, there are always some business needs that are special enough that the out-of-the-box features don’t satisfy the requirements. With the modular architecture in place, Liferay DXP provides developers unparalleled extensibility to adapt the existing portlets for whatever business needs their companies may have.

Summary

Liferay DXP has made significant enhancements to create engaging experiences across all touchpoints, and provided the ability to gain valuable customer insights through a robust forms capability. As described above, Liferay DXP Forms come with strong out-of-the-box features and are extensible to do even more.

Additional Reading

You can also continue to explore Liferay DXP by checking out The Top 10 New Features in Liferay DXP 7 and Liferay DXP Audience Targeting 2.0 Overview from a functional perspective or Top 5 New Features in Liferay DXP UI Development and Creating JAX-RS REST Services in Liferay DXP from a development perspective.

If you liked what you read, please share this helpful post with your friends and co-workers on your favorite social media here:

The post Top 10 Features of Liferay Forms appeared first on XTIVIA.

Liferay DXP represents a massive evolutionary change in the basic nature of Liferay’s underlying platform, and as such, it presents a unique set of challenges and issues for organizations looking to migrate their old Liferay Portal environments to the latest and greatest. XTIVIA has compiled a list of items to keep in mind when making the plunge from Liferay 6.x to Liferay DXP.

This entry is the first in a series on migrating to Liferay DXP.

Java 8 is the new normal

One of the biggest underlying shifts made in Liferay DXP is that the version of Java used by the platform is now Java 8; Java 8 was supported in later versions of Liferay Portal 6.2, but it was never the default JVM version. Java 8 is quite mature at this point, and brings a multitude of new features that improve the quality of life of Java developers significantly, while at the same time improving both overall performance and maintainability. While applications written for Java 7 can be run on Java 8 (in most cases), it is recommended to budget time into your migration plan to allow for each of your applications to be ported and validated using Java 8.

An additional consideration is that Java 8 provides improved support for the G1GC garbage collection algorithm; anecdotally, we have seen moderate improvements in JVM performance when using the G1GC algorithm over the concurrent-mark-sweep (CMS) algorithm. Using this GC algorithm is entirely optional, but it’s certainly worth testing as a part of a migration plan.

Liferay now requires an external search server

This will probably be one of the more controversial issues that most organizations experience when upgrading to Liferay DXP; Liferay has changed the underlying search engine present in the DXP application to be Elasticsearch. This was done for a number of very good reasons; the search function in the platform has become more and more important over time, and it was necessary to ditch the aging Lucene implementation in favor of a more scalable option. However, this does mean that every new Liferay DXP environment will need to provision separate servers for running the Elasticsearch engine; these servers need to be separate from the Liferay DXP servers themselves! Liferay’s official recommendation is that Elasticsearch servers be provisioned with a minimum of 8 CPU cores and 16GB of memory; 64GB of memory is preferred.

Additionally, if you are migrating a production-class environment, it would be wise to budget additional time and resources to set up a fully-redundant Elasticsearch cluster. An Elasticsearch cluster provides seamless redundancy for search requests and resiliency for the search indexes themselves; using only a single Elasticsearch instance would create a critical single point of failure in your DXP environment.

The default location for deployed apps has changed

This change will mainly impact organizations which have automated processes built around the structure of the application server being used (i.e. using the WebSphere Deployment Manager to deploy applications into a cluster, using Tomcat clustering, configuring session replication on a per-app basis). The Liferay DXP deployment process no longer deploys applications into its target application server’s application deployment directory; instead, it deploys applications to a separate osgi directory located in the Liferay home directory. This directory is used by DXP to store and deploy applications and modules within the OSGi framework container. The impact of this is manifold; application server “clustered” distribution of applications will no longer function, and the applications themselves will now run as OSGi modules within the liferay application, rather than running as baseline web applications within the application server.

For most environments, this change will be transparent; however, it is something to keep in mind when planning out your DXP deployment pipeline or troubleshooting classloader or namespace issues during migration.

Configuration has changed significantly

Historically, there were two common places to store configuration data in Liferay Portal: in the portal-ext.properties file, and in the PortalPreferences_ database table (set via the administration UI). In Liferay DXP, this has changed slightly due to the shift to OSGi modules. The PortalPreferences_ table has been removed entirely, and has been replaced by a modular OSGi-based configuration framework. The portal-ext.properties file is still present, but a number of available configuration settings have been moved to the new configuration framework (a detailed list of the configuration items which are no longer available will be covered in a subsequent posting).

The practical impact of this is twofold; first, any migration project will need to budget time to review and update configuration settings in each environment to match the new configuration processes. Second, any configuration management process in place for promotion of configuration data from environment to environment will need to be updated to use the new OSGi configuration framework. The new framework actually makes it slightly easier to manage configuration promotion, but it is significantly different from the old Liferay Portal process; details on how to build a configuration pipeline for DXP will follow in another post.

Summary

There are a number of significant changes that need to be taken into account when migrating a Liferay Portal 6.x environment over to Liferay DXP; careful attention to detail and planning can help make it as smooth a transition as possible.

If you need assistance with Liferay DXP migration planning and execution, or just want more detail on best practices to use when moving to a DXP environment, please reach out to us.

Get Expert Advice Today!

The post Migrating to Liferay DXP: Things to Keep In Mind appeared first on XTIVIA.

We see increasing interest in the market and among our customers in migrating team sites and general collaboration sites from SharePoint to Liferay, a leader in the Gartner Magic Quadrant for Horizontal Portals. A key aspect of these platform migrations is the migration of data – users, sites, and all types of content (web content, documents, lists, discussions). Depending on the volume of data that you have accumulated in SharePoint, this data migration can be a major undertaking and a manual migration might well be impractical if not impossible. At XTIVIA, we have developed an automated SharePoint Liferay Migration Tool for migrating SharePoint sites, users and content to Liferay, and can thereby help you avoid human error, speed up your data migration, and reduce your migration costs.

SharePoint Liferay Migration Tool Architecture

The migration tool was architected as a desktop tool that would migrate the content from the SharePoint site to the Liferay site. This is done using the SharePoint Client API in a C# desktop application. In addition, it uses remote database access to retrieve IIS form based user information that is not available through the SharePoint Client API. Once the users, sites, and content are retrieved via the SharePoint Client API and T-SQL queries it is mapped to a series of RESTful service calls provided by the SharePoint Import Services developed by XTIVIA for the Liferay environment.

Figure 1: SharePoint Liferay Migration Tool Architecture

Configuration Driven

The desktop tool provides a series of components that understand SharePoint lists and tables, as well as Liferay Users, Web Content, Message Boards, Categories, Documents and Media and Pages. A configuration language using JSON is provided to describe the existing SharePoint sites, lists and tables and the Liferay sites, users, etc… It also provides the mapping from the SharePoint components to the Liferay components. This allows for a reusable tool that does not require custom coding to support multiple SharePoint and Liferay sites. The following is an example of mapping web content with categorization.


{
"ListName": "Communications",
"ListType": "Communications2JournalArticle",
"ListConversionParameters": {
"JournalFolderName": "Communications",
"DocumentFolderName": "Communication Attachments",
"StructureName": "Communication",
"TemplateName": "Communication",
"DisplayPageUrl": "/communication-details",
"DisplayPagePrivate": true,
"VocabulariesMap": {
"CommunicationSection": {
"Vocabulary": "Business Unit",
"MappingType": "FromSharepoint"
},
"IsFeatured": {
"Vocabulary": "Communication Type",
"MappingType": "BooleanMap",
"True": "Featured",
"False": "Standard"
},
"BusinessMaterials": {
"Vocabulary": "Business Materials",
"MappingType": "FromSharepoint"
},
"ProductMaterials": {
"Vocabulary": "Product Materials",
"MappingType": "FromSharepoint"
},
"TrainingMaterials": {
"Vocabulary": "Training Materials",
"MappingType": "FromSharepoint"
},
"FoundationMaterials": {
"Vocabulary": "Foundation Materials",
"MappingType": "FromSharepoint"
},
"MarketingChannel": {
"Vocabulary": "Marketing Channel",
"MappingType": "FromSharepoint"
}
}
}
}


Repeatable and Restartable

Another feature of the tool is that it maps the SharePoint Id within the Liferay component to allow both restarting the tool if it is stopped in the middle of the transfer as well as allowing it to be rerun if new data is added as an existing item will not be duplicated.

Logging and Monitoring

The tool provides a log of the SharePoint ID mapping to the new Liferay ID as well as of successful and failed conversions. This allows manual intervention for the small percentage of items that were not migrated in an automated fashion.

SharePoint Liferay Migration Tool Summary

In summary this tool was used to convert an existing SharePoint site that was in production to a new Liferay site that was used to replace the existing SharePoint site. It was accomplished with a minimal amount of manual intervention. Twenty pieces of content and four documents and media files were transferred manually out of thousands of items.

If you liked what you read, please share this helpful post with your friends and co-workers on your favorite social media here:

The post SharePoint to Liferay Migration Tool appeared first on XTIVIA.

The post Fixing Mixed Content Warnings in Liferay DXP appeared first on XTIVIA.

This article provides a guide to building a “hook” to show the list of “Web contents” when using Liferay publishing. Introduction Liferay CMS is a critical part of most of the Portals and Websites built on Liferay platform. In most enterprise scenarios there are multiple content authors who work on adding and editing site content […]

The post Window into Liferay Publishing Black Box appeared first on XTIVIA.