AdoptOS

Assistance with Open Source adoption

Liferay
Syndicate content
Liferay.com
Updated: 9 hours 29 min ago

Customize Elastic Search and Search by Synonyms in Liferay

Sat, 02/24/2018 - 08:52

Q-Have you ever wondered if you can customize your Elastic Search, so that on your searches in Liferay, not only the words you're searching for come up in the results but also synonyms of these words?

A-Yes, you can!

Below, I'll show you an example of how I did it (by customizing my indexes and mappings settings).

Let's say that I have a web content article containing the word "small" and I search for the word "tiny".

 
  1. Navigate to Control Panel → Configuration → System Settings → Foundation
     
  2. Search for the com.liferay.portal.search.elasticsearch.configuration.ElasticsearchConfiguration system setting.
     
  3. Go to "Aditional index configurations" and add your own.

    You can start by copying the contents of your index-settings.json file there. Your index-settings.json file is packed in the Elastic Search module of your Liferay bundle.

    Now, modify it as this document describes: https://www.elastic.co/guide/en/elasticsearch/guide/current/using-synonyms.html .

    It should look like the image below (note the "synonyms" part of the json, where we wrote our list of synonyms):
      
     
  4. Now go to "Override type mappings" and copy into the text area input the contents of the file "liferay-type-mappings.json", also packed in the Elastic Search module (a jar that you will find in your Liferay bundle) into it.

    Modify it, also following the steps this document describes: https://www.elastic.co/guide/en/elasticsearch/guide/current/using-synonyms.html (as in the previous step).

    For example, you could add something like this:
      "content": {      "index": "analyzed",      "store": "yes",                "search_analyzer" : "my_synonym_analyzer",                "analyzer" : "my_synonym_analyzer",                "term_vector": "with_positions_offsets",                "type": "string"   },
    and something like this:
     "title": { "index": "analyzed", "store": "yes",                "search_analyzer" : "my_synonym_analyzer",                "analyzer" : "my_synonym_analyzer", "term_vector": "with_positions_offsets", "type": "string" },
    to it:

      
     
  5. Save your changes
     
  6. Navigate to Control Panel → Configuration → Server Administration and execute "Reindex all search indexes" under the section "Index Actions"


     
  7. Perform a search and... Voila!, the magic happens:


    Easy, right?

    If Elastic Search can do it, Liferay will do it too (since it leverages on Elastic Search for indexing its documents). You just need to know it can be done, and where in the control panel you can configure it.
     
Carlos Hernandez 2018-02-24T13:52:38Z
Categories: CMS, ECM

How to Upgrade to Liferay 7.0+

Fri, 02/23/2018 - 15:35

So the question comes up how to do Liferay upgrades.

I'm not talking here about the technical details of how you upgrade one particular plugin to another type of plugin, what kinds of API changes have to be made, etc.

Instead, I'm thinking more about the general process of how to upgrade, what choices you're presented with and what the ramifications are for making certain choices.

Upgrades Are Projects

The first thing to remember is that upgrades are projects. You should totally build them out as projects, you should have a project plan, you should have a project team, ... Having a full project plan forces you to define scope for the upgrade and time box all activities so you will know how the project is proceeding.

As a project, you also should have a risk assessment/mitigation plan. Know in advance what you will do if the project runs long or runs into issues. Will you just stretch the timeline? Will you seek help from Liferay GS or a Liferay Partner? Are you sending your development team to Liferay training in advance or only if they seem to struggle? Will you rely on LESA tickets, Liferay documentation, community support via the forums or slack?

Liferay GS offers an Upgrade Assessment package where an experienced Liferay GS consultant will come onsite to review your environment and build a customized report outlining what your upgrade effort will be. This assessment can become the foundation of your project planning and can help set your upgrade in the right direction.

Upgrades Have Scopes

Upgrading from Liferay 6.2 to Liferay DXP 7.1, there will be scope to this project and the project is susceptible to scope creep.

For example, you might decide going in that your project is simply to get what you currently have migrated and running under DXP. During the upgrade project, though, you might decide to add some backlogged features or refactor your codebase or rework legacy portlet wars into OSGi portlet modules. Each of these things would be considered scope creep. Each change like these that the team takes on will negatively impact your project plan and schedule.

Upgrades Expose Bad Practices

The one thing I've found is that upgrades tend to expose bad practices. This could be bad practices such as using an ORM package instead of Service Builder for data access. It could be a non-standard way of decoupling code such as making all service calls via remote web services where a local service implementation would have been an easier path. It can expose when standard design practices such as design by interface were not fully leveraged. It could be as simple as having used an EXT plugin to do something that should have been handled by a JSP hook or a separate custom implementation.

Exposing bad practices may not seem very important, but upgrading bad practices will always add to a project plan. Something done initially as a shortcut or a hack, these things get difficult to carry forward in an upgrade.

The one thing I've found in 10+ years of experience with Liferay, it is often better to do things "The Liferay Way". It is not always easy and may not seem like the right way, but it usually ends up being the better way generally to develop for the platform.

Upgrade Project Recommendations

To facilitate your upgrade project, I offer the following recommendations:

  • Limit scope. As far as the upgrade is concerned, limit the project scope to getting what you currently have running under the later version. Do not consider refactoring code, do not consider reworking portlet wars as OSGi modules, etc. Limit the scope to just get on the new version. If you want to refactor or rework wars as OSGi modules, save that for a later project or phase.

 

  • Leave portlet wars as portlet wars. I can't say this strongly enough. It is absolutely not necessary for your legacy portlet wars to be refactored as OSGi modules. Your legacy portlet wars can be deployed to DXP (after necessary API changes) and they will automagically be converted into an OSGi WAB for you. Do not spend your upgrade cycles reworking these into OSGi bundles yourself, it is a complete waste of your time and effort.

 

  • Only rework what you have to rework. You'll have to touch legacy hooks and EXT plugins, there is no way around that. But that is where your upgrade cycles need to be spent. So spend them there.

 

  • Rethink upgrading bad practices. I know, I said limit scope and migrate what you have. The one exception I make to this rule is if you have exposed some really bad practices. In the long run, it can often be a smaller level of effort to rework the code to eliminate the bad practice first or as part of the upgrade. Cleaner code is easier than spaghetti to upgrade.

 

  • Use Liferay IDE tooling. The Liferay IDE comes with a built-in upgrade assistant tool. While the tool is not perfect, it can help you upgrade your Maven and Plugin SDK projects to be compatible with the later version, including suggesting and making necessary API changes for you. If you do not use the upgrade assistant, you are willfullly missing out on an automated way to start your upgrade.

 

  • Have a Backup Plan. Know in advance if you are going to leverage Liferay GS or a Liferay Partner to help complete your upgrade in case you are seeing delays. If you wait until you are behind the eight-ball before mitigating your risk, you will be less prepared to get the project back on track if it is going off the rails.

 

  • Get a Liferay Upgrade Assessment Package. Even if you are going to do all of the work in house, an upgrade assessment can highlight all of the aspects you and your team will need to consider.

That's pretty much it.  Have any horror stories or suggestions you'd like to share? Please add them below...

David H Nebinger 2018-02-23T20:35:41Z
Categories: CMS, ECM

Deploying Liferay 7.0 on to Tomcat 8.5

Fri, 02/23/2018 - 13:21

Tomcat 8.5 is an in-between version of Apache Tomcam 8.0 and 9.0. According to the Apache site, it contains some features in 9.0 that have been backported to 8.0. This version of Tomcat is currently in the "Supported" matrix of the Liferay DXP Compatibility Matrix, and of course, the question is: How do I set up Liferay CE/DE 7.0 with Tomcat 8.5?

The short answer is: Exactly like you would on Tomcat 8.0, which can be found here. Much of this entry will be a reproduction of those steps. The order of the steps will be a little different.

This blog post will cover the bare minimum to get Liferay CE/DE 7.0 working on Tomcat 8.5, skipping some of the extraneous steps or providing alternate steps. These steps were run on a Windows 10 machine, but should be generally applicable to Linux environments as well. Differences will be noted. Despite having been done in Windows, "forward" slashes aka "/" will be used, as that is how Tomcat wants directories to be marked.

Terminology

$TOMCAT_HOME - location of the Tomcat 8.5 directory, usually inside $LIFERAY_HOME

$LIFERAY_HOME - location of the Liferay directory that will contain Tomcat, and all the usual Liferay directories, like data, deploy, logs, osgi, etc... This directory can be located anywhere.

Step 0 - Prerequisites
- Install Java JDK 8, and configure the JAVA_HOME variable if not done already.
- Test the validity of the path by using the command "java -version" in the command prompt/terminal
- If there is a JRE_HOME variable set, remove it.

Step 1 - Acquire all the necessary files
- There are 3 required files provided by Liferay: the Liferay WAR, the Liferay dependencies, and Liferay OSGI dependencies.
- These steps were performed using Liferay DE 7.0 SP6, the portal portion of Liferay DXP. If you have a Liferay subscription and wish to also do the same, the files are available from Customer Portal, here. The files for Liferay CE 7.0 GA 5 can be found here. The individual files can be found down at the bottom of the page.
- There are a number of JAR files that are not included in default Tomcat that need to be acquired. They can either be copied over from a Liferay Tomcat bundle, or downloaded individually.

  • activation.jar
  • ccpp.jar
  • com.liferay.osgi.service.tracker.collections.jar
  • jms.jar
  • jta.jar
  • jutf7.jar
  • mail.jar
  • persistence.jar

Locations on where to get these files can be found in the regular Tomcat 8.0 steps.

REMINDER: Don't forget the database driver JAR file.

Step 2 - Extract dependency files
- Extract the Liferay dependency JARs to $TOMCAT_HOME/lib/ext. It will be necessary to create the "ext" directory.
- Extract the "osgi" directory from the OSGI dependency ZIP into $LIFERAY_HOME

Step 3 - Configure catalina.properties
- In $TOMCAT_HOME/conf/catalina.properties, find the "common.loader" property.
- Add the following to the end:

"${catalina.home}/lib/ext/global/*.jar","${catalina.home}/lib/ext","${catalina.home}/lib/ext/*.jar"

OR

Replace the whole property

common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.home}/lib/ext/global","${catalina.home}/lib/ext/global/*.jar","${catalina.home}/lib/ext","${catalina.home}/lib/ext/*.jar"

- This tells Tomcat that there are extra JAR files that it needs to recognize.

Step 4 - Configure catalina.policy
- Delete the contents of catalina.policy and replace it with:

grant { permission java.security.AllPermission; };   - Yes, delete the contents of the file and replace it with the above 3 lines.

Step 5 - Configure server.xml
- In $TOMCAT_HOME/conf/server.xml, the URIEncoding needs to be set te UTF-8 for Tomcat. Add the property URIEncoding="UTF-8" into the 2 <Connector> sections. In the default server.xml, it will be on line 69 and 116. 

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8"/> AND <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" URIEncoding="UTF-8"/>

Step 6 - Configure ROOT.xml
- In $TOMCAT_HOME/conf, create Catalina/localhost/ROOT.xml
- Add the following to ROOT.xml

<Context path="" crossContext="true"> </Context>

- Note that in the original Tomcat 8.0 steps, there is a significant chunk of commented out settings. They are not used in this basic, minimal setup. If you are using JAAS, then yes, the commented out section is necessary.

Step 7 - Extract Liferay WAR
- Delete all the directories in $TOMCAT_HOME/webapps except for ROOT. These are just sample applications.
- Delete the contents of the ROOT directory. Alternatively, ROOT can be deleted along with the other sample directories and remade as empty.
- Unzip the contents of the Liferay WAR file into the now-empty ROOT directory.

Step 8 - Configure JVM
- This is where Windows and Linux diverge.
- In $TOMCAT_HOME/bin, create setenv.bat or setenv.sh, depending on OS.
- In setenv.bat, paste the following:

set "CATALINA_OPTS=%CATALINA_OPTS% -Dfile.encoding=UTF8 -Djava.net.preferIPv4Stack=true -Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false -Duser.timezone=GMT -Xmx2048m -XX:MaxMetaspaceSize=1024m"

- In setenv.sh, paste the following:

CATALINA_OPTS="$CATALINA_OPTS -Dfile.encoding=UTF8 -Djava.net.preferIPv4Stack=true -Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false -Duser.timezone=GMT -Xmx2048m -XX:MaxMetaspaceSize=1024m"

Note the following properties:
"-Xmx2048m" - Liferay 7.0 CAN be run with the default 1024m of JVM space, but it's not fun. I would suggest at least 2048m (2 GB) or higher for development work.

"-XX:MaxMetaspaceSize=1024m" - In Java 8, the property -XX:MaxPermSize was deprecated and is ignored. PermGen was replaced with Metaspace, which by default is unlimited. Setting it to 1024m is fine for development work.

Step 9 - portal-ext.properties (optional)
- In $LIFERAY_HOME, create or copy over a portal-ext.properties file. In the file, you can set various configurations like the database connection, and disabling of the setup-wizard.

Step 10 - Start it up
- There are 2 ways to start Tomcat from a command line/terminal.
- Executing startup.sh or startup.bat will have the process run in the background and will not output log into the current window.
- Executing catalina.sh run or catalina.bat run will have the process run in the current command line and will output log into the window. If the window is closed, or the terminal session disconnected, then the process will stop.

Skipped Steps
- In comparison to the original Tomcat 8.0 setup steps, the following sections were skipped:
JNDI database configuration
Mail configuration
PACL
Mojarra

- The database and mail configuration can also be done via portal-ext.properties, in Step 9 above.

Conclusion
There are no specific steps that differ between Tomcat 8.0 and Tomcat 8.5. Essentially, steps are the same for a basic configuration of Tomcat 8.5 with Liferay 7.0 CE/DE. PACL and Mojarra may have some differences, but I've never used them. I believe Tomcat 8.5 is just a hair faster than Tomcat 8.0, but that's a subjective topic.

Jonas Choi 2018-02-23T18:21:43Z
Categories: CMS, ECM

Seis tendências de Experiência do Cliente para 2018

Thu, 02/22/2018 - 14:46

O que define uma boa experiência do cliente está em constante transformação devido às constantes mudanças de comportamento do público e o uso de novas tecnologias. Entretanto, embora CX mude com o passar do tempo, sua importância para potenciais clientes e o sucesso dos negócios cresce a cada dia.

De acordo com um estudo feito pela Spigit, 75% das empresas pesquisadas em 2016 tinham como seu principal objetivo a melhoria da experiência do cliente. No entanto, a resposta para tornar isso possível encontra-se na continuidade. As seis tendências seguintes ajudarão você e seu negócio a criarem estratégias eficientes para atender às expectativas do seu público e atingir o sucesso com o passar do tempo.

1. Os Maiores Desafios Internos de uma Organização São Enfrentados na Experiência do Cliente

De acordo com uma pesquisa feita pela Forrester, os três maiores desafios na implementação de uma estratégia para a experiência do cliente são: a cultura da empresa (54%), sua estrutura organizacional (45%) e seus processos internos (41%). Todos esses obstáculos são, na maioria das vezes, associados ao CEO do negócio. Deste modo, 2018 pode ser um grande ano para empresas e CEOs principalmente, tomando decisões que poderiam permitir seus times a obter grandes ganhos em relação aos seus esforços de CX. CEOs e os departamentos deveriam focar na colaboração e comunicação efetivas para progredir substancialmente.

2. O Poder das Experiências sem Interrupções

Serviços como o Amazon Go lideram na criação de experiências de consumidores sem interrupções ao possibilitar compras online, até então realizadas apenas em supermercados, removendo o processo de checkout através de cobranças instantâneas. Como demonstrado pelo Customer Think, o público espera que as experiências avancem de maneira consistente e uma organização importante, como a Amazon, geralmente define os padrões para outros negócios. Neste caso, fazer compras sem obstáculos torna, o simples ato de comprar, fluido e mais rápido do que nunca.

3. Melhorando Experiências Baseadas na Localização

A tecnologia beacon tem sido usada por muitos anos, mas a sua adoção agora pode ser feita para deixar a experiência do cliente mais integrada e rápida. De acordo com a Dimension Data, os negócios estão trabalhando para fazer com que os pontos de contato físicos com o usuário sejam tão simples e eficientes como experiências onlines. Por exemplo, hotéis estão utilizando beacons para substituir chaves de quarto e empresas estão permitindo o acesso de colaboradores à locais seguros e informações sigilosas baseada na localização através dos beacons. A lacuna entre interações interpessoais e experiências online está cada vez menor. Clientes podem integrar todos os aspectos das suas atividades cotidianas às empresas.

4. Crescimento e Aperfeiçoamento da I.A. nas Operações de Negócios

A Inteligência Artificial terá papel importante em vários aspectos da experiência do cliente, mas garantir que isso aconteça depende da capacidade de reconhecer o discurso da sua audiência. A Customer Think detalhou como os sistemas de reconhecimento de voz podem ajudar os assistentes de voz a aprender rapidamente o modo como cada usuário fala, incluindo seus padrões, dialetos e sotaques únicos a fim de evitar a frustração e tornar seus papéis, nas empresas e em casa, essenciais no futuro. O Gartner prevê que 85% das interações dos clientes serão gerenciadas sem uma figura humana até o ano 2020, o que significa que sistemas automatizados e inteligência artificial gerenciarão a grande maioria dos processos. Com um uso cada vez maior de I.A. nas operações das empresas através de chatbots, agrupamento de dados, ferramentas de análise e muitos outros programas, espera-se que, em 2018, encontremos muitas outras empresas usando esta tecnologia de diversas maneiras.

5. Impulsionando o Gerenciamento de Identidade do Consumidor (CIAM)

Dados continuarão a ter importante função no modo como as organizações interagem com seus clientes. Por sua vez, empresas estão adotando o gerenciamento de identidade do consumidor (customer identity and access management - CIAM), que usa caraterísticas como o registro de clientes, autenticação “multi-fatores”, auto-gerenciamento de conta e administração do acesso a dados para escalar e personalizar canais para cada usuário e seus objetivos pessoais. Como discutido por Janrain, CIAM cria interações personalizadas elaborando estratégias de engajamento baseadas em insights de dados e na eliminação de obstáculos que podem afetar as experiências dos clientes. As empresas irão buscar este tipo de solução que seja robusta no gerenciamento e segurança de dados.

6. O Tempo se Torna um Produto

Enquanto ótimas experiências continuarem a ser uma prioridade, o The Economic Times destaca que o tempo de um cliente é um fator que se torna cada vez mais importante em cada interação. Desde realizar o processo de checkout o mais rápido possível a solucionar problemas de um item online obtendo respostas rapidamente através de chatbots, as empresas devem se esforçar para diminuir o tempo necessário dos clientes para receber os produtos ou serviços que eles desejam. Isso pode evitar que sua audiência se frustre e que potenciais clientes não abandonem sua jornada antes de concluí-la.

Mudanças para os Negócios Digitais em 2018

O modo como organizações realizam negócios e como elas são impactados pelas mudanças no marketing digital, irão, novamente, mudar em 2018. Leia mais sobre isso em negócios digitais.

  Transforme Sua Experiência do Cliente em 2018

Acompanhar as expectativas sobre experiência do cliente requer um software que está pronto para atender uma série de demandas. Leia mais sobre as estratégias possíveis com Liferay.

Leia Quatro Estratégias para Transformação Digital do Negócio   Isabella Rocha 2018-02-22T19:46:52Z
Categories: CMS, ECM

Why You Should Join the 7.1 Community Beta Program

Tue, 02/20/2018 - 23:32

So Jamie just announced the new Liferay 7.1 Community Beta Program here: https://community.liferay.com/news/liferay-7-1-community-beta-program/

I recommend everyone who has working code in Liferay 7.0 or Liferay DXP should join the 7.1 beta sooner rather than later.

Why? Well, mostly because Liferay's engineering team is focused on the 7.1 release, so anything that you find in beta, well that will be something that they will want to fix before release. Without those bug reports, some incompatibility that you encounter later on falls under the regular release process and that will only work against your release schedule.

Let's say, for example, that you have spent time building out a comprehensive audit solution for your Liferay 7.0/DXP environment where you have a slew of model listeners and a custom output mechanism to route the audit details to an ElasticSearch instance that you report on using Kibana. You've got a decent investment in your auditing solution, one that you plan on leveraging in 7.1 on.

You're basically looking at two choices.  Choice #1 is to do nothing; wait for the official 7.1 GA to come out and for your organization to decide it is time to consider an update to 7.1. Now I can't predict what might be part of 7.1, but let's argue that it has one or more bugs related to the audit mechanisms.  Perhaps the model listeners registration has changed or the audit messages are broken or the output mechanism isn't invoked consistently, ... I don't know, some sort of bug that maybe could have been caught sooner but ended up getting by. But now that you're looking at the upgrade, you've found the bug and want to report it. That's fine, Liferay wants you to report bugs, but at the time you've found it 7.1 is out and fixing the bug ends up becoming part of the release process.

Choice #2 is to join the Beta program. Now you dedicate a little bit of time to test your code under 7.1 before it goes out and you find and report the issue. Now Liferay has this list of things that they want to knock out for the first GA, so your report becomes one of many that Liferay really wants to deal with for a solid initial release. Your bug gets dealt with before it can impact your own upgrade schedule, and this actually helps you from the early reporting.

So please, please, please sign up for the 7.1 beta program.

Get the 7.1 beta and beat on it as much as you can.

Run the DB upgrade against your current database. Update and deploy your custom modules, make sure features, functionality and APIs are still there that you depend on. Point your load test tool at your instance and see if you have a measurable difference in performance or capacity vs your current environment.

Just bring it. Find and report the problems.

Together we can make the next release one of the best ever, all that's missing is you.

David H Nebinger 2018-02-21T04:32:04Z
Categories: CMS, ECM

Creating Consistent User Experiences with Liferay Adaptive Media

Tue, 02/20/2018 - 11:53

The average web page is far larger in size and more complex in its programming than it has ever been before. Today, businesses across all industries are using images, video and interactive capabilities more and more to help create better user experiences. In addition, there are countless types of devices being used to access the internet, creating a complex interface that changes the user experience from person to person.

Beyond the complexity of websites, individual web pages are steadily growing in size thanks to the many elements commonly used in each. These elements have increased the average total web page size from 702 KB in November 2010 to 3.3 MB in September 2017, according to HTTP Archive. This means that the average size has multiplied by approximately five times in seven years.

It isn’t just web pages increasing in size and devices multiplying in number that can cause such a wide disparity in user experience. More countries than ever have a large portion of their populations accessing the internet. However, the average bandwidth in each country can vary greatly, leading to even more variations in user experience. Differences in devices mean that navigation menus, text size, image placement, white space and more will change to suit the specific dimensions of various screens. In addition, the increasing size of web pages and large differences in bandwidth can cause sites to load slowly and frustrate visitors, or even fail to load various elements at all. Without great UX strategies that take these factors into account and plan for them through detailed programming, it can be difficult for companies to properly reach their target audiences.

As such, Liferay Adaptive Media has been created to address these needs and improve a company’s omnichannel strategy and behind-the-scenes performance.

Optimizing for Great User Experience

Video has made the largest gains in accounting for the size of web pages during the last seven years, with images still accounting for the majority of data, as seen in the charts below.

However, while video is taking up a great portion of data, images are accounting for more data than ever. As seen below, while the average number of images has stayed relatively the same across the years, the average image size is steadily increasing.

According to statistics from Kissmetrics, nearly half of web users expect a website to load in two seconds or less. Should the site not load in three seconds, then they are likely to abandon it. In addition, 79% of those polled said that they would not return again to a site with performance issues. These online factors influence the bottom line of every company and illustrate the importance of creating an online experience that performs well for a wide variety of users under many different circumstances.

As page data continues to grow, businesses must take steps to prevent complications from negatively affecting their user experience due to device specification, bandwidth and more, while still providing a pleasing modern user experience.

Taking Control of User Experience

A well-constructed user experience that conforms to the unique circumstances of users can benefit many different audiences. Liferay Adaptive Media can help:

  • Portal Administrators: Define media resolutions that will be used to process and serve uploaded images according to the characteristics of the accessing device (screen size, bandwidth and processing capacity).
  • Content Creators: Upload media and create new pages of content without needing to worry about their appearance being negatively impacted by varying screen sizes and devices, with Adaptive Media transparently working in the background.
  • End Users: Enjoy an improved experience by consuming images that best fit to their devices and Internet connection.
  • Developers: Easily integrate Adaptive Media in their apps to support different media qualities.
Improve Your UX with Liferay Adaptive Media

The Liferay Adaptive Media app help programmers combat the complications caused by large page sizes and variations in device layouts, with features including:

  • Core integration with documents and media
  • Optional integration with blogs and web content
  • Compatibility layer removing the need to modify old content
  • Resizing images stored in Liferay to certain image resolutions
  • Reducing page size and improving loading speed based on device and bandwidth
  • Applying these changes automatically to end users without individual programming

Adaptive Media helps Liferay DXP users create experiences that are tailored to their customers, wherever they are, regardless of device.

Improve User Experience with Liferay Adaptive Media

Find out if Liferay Adaptive Media is right for you and see how you can tailor image quality in order to provide the best user experience possible.

Learn More About Liferay Adaptive Media   Matthew Draper 2018-02-20T16:53:28Z
Categories: CMS, ECM

Liferay 7.1 Community Beta Program

Mon, 02/19/2018 - 19:12
Welcome to the Liferay 7.1 Community Beta Program!     During the Liferay 7.0 development cycle we launched the Community Expedition program.  With over 600 participants this was one of our largest and most successful community programs to date.  It is in large thanks to our awesome community who was instrumental in the success of Liferay Portal 7.0.     It is with great pleasure that I announce our next community initiative: Liferay 7.1 Community Beta Program.  The main goal for this program is to ensure that Liferay 7.1 meets your expectations by giving you the opportunity to provide vital feedback and bug reports during the duration of the 7.1 testing cycle.  The program will once again be hosted on the Liferay Developer Network and is scheduled to begin in early March.   Why participate? Besides the gratitude you’ll receive from the Liferay Community (and the Liferay QA, Engineering, and Release teams), other reasons to join include:
  • Get a heads up on new features in Liferay 7.1.
  • Help test your upgrade to make sure everything works as smooth as possible.
  • Engage other members of the community (including Liferay staffers).
  • Gain credit towards the Liferay Top Contributor award.
  • Receive a small token of our appreciation for your efforts.
Joining the Community Beta Program The Liferay 7.1 testing cycle will begin with the first Alpha release of Liferay 7.1 and will conclude when GA1 is released.  This will be a shorter testing cycle then we have had previously so timing is of the essence.  What you will need to do is to download a new pre-release when it becomes available, try out the new features highlighted on the beta program site (more details soon) and provide your feedback and report bugs to Liferay.  Here’s how to sign up:  
  1. Sign up for the program.  This let’s us know more about you and what your interests and environment are.  Once we are ready to launch the program we will send a follow-up email with more instructions.
     
  2. When a new pre-release (Alpha, Beta, RC) is released, we will provide an announcement on the beta program site with any important details for the release.  Be sure to download the pre-release and provide feedback and bug reports in the Forum on the beta program site.
     
  3. If you run into any problems or just have questions in general about the release, feel free to post in the Forum on the beta program site.
We look forward to your involvement with our community and hope that you will learn a lot about the release and meet some new faces along the way! Jamie Sammons 2018-02-20T00:12:34Z
Categories: CMS, ECM

¿Por qué tu customer journey map no está reflejando la realidad de tus clientes?

Fri, 02/16/2018 - 07:58

Las empresas diseñan buenas experiencias de clientes con el objetivo de satisfacer o superar las expectativas de su público objetivo; y lo hacen a través de la predicción de sus acciones e intereses. Sin embargo, las compañías necesitarán crear una descripción detallada y precisa de estas experiencias potenciales en forma de customer journey map, en el que estén representados todos los pasos que estos dan durante la interacción con la empresa. Estos mapas deben tener la función de trazar el recorrido desde la primera interacción hasta la ejecución de la compra o, incluso más allá. Dedicar recursos a llevar a cabo esta acción es especialmente importante, ya que un mapa del customer journey incorrecto, que no refleje la experiencia real de tu audiencia puede causar complicaciones innecesarias para tu negocio.

Independientemente de si tu empresa se encuentra actualmente en el proceso de definición de su customer journey, o de si ya ha finalizado este proceso, es importante que conozcas las principales razones por las que algunos customer journeys maps no funcionan. Y, si es el caso, puedas hacer los cambios necesarios para que el tuyo refleje perfectamente el recorrido de tu cliente a lo largo de su ciclo de vida.

Problemas comunes del Customer Journey Map

Si bien cada empresa debe hacer un esfuerzo por diseñar un customer journey map que refleje la realidad del cliente, hay un serie de problemas comunes que surgen a lo largo del proceso de diseño, y que pueden impedir la creación de un mapa ideal. A continuación ponemos algunos ejemplos de estos problemas frecuentes. Es importante que, en cada caso, pueda considerarse cómo cada uno de ellos puede afectar al customer journey de tu organización:

  • Recorrido idealizado: Existe una diferencia entre cómo te gustaría que se comportara tu cliente y cómo se comporta verdaderamente. Si tu customer journey solamente refleja el comportamiento e interacciones que te gustaría que tu audiencia tuviera con tu compañía , esta herramienta no podrá ser utilizada para analizar y orientar el comportamiento de los clientes para conseguir tus objetivos. Los customer journey maps que son realmente útiles para tu empresa y equipo son los que muestran cuál es el verdadero recorrido de tu público objetivo. De esta forma seréis capaces de poner en marcha los cambios necesarios que os ayuden a dirigir a vuestra audiencia hacia vuestro customer journey ideal.
  • Dejar de lado los pasos que no incluyen a tu marca o empresa: Un customer journey map de éxito es aquel que contempla todas y cada una de las fases del proceso, incluyendo aquellas que no están relacionadas con tu negocio. Lo que puede incluir aquellos momentos en los que el cliente analiza a la competencia o aprende algo sobre tu producto en una página de un tercero. Puede que no seas capaz de mantener un control sobre estas fases del proceso, pero debes tener en cuenta que también van a tener un impacto en el customer journey real.
  • Olvidar el Punto de vista del cliente: ¿Qué opinión tiene el cliente de tu empresa? Esta es una pregunta importante que toda compañía se debe hacer y que, además, va ayudarte a comprender cómo cada paso del customer journey va a impactar en dicha percepción, así como en incentivar o desmotivar al cliente para dar el siguiente paso hacia la compra. No olvides que este recorrido del cliente con tu empresa todavía depende de la visión y los intereses de la audiencia, independientemente de cómo de efectiva sea tu estrategia de experiencia del cliente.
  • Falta de Indicadores sobre el rendimiento del customer journey: Los mapas de customer journey también son capaces de identificar qué áreas pueden ser optimizadas, a través de la incorporación de indicadores que ayuden a medir su rendimiento. Según Tandem Seven, estos indicadores ofrecen insights sobre el estado emocional del cliente, facilitando la identificación de las razones que pueden estar impidiendo la finalización de la compra. No tener en cuenta este tipo de información puede impedir a la empresa conocer mejor las razones que hay detrás de la compra o abandono por parte del cliente.

Considerar los posibles problemas que pueden darse en el customer journey puede ayudar a las compañías a comprender mejor la efectividad de su mapeo y comenzar a ver las causas subyacentes de los posibles problemas para atajarlos y darles solución.

¿Qué está causando los problemas en tu mapa del Customer Journey?

Frecuentemente, un diseño incorrecto del customer journey es consecuencia de un alcance de visión limitado durante el proceso de su creación. Si una compañía no trabaja lo suficiente para definir con exactitud todas las fases de este proceso, así como para incorporar cada una de las perspectivas, la compañía no será capaz de definir un mapa lo suficientemente detallado y útil.

Asegúrate de que el mapa del customer journey que construyas refleja la opinión provista por parte de tus principales stakeholders, lo que va a proporcionar a tu equipo un mayor conocimiento de los pasos dados por el cliente y que involucran a varios departamentos de la empresa. Recibir la opinión e información de las diferentes áreas de la organización garantizará que ningún área en particular tendrá mayor peso en el diseño del mapa, como puede pasar cuando sólo se tiene en cuenta la interacción del usuario vía redes sociales y se olvidan detalles importantes que pueden aportar desde el servicio de atención al cliente. Según The Customer Framework, mapas del customer journey incorrectos pueden generar diseños que, aunque parezcan completos, en realidad no incluyen aspectos importantes del customer journey. El resultado de ello es la toma de decisión en base a un mapa inexacto, algo que seguramente no vaya a traer los resultados esperados.

Además de garantizar que todos los departamentos y equipos estén implicados en el diseño de este recorrido del cliente, no excluyas hacer una investigación detallada del que es el elemento principal de tu mapa: el cliente. MyCustomer.com señala que independentemente de la cantidad de informaciones que puedas adquirir internamente, conocer la opinión del cliente es fundamental. De esta forma, las empresas pueden obtener importantes insights y perspectivas distintas a las que se consiguen únicamente tomando como referencia el análisis de datos y feedback internos.

Creando un Mapa del Customer Journey preciso

A día de hoy, las empresas pueden utilizar analíticas detalladas para conseguir informaciones sobre cómo interactúan sus clientes con la marca online. Esto permitirá que tu mapa sea más preciso y basado en datos más reales y medibles. Estos datos pueden incluir: interacciones en redes sociales, anuncios, navegación web, llamadas al servicio de atención al cliente y cualquier otro tipo de acción que genere información que los sistemas de analítica puedan recopilar y clasificar.

Un análisis preciso es lo que va a garantizar que tu empresa pueda conocer realmente cómo interactúan los clientes con la compañía para obtener un customer journey más preciso. La consecuencia será que los cambios y mejoras que hagas en tus estrategias van a tener mayor probabilidad de afectar positivamente al negocio y satisfacer de forma más efectiva las demandas de tu audiencia.

Descubre cómo crear customer journey maps eficientes y capaces de identificar los principales pain points a los que se enfrentan los clientes en el proceso de interacción con la empresa en el siguiente post: Cómo descubrir los principales pain points en la relación de tu empresa con el cliente.

Transforma tu Customer Journey

Tras conocer más tu customer journey, vas a querer mejorarla al máximo. Aprende a cómo transformar las experiencias de tu cliente de la forma que más encaje con tu empresa a través de este whitepaper.

Lee “Four Strategies to Transform Your Customer Experience”   Rebeca Pimentel 2018-02-16T12:58:43Z
Categories: CMS, ECM

OSGi Fragment Bundles

Thu, 02/15/2018 - 21:54

Okay, in case it is not yet clear, Liferay 7 uses an OSGi container.

I know what you're thinking: "Well, Duh..."

The point is that OSGi is actually a standard and anything that works within OSGi will work within Liferay. You just need to understand the specs to make something of it.

For example, I'd like to talk about OSGi Fragment Bundles. There's actually stuff in the specs that cover what fragment bundles can do, how they will be treated by the container, etc.

The only way that Liferay typically presents a fragment bundle as a solution is for a JSP fragment, but there's actually some additional stuff that can be done with them.

OSGi Fragment Bundles

Fragment bundles are covered in chapter 3.14 of the OSGi Core 6.0.0 specification document.  In technical terms,

Fragments are bundles that can be attached to one or more host bundles by the framework. Attaching is done as part of resolving: the Framework appends the relevant definitions of the fragment bundles to the host's definitions before the host is resolved. Fragments are therefore treated as part of the host, including any permitted headers.

The idea here is that fragments can supplement the content of a host bundle, but cannot replace files from the host. Since the fragment is appended to the host, resources will always be loaded from the host bundle before they are loaded from the fragment.

This is counter to the old way Liferay used to do JSP hooks, where these hooks could actually replace any JSP or static file from the original bundle.  Fragments can only add new files, but not replace existing ones.

So you might now be wondering how the JSP files from a fragment bundle actually do override the files from the host bundle. The answer? Liferay magic. Well, not magic, per se, but there is special handling of JSP files by the Liferay systems to use a JSP file from a fragment before the host, but this is not normal OSGi Fragment Bundle behavior.

What good are they if they can only add files?

Actually you can do quite a bit once you understand that bit.

For example, I was recently trying to help a team override the notification template handling from the calendar-service module, a ServiceBuilder service module for the Liferay calendar. The team needed to replace some of the internal classes to add some custom logic and had been unsuccessful. They had seen my blog post on Extending Liferay OSGi Modules, but the warnings in the blog were taken to heart and they didn't want to go down that road unless it became necessary.

The calendar-service module has a bunch of internal classes that are instantiated and wired up using the internal Spring context set up for ServiceBuilder service modules. So the team needed to provide new template files, but in addition they needed custom classes to replace the instances wired up by Spring when setting up the context, a seemingly difficult ask.

The Spring aspects of the host module in addition to the appending nature of the fragment bundle handling actually makes this pretty easy to do...

First, create a fragment bundle using the host and version from the original.  For this override, it is com.liferay.calendar.service and rather than use a specific version, I opted for a range [2.3.0,3.0.0).

Next I added a new class, src/main/java/com/liferay/calendar/notification/impl/CustomEmailNotificationSender.java.  It was basically a copy of the original EmailNotificationSender class from the same package, I just added in a bunch of log statements to see that it was being used.  Note that I was actually free to use any package I wanted to here, it really wasn't that important.

Next I added a src/main/resources/META-INF/spring/calendar-spring-ext.xml file to the fragment bundle with a replacement bean definition.  Instead of instantiating the original EmailNotificationSender, I just had to instantiate my custom class:

<?xml version="1.0"?> <beans default-destroy-method="destroy" default-init-method="afterPropertiesSet" xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd" > <!-- Replace the Liferay bean definition with our own. --> <bean class="com.liferay.calendar.notification.impl.NotificationSenderFactory" id="com.liferay.calendar.notification.impl.NotificationSenderFactory"> <property name="notificationSenders"> <map> <entry key="email"> <bean class="com.liferay.calendar.notification.impl.CustomEmailNotificationSender" /> </entry> <entry key="im"> <bean class="com.liferay.calendar.notification.impl.IMNotificationSender" /> </entry> </map> </property> </bean> </beans>

So while I couldn't replace the old class, I could add a new class and a new Spring configuration file to replace the old definition with one that used my class.

Once the fragment was built and deployed, it was working as expected.  The project at this state is available here: https://github.com/dnebing/calendar-override

Additionally the team needed to alter the template files.  This was accomplished by adding a src/main/resources/portlet-ext.properties file with a replacement property key for the template to replace pointing to a new file also included in the fragment bundle.  Since the original portlet.properties file has an "include-and-override" line to pull in portlet-ext.properties, when the fragment bundle is appended to the host the replacement property key will be used and the new file from the fragment bundle will be loaded.

What Else Can I Use Fragments For?

While I don't have working code to demonstrate each of these, the working example makes me think you can use a fragment bundle to extend an existing Liferay ServiceBuilder service module.

Since ServiceBuilder modules are Spring-based and the default Spring configuration declaring the service is in META-INF/spring/module-spring.xml, we can use a fragment bundle to add a META-INF/spring/module-spring-ext.xml file and replace a default wiring to a service instance to a custom class, one that perhaps extends the original but overrides whatever code from the original. Spring would instantiate our class, it would have the right heirarchy and should make everything work.

This wouldn't work for services from portal-impl since they are not loaded by OSGi ServiceBuilder host modules, but it should work for those that are deployed this way.

Another idea is that it could be used to override static .css and/or .js files from the host bundle. Well, not override per se, but introduce new files that, in addition to a Configuration Admin config file, could use the replacements in lieu of the originals.

So, for example, calendar-web has a /css/main.css (actually main.scss file, but it will be built to main.css) file that is pulled in by the portlet. We could use a fragment bundle to add a new file, /css/main-ext.scss file. It could either have everything from main.scss with your changes or it could just contain the changes depending upon how you wanted to manage it going forward.  As a new file, it could be loaded if the portal was going for the file.

The original file is pulled in by the portal due to the properties on the CalendarPortlet annotation:

@Component( immediate = true, property = { "com.liferay.portlet.add-default-resource=true", "com.liferay.portlet.css-class-wrapper=calendar-portlet", "com.liferay.portlet.display-category=category.collaboration", "com.liferay.portlet.friendly-url-mapping=calendar", "com.liferay.portlet.header-portlet-css=/css/main.css", "com.liferay.portlet.icon=/icons/calendar.png", "com.liferay.portlet.preferences-owned-by-group=true", "com.liferay.portlet.preferences-unique-per-layout=false", "javax.portlet.display-name=Calendar", "javax.portlet.expiration-cache=0", "javax.portlet.init-param.copy-request-parameters=true", "javax.portlet.init-param.view-template=/view.jsp", "javax.portlet.name=" + CalendarPortletKeys.CALENDAR, "javax.portlet.resource-bundle=content.Language", "javax.portlet.security-role-ref=administrator,power-user,user", "javax.portlet.supports.mime-type=text/html" }, service = Portlet.class ) public class CalendarPortlet extends MVCPortlet {

So we would need the portlet to use a new set of properties that specifically changed from /css/main.css to /css/main-ext.css. This we can do by adding a file to $LIFERAY_HOME/osgi/configs/com.liferay.calendar.web.internal.portlet.CalendarPortlet.cfg file. This file format as defined here: https://dev.liferay.com/discover/portal/-/knowledge_base/7-0/understanding-system-configuration-files and basically allows you to create a file to replace configuration property key values w/ custom versions.

So in our file we would add a line, com.liferay.portlet.header-portlet-css=["/css/main.css","/css/main-ext.css"]. This is the format for including both files, if you just wanted the one file it would simply be com.liferay.portlet.header-portlet-css="/css/main-ext.css". This file would need to be manually deployed to the osgi/configs directory, but once it is done and combined with the fragment bundle, the main.css file and main-ext.css file would be included.

This is the same kind of process that you would use to handle static javascript files pulled in by the portlet's @Component annotation properties.

Conclusion

So OSGi Fragment Bundles can be used for things beyond simple JSP fragment bundles.

I'm hoping what I presented here gives you some ideas on how you might solve problems that you're facing with "overriding" Liferay default functionality.

If you have some ideas, please share below as they may be helpful to others struggling w/ similar issues.

 

David H Nebinger 2018-02-16T02:54:31Z
Categories: CMS, ECM

Adding plugins to the Liferay Alloy Editor

Thu, 02/15/2018 - 16:52

I have been working on adding CKEditor plugins to the Alloy Editor in Liferay DXP and figured I would share what I found. Specifically I was trying to add the YouTube Plugin. There are some articles online at Liferay but they focus more on packaged or custom developed plugins. I got close streaming the files into the Dynamic-Include, but there is a better way (thanks to Chema Balsas for the help!): The trick is to create a OSGI module fragment.

First we create a new Liferay Module Project Fragment – this module won’t have much in it, its purpose is to add the plugin files to the ckeditor module Liferay has in it’s core modules.

To do this, we download and extract the plugin, rename it to a simpler name – in my case youtube, and copy it into the resources/META-INF/resources/ckeditor/plugins folder:

Now all we need to do is edit the bnd.bnd file and inform the OSGI container of our awesome new plugin and that we would like to add it to the existing ckeditor module:

Bundle-Name: base22-alloyeditor-plugins Bundle-SymbolicName: base22.alloyeditor.plugins Bundle-Version: 1.0.0 Fragment-Host: com.liferay.frontend.editor.ckeditor.web

You can now test that it works by deploying our fragment and seeing if the js file is accessible. Go to http://localhost/o/frontend-editor-ckeditor-web/ckeditor/plugins/youtube/plugin.js and hopefully you see the JavaScript file.

As you can see we are accessing the same path as the standard editors plugins, we just added our own directory to it using the fragment. Powerful stuff.

Now that we have the plugin, we need to let the editor know we want to use it, and where. For this we need to create a module which implements the EditorConfigContributor – there is a good article at Liferay covering this as well.

We create our class and declare it as a component that is a EditorConfigContributor and tell it to configure the Alloy editor:

@Component(         property = {         "editor.name=alloyeditor",         "service.ranking:Integer=1000"},         service = EditorConfigContributor.class )

Next we extend the BaseEditorConfigContributor and override the populateConfigJSONObject. This is where we change the JSON that configures the editor. The JSON object will get passed to us and we will adjust it to include our new button.

As a tip, it is really useful to set a breakpoint in the code and look at the overall configuration as you are working with the configuration.

First, we are going to get the extraPlugins section of the configuration JSON and add our youtube plugin. We also want to make sure the ae_uibridge and ae_buttonbridge are loaded to ensure the CK editor plugin is bridged into Alloy editor.

@Override public void populateConfigJSONObject( JSONObject jsonObject, Map<String, Object> inputEditorTaglibAttributes, ThemeDisplay themeDisplay,     RequestBackedPortletURLFactory requestBackedPortletURLFactory) {     String extraPlugins = jsonObject.getString("extraPlugins");     if (extraPlugins == null) {     extraPlugins = extraPlugins+ "ae_uibridge";     }else{         extraPlugins = extraPlugins+ ",ae_uibridge";     }     if(!extraPlugins.contains("ae_buttonbridge")){         extraPlugins = extraPlugins+ ",ae_buttonbridge";     }     if(!extraPlugins.contains("youtube")){         extraPlugins = extraPlugins+ ",youtube";     }     jsonObject.put("extraPlugins", extraPlugins);

Now that the editor knows about our plugin, we need to add the button to a toolbar. We pull the toolbar from the JSON and add our button to it:

JSONObject toolbarsJSONObject = jsonObject.getJSONObject("toolbars"); if (toolbarsJSONObject == null) { toolbarsJSONObject = JSONFactoryUtil.createJSONObject(); }  JSONObject addJSONObject = toolbarsJSONObject.getJSONObject("add"); if (addJSONObject == null) {     addJSONObject = JSONFactoryUtil.createJSONObject(); } JSONArray buttons = addJSONObject.getJSONArray("buttons"); buttons.put("Youtube"); toolbarsJSONObject.put("add", addJSONObject); jsonObject.put("toolbars", toolbarsJSONObject);

Nothing extraordinary is needed in the Gradle or BND files. Deploy your modules and go edit some web content. Your new button should show where you placed it.

This is another way to use OSGI fragments as mentioned by David Nebinger in his post on OSGI fragments.

Christian Klein 2018-02-15T21:52:27Z
Categories: CMS, ECM

6 Vantagens de Plataformas de Experiência Digital com Herança de Portal

Thu, 02/15/2018 - 13:36
Gartner lançou seu primeiro Quadrante Mágico para Digital Experience Platforms e reconheceu a Liferay como um Líder. A análise independente do Gartner avaliou 21 provedores baseando-se na abrangência de visão e capacidade de execução de cada tecnologia, com a Liferay entre um dos quatro Líderes.   O Quadrante Mágico para DXPs substituiu o já reconhecido Quadrante Mágico para Portais Horizontais, processo natural já apontado pelo Gartner através do seu artigo sobre a evolução dos portais em plataformas de experiência digital no ano passado. Plataformas de Experiência Digital (DXPs) fornecem um conjunto de ferramentas para gerenciar experiências que surgiram com a necessidade das empresas oferecerem interações consistentes e conectadas através de todos os pontos de contato, como portais, sites, dispositivos móveis e IoTs.   Conforme apresentado no relatório, DXPs geralmente são originadas de portais ou de  sistemas de gerenciamento de conteúdo (CMS). Tecnologias, incluindo o Liferay DXP, com herança de portal, contam com pontos fortes para conectar negócios tanto internamente como com seu público-alvo.   As seis vantagens apresentadas a seguir de DXPs baseadas em portal podem fortalecer os negócios de maneira única. Enquanto estes elementos podem também ser encontrados em algumas tecnologias originadas de CMS, eles são inerentes a maioria das plataformas de portal e, dessa maneira, contam com uma forte presença naquelas que se tornam DXPs, até em versões iniciais.   1.Capacidade de Integração  Plataformas de experiência digital permitem que empresas realizem sua transformação digital tanto em suas operações internas como nas experiências do cliente que criam. Uma experiência do cliente é considerada excelente quando o cliente consegue alternar perfeitamente a navegação entre distintos pontos de contato, como sites, aplicativos e sistemas de backend, enquanto as empresas coletam dados e fornecem serviços personalizados. Uma empresa deve integrar uma série de sistemas com o intuito de prover interações excepcionais.   DXPs com herança de portal contam com capacidades essenciais para a integração de sistemas de backend, que concede aos clientes, funcionários e outros usuários finais, o acesso a dados que eles precisam em vários sistemas que a empresa utiliza. Por exemplo, dados de clientes armazenados em um CRM ou em uma ferramenta de automação de marketing podem ser unificados e compartilhados através de um DXP com herança de portal. Assim, pode-se economizar tempo e esforço tanto das empresas como dos clientes, ao mesmo tempo em que ajuda as empresas a compreenderem e melhor apoiarem seu público-alvo através dos insights fornecidos por estes dados compartilhados.   2. Foco nas Relações de Longo-prazo com Clientes. Portais são projetados para ajudar empresas a conectarem-se com sua audiência através de interfaces seguras. Isto pode incluir bases de usuários específicas, como clientes que precisam acessar informações e ferramentas integradas às suas experiências. Rivet Logic destaca DXPs com herança de portais como particularmente fortes no apoio às relações com clientes a longo prazo, já que sua capacidade de criar experiências individuais únicas através de logins para apoiar e atender às necessidades dos clientes já é algo estabelecido e fundamental em portais desde que foram criados. Está é uma vantagem em comparação a tecnologias CMS, que foca tradicionalmente em prospectos anônimos.   Liferay fortaleceu uma série de negócios para entender e alcançar seu público-alvo através do uso de portais e DXPs com herança de portal. Por exemplo, o Mercury Insurance Group criou um customer portal para gerenciar cada relacionamento entre cliente e empresa, e fornece componentes de autoatendimento que aprimoram a experiência do cliente. Além disso, a empresa global de TI, Unisys, criou o VantagePoint utilizando Liferay, um portal de serviços corporativos usando funcionalidades de integração para fornecer serviços configuráveis para sua ampla variedade de clientes em todo o mundo. O relatório do Quadrante Mágico do Gartner destaca que departamentos de TI modernos estão encontrando frequentemente como solução DXPs com herança de portais horizontais. As experiências do cliente criadas pela plataforma podem ajudar a aumentar a taxa de retorno de clientes e melhor equipar os times de vendas através de insights aprofundados dos clientes.     3. Suporte ao Ambiente de Trabalho Digital Plataformas de experiência digital atendem uma série de necessidades online, incluindo a habilidade de prover suporte a cada funcionário. Ao alavancar as várias ferramentas e métodos de comunicação já utilizados em portais para funcionários, DXPs com herança de portal podem utilizar-se de métodos já comprovados e transformá-los em ambientes de trabalho digitais. Enquanto CMS e DXPs com herança de portal podem ser utilizadas para criar esses ambientes de trabalho digitais, softwares de portal têm o histórico de ser usado para intranets e áreas de trabalho. Estes cenários incluem interfaces customizadas baseadas nas preferências e atividades de cada funcionário, interfaces mobile-friendly que equipam times em andamento e recursos de gerenciamento de informações que melhoram a forma como uma empresa se comunica internamente. Estes vários elementos são usados em um grau ainda maior em locais de trabalho digitais criados por DXP.   Estes ambientes de trabalho digitais concedem aos times o acesso a uma série de informações fundamentais e ferramentas digitais que os ajudam a melhor completar suas atividades e atender às necessidades dos clientes. Com a flexibilidade de uma DXP, os ambientes digitais podem ser acessados através de diversos dispositivos, de maneira que cada funcionário possa encontrar o que ele precisa a qualquer hora. Com o uso de DXPs, as empresas estão renovando seus portais e intranets com o intuito de trazer o mesmo nível de cuidado e personalização dos clientes para funcionários em um ambiente de trabalho online mais eficiente e útil. Além disso, criar suporte para o local de trabalho para todos os departamentos em uma plataforma única pode eliminar silos da empresa através do compartilhamento de informações e insights.   4. Gerenciando Relacionamentos B2B  Conforme já discutido, portais têm um importante papel nos cenários B2C e B2E. No entanto, eles também são fundamentais para DXPs usadas no contexto B2B.   Muitas empresas B2B utilizavam tecnologias de portal para facilitar as interações ao criar interfaces seguras e úteis para os negócios que eles atendem. Harvard Business Review destaca que os processos modernos de compras B2B estão mais complexos do que nunca, levando a complicações e à falta de satisfação que poderiam ser resolvidos com experiências mais parecidas com a realidade de B2C. Isto traduz-se em uma interface do cliente mais clara e customizada que fornece serviços necessários que atendem a jornada do cliente. DXPs com herança de portal eficientes utilizam as conexões bem estabelecidas criadas pelo software de portal e elaboram uma experiência mais robusta através das suas diversas funcionalidades disponíveis. Desta maneira, empresas B2B podem manter as expectativas e fortalecer as relações com os negócios em uma era onde a competição é muito alta devido às rápidas inovações em experiências online.   5. Gerenciamento Seguro de Dados Insights providos por dados têm papel importante no marketing moderno e nas estratégias de serviço ao cliente para empresas dos diversos tipos de indústria. No entanto, estes dados devem estar seguros contra possíveis brechas para prevenir danos às empresas e às pessoas que confiaram suas informações. Além disso, o público atual gera uma grande quantidade de dados, que são utilizados para ações de marketing altamente personalizadas e estratégias de experiência do cliente. De maneira contrária a softwares de CMS, portais são preparados para suportar uma grande quantidade de usuários e um grande fluxo de informação, que às vezes contém dados sensíveis tanto dos negócios como dos clientes. Assim, DXPs com herança de portais são baseadas em sistemas criptografados e prontos para armazenar e analisar dados para um gerenciamento de informações seguro e perspicaz.    6. Agilidade Digital Conforme destacado pelo Gartner, portais podem ser usados como um framework de arquitetura comum. Esta funcionalidade de uma DXP baseada em portal permite que empresas construam sites e rapidamente reutilize o framework criado para outros pontos de contato. Dessa maneira, os negócios não só asseguram que todos os aspectos da sua presença online são uniformes em termos de funcionalidade e aparência, mas também economiza tempo e dinheiro, evitando uma reconstrução do zero. Ao transformar uma plataforma de experiência digital com herança de portal em uma fábrica de soluções, as empresas podem avançar rapidamente suas estratégias digitais, mantendo o controle sobre a qualidade das experiências individuais.   Potencializando a Herança de Portal com Liferay DXP  Ao nomear Liferay como um Líder, o Gartner ressaltou a flexibilidade e agilidade do Liferay DXP para a criação de experiências altamente personalizadas, a responsividade da empresa e o crescimento orgânico ao lançar novos funcionalidades do produto para atender às demandas dos clientes, e um excelente suporte e experiência do cliente.   O Liferay DXP é construído sobre a herança do Liferay como uma plataforma de portal, usando a tecnologia criada para capacitar a força de trabalho e fornecer aos clientes acesso às informações que mais precisam. Empresas de todo o mundo usaram o Liferay DXP para criar vários aspectos da sua experiência online, incluindo sites, aplicativos móveis e experiências digitais conectadas, além de usar a tecnologia de portal para gerenciar cuidadosamente uma grande variedade de ativos para melhor servir seus clientes e apoiar seus funcionários. Estas vantagens da herança de portal ajudaram a distinguir Liferay DXP no mercado.   Isabella Rocha 2018-02-15T18:36:50Z
Categories: CMS, ECM

Liferay and Docker: Dockerised Liferay Workspace

Thu, 02/15/2018 - 12:58
Introduction

In recent times, containers are becoming more and more important in the software lifecycle management, whether we like it or not. The majority of  the leading software companies have already released a Docker version of their products, Microsoft did a huge work to adapt Windows kernel to Docker containers features, many Cloud services sell container-based solutions: containers are everywhere, and we can't just run away.

Also Liferay is playing its part in this. WeDeploy supports a Docker-based deployment and an official guide on how to deploy DXP on a Docker container has been released. We have come quite a journey since the first liferayctl proposal!

But wouldn't it be really nice to work with containers from the beginning of our development process to the last deploy in a production environment? I know that many blog articles, guides and speeches have been made on how to "Dockerise" Liferay, but a complete guide on how to transform our Liferay Workspace in a Dockerised Liferay Workspace, that allows developers to do everything they did before but with Liferay running on its own container, seems to be missing. And this is why I decided to write this blog article, hoping it can help. Enjoy!

Docker in Liferay Workspace

You can find an example of Docker integration in Liferay Workspace on this GitHub repository. It has been tested on a Windows machine running Docker for Windows, but it should work also with Docker Toolbox or with other OSs. Nevertheless, if you will experience some issues while trying it, please report them hereunder.

With this version of the Workspace, you will be able to start and stop a complex container environment, including Liferay 7 CE GA5 and other optional nodes (a separate DB, an Elasticsearch cluster, an Apache frontend, etc.) with just two Gradle tasks. Moreover, a third Gradle task allows you to build a Docker image of your current local environment, for versioning or test purposes or simply to share it with your colleagues or customers.

But the most important thing is that those features come without compromises: you will be able to debug your Liferay container form Eclipse, open a GoGo shell from your terminal, and even to use Gulp watch during theme development. But let's start from the core: the docker-compose file.

Docker Compose for multi-node environments

The core of the Dockerised workspace is the docker-compose.yml file. Even if you plan to run a simple Docker environment, with a single Liferay container, it's anyway better to have a docker-compose file to manage it. This is because you won't have to change anything in your environment start and stop Gradle tasks when you will be forced to use a more complex environment (and you will, be sure). A docker-compose file can manage multi-container contexts, with multiple nodes, networks and volumes: the only limitation will be your local machine processing power. For example you can:

  • Run a separate DB, like MySQL, when Hypersonic is not enough (quite always). In my example repository you will find a commented example on how to add a MySQL node
  • Run a separate Elasticsearch cluster. You will find a great example on how to do that on this Yasuyuki Takeo's blog post
  • Run a Liferay cluster with two or more nodes. You will find a great example on this Antonio Musarra's blog post on dontesta.it

In order to start and stop your environment, all you need to do is to launch the startDockerEnv and stopDockerEnv Gradle tasks, respectively. Those tasks are based on a bunch of additional Gradle properties that can be defined to partially customise their behaviour. Please refer to README.md file in GitHub repository for more details.

Moreover, the docker-compose file defines a list of bind mounts that link your local deployment folders with the container filesystem, so that the stantard Gradle deployment tasks can be used as usual. For the Document Library, a Docker named volume is used instead, in order to persist DL contents when the container is restarted.

Dockerfile for environment snapshot

Another important element of this Dockerised Workspace is the Dockerfile. It allows developers to create a Liferay container that reflects the current local environment, in order to create a snapshot, by simply running the buildDockerImage Gradle task. Such an image can be used for multiple purposes in the different phases of the software lifecycle. For example:

  • As a test environment, maybe in conjunction with a CI tool (Jenkins, Travis CI, etc.). Since containers don't implicitly persist any generated data after they are removed, they are perfect for testing purposes
  • For environment versioning. When you reach a stable version of your code, you can tag it and release both a code archive and a working Docker image associated to that particular version. This can be realised manually, launching the Gradle task, or with an Automated build technique
  • For continuous deployment, again in conjunction with a CI tool. This requires that you can use Docker also in deployment target environments (or at least in a subset of them). The ideal case is when you can propagate the same container from your local machine to production environment, but also less ambitious solutions are possible
  • For WeDeploy deployment. You can add a wedeploy.json file and deploy your image on WeDeploy, following this guide
Liferay Docker containers

Two simple Liferay Docker containers have been realised for this article, in order to provide a starting point to further customisations. You can find them on Docker Hub or on this GitHub repository. In particular, there are:

  • The liferay-portal:7.0-ce-ga5 image, that inherits from openjdk:8 official container and adds a full Liferay 7 CE ga5 installation, exposing port 8080. The aforementioned Dockerfile in Dockerised Workspace inherits from this image
  • The liferay-portal:7.0-ce-ga5-dev image, that inherits from the previous container, adding some features that facilitate the development process. The aforementioned docker-compose file creates a container based on this image

In particular, with the latter image a developer can:

  • Run Liferay in developer mode. The portal-developer.properties file is attached to Liferay
  • Debug Liferay as a Remote Java Application. This image runs tomcat with JPDA enabled and a socket listening on the exposed port 8000. Docker Compose binds such port to the localhost 8000 port, so that a debugger can be attached directly on localhost:8000 (without having to know the container IP)
  • Open a local GoGo Shell. Setting the module.framework.properties.osgi.console property to 0.0.0.0:11311 (instead of the default localhost:11311 value) and exposing port 11311, a remote connection to the GoGo shell is allowed. Docker Compose binds such port to the localhost 11311 port, so that the standard procedure described here can be used

The only thing that really changes between a standard Liferay Workspace and a Dockerised one is how to see Liferay logs. In a standard workspace, they can be viewed on the Eclipse console, while now you have to use the following command from a standard terminal (or Powershell):

docker logs -f [CONTAINER_NAME] Docker Gulp Watch

Here comes the trickiest part. It would be very nice if also frontend developers could rely on the same Dockerised environment to build up Liferay Themes without compromises. Unfortunately, Gulp watch task doesn't work when Liferay runs inside a container. Furthermore, a non trivial amount of customisation to the standard Gulp pipeline is necessary to make it work.

This is why I decided to create a separate npm hook module to handle this integration. You can find such module published here on npm, together with a short description on how to use it with Yeoman generated Liferay Themes.

Basically, this module overrides some Gulp watch and deploy tasks, in order to copy files from a local .web_bundle_build folder to the container file system, using docker cp command. This allows Liferay runtime to succesfully update its packages. Moreover, since this process decouples files managed by Gulp from those handled by Liferay, it seems to solve also some file permission issues that occur on Windows systems and cause Gulp watch to stop working.

Conclusions

We reached the end of this containerised journey.
To sum up, this is an example of how Docker can be integrated into Liferay Workspace, so that developers can rely on all its beautiful features without be constrained to break their habits. I hope that such a guide can be useful to the community. If you have further ideas PLEASE share them hereunder: I hope that this journey is only another step in a much longer one.
Happy Liferay Coding!!!

Iacopo Colonnelli 2018-02-15T17:58:32Z
Categories: CMS, ECM

Either Hybrid or Native. Is that the question?

Wed, 02/14/2018 - 05:33
In the very beginning of every mobile app project, we can have to face a tough decision: should I go for a native approach to make the most of the device capabilities and optimize the user experience, or should I prefer a hybrid development to make progress faster even though the result may be not as good. And you have to choose either one or the other. A few years ago the answer was quite easy: the hybrid technology was not ready yet (actually, ten years ago it didn’t exist).   Nowadays, the hybrid approach is mature enough to be considered an actual alternative, specially for enterprise apps. Besides hybrid, we also have a slightly different approach, called cross-platform, which consist of using third-party tools and languages that produce native code.   If you need a deeper understanding about native,  hybrid and cross-platform approaches, you can check  this webinar where we talk about it.   So in these days, the decision “native vs hybrid” is a difficult one: each company, project and team have different needs. You need to know the company, the market, the project goals, the team… the context, after all, to make the best decision. And when you know your context, you have to consider several factors. I found companies considering the following factors:
  • Know-how: Is my team able to do a native development both for Android and iOS? or maybe I only have access to web developers. In my opinion this is a critical factor.
  • Technical reasons: Is it possible to do the app without native code? Some apps require a tight integration with the device, and they make the most of sensors and device capabilities (camera, GPS, RFID) Others want a perfect UI with super-fluid and advanced animations and transitions.
  • Political/subjective/trend reasons: my competitors are using native, I read Facebook gave up on hybrid, my colleagues/developers say hybrid sucks... you know. 
Also, this decision has three important characteristics that makes it even more dreaded:
  • It’s a binary decision (almost): your app will be native or hybrid, but it can't be both at the same time. If you go for the hybrid path, it’s difficult to add advanced features that use native (Cordova plugins are an alternative, but not perfect). On the other hand, if you go for the native path, it’s tricky to add hybrid (HTML) content: you need to tweek a lot with embedded WebViews.
  • It’s a final decision, you can’t go back: maybe you want to start fast and small, with a simple hybrid development, and that works great. But a few months later, you need to starting implementing new features in native. You’re done because you need to start from scratch. Most of the hybrid projects regret because at some point, the app is technically limited. Also native projects regret because adding simple features can be difficult and slow.
  • It's a initial decision: you need to make the decision up-front. And that's probably the worst moment to decide (you know nothing, John Snow). It's so risky that the manager responsible for that usually asks for advice more than twice (and that's probably the reason why the Internet is full of articles about "hybrid vs native")
In the last year, we’ve been thinking deeply in this problem, and we believe we found a flexible way to approach mobile development without being constrained by that initial & final & binary decision. 
  • What if you don't need to decide once, at the very begining (decision per-app) and you can decide several times during the life of the app (decision per-feature)?
  • What if you can change your decision without starting from scratch if you think you chose wrong?
  • What if you can combine both approaches instead of choosing one or the other?
If you like this new approach, stay tuned. We really believe we found the sweet spot in the “native vs hybrid” dilemma!   Jose M. Navarro 2018-02-14T10:33:56Z
Categories: CMS, ECM

¿Cómo adoptar el modelo Fast Fashion de forma responsable?

Tue, 02/13/2018 - 09:13

El concepto de fast fashion está cambiando la industria de retail.

Desde hace años, en la industria de la moda se ha trabajado para lanzar las nuevas colecciones al tiempo que aparecían las nuevas tendencias. Y, hoy los retailers están trabajando para hacer que los productos de las pasarelas de la moda lleguen a las tiendas en el menor tiempo posible, de forma más rápida que nunca. El resultado es un mercado de retail que responde rápidamente a los cambios en las tendencias, ofrece más de las cuatro temporadas tradicionales y hace que los clientes esperen encontrar los productos en las tiendas sin demora. El ideal moderno del “fast fashion” tiene como ejemplo las tiendas Walmart y Zara, que están acercando las tendencias de la moda de las pasarelas y showrooms a las tiendas en tiempo récord para ofrecer las últimas tendencias.

Sin embargo, recientes estudios han demostrado que a medida que las marcas intentan producir en masa los nuevos diseños, en el menor tiempo posible, la industria de retail está aumentando los residuos, perjudicando a los entornos de trabajo, que se ven afectados por una demanda creciente./p>

La pregunta principal es: ¿Cómo puedes afrontar la adopción del modelo fast fashion de forma responsable respetando a tus empleados y al medio ambiente en general? La solución radica en transformarse digitalmente y mejorar la forma en la que las empresas operan mediante la tecnología moderna de retail.

Garantizar la velocidad en todas las áreas es la clave para una implementación exitosa de las estrategias fast fashion. Mientras que muchas empresas ya aplican esta visión a los procesos de fabricación de los productos y de manipulación de los materiales utilizados, reducir los tiempos en todas las áreas de forma constante y rápida puede ayudar a que tu empresa se mueva con más agilidad que nunca sin causar un daño excesivo, ni malas condiciones de trabajo. Las siguientes estrategias están diseñadas para aprovechar la tecnología moderna de retail para reducir el perjuicio resultante de la operativa de estos negocios, eliminando los efectos negativos que actualmente afectan y se asocian a los retailers. Para que estas mejoras puedan tener un impacto positivo en tu compañía, considera cómo cada una de ellas puede ser aplicada a tu empresa de retail, conforme a sus particularidades.

Explotar el análisis de datos/h2>

Una importante característica del fast fashion es la capacidad de anticiparse con acierto a las tendencias y los gustos de la audiencia. Zara se ha convertido en un referente del fast fashion moderno debido a la puesta en marcha de una estrategia que buscaba comprender mejor los intereses de su público objetivo a través del análisis de datos.

Zara revolucionó el proceso típico de previsión de tendencias y de abastecimiento de los almacenes de las tiendas, sustituyéndolo por una estrategia que consistía en la provisión de una pequeña cantidad inicial del nuevo producto. Después, recopilaba los datos provenientes de las ventas y los comparaba con los SKUs (número de referencia en almacén) del departamento de logística. Además, Zara cuantificaba qué estilos, colores y otros detalles eran los más vendidos, utilizando esa información para llevar a cabo los siguientes diseños y pedidos. El resultado fue un ciclo a corto plazo en el que se eliminaban los estilos menos populares y se enfocaba la producción a aquellos que tenían mayor probabilidad de venta.

Mientras que cada tienda de retail tiene que adaptar su estrategia a sus objetivos en particular, lo más importante es que Zara siempre se centra en los datos y profundiza en los detalles más pequeños con el fin de generar insights extremadamente valiosos. No solo es crucial recopilar datos de tu equipo de ventas y de los inventarios de manera clara y medible, sino también interpretarlos correctamente. El éxito puede significar un inventario optimizado y reduciendo los productos que no son populares entre tu público objetivo.

Optimizar la Entrega

Tal como demuestra la compra de Jet por parte de Walmart, un aspecto importante del éxito del fast fashion es la forma en la que una marca hace llegar sus productos a sus clientes. Si bien el uso efectivo del análisis, como discutimos anteriormente, ayuda a mantener el stock apropiado en los inventarios, los retailers deben hacerlos llegar rápidamente a los clientes para cumplir las expectativas de la era del fast fashion.

A través del uso de Jet, Walmart fue capaz de incorporar un algoritmo de precios en tiempo real en su tienda online, lo que permitió aplicar una reducción en el coste de los artículos conforme se agregaban más productos al carrito de la compra. Pedidos de compra mayores implican menores gastos de envío, tanto para clientes como para la tienda, además de una disminución de desperdicios causados por el proceso de envío. Combinado con otros descuentos, el algoritmo es parte de una estrategia para aumentar las compras online, disminuir los gastos de envío y fomentar la parte online del negocio. Además, la creación reciente del Walmart Pay les permitió a los clientes comprar artículos a través de su dispositivo móvil mientras estaban en la tienda física, facilitando a los usuarios obtener de forma más rápida los productos que desean. Según PYMNTS, el uso de la aplicación por primera vez ha crecido un 31,7% en Junio 2017, con respecto a Marzo del mismo año y sigue demostrando un crecimiento estable de su uso.

Además, otras empresas como Rent the Runway, servicio de alquiler de ropa para ocasiones especiales, ha explotado sus datos y simplificado sus procesos internos para predecir mejor las necesidades de sus clientes y atender a sus deseos de recibir los productos en plazos de un día, con el objetivo de estar a altura de sus expectativas. Algo que han impulsado compañías como Amazon. El envío de productos a clientes en menos tiempo acelera los ciclos de compra, algo fundamental en el fast fashion.

Facilitar la compra

El fast fashion consiste en algo más que únicamente proveer los productos a los clientes lo más rápidamente posible. Es también permitir que estos mismos clientes conozcan, se interesen y compren estos productos rápidamente. De esta manera, los retailers pueden reducir los tiempos entre la creación del inventario y la venta, así como analizar los datos provenientes de los procesos de compra para utilizarlos como apoyo para decisiones futuras.

A día de hoy, los clientes esperan altos índices de usabilidad y procesos de pago rápidos durante la compra online. Además, las experiencias omnicanales de retail acercan más que nunca los procesos de compra online y offline. Mediante el uso de tecnologías de retail para fomentar el interés del cliente por los productos online, y la finalización de la compra en la tienda física, los retailers pueden facilitar y agilizar los ciclos de compra de su público objetivo.

Transforma Digitalmente tu empresa de retail

Satisfacer las demandas actuales del fast fashion no es el único beneficio de la transformación digital para los retailers. Ya sea ofreciendo a los clientes la experiencia online que esperan o equipando a tus empleados con las herramientas y tecnologías modernas necesarias, la transformación digital del sector retail puede tener numerosos beneficios. Lee más sobre la temática y empieza tu proceso de transformación digital.

Lee el Whitepaper   Maria Sanchez 2018-02-13T14:13:33Z
Categories: CMS, ECM

Adaptive Media Released

Tue, 02/13/2018 - 06:32

I am very pleased to announce the first release of Adaptive Media available for Liferay 7 GA5 and Liferay DXP. Below you can find the links to download the app from Liferay Marketplace.

Download Adaptive Media DXP Download Adaptive Media CE
What is Adaptive Media?

In case you are unfamiliar to Adaptive Media and you want to know more about how this powerful app can help you to deliver the right content to the right device I recommend you to read our official User Guide and Developer Tutorials.

In case you prefer a video, you can also see the presentation of the feature in Liferay Devcon 2017.

This is a sneak peak of what you can do with Adaptive Media:

The Adaptive Media app tailors media in your portal to the device consuming it. Since users often consume media on multiple devices that have different screen sizes and capabilities, you should make sure that your portal presents that media in a manner suitable for each device.

The source code of Adaptive Media is available in GitHub


Installation

Adaptive Media can be installed from Liferay Marketplace. The app is composed of multiple modules and all of them are installed by default, although some of them are optional. You can see a list and description of the module in the documentation. 

If you are installing Adaptive Media in a Liferay installation that has images added in Documents and Media you might want to run some upgrade commands using the Gogo console.

If you are interested in supporting animated GIFs you will also need to install a separate command line tool named Gifsicle as described in the documentation.

Adaptive Media installation in Liferay Portal 7 GA5 requires an additional step. Please make sure to read the installation documentation if you are using this particular Liferay Portal version.
Kudos

Special thanks goes out to the Collaboration Team (formed by devs, qa engineers, designers, product managers, tech writers, etc) and for everyone in the community sharing their feedback and tests with the Adaptive Media early access beta program.


Bug Reporting

If you have found a bug in the Adaptive Media released you car report the issue on issues.liferay.com and select "Adaptive Media" as the affected component. 


Known Bugs

In Liferay Portal 7 GA5 deploying Adaptive Media will throw some console errors. These errors go away after restart and they have no functional impact on the application. This is reported in LPS-76624

Sergio González 2018-02-13T11:32:56Z
Categories: CMS, ECM

Angular 2+ Portlets in DXP

Thu, 02/08/2018 - 15:59

So I've been working a lot more with Angular 2+ recently (Angular 4 actually, but that is not so important) and wanted to share some of my findings for those of you whom are interested...

Accessing the Liferay Javascript Object

So TypeScript is sensitive to defined variables, classes, objects, etc.  Which is good when you want to make sure you are building complex apps, type safety and compilation help to ensure that your code starts on a solid foundation.

However, without a corresponding .ts file to support your import of the Liferay javascript object, TypeScript will not be able to compile your code if you try to use the Liferay object.

That said, it is easy to get access to the Liferay object in your TypeScript code.  Near the top of your .ts file, add the following line:

declare var Liferay: any;

Drop it in like after your imports but before your class declaration.

This line basically tells Angular that there is an object, Liferay, out there and it is enough to pass the compile phase.

Alternatively you can use the following syntax:

window['Liferay']

to get to the object, but to me this is not really the cleanest looking line of code.

Supplying Callback Function References to Liferay

So much of the Liferay javascript functions take callback functions.  For example, if you wanted to use the Liferay.fire() and Liferay.on() mechanism for in-browser notification, the Liferay.on() function takes as the second argument a Javascript function.

But, when you're in your TypeScript code, your object methods are not pure javascript functions, plus as an object instance, the method is for a particular object, not a generic method.

But you can pass a bound pointer to an object method and Liferay will call that at the appropriate points.

For example, if you have a method like:

myAlert(event) { alert('Received event data ' + event.data); }

So if you want it to be called on a 'stuff-happened' event, you could wire it up like:

ngOnInit() { Liferay.on('stuff-happened', this.myAlert.bind(this)); }

The this.myAlert.bind(this) is used to bind up sort of a proxy to invoke the myAlert() method of the particular instance. If someone does a:

Liferay.fire('stuff-happened', { data: 'Yay!'});

Liferay will end up invoking the myAlert() method, providing the event object, and the method will invoke the alert() to show the details.

Sometimes it is advantageous to have the callback run inside of a zone.  We would change the above ngOnInit() method to:

constructor(private ngZone: NgZone) {} myZoneAlert(event) { this.ngZone.run(() => this.myAlert(event)); } ngOnInit() { Liferay.on('stuff-happened', this.myZoneAlert.bind(this)); } Using NgRoute w/o APP_BASE_HREF Errors

When using NgRoute, I typically get runtime browser errors complaining Error: No base href set. Please provide a value for the APP_BASE_HREF token or add a base element to the document.

This one is pretty easy to fix.  In your @NgModule declaration, you need to import the APP_BASE_HREF and declare it as a provider. For example:

import { BrowserModule } from '@angular/platform-browser'; import { NgModule } from '@angular/core'; import { FormsModule } from '@angular/forms'; import { APP_BASE_HREF } from '@angular/common'; import { AppComponent } from './app.component'; @NgModule({ declarations: [ AppComponent ], imports: [ BrowserModule, FormsModule ], providers: [{provide: APP_BASE_HREF, useValue : '/' }], bootstrap: [AppComponent] }) export class AppModule { }

The important parts above are (a) the import of APP_BASE_HREF and (b) the declaration of the providers.

NgRoute Without Address Bar Changes

Personally I don't like NgRoute changing the address bar as it gives the really false impression that those URLs can be bookmarked or referenced or manually changed.  The first time you try this, though, you'll see the Liferay error page because Liferay has no idea what that URL is for, it doesn't know that Angular might have taken care of it if the page were rendered.

So I prefer just to block the address bar changing.  This doesn't give false impressions about the URL, plus if you have multiple Angular portlets on a page they are not fighting to change the address bar...

When I'm routing, I always include the skipLocationChange property:

this.router.navigateByUrl('path', { skipLocationChange: true }); Senna and Angular

Senna is Liferay's framework that basically allows for partial-page updates for non-SPA server side portlets. Well, it is actually a lot more than that, but for a JSP or Struts or Spring MVC portlet developer, it is Senna which is allowing your unmodified portlet to do partial page updates in the rendered portal page w/o a full page refresh.

Senna may or may not cause you problems for your Angular apps. I wouldn't disable it out of the gate, but if during testing you find that hokey things are happening, you might try disabling Senna to see if things clear up for you.

Find out how to disable Senna here: https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-0/automatic-single-page-applications#disabling-spa

I say try your app w/o disabling Senna first because, well, if you disable Senna globally then your non-SPA portlets revert to doing full page refreshes.

Conclusion

So that's really all of the tips and tricks I have at this point.

I guess one final thing I would leave you with is that the solutions presented above really have nothing to do with Liferay. That's kind of important, I found these solutions basically by googling for an answer, but I would leave Liferay out of the search query.

When you think about it, at the end of the day you're left with a browser with some HTML, some CSS, some Angular and non-Angular Javascript. Whatever problems you run into with Angular, if you try to solve them generically that solution will likely also work for fixing the problem under Liferay.

Don't get too hung up on trying to figure out why something in Angular is not working under Liferay, because you are not going to find a great deal of articles which talks about the two of them together.

 

David H Nebinger 2018-02-08T20:59:52Z
Categories: CMS, ECM

7 Cambios en los negocios digitales que vendrán en 2018

Tue, 02/06/2018 - 10:29

Las empresas están evolucionando constantemente la forma con la que operan, conectan con su audiencia objetivo y compiten en sus sectores.

Si bien este es un proceso continuo que cambia a medida que lo hacen la tecnología y el panorama de la industria, el comienzo de un nuevo año es un momento apropiado para predecir y empezar a diseñar acciones que tengan en cuenta las nuevas tendencias y cambios que se producirán a lo largo del año.

A continuación describiremos las tendencias en las operaciones digitales que probablemente van a influenciar, a distintos niveles, a una multitud de industrias y a sus negocios. Mientras que estos cambios van a exigir una cierta reestructuración de los planes de negocio tanto a corto como a largo plazo, es importante estar atento y llevar a cabo una planificación para evitar quedarse desfasado al respecto de la consideración de las nuevas exigencias, ya sean de tus clientes, como de las nuevas tendencias operacionales para el negocio.

1. Estrategias de Targeting Contextuales

Las reglas de protección de datos introducidas por el Reglamento General de Protección de Datos (GDPR) suponen que las empresas tendrán que gestionar con cuidado, y de conformidad con esta normativa, el uso de los datos de los usuarios en sus objetivos de marketing. Mientras que las técnicas de audience targeting pueden verse afectadas por el GDPR, Forbes destaca que las estrategias de targeting contextuales pueden ayudar a las empresas a dirigirse a sus clientes potenciales en base a informaciones detalladas, que se ajusten a los estándares de gestión de datos y cree un marketing personalizado y efectivo.

2. Aumento de la Seguridad en los Pagos

En 2017, los casos de robo de datos y de identidad han puesto de relevancia la vulnerabilidad de muchas organizaciones y las consecuencias de poner en riesgo datos sensibles de los clientes. The Star, destaca que las empresas deben estudiar las posibilidades de combatir este tipo de amenaza a través de soluciones modernas. Alternativas como el blockchain o la biometría, se irán considerando e incorporando al conjunto de funcionalidades adoptadas en el esfuerzo de mejorar la seguridad a medida que aumenta tanto el número, como la variedad de los métodos de pago por parte de los clientes.

3. Un aumento de las redes WAN

Tal como ha anunciado Dimension Data, la recientemente nombrada como tecnología WAN ( Wide Area Network) va a experimentar un considerable aumento en su nivel de adopción en 2018. Mediante la implantación de una red de comunicaciones que puede cubrir un área geográfica extensa, al tiempo que mantiene las capacidades de control de sus administradores, la tecnología WAN ayuda a las organizaciones a tener una mejorar la conexión entre oficinas, la consistencia de los datos, la arquitectura del sistema, el flujo del tráfico, etc. Este aumento en la adopción de la tecnología WAN refleja cómo las empresas modernas están intentando crear redes más amplias que mantengan un equilibrio entre la necesidad de acceso generalizado a los datos y de garantizar su seguridad.

4. La creciente importancia de la transparencia

Según Marketing Dive, los clientes hoy solicitan una mayor transparencia a las organizaciones al respecto de sus prácticas, alianzas con otras compañías y políticas de negocio. Este aumento en la concienciación por parte de los usuarios significa que las empresas tendrán que enseñar a sus clientes no solo cómo operan, sino que también tendrán que comercializar sus productos o servicios de forma efectiva, protegiendo sus informaciones más sensibles. Las compañías que están buscando atender a estas demandas por parte de sus clientes deben crear una estrategia basada en la transparencia, que no comprometa a sus procesos de negocio.

5. Extendido uso de la asistencia robótica

Las empresas llevan tiempo destacando el auge del software robótico, como los chatbots y las herramientas de automatización. Sin embargo, se espera que 2018 sea el año en el que los asistentes robóticos estén presentes la mayoría de las grandes compañías. Esta aceptación, tanto de los empleados como de los clientes, hará que las audiencias esperen experiencias aún más personalizadas en todas las industrias. Según CMS Wire, la gestión de estas expectativas marcará una diferenciación entre las compañías que las proporcionen y las que no.

6. El concepto de “Marketing de Milisegundos”

Llegar a los clientes y responder a sus intereses se está convirtiendo en un proceso cada vez más rápido. Gracias al uso de la Inteligencia Artificial y otras tecnologías modernas, las empresas son capaces de comparar el histórico del cliente con múltiples anuncios potenciales en pocos segundos para aprovechar al máximo las oportunidades de marketing posibles. Según AdWeek, se espera que en 2018 las empresas trabajen para conseguir el “marketing de milisegundos”. Esta es una técnica que utiliza algoritmos complejos para hacer anuncios y ofertas individuales de forma mucho más rápida de lo que es capaz de hacerlo una persona. Mientras que este es un nivel difícil de alcanzar para muchas compañías, es un escenario ideal al que muchas intentarán llegar.

7. Midiendo Costes por Iniciativas

Comprender los éxitos y los fallos de las iniciativas emprendidas por parte de una empresa requiere de un esfuerzo extra para que sea posible calcular el ROI (retorno de la inversión) exacto de cada una de ellas. Con una diversidad tan grande de canales y métricas utilizadas por empresas a la vez, Forbes prevé que las compañías van a empezar a considerar métricas como: el coste por impresión impresión (CPM), por click (CPC), por lead (CPL), por píxel (CPP) y otros para determinar el un coste por iniciativa (CPE, cost per experiment). Lo que puede generar una visión más detallada y medible de la variedad de esfuerzos realizados por las empresas en 2018.

Prepara tu negocio para la transformación digital

Mientras los negocios digitales siguen evolucionando, las empresas de todas las industrias se deben equipar con la tecnología necesaria para mejorar sus operaciones. Descubre cómo hacer esto posible a través del uso de plataformas de experiencia digital.

Lee “Plataformas de Experiencia Digital: Diseñadas para la Transformación Digital”   Rebeca Pimentel 2018-02-06T15:29:34Z
Categories: CMS, ECM

Five critical CMS capabilities for public services

Mon, 02/05/2018 - 11:44
Choosing the right Content Management System (CMS) has always been instrumental in the success of any organisation’s digital services. But today, with the citizens of all ages expecting more from digital services than ever before, choosing the right website platform has never been so vital to encourage people to use your digital services and drive efficiencies. New devices, technologies and apps are constantly emerging, making the task of digital transformation even more arduous for public sector organisations trying to keep up with consumer’s digital demands. So in 2018 and beyond what exactly should a public sector service be looking for in a CMS? In this blog I will take a look at the long list of requirements – and where public sector organisations tell us they hit the wall – to highlight those critical capabilities project teams should be aware of before adopting a CMS. 1. A user-centric admin interface First things first. Everybody on your team needs to feel comfortable using the new CMS, and be able to efficiently carry out their work. A friendly user interface that presents the various members of a team with the access and functionality they need to carry out their role is paramount.  This also extends to the content editor, where communications and web personnel are often the most regular users – requiring fast and streamlined workflows. Features like bulk image uploading, drag-and-drop page building and simple formatting tools will all help make it easier and more efficient to write and publish content such as blogs or press releases and publish to all relevant channels. For larger organisations, the ability for the IT team to author templates and workflows for each role within the organisation will help remove IT / web team bottlenecks, and also ensure the website(s) have a consistent structure and look and feel at the source. 2. Asset Management A CMS shouldn’t just be capable of uploading, downloading and storing assets. It should also make it easy for your team to search through those assets in order to find what they’re looking for.  Much thought is given to the structure of public-facing parts of a website, but the experience of those staff accessing the site is also vitally important. A proper content strategy and taxonomy will make it easier and more efficient for users to update a document such as a pdf because that document can be found easily according to its metadata, taxonomy information and if appropriate workflow status (is it approved / final?).  With a proper content strategy and taxonomy, the right CMS encourages reuse of content and makes auditing and archiving and data management manageable over time. 3. Collaboration And Workflows Having a strong content editor is important, but most content workflows start several stages before a piece of content is updated or new content published. At some point, that content needs to be entered into the CMS and prepared in the necessary format for publishing. Workflow and Collaboration capabilities can further streamline operations and reduce subsequent edits and fixes to live content by taking at least part of this process inside the CMS.  For example, the web team may wish to enable an administrator to revise a page that details a service for citizens which must be reviewed by a compliance officer before it is published. Alternatively, an external contractor could post an update that is then reviewed for style and messaging by the communications team they publish. If you have a Document Management System or storage system, consider whether your CMS will integrate the functionality you need.    4. Omni-channel delivery & personalisation Being able to deliver your content and engage audiences across devices and channels is an uphill struggle for many public sector entities. Consumers already expect content on their smartphones and tablets, but their expectations are also growing for a wider range of channels such as smart home assistants (Amazon Echo, Google Home). The starting point is to ensure your CMS (and the theme you use) can deliver content effectively via a web browser using Responsive Web Design approach (for example Bootstrap) or Adaptive Web Design approach (optimised at the server for the device).  If your project needs to provide a high degree of interaction then a mobile app or hybrid web/app approach may be required to deliver the quality of user experience required. A headless CMS is able to decouple the management of content from its presentation and offers an efficient way to deliver content to any channel.  Another important way to improve the citizen's experience is personalisation. If service users receive only information that is relevant to their area, about the services they use and in their chosen format/ language/channels then they will more engaged and adoption will increase. Personalisation is a fast-moving area of technology development, so be sure to evaluate the CMS personalization engine and roadmap. Can it help segment, understand and tailor customer experiences across those channels? This article will help you learn more about delivering personalised content.   5. Multi-site Compliance mandates accessibility – to generalise each citizen must receive equal quality of service, regardless of their age, language or other demographic.  But budget holders must wring out efficiencies and reusability. This suggests fewer sites, less complexity, lower operational costs.  These are just some of the priorities to juggle at the coal face. Here, you may need to look at multiple sites to cater for different audiences or serve different public-facing entities. For example, if two local councils share services they may each need a public facing site or homepage that displays relevant announcements, information, services and branding but the self-service portal could be shared and accessed by both groups of residents. By building multiple websites, each with their own domain name on the same platform, the relevant services and content can be reused across the two sites and the IT and hosting resources managed centrally. For example, the New South Wales Department for Education provides public websites for 2,044 schools from a single platform. Where services need to be delivered in two languages, also look at the localisation requirement – multi-site is one option if the content is unique to that audience, else built-in multi-language capabilities can help to serve multiple versions of a page if a significant amount of content must be served in multiple languages.  The elephant in the room  With the essentials out the way, let's turn our focus to the one area that differentiates a good website from a great citizen experience: integration.  Integration helps in two key areas. Firstly, a CMS with a strong set of integrations will help you keep up to date with new opportunities. “Login with Facebook” might simplify login as an off-the-shelf plugin, but it’s probably not the security and identity management you actually need. Can you integrate system x,y,z? To transform the user experience and achieve the sort of channel shift most public services require it’s essential to connect the back office systems staff use every day. So, an organisation using SAP to manage finance or a CRM system to coordinate across teams must draw the required information from these systems to deliver useful and actionable information for self-service portals. A proprietary platform that does not allow you to build custom applications and integrate the systems of record upon which public services are administered will only hinder your digital transformation, as your developers will need to bridge the gap between the systems (or worse still wait for a solution from the vendor).  The bottom line? No integration, no transformation. Choosing Wisely Choosing a CMS has always been a delicate task, but in 2018 and beyond, you need to consider the demands of the consumer — which is precisely why integration with other systems and open standards is so vital. So, my advice is to get these essentials covered, and then focus on perfecting the front-end user interfaces. Because if your project is lacking foundations, you’ll need to develop custom applications or finance other tools to plug the glaring gaps before you get a chance to transform experiences.   Why does integration improve digital services?

Explore how Liferay DXP helps organisations move from web content management to delivering digital services.

Read more   Robin Wolstenholme 2018-02-05T16:44:43Z
Categories: CMS, ECM

The Power of Patience

Fri, 02/02/2018 - 11:01

So, as a developer, I'm like usually whacking my whole runtime environment and starting over.

Why? Well, regardless how much I try to keep it clean, cruft will find its way into the environment. I'm left with users I don't want, content I don't want, pages I'm not using any more, sites created to demo something I'm not demoing any more...

So I'll throw out my data directory, drop my database and create a new one, purge old logs, modules, osgi/state and the work directories, ... Basically I get back to a point where I am starting up a brand new bundle, all shiny and new.

One of the things I often find when I do this, though, is that I'm a lazy developer.

So for awhile I was actually writing code that had dependencies on some environmental aspect. For example, my code would assume that a custom field had been created, roles or organizations were defined, ...

When I would bring up the environment, my code would fail because I had forgotten to create the dependent data.

So I got a little smarter, and I learned about the Liferay Upgrade framework. I now use this framework when writing my modules so I can just deploy my modules and, if the dependent data is missing, it will be created automagically. This works really great and, from a deployment perspective, I can promote my modules to test, QA, and prod knowing that my modules will create whatever they have to have to function properly.

This has been working really well for me, well, until today.

Today I did one of my purges and then fired up the environment and my upgrade process was failing.

I had created an upgrade process that was creating a custom field for the User model object. The code totally works when deploying to a previously-running instance, but I was getting an error during startup after the purge because my code was executing before the portal finished loading all of the default data. So one of the things you need for a custom field is a company id to bind them to, but my upgrade process was running before the first Company record was created.

Not company record, no company ID, and my code was just throwing all kinds of exceptions.

So I was effectively still being lazy. I was assuming that my code always ran at a particular time and that certain things were already available, and I found that when starting up from a clean state my assumptions caused my code to fail.

Basically I wasn't waiting for a good time for my code to execute (well, I didn't think I had to wait).  As a module developer, we can all often assume that if our code works on a hot deploy, well then it will always work. The problem, of course, is that environment startup we really don't have control over when our modules load, when our components start. As far as OSGi is concerned, if the references have been resolved and injected, the component is good to go.

But often times our components may have some sort of dependency that is hard to declare. For me, I was dependent upon the initial Company record being available, and I can't really declare a dependency on that which OSGi would be able to verify. In this forum thread, the code wanted to unload a component that had not been loaded/started when the componen t was activated, so sometimes the right thing happened and sometimes it didn't.

So the key is to identify when you have code that really needs to wait on something, but also to have something identifiable to OSGi to wait on.

What if you can't identify something for OSGi such as the initial Company record? Or the creation of some service in a different module that you don't want to declare as an @Reference in your component?

One trick I like to do to solve this case is to add a final dependency on portal startup. By adding the following to your @Component class, you will typically get the right outcome:

@Reference(target = ModuleServiceLifecycle.PORTAL_INITIALIZED, unbind = "-") protected void setModuleServiceLifecycle(ModuleServiceLifecycle moduleServiceLifecycle) { }

That's it. This code basically has OSGi wait to start your component until the portal has been initialized. Note that I'm not doing anything with the injected object; I'm just forcing OSGi to delay the start of my component until it can be injected.

Adding this line to my Upgrade class, I did my purge stuff and started up the portal. After the portal was initialized, the Company record is guaranteed to be available, and my Upgrade had no problem creating the custom field.

Success!

So, keep this in mind if you need to ensure that some component doesn't try to do its thing too early in the startup process.

Oh, and if you just need to enforce a start sequence between your own components? Well, just remember that OSGi will not start a component until its @References can be injected. So if B depends on A, and C depends on B, just add the necessary @Reference guys to B and C. At startup, OSGi will be able to start A (since it has no dependencies), which means it can then start B and finally start C, guaranteeing the startup sequence that you need to have.

David H Nebinger 2018-02-02T16:01:33Z
Categories: CMS, ECM

Las 6 ventajas competitivas de las Plataformas de Experiencia Digital heredadas del Portal

Thu, 02/01/2018 - 07:34

Gartner ha divulgado su primer Magic Quadrant para Digital Experience Platforms (Plataformas de Experiencia Digital, DXP), en el que ha reconocido a Liferay como líder. Este análisis independiente, permitió a Gartner evaluar 21 proveedores en base a su visión completa y su capacidad de ejecución y de integración, entre el conjunto de funcionalidades ofrecidas; un contexto en el que Liferay ha sido nombrado como uno de los cuatro únicos líderes de este nuevo cuadrante.

El Cuadrante Mágico para DXP es el sustituto del antiguo Cuadrante Mágico para Portales Horizontales, lo que se puede considerar un paso natural ya que Gartner predijo la evolución de los portales hacia las plataformas de experiencia digital el año pasado. Las DXPs ofrecen un conjunto de herramientas para una gestión de experiencias coherentes y conectadas en cada etapa del customer journey y sus diferentes touchpoints, como pueden ser los portales, websites, móviles y dispositivos IoT.

Según la explicación de las tecnologías analizadas en el informe, las DXPs suelen tener una herencia de portal o de sistemas de gestión de contenidos (CMS: content management system) en su tecnología. Proveedores, como Liferay DXP, que tienen sus raices en los software de portal tienen su principal fortaleza en el hecho de que son capaces de conectar a las empresas tanto con su público interno, como con su target externo.

A continuación describimos las 6 ventajas de las DXPs basadas en plataformas de portal y que pueden empoderar los negocios de una manera única. Mientras que algunas de estas ventajas también se encuentran en algunos CMS, En la mayoría de los casos, estas son inherentes a la mayoría de las plataformas de portal y, por tanto, tienen una fuerte presencia en aquellas que evolucionan a DXP, incluso durante la fase de lanzamiento inicial, por lo que las probabilidades de que encuentres estas ventajas en esta tipología son mucho más altas.

1. Capacidades de Integración

Las plataformas de experiencia digital permiten que las empresas afronten el proceso de la transformación digital tanto en lo que respecta a sus operaciones internas como a su oferta de experiencias de cliente (UX). Las UX modernas dependen de la facilidad y consistencia con la que un cliente pueda llevar a cabo un proceso accediendo desde los diferentes puntos de contacto disponibles: desde un website a las aplicaciones, pasando por los sistemas de back-end y otros touchpoints, todo ello mientras la empresa recopila sus datos para analizarlos posteriormente y ofrecerle así un servicio personalizado. Las compañías deben ser capaces de integrar la gran variedad de los sistemas ya existentes para poder proporcionar excelentes experiencias de usuario.

Las DXPs con herencia de portal tienen las competencias fundamentales para integrar los sistemas de back-end, lo que permite que ofrezcan a clientes, empleados y otros usuarios acceso a las informaciones que sean necesarias a través de múltiples aplicaciones de la empresa. Por ejemplo, los datos del cliente almacenados en un CRM u otras herramientas de automatización de marketing pueden ser unificados y compartidos a través de una DXP basada en una plataforma de portal. De esta forma se consigue un ahorro de tiempo y de esfuerzo tanto para las compañías como para los clientes; ayudando así a las organizaciones a entender mejor a su audiencia objetivo a través de las conclusiones extraídas de esta compartición de datos.

2.Foco en crear relaciones con el cliente a largo plazo.

Los portales están diseñados para ayudar a conectar las empresas con su público objetivo a través de interfaces seguras. Esto puede incluir bases de usuarios específicas, como clientes que necesitan acceder a información y herramientas de forma integral, a través de experiencias consistentes. Rivet Logic, destaca las fortalezas de las DXPs basadas en tecnología de portal en la construcción de una relación a largo plazo con el cliente, gracias a su capacidad de creación de experiencias individuales únicas desde el login hasta el soporte. Además, el servicio al usuario ha venido siendo la principal función de los portales desde sus orígenes. Esta puede ser considerada otra ventaja competitiva con respecto a las DXPs provenientes de los CMS, ya que estas últimas están tradicionalmente más centradas en prospects anónimos.

A través de su DXP con herencia de tecnología de portal, Liferay ha ayudado a una gran variedad de negocios a comprender y comunicarse mejor con su público objetivo. Como hizo con el Mercury Insurance Group, que ha creado un portal para gestionar la relación que cada cliente tiene con la compañía a lo largo del tiempo y ofrecerles los auto-servicios necesarios, algo que mejora su experiencia. Además, la empresa global de IT, Unisys, ha creado el VantagePoint con Liferay, un portal de servicios que utiliza funcionalidades de integración para ofrecer servicios configurables para los clientes que tiene en alrededor del mundo.

El informe del Magic Quadrant de Gartner destaca el hecho de que los departamentos más modernos de IT suelen encontrar la solución en las DXPs provenientes de los portales. Las experiencias resultantes ayudan a aumentar el número de clientes fidelizados, además de dotar al equipo de ventas de información relevante.

3. Soporte para un lugar de trabajo digitalizado

Las plataformas de experiencia digital suplen diversas necesidades online que surgen en la vida cotidiana de los trabajadores. Aprovechando las diversas herramientas y métodos de comunicación que ya se utilizan en los portales de empleados, las DXP con herencia de portal pueden utilizar los métodos ya probados anteriormente, y expandirlos para crear un ambiente de trabajo digitalizado robusto. Mientras que tanto las DXPs basadas en CMSs, como aquellas que tienen herencia de portal son válidas para crear estos espacios de trabajo, el software de portal viene siendo usando tradicionalmente para crear las intranets de los empleados. Algunas de las funcionalidades ofrecidas por los portales son las interfaces personalizadas en base a las preferencias y funciones del trabajador, su capacidad mobile-friendly, permitiendo que tu equipo pueda actuar sobre la marcha, así como sus capacidades de gestión de información, lo que va a promover una mejor comunicación interna. Estos diversos elementos se utilizan en mayor medida en los espacios de trabajo digitales creados por DXPs.

Los lugares de trabajo digitalizados dan a los equipos acceso a una gran cantidad de información y a herramientas digitales que les ayudarán a completar mejor sus tareas y dar respuesta a las necesidades de los clientes. Gracias a la flexibilidad ofrecida por una DXP, estos espacios de trabajo son accesibles a través de cualquier dispositivo permitiendo que los empleados encuentren las informaciones que necesitan en cada momento. Además, de esta forma, las empresas están renovando sus portales e intranets con el objetivo de proporcionar a sus trabajadores el mismo nivel de importancia y cuidado que tienen con sus clientes, convirtiendo el ambiente de trabajo en un espacio más colaborativo y agradable. La consecuencia del uso de una única plataforma para dar respuesta a las necesidades de todos los departamentos, será la eliminación de los silos de la compañía a través de la creación de una cultura de comunicación que va a facilitar el flujo de informaciones y insights sobre el cliente.

4. Gestión de las relaciones B2B

Tal como se ha mencionado, los portales tienen un gran rol en las relaciones B2B y B2E. Sin embargo, tienen un importante papel también en los escenarios B2B.

Muchas empresas del sector B2B, han utilizado la tecnología de portales para facilitar sus relaciones con otras compañías a las que prestan servicios, creando interfaces útiles y seguras. Harvard Business Review destaca que el moderno proceso de ventas B2B se ha vuelto más complicado que nunca, lo que genera confusión y una insatisfacción que puede resolverse si se reenfoca, abordando estas experiencias como se hace desde los procesos B2C. Esto significa tener una interfaz más clara y personalizada que ofrezca los servicios demandados y que se adapte a las fases del customer journey. Las DXPs provenientes del portal utilizan las conexiones ya establecidas por su antecesor y las suman a sus nuevas capacidades. Al hacer esto, las empresas B2B pueden cumplir con las expectativas de sus usuarios y fortalecer las relaciones comerciales con sus clientes, en una era donde la competencia es alta dada la rápida evolución de la innovación en lo que respecta a las experiencias online.

5. Capacidades de gestión segura de datos.

La información de valor extraída de los datos tiene un papel relevante para las estrategias de marketing y de servicio al cliente de compañías de todos los sectores en la actualidad. Sin embargo, todos los datos utilizados para obtener estos insights deben ser almacenados de manera segura para evitar posibles brechas de seguridad y prevenir una posible fuga de información que pueda perjudicar tanto a los clientes, como a la propia empresa. Además, en la actualidad, el nuevo tipo de usuario moderno genera una mayor cantidad de volumen de datos, lo que es utilizado para el diseño de de estrategias específicas de marketing y de experiencias de clientes. Al contrario que los CMS, los portales están diseñados para soportar un gran número de usuarios, así como un gran flujo de información que, a menudo, contiene datos sensibles tanto de clientes como de negocios. Por ello, las DXPs basadas en plataformas de portal son desarrolladas sobre sistemas cifrados, listos para realizar una gestión del almacenamiento y análisis de la información de manera segura.

6. Procesos de digitalización ágiles.

Tal como ha sido destacado por Gartner, los portales pueden ser utilizados con una arquitectura de framework común. Esta funcionalidad, presente, por ende, en una DXP con herencia de portal, permite que las compañías creen un website y reutilicen el framework que han creado para construir otros touchpoints. De este modo, las empresas no solo se aseguran de que todos los aspectos de su presencia digital son uniformes tanto en funcionalidad como apariencia, sino que también ahorran tiempo y dinero por el hecho de evitar tener que crear todo desde el principio. Al convertir una DXP basada en portal en una fábrica de soluciones, las compañías son capaces de avanzar con sus estrategias digitales , al tiempo que mantienen el control sobre la calidad de cada experiencia ofrecida.

Sacando provecho de la herencia de portal de Liferay DXP

Al reconocer a Liferay como líder, Gartner ha destacado la flexibilidad y agilidad con la que Liferay DXP puede crear experiencias extremadamente personalizadas, la capacidad de respuesta de la empresa a la hora de desarrollar productos y funcionalidades que tienen en cuenta las necesidades del mercado y su sólida trayectoria en la oferta de un excelente soporte y servicio al cliente.

Liferay DXP se basa en el legado de Liferay como una plataforma de portal, que utiliza la tecnología desarrollada para capacitar a los equipos de trabajo y proporcionar a los clientes acceso a la información que más necesitan. Muchas compañías alrededor del mundo han utilizado la tecnología Liferay DXP para abordar diversos aspectos de la experiencia online que ofrecen a sus clientes y empleados, incluyendo websites, aplicaciones móviles y experiencias digitales conectadas. Esta herencia de portal ha dotado a Liferay DXP de ventajas competitivas que le hacen distinguirse en el mercado.

Accede al Magic Quadrant de Gartner para Digital Experience Platforms

Descubre por qué Gartner ha reconocido a Liferay como líder en el sector en su primer informe del Cuadrante Mágico para Plataformas de Experiencias Digitales y conoce todas las ventajas de las DXPs.

Lee el informe del Magic Quadrant  Rebeca Pimentel 2018-02-01T12:34:06Z
Categories: CMS, ECM