Let’s continue our journey looking at how Microsoft Flow can be used to build integrations for Microsoft Dynamics 365 for Operations (also known as AX7).
This latest post gives examples of how to export data from Microsoft Dynamics 365 for Operations (AX7) into your local file system in JSON, XML, or CSV formats using Microsoft Flow. It assumes that the Microsoft Flow on-premises data gateway is already installed and configured – if not, refer to Part 2 of the series.
- Based on recurring schedule (trigger),
- Query all customer records from AX (action),
- Transform the data into required format (action),
- Write the data into a file in the local file system (action).
Dynamics 365 for Operations (a.k.a. AX7) provides several endpoints for web service. In this blog post, I want to describe consuming a D365O custom web service in a C# application using the SOAP endpoint.
For a detailed description about service endpoints, you can read the official documentation at https://docs.microsoft.com/en-us/dynamics365/operations/dev-itpro/data-entities/services-home-page.
The main advantage of the SOAP protocol is its descriptive functionality through the WSDL language. SOAP endpoints provide detailed description about contracts and parameters to call each service method. Visual Studio has a great functionality that can read the service description and automatically generate proxy classes to access the service methods.
Let’s do an example of consuming a D365O web service in Visual Studio. Continue reading
Recently one of my colleagues ran into a strange issue. When performing some actions on the POS that involved calling AX 2012 via Real Time Service, the call failed. In another environment with the same code base, the code succeeded. Also, the RTS failure happened only on certain calls, other calls against the same server worked correctly (the specific case: retrieving a previous sales order succeeded, but sending a completed return order to AX failed).
The event log on the RTS machine was quite confusing: the error message was “Cannot create a record in System parameters (SystemParameters). The record already exists.” But there was nothing wrong with the system parameters.
I captured the request from the POS to the RTS and wrote a small job in AX to call the respective class/method directly using the same request and this worked fine. Even more confusing.
The solution came after realising that the Real Time Service uses .NET Business Connector to connect to the AOS. From the architectural perspective, the Business Connector is like a regular AX client without a user interface. Recently the AX environment in question had been updated with new code – but the same code worked fine on another machine. Earlier I had seen weird issues on a regular AX client where the solution was to get rid of the user cache files. And this turned out to be the solution for the RTS too. Continue reading