May 12, 2017
The Salesforce Streaming API is a wonderful tool that can help you create UIs that stay up to date with your data in real time. You also might find that it mysteriously doesn’t work in IE11, which Salesforce still officially supports on the platform.
Problem 1: Salesforce documentation is horribly out of date
The official documentation has you installing CometD version 2.2 (from 2011) against Salesforce API version 24. This version is way to old to work with IE. I found a blog post from 2014 that determined you need at least 2.9
Problem 2: CometD folder structure has changed
- jQuery is no longer included in the CometD download. Grab the latest jQuery from jquery.com. You need at least 3.1.0 but I used 3.2.1
- json2.js is no longer included in the CometD download. Theoretically this is no longer needed as it is only for IE8 and below and SF only supports IE11 so ignore it.
Problem 3: CometD defaults to WebSockets
Salesforce doesn’t support WebSockets. CometD is supposed to detect this failure and fall back to https, however, it does so by attampting the WebSocket connection, catching the failure, and re-trying with https. Very inefficient and also means that the example code from the Streaming API Developer Guide will not work as is. There are two fixes to make sure you have a robust connection, only one is required but the combination builds in some efficiency and reliability so I highly reccoment implementing both fixes.
Add the line
before calling $.cometd.init to disable WebSockets right off the bat. This will prevent CometD from even attempting the pointless WebSockets call.
Do your subscribes only after the handshake has succeeded by using callbacks instead of syncronous calls like the Salesforce documented example has you do. To do this, you need to split the legacy init call into configure and handshake with a callback.
- $.comet.init should simply change to $.cometd.configure, all parameters can stay exactly as they are.
- Wrap your subscribe call the handshake callback
Problem 4: VisualForce overrides XMLHttpRequest with IServerXMLHTTPRequest2 in IE only
This is a problem because IServerXMLHTTPRequest2 is missing attributes used by the jQuery $.ajax calls.
This one took me forever to find as I had to first use IE debugger with breakpoints to even find out that the object substitution was taking place and then IServerXMLHTTPRequest2 + anything in a search engine returns no results. Finally, I found this forum post. Luckily the fix is easy, just add the following code block before making any $.CometD calls
Putting it all together
Lets take the Salesforce example
This would become
I hope this saves some of you some huge headaches when using the Streaming API with IE11.
January 16, 2017
Why we need a Builder Pattern for our test data
Properly testing Apex code is a necessary and important element of Salesforce development. To do so requires building test data that grows in complexity with the code you are testing.
The Force.com platform gives us a pretty simple way to create sObject Data for Unit Tests. With the dynamic constructors that sObjects are equipped with, we can create records with populated fields.
How is it then that so many people struggle to create good test data?
This pattern does not hide the complexity of the test data creation from the actual test method / class:
Now, there are several issues with the above pattern:
- First off, we need to know all this information for every test method or class we want to create this data for.
- We also need to know which fields need to be populated for our initial insert.
- As well as which fields we need for our actual test.
So at some point, we start to abstract this knowledge away to make our tests clearer and more readable.
This is where the Factory Pattern comes in…
The Factory Pattern is used inside the Force.com community to create abstract test data in an easy, convenient and re-usable way. For example, the above test data could be generated by one line:
Seems nice enough, right?
But now let’s take this pattern one step further. Let’s create a more specific test data:
- [ ] an order with specific items and specific addresses. What do we do?
Over time, our factory classes tend to get bloated, messy and very hard to maintain to a high coding standard.
In the example above, what if we want to create an order with tables, chairs and lamps with a generic address? -> We again create a new static method with specific naming. What happens when our test breaks? And how do we find out quickly which value the OrderSummary__c field has for a specific test? -> It is likely we have to dig into the factory class itself to find out. What if we need to change this value just for one of our new tests?
This is an awful state for our code. The harder it is to understand unit tests, the slower it is to update them and write new ones. This leads to poorly tested code and projects that fail to meet deadlines and requirements.
It feels like our tests drag us down and slow us down.
How can we avoid this terrible state?
In Part Two of our Builder Pattern blog series, we’ll see how the Builder Pattern can clean up some of the issues outlined above.
#blog #builderPattern #mavens
March 01, 2016
We recently updated an application for a client and helped dramatically decrease the time it takes to deploy a change. It was taking upwards to 2 weeks to get through a full deployment the application and now a change can be made and deployed in a matter of minutes.Read more
February 22, 2016
What Problem is Being Solved?
Salesforce Lightning is a great platform and one of the cool “features” is that it encourages the developers to document their Lightning components using the
tags. The platform will then dynamically build documentation specific to your org.
One minor gripe I have is needing to remember the path to the documentation. Read more
January 04, 2016
subscribe via RSS