I am seeing more and more customers and partners who actively promote the use of Azure API Management for D365 F&O backend and/or D365 Commerce Scale Unit ODATA interfacing. See for example, this blog post by Adrià Ariste Santacreu. However, there’s still a significant number of customers and partners who shrug their shoulders while thinking: “Why would we use it when we can interface ‘directly’?”. In this blog post I’ll address this question by sharing my best personal best practices in using Azure API Management for D365 F&O backend and/or D365 Commerce Scale Unit ODATA interfacing. But before sharing the best practices, we first have to explode the myth that interfacing via Azure API Management (APIM) would not be DIRECT.. 😉.Read more
In most projects, customers and partners are deploying Build and DEV boxes from LCS\Cloud hosted environments. These utilise multiple Azure resources such as storage accounts, virtual network and virtual machines. In many cases, the LCS environment is working against only 1 Azure subscription which is eventually used to host the PROD environment as well. If this is the case, you can potentially save your customer quite some money. In this blog post, we’ll see how much and how!Read more
Ever since D365 Finance & Operations V10, we’re in the Managed Updates model which aligns all Customers on a similar Platform Version – It’s the so called “One Version” strategy which brings a lot of benefits. But is there really ONE VERSION in reality? We have License keys, Parameter modules, SysFlighting and Feature Management which already contains 250+ Features in V10.0.11 PEAP. Did you all enable them? If you sum all these parameters, D365 Finops installations can fundamentally differ even if the underlying Platform version is similar.
Now with D365 Retail (Commerce) there is yet another variable – A relatively new Retail/Commerce Parameter area which is controlling Retail functionality behind the scenes… In this blog post we’ll dig out all the Features that can be enabled from here. Fellow Functional and Technical D365 Retail/Commerce consultants sit tight: this area is likely to become more and important in the future. It can also be really helpful for your own customisations.Read more
After walking through the overall D365 Retail API Architecture in part I and II of this series on the D365 Retail APIs, it’s now time to enable anyone to actually use the Retail APIs. To allow this, this blog post will contain all details on how to construct a request to most of the 400 out-of-box D365 Retail APIs – Beyond that, I’ve included a step-by-step instruction on how to use any of the Retail APIs from Microsoft Power Automate (Flow).
But before we can really get things rolling, we first need to apply some additional D365 setup and we need to choose the right security pattern. So that’s where I’ll start this blog post.Read more
Now that we’ve constructed a ‘RSAT connector for Microsoft Flow’ in Part I of this Series, we have lots of new opportunities offered by the Microsoft Power Platform to push our Test Automation in D365 to a new level.
In below video I’ll demonstrate how toggling the State of an Azure DevOps Test Suite to “Run RSAT” triggers MS Flow to iterate through the Test Cases in the Test Suite and let RSAT execute the Test Cases (D365 Task Guides) in the background. MS Flow will wait until RSAT execution is finished to send an e-mail to notify that RSAT execution is done. The e-mail will have the logs from the RSAT execution as attachments.
See my OneDrive for the Flow which is used in the video.
Note: I didn’t manage to import this Flow package into another tenant than the tenant where the Flow was originally built – MS Flow complaints about a problem with the authorisation against Azure DevOps – So you may have to amend the packaged (zipped) json definition of the Flow to allow import. Please share an updated .zip file if you manage to make amendments to the packaged .json definition which allows import.
We’re now in the new world of D365 “OneVersion” – A world in which we can benefit from continuous Microsoft investment without having to re-implement ERP ever again. But the new world also requires a solid Regression Testing Strategy to control the cost for consuming new updates. Here’s where Microsoft stepped in giving us the Regression Suite Automation Tool (RSAT). Although this tool is a good starting point, anyone who ever worked with RSAT will probably recognise one or more of the following limitations:
- I don’t want to go into a VM to run test cases!
- How can I test my D365 interfaces???
- How can I run multiple test cases/test suites in parallel (in other words: multi threaded)??
- I don’t want my chained tests to be scripted in Powershell, but in Azure DevOps (low code/no code solution!)
- How can I run mixed tests of process and interface? – e.g. to support E2E scenarios like: my e-com platform creates a sales order through an interface into D365 which is Released to warehouse through RSAT?
We can of course wait for Microsoft to come up with solutions to overcome these limitations. In my case, I decided to accept the challenge to leverage the Power Platform to fill the gaps. In this series of blog posts I’ll gradually tackle each of the above limitations one by one.
Key step in the overall solution is to find a way to move away from executing our D365 test cases directly from the RSAT tool and to bring this into a higher control layer with broader capabilities than RSAT alone… Please welcome an RSAT connector for Microsoft Flow!
Get started with the QuickStart Guide I published on my OneDrive:
We’ve all seen it many times in our projects.. Being under pressure to close these last P1 and P2 bugs by making some quick config changes in UAT, we forget to keep a record of what we did and to bring this into our Golden Config environment. And then, after cutover to Production, our users are confronted with the same issues as before.. How great would it be if we can prevent this with an extra ‘lock on the door’?More