Alexa, ask (on-Prem) HANA …

Voice Assistants such as Apple Siri, Google Home, Amazon Echo and Microsoft Cortana are coming around to be a common sight in various personal aspects. We often use them for asking about weather and news updates, looking up local businesses, getting directions, etc. It is indeed a convenient user interface for on-demand updates without having to open up an app, sign-in, navigate menus, etc.

This article presents a general architecture for enterprises that can leverage SAP Cloud Platform to integrate Amazon Alexa to on-Prem SAP applications, specifically SAP HANA in this case.

Objective

The primary objective of this article is to demonstrate how on-Prem SAP applications can be leveraged to improve consumer experience.
The primary objective is not to dive too deep into programing Amazon Alexa as there is a lot of in-depth documentation available on Alexa Skills Kit page.

Another objective of this article is to raise general awareness on an approach that leveraged SAP Cloud Connector in conjunction with SAP API Management and other tools from SAP Cloud Platform to securely expose selective functions of on-Prem solutions to be  used by  cloud micro-services. I am specifically excited about this approach and will dive a bit deeper into this.

This exercise helped develop a pretty good appreciation of how easy it has become to leverage Artificial Intelligence (a.k.a. AI) from various cloud providers. Businesses & IT teams can finally focus on consumer experience – more than the technology required to provide that experience.

Further, enterprise application users can be broadly classified into “external” and “internal” consumers. Please note that “External” and “Internal” in this case is not so much about the location of the user or the network segmentation. It has more to do with the Role that user is playing when interacting with these enterprise applications. For example, a Purchaser approving an order in an ERP is an “Internal” user of the system, while the Supplier given access to the same ERP to lookup new orders or update statuses is an “External” user of that same system. In those lines, a customer placing an order on an enterprise eCommerce Portal is “External” while the Customer Service agent logged on to that same eCommerce Portal to service customer questions / requests is an “Internal” associate of the enterprise.

Point in case being, providing external-facing access to some functions of the enterprise applications is very common. This is also the premise of this article considering Amazon Alexa is an external service trying to seek information from an enterprise application.

High Level Architecture

Below is an overview of different components in this architecture. A generic explanation is initially provided followed by brief description of components actually used in this exercise. This is because there are other possible components and/or architectures that can be leveraged to achieve the same goals.

Figure 1. High-Level architecture to let Amazon Alexa integrate to on-Prem SAP applications through SAP Cloud Platform

• The Amazon Alexa Skill / App.
• It is assumed here that you know how to:
• Configure an app invocation phrase.
• Configuring the Custom Skill’s Intents & Sample utterances.
• Creating an AWS Lambda function that will be invoked by the Alexa Skill.
• The Lambda function would call appropriate APIs (described below) based on the invoked Intent.
• Enterprise functions.
• This can be simply achieved by providing a secure REST web service.
• Depending upon the use case appropriate source needs to be identified.
• For example, if the enterprise function is creating an artifact (e.g. customer inquiry, complaint, etc.) it might be best to go directly to the source.
• Whereas, if the enterprise function is providing visibility to certain process (e.g. shipping reference, workflow status, estimation/prediction, etc.), an intermediate DW/ADW system can be leveraged.
• In this case, HANA was leveraged, as briefly described below:
• A high-performance HANA Model (Calculation View) was built based on data replicated in near real-time from multiple sources
• An OData based REST web service was developed around this HANA Model.
• How this API was exposed as an enterprise function for external consumption is described further
• Enterprise Function to Alexa Skill (Part-1).
• A simpler solution to this could be to setup a Gateway and Reverse Proxy to expose an enterprise API to the outside world (of course assuming in a secured manner!)
• However, a more simpler solution in this case was to leverage SAP’s API Management platform that enables –
• Creating external endpoint for selective enterprise APIs
• Creating & monitoring such endpoints across multiple environments, thus making management easier
• Integration with SAP products (HANA or Netweaver Gateway) in an absolutely painless manner.
• Considering getting this setup completed quickly, leveraging the API Management capability from SAP Cloud Platform was believed to be the right choice
• Enterprise Function to Alexa Skill (Part-2)
• A core component of this enablement is provided by SAP Cloud Connector that sits on an on-Prem infrastructure
• Unlike a larger networking effort (e.g. DMZ, firewalls, ports, etc.), SAP Cloud Connector allows selective applications, selective protocols (e.g. HTTP(s) / SMTP / RFC), and even selective URI paths to be integrated with SAP Cloud Platform solutions.

Use Cases Deployed

Considering business leaders as the persona, use cases were primarily around providing summarized information from multiple areas of operations. Some examples of those were as follows:

◉ Order counts and values based on key order types

◉ Orders blocked grouped by top reasons as well as by top customers impacted

◉ Top N customers by volume and order value

◉ Products in high demand from various plants

◉ Top N customers making product returns along with return reasons

◉ …

Learnings

Beyond the excitement of being able to wire cognitive intelligence to an enterprise system, the entire exercise provide key learnings that could be easily applied to future projects. These are summarized below hoping that these could benefit anyone getting their feet wet with similar journey

Constantly being aware that the consumer of a conversational app is relying completely on his/her hearing and speech. This is way more challenging than being able to fill up an online form and submitting it. Thus, being clear about instructions, input prompts, error messages, etc. is essential. At the same time, making it conversational is important in order to build a rapport with the consumer.

Chopping down the information in consumable bits is important. For example, instead of reading out 1234 as “one thousand two hundred and thirty four”, it may make sense to round off to “about one thousand” or “about twelve hundred” with some extra code. At the same time, instead of reading out the entire information, it may make sense to pause at logical points and ask permission to proceed further.

Exception handling and providing guidance to user in case of an error is very important. Note that the Artificial Intelligence is just around speech recognition. The means to obtain the data and generating response is still “your code”. For example, plan to handle error response from the API used in a certain Intent, or else Alexa is going to generate a standard response, such as “The requested skill could not be completed”, which does not seem directional from a user’s point of view.

Response time is very important – not only to provide a good experience to the consumer, but also because Lambda functions will timeout in a few seconds. Yes, you can certainly increase the timeout, but then remember the experience is going to degrade. One possible cause for this could be that the HANA Model utilized may not be fit for this experience. For example, a HANA Model designed for batch or to generate long detailed report may not be best for a voice interface experience.