The message should have gotten through load and clear by now, customisation of Dynamics 365 for Operations (AX7) should, wherever possible, be done using Extensions. Your development team should have seen this being hammered home by Microsoft and the D365 community over the past months and especially since Microsoft told us that the Application Suite will be sealed by spring 2018. So how do you stop your development team from falling back on old habits by using their tried and test over layering techniques?
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
I have been experimenting with oData actions and testing them using Fiddler. Overall it is easy to implement them and they can be used as a “cheap” alternative to custom services. Compared to a custom service, the Data Entity can act as the data contract and removes the need of querying/saving a complicated table structure.
There are two kind of actions you can add, collection level (static) actions and instance level actions. We are going to use the Fleet Management module in order to create one action of each type and then test it using Fiddler. Continue reading