I’ve written quite a few web services in Salesforce, and I’ve written about them a couple of times. And my love of testing is pretty well known. One thing that’s always been a problem is testing the web services in an automated fashion as a real consumer would. I’ve talked about manually testing them with SoapUI before, and while useful doesn’t fit into an automated process well. So let’s jump into the world of JMeter and how we can automate our web service testing for Salesforce.

One of the things I love working on are webservices. However, one of the things I dislike about using SOAP is that using the endpoint isn’t as nice as it could be. This is something that has been addressed by how REST endpoints are interacted with. By writing clean REST endpoints, your users can easily understand what is going on under the hood

Clean REST Endpoints

What do I mean by clean REST endpoints? Let’s take a look at two possible URIs and see which ones are cleaner and easier to understand. For the examples below, we are going to have two URIs, one to get a case by case number, and one to get it’s comments

#Get case using url parameter
curl "$SFDC_URL/services/apexrest/v1/cases?number=012345"

#Get case comments using url parameter
curl "$SFDC_URL/services/apexrest/v1/comments?number=012345"

#Get case using number in url
curl "$SFDC_URL/services/apexrest/v1/cases/012345"

#Get case comments using number in url
curl "$SFDC_URL/services/apexrest/v1/cases/012345/comments"

While the parameters are perfectly acceptable, they are not pretty. Also, it is difficult as a programmer to know if the param you have add to the URI is number, or casenumber or what. So instead if we have clean REST endpoints, we have the case number as part of the URI and it is just more logical as to knowing how to get a specific case.

Several years ago, I wrote a blog post on developing web services on Salesforce. When helping someone in the IRC channel with web services, I realize that the article was outdated and does not follow some of the design patterns that I have learned after spending a lot of time with web services

What are Web Services?

Let’s start with a little background. Web services are Apex code that you expose out and can consume with either SOAP or REST. Typically this is used to expose complex business logic in an easily consumable way. For example, you could use a web service to combine together an account with all of it’s contacts and return them in a single call. In this article we will be covering SOAP endpoints, but most of the principles also apply to REST endpoints.

The Problem

The other day I came across a problem where sending in a blank field to Salesforce via SOAP was not nulling out the field. Instead, the enterprise WSDL was treating this as if nothing was sent, and therefore not updating the field at all. This make sense. If you were to send a sparse data structure over with only fields you want to update, you wouldn’t want to either have to provide the current value of every field or have them all nulled out. So, how do you null out a field with SOAP via the enterprise (or partner) WSDL in Salesforce?

In a previous post I discussed how to test Salesforce webservices with soapUI. In this post I will show how to use the “default” methods inside the enterprise WSDL.

Logging In

First we need to login to Salesforce and get our session Id. Under the SoapBinding list, expand login and choose Show Request Editor. After opening the request editor we need to remove the extra headers we don’t need, and fill in our username and password.

In a previous post I talked about writing webservices for Salesforce. In this post I’ll discuss how to test your webservice with soapUI without having to write any additional code.

Getting soapUI

You will need to install the Open Source version of soapUI from their sourceforge. Go ahead, I’ll wait…

Preface

At my current job, we have several external systems that interact with Salesforce, and they do so through web-services. This document will cover what I have learned in regards to web-services, caveats with them and common pitfalls.

Overview

The goal of our web-services is to provide a single point of entry for each major object represented in Salesforce. A major object would be Account, Case, Case Comment etc. The reason this is differentiated is that for instance, Case Groups would under the AccountAPI since they are a minor object. Each web-service consists of two parts. First the actual web-service class which holds the externally facing methods and from which the WSDL is generated. The second part is that of the util class which holds all of the logic and is reusable.