Last month I attended the London Salesforce Developers’ meetup, which was hosted at the SkillsMatter at CodeNode in Moorgate. You may remember that this is where the 2016 London’s Calling Salesforce community event was recently held.
MobileCaddy is the new proud video sponsor and was recording both talks, which will be published to the new London Salesforce Developers YouTube Channel as they become available. So why not check out the existing videos once you’re done reading this, as they include my goodself doing a live coding demo – building a fully offline Salesforce mobile app using the MobileCaddy SDK.
There were two talks on the night, both Lightning related, though they were quite different from each other. I suppose that’s what happens when you get a new, slightly ambiguous, branding phrase.
Migrating your Apps to Lightning – John Belo
John is an ISV Technical Enablement Director (EMEA) for Salesforce and I’d met him a couple of times before. He had offered his assistance to us at MobileCaddy if we ever needed help with anything Salesforce Mobile SDK related, a kind offer to which I replied that we found them very helpful already – MobileCaddy has actually been submitting code to the core Salesforce Mobile SDK project for a couple of years, providing improvements and bug fixes alike.
The team who work on the Salesforce Mobile SDK are key to anyone wanting to build mobile apps that offer true offline capabilities, and stretch the demands beyond those that are catered for by Salesforce1. We’re thankful for them doing such a great job, so that we can do ours.
John was here to talk about how ISVs can start migrating their apps to Lightning. This is something I’m sure Salesforce wants to really push, to generate some traction around the technology. It was interesting to see though, when asked, how many users were already using Lightning in their apps, which turned out to be only one amongst us all. Other notable stats mentioned were;
- 140+ Lightning-ready Apps
- 50+ Lightning-ready Components
These stats show that although Salesforce is mightily keen on pushing Lightning, it still has a long way to go to gain traction and take-up among ISVs and users alike.
The core of the talk was focused around how ISVs can start using Lightning today to prepare themselves for further takup by users. There are several routes to this, depending on how much work you want to undertake, and also the architecture of what you currently have (if anything). These approaches range from simply adopting the Lightning Design System for style, right through re-writing apps with Lightning components.
One handy route to slowly and controllably adopting Lightning is to migrate chunks of functionality to Lightning, piecemeal. This can be achieved by using Lightning components within Visualforce pages.
Pic courtesy Salesforce
Talks like this from the ISV team are really handy, though I think it will take more (at least more time) for partners to really start rolling Lightning into their current offerings, especially when there are still some elements that are’t available through Lightning yet (and no concrete ETAs, either).
From a mobile perspective, the drive to Lightning may smooth the road to getting apps to fit well with Salesforce1, though of course they will then be subject to the constraints that come with it. Applications that still require advanced features, such as a fully customised UI, or full offline support, need to be built outside of Salesforce1. If your app has the requirements then MobileCaddy is the answer for you.
Lightning Connect Int. with OData Services – Marc Paris
Marc is a Technical Architect at Cognizant and kicked off a passionate talk on Lightning Connect. He talked about how and when it can be used to pull external data into the Salesforce UI.
Lightning Connect was launched towards the end of 2014, but I hadn’t really seen it in action – or maybe I had, and I wasn’t aware of what was happening under the hood, but I suppose that’s its beauty, right?
Lightning Connect can be used to connect in these scenarios;
- Lightning Connect ←→ Lightning Connect – for inter-org communication
- Lightning Connect ← → oData Service
- Lightning Connect ← → Custom Adapter
Marc took us through a demo of the second option, where he had a basic oData service running using the Apache olingo project. He showed us how, through config, the connection could be added, and how Salesforce would use the web service to discover the objects available. Lightning Connect can support the following features, as long as the backend service does likewise;
- Create, Read, Update, Delete
- Filters
- Inter-object Relationships
- Integration with Global Search.
His demo included querying the REST API in a basic manner, as well as using page layouts to filter the data that is requested from the source. He also showed us basic update and delete flows too… it all seems very powerful.
£33k per external source, wowee! – Todd Halfpenny 2014
The power though does come at a cost, currently £33,000 per external data source… a price tag though that may well put a big-ol-hole in a lot of business plans.
It’s interesting to think that through the use of Lightning Connect that no data is stored on SFDC itself, and that it is all pulled/pushed in real-time to and from the external data source. Whether this helps with any data residency restrictions is, of course, another topic altogether. In the questions that followed Marc’s talk the mention of PCI was also raised, but it seemed we all agreed that internal logs may also contain data, so this would need further investigation.
I will post a link to Marc’s slides once I have it.
Wrap Up
Initial thanks, as always, go to the organising crew, and especially to Anup as he was the only one able to make this outing. And thanks to must go to Cognizant who sourced the venue, beers, and pizza (and chocolate snacks too).
Lightning isn’t going to go away, but the path for ISVs is a long one, and one that is going to need investment. With regards to Lightning and fully offline, robust mobile apps, there are still several gaps to be filled. For these reasons it’s not currently our go-to framework; it does not, at the current time, lend itself to the control and extensibility needed to support mobile apps that fulfil parts of critical business processes. Performance issues are another reason that, at present, we are steering our partners and clients to alternative such as Ionic, though of course we hope that this will change in future.
And as for Lightning Connect, I have so many ideas on how it could be used, I just don’t have pockets deep enough.