Welcome, fellow integrators, to post number six in this blog post series, where I talk to SAP Cloud Integration practitioners, developers, architects and enthusiasts about their favourite feature of the platform. For this post, I had the opportunity to chat with an old colleague of mine, who is a very skilled integration developer and architect: Piotr Radzki.

First off, could you introduce yourself briefly, please?

Sure, Morten! First of all thanks for inviting me to your series, I really enjoyed each post so far!

My name is Piotr Radzki and I’m a freelance SAP integration architect and expert. Currently I live in Warsaw, Poland. I help my clients with integration strategy, design and development with a main focus on SAP Integration Suite products.

In my free time I’m trying to contribute to the SAP Community by writing blogs and answering questions, helping out with SAP Cloud Integration issues and challenges.

Thanks, Piotr! And then on to the central question of this blog post series: What’s your favourite SAP Cloud Integration feature?

My favourite functionality of SAP Cloud Integration up until now is definitely JMS queues.

Why that particular feature?

JMS queues bring a very critical capability to iflow design and that is the Guaranteed Delivery pattern. Using queues, we can decouple the communication between the sender and receiver applications. This can be implemented by developing an iflow that receives messages using any type of sender adapter, confirms technically that messages were received, and then stores the messages securely on the tenant in a JMS queue.

From the queue the message can then be processed with the frequency and logic most suitable for the specific requirements and capabilities of the receiving application. Using queues for decoupling we make sure that messages will be delivered to the receiver irrespective of capacity or current state of the target application.

In that way we can also implement various sync-async bridges on SAP Cloud Integration. For example, if the sender application expects a response message for each request that is sent, but the receiver is not able to provide it synchronously. In that situation, the iflow can confirm by responding to the sender and proceed with processing messages to the receiver, after the communication session is closed with the sender application. In a similar way we can implement async-sync scenarios, where the iflow will take care of synchronous communication with the receiver application, even if the sender doesn’t wait for a synchronous response.

With the retry mechanism, we don’t need to depend on a retry mechanism implemented on the sender side. Once messages are successfully stored in the queue, they will be retried if they fail in mapping, scripts, connectivity etc. This continues unless the Exception Subprocess in the iflow handles such situations.

Using Transaction Handling for JMS queues, we can manage transactions during runtime in a more sophisticated way. It is especially needed when we process incoming payloads sequentially, split incoming messages using a Splitter or implement several JMS receiver channels in one iflow. In such scenarios, we need to make sure that each transaction is committed after successful processing or rolled back to the starting point in case of failures.

While working with queues, we need to be aware of the maximum number of available queues on the tenant we work on. Not only on test environments but also in production. The number of queues available on the tenant can be increased, but there is a hard limit for each tenant on the number of queues, that we can get. This is why it is crucial to design iflows so that they don’t consume all available queues rapidly and without governance.

Finally we are reaching the last important element of the JMS queues feature in SAP Cloud Integration: Monitoring. It is possible to monitor all active JMS queues that are coming from deployed iflows. It’s easy to check the current capacity of the queue, allocated memory and where the queue is used. In special cases it is possible to manually retry, delete or even download the messages. JMS queues are not yet fully exposed for monitoring by the OData APIs, but it is possible to query SAP Cloud Integration via an API to get available resources of JMS queues.

How do you see this feature evolving going forward?

For the JMS queues functionality in SAP Cloud Integration, I see the following improvements and roadmap, that would enable us to solve more complex integration scenarios:

• Currently we have a hard limit on the number of available queues for each tenant. If a customer wants to use a higher number of queues than allowed, then another SAP Cloud Integration tenant needs to be purchased from SAP with all its dependencies, costs etc. This might be a showstopper for some customers. I really hope SAP will change this approach in the future.

• I’m looking forward to the new functionality on SAP Cloud Integration for inspecting JMS resources, which is planned for Q4 2023. I assume it will be enabled in the tenant UI in a similar way to the current database and data store inspection features.

• I’m also very curious about how the IDoc adapter will evolve and if it will follow the architecture of the XI and AS2 adapters, where we can use JMS queues as temporary storage. This was announced already but delayed a few times. At this point we expect this IDoc adapter update in a year. It means that for now, we can use decoupling via JMS queues to achieve real asynchronous scenarios when using this adapter.

• We are all waiting for Edge Integration Cell to be released. It was announced already some time ago and looks like we finally will be able to handle integrations, that cannot be moved to the cloud. I’m really curious how queueing will work on Edge Integration Cell. What will be the limitations – if any – for JMS queue usage? This topic will be one of many to look into once Edge Integration Cell is finally available.

It’s hard to predict what will be the future of JMS queues on SAP Cloud Integration, especially when we have Advanced Event Mesh and another event broker in the SAP Integration Suite road map. But definitely it will stay around. This SAP Cloud Integration functionality is now the backbone of many tenants and live integrations, so integration teams are counting on future investments in this feature.

Thanks for an interesting chat, Piotr!