Slightly depressing to be saying this in late August but Winter is almost upon us in the shape of the Winter ’14 (or v29.0) release. The Winter ’14 release notes are now available, find below a brief introduction to 10 Force.com highlights (in no order of significance).
1. Increased Sandbox Storage Limits. Developer sandboxes now enjoy a 200MB data storage capacity limit (and yes that is a massive increase from 10MB) enabling record storage to increase from 5k to 100k records. Configuration-only sandboxes double in capacity from 500MB to 1GB, and are renamed to Developer Pro. I understand that existing sandboxes will only increase in capacity post-refresh and will therefore require the production pod (NA1, EU3 etc.) to be upgraded to Winter ’14 before related existing sandboxes can be increased.
2. Performance Edition. Not exclusively a platform highlight but the introduction of Performance Edition is definitely worth a mention. It appears that Performance Edition will replace Unlimited Edition for new customers, in that UE will no longer be available to buy after November 2013. Performance Edition is essentially a bundled (or suite) offering comprised of core CRM, platform, Data.com, Work.com, Identity, Live Agent, Salesforce Knowledge plus at least one full-copy sandbox. The list price differential from UE appears to be $50 ($250 per user/per month increasing to $300), which seems reasonable in relative terms. I had hoped that “Performance” related to high-performance, very large data volume (VLDV) support etc. not this time apparently.
3. Developer Console Improvements. Some nice Visualforce related enhancements including a page preview feature within the console and the ability to inspect the viewstate (beta only). Additionally it is now possible to add and edit Static Resource files, a nice convenience particularly for JavaScript and CSS resources.
4. Apex Statement Limit Elimination. The script statement limit previously applied to an Apex context has now been replaced with an execution time limit; 10 seconds for synchronous contexts, 60 seconds for asynchronous. Time spent waiting for synchronous callouts to complete is not counted nor is time taken by the database to service queries and DML. I’ve always considered the governor limits applied by the platform to be a positive encouragement to write efficient code respectful of well defined and constant, predictable limits. The CPU time limit appears to be more variable in nature, i.e. Application server load may impact on context execution performance, and therefore could potentially be more problematic for developers to mitigate.
Excellent blog post on this topic by Dan Appleman
5. Flexible API Limits (Pilot). In short the platform now supports up to a 50% spike in inbound API calls (SOAP or REST) versus calculated allowance (function of edition and selected license counts). This additional flexibility makes a great deal of sense given the growth of off-platform composite apps such as mobile, where the API call utilisation can be inconsistent. This flexibility isn’t intended for continued use more to prevent limit exceptions on an occasional basis.
6. Visualforce – HTML5 Development. A new HTML5 friendly component , some additional attributes, plus the ability to pass-through attributes to the rendered HTML markup (key for JavaScript library interactions) have been added to Visualforce to enhance the HTML5 developer experience.
7. Visualforce – Server Side Viewstate (Pilot). There isn’t much in the way of detail available on this one, however it would seem that pages will be able to opt for a server-side viewstate, making the page weight considerably less. Quite how this change to a stateful server-side will be implemented is unclear, ideally the server side state cache would be persisted somehow across controllers within a Session. This would be extremely usedful (and hardly uncommon), avoiding a custom object solution to persisting state across multiple pages that do not share a common controller.
8. ISVforce – Delete Managed Package Component (Pilot). ISVs can now delete obsolete custom fields and tabs from a released managed package. A subscribing org that upgrades to the new package version will not have deletions applied automatically, instead deleted components will list as Unused Components on the Package Details page. It is therefore up to the ISV to inform their customers. For the ISV this is a great improvement in terms of maintainability.
9. Environment Hub (GA). Provides a central view on all orgs across a multi-org estate, including related orgs such as sandboxes and patch-orgs (which are auto-discovered), but also completely unrelated orgs. This feature requires activation via Salesforce support and will be extremely useful on both large implementation programmes and to ISVs juggling multiple QA, localisation, development, packaging orgs etc. Note, the hub org requires a My Domain to be configured which may be related to single sign-on (SSO), an area of Environment Hub functionality unclear from the release notes.
10. Canvas Apps as Chatter Actions and Chatter Feed Items (Pilot). The UI integration options for standard Canvas apps (i.e. not Visualforce page hosted) is now extended to enable apps to be integrated directly into the Chatter feed as either feed items or publisher actions. In the former case the initial view is collapsed (thumbnail, link and description), clicking the link opens the full canvas app (still in the Chatter feed) to enable a larger display you may not want to see in the feed otherwise. In both cases this is a useful extension to the integration potential for Canvas apps, it will be very interesting to see the real world use cases for this over the coming months.