SAP Eventing with SAP Advanced Event Mesh (AEM)
Receive CloudEvents from SAP Advanced Event Mesh (AEM) and send CloudEvents to AEM.
About SAP Eventing
This consists of three connectors that allow bidirectional communication between Camunda and AEM.
Connector | Description |
---|---|
SAP Eventing Outbound Connector | Send CloudEvents from Camunda to an AEM topic or queue endpoint. |
SAP Eventing Message Start Event Connector | Translate an incoming CloudEvent from AEM into a BPMN Message Start Event triggering a new process instance. |
SAP Eventing Intermediate Event Connector | Translate an incoming CloudEvent from AEM into a BPMN Intermediate Catch Event allowing an active process to continue based on the event. |
The integration uses HTTP
as the transport protocol.
- The incoming connectors act as webhooks, receiving CloudEvent payloads and delivering them into process instances.
- The outbound connector sends
HTTP POST
requests to an Advanced Event Mesh topic or queue endpoints.
SAP Advanced Event Mesh uses Solace Event Broker as its core event broker. This means the terms AEM and Solace Event Broker can be used interchangeably when referring to core eventing functionality.
Prerequisites
As HTTP
is used as the transport protocol, AEM must be configured to use REST messaging.
This enables publishers and subscribers to communicate over HTTP.
The following configuration examples in Camunda build on the Solace tutorial Publish/Subscribe REST Messaging, which provides detailed steps for setting up REST-based publish/subscribe messaging.
Installation
You can install the SAP Eventing connectors directly from the Camunda Marketplace.
Configuration
SAP Eventing Message Start Event Connector
Inbound CloudEvents → BPMN Message
Applying the SAP Eventing Message Start Event Connector generates a unique Webhook URL that starts a new BPMN process instance when invoked.
The Webhook URL is generated only after the initial deployment of the process.
This Webhook URL must be registered as a target in SAP Advanced Event Mesh (AEM).
The host portion of the URL (https://<region>.connectors.camunda.io
) is used when configuring the REST consumer in AEM.
Authentication
In the same REST consumer configuration, set up authentication from AEM to the Camunda Webhook endpoint.
The credentials configured in the Authorization section of the Camunda connector must correspond to the Authentication Scheme used in AEM.
Queue Binding
The path component of the Camunda Webhook URL must be used as the POST Request Target in the Queue Binding of the REST consumer.
Other Configuration Options
The remaining configuration options of the SAP Eventing Message Start Event Connector match those of the HTTP Webhook Connector, except for one key difference:
The default Webhook response explicitly returns a
200
status code and an"OK"
message body, confirming that the CloudEvent was successfully received and acknowledged by Camunda.
Event Flow
When a CloudEvent is received from AEM, all header properties and the body payload are relayed as-is to the target process instance, either:
- At process creation, when using the SAP Eventing Message Start Event Connector, or
- During event correlation, when using the SAP Eventing Intermediate Event Connector.
This ensures that message attributes and payload data from AEM are preserved end-to-end within the Camunda process.
SAP Eventing Intermediate Event Connector
Correlate CloudEvents as BPMN Messages
The SAP Eventing Intermediate Event Connector injects a CloudEvent from SAP Advanced Event Mesh (AEM) into an active Camunda BPMN process instance.
It does this by leveraging the BPMN principle of message correlation.
Any CloudEvent property can be used as a correlation key to map incoming event data to the correct process instance.
Correlation via CloudEvent Body
The configuration options of the SAP Eventing Message Start Event Connector and the SAP Eventing Intermediate Event Connector are identical, except that the Intermediate Event requires an additional Correlation section to be configured.
- In the example above, the process variable
ENCOMGridID
is expected to exist within the process instance. - Its value is compared against the CloudEvent payload (
request.body.FlynnLocationID
). - If both values match, the CloudEvent is considered to be the published BPMN message that is correlated to the corresponding process instance.
Correlation via CloudEvent Metadata
Since HTTP is used as the transport protocol, the CloudEvents specification requires all CloudEvent metadata to be passed as HTTP headers.
In addition, AEM prepends all user properties with the prefix Solace-User-Property-
to persist them in its event engine. For example, a CloudEvent with the property "ce-id"
is represented in AEM as the HTTP header named Solace-User-Property-ce-id
This means that to perform BPMN message correlation based on CloudEvent metadata, reference the corresponding HTTP header name including the Solace-User-Property-
prefix.
Example: CloudEvent HTTP Message
The following is an example of a CloudEvent HTTP request received by Camunda:
{
"request": {
"body": { "FlynnLocationID": "34.0522,-118.2437" },
"headers": {
"host": "<region>.connectors.camunda.io",
"x-request-id": "956de0835ad61a211a20e4755315b413e",
"x-real-ip": "12.123.123.456",
"x-forwarded-host": "<region>.connectors.camunda.io",
"x-forwarded-port": "443",
"x-forwarded-proto": "https",
"x-forwarded-scheme": "https",
"x-scheme": "https",
"content-length": "44",
"authorization": "Basic CaMUnDakZW1v",
"cache-control": "no-cache",
"content-type": "application/json",
"solace-delivery-mode": "Persistent",
"solace-user-property-ce-specversion": "1.0",
"solace-user-property-ce-type": "sap.s4.beh.encom.grid.program.v1",
"solace-user-property-ce-source": "/alan/pager/buzz",
"solace-user-property-ce-subject": "CLU-2.0",
"solace-user-property-ce-id": "Argon-T-01",
"solace-user-property-ce-time": "2018-04-05T03:56:24Z",
"solace-user-property-ce-datacontenttype": "application/json",
"user-agent": "Solace_PubSub+_Enterprise/10.11.1.167"
},
"params": {}
},
"connectorData": {},
"documents": []
}
In this example, to correlate the CloudEvent ce-id
property to a process instance, reference it as:
request.headers.`solace-user-property-ce-id`
in the header field.
Note the "backticks" notation of the header value request.headers.`solace-user-property-ce-id`
to escape the dashes in the header field name.
SAP Eventing Outbound Connector
The SAP Eventing Outbound Connector allows you to send CloudEvents to SAP Advanced Event Mesh (AEM) using its REST messaging capability. It uses the REST messaging capability of AEM to publish the CloudEvent via a HTTP POST
request.
Endpoint
The Endpoint field specifies the URL of your AEM Event Broker.
You can find this URL in the Advanced Event Mesh's web interface by navigating to:
Cluster Manager → Your Cluster → (Service Details) → Connect → Connect with Java → Solace REST Messaging API
On the right-hand side of the interface is the FQDN (Fully Qualified Domain Name) of your AEM broker instance.
Topic / Queue
Specify the target topic or queue path where the CloudEvent will be published.
Neither value should begin with a /
— the connector includes a validation check to prevent this.
Authorization
Select one of the following authorization methods:
None
API Key
Basic
OAuth 2.0
Bearer Token
CloudEvent
While CloudEvent metadata (for example, ce-id
or ce-subject
) is automatically handled by the AEM broker—including the required Solace-User-Property-
prefix, you only need to configure the standard CloudEvent attributes in this connector.
The CloudEvent data is serialized into a JSON body, and both the metadata and data fields support FEEL expressions for dynamic values.
Other Configuration Options
All remaining options are identical to those of the REST Connector, including:
These settings control network behavior and define how response data is mapped to process variables.