Monday, March 24, 2014

An alternative to Salesforces Wsdl2Apex for calling SOAP web services in Apex

Salesforce provides a tool called Wsdl2Apex that allows you to generate Apex classes from a WSDL. These Apex classes act as a proxy for invoking the web service methods.

While functional, Wsdl2Apex has a number of limitations. Including:

  1. The generated Apex classes require code coverage, which needs to be created manually.
  2. You need to import the entire WSDL. In many cases you may only require a subset of the web methods. Reducing the number of methods cuts down the lines of Apex (a limited resource) that are generated and subsequently the number of lines requiring code coverage.
  3. Support for complex types that extend a base type. <xsd:extension base="foo:Bar">.
  4. Support for importing another WSDL. <xsd:import>
  5. Support for attributes. <xsd:attribute>
  6. The ordering of the generated methods appears to be arbitrary (maybe hash based ordering internally?). At the very least, a small change in the input WSDL can produce Apex that doesn't diff very well. This can be a pain with source control and tracking the history of changes.
  7. Conflicts between named WSDL elements and reserved keywords in Apex. E.g. long
  8. WSDLs that contain multiple wsdl:binding elements

I've been working with an intern student here at FuseIT to create a replacement tool as part of the FuseIT SFDC Explorer under the new WSDL tab in the 1.0.0.47 release. The current release is aimed at having reasonable feature parity with the existing Salesforce Wsdl2Apex implmentation.

Current functionality:

  • Import a WSDL from URL or local file.
  • User definable class names for each WSDL namespace
  • Detection of existing Apex Classes that match those being generated
  • The ability to select just the Apex methods that should be generated (including a description of the input and output parameters)
  • Publish the Apex classes directly into a Salesforce Org via the Tooling API.

Work in progress and possible future extensions:

  • Generate test Apex methods and mocks that give 100% code coverage for the generated callout code.
  • Generate HttpRequest web service calls as an alternative/backup to the WebServiceCallout.invoke calls.
  • Generate a WebServiceMock class with expanded request/response objects and doInvoke implementation.
  • Generate a wrapper Apex class that will revert to the mock implementation with running in a test case context. This could also expose the end point and timeout settings as properties.

See also:

Wednesday, March 19, 2014

Checking Salesforce ApexClass code coverage using the Tooling API

The FuseIT SFDC Explorer has been extended to provide Code Coverage reports for Apex classes.

Background

It used to be that you could easily bring up the Code coverage for a class from the Setup > Develop > Apex Classes page. There was a column that showed the percentage per class. Clicking this column would open a page that showed the coverage status per line. This was great as you could sort by this column to find classes that with lacking in coverage. Either by percentage or based on the "Size Without Comments" of the apex class. Also, the page that came up could easily be linked to and refreshed with an F5 in the browser. The URL had the format:

https://pod.salesforce.com/setup/build/viewCodeCoverage.apexp?id=01pE00000000001

Then, in the Winter 14 release they stripped this functionality out and proposed using the Developer Console instead.

Sadly, the current response from Product Management is that this useful column and page aren't coming back any time soon:

Josh Kaplan

We are slowly moving all functionality in the various setup pages into the Developer Console. Starting with the Winter '14 release, you will be able to see your code coverage metrics, at a glance, in the Developer Console tool only. This information will no longer be available in the class and trigger list views as it has been in the past.

Moving forward, the Developer Console will be the supported tool for browser-based development on the platform. It is costly to support multiple tools that perform the same function, so we are migrating everything to a single application. Over the next few releases, we will be retiring the old setup pages entirely.

You can still check the code coverage using the developer console, but I find this doesn't work well with my development. Finding the correct class and refreshing test results is ackward. Maybe it's just me and I'm missing some shortcuts with the Developer Console.

Code Coverage with the FuseIT SFDC Explorer

Happily, the Tooling API can now pull most of the required data for code coverage. So, rather than complain about lost functionality, I've started to build my own tool.

The Code Coverage tab in the SFDC Explorer is fairly minimal at this stage. You can search your Apex classes and then open up a code coverage view.

The code coverage results here rely on the results of running asynchronous test cases. You won't see any results from the synchronous test runs.

Given an Apex Class name or Salesforce Id (01p key prefix) you can quickly search for the code coverage results.

There are buttons to link to the Test History in the Salesforce Web UI or clear the current code coverage results.