Usually, working with SAP comes with heavy loads. This is not strange given the fact that your ERP is probably at the heart of your company, thus running many tasks at the same time.
Therefore integrating with SAP gives you great power, which means you should also take great responsibility when it comes to distributing load evenly on your integration platform. Even when working with Azure.
However, this isn’t always as straight-forward as you might think.
In this blog I’m going to show you the possible scenario’s of integrating with SAP, as well as the matching load balancing scenarios. To enable you to scan through this blog I’ve added a Table of Contents.
Prerequisites
While writing this blog I consider the following to be in place
- You are already using SAP with an On-Premises Data Gateway, or planning to do so
- Connections to SAP are handled by the On-Premises Data Gateway, and you’re not using VNets or VPNs for direct connections to SAP
Scenarios
Basically there are two different scenarios:
- Using default settings: fit for most of the SAP integration scenarios
- When using sessions: this is where it gets tricky to use the default
In the following paragraphs I’m going to tell you all about those two scenarios, and how they differ from each other.
Using Default Settings
In many cases this is where you start when using the On-Premises Data Gateway: you install the On-Premises Data Gateway on a server, and for high availability you make sure to install another on in the same cluster, and you’re done!
In many cases this will work perfectly, without any issues. When you do notice issues due to heavy loads, you simply plug in another On-Premises Data Gateway server in the same cluster and you’re good to go again.
You can build as many integrations you’d like with an almost unlimited amount of load. SAP isn’t the culprit due to its queueing system. Whenever the On-Premises Data Gateway might be, you just add another one.
When Using Sessions
This is where it gets interesting, because at some point in your integration firing a call to an RFC or BAPI simply isn’t enough. as you first need to create a stateful session (transaction in SAP terms). This might be necessary because you need to call multiple Function Modules in order before doing the final commit, or you need to roll back in case of an error.
In a Logic App a stateful session can be easily created through the available SAP connector, allowing you to chain Function Module calls together, and control the commit and roll back as you wish. However, when you execute this over a network with an On-Premises Data Gateway cluster in place you may all of a sudden stumble upon this error:
While digging into the error it got clear to me this error occurred because of load balancing of the On-Premises Data Gateway. The default setting when it comes to load balancing randomly selects a server running the On-Premises Data Gateway in the cluster. As the session is maintained by the On-Premises Data Gateway this results in the session being set up on server 1, but the second request gets redirected to server 2 which is unaware of the session. Thus throwing an error.
To bind the requests to a particular server, you should disable the setting “Distribute requests across all active gateways in this cluster” on the Power Platform Admin Center. This enables the session to be set up and maintained on a single server, allowing you to chain Function Module calls together.
This seemed like the perfect solution to our problem. Only after some time we noticed that the binding has another effect, being memory exhaustion on the server running the On-Premises Data Gateway.
The Load Balancing Act
So, now you’re aware of the different scenarios it is time to continue with the burning question: what is the best load balancing configuration in my case? The next paragraphs contain the available options together with the best possible scenario.
Adding More Servers
When you’re not using sessions this could be an easy way forward, as you simply add another server to the On-Premises Data Gateway cluster and you’re done! If you do use sessions, you must not only consider to add more servers, but also check the paragraph “Through Configuration”, as adding servers only won’t help in this case.
With Multiple Clusters
It is actually best practice by Microsoft to create an On-Premises Data Gateway cluster per use. Let’s say you’ve got a process for invoicing, then you should create an invoicing cluster. Another process, for example orders will have an orders clusters, and so on. However, the same applies here as in the “Adding More Servers” paragraph: when not using sessions this helps directly, but when you do you need to consider the steps in the “Through Configuration” paragraph.
Off course, this does mean a lot when it comes to your local infrastructure, as an On-Premises Data Gateway cluster would require at least two servers to run. The minimum split should be at least between high-priority and low-priority workloads, as you would not want a less important process to knock down an important one.
Through Configuration
If you’re using sessions in your calls to SAP, this is the place to be. By default a server is randomly selected for load balancing purposes, but as we’re using sessions we must bind to a single server for the session to stay active. Therefor, load balancing is not as default anymore. Resulting in one server being very busy, while the others are almost at rest.
To bypass this behaviour, it is necessary to update the configuration of the On-Premises Data Gateway servers to lower the failover thresholds. You can either choose for a memory and CPU threshold. Since SAP calls are regularly memory expensive it makes sense to adjust the memory threshold. This can be done as follows:
- Log on to the server running the On-Premises Data Gateway
- Browse to the installation folder of the On-Premises Data Gateway
- Find the file named “Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config”
- Adjust the setting “MemoryUtilizationPercentageThreshold” as desired (the default is 0 meaning disabled)
- Save the file and restart the On-Premises Data Gateway service
Just so you know
The setting “ResourceUtilizationAggregationTimeInMinutes” sets the time in minutes for which CPU and memory system counters of the gateway machine are aggregated. The aggregated values are then compared against the respective threshold limits.
Conclusion
Load balancing must be carefully considered based on your scenario to make it fit for function, otherwise you may run into unexpected situations. Take a close look at how your integration is operating, and what load it generates, to select the most optimal set up in your case.
Next Steps
Check your current integration scenario and load together with your On-Premises Data Gateway set up, and plan optimizations accordingly based on the scenarios noted above. I’m hoping my blog post will help you on your journey finding the best possible solution for your needs.
Please feel free to discuss with me on this topic through the comments below. Off course, you can also get in touch and leave me a message. Looking forward!