Wednesday, February 21, 2018

[Salesforce / Amazon Echo] AlexForce 2.0: integrate Salesforce and Alexa (the ultimate Apex library)

More than 2 years ago I wrote about a library I made up for integrating Salesforce and Amazon Echo, using its REST APIs and Apex: this is the original post.

I supported the library for a while hoping that the Ohana could took ownership of it but unfortunately this didn't happened.

With great surprise I met the next guest blogger, Harm Korten, who was developing his own version of the AlexaForce library.

I'm more than happy to give him place to his amazing library and hope that the time is now ripe to bring this library to the big audience!

Harm Korten is a Force.com fan from The Netherlands. His professional career in IT started in 2001 as a developer, but his interest in computers started well before that. He got introduced to Salesforce in 2005, working at one of the
first Dutch Salesforce.com partners, Vivens. He has been a Salesforce fan and advocate ever since.
Over the years, he has worked on countless Salesforce projects, at dozens of Salesforce end-user customers. Currently he is active at Appsolutely, a Dutch Salesforce partner, founded in 2017.
Find him on LinkedIn or follow his Salesforce (and other) adventures on his blog at harmkorten.nl.




Introduction


In the first week of 2018, I ran into some of Enrico Murru’s work. Google offered his AlexaForce Git Repo (https://github.com/enreeco/alexa-force) as a suggestion to one of my many questions about integrating Amazon Alexa (https://developer.amazon.com/alexa) with Salesforce. It turned out Enrico had been working on this same thing, using the same technology stack, as I was at this moment.

An Alexa Skill SDK in APEX, only 2 years earlier!

Nerd reference

Up until this moment, besides Enrico’s proof of concept version of such an SDK, the only available technology stacks that would allow integration between Salesforce and Alexa were the Node.js and Java SDK’s. These could be hosted on Heroku and use Salesforce API’s to integrate.

Like Enrico, I wanted to build an on-platform (Force.com) Alexa Skill SDK. This common interest put us in contact. One of the results is this guest blog, not surprisingly, about AlexaForce. Not Enrico’s AlexaForce, but Harm’s AlexaForce. We apparently both came up with this very special name for the SDK (surprise, surprise) ;)


AlexaForce


The basic idea about this Force.com SDK for Alexa, is to remove the necessity to work with Salesforce data through the Salesforce API. The Java or Node.js approach would have Amazon send requests to Heroku and from therefore require API communication with Salesforce.

With the AlexaForce SDK, Amazon will send the Alexa requests straight to Salesforce, allowing a developer to have full access to the Salesforce data, using SOQL, SOSL and APEX. The resulting architecture is depicted on the image below.


For more information about AlexaForce and how to use it, please visit https://github.com/HKOLWD/AlexaForce. You will find code samples and a detailed instruction there. For this article, I will elaborate on a specific Alexa Skill design approach, which is still in beta at Amazon: Dialogs.


Dialogs


Generally spoken, the most important part of an Alexa Skill, is its Interaction Model. The Interaction Model is defined in the Amazon Developer Portal when creating a new skill. The model will determine how comprehensive your skill will be as well as its user-friendliness, among other things.

An Alexa Skill model generally consists of Intents and Slots. The Intent holds what the user is trying to achieve, the Slots contain details about the specifics of the user’s intention. For example, the Intent could be ordering a pizza, the Slots could be the name and size of the pizza, the delivery location and desired delivery time.

One could build a model that just defines Intents, Slots, Slot Types and some sample utterances. This type of model would put a lot of the handling of the conversation between Alexa and the user in your (APEX) code. Prompting for information, checking and validating user input etc. would all be up to your code.

Here’s where Dialogs come in handy. With a Dialog (which is still in beta at the time of this writing) you put some of the conversation handling inside the Interaction Model. In other words, besides defining Intents, Slots and Utterances, you also define Alexa’s responses to the user. For example, the phrase Alexa would use to ask for a specific piece of information or how to confirm information given by the user.


From an AlexaForce perspective, you could simply tell Alexa to handle the next response using this Dialog definition inside the Interaction Model. This is done by having AlexaForce send a Dialog.Delegate directive to Alexa.


Example


Imagine an Alexa Skill that takes support requests from the user and creates a Case in Salesforce based on the user’s request, a ServiceRequest (Intent) in this example.

Two important data points (Slots) need to be provided by the user:

  1. The topic of the request. Represented by ServiceTopic in this example.
  2. The description of the issue. Represented by IssueDescription in this example

A Dialog allows you to have Alexa collect the data points and have them confirmed autonomously. The APEX keeps delegating conversation handling to Alexa until all required Slots have been filled.

A Dialog has 3 states, STARTED, IN_PROGRESS and COMPLETED. When COMPLETED, you can be sure that Alexa has fully fulfilled the Intent as defined in your model, including all its required Slots. Below is a code sample that would implement this, returning true on Dialog completion.

if(req.dialogState == 'STARTED') {
    alexaforce.Model.AlexaDirective dir = new alexaforce.Model.AlexaDirective();
    dir.type = 'Dialog.Delegate';
    dirManager.setDirective(dir);
    return false;
} else if(req.dialogState != 'COMPLETED') {
    alexaforce.Model.AlexaDirective dir = new alexaforce.Model.AlexaDirective();
    dir.type = 'Dialog.Delegate';
    dirManager.setDirective(dir);
    return false;
            
} else {
    return true;
}

The APEX takes over again when Alexa sends the dialog state ‘COMPLETED’. Once this happens, both the ServiceTopic and IssueDescription will be available (and confirmed by Alexa) to your APEX to create the Case.

This example would be even more powerful if you set up account linking. This would allow users to first log in to Salesforce (e.g. a Community) and therefore providing the developer with information about the Salesforce User while creating the Case.

All of the code for this example, including the model and full APEX can be found here: https://github.com/HKOLWD/AlexaForce/tree/master/samples/Dialog.Delegate.


Wednesday, February 14, 2018

[Salesforce / AppExchange Series] RingsTrue: Smarter phone numbers in Salesforce


This week's new post is dedicated to a new AppExchange app, meant to help us in one of the most difficult and annoying tasks on every CRM: phone number validation.

Thanks to our week's guest blogger Iain Clements.

Iain runs Cloud Ursa Ltd, a registered Salesforce partner based in the UK. In addition to helping customers configure Salesforce, we also make RingsTrue.

XConnect is a world renowned telecommunications routing specialist that provides the world’s leading global telephone number data and phone intelligence services. XConnect combines trusted information from hundreds of disparate global data sets and enables our customers to build the best communication services and applications using our unified data via simple, secure, scalable and real-time interfaces.


Managing data quality in Salesforce can be time-consuming.


Making sure that your customer records have correct telephone numbers is an endless task. However, authentic numbers lead to less failed call backs and lower contact centre costs. If that phone number belongs to a new potential customer, getting the right data also improves your business.


Can’t I just fix them with regular expressions?


Not easily! Unlike other global numbering schemes (eg IP addressing), Telephone Numbers have evolved organically, (and not necessarily logically). Using Regular Expressions (REGEX) means creating a set of rules, to take a string of information and ‘reformat’ that information into something else.

But what are these rules for Telephone Numbers?

  • Is the number in national or international format?
  • Does it include the national dialling code (eg 0)?
  • Does it include a country code ? How many digits is that country code?
  • Is the country code valid?
  • Does the remaining number have the correct number of digits for that country code ?
  • Is the National number prefix valid for that country?


So what’s the answer?


Well, we’re biased of course but we think our app RingsTrue is a huge time saver for this work.


RingsTrue powered by Xconnect brings a wide range of number checking functionality to your Salesforce environment and tells you if your telephone numbers are authentic or not. It’ll do the heavy lifting of formatting, validating, and actively testing the telephone number for every contact in your database.

Using RingsTrue, powered by XConnect, you will be able to:
  • Identify which telephone numbers in your CRM are Authentic and whether an authentic telephone number is a mobile number, fixed line number, or some other telephone number type.
  • Check which of the authentic telephone numbers is known to be In-Service with telecommunications provider.
  • Discover additional information about the capabilities and services supported by the end-uses devices, as well additional data made available by the mobile service provider.


How do I install it?


  1. Go to the Appexchange
  2. Click on Get It Now
  3. Choose to install in your test environment or your live environment
  4. When installed, go to the RingsTrue homepage and either click 'Run' or choose a schedule of phone checking to suit your company
  5. When RingsTrue has checked all of your records you will see clearly what the current status of that number is




Where can I try it out?


Try it for free for 5 days with no obligation, click here to start now!


Thursday, February 8, 2018

[Javascript / Chrome / EasyPeasy] Blocking form autocomplete after Chrome Canary (version 65)

Recent Google Chrome update (65) brought something that developers are not liking too much: the autocomplete="off" attribute on forms and inputs is no more considered.

Read in depth this Stack Overflow thread.

The solution (not so clear) is to give a random autocomplete value to the autocomplete attribute of each input of the form:

$('form input').each( function(){
   $(this).attr('autocomplete','no-autocomplete-'+(Math.random()*Math.random()));
});

Also apparently Chrome uses the name attribute (at least for email and password values), in my use case the name attribute was not necessary in the form so this script worked like a charm.


Tuesday, February 6, 2018

[Salesforce / Apex Test] Code coverage and logical tests in Apex Test Classes

This article is actually a repost from a buddy I came across online.

I read his articles on LinkedIn by chance and I really appreciated the easy way he writes and how he delivers important Salesforce concepts.

I choose an article about Apex Test Coverage... but before going on the article...
...please take a moment to hail our beloved lord the deployment fish!


The guest blogger

Vladimir Egikyan is a SFDC developer since 2010. Most of his career he worked for technical services providing company in Israel. During that time he helped to implement business of various companies, among which are ZIM Integrated Shipping Services, Bank Leumi.
In the latest three years he works as in-house developer and sharpen his architect skills. Though he is officially certified only as Developer... yet ;)



Writing good Apex Tests is a key to successful developing. There is a huge list of best practices and recommendations, that you can find in Salesforce documentation. Following them all, is what every developer should aim to do. Over years of developing on Salesforce, I learnt that code coverage is not what really matters…

How can that be?

Well, your coverage will raise by itself if you mind checking what your class or trigger has to do and what results you expect. Having said that, the most important thing that your test class has to do is to use System.assert methods to prove that code behaves properly. This will keep you on the safe side from any unintentional mistakes, changes in business requirements and eventually will save time and money on development process.

Okay, let’s take a look at the example:


TVRemoteControl class describes remote controls that can increase and decrease volume in scale 0-50 and have simple menu text.

Corresponding test class would contain call for each of class’ function:


TVRemoteControlTest covers the TVRemoteControl by 86% which is more than allowed minimum of 75% and these classes will deploy to production.

First and obvious defect of the test class is that it does not test if code will properly handle changing the volume beyond limits. The most important is we have to test that we get expected results in any possible use case. Our applications are almost never finished: business requirements constantly change. Besides that, we are all human and we always can make mistakes and test class is a tool that can help us to correct possible mistakes in time and that happens quite a lot.

Let’s see the better version of the test class.


This version of test class contains checking for going out of boundaries and also in each test method implements different use case and uses System.assert methods to make sure that class is performing the expected logic.

The given example is simple, but do not underestimate the importance of using assertion methods. Business logic in real life is way more complex then tv remote control, keep using these methods and you will be surprised how much time it saves for future technical support.