A couple months ago, Microsoft Azure Load Testing (MALT) was made generally available as a fully managed load-testing service that enables generation of high-scale load against our applications. Azure Load Testing has many features that can be leveraged to automate Load Testing in business applications project implementations and hyper care, and also to complement other testing strategies like functional test automation with RSAT:

• Generate high-scale load quickly and easily.
• Identify bottlenecks with actionable insights.
• Build load testing into your DevOps workflows.
• Use a fully managed testing service for Azure.
• Comprehensive security and compliance, built in.
• Keep costs low by paying for only what you use. 

Creating simple load test with MALT is straightforward, as explained in the Quickstart: Create and run a load test with Azure Load Testing, but this will only generate workload against the home page, which is not enough to properly stress a Dynamics applications.

To do that, we must create some custom requests to leverage different Dynamics components like the batch framework, OData endpoints, custom or standard web services, and so on. This can be done by running an existing JMeter script in Azure Load Testing. Here is how:

Create a custom load test script for finance and operations apps

• First of all, we must install Apache JMeter and its pre-requisites: https://jmeter.apache.org/download_jmeter.cgi
• When you execute JMeter (look for the jmeter.bat file on the installation folder) it looks like that:

• JMeter organizes its components on a similar style as Dynamics AX/F&O organizes the AOT, as a tree. We mainly start creating Thread Groups, and within these groups we create the required actions (there are many actions included out of the box, and can be extended with plugins). When the test script runs, every thread group will create a configurable number of threads that will scale up the workload as desired.
• I will create here a very simple example with 3 thread groups. First one sends a request to the OAuth login server to get an authentication token, and the second 2 thread groups will create GET and POST actions to OData endpoints, reusing the same authentication token. The tree looks like:

• As the load test script will require some parameters from the outside, like the information about the environment we want to test and the required credentials and secrets, we can create variables on the JMeter script to receive these parameters. The function GetSecret will integrate with Azure Load Test, so we will provide these parameters easily from an Azure Key Vault on a later step.

• We can use these variables in the next steps, like here when we use the environment URL and the Tenant Id to request a login OAuth access token:

• This token is then extracted with a JSON Extractor and persisted as a session variable with a BeanShell PostProcessor component, so we can use the value in any further step out of this thread group. 
• Then an HTTP Header Manager component is used to specify the appropriate header values for OAuth, including the variable used to store the access token:

• And finally we can use an HTTP Request action to send a GET request to the OData endpoint to select one specific customer information, for example:

• See how we can specify parameters to the request on a configurable way, that can also leverage external variables or even read data from CSV files natively from JMeter. But this is for a next blog post 
• Similarly, we can also create a thread pool to send data to Finance and Operations through POST actions to the OData endpoints. We can also send information directly in JSON or using the parameters version from the previous step, and also read data from an external file.

• The script can be tested directly in JMeter by clicking the "Run" button, and we can use the View Results Tree nodes to debug that our requests and the corresponding responses from the server work as expected.
• When the script is finished, save the test plan as a JMX file (from File menu in JMeter). We will load this file to Azure Load Testing to run it at scale!

Load a custom JMX file to Azure Load Testing

• First of all, you must create an Azure Load Testing resource in your Azure subscription.
• Then navigate to your resource and use the Upload a JMeter script and then Create.
• In the fist step you can give your test a name of your choice and click Next.
• Here you will find and upload your JMeter JMX file and then click Next.

• In the next step (Parameters) you will pass all the required parameters to your script. If you used the GetSecret function in the previous steps, you want to pass these parameters in the Secrets sections, and you only need to specify the secret URL in your Azure Key Vault. The system will read the secrets securely from the vault automatically during test runs. It's explained here: https://learn.microsoft.com/en-us/azure/load-testing/how-to-parameterize-load-tests

• In the next step (Load), you can specify how many Engine instances will be ran. This is important, as this number will combine with the thread count specified in your thread groups to determine how many threads will be created during test execution (they multiply) as explained here: Configure Azure Load Testing for high-scale load tests - Azure Load Testing | Microsoft Learn

• And finally, in the last step (Test Criteria) you can specify your minimum thresholds expected so the test is flagged as "failed" if these quality bars are not met. This requires some tuning and depends on a case-by-case scenario, and obviously on how powerful is the environment we are testing.

And that's all! Save your test and run, and enjoy test results:

But this is only the beginning!

• This test is configured in your Azure Load Test instance and can be executed manually or as part of your deployment DevOps Pipelines.
• This test is only creating random data but JMeter can natively use CSV files as data source to create more meaningful, related and complex tests. 
• You can leverage your existing web services (custom or standard) to generate different kinds of workloads as needed.
• Azure Load Testing can also connect to different cloud applications, therefore can be used to orchestrate more complex integrations involving third party components like message queues and such. All from the same place!
• Azure Load Testing is a relatively new product. Do you have any good ideas? Help the team know by creating or voting ideas!

If you are interested in more Azure Load Testing content, let me know. Feel free to contact by LinkedIn, and let me know how you are leveraging this tool for load testing your business applications environments.