Best Practices for Apex Callouts, Part 2

February 22, 2013 Prabhu Palanisamy

Earlier we posted some initial considerations in designing and implementing Webservice callouts from SFDC. Here is part two of Best Practices for Apex Callouts.

Security

One of the key items to remember in security is SFDC does not support self-signed certificates. Any certificates configured in SFDC have to be signed by a valid 3rd party CA. Similarly any endpoint which SFDC connects as a client have to trusted by a valid 3rd party CA. Also SFDC supports only PKCS#12 format certificates. We can use OpenSSL to convert between various file formats. Most of the time the Certificates have chains ie. Root -> Intermediary -> Valid cert. The endpoint server must send any intermediate certificates in the certificate chain, and the certificate chain must be in the correct order. The correct order is:

  • Server certificate.
  • Intermediate certificate that signed the server certificate if the server certificate was not signed directly by a root certificate.
  • Intermediate certificate that signed the certificate in step 2.
  • Any remaining intermediate certificates. Do not include the root certificate authority certificate. The root certificate is not sent by your server. Salesforce.com already has its own list of trusted certificates on file, and a certificate in the chain must be signed by one of those root certificate authority certificates.

Common Error messages:

  • IO Exception: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
  • IO Exception: java.security.cert.CertificateException: No subject alternative names matching IP address [IP address] found

SFDC References:

Testing

Use of testing tools like SOAP UI is highly recommended to ensure the service endpoint can be tested first outside of SFDC. SOAP request and response tracing. Unfortunately SFDC does not allow tracing in production orgs. One of the ways is to use TCP monitor on the on-premise side to interject and look at the request and response.

Test coverage:

Test coverage is important for all apex classes including the ones generated from WSDL. By default, test methods don’t support Web service callouts and tests that perform Web service callouts are skipped. To prevent tests from being skipped and to increase code coverage, Apex provides the built-in WebServiceMock interface and the Test.setMock method that you can use to receive fake responses in a test method.

Similarly the service provider can also perform test coverage for service methods which are exposed. SOAP UI provides features to write test cases, mockup services request and response and could be automated for regression testing. This will be help during incremental development and new WSDL needs to be consumed in SFDC.

Configurable Parameters:

Use of custom settings/ custom objects is recommended to maintain the following items

Endpoint URL
Service specific timeouts
SOAP Headers
HTTP Headers

Previous Article
Tutorial: Creating an AngularJS app with node.js and Heroku Part II
Tutorial: Creating an AngularJS app with node.js and Heroku Part II

by Bryan Leboff So now that we have our environment set up from Part I of this tutorial, it’s time to start...

Next Article
The Company Meeting, Cloud-Style – The Technical Details
The Company Meeting, Cloud-Style – The Technical Details

by Glenn WeinsteinCo-founder and CIO On our CIO blog yesterday, I wrote a post on how we pulled off our vir...