📟📟 COLLECT BUSINESS INTELLIGENCE FROM PHONE OR ANY IoT ENABLED DEVICE LEVERAGING SALESFORCE PLATFORM. 📟📟
Team: Vineet Kaul, Ajay Kumar, Alekhya
IoT Is Mainstream.
All technology professionals are increasingly being inundated with customer requirements to connect devices to CRM and/or customer engagement solutions. It is not just important to connect devices with CE systems, but the systems should ingest the streaming data and produce actionable insights into business behavior. IoT today is no longer technology, but a business problem and requires a business-centric solution. Today, companies use IoT data for operational performance in internal silos.
While the goals are simple, orchestrating such a system is could be an architectural mix of multiple technologies. By using the Salesforce technology stack, architects can design and deliver a seamless system that translates IoT data streams to data intelligence driving business decisions.
One way to accomplish this That is what we have tried to achieve in this submission.
The post takes two business scenarios and provides a detailed description of one of the many technology solutions to address them. For the more adventurous readers, it provides a description of code (GitHub repository included) and a self assist guide to implement a technology demonstrator on their own.
Uses In The CRM Industry.
🚑 Emergency Services: Track sudden change in altitudes of cars outside of safe envelop to detect accidents.
🚫 Insurance: Track driving behavior to determine insurance claims and renewal benefits.
📢 Marketing: Track gradual changes in altitude to send contextual notifications.
🚙 Automotive: Track vehicle acceleration, orientation to determine service plan.
And other amazing things you can think of !!!!!!
Business Scenarios
Usecase # 1: The same insurance company provides value-added services like emergency assistance and pick up to its insurance holders. The errant drivers for one would certainly need it.
In case of an emergency, the customer engagement application would track beacon messages from IoT-enabled devices to get the real-time location (static or kinetic) of the vehicle. While the application gets the immediate coordinates of the distressed vehicle(static), it also tracks the beacons of the moving vehicle. A combination of these could be used for emergency response or guiding drivers to the nearest workshop or gas station. And yes, you've read it right, everything is real-time.
Usecase # 2: An insurance company wants to link premium with driving behavior. It provides its customers with a device or mobile-based app that is kept on while driving. The solution pings sensor output (linear X velocity) to the insurance application.
If the speed exceeds a threshold value (let's say 20 miles/hr), the platform event engine automatically creates a "Violation" record with violation details i.e. excess speed, location, etc (yes, everything is real-time). The violation is attached to the customer policy record and each violation results in an additional surcharge at the time of policy renewal. Or in other words, no violation means no surcharge and less costly insurance renewal.
Technology & Architecture.
While it looks like complex architecture, with Salesforce technology stack, this could be orchestrated with clicks not code. Below, we describe the moving parts of the solution in detail.
MOBILE:
A simple app is required that sends a stream of sensor values as the customer is driving. MQTT is the best protocol for sending lightweight messages from a mobile device. In real life scenario, mobile could be replaced with an in-car appliance, satellite tracker, or anything that has a battery and connects to the net. In the solution, we transmit a stream of linear X velocity of the mobile phone to simulate vehicle speed.
HEROKU:
*CloudMQTT: The streams of sensor pings require a broker. This is provided by CloudMQTT, a Heroku based message broker. The broker receives the message stream that any customer based system can subscribe to. Such a pub-sub architecture has the following advantages
It de-couples the devices with customer engagement systems. Any new system can just plug into the stream rather than being hard-wired to it.
It allows message streams to be published under different topics e.g. speed, tilt, acceleration, etc. In the case of multiple systems, each customer engagement system could subscribe to the topic based on its business requirements.
Node-RED + MULESOFT
Once the MQTT broker receives a message, it is to be consumed and routed. This is termed as IoT orchestration. A combination of
Node-RED & Mulesoft flow forms the ESB backbone that does the following:
Node-RED: Integrates with the MQTT broker and collects the message stream. It throttles the message stream to ensure that downstream systems are not overwhelmed by the data overflows. Many customer engagement systems have data ingestion limits and strategies like throttling ensure downstream stability. There is no business sense as well to create multiple violation records for the same speeding instance, is it? Node-RED also strips the complex JSON message and creates a simpler message with limited values.
Mulesoft: Works as a messaging glue between the message stream and the subscriber systems. Mulesoft is the ESB backbone that publishes the message stream as a Salesforce platform event (we assume for this solution that our customer engagement platform is built on Salesforce). Multiple Salesforce Orgs can subscribe to the message and use it for their individual business logic. Mulesoft provides an inbuilt connector that publishes custom or generic platform events described in Salesforce. The advantages of an event-based approach are
Events order of delivery for a specific channel is guaranteed.
Event subscribers can be defined and integrated with the platform business logic through clicks not code.
Platform Events are non-transactional thereby resulting in no database overhead (an important factor for multi-tenant systems) and have high volume support.
SALESFORCE PLATFORM: (we assume for this solution that our customer engagement platform is built on Salesforce)
Usecase #1: Everything revolves around the subscription of platform events published by Mulesoft. For this use case, an empApi aura component displays the real-time message stream from Mulesoft. The component dynamically sets the map markers on receipt of each platform event thereby dynamically tracking the message source.
Usecase #2: Salesforce Flow subscribes to the specified platform event published by Mulesoft. When a platform event message with sensor event is received, the flow orchestrates and implements the business process i.e. check the speed value and create a "violation" record.
Watch the demonstration (Usecase # 1).
Watch the demonstration (Usecase # 2).
Want to give it a test drive?.
Complete installation and demo steps are documented in the README.md of repository
All technology professionals are increasingly being inundated with customer requirements to connect devices to CRM and/or customer engagement solutions. It is not just important to connect devices with CE systems, but the systems should ingest the streaming data and produce actionable insights into business behavior. IoT today is no longer technology, but a business problem and requires a business-centric solution. Today, companies use IoT data for operational performance in internal silos.
That is what we have tried to achieve in this submission.
There are 4 parts to the setup, fron setup to test. They might look complicated but everything is point & click configuration.
Step 1: Deploy Salesforce application.
Click on the button below to install the DriveSafe application package. The Salesforce Org should be Enterprise and above.
On successful completion of the deployment, log-in into…
There are 4 parts to the setup, fron setup to test. They might look complicated but everything is point & click configuration.
In case of trouble, post a comment on GitHub or this post.
Design Considerations:
As discussed in the architecture explanation, Platform Events are not unlimited. Even the High Volume Platform Events are governed by daily limits. For use cases where the message stream volume is very high, follow strategies that would limit the production & consumption of events and events.
Use throttle while delivering IoT events: Process each message in the message stream at a fixed rate. This rate could be based on the volume, size, or time. We have followed this strategy in this solution.
Use Report By Exception strategy: Block messages unless its value has changed.
