Salesforce Winter’11 release for apex web services developers

Salesforce Winter’11 release came with many new exciting features and governor limit relaxations. These relaxations are specially cool specially for apex developers, who are creating Mash-ups & Enterprise integration projects on top of force.com platform.

This post explains

• Correlation between existing platform limitations/issues in developing such web service projects with apex

• And how winter’11 governor limit relaxations, make more such mash-up projects possible and easy to develop on force.com platform.

Here are few common scenarios for web service development with apex, each scenario is inline value add from winter’11 features.

• Scenario 1: Making web service calls via Apex to other Clouds or Enterprise stacks like Google, Facebook.

  • Related Winter’11 Change: Removed governor limits in Winter’11
    • Total request time for one callout (HTTP request or Web services call) has been removed.
    • Maximum size for a callout (HTTP request or Web services call) has been removed.

  • Benefits

    • Previously “Total request time for one callout (HTTP request or Web services call)” was 60 seconds. Though 60 second is decently big time for any general web service call to compete.But we know because of some web service method requirements, internet latencies and server overload this limit might be less in some scenarios.

    • Previously this limit was 1 MB, so chances of failures exists when huge XML is returned in response. Developers have to do some hacks to make the stuff work right for them in case of big responses. 

• Scenario 2: Parsing XML/JSON response via Apex

  • Related Winter’11 Change:

    • General heap size has been raised from 2 MB to 3 MB, with no scaling. In addition, batch Apex heap size is 6 MB.

  • Benefits

    • More heap size is important for many reasons, even previously(before winter’11) with ability to handle just 1 MB XML response.

      • 1 MB response means a String response, that will eat up 1 MB of available heap.

      • The relevant data structures that will encapsulate the parsed web service response might take some where between at least 300-500KB easily for a 1 MB response.

      • So XML + Data Structures will for sure end up you in consuming at least 1.5 MB of heap. So increase of heap size upto 3 MB, is really important.

  • Important Note : With winter’11 relaxation on “Maximum size for a callout”, one needs to watch the amount of heap available. This doesn’t really means we can handle any big web service response. For ex. one can’t parse a 4 MB big XML, with 3 MB available in heap.

• Scenario 3: Performing WSDL2Apex, via “Generate from WSDL” button available in Salesforce Org > Setup > Develop > Apex Classes.

  • Related Winter’11 Change:

    • Apex classes and triggers have been raised from 100,000 characters and 32,000 characters, respectively, and can now be 1
      million characters long, not counting comments, test methods, and classes defined with @isTest.

    • Maximum amount of Apex code allowed in an organization has been raised from 1 MB to 2 MB.

  • Benefits

    • We can’t perform WSDL2Apex previously on WSDLs, those generate big Apex classes, for ex. we can’t do WSDL2Apex on partner WSDL. So the hacks developers do includes

      • Removing methods/operations from WSDLs to reduce the number of chars in generated Apex classes.

      • Instead of straight SOAP options available in WSDL, look for REST API and try implementing an Apex client on own.

    • So having scope of 1 million chars in Apex Class, will for sure open the ability to bring more smart Apex clients to various WSDLs.

Conclusion

I see questions(link) on force.com forums, where developers try to compare developing web service clients in Apex or Java or .Net. Developers often hesitate out of force.com platform and end up in implementing solution on Java/.Net stack to get rid of these governor limits. But now after winter’11 this scene should change a lot, developers have much more bandwidth to do on platform then ever before.