rob_valcich

What are Hue Talking About?

Blog Post created by rob_valcich Employee on Mar 1, 2016

Boomi helps thousands of customers connect the dots between systems. But what happens when your boss lets you grab some Philips Hue light bulbs for your desk?

 

When one talks about a true “business need”, flashing multi-colored lights should obviously be involved. There are three Philips Hue smart bulbs setup here atop my desk. They are labeled as “month”, “quarter”, and “half”, and perform two major actions:

  • Color, brightness, and saturation of each light is set according to the percentage of sales closed for the corresponding period. The color ranges from a dim yellowish white (0%) to a rich bright green (100%).
  • When a deal is closed in Salesforce, the lights all flash, and then cycle through all colors in the spectrum. The bigger the deal, the brighter and longer the show.

 

This is how it happens.

 

Hue can use the API

 

Once registered as a Philips Hue developer (free), HTTP calls can be made to the Hue bridge, which is the control center for all three lights. The bridge’s IP address, combined with an authentication code, provides the stub URL for the HTTP Client connector within Boomi:

 

 

Now that the stub URL is set, we can append stuff to it, in order to set the state of the lights, or even have them perform actions.

 

By default, the three lights are given IDs of 1, 2, and 3. Through the API tool, we are able to add these three lights into a single group, which is given an ID of 1. So, for example, to set the state of the 2nd light, we append “light/2/state” to the URL. To have all three lights perform an action, we append “group/1/action” to the URL. This part is done in the Boomi operation.

 

The fields in the JSON document used to set the state of the light are:

  • hue - Color of the light, which is a wrapping value between 0 and 65535. Both 0 and 65535 are red, 25500 is green and 46920 is blue.
  • bri - Brightness of the light. This is a scale from the minimum brightness the light is capable of, 1, to the maximum capable brightness, 254.
  • sat - Saturation of the light. 254 is the most saturated (colored) and 0 is the least saturated (white).

 

This is an example of the JSON, which (in addition to having the URL as /light/2/state) would turn light number 2 on, make it the color green, fully saturated, at full brightness:

 

{"on":true, "sat":255, "bri":100, "hue":25500}

 

The fields used to make the group of bulbs perform the alert and colorloop actions include brightness, as well as:

alert - Set to the value “select”, which makes the lights flash

effect - Set to the value “colorloop”, which makes the lights cycle through all colors in the spectrum

 

{"bri":50, "alert":"select", "effect":"colorloop"}

 

Now that we have the basics on how to talk to the lights, let’s talk about what drives the values being passed to them…

 

How are Hue (We) Doing? Color Based on Actual vs. Target Numbers

In order to determine which values to use for the setting of the lights, we have make some calls to Salesforce, and determine the percent closed for each period.

 

From here, the percentages are passed (via an XML profile) into a sub-process, which determines the colors, brightness, and saturation for the bulbs using some serious fifth grade math, using n as the percentage closed:

  • Brightness = n * 100
  • Saturation = n * 100 + 155
  • Hue = n * 9000 + 16500  (note: 0% = 16500, which is pale yellow. 100% = 25500, which is green) Anything beyond 100% starts turning bluish. This would be a good thing.

 

Hue Closed a Deal: Flash and Color Loop

Whenever an opportunity is closed/won in Salesforce, Boomi retrieves the email notification, and passes the XML content into an Atom Queue. This is in case there is more than one opportunity at one time. There is another process that is set up as an Atom Queue listener, which then retrieves the opps, one at a time, and determines:

  • How bright the bulb will flash
  • How long it will loop through the colors. Smaller deals go for a few seconds. For the big fish, we’re talking full-on Epcot Center up in here.

 

Once the lights get the message to flash and loop, they will continue doing so until another call is received to turn off the loop and set the colors. This subsequent call will occur on a delay, which is driven by the size of the deal. This is accomplished using some Java, and a dynamic process property called “DelayAmount”.

 

hue process flow.png

 

Java code in the “Delay Next Call”:

 

String myValue = ExecutionUtil.getDynamicProcessProperty("DelayAmount"); float f = Float.parseFloat(myValue); int waitFor = Math.round(f); Thread.sleep(waitFor);

 

Once the delay is complete, the “SFDC Get Boomi Opps” process described above is triggered to retrieve opportunities and reset the lights to the appropriate colors. This has a two-pronged effect:

  1. The lights stop looping
  2. The colors are updated to include this latest opportunity value.

 

Hue Made It!

Sure it’s questionable to consider this a business case. But, it does showcase how Boomi can easily speak to business systems such as Salesforce, but also to generic APIs for new, exciting IoT gadgets.

 

So if you have an extra couple of connectors available in your Boomi account, consider grabbing some bulbs and lighting them up.

Outcomes