Pulse as a Microservice Client Extension
The workspace is configured to use the latest Liferay product version.
liferay.workspace.product=2025.q4.12
The Pulse microservice has been upgraded to Spring Boot 3.4.2 and Java 21. It requires a minimum of JDK 17 to run, but is specifically optimized for JDK 21.
If your CI/CD environment (e.g., Jenkins) uses an older JDK by default, you may need to explicitly point Gradle to the correct Java home in gradle.properties.
#org.gradle.java.home=/opt/java/openjdk21
Pulse shares information with Liferay DXP via cookies and therefore, there needs to be a common parent domain. In the case of LXC SM, this could either be lfr.cloud but it could also be a custom domain. In the case of a custom domain, both the Liferay web server and the Pulse microservice need a subdomains with a common parent domains. For example, the DXP could be assigned www.example.com, in which case, Pulse would need something like p.example.com.
There are several environment variables that you need to populate.
The PULSE_COOKIE_DOMAIN variable needs to be set to the parent domain. In the case, where no custom domain is used, then this would be ltr.cloud and in the example.com, case, this would be example.com.
At the time of writing this, there are some additonial environment variables which are needed to make the Pulse microservice run on LXC SM (PaaS). More details can be found here
In the case of COM_LIFERAY_LXC_DXP_DOMAINS, COM_LIFERAY_LXC_DXP_MAINDOMAIN and COM_LIFERAY_LXC_DXP_MAIN_DOMAIN the value is the same. In the example.com example, the value of all three will be www.example.com, i.e. the hostname of the Liferay DXP instance. It should not be prefixed with the scheme, i.e. https:// or have any trailing slashes.
The value of COM_LIFERAY_LXC_DXP_SERVER_PROTOCOL should reflect the scheme being used to access the Liferay DXP. In most cases this will just be https.
There are two environment variables which are needex for LXC deployment. However, problems can be experienced if they are not included here too. The value of LIFERAY_ROUTES_CLIENT_EXTENSION should be /etc/liferay/lxc/ext-init-metadata and the value of LIFERAY_ROUTES_DXP should be /etc/liferay/lxc/dxp-metadata.
All of the client extensions, need to be built and deployed via the CI / CD process in LXC SM, including the Pulse microservice. However, in the case of the microservice, only the configuration needed by Liferay DXP is used. In order to deploy the microservice to the environment, it is necessary to use the lcp command, more details can be found in the Liferay documentation.
The Reporting give a user journey view of campaign interactions. This may include the initial Pulse touch-point / redirect and any further custom events which are recorded.
This custom web component, uses the User Agent defined within the microservice client extension to retrieve the required data from Liferay DXP.
Frontend dependencies have been hardened against security vulnerabilities (jsPDF v4.2.1, SheetJS v0.20.3).
The Campaign Creation form is one of three UI components which are included in the pulse-user-interface-components client extension.
To include it on a page, add the Pulse UI Components widget to the page and then configure it by adding route=create-campaign to the Properties field within the Configuration panel.
This custom web component, uses the User Agent defined within the microservice client extension to submit the campaign to the Pulse microservice.
The Refresh Cache button is a way to request a full refresh of the cache within Pulse. While Liferay Objects are used to persist the data, Pulse maintains an in-memory copy of the data to allow for responsive redirections.
To include it on a page, add the Pulse UI Components widget to the page. This component uses the default route, so it is not necessary to update the Configuration.
This custom web component, uses the User Agent defined within the microservice client extension to request the cache refresh. The microservice will return a job identifier which can be used to check the status of the request.
The Check Refresh Status component provides a way of checking the status of a request to the microservice to refresh its cache. There is a configurable option within the application.yaml which introduces a delay to better simulate a request taking longer to complete.
To include it on a page, add the Pulse UI Components widget to the page and then configure it by adding route=check-refresh-status to the Properties field within the Configuration panel.
This custom web component, uses the User Agent defined within the microservice client extension to check the status of the job.
When the following is executed within a Liferay context then the list of URL tokens currently in the Pulse cache (H2 in-memory DB) is returned.
Liferay.OAuth2Client.FromUserAgentApplication("pulse-micro-service-oauth-application-user-agent").fetch("/api/url-tokens").then((response) => console.log(response))
The following will create a new campaign within the Pulse cache and also persist it using Liferay Objects.
Liferay.OAuth2Client.FromUserAgentApplication("pulse-micro-service-oauth-application-user-agent").fetch("/api/campaigns", {method:"POST",headers:{"Content-Type":"application/json"},body: JSON.stringify({name:"Test",campaignUrl:"/redirect"})}).then((response) => console.log(response))
At this time there are issues with the Liferay OAuth2 Client. It does not pass the Bearer token when the headers are overridden and in the case of this example, the content type needs to be set to application/json in order to be accepted by the microservice API. In order to work around this, the _getOrRequestToken() method is being used and this does not refresh the Bearer token which can lead to 401 responses
The following CURL command will create a new campaign within the Pulse cache and also persist it using Liferay Objects.
curl
--verbose
--header "Content-Type: application/json"
--header "Authorization: Bearer "
--request POST
--data '{"name":"Test","campaignUrl":"/redirect"}'
http://localhost:58080/api/campaigns