Enterprise Mobility @ SAP – Application Development – Relay

This is another blog post of a series around the enterprise mobility IT team at SAP. We are an internal IT team focused on managing mobile devices, applications, and developing custom apps for SAP’s 100,000 employees. I have been a part of this team for the past six years and believe we have some unique stories, software, tools, and insights to help others in the community considering, or currently undertaking, some of the challenges which surround mobility and its adoption in the enterprise.

Introduction

As mentioned in previous posts, apps are an essential cornerstone of mobility @ SAP. Whether they are employee initiated or driven by innovation, we adopt the underlying processes and do our best to deliver solutions that increase our end users’ productivity. This post will take a deep dive into the ideation, architecture, design, and lifecycle of an internal app called Relay. A real-time chat application initially developed in 2012 using the Business Technology Platform (Previously known as the SAP Cloud Platform). A variation of the application might be familiar to some of you SAP community users, as Messages. We recently retired the application internally due to the increased adoption of MS Teams and Slack. However, I believe that some of the concepts and premise behind the application are still relevant to share.

In addition to a simplistic chat application, we wanted Relay to have some additional features:

2012	2020

Developing a real-time chat app is not easy, as there are many small intricacies that take the application from simplistic to what consumers would expect. Read/Delivered notifications, push notifications, message read delays, emojis, individual message emojis, scaling, custom controls, security, encryption, integration, message search, link previews, and cross-device message synchronization are just a *few* of them.

While building Relay on the Business Technology Platform would be easy to accomplish today, we faced multiple challenges because, at the time, the platform was still evolving. Real-time communication with web-sockets, custom UI5 controls for our web application, and push notifications were not necessarily highly demanded features for business applications at the time. On the other hand, experimenting with new technology and web standards helped us deliver valuable feedback to the development teams.

The team developed a Java backend for the application, initially using MaxDB for persistence, and subsequently SAP HANA when it became available on the SAP Cloud Platform. We decided on a REST-based Web API and an event bus based on WebSockets as the underlying communication protocol due to its support and availability in the Java ecosystem and open source libraries for the clients.

For the clients, we developed a native universal iOS app for iPhone and iPad, an Android app, a universal Windows app. We also packaged and “compiled” the HTML5 app using Electron for desktop use on Mac and Linux. In terms of clients, this was the most prolific client deployment we had since we wanted our users to have a native experience on any of their devices. In 2018 we decided to rewrite the web frontend and moved from SAPUI5 to Angular. This was primarily a technical resource decision, but we also wanted to expand our skillset as a team and have something to compare UI5 to, as it was the only frontend language we had previously developed our enterprise web apps in.

In addition to the core library dependencies like Angular.js or Material Design, we depended on a couple of very helpful libraries:

One beneficial aspect of developing your own chat solution is morphing and integrating additional scenarios with little effort. A nice integration example that we wrote for Relay was “Relay Wall” – this displayed the content of a Group or Public chat via a large format UI perfect for a projector or event, providing a way for attendees to interact with each other in realtime. It was popular at social events, conferences and a variation also made its way to the SAP Arena in Mannheim.

Conversational UI & Bot Platform

Another integration scenario we built focused on conversational UI and API’s which support a bot platform. I have another blog post planned to outline the architecture and overview of this.

UsageBefore Slack and Teams were being deployed at SAP, Relay was a helpful tool and a great experience builder for us. We did have some special surprises which we never really considered when developing the tool.

1.) One of the most popular and active chat groups was a public chat of “Pictures from around the world” at least a few times per day, an employee would share a photo from their current office, vacation, or location. A great way to share something interesting and beautiful with their colleagues.

2.) Public chats were considerably more prevalent than we had imagined. Besides mass email, there is no way for employees to discuss internal topics in a large forum openly. The chats were used during Global all hands calls and at major events to discuss important issues and keynotes and respond to attendees’ comments and questions in real-time. Chat alone is appealing as a communication tool, but when used as a facilitation or ancillary tool, is where we think it really shines in the enterprise.

3.) Chat is a great workflow tool – we had multiple teams who created group chats with individual vertical silos of workloads who independently pushed and pulled tasks that needed to get completed. Some teams subsequently developed custom integrations for just this purpose.

If you are interested in a specific implementation or component of Relay on the Business Technology Platform, please feel free to reach out. I would be happy to answer any questions in the comments!