Do Not Expect - Trouble with HTTP

This is a bit of old issue, but I making this post as it does drive home an important lesson regarding Salesforce.com custom code development.  For one of our customer, there was this legacy code that used HTTP Callouts, which has been working for several years.  However, around the time of Winter '14 Release, the users started reporting that that piece of code was not working.

After digging through it, I was able to narrow it down the problem to following error on response from the callout to the external web service - a standard non-descriptive error message that appears for pretty much all error with HTTP callout:

Read Timeout Error
Unexpected End of Element...

Because the way Apex parses the response,  I couldn't find out much more from the debug log.  As a next step, I tried to find out if the issue was related to how Apex handles the Callout or if it was something wrong with the web service itself by duplicating the request that the Apex code is suppose to generate within SoapUI.  However, from SoapUI, we were getting the response that we expect to get, leading us to go back to the Salesforce side of things.

This time around, what I did to find the issue in the Callout was to strip down the Callout message to bare bones to see if it would work and then adding the elements back to the message one at a time.  The bare bone message did indeed work from Salesforce, and it turned out that problem was caused by following header:

Expect: 100-Continue

The fix for this problem was simply removing that header.  I don't know for sure if this issue was introduced with Winter '14 Release or through the changes to the external web service (btw, this limitation is now documented here).  However, this does provide a reminder on the dangers of using custom code in terms of its fragility when it comes to upgrade either to Salesforce or external service it interfaces.

Introducing Lightning Components - Salesforce Front-end Framework: First Thoughts and Gotchas

One of the biggest announcements from Dreamforce '15 was the new Lightning user interface. For us developers, the part that would be of most interest to us is Lightning Framework – the new component-based Javascript Front-end web framework for Salesforce.com. From going through the Developer's Guide for the Lightning Components, here are my first thoughts and some gotchas I found.

The Lightning Components is intended to allow developing responsive-design single-page app.  This should allow the developers to develop not only a Salesforce app that is more responsive than with Visualforce, but it should also allow us build one app that would optimize based on the client, instead of building separate app for Desktop and Mobile devices.

In terms of the structure, I found it to be quite similar MV*-based front-end frameworks such as AngularJS, Backbone.js or Ionic Framework, and if you are familiar with any of those frameworks, you shouldn't have much difficulty with it. The basic structure is that you create an app, which consists of one or more components with each component representing a section of the page. Each component then can have its own stylesheet, controller/helper scripts, and events.

Some of the main benefits I see is that because it is based on the Javascript, it should make it easier to implement custom Javascript components, such as auto-complete input box.  If you have had experience of taking over the input field with custom code in Visualforce page, you know how nightmarish of task it can become, dealing with Visualforce-specific convention regarding IDs and trying to resolve conflict between Visualforce tag and your Javascript code. Also, the UI testing and testing automation should be easier with this framework as you don't have to deal with auto-generated mark-ups from compiled Visualforce code and aforementioned ID conventions.  I would also like to mention Live Preview support in regards to testing, which you can open from Developer Console.  Finally, this will make managing your CSS stylesheet much easier as you have a separate CSS file associated with each component, instead of having to deal with either static resources or embedded CSS.

As for drawbacks, I did find a few potential issues.  One such issue may be that you have to customize the look-and-feel of every component with your own stylesheet.  One advantage of Visualforce is that it gives you a consistent look-and-feel to the Salesforce platform by default, which is lost with custom stylesheet.  Another issue I found was the file structure.  With the component-based structure, it appears to have completely different file-system structure to the rest of the Apex and Visualforce code directory structure we are familiar with.  As far as I know, you can only edit Lightning Components code from Developer Console, but I would assume it will become available in Force.com IDE and Mavensmate, and I wonder how those IDE/editros will be able to handle this rather diverging structure.

Finally, I would like to close this post with some gotchas I found while going through the Developer's Guide:

•  You can’t use Force.com Canvas apps in Salesforce1 if you enable Lightning components.
•  I think this may be the biggest issue for people looking into enabling Lightning components.
• In order to use Lightning Components, you need to register separate namespace for it.
• Some HTML tags are not supported with Lightning Components.
• Please see https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/ref_supported_html_tags.htm for the list of the supported components.
• You need to create a custom tab in order to enable your component in the Salesforce1 Navigation menu.  
• Also, accessing your Lightning Component from the full Salesforce site is not supported - another major issue that I would think would be resolved before going into GA.

A Developer's Guide to Dreamforce

Another Dreamforce is upon us, and, although I won't be attending this year, I thought this is an opportune time to discuss how to use your time while at Dreamforce based on my experience from last year.

The first advice I would give to any developer attending Dreamforce for the first time would be don't try to attend all the sessions.  Rather, I would minimize the time spend on attending sessions, but try to maximize your time at the Developer Zone.  At the Developer Zone, you will have a chance to get some hands-on experience with new products and emerging technologies.  If it is anything like last year, you will also be able to drop in and listen to a number sessions that are held at the open spaces, and you can, of course, participate on the mini hackathons, even if you are not in the $1 million main hackathon.

As for the actual sessions, I would focus on attend sessions that are presented by either a developer from Salesforce or developers well-known within the community.  Googling the presenters prior to attending sessions could help you decide whether you would want to attend the given session.  I would avoid any session that is specific to a product or a panel discussion as I found most of those were more of promotional rather than educational.  One exception to this is the open developer Q&A session at the end of the conference.  Some of the sessions that I found to be on the better presented include:

• Testing and Testability
• Javascript Debugging

Another fun aspect of Dreamforce is the numerous After-party.  These are great opportunities to social and get some great free food and drinks.  However, it's pretty exclusive, so try to do some research and sign up for those as soon as possible.

Finally, if this is your first time in the Bay area, I would take the weekend and do some sightseeing.  I heard the tour to Alcatraz and Segway tour are really fun, although I didn't get to do those last year.  Also, renting bike and crossing the Golden Gate bridge is great as well.

Anyway,   if this your first time at Dreamforce, I'm sure you will have a great time, and you'll learn thing or two about Salesforce as well.

Validation, Approval Process and Testing

Two of the common sources of headache for Salesforce developer is approval process and validation.  Because these are declarative aspect of Salesforce (i.e. configured through the Salesforce user interface) with some restriction, these can be difficult to manager and migrate

With it being now migratable, many of the pain points for developing approval process in the sandbox has been removed.  However, once you activate an approval process, Salesforce removes some of the functionalities.  You can find more about these limitations here, but I found the following to be particularly difficult to deal with when you have changes in business logic and need to modify the approval process:

• You cannot delete active approval process, and you can't deactivate an approval process if there is any records that are submitted for approval (you have to hard delete those records).
• Once you activate an approval process, you can't add, delete or change the orders of the approval step even if you deactivate them.

With the validation rule, the difficulty I sometimes encounter is when trying to migrate some code and there is additional validation rule in the destination org (e.g. production or QA sandbox).  These validation rule can cause your test methods to fail in the destination org even though it has passed in the development org.  You can either create those validation rule in your development org and refactor your test methods to meet the validation rule, or if you are confident that the additional validation rule will not cause the business logic error when the new code is deployed, you can temporarily disable to the validation rule in the destination org during the migration and re-activate it afterwards. 

New Course on Salesforce App Development on Udacity

While browsing courses on Udacity, I noticed that it will be offering new course on Salesforce App development starting on Monday.  It is aptly named Introduction to Salesforce App Development.  The full course experience is $105/month, but you can follow the courseware for free.  It might be of interesting course for those aspiring Salesforce developers.

Upcoming Salesforce Webinars for Oct. 2013 - Migration, Notification, Mobile, and More

The October, 2013 lineup for the Salesforce webinars has been released, the details for which you can find in the Salesforce event calendar, as per usual.  For this month, instead of focusing on a single theme, the webinars cover various topics ranging from migration, to notification, to mobile development, and to Apex development.

The first webinar for October, which will be held at 7:00am and 10:00am PDT on October 2nd, is entitled Salesforce API Series: Release Management with the Metadata API.  Based on the description and technologies mentioned, the focus of this webinar will be on continuous integration.  This is not something we had to deal with, but for those looking to automate their release of process, this would be interest to you.

On October 10th (9:30am PDT), there will be another session of CodeTalk.  This time, it will be on Apex programming, so the Apex developers out there, get your questions ready.

On October 16th (7:00am and 10:00am PDT), there will be a second webinar, entitiled Alert! Event Notification Options for Force.com Apps.  This webinar promises to go over and discuss various event notification that are available through Salesforce.  The event notification is something that many of our customers ask for, so I am interesting to see if I can pick up some new techniques in this webinar.

Finally, on October 23rd (7:00am and 10:00am PDT) there will be another webinar on mobile development.  This one is called Intro to Salesforce Mobile SDK: Building Android Apps.  Based on the title, this will be similar to the last webinar on iOS app development webinar, except it will walk through development in Android app.  If you enjoy that last webinar and interested doing Force.com app development on Android platform, this would definitely be an interest to you.

Upcoming Salesforce Webinars for Sept. 2013 - Mobile, Mobile, and More Mobile

I am just getting back from my vacation, and for my first post-vacation post, I would like to let you know about upcoming Salesforce Webinars for September 2013.

One of the resources that Salesforce avail to the developers is the webinar - online tutorial or question and answer period - they hold frequently.  These webinars are usually held over GoTo Meeting or Google Hangout, and you can register for free on their respective webpages.  You can find out about their upcoming webinars on the Salesforce event calendar, but I'll also post somewhat regularly about the upcoming webinars here as well.

The focus for September seems to be on mobile development, probably in conjunction with release of version 2 of the Salesforce Mobile SDK.  The first of the webinar is entitled Intro to the Salesforce Mobile SDK: Building iOS Apps and appears to focus on iOS application development using Mobile SDK 2.0.  This will be held on Thursday, Septebmer 5, 2013 at 7:00am PDT and 10:00am PDT.

At 11:00am PDT of  Tuesday, September 10, 2013, there will be a webinar on Rapid Mobile Application Development Using the Appery.io Mobile Pack and Salesforce.com.   I am not familiar with Appery.io, but based on name and on description, this is another framework for developing mobile web application.  I believe this webinar will actually be run by the representative from Appery.io, so we should be able to pick up a thing or two on integrating this framework with Salesforce.

Finally, there will be another CodeTalk on Mobile development at 9:30am PDT, Thursday, September 12, 2013.  CodeTalk is an online question-and-answer session on a chosen topic that Salesforce hold somewhat regularly, and the topic is usually is closely tied to a recently-held webinar.  I usually find these CodeTalks more helpful than the webinar as webinar seems to be more geared towards the beginning developer whereas these are actually answering the questions the developers have.  One thing I would advise is to get your questions ready as it can go by pretty quickly.