How to Optimize D365 OData API Performance Testing with JMeter

Performance testing has always been important for any application, but it is almost imperative in a cloud deployment of Microsoft Dynamics 365 Finance & Supply Chain (D365 F&SC) because if the environment is not properly sized before go-live, it can have a huge negative impact on both the business and the confidence of users.

Performance testing before going live gives you enough indication on how the application is going to perform with the expected load. Manually it is not possible to put enough load on the application and do the stress testing, so using this tool to perform the testing will save a lot of manual effort, time and costs.

 

Why bother with D365 performance testing?

In the absence of the performance testing tool, you must test the application with as many users as possible by logging into a tier 4 environment and performing “day in life” scenarios during a certain period. Then you need to check if there are any performance bottlenecks by keeping an eye on the Health Matrix in Lifecycle Services (LCS) Environment Monitoring to check the memory and central processing unit (CPU) utilization.

A predefined set of queries like deadlocks, slow-running queries in Activity → Raw logs and live views in Structured Query Language (SQL) insight also help nail down any issues. But were you able to put exactly same amount of load on the system?

We’ve seen quite few implementations where performance testing was not done with any tool. In just one or two days, the applications stopped responding because all of the licensed users started performing multiple operations and there was too much data coming in from different integrated applications.  This can be incredibly frustrating, especially after investing so much effort into bringing a system to life, only to see everything come to a halt.

Fortunately, this situation can be largely avoided with performance testing, especially beneficial for big implementations, because:

1. Performance testing is performed in the production-like environment, so any performance bottlenecks are identified before going live. This gives you the opportunity to get them fixed or provide evidence to Microsoft that with this server configuration the functionality might not work in production.
2. Performance testing is a must from Microsoft before the production environment is deployed. Again, this is done to ensure the right sizing of the production environment.

 

Using JMeter for performance testing in D365 F&SC

Performance testing of the D365 F&SC user interface (UI) with JMeter by Edison Lai is a complete series of performance testing. This blog will focus on how to call the Dynamics 365 Open Data Application Programming Interface (API) through JMeter.

Note: This blog assumes you already have JMeter installed. If you need don’t and require assistance, check out Edison Lai’s blogs. If you’ve tested APIs with Postman, you’ll find JMeter’s configuration quite similar.

Configuration steps to call the API

1. Open the JMeter.bat file in administrative mode.

2. Enter the name of the test plan “D365 API Test” and save that as D365 API Test.jmx file.

3. Add the User Defined Variables in the Test Plan.

4. Add the below variables:

scheme – https

host – URL of d365 environment without https://

tenant – Tenant Id

client Id –  This value will come from App registration in Azure Portal

client_Secret – This value will come from App registration in Azure Portal

x-ms-client-request-id – ${__UUID}

Note:

• The client_Id and client_secret values will come through App registration in the Azure Portal. For details, please check here.
• The tenant Id value can also be retrieved from the App registration screen in Azure Portal.

 

5. Add HTTP Request Defaults.

6. Enter the below values:
Protocol [http]: – ${scheme}
Server name or IP – ${host}

7. Add the thread group as shown below.

8. Add the HTTP Request.

9. Enter the below values:

HTTP Request – Post

Path – $scheme}://login.microsoftonline.com/${tenant}/oauth2/token

 

Parameters

resource –  ${scheme}://${host}

grant_type – client_credentials

client-id – ${client_id}

client_secret – ${client_secret}

10. Add the Post Processor → Regular expression extractor. This is required to extract the value of the access token from the result.

11. Enter the following values in the Regular Expression extractor:

Name of created variable – access_token

Regular expression – “access_token”:”(.+?)”

Template(…………..  )- $1$

Match No. (0 for Random) – 1

12. Add the BeanShell PostProcessor.

This is required to make the access_token value available across another Thread group as the scope of any variable is local to that thread group. Another option is to use the property.

13. Put the below values in the BeanShell PostProcessor Script section:

props.put(“access_token”,vars.get(“access_token”));

14. Add the listener View result tree. This will just check whether the token is getting generated or not. Once the listener is added, press the start button to run the test plan.

15. If you get the response with the proper access_token, that means you have configured everything properly!

Steps to call the API

16. Now we’ll do the real stuff! Add the new thread group to call the OData API for CustomerGroup to get the customer group details.

17. Add the HTTP Header Manager to pass the header values.

18. Add the below header values using the Add button:
Authorization – Bearer ${__P(access_token)}
Content-Type – application/json
x-ms-client-request-id – ${x-ms-client-request-id}

19. Add the HTTP Request to call the OData API and get the list of customer groups.

20. Enter the below values:
Path: /data/CustomerGroups

No need to enter Protocol [http]: and Server Name or IP as those values will be defaulted from HTTP Request Defaults.

21. Press the start button again and check the results in the View Result tree.

If you get the details of all the Customer group as a result in “View Result Tree” Listener, then all is good. If not, you will need to check the configuration. 

You can add listeners like View results in the table to get details in a tabular format.

This is how you can configure the OData API in D365 F&SC. You can also use the same method to create and update requests. If you have any further questions on this process, please contact us.

 

About the expert 

Tanuj Goel, D365 F&SC Technical Capability Lead, OnActuate   Tanuj is a Microsoft Dynamics 365 Finance & Supply Chain professional with more than 20 years of experience in development, upgrades, integrations, DevOps, LCS tools and deployment in Dynamics AX and D365 F&SC. He is also experienced with performance testing using JMeter and test automation tools like RSAT and Leapwork.

 The “OneByte” blog series are technical how-to articles by OnActuate’s expert consultants covering Microsoft Business Applications (Microsoft Dynamics, Power Platform) and related technologies. Have a topic you’d like to learn more about? Email us at info@onactuate.com!