How To: Test a Dynamics NAV Webservice with Soap UI (free)


For the last few days I have been working more than usual with Dynamics NAV Webservices in order to make available the business logic to the outside world and allow for external connections. And to do so I needed a trustworthy testing tool.

In my case I have used Soap UI in the past and have had good experiences. So I wanted to create this entry detailing how to test a webservice with this tool :-)

To demonstrate this I have decided to create a new codeunit that has one function alone named “PrintPDFInvoice”. This function prints a PDF of a specific invoice and leaves it in a specific folder.



And we publish the codeunit as a webservice



Now let’s test the webservice with Soap UI. To do so we must do as follows:

1.- First we open the web browser with the URL provided by NAV. In my case it has the following format: http://localhost:”WebservicePort”/”NAVInstanceName”/WS/”CompanyName”/Codeunit/”WebServiceName”.

We should see a familiar structure: XML.



2.- Once we have opened the browser, we save the website using the “Save as…”. Important: when saving the file it is important that it is saved as .xml.

3.- When we have the XML saved, we must open Soap UI (download here).

4.- From within the Soap UI Application, we right click Projects>New SOAP Project



5.- In the next window we must use the “Browse” button to select our previously saved XML file. We make sure that the first option is active (Create sample requests for all operations?”).


6.- This will generate a SOAP project with the methods that are defined within the webservice with an example to call each one. In the case that those examples are not created we can create them by right clicking the method and selecting “New Request”.


7.- The following step is to specify valid credentials. To do so and with the request that we will use selected, we can go to the Request Properties pane and fill the parameters: Username, password and domain.


8.- Now all we have to do is pass the parameter that the webservice requieres. Each webservice can require different specific parameters (or none!). In this example all I have to do is pass a valid posted invoice number.


9.- Once executed and we get the “Ok” back we know we can go to the specificed path to find our PDF file.

In my opinion one of the most complex parts of working with a webservice is knowing exactly the XML structure that the listening webservice is designed to understand. With this kind of testing we can rebuild the XML necessary structure and that way implement it on our code regardless of the programming language we use. Beautiful :-)


Leave a Reply to Leandro Cancel reply