Salesforce TLS 1.0 Support

As of June 25th 2016 sandbox orgs no longer support TLS 1.0 encryption. The previously optional critical update “Require TLS 1.1 or higher for HTTPS connections” was auto-activated on this date. Production orgs will be auto-activated on the 4th March 2017.

Inbound API connections requesting TLS 1.0 will receive the error message “TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https.”.

Eclipse IDE Error

For Force.com IDE (Eclipse) users on Java 7 the eclipse.ini file must be modified to add the line below. This is not required for Java 8.

-Dhttps.protocols=TLSv1.1,TLSv1.2

Further information here.

External Id Deployment Error

On occasion when deploying components between orgs you may encounter a database-level category of deployment error, bubbling up from the underlying Oracle RDBMS with limited information to support any diagnostic process. The example below is one such case I’ve seen in practice recently. Most concerning about this type of error is that the deployment appears to commit (with the exception of the affected fields) but reports a failure result state. It’s therefore one to take seriously in automated build environments where undesirable action may be taken on the basis of the build result etc.

Example Case – Too many external Ids on a single object
Scenario – object (standard or custom) has 3 custom fields defined as external Ids (this is the soft limit), and an attempt is made to deploy a new object definition with 2 different fields marked as external Ids, making the sum 5. Remember, the deployment won’t remove this field attribute. In all such cases, where the updated object definition has more than the 3 limit, the result is..

C:\Program Files (x86)\Jenkins\jobs\..\workspace\build.xml:41: Failed to process the request successfully. Cause(LIMIT_EXCEEDED): LIMIT_EXCEEDED: java.sql.SQLException: ORA-20526: 
ORA-06512: at "HAPPY.CCUSTOMINDEX", line 275
ORA-06512: at line 1
: {call cCustomIndex.insert_detail(?,?,?,?,?,?,?,?,?,?,?)}

..or..

C:\Program Files (x86)\Jenkins\jobs\..\build.xml:41: Failed to process the request successfully. Cause(LIMIT_EXCEEDED): LIMIT_EXCEEDED: java.sql.SQLException: ORA-20526: 
ORA-06512: at "SLEEPY.CCUSTOMINDEX", line 275
ORA-06512: at line 1
: {call cCustomIndex.insert_detail(?,?,?,?,?,?,?,?,?,?,?)}

I’ve also seen this behaviour with deployments that exceed the tracked fields limit in a similar way, however I’ve been unable to recreate this with the 27.0 Metadata API.

Salesforce Tooling API

With the upcoming Spring 13 release (release window dates below) the new Tooling API goes GA.

11th Jan, sandbox instances
18th Jan – 9th Feb, production instances (EU0 8th Feb, EU1/2 9th Feb)

What is the Tooling API?
The full details can be found in the API guide here, in short the API is intended to provide an optimised, standardised, capable and compelling interface for tools developers. Full stop. The latter two points being key – a major complaint I’ve been hearing for a long time is the immaturity of the available developer tools and the lack of choice. Substandard tools (relative to Ruby, Java and particularly .NET etc.) can really hamper adoption within the IT department, it never ceases to surprise me how much power developers can wield particularly where strong technical leadership is absent.

The Tooling API supports both SOAP and REST styles of web service and enables working copy management for the Apex metadata types, update synchronisation and error checking as well as access to heap dumps, debug logs and so forth. All in all the provided functionality looks like all you’d need to build a rich development tool or Force.com augmentation to an existing toolset.

A new open source version of the Force.com IDE, developed with the Tooling API, will follow the GA release, no date announced.

If I had the time, my first task for 2013 would be to design and build an iPad developer app; delivering a super-efficient developer experience, integrated with GitHub etc.. Anyone who has experienced code-editing in the web app in the iPad Safari browser will surely agree, this could be a winner! I suspect other more forward thinking people will already have such things ready to ship as soon as Spring ’13 rolls out. I hope so. Looking forward to 2013 being the year of new and innovative developer tools..