Triggering Events in Camunda with Liferay Webhooks
You can send payloads from Liferay’s webhook object actions to your Camunda process instances. This enables inbound communication from Liferay to Camunda. For example, you can use a form submission to kick off a workflow process in Camunda. Start Events, Boundaries, and Intermediate Catch Events can receive the webhook payload. Download the connectors you need from https://github.com/liferay/liferay-portal/tree/master/modules/etl/camunda/element-templates.
Example Start Event Webhook: Use a form submission with a webhook to kick off a new Camunda process instance.
Example Intermediate Event: Wait for a response from a Liferay webhook. When its payload arrives, advance the Camunda process instance if the correlation keys match. A common scenario is sending a notification to a Liferay user (using the outbound connector) to update a form (e.g., add an attachment) and then wait for the incoming webhook request.
Example Boundary Event: You can respond to an object update action using an attached Message Boundary Event to receive the webhook payload while a task is active. You can change the workflow path or trigger a parallel path depending on what’s in the payload. This often requires a gateway to handle the different paths.
Enabling Inbound Communication from a Liferay Webhook to Camunda
-
In Camunda, design a webhook-triggered process:
- In your BPMN diagram, use a Start Event, Intermediate Catch Event, or Boundary event with the Liferay Webhook Connector template that matches the Camunda element.
- Configure the Webhook ID (part of the incoming URL); if you change it from the randomly generated default, make sure it’s unique.
- You can set up secret-based authorization for security. In production environments, use Camunda secrets for secure storage.
- If incoming messages should be used to start a new process instance, you can filter them with Activation Conditions using FEEL expressions.
- If incoming messages should continue a running process, link messages to process instances with Correlation Keys using FEEL expressions.
-
In Camunda, deploy the diagram and copy the Webhook URL from the Camunda Modeler’s properties panel.
-
In Liferay, configure a webhook action) in a Liferay object (or another event source):
- Set the webhook URL to the one copied from Camunda.
- If you set a secret in Camunda, use it in Liferay’s webhook configuration. In production environments, use Camunda secrets to store your credentials securely.
-
In Camunda, map the incoming webhook payload data to variables.
- If the payload should be stored in one variable, use result variables to store the payload.
- If the payload should be parsed to multiple variables, use result expressions (FEEL) to extract and store data from the payload.
The result expression processes the payload from the Liferay webhook in Camunda. This result expression produces four variables in Camunda modeler from an
Employeeobject’s form submission:{ "accountExternalReferenceCode": request.body.objectEntryDTOEmployee.properties.accountNumber, "userFirstName": request.body.objectEntryDTOEmployee.properties.firstName, "userLastName": request.body.objectEntryDTOEmployee.properties.lastName, "userEmailAddress": request.body.objectEntryDTOEmployee.properties.email }
You can reference these variables in a later step in the workflow.
With the inbound connection, you can trigger events in Camunda from Liferay objects and other webhook event sources.
Refer to the Camunda documentation for more information.
Activation Conditions
You can set activation conditions that must be met to start a new workflow instance from the incoming message (i.e., the webhook payload). These conditions apply to Liferay Connector Start Events, Intermediate Events, and Boundary Events. They’re useful when you only want to trigger a process for specific events or when certain data criteria are met by the webhook payload. For example, if the payload has the following body,
{
"body": {
"classPK":35399,
"companyId":"13509014921405",
"objectDefinitionId":"35324",
...
}
...
}
An activation condition value might use it to dictate that the company ID has a certain value:
=(request.body.companyId="13509014921405")
If the condition is not met, the message is filtered out of the workflow and the BPMN event is never activated. Leave the activation condition empty to process all incoming messages every time.
Correlation Keys
Correlation keys are used by Intermediate Catch Events and Boundary events in a BPMN diagram to match the incoming payload with an ongoing process instance. Set two correlation keys:
Correlation Key (Process): use a FEEL expression to define the correlation attribute (i.e., an existing variable) in the ongoing process instance.
Correlation Key (Payload): use a FEEL expression to extract the correlation attribute from the incoming payload.
If the keys match, the BPMN event is triggered.
For example, if your correlation key is a process variable named myCorrelationKey and you want to correlate it with the companyId property in this webhook payload request body,
{
"body": {
"classPK":35399,
"companyId":"13509014921405",
"objectDefinitionId":"35324",
...
}
...
}
Your correlation key settings look like this:
Correlation Key (Process): =myCorrelationKey
Correlation Key (Payload): =request.body.companyId
Learn more about correlation keys in the messages guide.
Message ID expression
The Message ID Expression is used by Camunda to ensure that each incoming message is only processed once. Subsequent duplicate messages are discarded to avoid triggering multiple process instances erroneously or advancing a workflow multiple times. You can set this in Start Events, Intermediate Catch Events, and Boundary Events configured to receive messages.
Set a FEEL expression that extracts a unique identifier from the incoming payload. If a message with the same ID arrives again within a configured de-duplication window, it’s ignored by Camunda to prevent unintended duplicate actions.
Learn more about how message IDs influence message correlation in the messages guide.
Message TTL
The Message TTL is an optional field for setting the time-to-live (TTL) for buffered incoming messages that cannot be processed immediately. TTL defines the duration the message can be buffered in Zeebe (Camunda’s process automation engine) before being processed by the workflow instance (i.e., used in correlation or activation). If it is still unprocessed after the TTL duration is up, the message is discarded.
Specify the Message TTL as an ISO 8601 duration. For example, PT1H sets the TTL to one hour. Learn more about Zeebe’s TTL concept in the message correlation guide.
Activating the Liferay Webhook Connector
You must deploy the diagram to activate your webhooks and begin receiving their payloads from Liferay. Once you deploy, your Liferay webhook is activated and made publicly available.
The URLs of exposed Liferay webhooks use the following pattern:
http(s)://[base URL]/inbound/[webhook ID]
[base URL]is the URL of the connector’s component deployment. When using the Camunda 8 SaaS offering, this typically contains your region ID and cluster ID, found in your client credentials under the API tab within your cluster.[webhook ID]is the ID (path) you configured in the properties of your Liferay Webhook connector.
If you make changes to your Liferay webhook connector configuration, you must redeploy the BPMN diagram to apply the changes.
When you click on a BPMN event with a Liferay Webhook connector applied to it, a Webhooks tab appears in the properties panel. This tab displays the URL of the Liferay Webhook connector for every cluster where you have deployed your BPMN diagram.
The Webhooks tab is present in the web modeler only in the Camunda 8 SaaS offering, but you can use the Liferay webhook connectors in the desktop modeler and with Camunda 8 self-managed. However, Liferay webhook connector deployments and URLs are not displayed in the modeler in those applications.