SAP Integration Suite is licensed on 2 metrics: tenants and messages. Tenants are usually the number of environments/tiers you have, for example in a 4-tier environment you would have 1 tenant for development, 1 for test, 1 for quality assurance and 1 for production. A certain number of messages is included in the license of SAP Integration Suite (depending on the edition), more messages can be licensed/bought in blocks of 10K messages per month.
For every 250KB, that is sent over Integration Flows, API calls, etc. there is always a message consumed in SAP Integration Suite. There is only 1 exception, when you are leveraging prebuilt SAP-to-SAP integration scenarios and have only configured these flows (not modified), in this case messages will not be counted for those flows.
SAP Note 2942344 describes the message definition in full detail.
Information on the licensing and pricing of SAP Integration Suite is publicly available on the SAP Discovery Center.
Customers can leverage the usage analytics in the SAP BTP Cockpit, to see a monthly breakdown of how many messages they have consumed, how many of those messages were not counted (meaning how many free SAP-to-SAP messages were consumed) and how many messages were counted. This is further described in the blog "Integration Suite - Usage Analtyics".
A monthly integration flow level message breakdown can be viewed in the "Monitor" section in SAP Integration Suite, this is described in the blog "SAP BTP Integration Suite - New Message Metrics"
With this blog I’m trying to open the discussion on some tips to keep the message consumption and size under control in SAP Integration Suite.
So, kicking off the discussion the following 5 tips:
Run integration flows under well-defined boundary conditions
One of the design guidelines for integration flows on SAP Integration Suite is to run integration flows under well-defined boundary conditions. This helps you to increase the performance of your flows and avoid issues and errors. One of the best practices is to limit the size of incoming messages. The messages in Cloud Integration are calculated based on the size of the outgoing messages. Limiting the size of incoming messages could lead to limiting the size of outgoing messages.
On top of that, it also includes other best practices like managing large batch sizes, optimizing integration flows for streaming, optimizing performance and memory footprint, etc.
On the SAP Help Portal it is explained in detail how you can achieve this.
Use ProcessDirect or JMS for exchanging messages between integration flows
Sometimes organizations are leveraging the HTTP(S) adapter for communication between integration flows. This should be avoided as much as possible, instead, organizations should use the ProcessDirect adapter.
The ProcessDirect adapter provides a direct communication between integration flows deployed on the same tenant. As it’s a direct connection, the communication will not be routed over the load balancer of SAP Integration Suite, thus reducing latency and network overhead.
On top of increasing performance, the ProcessDirect adapter will also decrease the number of messages (compared to using the HTTP(S) adapter) as the messages sent over the ProcessDirect adapter are not counted.
The same goes for external queues, they are often leveraged for creating asynchronous integrations but they are not always recommended for this scenario. Every time you publish a message to an external queue you'll consume a message and every time you retrieve it from the external queue and publish it to another endpoint you'll consume a message.
Instead, use the internal JMS queues in SAP Cloud Integration.
This works similar to ProcessDirect, messages are not consumed when publishing to the internal JMS queues, only when they are retrieved from the queue and published to an external system.
Leverage prebuilt integrations as much as possible
SAP provides 3200+ prebuilt integrations on the SAP Business Accelerator Hub, these include many SAP-to-SAP integrations and SAP-to-non-SAP integrations. The integrations can be easily copied to your own tenant and come with the required documentation. This is one of the most important differentiators of the platform, and an important accelerator for integration projects, as it will save you time and money in development and maintenance of your integration flows (SAP also maintains the integrations).
On top of delivering a quicker time to value, the prebuilt integration flows also follow the SAP best practices and guidelines, making them more performant and less prone to errors or uncontrollable message sizes.
Also, as mentioned earlier in this blog, if you use the prebuilt SAP-to-SAP integrations and only configure the endpoints (so no modification on the integration flow itself), SAP will not charge you for the message consumption on these flows.
Enable an event-driven integration strategy
As described in the blog "SAP's Event-Driven Ecosystem Revisited", there are many benefits of enabling an event-driven integration strategy, including real time connectivity and updates in enterprise applications, loose coupling, flexibility, scalability, etc. It’s key in delivering composable architectures.
From the perspective of message consumption, the benefit is that it helps organizations ensuring that integrations only run when necessary and that receivers only receive information that is relevant for them.
It limits the needs for integrations that run on a scheduled basis just to check for updates that happened in the backend. And avoids sending large IDocs to receivers that are only interested in a small part of the information.
Eventually, this avoids overhead and avoids consuming unnecessary messages.
SAP Integration Suite comes with its own event-broker (where 100 events = 1 message), which offers a more lightweight approach to start with an event-driven strategy.
Once your Event-Driven Architectures reach a certain maturity level, capabilities like in-depth monitoring & analysis, the ability to create a network/mesh of brokers, dynamic routing, event replay,... become a must, in this case, SAP Integration Suite, Advanced Event Mesh is the go-to solution for facilitating your event-driven integration strategy.Follow the integration flow design guidelines
When running integration flows productively in SAP Integration Suite, the integration scenario should be designed in line with the best practices. Poorly designed integration flows may lead to issues like errors, but it may also lead to unnecessary usage of tenant resources that could negatively impact the performance of the integration flows and could increase the message consumption.
In tip 1 and 3 of this blog the design guidelines were already mentioned. You can run your integration flows under well-defined boundary conditions, or you can leverage the prebuilt integrations that are already following the best practices.
The integration flow design guidelines are well-documented on the SAP Help Portal.
You can also validate whether your integration flows comply with the design guidelines.
In week 4, of the course "Modernize Integration with SAP Integration Suite" this is also addressed. I highly recommend to go through this course and the SAP Help Portal to get more familiar with the SAP Integration Suite and the design guidelines.
So, these were some tips to keep the message consumption and size under control.
Hope you enjoyed reading this blog!
Curious to hear about your tips and feedback, feel free to share in the comments!
