Showing posts tagged with:
This diagram provides a high-level overview of Salesforce Development Architecture concepts and platform capabilities. This is the fourth in a five-part Salesforce Architecture reference series covering core application and system architecture topics.
The document linked below provides a high-level overview of the Marketing Cloud data modelling and management tools, programming languages, and APIs. For architects and developers taking the Salesforce Marketing Cloud Developer certification the document provides a useful technical reference.
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.”.
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.
[code language=”text”]
-Dhttps.protocols=TLSv1.1,TLSv1.2
[/code]
Further information here.
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..
[sourcecode language=”text”]
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(?,?,?,?,?,?,?,?,?,?,?)}
[/sourcecode]
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.
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..
