Test/Simulate Custom Webservice Using SOAP UI Tool

Testing Custom WebService in Salesforce Using SOAP UI Tool

In the last post :Creating Custom WebService in Salesforce we learnt how to create custom WebService in Salesforce and how to generate the WSDL for it.

This post will be centered around the way to Test/Simulate the Webservice using SoapUI Tool.
SoapUI is an open-source web service testing application for service-oriented architectures (SOA) and representational state transfers (REST). Its functionality covers web service inspection, invoking, development, simulation and mocking, functional testing, load and compliance testing.

How to Download SoapUI ? - Go to https://www.soapui.org/downloads/soapui.html and get the SoapUI Open Source. Install the software once downloaded.

Step 1: Go to Salesforce and download the EnterpriseWSDL. Click Setup--> Develop--> API--> Enterprise WSDL.

Step 2: Go the Webservice class which we have created in the initial Post : Creating Custom WebService in Salesforce and generate WSDL as mentioned in the post.

Step 3: Open the SoapUI tool and Click on File option and then New Soap Project .and enter the information in the form.Make sure your initial WSDL should be the enterprise WSDL. Create Request should be checked.

After creating the new project you will see a section called SoapBinding with several methods below it. These are standard Salesforce methods that are provided by the Salesforce Enterprise WSDL. Let’s ignore these for right now, and import our webservice. To add a new WSDL right-click on the project name,Salesforce in our case, and select Add WSDL.

Now add our custom WSDL to it.

Now we are all set to test our WebService. Expand SoapBinding List then login and then Request1. In the window opened enter the Username and password with securityToken to login.

Click on Plan button on the top to run it. Now in the resulting XML we can pull out our session Id

Now we can use this session Id in our custom webservice Call. Expand the AccountExamplebinding and click on request1.
we can remove almost all of the header out of the request. The only section we need to leave is the SessionHeader and SessionId.