Pages

Wednesday, December 14, 2016

FuseIT SFDC Explorer 3.4.16349.2

The latest v3.4 release of the FuseIT SFDC Explorer is out and contains a number of new features.

SOQL Queries with nested sub queries

Previously if you did a SOQL query with a nested related query I'd flatten out the results for display. This was less than ideal as all the sub records would get mushed together. Yuck!

Compare this with the developer console where JSON is the preferred way to handle the nested data.

Using the "Flat Display" table button will now toggle between the old behavior and providing a link to popup the nested results.

Basic IDE Workspace support

When you first connect to an Org a check will be made for existing IDEWorkspace records for the authenticating user. This can be used to restore the last anonymous apex code or previous SOQL queries.

Tabular Report Viewer

There is now a basic report viewer. The selected report can be exported to CSV, the clipboard, or Excel's XLSX format. I've only really tested it against tabular reports so far. When exported to Excel both the cell value and label will be maintained.

It's still early days for this feature. There are lots of improvements I could do around maintaining the field data types on the transition to Excel, such as DateTimes, Booleans, picklists. I could also add an option to nominate an ID column to be used for sorting that would then allow you to access more than 2000 records.

Do let me know if this is an area that would be useful to extend.

Asynchronous loading of org metadata

I'd noticed that the login time was getting successively slower. Turns out it was getting expensive to describe the sObject metadata as the number of sObjects grew in each org. They have to batched per 100. I've switched to loading the metadata asynchronously on initial login. It might take a moment before all the sObjects are available.

Pod Status and Release version

After a Session is established a quick check will be made for the current pod status and patch version.

Other changes

  • Improved Tooling API Metadata exploring by caching the describesObject results.
  • In Tooling API SOQL results, directly update values in the GridView
  • Selecting Id's or the Session ID from the Status Bar will give an option to copy the value to the clipboard.
  • Improvements for manual package creation with Metadata Deployment. You can now remove previously added nodes, or diff them with the target org.
  • Option to filter an Apex log to just rows that match the search term.

Wednesday, December 7, 2016

Transitioning to Lightning from Visualforce

Salesforce are pushing, and pushing hard, for customers to transition into the newer Lightning UI. That's not to say that Visualforce is going away any time soon, but it's time to think about moving with the cheese!

Where to start?

Choose a migration strategy

Mike Topalovich did a great blog series and presentation on migrating from Visualforce to Lightning.

In Part 1 he covers the background on Visualforce and Lightning so you know what each is an isn't.
In Part 2 he covers the roles Visualforce can play in Lightning.
Finally, in Part 3 he covers migration strategies for getting an existing org into Lightning.

Adopt the Lightning Design System in Visualforce

I recently completed a project to create a public facing Sites page for some Salesforce data. As it was a new project I thought I'd use a Lightning App and components to put it together. However, as at Winter'17, a Visualforce page that is rendering in a public facing site won't work if it contains a Lightning Component.

Instead I opted to use the Salesforce Lightning Design System (SLDS) with existing Visualforce components. I found this to be a good introduction to the SLDS as I was still using the very familiar Visualforce components.

The first thing I realized about the SLDS was all form and no minimal function. Take the Trees for example. You get a collection of CSS classes and attributes to apply, but must provide all the JavaScript functionality to apply and toggle those classes and attributes as required.

As part of the design for this new page I tried to focus all the page content into separate Visualforce components that communicated via JavaScript. Hopefully with the features come to use Lighting components in this scenario the transition will be easier.

See also, the Trailhead Lightning Design System module.

Locker Service

Coming back to needing to provide all the JavaScript logic to use the SLDS, it's important to consider the compatibility of any third party code you are bring in with the LockerService. See Introducing The LockerService For Lightning Components

Getting helps - Salesforce StackExchange

As always, the Salesforce StackExchange postings on lightning and lightning-components can be great resources for specific questions.

I found these ones in particular interesting:

Developer Tools

The following tools can make if much easier to develop and debug lightning components

Trailhead

At the time of writing there are 11 modules on Lightning in Trailhead targeting developers.

Tuesday, November 1, 2016

Debugging an Outbound Message using a public facing Apex REST web service

I needed a way to capture the SOAP Requests that were being sent by an Outbound Message.

One option would be to host something on my local development machine. However, at work this would necessitate getting a network admin to open a port from our public IP address through to my machine.

Another suggestion, by Daniel Hoechst, was to use an existing online service like http://requestb.in/ to capture the SOAP message.

Instead I thought I'd explore using a public Salesforce Site that exposes a REST web service accepting all POST requests. One advantage of this approach is that the request doesn't need to go off to a third parties server. It's also simple to implement and is mostly just putting a few known parts together.

The first step is to add a public RESTful webservice on the Force.com Site.

The debug log would have been a good option to capture the request, but in Winter '17 a requirement was added to use a cookie to enable the logging - Set a Browser Cookie to Enable Debug Logging for Guest Users. It isn't possible to add a cookie to the outbound message. So, yeah cool. Thanks for that Winter '17 Winking Snowman. (Please vote for the idea: Add IP Whitelisting for Site Guest User Debug Logs)

Instead I've needed to create a basic custom object to store the RestRequest Body.

@RestResource(urlMapping='/SoapMessage')
global with sharing class RESTController {

  @HttpPost  
  global static String inboundSoap() {     
      RestRequest req = RestContext.request;
      
      DataCapture__c dc = new DataCapture__c();
      dc.Data__c = req.requestBody.toString();
      insert dc;
      
      return 'Done ' + dc.Id;
  }
}

Once the Apex class is ready a quick smoke test from POSTMAN to make sure it is working as expected.

Then configure the outbound message to POST to the REST services URL.

Example of a captured outbound message:

Saturday, October 22, 2016

Experiments in 3D printing

I've been experimenting with 3D printing recently after initially having similar opinions to Scott Hanselman on the subject:

The first 3D printed thing I ever saw was a florescent green Yoda head. First you're like "HOW DID YOU DO THIS?" but quickly you're more like "OK, how many brightly colored plastic pieces of crap do I really need in my life?" - Scott Hanselman

My previous impression was that the majority of things people printed were replacement parts for the printer itself.

But... then I got access to a printer to use for a few days and printed a few bits and pieces. I think the first thing I printed was a micro quadcopter frame to carry an equally small FPV camera.

Once I realized I could print things that could fly it sort of snowballed from there.

And fly they do...

Dreamforce

At the Chicago MVP Summit event and Midwest Dreamin' conference I'd taken along a handful of Deployment Fish to hand out to people. They were well received, which left me wondering if I could refine the idea for Dreamforce.

At first I thought I could do a 3D version of the Salesforce logo with a flash drive or Raspberry PI embedded.

The idea kind of worked, but I wasn't sure I wanted something that was the company's logo. Plus, I could never figure out how to correctly fill the middle of the cloud between all the defined spheres so it looked right.

I then tried some variations of the deployment fish concept. I really liked the idea of a punch out deployment fish, but the printer didn't have the resolution to do text for a business card. The other idea was a fish that would clip over a conventional business card.

In the end, keeping it simple seemed like the best idea. So I got some basic stickers printed with my details and put them on the back of the original designs. For good measure I did some Trailhead logos as well.

I also really wanted to get my Twitter handle on my conference badge. I had a number of people recognize me first by my handle. The fish was supposed to slot into the sharks mouth, but I didn't have time to refine it the day before departing for the conference.

Einstein

Shortly before Dreamforce the Einstein announcements started coming out. Putting Einstein in a plane just seemed like the thing to do.

I also played around with having the cloud be Einstein's brain.

Apex Hammer Test

Rumor has it that if you can catch one of each of the Seven Dwarf's they'll forge you a might Apex Test Hammer™ like the one that is used to check every orgs test cases during a seasonal release.

It may or may not bear a striking resemblance to Mjolnir with custom rune plates.

Quadcopter travel frame

I wanted to travel with my quadcopter but didn't want to draw attention to it strapped on the outside of a backpack. I made a basic case for it to slide into with the props removed. This was as much to protect the contents of the bag from it as it was to protect the quad.

Stuff for the kids

There is no end of things to print for the kids. I like the simplicity and usefulness of printing new train track connectors.

Sometimes things don't always go to plan

Sometimes the model isn't correct and you try and print a surface with no depth.

Sometimes the filament feed jams mid print.

Sometimes the entire print bed moves mid print.

If nothing else, 3D printing helps teach you perseverance. Happy printing!

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 'urn:tooling.soap.sforce.com'. Unable to import operation 'create'. The datatype 'urn:metadata.tooling.soap.sforce.com:FTestGeneratedEntityComplexValueType' is missing.

The useful bit is hiding at the end - "The datatype 'urn:metadata.tooling.soap.sforce.com:FTestGeneratedEntityComplexValueType' 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 "urn:metadata.tooling.soap.sforce.com". That's fine, except they are both defined within the "urn:sobject.tooling.soap.sforce.com" 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.

Update: Now a known issue The datatype urn:metadata.tooling.soap.sforce.com:FTestGeneratedEntityComplexValueType is missing


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

Session videos:

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]

The metadata for a single custom object can be split over multiple files. E.g. Split out each individual field.

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 (Org Shape by declaration). 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.

In another session it was suggested that instead you would have a finite number of scratch orgs and would need to explicitly delete them.

They will have a combination of parts from DE and the Branch Org pilot (giving support for multi orgs with the same global namespace). The Accounts etc... that get created with a standard DE org won't exist.

SourceMetadataMember with RevisionNum field will be used to keep local file system source control in sync with any changes made directly in a scratch org. Might be enhanced in the future with a StreamingAPI topic that can be monitored for direct changes in the org.

force.com CLI interface ++

The extended force cli appears to be a number of additional commands added to the existing force.com CLI, or something like it if you start to merge in the Force.com Migration Tool. 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.

Implemented in Node.js using the Heroku CLI pluggable architecture. Support Web and JWT Bearer Token OAuth flows.

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/Hub 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

Conclusions...

  • 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

Random

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: