When Salesforce is life!

Tag: iot explorer edition

[Salesforce / IoT] Let’s play the game with Salesforce IoT (part 3): Heroku IoT platform

 

In the previous post we have setup everything needed on the Salesforce side to configure the IoT Explorer.

Before jumping on the Arduino Nutellator 3000 project, we have to create a proxy that will transform data received from the devices in order to push them to our beloved CRM.

For those, like me, who are the typical TL;DR developers, head over the GitHub repository and have a look at this simple NodeJS project.

What do we need?

  • A Salesforce Connected App
  • An Heroku dyno to host the proxy (our own IoT Platform)
  • An Heroku Postgres Database (free tire) to handle basic authentication

What will this app do?

The main job of this app is to create Platform Events filled with the data that comes from the Nutellators and send this events to the IoT Explorer to finally trigger the orchestrations.

N.B. If the last sentence is totally obscure to you, please go back to the first post of this series to learn more about Platform Events and how they are related to Salesforce IoT.

Configure a connected app on the CRM

To send a Platform Event using the REST APIs, you’ll need a Connected App.

To create a new one go to Setup > Apps > Connected Apps and create a new app:

We won’t be needing the callback URL since (so put a protocol://fake formatted url) we’ll be using Username-Password OAuth Flow (more details here).

From this app you need the following info to properly configure the Heroku app:

Next thing you need your user’s username/password/token to complete the Oauth process.

Setup Heroku

Create a new Heroku app (let’s say iot-nutellator.herokuapp.com).
Fork the salesforce-iot-nutellator-proxy repository on GitHub.

Click on the Deploy tab and link the forked Github repository:

Do not deploy the code right now.

Add the Heroku Postgres add-on and set everything up

Jump to the Resources tab and look for Heroku Postgres addon (choose the free tier):

Let’s put some settings

Before deploying the code from GitHub we have to setup few settings on the Settings tab:

You should have seen the DATABASE_URL already there: this is the url to access the Postgres database.

Deploy

Go back to the Deploy page and hit the Deploy branch button:

Last action to make is executing the DB initialization code that creates a iot_user table with a single user called “user” with password” pass: this user (and any other you decide to add) will be used to authorize every request from the device using basic authentication.

To execute the script simply use the Heroku console:

Test it out!

Open the app on your browser using https://your-app-name.herokuapp.com.
If everything is ok you should see this message:

Salesforce IoT Proxy 
© Enrico Murru - blog.enree.co 2018

Anatomy of the proxy

The Express JS server exposes 2 different routes:

  • GET /: doesn’t actually do anything
  • POST /api/level: this is the route used by the devices to send their data

A typical call would be so formatted:

POST /api/level

Headers
Authorization: BASIC BASE64(user:pass)
Content-Type: application/json

Body
{
    "level": 30,
    "device_id": "T1-C0DE-IRI"
}

Where device_id is the Devide Id that we’ve seen in the Nutellator Salesforce object and level is the nutell-level of the device in %.

The result of such a call is an update triggered by the orchestration on the targeted device:

In the next and last post we’ll be closing the post series by having fun with Arduino and a Nutellator 3000 project.

[Salesforce / IoT] Let’s play the game with Salesforce IoT (part 2): Setup an Orchestration

Here we go with the second part of the Salesforce IoT playground post.

Read the part 1 post before going on to get the whole context.

Let’s start playing with the Salesforce IoT Explorer Edition by enabling it on the Setup:

The Salesforce IoT platform gives you the means to build business processes with point-and-click: you are still able to create triggers and complex logics, but now you have a simple tool that can be used to orchestrate your IoT information flow (aka Nutellator refills).

As you can see from the image above, new setup items apper:

  • Contexts: the configuration that matches platform events (Nutelleven__e) to Salesforce objects (Nutellator__c)
  • Orchestrations: this is the logic you build up to create powerful state machines that represent your Nutellators’ live state
  • Usage Data: lists all the orchestrations running on your Org

Let’s put all together

The Salesforce IoT Explorer flow is quite simple and works this way:

  1. IoT data comes from outside in form a HTTP post requests using REST APIs and Platform Events: data can be transformed and modified using Apex Triggers
  2. Each event is then coupled with actual Saleforce Sobject, the contetual data
  3. The context is then processed with Orchestrations which define state machines and translates state changes into business actions
  4. We have now Salesforce actions that can do whatever effect you want (external integrations, Sales / Service actions, …)

The Context

We have already defined the Nutellevent__e platform event and the corresponding Nutellator__c Sobject.

To couple them we should create a new IoT Context from Setup > Salesforce IoT > Contexts > New Context:

After the Context is created, let’s configure what’s inside. Click on Edit > Add Event data:

Select the main event and then the reference device ID that will be source to identify the context objects:

Now click on Add Reference data to complete the configuration:

Select the Nutellator Sobject and the unique field that represents the device:

Complete by hitting Save and then Done.

We are now able to link IoT data to Salesforce objects, such as knowing which device is sending data and which customer (Account) it belongs so.

Our first orchestration

It’s time to add logic to our IoT data to support our refill service.

Click on Setup > Salesforce IoT > Orchestrations > New Orchestration:

Our orchestration is meant to monitor the Nutella levels on the devices, so we are expected to have 3 different states:

  • Normal level: level is way above the minimum nutel-level, nothing to do here!
  • Warning level: we have reached a warning level, we have enough Nutella but it’s about to drop under the danger threadshold. This state is particularly important if we have different Nutellator for a given customer, and the support technicians could pro-actively refill more than one device when only one is under the danger level
  • Empty level: this is the danger level. From now on the Nutellator could finish soon its delicious sauce: it’s time to act not to let the customer without happiness.

To create a new state simply click the + Add State button (don’t worry if your colors differs from the following picture, I had to create and delete more states to match the idea behind the warning and danger ideas):

Switch to the Variables tab and let’s create the warning and empy threadsholds:

These variables should be used to evaluate the level received in the IoT data and to make the proper state transition. Let’s go back to the Rules tab and create a new rule for each state:

From NormalWarning when the level drops under the warning level, from Warning jump to Empty when the level drops under the empty level and finally when in Empty if the level rises up we’ll have a state transition to Warning (which can finally go to Normal.
We are using the Warning level as a “proxy” state of transition between the normal and danger states.

Click on the States tab to have a look at the state machine:

Let’s add some more actions.
When a new event comes, we want to keep track of the level on the Nutellator__c object as you can recall from the Nutellator tab on our Nuterllator 3000 app:

We can add a new action of each state that simply updates for any given incoming Nutellevel__e platform event the corresponding Nutellator__c object:

Click on the Add rule of the rule’s context menù (the three dots on the right side of the rule’s title), select Nutellevent__e on the when column, leave condition blank and set Salesforce record on the action column:

Select the Nutellator__c object and click Edit and select the following configuration:

Replicate this action on the other rules: you cannot use the Global Rules, because this kind of rules can only be used to reset context variables (such as counters, i.e. you could decide to activate the support process only if the state machine remains in the empty state for a certain amount of events received and not immediately).

Finally we need to start our support process if the level drops under the empty level.

Before adding this action, create a Nutellator__c lookip field on Nutellator__c object on the CaseEmpty Nutel-level state, stating that a new Case record should be used when state is entered (when column compiled with the State entered and a Salesforce record action):

This is the detail of the so configured Empty level:

Finally activate the Orchestration using the Activate button:

Let’s play the game!

Everything have to start with a platform event, which can be created via:

  • Apex code
  • HTTP post request

For the purpose of this post, we’ll go with the first method, and here is the execute code (made with the Execute Anonymous plugin of the ORGanizer for Salesforce Chrome & Firefox extension):

Nutellevent__e event1 = new Nutellevent__e(Nutellator_ID__c = 'TI-C04-41R1', Nutellevel__c = 99);
Nutellevent__e event2 = new Nutellevent__e(Nutellator_ID__c = 'T1-C0DE-IRI', Nutellevel__c = 99);
List<Database.SaveResult> results = EventBus.publish(new List<Nutellevent__e>{event1, event2});

We expect 2 different things:

  • Level and date/time of event are written on the Nutellator__c objects
  • The Orchestration’s state machine should have 2 devices on the Normal state (Orchestration’s Traffic tab)

Now let’s take one of the two devices and make its level drop under 30%:

Nutellevent__e event1 = new Nutellevent__e(Nutellator_ID__c = 'T1-C0DE-IRI', Nutellevel__c = 25);
List<Database.SaveResult> results = EventBus.publish(new List<Nutellevent__e>{event1});

Finally let’s drop under the 10% level and a new Case is expected to be automatically created:

Nutellevent__e event1 = new Nutellevent__e(Nutellator_ID__c = 'T1-C0DE-IRI', Nutellevel__c = 9);
List<Database.SaveResult> results = EventBus.publish(new List<Nutellevent__e>{event1});

And here is the Case related to the device:

With the given configuration you may have experienced a strange behavior: when changing state, the level on the Nutellator__c object is not updated.

This is caused by the order of the rules, that should be evaluated in the correct order: if rule makes a state transition before updatin the record, the record is simply not updated. The solution is to move the update rules before the state transitions:

What’s next

Now that we have all setup on the Salesforce platform, we can setup the real IoT platform (using Heroku?) that will send Salesforce the IoT data (transforming raw data into Platform Events) and I’ll show you how to build an Arduino powered device that will simulate the Nutellator 3000.

See you in the next post!

[Salesforce / IoT] Let’s play the game with Salesforce IoT (part 1): let’s get started

 
Have you ever heard of IoT before? I strongly believe so, it is one of the most trending topics everywhere.

It’s all about things (i.e. devices) that are connected through the Internet and can become smart by sharing their data.

Devices are only the first part of the IoT world: we cannot think of IoT without the “T” of things and we cannot think of IoT without the “I” of internet.

That said, the involved actors behind the “I” of Internet are not sentient machines that are ready to use devices data to rule humans (actually not yet) but actually platforms that can collect, elaborate and route this tiny pieces of data to make the devices actually smart!

What I want to say is that your toothbrush is not smart until you connect it on the Internet and make it talk with the “Toothbrush Factory Inc.” platform, which will hestimate your toothbrush consumption and alert you on your smartwatch or make an automatic order to Amazon.com, so you’ll receive the day after your new toothbrush head without even knowing you needed a new one!

What about Salesforce?

Salesforce is your toothbursh factory platform for Sales!

I guess the guys at Salesforce won’t like so much this similitude, and they may be right, because there is an actual distinction: Salesforce IoT is not an IoT framework that talks with the devices directly, but it is an application that works on the data produced by those devices, whose bits of data is transformed by proper IoT platforms (Google, Amazon, Microsoft, …) and consumed by Salesforce (who correlate that info with actual Salesforce objects).

This picture sums up the concept:

The Salesforce IoT product is meant to enhance your business by:

  • Combining devices data with Salesforce data to better understand devices usage
  • Orchestrating with code-less tools your business process around IoT data (you can still use “low level” Apex code to increase the complexity and customization level of your Org)
  • Increasing user engagement and customer perception (the customer knows he needs something only when the company tells him)

An example? Have a read at the dedicated Trailhead modules to better understand this concept.

An example please!

You own a company that provides rechargable Nutella stands: they are much like a coffee machine, the only difference is that the machine drops Nutella instead of coffee.

Author’s note: this is something that doesn’t exist, and it makes me really sad 🙁

You sell tens of machines all over you country and provide the “recharge” service as well, for an additional price.

Every Nutella device, which is connected via WiFi to the Internet, sends a data packet to your Google Cloud IoT instance telling the device ID and the amount of Nutella level (from now on called Nutel-level).

The platform takes those inputs and format them correctly so that Salesforce IoT platform can “eat” them (packaging them inside the so called Platform Events).

Whenever the nutel-level drops under a certain level, Salesforce IoT automatically activates its business process logic magic and a new Case is automatically opened and sent to the technicians along with a Work Order to start a field service operation.

Ready, get set, go!

Before activating the Salesforce IoT Explorer Edition let’s create the necessary metadata on our DE Org.

First we create a Nutellator__c custom object that represents the Nutella device with the following fields:

  • Device_ID__c: Text(255), unique, required, identifies a specific device by its unique id
  • Nut_level__c: Percent(3,2), % level of Nutella on the device (last measure)
  • Last_Measure_Date__c: Date/Time, date of last measure
  • Account__c: Lookup(Account), your customer
  • Location__c: Text(255), where the device is located

We could have used the standard Asset object, but I loved the idea of creating an object called Nutellator.

Second task is to create a Platform Event called Nutellevent__e: if you don’t know what a platform event is click here to learn more, but you can think of it as an ephemeral object that is not stored on the database but that can be used to trigger business logic.
The Nutellevent__e platform event is used to start the IoT flow on Salesforce: this object conveys the id of the device and the nutellevel percentage.

All is set up to start playing with Salesforce IoT Explorer Edition…but we’ll see it in the next post!

Powered by WordPress & Theme by Anders Norén