Monday, October 17, 2016

Salesforce Tooling API Winter '17 (v38.0)

My saga continues. As the seasonal releases pass I'm beginning to suspect more and more that I'm the sole occupant of SOAP Tooling API town.

Previous encounters with the Tooling API include:

Today's post was encountered when updating to the Winter`17 (v38.0) Tooling API.
.NET would failed to update from the new WSDL with the error message:

Custom tool error: Unable to import WebService/Schema. Unable to import binding 'SforceServiceBinding' from namespace ''. Unable to import operation 'create'. The datatype '' is missing.

The useful bit is hiding at the end - "The datatype '' is missing.".

v38.0 of the Tooling API WSDL contains two new and really odd complex types. FTestGeneratedEntityFtest and FTestGeneratedEntityWithLongishNameFtest. The first of these refers to the second via the namespace prefix mns, which is "". That's fine, except they are both defined within the "" namespace.

Commenting these extra complex types out of the WSDL seems to be sufficient to get it going again.

Raised as support case 14900660 for those who want to play along at home.

Bonus Round!

The Tooling API now includes the dreaded QuickActionLayout complex type and the corresponding generated quickActionLayoutColumns multidimensional array. As such, the generated C# class will need the same fix that the Metadata API does.

Double Bonus Round!

The describeGlobal method on the Tooling API is returning 122 new sObjects in the autogen__ namespace. They all have the label "Metadata Facade Template" and the keyPrefix "0Dw". If you attempt to do a describeSObject or describeSObjects API call for any of these autogen__ types you get a GACK response.

Raised as support case 14909168.

Friday, October 14, 2016

Dreamforce 2016 Round-up / Summary

This was my third year attending Salesforce's annual Dreamforce conference in San Francisco.

On the first day of the conference, within the first minutes of entering Moscone West, I walked into a both demoing Microsoft HoloLens units. That sort of set the pace for the rest of the conference. I certainly didn't get to as many sessions as I would have liked to. Managing about a dozen over the 4 days. I'd planned to attend many interesting sessions. According to agenda builder I had a laughably optimistic 58 sessions bookmarked. Instead I focused on the activities that could only be done while there in person. The backlog of 40 odd sessions will have to wait for the recordings to become available.

Salesforce DX

The clues I'd been seeing about "artifacts" turned out to be the internal name for a replacement to packaging that formed part of the larger Salesforce DX (Developer Experience) changes. While many of the conference headlines were for Salesforce Einstein, as a developer the Salesforce DX changes will have a more immediate and significant impact to my day to day operations over the coming years (unless they can get a Salesforce Einstein type product to do intelligent debug log parsing - hint, hint.).

Salesforce DX can mostly be thought of as a catch all name for a number of changes coming for developers (and admins). There are a number of areas affected and numerous changes will need to come together over the next few releases to make it a reality. You might be looking at piloting in Summer '17 and GA in Winter '18 (the usual disclaimer applies). You can register your interest to be in the pilot test when it opens up.

You might like to take a detour to the Salesforce DX posts by Peter Knolle or Matt Lacey

Source-driven development

The current status quo for development, especially of a managed package, is that a single packaging org stands as a source of truth for the current release. With Salesforce DX you will be able to drive deployments from a source control system of your choosing.

To make this possible, we're enabling you to export more of your metadata, define data import files, and easily specify the edition, features, and configuration options of your development, staging, and production environments. [Source]

Scratch Orgs

Scratch Orgs will be shorted lived and provisioned via the new CLI (and in theory a backing API call that the CLI uses). The most appealing part of these orgs is that a JSON file provided to the CLI tool will configure which features are enabled or disabled for the org. You will no longer need to wait 4+ days for support to enable multi-currency in your development org at some random inopportune moment. It will be interesting to see how flexible the APIs will need to become to access things there were previously only accessible via the UI. E.g. Remote Site Settings.

I recall hearing that scratch orgs would last around 2 days, but don't hold me to that. Also, they likely wouldn't be hosted on the production instances, which might open up the options for using the interactive debugger. CLI interface ++

The extended force cli appears to be a number of additional commands added to the existing CLI, or something like it. I mostly view this as a command line friendly wrapper over the functionality provided by the Tooling and Metadata APIs. The big advantage here is that the command line access to these APIs provides an interface that many other developer tools can integrate with. The increased API and CLI support will move many of the developer tasks away for the UI.

Salesforce Environment Manager

[...] a tool we’ve created to make it easier to manage the orgs you use as part of the development process. Most of these orgs will be scratch orgs, but it also allows you to manage your sandbox and production orgs. Furthermore, the Salesforce Environment Manager makes it easy to attach your orgs to Heroku so that they can participate inside of Heroku Pipelines, our continuous delivery tool. [Source]

Packaging / Artifacts

Some of the key themes (for the future):

  • Moving from UI centric to an end-to-end API and CLI support
  • Modules & Namespaces help in name isolation and metadata organization
  • Multiple packages share the same namespace. Removes the need to extension packages and global Apex classes.
  • One App Exchange listing that can install multiple packages.

The Tooling API will be extended (GA Winter `17) to allow for package creation. There will also be an API (Enterprise API?) (GA Winter `17) to create Push Requests.

FMA (Feature Management Activation?) to sit besides the LMA in the LMO to allow features to be toggled in the package. It will include an Activation API and Activation Metrics. For admins in the subscriber orgs it will appear similar to how existing Salesforce features are activated.

Register to Learn More about Salesforce DX

Peek Under the Hood of the New Apex Compiler

This was a really interesting session.

Firstly, it covered how Apex classes are compiled to byte code and then to an interpreted form for execution on the app servers. There are various levels of caching involved at each step.

The latter part of the talk was on how the new Apex compiler was being regression tested to ensure it produced the same output as the existing compiler.

Coming Attractions: Change the Game with Event-Driven Computing on Salesforce

Another really interesting talk about providing a mechanism to raise and consume events. It would be accessible in Apex for event publishing and in Triggers for consuming events. (__e suffix.) They could be described via the Metadata, but won't support queries or updates.

Platform Events (Winter 17 Beta) - PDF

Roadmap is:

  • Winter '17 Beta of Platform Events, Apex Subscriber, External Pub/Sub Platform Events
  • Spring '17 GA for Platform Events, Pilot for High Volume Platform Events
  • Summer '17 Beta for High Volume Platform Events. Additional Messaging protocols.

The Dark Art Of CPU Benchmarking


  • Assignment from static field reference = 20x slower than variable assignment
  • Assignment from dynamic field reference = 30x slower than static reference
  • Use temporary variables instead of referencing a field multiple times!
  • Doing lots of math? Use doubles instead of decimals
    Doubles are 200 times faster (.5 us vs 100 us for decimals)
  • Serializing data can eat up CPU time, depending on the amount of data being serialized.
  • Processes are much less efficient than the equivalent workflow rules.
  • Use Limits.getCPUTime() to find out if you’re getting into trouble, and exit (or go async) if you’re getting close.

True to the core

Meet the developers


Friday, September 30, 2016

Starting related test cases for a given Apex test class

Way back in the day (v27.0 and earlier) it was possible to inline the test cases directly with the apex class. This wasn't always ideal, but it did have one big advantage. Finding the test cases for a class was super easy - they were right there in the class!

This functionality was torn away from us in Summer '13 (v28.0) with the Apex Test Code Segregation act. Maybe that phrasing was a bit melodramatic. The change was actually for the better and heralded in improvements to Apex performance. It did leave a gap with finding the applicable test classes for a given class. This was partially acknowledged with the following planned improvement:

"Test-to-Parent class linking – You will be able to have a test class explicitly related to regular class or trigger. Currently, many of you have implicit connections by adding a suffix or prefix to a class name, but this doesn’t make managing or interacting with your codebase all that much easier. The explicit linkage will allow us to do better UI treatments for related classes. A direct mapping will also make the upcoming Fast Deploy feature much easier to utilize."

Unfortunately for us developers I think the safe harbour this one pulled up in is a bit too comfortable. Since 2013 it's been sitting on a golden beach sipping a cold drink without a care in the world. Maybe we will see it one day.

Back to the now, I've been tinkering with the APIs to try and find an interim solution. There are a couple of challenges with this.

  1. How do you find the Apex classes that directly call a given class?
  2. How do you identify which of those classes is a test class?

The SymbolTable that is exposed by the Tooling API can be useful for the first problem. The ExternalReferences can be used to find all the Apex Classes (and Triggers) that have a direct reference to the given class. It isn't ideal as we really want to find the inbound rather than outbound references. I.e. what calls me, not what do I call. Also, the ExternalReferences returns the class name and namespace, but not the Id. Ugh, so I need to do an extra query to resolve the Id for each class.

There are also less savory ways of finding the reference information if you are willing to pull apart the developer console. Do so at your own risk. One of these is to borrow an unofficial API from the developer console. The short version is that you POST to /_ui/common/apex/debug/ApexCSIAPI and pull out the JSON response. That will give you the list of Apex classes that depend on a given class.

This brings us back to the second problem. How to determine if an Apex class contains Test cases?
My current approach is to do a SOSL query looking for Apex classes that contain @IsTest or testMethod. It can get a few false positives, but at least narrows down the referenced Apex class Ids to those that are likely to contain test methods.

I've put the accumulation of these ideas into the latest release of the FuseIT SFDC Explorer. If you are viewing an individual Apex class you can used the double green arrow to start all the associated test classes.

See also:

FuseIT SFDC Explorer 3.3.16274.7

The latest v3.3 release of the FuseIT SFDC Explorer is out and contains a number of new features. Just in time for Dreamforce '16.

Metadata Deploy

Select a folder to monitor for changes (1). Anything that changes in that folder and is a supported metadata type is added directly to the package.

Select a folder to scan for files modified today (2). Finds any supported metadata types that were added today and adds them to the package.

Redeploy the most recent package (3). If you last deployed from a collection of selected files it will rebuild the package from those and deploy them.

SOSL query support

The SOQL Query tab now doubles as a SOSL query tab (no syntax highlighting yet). You can also export the results to a CSV or the clipboard as with SOQL.

Code Coverage

On the code coverage tab the Percent column has some color coding to indicate if you are hitting the minimum 75% for that class. The individual selected classes is also shown plus an org wide coverage at the top.

The green double arrow to the right of the classes code coverage will attempt to find all the test cases that contribute the the coverage of that class. Then it queues those tests up to run.

Note that as of the time of writing there is a bug in the SOAP version of the Tooling API that is preventing individual line coverage results from being returned.

Apex test execution

If Max Failures is set to a number greater than -1 it will stop after the specified number of test case failures in an asynchronous run.

Individual Entity Viewer

When viewing an individual record by ID the field metadata will be used to expand the property grid and show all the accessible fields. Note that I'm seeing some oddities with the Entity Viewer and sometimes need to toggle between the Categorized and Alphabetical views to get it to render. It might just be something with my display drivers.

Other changes

  • Detect and highlight a "Skipped X bytes of detailed log" message in the debug log
  • WSDL2Apex: Handle class name conflicts within a namespace.
  • WSDL2Apex: Add warning for "INVALID_FIELD_FOR_INSERT_UPDATE - Number of parameters exceeds maximum: 32" - Include names for elements in warnings.
  • WSDL2Apex: Improve error handling if WSDL schema element is missing type attribute
  • WSDL2Apex: ensure enum name starts with a letter. It is not allowed to start with the number in Apex.

Saturday, September 10, 2016

Getting involved in the Salesforce Developer Community

I'll let you in on a little secret. Salesforce as a platform is really big, and it is only getting bigger. See all those colored circles, those are the Sales, Service, Marketing, Community, Analytics, Platform & Apps products. Then there is IoT in the middle integrating with many of those areas. Plus at Dreamforce '16 we are going to learn more about Salesforce Einstein, the new AI product and where it will fit in.

I'll go out on a limb here and say there probably isn't anyone with really in depth knowledge of all these products. And by that I mean deep vertical knowledge that would only come from working with it day in and day out solving real world problems. The sort of person you turn to late on a Friday when the deployment fails with some newly discovered error that even Google has never heard of.

How are you, as a developer, supposed to work with any number of these products at any given time?

No developer is an Island

Thankfully, it isn't all doom and gloom.

There are a number of existing Salesforce communities to help fill in the gaps with your Salesforce knowledge. Best of all, they are all free.

Salesforce StackExchange (SFSE)

This is my personal favorite, so it goes first in the list. Think Stack Overflow specifically for Salesforce. It's a well tuned site for asking and answering questions specific to working with Salesforce. It isn't a discussion forum, so you avoid the back and forward chit chat and associated noise that you get in other places. Plus content gets moderated and refined over time by the community.

An example of community moderation in the StackExchange format is the drive towards removing duplicates and having one conical answer where possible. We don't really need one question per person who encounters a System.QueryException: List has no rows for assignment to SObject exception. One is sufficient to outline how to check if a SOQL query returns at least one result.

SFSE is definitely my first stop for any Salesforce related questions I might have. More often than not the system will suggest a related question to the one you are forming, saving you from creating a new one.

If there is a downside to the SFSE system, it is that it can be a bit unfriendly/daunting to new users. Approaching it like any other forum system likely won't get you the results you want. Before asking a new question, have a read of How do I ask a good question? You want the question to be on topic to Salesforce, about a specific problem, and with the right amount of relevant details that someone could answer it.


  • Include the applicable lines of code.
    If your asking a question about an exception, include the code that caused it. More importantly, indicate which of those lines of code caused the exception. It isn't always obvious when dealing with a snippet of code as line numbers aren't meaningful.
  • Put some effort into formatting your question. Code blocks in particular.
    Use the built in code formatting syntax. A bit of clean formatting makes it much easier for anyone attempting to answer your question to focus on the actual problem rather than misaligned code samples.
  • Vote for the constructive benefit of the site.
    Use your votes to encourage good questions and useful answers.
  • Acknowledge and link to any resources you used.
  • Use the tags.
    These help users identify questions they can potentially answer faster.


  • Post without showing any effort on your part to solve the problem.
    Someone else is giving up their time to try and help you. Include some details about what you have already tried and why it didn't work.
  • Post comments as an answer.
    It will get removed. Instead try and gain sufficient reputation so you can use the commenting system.
  • Post answers as comments.
    Comments are considered transient. They can drop off the page if there are several other interactions occurring. Also, voting on comments only serves to reorder them, nothing else.

Salesforce Developer forums

The Salesforce Developer Forum predates the SFSE. It still offers a broad trove of knowledge in the various threads.

The difficulty here is finding the nuggets of current information. It suffers from a number of problems that Stack Overflow was designed to address with Q&A sites. Lots of duplicates, stale posts that can't be edited, a limited notification system for interacting on multiple threads, painfully bad hyperlinks, etc....


If you've got problems that can be expressing in 140 character then the #askforce hash tag can provide 140 character solutions.

Also follow and interact with MVPs and UG leaders.

Local User Groups

Check if there is already a local user group that you could attend. This is a great way to network, attend presentations, and share ideas.

Salesforce blogs

Many members of the Salesforce Developer community also run blogs that run the gamut of products. Rather than trying to compile such a list here I'll refer you to Johan Yu's complied a list of Salesforce Blogs.


First off, you got me, this isn't really a community where you can interact with other developers directly. At least not on the face of it. Initially it is an excellent learning resource for Salesforce. You can take modules on topics of interest and then complete some challenges to help cement what you have just learned. However, the more time you spend doing it the more you find there is a whole community of people behind it as well. See #Trailhead. Also, it is not uncommon to see Trailhead specific events at usergroups.


Suggest new enhancements or vote on existing ideas to see the products changed.

Wednesday, August 24, 2016

Dreamforce 2016 Session Picks and General Tips

Here are some of my current picks for Dreamforce 2016 sessions. They are mostly development or architecture focused. I'll be refining the list as more information becomes available. As with previous years, it's likely that I won't actually get to all of these and will need to prioritize activities that can only happen at Dreamforce vs. things that are being recorded.

If you haven't already registered for Dreamforce you can use the Developer Discount code D15DEV999F


Something is coming in the packaging/change set/metadata deployment area. The first session in this list is definitely worth a visit. Here's hoping for some sort of source control integrated deployments.

Mocking and Testing

The Winter '17 Release notes include the section - Build a Mocking Framework with the Apex Stub API (Pilot). I'm lead to believe that the first of the talks below will have some more details on using the System.StubProvider interface and System.Test.createStub() method. If only because Aaron Slettehaugh from Salesforce is also presenting with Jesse Altman.

Meet The *'s

The Meet the Developers session on the last day of the conference is always an interesting one and might not be recorded. This year I see two other additional variations.


  • Developer Keynote - Thursday Oct 6th 11-12pm
  • Main Dreamforce Keynote - Wednesday Oct 5th 1-3pm
  • Mark & Exec Q&A - Friday Oct 7th 2-3pm
  • Something on the new Einstein AI product? Salesforce Einstein Keynote: AI for Everyone


It goes without saying that everything will be either Lightning or Trailhead based this year. Probably both.

Custom Metadata


Platform Events

Winter '17 Release Notes:

Use platform events to deliver secure and scalable custom notifications within Salesforce or from external sources. Define fields to customize your platform event. Your custom platform event determines the event data that the Platform can produce or consume.


General Tips

Hopefully you've been an adult for long enough by now to know if you're going to do a lot of walking you probably need to wear something comfortable on your feet. Seems like an odd thing to have to remind people about. Then again, all my shoes are comfortable. Why are people buying shoes that aren't comfortable?

  • Don’t bring your laptop. In previous years other channels were promoting travelling light with just a cellphone and maybe a tablet. I say bring a small laptop to the developer zone in Moscone West. Seen something cool in a session and want to try it out straight away? A laptop gives you full access to Salesforce and your favorite developer tools. I've never tried to code Apex on my phone or tablet, but I'm pretty sure it would be a frustratingly slow experience. With Trailhead being such a big part of the developer zone this year, it could be useful to knock out a few modules on the go. There are also the development "Mini Hacks" to be completed. Easier to have your own machine on hand than have to wait for a community machine of unknown configuration.
  • Following on from that, create a blank dev org. Maybe a prerelease org. This gives you a blank canvas to experiment from.
  • Bring a power bank type device to charge your cellphone so you can avoid being tied to a powerpoint. You can probably pick several of these up from vendors as giveaways if need be.
  • Talk to the person next to you, find out what they do for a living with Salesforce. Find out what sessions they liked so far and what they intend to attend.
  • If you get a good photo of a presenter during a session, share it with them. The session audio and slides are often recorded, but there may be no other visual proof that they presented at Dreamforce.
  • Be mindful of who you let scan your badge. By all means, if you want to hear from them again scan away. Otherwise, is it worth giving your contact details to a vendor for some shiny trinkets to take home to the kids?
  • A developer can mostly stay within the Moscone West building and find plenty of suitable sessions and vendors to visit. It will be full of technical sessions and activities. That's not to say the an excursion out to Moscone North for the main expo isn't worth it. (Expo map)
  • Be adaptable with your scheduling. The majority of the sessions are recorded. It's sad for the presenters who have put so much effort into creating their sessions, but focus on things that you can't catch up on later in the recordings.
  • Stop by the Admin Zone. In previous years they have offered professional headshots (Headshot studio?). Do this early in the conference before lack of sleep starts to catch up with you.
  • Get your twitter handle and avatar on your badge. I spend all year interacting with people via twitter, then struggle to identify them in real life if they don't resemble their abstract avatar.
  • Fleet Week San Francisco is on October 3-10. If you like planes the airshow was worth a detour or an extended stay if you can.
  • Track Dreamforce Shuttle Locations in Real-Time:
  • The Salesforce Events App: iPhone and Android
  • Dreamforce BART promotion for round trip from SFO to downtown SF.
    A Clipper card for Muni, BART, & CalTrain to get around! FYI, brings Bay Area transit all together in one site.

International Traveler

  • Plan on having an extra bag on the way back incase you pickup some oversized swag.
  • Get a local sim card. Have a plan if you previously relied on SMS 2 factor authentication. Update apps like Uber with your new temp contact details.
  • Switch your Calendar to PST.
  • If you can time it right, drop ship things to the FedEx office at 726 Market St. It is only a quick walk from the conference and you can get a "Hold at FedEx location" when shipping.

See also:

Tuesday, August 16, 2016

Using Two-Factor Authentication in Salesforce with Windows 10 Mobile

As part of the Trailhead User Authentication - Secure Your Users' Identity module I enabled Two-Factor authentication for a user in my developer org.

Upon logging in with the user required to use 2FA I now get the following prompt to download the "Salesforce Authenticator from the App Store or Google Play":

As a Windows Phone / Windows 10 Mobile user this wasn't really an option for me.

Happily, Salesforce is using the IETF RFC 6238 time-based one-time password (TOTP) algorithm. Being a standard we can substitute in another app that is available - such as Microsoft's Authenticator.

  • Use the "Choose Another Verification Method" link at the bottom of the "Connect Salesforce Authenticator" page.
  • Choose "Use verification codes from an authenticator app"
  • Start the Authenticator app on your phone. Use the "add" app bar button. Use the "Scan" button.
  • Optionally tap the new entry to give it a more meaningful name.
  • Use the generated code to complete the authentication process.

See also: