Summer '13

Quick post highlighting some Summer ’13 goodness for metadata deployment.

1. Abort a running deployment – This is a massive improvement enabling failed or inadvertent deployments to be cancelled whilst in progress. Anyone working on large deployments will bear witness how frustrating it can be to watch a 30 minute deployment run to completion with a failed unit test occurring after 5..

The Abort option appears against the running deployment in the Salesforce web UI. There doesn’t appear to be an abort operation via the Migration Tool or underlying Metadata API.

2. User references are maintained – Simply put, where individual user references (email alert workflow actions, running users etc.) exist in the metadata, the deployment process attempts to match the source usernames to existing target usernames, by stripping-off sandbox suffixes added to sandbox usernames. This is great for sandbox to production deployments, but needs to work with sandbox to sandbox deployments also – the documentation is unclear on this aspect, although it looks likely that this is supported. Multiple match or non-match cases result in a deployment error. I’ve previously used Post-Retrieve Modification via Ant to deal with this through simple string substitution.

3. Metadata API Supported Types. New additions include Approval Processes and SAML SSO configurations. The former being long overdue as approval processes can be extremely time consuming to recreate manually in a target org. The latter provides a minimal convenience for cases where multiple orgs share the same IdP.

The Summer ’13 release notes are now available, find below a brief introduction to 10 Force.com highlights (in no order of significance).

1. New Setup interface. Clean new interface for the Setup area, with a top-level “Setup” link in the header region. Administration and Personal settings are now separate, the latter is accessed from a “My Settings” menu option – available on the user name titled menu in the header region. Streamlined and convenient.

2. Record Type assignment via Permission Set. Non-default custom record types can now be assigned via Permission Set, strengthening the concept that Permission Sets encapsulate application permissions.

3. (Universal Single Sign-on) Multiple SSO service provider configurations. A single org can now be configured as a service provider for multiple identity providers. Previously federated SSO required all users to be authenticated by a single IDP, an unrealistic situation where the org services user populations in disparate IT environments.

4. Test methods must be defined in test classes. Anything that enforces good behaviour is a positive step in my mind. A scattering approach to defining test methods can be a maintenance nightmare.

5. Consolidated asynchronous execution limits. Batch Apex, Scheduled Apex and @futures now share a single set of limits calculated as 250k or 200*standard user count per 24 hour period, whichever is greater. This is really great news for orgs with low standard user counts that utilise @future calls (callouts in trigger scripts perhaps). Such orgs have been prone to limit exceptions.

6. System.scheduleBatch(). New Apex method to enable onetime scheduled invocation of batch Apex class. A nice convenience.

7. Sandbox Templates. For full copy sandbox refreshes, template can be defined to specify the objects for which data is copied.

8. Sandbox refresh copies Custom Settings data. This is a long awaited improvement, applies to all sandbox types. Additionally the new Sandbox page UI shows the availability of the different sandbox types.

9. Domain Management. Force.com Sites (and Site.com sites) can now share domains – Custom URLs are defined between the Site and the Domain enabling a many-to-many relationship. For example it is now possible for a custom domain to host a mixture of sites each with a different Custom URL. A new page “Setup>Administer>Domain Management” enables centralised management of domains and custom URLs.

10. Approval Process deployment via Changeset. Ideally this would also be the case with the Metadata API, that said anyway to automate deployment is great news. The manual configuration of Approval Processes can be a time expensive process, and historically has been one of the issues detracting from the value of deployment automation.

My first post on this blog back in March 2012 related to Simulated Breakpoints, a developer console feature enabling a head dump to be captured when code execution hit a specified line(s) of Apex script. Whilst not comparable to the power of breakpoints in debugging with other languages, Simulated Breakpoints was a definitely step forward for Force.com development, but I suspect this still remains an unused feature, with System.debug() statements being used instead. I don’t believe too many developers are juggling the Force.com IDE and Developer Console, which is unfortunate as the latter provides features and metrics not supported by the IDE.

Checkpoints.
In Summer ’13 Simulated Breakpoints are now termed Checkpoints and can be set on lines of Apex script in the same way using the code editor (now with syntax highlighting) within the Developer Console. In addition to capturing a heap dump, Apex script or SOQL query Execution Actions can be added which run when code execution hits the Checkpoint. Very useful in determining state of the execution context and in particularly in debugging data related issues.

In the screenshot below we can see the new Developer Console UI for Summer 13, the Checkpoints tab and the definition of an example SOQL query Execution Action which will run when the Checkpoint is hit.

In the screenshot below we can see the result, when the Heap Dump log statement is double-clicked a Checkpoint tab is revealed with subtabs that show the Heap Dump itself, plus the result of defined Execution Actions. Note, I was unable to open the Checkpoint results where an Apex Execution Action was defined, from the log activity it does appear to run as an Execute Anonymous block, but it isn’t clear if the user context is the debugging user or the running user.

In the first of a series of short posts looking at interesting aspects of the forthcoming Summer 13 release, this posts explores a new capability to add custom publisher actions to the Chatter UI.

In the screenshot below we see the end-result, i.e. a custom publisher action “Create Account” and the UI displayed when invoked.

Publisher actions (or Global Actions) come in 2 forms; Create a Record and Custom Action.

Create a Record – pick an object, define a layout. Fields can be made mandatory on the layout and given Predefined Field Values, set via formula expressions.
Custom Action – pick a Visualforce page and define the display height dimension

The defined layout or Visualforce page appears as per the first screenshot, in a revealed section beneath the publisher action toolbar. So small, simple displays and basic interactions are in order.

The publisher action toolbar is controlled by Global Publisher Layouts which can be assigned per-profile, and optionally overridden in object page layouts, as required. The Global Publisher Layout is the only means to control the actions visible on the Home page, Chatter Home page and User profile page.

Note, the Enable Publisher Actions option in Chatter Settings must be enabled.

I really like this new feature. The ability to add custom functionality to the Chatter UI opens up a new category of use cases where business process interactions are supported without leaving the Chatter feed. Collaboration really is at the heart of everything.