Liferay 7: An example of integration with Salesforce.com

Liferay 7: An example of integration with Salesforce.com
Liferay 7: An example of integration with Salesforce.com

A few weeks ago I saw the post Liferay Salesforce.com integration on the Liferay forum of the year 2010. Certainly the post is a little old-fashioned and personally at that time I didn’t even know about Liferay’s existence. The request of Nicolas Raoul (author of the post) was this:

Hello all,

Is there any way to integrate Salesforce.com into a Liferay portal without writing code?

If not, a solution would be to create a new portlet that calls Salesforce.com’s Web Services, but I am wondering if anything already exists that I could just reuse.

I am not asking for perfect integration of everything, but if you know of a portlet that shows some data or allows any Salesforce.com action that would be great already 🙂

Thank you!
Nicolas Raoul

I took the challenge in hand and throughout this article we will look at the modern approach (Liferay 7.x & OSGi) of the solution I developed to integrate OSGi, Liferay 7.x and Salesforce.com as bundles.

 

 

In this repository liferay-crm-sample-integration you will find an example project for the integration of CRM systems. Examples of integration with the Salesforce.com, SuiteCRM and OpenCRX system.

1. What you need to know first

All the developed software referred to is available on my GitHub account which specifically covers two repositories Salesforce SOAP API Client OSGi Bundle and Salesforce Gogo Shell Command Client.

For your integration tests, remember that you must have at least one Salesforce.com Developer account (free of charge). The resources to follow are in-depth points that I recommend reading after reading this article.

  1. Introducing SOAP API
  2. Cheat Sheets
  3. Force.com SOAP API Cheatsheet
  4. Force.com Web Service Connector (WSC)

The two OSGi bundles are compatible with Liferay 7.x and Apache Karaf 4.x and in general can be installed in any container that complies with OSGi R6 specifications. The latest version of the Salesforce SOAP API Client OSGi bundle is publicly available on the Maven Central Repository.

 

2. What you need to build

We are fortunate enough, we do not need a lot of effort in terms of code development. The only fundamental component to prepare is the one that will allow us to talk to Salesforce.com. The tasks to be done are:

  • create the OSGi bundle responsible for communicating with Salesforce.com;
  • create the OSGi bundle that will use the component above to perform actions on Salesforce.com.

We have identified the “pieces of software” that we need to realize and at the end of the construction we should find ourselves in a situation analogous to that shown in Figure 1.

Integrazione Salesforce.com in contesto OSGi

Figura 1. Integrazione Salesforce.com in contesto OSGi

The diagram in Figure 1 shows the two Salesforce SOAP API Client and My Salesforce Bundle App bundles. The first bundle is the one that will communicate with Salesforce.com through the SOAP APIs (exposed by the latter), the second bundle uses APIs instead Java exported from the first bundle in order to perform actions on Salesforce.com (such as login, account creation, etc.).

 

3. The Salesforce SOAP API Client bundle

Salesforce.com exposes a set of APIs via SOAP and REST that allow external systems to interact with it. In this solution I chose to use the SOAP API. Salesforce.com provides the Force.com Web Service Connector (WSC) tool that creates the Java stubs needed to communicate via SOAP and this greatly facilitates the process of creating our OSGi bundle.

Our OSGi bundle will show the following set of Java APIs that can then be used by any other bundle that will need to interact with Salesforce.com.

  1. com.sforce.soap.partner.*
  2. com.sforce.soap.enterprise.*
  3. com.sforce.async.*
  4. come.sforce.bulk.*
  5. com.sforce.ws.*

In the article How to Build a Salesforce SOAP API Client OSGi Bundle you can read all the details related to the construction of the OSGi bundle responsible for communication via SOAP with Salesforce.com and for exporting the Java APIs that will then be publicly available within the OSGi container.

 

4. The Salesforce App bundle

Once we have the Salesforce.com Java API available in our OSGi container (thanks to the salesforce-client-soap v1.2.0 bundle we created earlier), we are able to implement all the integrations we want with Salesforce.com.

As an example application, and for reasons of simplicity, we could make a series of OSGi commands that perform the following actions on Salesforce.com:

  1. salesforce:login: Login on Salesforce.com
  2. salesforce:createAccount: Create an account
  3. salesforce:getNewestAccount: Return the list of the new account

Article Liferay 7 Salesforce.com Gogo Shell Command Client explains in detail the implementation and use of this specific example integration bundle with Salesforce.com.

The two videos published on Antonio Musarra’s Blog YouTube Channel show the integration solution in the Liferay 7 and Apache Karaf context in action.

 

 

5. The next step

Thanks to the OSGi approach we have been facilitated in implementing the solution to the integration problem between Liferay and Salesforce.com. The solution of creating an OSGi Salesforce SOAP API Client bundle responsible for communication via SOAP with Salesforce.com and exporting the Java API in the context of the OSGi container, makes this component very “reusable” (in fact we installed on Liferay and Apache Karaf) .

I would like to receive your comments regarding the solution adopted.

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

Cos'è il progetto CIE/CNS Apache Docker - Developers Italia

In questo video https://youtu.be/TcAzn1POhsM introdurrò il progetto CIE/CNS Apache Docker di Developers Italia (https://developers.italia.it/it/cie/#resourcecontent-3) nato circa due anni fa.

L'obiettivo di questo progetto è quello di fornire un template pronto all'uso che realizza un sistema di autenticazione tramite la Smart Card TS-CNS (o CNS) e la CIE (Carta d'Identità Elettronica) basato su Apache HTTP. Ognuno può poi modificare o specializzare questo progetto sulla base delle proprie esigenze Si tratta di un progetto docker per la creazione di un container che implementa un sistema di mutua autenticazione o autenticazione bilaterale SSL/TLS.

Questo meccanismo di autenticazione richiede anche il certificato digitale da parte del client, certificato che in questo caso risiede all'interno della TS-CNS o della CIE. La particolarità del sistema implementato (attraverso questo container) è quella di consentire l'autenticazione tramite:

  • La TS-CNS (Tessera Sanitaria - Carta Nazionale Servizi), rilasciata dalla regione di appartenenza;
  • La CIE (Carta d'IdentitĂ  Elettronica), rilasciata dal comune di residenza.

Nella versione 2.0.0 il progetto è stato aggiornato per essere uniforme alle linee guida di Bootstrap Italia. A seguire alcune risorse che possono essere utili.

  • Cos’è il progetto CIE/CNS Apache Docker (http://bit.ly/3aJ5Gbl)
  • CIE Carta d'IdentitĂ  Elettronica (https://developers.italia.it/it/cie/)
  • Carta Nazionale dei Servizi (https://www.agid.gov.it/it/piattaforme/carta-nazionale-servizi)
  • Raspberry Pi – Un esempio di applicazione della TS-CNS (https://bit.ly/3hkJ8Aj)
  • Pubblicare il servizio CIE/CNS Apache Docker su Azure Cloud (http://bit.ly/3aPoq8V)
  • Come accedere al portale VETINFO tramite TS-CNS e Mac OS (http://bit.ly/2VFMKq7)