SugarCRM inside of Liferay

Certainly the title of the article may seem a little odd, but I have not found better title. I could give a title like “Integration between CRM ….” but then I was not very convinced!

The protagonists of this short article are: SugarCRM implementing a Customer Relationship Management (or CRM) and Liferay instead implements a Content Management System (or CMS).

We are going through a phase where it is needed more and more integration between most disparate information systems with different responsibilities, it’s like doing a puzzle, combine sets different pieces so that their collaboration allows to reach the goal, trying to maintain a single interface to interact with the whole or parts of the puzzle.

We will then see how it is possible and easy to put SugarCRM “inside” Liferay. Assuming a scenario where Liferay implements a web portal of a hypothetical company would not be something out of the ordinary, give access to CRM from the web portal without having to be forced to open a new browser window and avoid repeating the authentication .

Achieving the goal is really simple with Liferay, it is only an activity configuration of the iFrame portlet, already available with Liferay. As shown in the course of the discussion is applicable to the Community Edition and Enterprise Edition of Liferay, the version used is a 6.1 CE GA2.

1.  Requirements

To ensure that the proposed solution is applicable, it is essential that the following requirements are met:

  • Access to the portal with an administrative role or a role that allows you to add applications (portlets) and configuration options;
  • Ability to perform administrative tasks, such as operations of start, stop and change configurations;
  • URL of SugarCRM.

2.   Behavior

Each user of the portal, so authenticated, you can access directly from the portal to the application of CRM, without repeating the authentication procedure. As introduced above, this is possible through iframe portlets.

The Iframe portlet makes it possible to embed another HTML page inside the current page. Furthermore the user can navigate through the embedded page without loosing the context of the portal page.

The Iframe portlet uses the HTML iframe tag that is part of HTML 4 and is supported in all major browsers. The iframe portlet will adjust to the size of the HTML page if that page is hosted in the same server. The browser will add scrollbars if the embedded page does not fit within the size of the iframe.

An important feature of this portlet and fundamental in this scenario, the possibility to perform the authentication process for us. Supports two types of authentication: Basic and Form, we will use the second method, however, the choice depends on the type of authentication supported by the web application to integrate.

You may have guessed that a prerequisite in order for the authentication to work properly, you must have your username (usually the attribute screen name) and password of the portal coincide with those of CRM.

3.   Configuration

Once you add the portlets on a your page, you just have to continue with the configuration whose main parameters and values ​​are as follows:

  • URL of SugarCRM to which you want to give access;
  • Authentication type:
    • Type: Form
    • Method: POST
    • Username
      • FieldName: user_name
      • Value: @screen_name@
    • Password:
      • FieldName: user_password
      • Value: @password@
    • Hidden Variable
      • module=Users;action=Authenticate

The values ​​shown as @screen_name@ and @password@, then replaced at runtime with the actual values ​​and then sent to SugarCRM in the process of authentication, that’s why it is necessary that the credentials match, in Otherwise you will be necessarily required to manually perform authentication in the form of SugarCRM. In Figure 1 is shown the configuration of the iFrame portlets. The specified URL refers to an instance of SugarCRM CE 6.5 hosted on the Cloud Open Shift.

Figura 1 Configurazione iFrame Portlet per SugarCRM.

Figure 1 Configuration of the iFrame Portlet for SugarCRM.

There is a security mechanism such that your credentials are not stored (in session, cookies, etc …) by default, you can also make sure that only users belonging to a particular role can send your password to external systems through the iFrame portlet.

Figura 2 Creazione del ruolo per l’autenticazione trasperente.

Figure 2 Create a new Role for iFrame Portlet

Through the configuration properties (see the Listing 2) you can enable the storage of the password (unencrypted) in session, and also specify the role to be assigned to users who need to be able to send your password to the outside through the iFrame portlet.

Listing 1 Get clear password from session (Link on Gist ).

Listing 1 shows GetPassword() class IFrameUtil com.liferay.portlet.iframe.util package that retrieves the user’s password from the session, checking the association role/user using the method isPasswordTokenEnabled().

Figura 3 Associazione del ruolo all’utente.

Figure 3 User Roles.

Listing 2 Configuration properties file portal-ext.properties (Link su Gist).

The configuration (see Listing 2) shows the role (a name of your choice) to which users must belong and the explicit instruction to store in session, the user’s password. The application of this configuration requires a restart of the portal. The configuration shown in Listing 2 must be specified in the file portal-ext.properties. This file must be created or found within the directory webapps/ROOT/WEB-INF/classes.

After restarting the portal and set the iFrame portlet, you would login with your credentials to get your workspace ready to use CRM.

Figura 4 Il CRM dentro il CMS.

Figure 4 SugarCRM inside of Liferay.

Figure 5 shows instead the passage of the parameters to the target application, in this case SugarCRM. I have highlighted in particular the password attribute, passed in the clear.

Figure 5 - Sending the password to the instance of SugarCRM

Figure 5 – Sending the password to the instance of SugarCRM

4.   Conclusions

In this short article we have seen how easy it is to integrate SugarCRM “inside” Liferay exploiting the potential provision by the iFrame portlet. Is certainly convenient to be able to authenticate in a transparent manner. This solution can be used to integrate any type of web application.

Antonio Musarra

I began my journey into the world of computing from an Olivetti M24 PC (http://it.wikipedia.org/wiki/Olivetti_M24) bought by my father for his work. Day after day, quickly taking control until … Now doing business consulting for projects in the enterprise application development using web-oriented technologies such as J2EE, Web Services, ESB, TIBCO, PHP.

You may also like...

  • Pingback: Un CRM dentro un CMS « Antonio Musarra's Blog

  • http://www.aegisisc.com/liferay-portlets-development.html Liferay Programming

    liferay is very useful , free and open source also support for multiple programing languages,
    Thanks for sharing Customer Relationship Management.
    it’s helpful and improved my CRM knowledge.

    • http://musarra.wordpress.com Antonio Musarra

      Thanks for the appreciation.

      Bye,
      Antonio.

  • http://twitter.com/gaurav_sharma Gaurav Sharma (@gaurav_sharma)

    Thank you for this tutorial. I tried this out and it works perfectly. One problem I see with this approach is, although you are logged in automatically, you are not logged out once you log out of Liferay. Any idea how to fix that?

    • http://musarra.wordpress.com Antonio Musarra

      Hi,
      Thanks for the appreciation.
      The two systems are decoupled with the iframe in the middle. One solution would be to be with the two systems in SSO, or if either of the two systems belong to the same domain, it would be possible to access the Cookie PHPSESSIONID (Sugar) from Liferay, then calling the logout URL or web service of CRM, passing session id as the value of PHPSESSIONID.

      What do you think?

      Bye,
      Antonio.

      • http://twitter.com/gaurav_sharma Gaurav Sharma (@gaurav_sharma)

        I think the PHPSESSIONID idea sounds like an easier solution. I’ll give it a try and let you know how it works out.