As for Dyanamics AX 2009 I quite often bump into problems when trying to consume external webservices inside Dynamics AX.
The problems that I’ve experienced often relates either to the WSDL causing AX to throw an CLR error when trying to add a service reference or if the webservice requires authentication or similar, which is not possible to configure/set within AX.
The workaround that has shown to come in handy numerous times, is to create a webservice wrapper in .net and having that wrapper added as a reference in the AOT.
In order to be able to perform this task, You will need to do as follows:
- Create a new library project in Visual Studio
- Add a service reference to you WSDL file. In “advanced settings” make sure that the “Access level for generated classes” is set to “public”.
- compile the DLL
- Copy the dll to the client bin folder.
This procedure is primarily only necessary in order to being able to select the assembly from the AOT or if You want to be able to use the assembly from AX clients.
- Copy and rename the corresponding *.config file as “ax32.exe.config”. If the file already exist, merge the content of Your file with the existing one.
- Copy the dll to the AX server (AOS) bin folder.
- Copy and rename the corresponding *.config file as “ax32serv.exe.config”. If the file already exist, merge the content of Your file with the existing one.
- test using the dll from client side jobs. you can leave this out, if You’re only going to use the assmebly from server side operations.
- test using the dll from server side classes.
Ofcource there is always pros and cons when dealing with workarounds…
- a slight increase in complexity when dealing with components outside AX.
- You need to remember to copy the dll to new AOS instances if you in the future are adding new ones to Your setup.
- some people don’t like to have code residing outside AX
- The abilty to access proxy properties that aren’t normally exposed to AX – eg. “ClientCredentials”.
- when a wsdl fails to be added as a service reference in AX you will most likely not experience the same problems from .net. This means that You could either try to have the webservice changed into something more AX friendly (good luck with that) or you could just simply choose/be forced to use this workaround;-)