Query on SAP Integration Suite and JMS Queue

[babruvahana]

Hi Experts,

We are working on a solution that needs some retry mechanism within CI as the source doesn't resend the messages if in case of any failures in CI. We are planning to leverage JMS queues for this. However, we have a few concerns about the capabilities of using SAP Integration Suite and JMS Queues together.

Requesting your input on the below:

1. We understand we can create 100 queues per JMS queue, Can we create more than 100 queues per tenant?

2. Are the JMS Resources limited per tenant? If not, any possibility of auto-scaling?

3. Does JMS Queues use the same memory from SAP CI tenant DB to store the messages?

4. It is expected to process 10 million+ messages per day now using SAP CI, the volume might increase in the future.

Is it a better approach to use SAP Integration Suite or we should look for an alternative like Serverless Functions?

Any leads/suggestions are highly helpful.

Regards,

Pavan

[sunny_kapoor · Accepted solution]

Hi babruvahana,

Please find the answers to your questions:

1. Yes, you can get more then 100 queues in a tenant but not via self provisioning. You need to raise a ticket as mentioned in SAP Note 2904202.

2. There is no auto scaling of JMS queues as of today but as mentioned in the above point you can request for more JMS resources by creating a ticket and we do extend quite well. But there is a limit to everything and so is the case with JMS queues per tenant.

3. JMS queues and Database are both different concepts and used for different purposes. Databases are commonly used for storage, and they allow you to access the same information over and over again whereas Message Queues cannot be used for long storage purposes. Once a message has been consumed successfully, it is deleted from the queue. It is mainly used for Aysync processing anfd guaranteed delivery. SO in short your question is not relavant as both are different.

4. It is diffucult to answer just based on the throughput. There are many other factors like payload size, other resource usage like JMS, DB, etc, enterprise integration design patterns and the overall complexity of the flow. For Example: a pass through integration flows can always scale better then the one with message transformation logic, a push based integration flow has better scalability then the pull based, etc.

We suggest to perform the stress/load test, raise a ticket in case of performance issues and can decide accordingly.

Regards,

Sunny

[babruvahana · Accepted solution]

Hi sunny.kapoor2,

Thanks a lot for responding to my queries.

If I understand correctly from the 1 and 2 answers, JMS queues are better off for scenarios that need storing the messages for reprocessing/retrying with short intervals maybe with a few hours with a max retry limit. Just curious to know what is the maximum number of JMS queues available per tenant.

I think I have not framed Q3 correctly, Do JMS and CI share the same storage/memory spaces allocated per tenant? Wanted to know this coz in case a huge incoming volume and messages already stored in JMS for retrying might impact the tenant performance.

Q4: Integration flow is already set up and is stable for now, but I need to include a retry mechanism by leveraging JMS queues. It's an event-driven integration flow, API calls, and Groovy script are used for fetching the payload and for look-ups along with mapping transformations. The concern is when a large number of failures occur due to the non-availability of the Target system (SAP on-premise) we thought of storing them in JMS for reprocessing till the target system availability.

With the expected more volume of messages in the future, wanted to know which is the better approach using SAP Integration Suite or alternatives like Serverless Functions.

Regards,

Pavan

[sunny_kapoor · Accepted solution]

Hi babruvahana,

Kindly raise a ticket to know more about the available JMS respurces per tenant.

As I said message queues and database are two different things and do not share the same stoarge. JMS message queues are created in a separate mesage broker which is different from the database.

Stress/load test can only give the accurate picture but if you have the possibility to move this logic to Serverless Functions then why not

Regards,

Sunny