Configuring Queues, Subscriptions, and Security in Event Mesh

Explanation

Moving from concept to practice, configuring Event Mesh begins with creating a service instance in a BTP subaccount, typically via Cloud Foundry (cf create-service) or the SAP BTP cockpit, choosing a plan that matches expected throughput and isolation needs. The service instance produces a set of credentials (a service key or binding) containing the messaging URIs for supported protocols (AMQP, MQTT, REST/Webhook), a namespace identifier, and OAuth client credentials scoped to that instance. Applications running on Cloud Foundry or Kyma bind to this service instance, and the platform injects these credentials into the application's environment (VCAP_SERVICES on Cloud Foundry, or a Kubernetes secret on Kyma) so the application can authenticate without hardcoding secrets. Queue creation can happen implicitly when a consuming client first connects and declares a queue with a subscription, or explicitly via the Event Mesh management REST API, which is useful for infrastructure-as-code approaches where queues and subscriptions are provisioned as part of a deployment pipeline rather than left to runtime side effects. When defining a subscription, you specify a topic filter pattern; Event Mesh supports single-level and multi-level wildcards so a queue can, for example, subscribe to acme/sales/*/created (single-level wildcard for entity) versus acme/sales/# (multi-level, catching all sub-levels under sales). Overly broad wildcards can unintentionally pull in irrelevant traffic and increase queue processing load, so subscription design should be reviewed against actual business needs. Security in Event Mesh is enforced through OAuth 2.0 client credentials tied to the service instance; each instance's credentials are scoped so that a client can only publish or consume on topics permitted by its instance configuration. Some plans allow you to define topic-level permission rules restricting which credentials may publish versus subscribe to specific topic patterns, which is important in multi-team landscapes where you want producer teams to have publish-only rights and consumer teams to have subscribe-only rights, preventing accidental cross-team message injection. Transport security uses TLS for all supported protocols, and credentials should be rotated periodically following your organization's secret management policy, ideally automated through a credential store rather than manual regeneration. From a runtime perspective, when integrating with Integration Suite, a Cloud Integration flow can use a JMS or AMQP sender/receiver adapter configured with the Event Mesh service key to consume or publish messages as part of an integration flow, letting you combine event-driven triggers with the mapping, routing, and enrichment capabilities of Cloud Integration. This is a common pattern where an S/4HANA extension publishes a business event to Event Mesh, and an integration flow consumes it, transforms the payload, and calls a downstream non-SAP system via a different adapter (SOAP, REST, OData). Operationally, monitoring queue depth, message age, and dead-lettering behavior is essential. If a consumer is down or slow, messages accumulate in the queue up to a configured retention/size limit; once exceeded, new messages may be rejected or older messages dropped depending on the queue's configured behavior, so alerting on queue depth thresholds before hitting limits is a standard production practice. Understanding these configuration levers—service plans, queue provisioning method, subscription wildcards, and OAuth scoping—forms the backbone of implementing Event Mesh correctly in a real landscape.

Code example

# Creating an Event Mesh service instance via Cloud Foundry CLIcf create-service enterprise-messaging default my-event-mesh-instance \  -c '{"emname":"acme-integration","options":{"management":true,"messagingrest":true}}' # Creating a service key to obtain credentialscf create-service-key my-event-mesh-instance my-event-mesh-keycf service-key my-event-mesh-instance my-event-mesh-key # Example subscription definition (conceptual JSON used via management REST API){  "queueName": "billing-consumer-queue",  "subscriptions": [    { "topicFilter": "acme/sales/order/created" },    { "topicFilter": "acme/sales/order/cancelled" }  ],  "maxQueueSize": 5000,  "deadLetterPolicy": "route-to-dlq"} // Cloud Integration JMS/AMQP sender adapter (conceptual configuration fields)// Connection: <messaging URI from service key>// Authentication: OAuth2 Client Credentials// Queue Name: billing-consumer-queue

Real project scenario

An integration team building a cross-system order fulfillment process provisioned a dedicated-plan Event Mesh instance to isolate high-volume order events from a shared default-plan instance used for lower-priority notification events. They configured separate OAuth credentials for the S/4HANA extension (publish-only) and the fulfillment microservice (subscribe-only), and set up a Cloud Integration flow with an AMQP sender adapter to consume order-created events, enrich them with customer master data via an OData call, and forward the enriched payload to a third-party logistics API. Queue depth alerts were configured in the monitoring dashboard so the on-call team was notified if the fulfillment service fell behind by more than 500 unprocessed messages.

Common mistakes

• Letting queues be created implicitly in production without documenting naming conventions, leading to orphaned or duplicate queues over time • Granting broad publish-and-subscribe credentials to every application instead of scoping OAuth clients to least privilege • Using overly broad multi-level wildcard subscriptions that pull in unrelated topics and overload consumer processing • Not setting or monitoring maxQueueSize and dead-letter policies, causing silent message loss when a consumer outage exceeds retention limits • Hardcoding service key credentials in application code instead of relying on injected environment bindings, creating security and rotation problems

Best practices

• Provision queues and subscriptions declaratively as part of deployment automation rather than relying on implicit runtime creation • Scope OAuth credentials per application role (publisher vs subscriber) rather than sharing one broad credential across teams • Set explicit maxQueueSize and dead-letter policies, and alert on queue depth and message age before limits are reached • Choose service plans (default vs dedicated) based on throughput isolation needs rather than defaulting to the cheapest option • Document topic naming conventions and wildcard subscription patterns centrally to avoid unintended cross-team message consumption

Interview angle

Expect questions on how Event Mesh credentials are scoped and injected into Cloud Foundry or Kyma applications, and how you would design topic-level permissions to separate publisher and subscriber responsibilities across teams. Interviewers may also probe your understanding of wildcard subscription patterns and how you would handle a scenario where a consumer is offline for an extended period, testing your knowledge of queue retention, dead-lettering, and idempotent reprocessing.