Build an application on Salesforce App Cloud from start to finish

December 2015...

The force has just awakened...

And the Trailhead Team have created an incredible new project that helps you wake up in the force too... you can build your first application on Salesforce App Cloud from start to finish.

Build a Battle Station App

This links to the new Trailhead project

The purpose of this project is to guide you through the process of building an application on Salesforce App Cloud from start to finish.

You will not be required to write any code; so don't panic if you're new to App Cloud, because the purpose of this Trailhead project is to introduce you to the basics of app building.

You need a free Developer Edition ORG to complete this project. If you don't have one, you can create a new one here.

This new app you are going to build is a project management app that allows users to manage the resources and supplies used to build a Battle Station.

You will learn point-and-click skills that are applicable to building almost anything on App Cloud. Here's what you'll be doing: 

     - Create the app and a data model for the application. This simple application requires only a few custom objects with a small number of fields. 

     - Modify the user interface on the browser and on Salesforce1 Mobile using page layouts, compact layouts, and global actions

     - Implement business logic using formulas, validation rules and a process builder

     - Build reports and dashboards to track the status of supplies and analyze how well the company manages resources.

Go get your hands on this new Trailhead project and complete it by the 31st of December for a chance to win some amazing prizes:
     - 3 PlayStation 4 Consoles
     - 10 Sphero Robots
     - 15 Air Hogs Remote Control Quad Copters

More new content

If you're not new to Salesforce there are good news for you too! There is some new Trailhead content for you to look at and earn some new badges! 

Admin Advanced Trail 

Reach all star admin status by tackling more advanced Salesforce features.

Link here. 

   

Apex Integration Services Module 

Integrate with external apps using Apex REST and SOAP services.

Link here. 

    

Advanced Formulas Module 

Learn how to write clean, easy-to-understand formulas for complex use cases.

Link here. 

    

Lightning Chatter Basics Module 

Get started with enterprise social collaboration in the new Lightning Experience.

Link here. 
 
 

Lightning Data Management Module 

Learn how to import and export data in the new Lightning Experience.

Link here. 
  
 
 

Application Lifecycle Management (rewritten) 

Learn best practices for team app development and lifecycle management.

Link here.


 

Salesforce & XMLHttpRequest & Internet Explorer - Bermuda Triangle!

Möbius Strip

Have you ever found yourself walking in circles? Have you ever been stuck in an infinite loop with no exit? Feeling like you are trapped in the Bermuda Triangle? Maybe feeling like Jack Shephard in Lost unable to find a wait out off the island?

Well, I have to say that I have. And I have to admit that it's not only been once or twice...

I consider myself a frequent lost passenger walking on a Möbius Strip like the one next to these lines... Well, this is probably one of the side effects of being a developer.

That feeling of frustration when you get stuck, and you think about the same thing over and over again, when it appears even in your dreams and doesn't let you rest while you sleep. I guess you know what I'm talking about...

That situation is something I experienced a few weeks ago when I was working on one of my Salesforce projects, on an integration with ShareFile.

WHAT HAPPENED?

As part of our Salesforce integration, we were using the ShareFile REST API, and we had to send files as multipart/form-data.

The environment and requirements of the project forced us to send the files from the client side. We were therefore using JavaScript, so we were basically declaring an XMLHttpRequest object and sending the content with a POST method to the relevant endpoint.

We were happily working on Google Chrome, where everything worked successfully and our files were smoothly being sent to our endpoints. But we then moved to Internet Explorer, and that's when we encountered problems...

Yes, I know, who uses IE? Well, a lot of people do... And our clients used IE, so we had to make it work for IE10 and IE11.

HOW DID WE SOLVE IT?

 
Initially we thought that the problem had to do with CORS policies (Cross-Origin Resource Sharing), so we focused on that area for a while, but that wasn't the issue, because we were successfully connecting to our endpoints, so that wasn't the root of the problem.

Hours and days of googling and revisiting our code, checking for possible causes mistakes in our approach didn't really give us a clue...

We then started sniffing the traffic produced by the HTTP requests and responses sent by Chrome, to compare them with the HTTP requests and responses sent when using IE.

That was a critical exercise, because it really helped up find out some differences in the request headers. Our POST request was a multipart/form-data, and it needed to include a specific header, like the following:

var xhr = new XMLHttpRequest();
xhr.open("POST", "https://the_endpoint", true);
xhr.setRequestHeader("Content-Type", "multipart/form-data; boundary=the_boundary");
xhr.send(your_data);

But we found, by analysing the traffic, that this header was somehow being removed from the request, so the message was badly formed and our request wasn't valid. So, who was removing the header that we were populating in our code?

THE SOLUTION

The answer to our question was found by stripping down all the code from the page we were using. We removed all the Visualforce skeleton from the page, as well as all the libraries imported by Visualforce.

After doing this, our code started working! What we did was correct from the beginning!

Now, that was a relieve... We were getting there, and we only had to find out what was causing our HTTP header being removed. We did some research and found this question in the Salesforce Stack Exchange and this discussion in the Salesforce Developers forum. The discussions on these links led us to the right place.

We found out that the VRremote.js library imported by the Salesforce Visualforce pages overrides the default behaviour of the XMLHttpRequest object; so that the Content-Type request header was being removed from the request when running on Internet Explorer, and the request became invalid. By forcing it to use the default implementation of the object we could make it work for IE10 and IE11.

The only change we had to do to our code was forcing the XMLHttpRequest object to use the default implementation and not the overriden version from the VRemote.js library:

if(isIE)
{
    XMLHttpRequest = Sarissa.originalXMLHttpRequest;
}
var xhr = new XMLHttpRequest();
xhr.open("POST", "https://the_endpoint", true);
xhr.setRequestHeader("Content-Type","multipart/form-data; boundary=the_boundary");
xhr.send(your_data);

EUREKA! Our code was ready! And after fixing this problem we starting catching up again with our sleep and the quality of our dreams!

THE TAKEAWAYS

Never give up!!

I said earlier that being in this type of situations where you can't seem to find a solution is one of the side effects of being a developer. It may be hard times when you can't see the light at the end of the tunnel, but how good is that feeling when you solve it!! It's like feeling you are Marty McFly!! The satisfaction of solving the problem leaves all the stress behind, and that's also a positive side effect of being a developer; I think that's the motivation we have for problem-solving, and it's what makes it great to be a developer!
  

Salesforce Trailhead: Learning Lightning Development

We are just 2 weeks away from Dreamforce 2015, I'm going again this year, so I have to get up to speed with the latest features. After last week's announcement to Meet the New Salesforce you can't help but get your hands on learning the new Lightning Experience, and what better way to do it than with Trailhead? None. So that's why I encourage everyone wanting to start building Lightning components to check it out. It's also a really nice way of starting your preparation for what's to come with the new Salesforce release in Winter '16.

The Lightning Experience Developer Trail takes you through 5 modules to show you an overview of the different points of view of the new Salesforce development approach:

• Lightning Experience Basics 
• Lightning Experience Development 
• Visualforce & Lightning Experience 
• Lightning Components 
• Lightning Design System

I consider it quite important to highlight that the Lightning Experience is not fully terminated and rolled out to the whole platform at the time of writing this post (September 2015), and even if it brings new capabilities that weren't available before, it is still "Work In Progress" and it doesn't support all the features that Salesforce Classic does at the moment.

In Salesforce's own words: "Lightning components are still in their infancy and not all the features you’re used to in Visualforce are fully supported yet."

Just be patient and let the Salesforce team do their job. We'll definitely be getting updates from them with the progress through the usual channels...

This is what you can expect from each of the Modules. As usual, you will earn some new badges and you can win up to 5800 points!


Lightning Experience Basics

Find out about what the Lightning Experience is and how it's different to Salesforce Classic. View examples of the look and feel of the new interface.

Get advice on how to decide whether the new experience is right for you.

Instructions on how to enable it in your ORG.



Lightning Experience Development

An overview of the impact of the new User Experience on the typical Developer tools, like Apex, the API, Visualforce, and others.

Recommendations on what technology you should use depending on the requirements of your application. One of the features from the Lightning Experience I'm more excited about is the fact that you don't have to worry about compatibility accross devices and browsers, it's all taken care of for you!

Guidance on what to do with Packaged applications or the Apps in the AppExchange to accommodate the new Lightning Experience.

Visualforce & Lightning Experience

You will find out the ways in which you can keep using Visualforce within the Lightning Experience.

Set up your work environment for a better development experience: code editor, page viewers and review in multiple environments.

Discover how Visualforce pages behave when running in Lightning Experience and how to share them between both experiences, as well as the styling considerations to bare in mind.

Lightning Components

This module describes what Lightning Components are and how the new Lightning Components framework differs from the Visualforce one. Prepare for a good 4 hours of exciting training with this module, because this is where you will write some actual code and connect your Trailhead to your Developer ORG to create some Lightning Components.

An overview of the different techniques available for Lightning Components is given in this module: server-side and client-side controllers, Apex and JavaScript...

Lightning Design System

This final module goes into the Design principals used in the Lightning Experience. You get introduced to the Block-Element-Modifier syntax (BEM) for styling your components.

Some explanations about the Grid System, that is a good way to understand the layout that your Lightning Components will use.

You will find out next the recommended ways of accessing your Data in Salesforce from your Lightning Components; and also how to include Avatars and Icons within your components.

The final activity of this module helps you build Record Home Page making use of several components!

And now you're all set to understand MOST of what people will be talking about at Dreamforce '15!

It was helpful for me, so I hope this is also of help for you.
 

Trailhead by Salesforce: Detective Learning with Event Monitoring!

If you are thinking of learning Salesforce, or you already know Salesforce and want to update your knowledge and get up to speed with the latest features, a very good way to do it is to use Trailhead, an interactive and intuitive learning tool provided by Salesforce to guide you through the process of learning about the Salesforce1 platform while having fun. Your achievements will be rewarded with points and badges.

There are now 30 modules, 7 trails and 6 projects available in Trailhead, aimed at both admins and developers, so you can choose the one that best suits your needs.

The latest Trailhead releases are the following:

- Admin Trail - CRM, with three modules
- Dreamforce Trail with Get Ready for Dreamforce module
- Event Monitoring

Out of the new content, today I will be focusing on the Event Monitoring module. I have recently been carrying on some investigations in one of the Salesforce orgs that I usually work on to find out who did something really dodgy on a trigger, and I find it fascinating all the things you can find out when you dig in a bit deeper, so doing the Trailhead module on Event Monitoring would help me become a better Salesforce Detective.

It takes about 45 minutes to finish the whole module, broken down into 15 minute blocks that you can follow as you find gaps through your day, or whenever you need a break from whatever you are doing. These are the three blocks for the Event Monitoring module, each of them can give you up to 100 points, a total of 300!

Get Started with Event Monitoring: This is an introduction to Event Monitoring, explaining what you can achieve with it and defining a few basic concepts. The way this block is structured makes you want to keep reading and it definitely catches your attention.

Query Event Log Files: This section drives you through one of the most useful tools in Salesforce, the Workbench, which allows you to inspect the Event Log Files in a very intuitive way.

Trailhead shows your module progress as you play along

Download and Visualize Event Log Files: This last block gives you details about how to download the Event Log Files and the format in which the files are generated, so that it becomes easy for the end user to read and understand the file's content.

So once you complete your module, you'll get your points and new modules are suggested to you. I encourage you to take on the different modules, even if you already know Salesforce, as it gives you other points of view and approaches you wouldn't have thought yourself...

I wish I could have used Trailhead when I first started learning Salesforce, it makes it a lot easier to learn, more in line with the online world we live in.

And if you are not sure how to get started with Trailhead, you can alwasy check for Salesforce User Groups in your area; you will always find someone there to ask for help or even organise a joint Trailhead session.

Thanks very much for reading this post, I hope you found it useful and enjoyed getting started with Trailhead.
   

Files with non-standard encodings in Salesforce

This post is about one of my latest challenges at work. It looked like something simple to achieve, but it turned out to be a difficult one...

THE REQUIREMENTS

The requirement was to build attachments in Salesforce that could then be downloaded. Those files would then be imported into a third party software for processing. It doesn't seem to be a difficult task, on paper it is a straight forward thing to achieve...

The problem was that we were dealing with a Korean third party, and the content of the files was in Korean (really funny looking characters from my point of view...). They were plain text files, but written in Korean...

The obvious solution was to provide button with a link to a URLFOR pointing to the attachment Id, that would download the file directly from Salesforce.

The following snippet shows the simple solution that would download the attachment in one click:

Once the file was downloaded, it was ready to be imported by the third party software. The third party software provides a preview feature, that lets the user see what is going to be imported before submitting.

Unfortunately, the result was not the expected one. See the following images to compare the expected result with the actual result, there are some characters that could not be successfully read by the third party sofware... What are those question marks there?

Expected result

Actual Result

THE PROBLEM

After that came investigation time... What might be going wrong? Comparing the text files with comparison utilities did not provide any clues... Checking for additional blank spaces... Checking for implementation of the line breaks... It all looked the same!!!

Finally, after inspecting every single aspect of the files I made a binary comparison of the files with Beyond Compare, and the bytes were not the same for the same shown text. The problem was that the files had different encodings!!!

THE SOURCE OF THE PROBLEM

So we got to the root of the problem: the third party software was expecting an EUC-KR encoding, whereas the file provided by Salesforce was created with a UTF-8 encoding.

Now, I had to find a way to create my downloadable files with the EUC-KR enconding, and the body of those files was the body of the Salesforce attachments.

Salesforce only uses the UTF-8 standard enconding for all the files; now that stopped me from using the solution in the snippet above, because there was no way Salesforce was going to create the files in the format I needed in just one click and one line of code...

But that's where the challenge is, and that's what us developers love!! We love chanllenges!! And this case became one for me, hence this blog entry...

Another problem I found with this specific case was that the EUC-KR encoding is a legacy encoding, i.e. it's not a standard one and it is not supported by most of the browsers by default.

THE SOLUTION

Thankfully I found this github repository with a polyfill for the Encoding Living Standard's API by inexorabletash (many thanks for your solution). It is an implementation of the TextEncoder API.

The github repo includes the source file for the encoding.js and encoding-indexes.js libraries. The later is required when working with non-standard encodings; and following the repository's README explains the usage of the libraries.

This solution has been really helpful for me because it did what I needed, although it didn't work with the exact source code from the repository, so I had to apply a tiny tweak to the code in the encoding.js library.

I was using a version of Chrome that natively supports the TextEncoder API, so the polyfill wasn't being used, and therefore the EUC-KR encoding wasn't being recognised as a valid entry.

I had to modify the library to implement my TextEncoderCustom API, which was easily done by just replacing the TextEncoder string by the TextEncoderCustom string in the encoding.js file. Once this is done, the browser will use your own implementation of the TextEncoder API, which is your TextEncoderCustom API.

In the following code snippet, the variable uint8array is properly encoded with an EUC-KR format and it can be used to be saved in a file:


You need to create static resources in Salesforce for the libraries to be included in your Visualforce page as shown in the snippet above.

I hope you find this post useful if you need to work with non standard encodings in Salesforce. Once again, many thanks to inexorabletash for the github contribution.