2 min read

Managing Web Service Settings in Salesforce

I have tried a couple of different ways to manage configuration settings for web services that I have integrated with Salesforce.com. I have tried hard-coding the endpoints and credentials (very bad), creating custom objects (better idea), and now I am using the new custom settings objects (best option).

First you will need two custom settings objects. The first one will be a global system setting object that is hierarchy based. The second will be a setting object that is list based. This will allow your global settings to be based at a global or profile level making your system much more flexible.

Here is what my System Settings object looks like:


Notice that it is pretty basic but you can add many new fields to manage various global settings in place of hard-coding these values into constants. I only have two fields configured at this point; a Default Error Message field (more on this in another post) and the active service name. This is where I put the name of the service that I want the system to use. This name will match the name of a web service configured in the Web Service custom setting object.

Here is why my Web Service Settings object looks like:

Web Service Settings Screenshot

As you can see I have the basic fields configured like the service end point, username, password (I wish we could create password masked fields - promote the idea). Then you will see a couple of additional fields that control whether the service is in test mode or in maintenance mode each with their own description field so that the message that is sent back to the user can be customized.

In my particular use case these services are triggered either from custom visualforce pages or from view pages that have been overridden. So this allows me to have more control over how the message is displayed to the user. For instance if the service is in maintenance mode I can display that message to the user as soon as they enter the screen and not allowing them to do anything until the maintenance period is up.

This not only allows you to be forward thinking about future maintenance plans for interfaces but it also removes the developer from having to be involved. It can now become a system administrator activity to allow the services to be turned off or on and what the message should be to the users. Custom settings are also more efficient than querying custom objects since they implement the singleton design pattern and do won't add to your query limits.