Don’t Worry Mum,
I know how to use HTTP Client right
February 5, 2024
By Yuriy, Business Applications Developer
Global Mediator
If you're working on a project in Business Central that involves interacting with various web services, don't just pass by. We're about to delve into the usage of the HTTP client data type.
There has been some buzz about the implementation of the HTTP client data type in Business Central extension development. Some even suggested using "antipatterns" to avoid serious performance bottlenecks when consuming web services. This was mainly due to socket exhaustion on the consumer machine. It made sense until Business Central changed the behavior of the HTTP client.
In this blog post, we'll explore how the HTTP client in Business Central has changed. Previously, there were performance issues, prompting unconventional solutions. Now, Business Central has changed the HTTP client, resolving these problems and enhancing the efficiency of web service consumption.
Say goodbye to old worries and welcome a simpler way to work with web services.
In the old days
To prevent performance issues, it was crucial to find a way to reuse an instance of the HTTP client type. Otherwise, not doing so could lead to socket exhaustion, potentially causing a system crash. An example of this "bad habit" is illustrated below.
In the SendMulti method, if you repeatedly call the Send method, a socket is reserved for each instance of the client variable. Even after the execution of the Send method ends, a socket continues to be reserved. Running the netstat command in a PowerShell session reveals numerous sockets in a "TIME_WAIT" state.
The more times the Send method is called, the greater the number of sockets in a "TIME_WAIT" state you get.
In simple terms, the "TIME_WAIT" state occurs briefly when closing a connection between two computers. It acts as a waiting period to ensure all data from the previous connection is received and processed before it is fully closed. This prevents confusion or errors in case there's lingering data.
One solution to this issue involves using a single instance codeunit, as demonstrated in the code snippets below.
The local client variable of the SendBetter method now refers to a single instance of the MyClient codeunit. In the MyClient codeunit, an HTTP client is declared as a global variable, enabling the system to reuse the same connection socket for each HTTP request.
Alternatively, you could use a global HTTP client variable in the same module as the Send and SendMulti methods or declare a variable in the SendMulti method scope and pass it to the Send method as its argument. All approaches solve the problem, but the final choice depends on the circumstances.
The netstat output now appears normal, and the "TIME_WAIT" sockets have disappeared.
However, the real concern is not the number of sockets in use unless it impacts performance. Implementing the described approaches can significantly improve project performance, sometimes by up to 10 times. Imagine telling your customer that Web Shop synchronization now works 10 times faster just because you are so good at using the HTTP client effectively.
Now It’s Time to Relax
If you're eager to refactor your code and make your customers even happier, hold on for a second—there's no need for it. In the latest version of Business Central, Microsoft has changed the way the HTTP client behaves. Under the hood, the system now reuses available instances of the HTTP client. Now, it doesn't matter how you handle the HTTP client variables; the system will figure out the optimal way of using the connection.
Given that the AL code is compiled into the C# language code, it is fair to suggest that IHttpClientFactory is used. IHttpClientFactory is a feature in .NET that helps manage and create instances of HTTP clients more efficiently. Instead of creating a new HTTP Client every time you need to make an HTTP request, you can use IHttpClientFactory to create and reuse instances. This not only improves performance but also handles certain issues, like socket exhaustion, more effectively.
In simpler terms, it's like having a factory that produces and manages your HTTP clients, making your code more efficient and avoiding potential problems associated with creating a new client for every request.
If you run the examples from the previous section and compare the performance results, you’ll see that there is no difference in performance.
The bottom line is that if you don't reuse HTTP clients like, in the first example of this blog, you don't need to refactor your code. Microsoft has already handled it for you.
Conclusion
In this blog post, we've explored how the Business Central HTTP client data type operates. This understanding not only provides insight into its workings but also has the potential to save you time by avoiding unnecessary development efforts.
Do you need advice on your Business Cenral projects?
Feel free to discuss your needs with us
Stay current with the latest insights from us