Fun with Alexa & Hybris as a Service: yalexa

It’s a shame I’ve not written earlier about this. We’ve got Amazon’s Alexa and also Google Home available at Hybris Labs in Munich, but I’ve had so much other things going on, that I just could not concentrate a lot on this. Today,  I finally had a few hours play a bit more with Amazon’s Alexa. While I need to do more with Google Home, I’ve tried both to some degree now. I find the overall programming and configuration simpler, although Amazon is also trying to totally lock you in of course with the Lambda functions on EC2 – but you have a choice and my choice was to use my own Cloudfoundry based backend and YaaS APIs to implement the business logic. Continue reading

… and the best part is, it's open source!


This post is outdated! Please read yaas.js examples for more information!

It took us longer than expected, but here we go:

YaaS Client SDK for Node.js

The YaaS Node.js client SDK is an open-source JavaScript project that helps you to use and consume services.

If you want to skip the introduction, you can jump to the preparation or to the code directly!

Contribute on GitHub

As the whole project is published under the apache2 license, you can find it on GitHub under SAP’s namespace:

Find the module on npm

We also published the code as a module to npm (node package manager).

From time to time, depending on the changes, you will find new versions of the SDK there.


To be honest, there’s still a lot of work to do. For now, we included the services that were most important to us.
But let’s give you a quick start. Let me introduce you to

YaaS or hybris as a service

YaaS is a cloud offering by hybris.
It uses a microservices architecture – this means that instead of having a single, complex software, it is broken down in small services that provide a certain function. For example, there is a product service that let’s you manage and configure products you would use in a webshop.
There are lots of services that you can use and combine to build an application.
A simple webshop would use services such as Customer, Product, Cart, Checkout, Payment, and so on.

For a more detailed introduction, please visit YaaS in a nutshell

Consume services with Node.js – Preparation

To give you an idea how to use our SDK we prepared a code example.
This example is also included in the tests folder.

We have some prerequisites that this will work:

  • have Node.js 4.0.0 or higher installed (preferred is a version > 6.0.0)
  • have a terminal on your computer to work in
  • go to and create an account

Once you are set go to the YaaS Builder and create a new project:
Create Project
Enter any display name you like and give it a fitting identifier.
Project created
Once you created the project open it and go to Subscriptions.
Click on +Subscription (not the private subscription) and you will be redirected to the YaaS Market.
Select Beta - Worldwide (for now) and you will see a list of all the existing services:
List of services
Scroll down until you find Product Content (Beta).
Click on it and you come to the market page of this service.
Product Content Service
Here you can Subscribe Now and a popup will open
Select project for subscription
Select the Project for your Subscription (you should find the name of your newly created project in the dropdown) and Continue
Preview Subscription
You get another popup where you can double-check you selection. If it’s all good Subscribe Now
Subscription successful
As we only need one package in our Project, just click Configure It in the last popup!

You fill be redirected back to the Builder and see your project again.
Product Builder Module
Click on Products in the left sidebar.
Add Product
Select +Product here…
Add Product Configuration
…and you will see a configuration mask to add a new product.
Enter some details here as you wish and don’t forget to Save

Next, click on Clients in the left sidebar
Add Client
Select +Client here!
A client is, to keep it short, a set of credentials that you can use to receive API Tokens.
The API Tokens are necessary as YaaS authenticates with OAuth2.

You will now be able to configure your Client.
Select Scopes
First of all you need to select necessary scopes (types of permissions) you want this client to have.
We don’t need any in this example – just click Next
Configure Client
On the next page, you can give your client an identifier, a name and a description. Fill them out as you like and Save!
Client List
You come back to the Clients overview. Click on your newly selected Client!
Client Detials
Now you can see all details for your Client. We want the Client credentials, you find them on the bottom left. Click on Show
Client Credentials
You will see the plaintext of your Client ID and Client Secret. These are your login data, you need them when you talk to YaaS to receive an Access Token (for now just have the data ready, we’ll use the SDK for receiving a token).

Example and Code in javascript for Node.js

First of all, open a Terminal/Console
Generate a new folder and change to it.

Now, install the yaas.js package using npm

This install yaas.js to the node_modules folder.
First of all, we need to save our Client ID and Client Secret to a JSON file in this folder so that our script can access it.
Create a file called yaas-credentials.json

Open this file in your favorite text editor and insert

Don’t forget to fill in your Client ID and Secret!

Now create a javascript file and open it with your favorite text editor/IDE

Insert the code you find below. You can also find this example in the file /tests/test-yaas-product.js in the project folder.

The code snippet above has some useful comments included!
Some useful links:
Query Parameters on YaaS
JavaScript Promises

That’s it! Now run the script:

and you should see something like this:

The response is parsed JSON – you can see an array containing one item.
That is – of course – exactly what we expected, as we queried for a single sku (product number).

Now you should be prepared to play around with the other parts of the SDK!
If you do, tell us your feedback in the comments or shoot us an email!

Bullseye – in-store targeting and analytics – an update

Yes, it’s more than  a month ago since the last update. The assumption was right – tons of work was ahead of us. And still things need to be optimized, beautified and fixed… but an end is in sight! We’ve made huge progress… we got products, we got a name, we overhauled the technology and worked with the designers to beautify the whole prototype. All while maintaining full YaaS compatibility and flexibility.

IMG_20151214_144959#1 – the name:  bullseye. We think it’s great for a prototype about in-store targeting and analytics.

#2 – the products: we switched from perfume to candy. This morning, I got the confirmation for >180kg of candy delivered next week to the hybris labs premises here in Munich 🙂

#3 why do we need all that candy? At this point, we also got full confirmation to make this prototype the central piece of art/technology at the hybris summit 2016. We’re running our recommendation and analytics system for two days at this event. If you can, please stop by!

In case you’re completely unsure what this is all about, here’s a brief summary – directly form the documentation that I’ve written yesterday.

Screen Shot 2016-01-15 at 3.37.30 PM

So let’s take a more technical view on the updates. Below is the current arch diagram, also soon to be even more shiny. For now, all technical goodness is on it. Let’s step through each part.

Bullseye - plat Technical Architecture (1)


bullseye is a YAAS-based in-store product recommendation and analytics system. The end-user facing and visible components are the platforms (here numbered from 1-8) that can be programmed via commands in various ways. For product selection, for example, the platforms may receive color events. The platforms also contain one or multiple sensors whose values can be requested. For power supply and communication, the platforms are connected to a base station via a standard Micro USB cable. As a typical IoT edge device such as a Raspberry PI has only a limited number of USB ports and limited power supply, standard USB 2.0 hubs are used in between the base stations USB ports and the platforms.

Recent updates here, not including bug fixes:

  • We’ve optimized the serial communication – previously all commands sent to the platforms (serial, byte-based communication) responded with an event that repeated the data for confirmation. We’re only responding with a JSON-formatted response in case the command triggered an EEPROM update or a sensor reading.
  • We’ve implemented new commands, mainly for light effects. The platforms can now flash in RGB colors (random flashing, simulates a “thinking” system” and a few other color effects.

Next, the base station – that’s where the platforms connect to via USB cable:

The base station is acting as a gateway between the platforms and the internet. It connects to the internet via the IoT standard protocol MQTT and to the individual platforms via a serial, byte-based communication protocol. The base station is subscribed to a MQTT topic for the base station itself and issues commands that are sent to this topic to all connected platforms. At the same time, it is also subscribed to individual topics for each platform – this allows each connected platform to be addressed individually. The central communication broker in this system is a MQTT broker. It is the essential element that connects the base stations to the internet and allows the remaining bullseye system to send commands to the platforms and to receive events from them.

Recent changes:

  • We can now address the base station itself with a dedicated MQTT topic and the base station forwards the command to all connected platforms. This minimizes the network load and is great in combination with the “flash” command. We use this command to simulate a thinking system, right before the results are presented with individual lit-up platforms.
  • MQTT reconnect behavior: we’v fixed a major bug around the reconnect behavior. From time to time, our MQTT connection is closed due to network issues. We’re now able to subscribe to all platform topics so that the system stays fully functional.
  • Our base stations are now Raspberry PIs and we use the excellent forever-service to start our node process in a “forever” fashion. Even if the process is killed, forever restarts it immediately.

Let’s move on to the bullseye YaaS package:

The bullseye package is part of the YAAS marketplace and can be subscribed to by a client project. The package contains the bullseye service, offering various UIs for the end user and retailer, and also the central matching service.  The matching service is a completely tenant-aware service, that uses the profile input from a customer questionnaire to score a selection of products. The result is a scored list of products that are mapped to platform IDs and then addressed with a color command over MQTT. This results in a physical selection of products based on a previous product matching algorithm. The bullseye service also contains an internal analytics module that is powering various analytics UIs. The bullseye builder module is used by a client project to configure the bullseye system. Typical configuration includes the mapping of products to platforms and the setup of a customer-facing questionnaire with scoring information for each correctly answered question.

Changes, well, tons. Let’s see:

  • The matching service is the central component, taking the profile info and matching it with products based on the questionnaire and scoring information. We’ve now implemented a proper blocking behavior – a user enters a session and operates the base/shelf alone for 30 seconds. If he chooses to keep using the shelf, the session is extended.
  • We’ve created 3 analytics screens that connect to real-time data via channels. All analytics is in memory, which is OK for a prototype. It’s nicely part of a single node.js library and could easily be persisted. Below are some of the analytics screens. More later on when the screens have been completely redesigned.
  • The questionnaire / form UI is already beautified. in the pics below, you see the result. It works excellently on desktop/tablet/phone, fully responsive. Form resubmission for flashing effects and the back button to play again complete the changes here.
  • A product info screen, connected to live product liftups, has been added.
  • A randomizer feature will perform a slideshow among the 3 analytics and product info screens. For events, we’re able to launch it and it just runs and shows all screens over time.
  • More… but this is getting too long…

So – you probably want to see some pictures, right? See below. What’s next? While a lot has been done, we’re still working on finishing touches. Potentially we’ll save the product results to a customer’s cart – so when she opens the cart later at home or at the event, the cart is prefilled with the matching products. We also need to take care of all kind of UI related small issues and we need to make sure the logistic for the hybris summit are taken care of. We’re creating an amazing construction, a pole-like art installation, together with our booth builders here in Munich. Stay tuned!

The state of the end-user questionnaire UI:

Screen Shot 2016-01-15 at 3.19.21 PM Screen Shot 2016-01-15 at 3.19.33 PMScreen Shot 2016-01-15 at 3.19.25 PM  Screen Shot 2016-01-15 at 3.19.40 PM

The state of the builder module:

Screen Shot 2016-01-15 at 3.21.16 PM Screen Shot 2016-01-15 at 3.21.25 PM Screen Shot 2016-01-15 at 3.21.39 PM Screen Shot 2016-01-15 at 3.21.52 PM

And finally some of the early analytics screens:

Screen Shot 2016-01-15 at 4.15.48 PM Screen Shot 2016-01-15 at 4.15.54 PM Screen Shot 2016-01-15 at 4.16.12 PM Screen Shot 2016-01-15 at 4.16.22 PM

In-Store Targeting and Analytics – on YaaS!

It’s finally time to write about a new project we’re working on. Hopefully this also helps to clear up a few open issues we’re still working on. So here’s some news about a project we’ll probably name “bullseye”. To some degree it is an extension of the wine shelf. But it’s super flexible in terms of configuration and products. And – boom – it’s almost 100% based on YaaS, the new hybris commerce APIs.

Architecture, rough… 

This architecture is rough and can change any moment, but it’s a good ground to describe what this is about. The idea itself – again – is about selecting products in the physical retail space. And also about providing feedback to the retailer about physical interactions with products. YaaS plays a big role as we use the YaaS Builder Module system to edit all the configuration of the system. We’ve also written our own YaaS service, that provides the product matching logic in a completely tenant-aware fashion.

Bullseye - plat Technical Architecture (1)

Platforms and Bases = Smart Shelf

From a technical perspective, the hardware used is less impressive. It’s really not the focus this time. We’ve worked on a 3D-printable design that contains the electronics for the hardware parts of this prototype. Each of the platforms below (so far we have about 20 fully working platforms) contains a microcontroller for the logic, a large 24 NeoPixel LED ring (output) and a LDR (light dependent resistor, input). The platforms connect via Micro-USB to a base (power, serial data), which most likely will be a Raspberry PI again. In between, we need standard USB 2.0 hub, as  a Raspberry PI has only 4 USB ports and we would like to power as many as 20 or 30 platforms from one base. Check out some images below.

IMG_20151210_101416 IMG_20151210_103701
IMG_20151021_153508 IMG_20151210_103708

The firmware that runs on the platforms is able to receive a few commands over a custom serial protocol. Via this protocol, we can change the identity of the platforms (stored in EEPROM), read the sensor value or issue a light effect command (e.g. turn all pixels on, turn them red). It’s a fairly low-level, basic, communication protocol. The only business-level logic that so far still runs on the microcontrollers is the calculation of liftup times. We count the duration between the increase of light (product lifted) and the decrease of light (product down). To not interfere with the NeoPixel (light) ring, we’re blocking the event calculation during the light effect execution.

The bases, most likely Raspberry PIs, each have a unique ID. The platforms, again, have unique IDs. Via MQTT (node.js using MQTT Client Software) we can issue commands to the bases and to the platforms directly.

MQTT Broker

An important architecture component that we can’t live without is the MQTT broker. Due to port restrictions and other technical issues, this part is currently outside of the YaaS cloud. For now, the bases connect to the broker to connect the platforms over serial. The bases subscribe to MQTT topics that match the platform ids. They also subscribe to a base-level topic, so we can send base-wide commands. If a platform disconnects from a base, we unsubscribe from the MQTT topic of that platform. This ensures that the communication bandwidth required is lightweight.

YAAS Builder Module

The builder module that you get once you subscribe to our package in the YaaS Marketplace allows you to configure the physical mapping and the questionnaire that the end-user finally gets to see. The products derive from the products you’ve configured via the YaaS product service. Below are a few honest screenshots, before we even started styling these screens (be kind!).

As a user, you’ll first have to choose a shelf, which is identified by the id of the base. Next, you choose which product category you’re creating the recommendation system for. All products of the shelf need to adhere to a common set of attributes, hence the category. Third, you’ll assign the products of that shelf/category combination to platform IDs. Finally, the scoring configuration – which questions, which answers, which score per correct answer is specified. The scoring configuration is the key ingredient to the end-user questionnaire form. Once all four steps are completed, the retailer is given an end-user URL that can be turned into a shelf-specific QR code (or put onto an NFC tag, or put onto a physical beacon or shortened and printed, etc.).

Screen Shot 2015-12-10 at 11.37.10 AM Screen Shot 2015-12-10 at 11.37.13 AM
Screen Shot 2015-12-10 at 11.37.17 AM Screen Shot 2015-12-10 at 11.37.35 AM

YaaS Matching Service

Our matching service is triggered by a special URL that goes through the YaaS API proxy. All requests and bandwidth is counted and can later be billed. The end-user experience begins with a rendering of the questionnaire. The user chooses his answers and sends the data off to the matching service. The matching service now pulls the scoring configuration, the products and the mapping to calculate the matches. Based on the relative threshold, we calculate which products and therefore physical platforms are highlighted. Now, MQTT messages are sent out to the bases/platforms to highlight the appropriate platforms.

Screen Shot 2015-12-10 at 1.08.54 PM  Screen Shot 2015-12-10 at 1.09.03 PM

Once a customer uses the system via a questionnaire, the shelf belongs to her for the next moments. This means we block access to the tenant/shelf combination for some time. During that time, the user is interacting in a personalized session with the shelf. Lifting up a product results in the display of detailed information directly on the customer’s tablet or smartphone. And of course, it fuels a few analytics displays that still need to be detailed.

What’s next? tons of work ahead.

We’re working hard on the specs for the initial version of this prototype and some sample products, categories, configuration that we’ll use for the hybris customer and partner days in Munich 2016 (early February 2016). But we’re also thinking of a few extra features that might make it into the prototype by then: for example, we’re thinking of a stocking mode, in which the platforms highlight one after each other and the screen shows you the product that needs to be on. It helps both the labs member to setup a demo as well as the retail employee to stock a shelf. And we’re thinking of sending the recommended products via email. A customer could then continue the shopping at home which a pre-filled cart.

Got ideas? Let us know. This is the time to provide input!

IoT with Arduino Yun and YaaS

Arduino Yun IoT

The Arduino Yun hooked up to an LDR light sensor

Inspired by Georg’s post about connecting the ESP8266 to the upcoming hybris as a Service (YaaS), I thought it would be great to connect an Arduino microcontroller to the YaaS platform to showcase an Internet of Things (IoT) scenario. To keep this proof of concept (PoC) small, I decided that fetching an OAuth2 token and posting a sensor value to the YaaS Document Repository would be a good start.

The Arduino however does not have any out of the box capability to send data to the Cloud. There are many modules (or shields) which are able to connect the Arduino to the Internet, including Ethernet, WIFI or using Bluetooth Low Energy (BLE) through a gateway. Due to the Arduino computing and memory constraints, almost all of those connection options cannot levarage security layers such as HTTPS or TLS. The hybris YaaS platform though requires data to be sent using HTTPS which does not leave a lot of options for secure IoT with the Arduino.

While looking into different options I saw that we had an Arduino Yun lying around in the office and so I decided to use it for the PoC. The Arduino Yun is a hybrid microcontroller board which includes a full-blown Linux System-on-a-Chip (SoC) as well as the same AVR chip found on an Arduino Leonardo. The Arduino IDE includes a Bridge library which lets the Arduino microcontroller talk to the Linux SoC over a USART serial connection.

Instead of implementing an Ethernet and/or WIFI driver plus TCP/IP and HTTP for the limited AVR microcontroller, the Arduino team created a lightweight wrapper for the CURL command line HTTP client which is called over a serial bridge on the Linux SoC.

Unfortunately, this library currently implements HTTP and not its secure variant HTTPS nor sending POST requests. In order to make web service calls to YaaS, I had to implement my own little wrapper around CURL for fetching YaaS tokens and for sending secure POST requests to the YaaS Document Repository.

The sensor that I am using is an LDR (Light Dependent Resistor) which is connected to the Arduino’s Analog-Digital-Converter (ADC) port A0 using a voltage divider circuit. The circuit was set up on a breadboard and connected to the Arduino Yun.


YaaS client library in the Arduino IDE

I am using the Arduino String library to construct the JSON strings for the HTTPS request bodies. The Arduino Yun YaaS library I created only implements the following features: requestToken(), securePostRequest() and a super simple jsonStringLookup() to parse the token from the JSON response. Packing this functionality into 32kb of program memory and 2kb or RAM of an Arduino was a real challenge. When running out of RAM on the microcontroller, things will just stop working without any warning. The Arduino IDE only offers serial messages for debugging.


Successfully requested OAuth2 token and uploaded a sensor value to the YaaS document repository

In the process of writing the YaaS HTTPS library, I realized that doing requests by wrapping CURL requests does not provide a great level of flexibility when it comes to error handling and retries of requests. There are also some drawbacks to having a Linux SoC on the same microcontroller board: the difficulty of battery operation due to its power requirements or keeping a full-blown Linux system maintained and secure over time.

With my Arduino Yun PoC I have proven that it is possible to connect an Arduino to our new microservices based cloud platform YaaS. I learned that doing HTTPS requests on an 8-bit microcontroller is only feasible if you are using a more powerful gateway such as the Linux SoC included in the Arduino Yun. As a next step, it would be great to be able visualize the sensor data which I am pushing to the document repository. That’s a story for another blog post though.