Tag: crafter

Creating Better Employee and Customer Experiences with Liferay and Crafter

Posted by on June 21, 2016

man-1191845_1280

The modern customer’s needs are ever increasing as they want information combined with the convenience of interacting with your brand whenever and wherever from various digital touchpoints and devices. Meanwhile, employees are demanding digital experiences that facilitate rapid information access, communication and enterprise collaboration.

To meet these demands, organizations are leveraging Web Content Management (WCM) solutions such as Crafter CMS to help deliver consistent and personalized experiences throughout the customer journey. And internally, portal solutions such as Liferay Portal are being used to address a variety of social business and collaboration needs.

But what happens when you want to share the same content across both internal and external sites? Is integration the key? While many organizations are realizing the business benefits of an integrated solution, it’s important to keep in mind that integration isn’t always the answer, and when it is, the approach taken can determine your implementation’s success.

Understanding Platform Differences

Gaining a clear understanding of how each technology can be used for addressing various business needs means recognizing what each technology is under the hood.

At a high level, Liferay Portal is a multi-tenant, site-based platform, allowing the creation of multiple sites — including websites, portals, social collaboration environments, e-commerce, big data solutions, and mobile apps. The sites are built with Liferay’s portlets, all of which sit under the Liferay umbrella, meaning these sites are being published to the web by Liferay.

Crafter CMS, on the other hand, is an enterprise WCM tool with robust content management features — including user-friendly content authoring, in-context preview, workflow, multi-channel publishing, versioning, and content delivery.

Architecturally, Crafter is very different from Liferay in the way content is delivered. Crafter employs a decoupled architecture, where content authoring and delivery occur separately. Crafter’s authoring component, Crafter Studio, is where all the authoring takes place, along with content being managed in an Alfresco repository.

Unlike Liferay, where publishing occurs within itself, Crafter publishes to a completely different environment through Crafter Engine, the delivery component. Crafter Engine is able to serve content to virtually any channel, whether it’s a website using any front-end framework (PHP, .NET, Java, etc.), mobile app, or other third party system. This is the fundamental difference between Crafter and Liferay, and understanding this is a vital part of knowing when to integrate or not.

Perspective Differences

Liferay and Crafter are both powerful platforms that can be used to address a variety of business needs, including many similar, overlapping use cases. This overlap creates confusion around when to use each of these tools and if they should be used together. We’ve seen organizations integrate these products for the wrong reasons, which result in a lot of wasted effort to correct those mistakes.

Determining if your business will benefit from using these two products together requires you to think about perspective. Based on your business needs, if you see a lot of overlap between the two products, then one platform should suffice and it’s probably not a good idea to integrate. However, if there isn’t much overlap, then integration makes much more sense as it allows you to leverage each solution’s strengths.

The amount of overlap really depends on your unique requirements and what you’re trying to accomplish with your website(s). Keep in mind that much of this is attributed to how websites and content management has evolved over the years and its affect on marketing’s needs. Today’s organizational websites have grown to become much more complex, often involving multiple sites that are then integrated with other enterprise systems, such as marketing automation, CRM’s, e-commerce, and analytics to provide a richer end user experience.

The key consideration here is the total number of web assets your organization has. Are you a small organization with just one website, or a large enterprise with a global presence with hundreds of web properties to maintain?

For smaller organizations with only one website, then either Liferay or Crafter on its own is fully capable of addressing most, if not all, content management needs. However, it becomes more complicated when it comes to larger organizations with more sophisticated digital experience needs that typically involve many different sites and touch points.

In the latter case, an example of an integration pattern that doesn’t work is when Crafter is being used solely for managing all web content, where the entire site is then published through Liferay as the front end. This pattern fails because Liferay controls its own look and feel, so trying to control it outside of Liferay breaks its architecture.

When there are multiple sites involved, it only makes sense to use both Liferay and Crafter when Liferay is just one of many delivery channels. An example would be an organization using Liferay for its employee intranet and Crafter to manage its global and regional websites. When the organization wants to publish content that needs to be delivered across all websites along with the intranet, that’s when it makes the most sense to integrate.

In this use case, Liferay manages its own intranet page. Within the page is an area that’s managed by Crafter that enables access to enterprise content while still adapting to the look and feel of the intranet.

 integration-patterns

This decoupled architecture, where content is separate from delivery, also makes it easy to expand and add additional delivery channels (mobile, social, etc.) for true multi-channel publishing. We’ve found this to be a great integration pattern for organizations that desire the flexibility to scale.

crafter-publishing-reference-arch

 

To summarize, Liferay and Crafter are both very powerful at the platform level. If you’re thinking about integrating the two, it’s counter productive to perform a feature by feature comparison. Instead, design your solution based on your use case and not by focusing on features, as many different technologies will have the same features, but address each use case differently. And remember that integration isn’t always the answer, so do your research to understand the pros and cons. When done right, integrations can yield tremendous long-term benefits.

 

JBoss Seam Component wiring options

Posted by on October 29, 2009

At Rivet Logic we do quite a bit of work with the JBoss Seam framework, specifically with our Content Management System integration we call Crafter rivet.

Seam can be used with the Spring bean factory framework, a popular “IoC” or Inversion of Control / Dependency injection framework. Spring enables developers to create instances of java objects known as beans and then to wire them to other java objects. Most people working in J2EE today are familiar with this so I won’t spend any time going in to further detail here. Seam also supports the ability to use java annotations to declare a class as a bean and to specify how it should be wired through what they call out-jection and injection. Check out the Seam website for more details on how the Seam bi-jection mechanics work.

One question that has come up for me many times on consulting engagements is: “which approach to use, Spring or Seam bi-jection?” My experience shows me that the answer is not one or the other. Both approaches have significant benefits and can be used together to create a stronger approach than either one can provide on its own.

Here are some very simple guidelines

When to use Spring beans:

Infrastructure components and services are great candidates for Spring beans

  • Such services are generally singletons within the system. Spring has excellent support for managing and wiring these objects
  • Such service classes are often packaged in separate more commonly used libraries. Hard coding a bean name and wiring within the class definition or strongly coupling to Seam is less desireable.
  • You want a very simple way to override the implementation at deployment time. Consider a scenario where you want to override a DAO. By managing the bean in Spring it is extremely easy to override the bean definition to use an alternate class and configuration in a given environment simply by placing an additional xml file in the classpath

When to use Seam annotations:

Domain specific components are good candidates for bi-jection.

  • They are often fine grained application specific components.
  • Explicitly stating how the component will be wired in the the class file has little impact on its re-usability because its scope is limited to the application at hand.
  • Such components really benefit from one of Seams strongest features in its bean framework: Conversation Scoping. This is the ability to define a life-cycle which is shorter than a session. By limiting the lifetime of a object to its true life-cycle it’s possible to free memory up for other needs within the system. On large, high troughput applications the benefits here cannot be overstated.

By using a combined approach you get the reusability and flexibility of Spring framework with the performance orientation of conversation scoping and ease of development associated with Seam annotations.