SAP Event Mesh – Resource Units

Working with SAP Event Mesh (formerly known as SAP Enterprise Messaging), you might have seen this or similar errors before:

[connection rejected (too much connections)]

Until recently each SAP Event Mesh service instance supported only 10 connections in parallel and there was no option to change this number.

With the SAP Event Mesh update end of January 2021, Resource Units have been introduced: an option to distribute the available resource across your Event Mesh service instances in the same subaccount.

The announcement and further details can be found here: What’s New for Event Mesh

What is a Resource Unit?

Resource Units (RUs) are used to size SAP SAP Event Mesh service instances and the Event Bus on subsccount level. Hence, RUs can be configured on two levels. RUs represent a kind of grouping in Event Mesh for a collection of several resources (connection, queues, etc.). The resources of one RU are described in the table below:

For more detailed descriptions of the messaging resources please check: Scope and Limitations

You can specify resource units on Event Bus (subaccount) level and on Messaging client (service instance) level:

• RUs for the Event Bus/subaccount level are the total amount of RUs which can be distributed across the connected clients (service instances / subscriptions).
• RUs for the Messaging clients/instances are the resources which are allocated for a particular client/instance. The sum of the RUs for all clients must not exceed the total amount of RUs available for a subaccount.

The following table shows the RUs (default, min, max) for Event Bus/subaccount and for Messaging clients:

Resource Units – Event Bus/subaccount

The RUs for Event Bus/subaccount can be specified in the Event Mesh Management UI: Edit Resource Units for a Subaccount

Resource Units – EMS Clients

The RUs for Messaging clients can be specified during service instance creation/update via the following JSON snippet in the service descriptor: Syntax for Service Descriptor

{
  ...
  "resources" : {
    "units" : "10"
  }
  ...
}

A complete example of the service descriptor can be found here: Create an Event Mesh Service Instance.

Existing service instances can either be updated via the Cloud Foundry CLI, or via the UI as described here: Create an Event Mesh Service Instance Using the Cloud Foundry Command Line Interface

Resource Units – Limits

The latest default and maximum limits for the RUs is different if you already have an Event Bus in your subaccount, or if you are just onboarding a new subaccount. For details please see: Scope and Limitations

Messaging via AMQP / MQTT

• Each client connection occupies one connection – if you have e.g. 3 app processes/instances running and all of them have an open connection you need 3 RUs
• Each publisher flow within a connection occupies 1/3 RUs – if you have e.g. 3 app processes/instances running and all of them open a publisher flow you need to have 3 RUs
• Each consumer flow (consume from queues, direct topic subscription) within a connection occupies 1/3 RUs – if you have e.g. 3 app processes/instances running and all of them open a consumer flow you need to have 3 RUs

Messaging via REST / Webhooks

• One RU is required for one Webhook – 1:1 RU:Webhook
• When webhooks are used to consume messages each webhook gets 3 consumers.
• When messages are consumed with REST APIs by polling for messages three consumers are used per queue or topic. These consumers are closed if there’s no active publishing of messages for a period of 30 minutes

Additional information for Cloud Platform Integration

Each AMQP channel (sender or receiver) will need one connection per Cloud Integration worker instance. Using the example where your tenant cluster has currently 5 worker instances:

This means if you have 1 Queue with one sender channel and one receiver channel, you will need 10 connections for this.

Please be aware that the limit of 50 connections is per service instance. You can create multiple service instances of the Event Mesh service. In the Cloud Integration system, you can deploy multiple credentials objects (one per service instance). If you then take different credential objects for different queues, you can work around this 50 connections limit.

The AMQP consumer allows you to configure the maximum number of parallel threads for consuming messages on one worker instance. As the Event Mesh only allows you to have 3 consumers per connection, you should set that number to 3 (at maximum).

Summary

With the introduction of the Resource Units you have now more flexibility to distribute and scale the available resources among your existing Messaging clients/instances. As a result, you might need less Messaging clients/instances, if e.g. Cloud Platform Integration is running on multiple worker instances.

Still you need to be careful with the RUs which are assigned to Messaging clients as they are shared by the different messaging channels / protocols. If you e.g. mix REST messaging and AMQP / MQTT you need to make sure that there are always enough RUs for REST / AMQP.