RealBox Data Analytics uses business intelligence and predictive analysis tools to help offline businesses increase revenues and decrease risk. In this project, RealBox developed an end-to-end solution for PVR Cinemas and its luxurious cinema experience, PVR Director’s Cut.

The RealBox solution involves an IoT device that serves as a point of sale in the PVR Director’s Cut. The prototype of the server-side API application was done in NodeJS running on virtual machines.

The solution also consists of three mobile applications:

  1. For customers who want to order food from their seats.
  2. For guest relationship assistants (GRA), who manage the orders.
  3. For kitchen order ticketing (KOT) and display.

A Microsoft team worked with RealBox to assist with the migration of its application to Azure App Service, which enabled RealBox to focus on its application rather than on continuous integration/continuous deployment or maintenance of virtual machines. The features of the App Service deployment slots decreased the turnaround time for fixes as well.

Microsoft also worked on implementing Azure IoT Hub for data ingestion from the RealBox point-of-sale devices. The mobile applications were designed and developed using Xamarin because the RealBox team had prior experience in C# and didn’t want to write repetitive code for multiple platform builds.

Participants

The core hackfest team:

Company profile

RealBox Data Analytics is a technology company based in Noida, India. It has developed an IoT device-based point-of-sale solution for cinemas and amusement destinations. This solution allows customers to place orders using a point-of-sale application on their own devices. As these orders are “punched” (entered) in the Cinema point of sale in real time, guest relationship assistants (GRAs) track the orders and their delivery to customers.

A local point-of-sale solution runs on iOS or Android devices and uses the IoT device as their gateway. The IoT device is a plug-and-play box running on Raspberry Pi 3 that can be managed directly from the cloud.

The point-of-sale box is responsible for connecting local point-of-sale (iOS, Android) applications, local GRA applications, and local kitchen order ticketing (KOT) applications with the cloud.

The solution uses the following Azure technologies:

  • Azure App Service
  • Azure IoT Hub
  • Azure Notification Hubs
  • Xamarin

Pain points

Application

RealBox had been developing its server-side API application locally using technologies like NodeJS and MongoDB and deploying early prototypes over Linux virtual machines. RealBox is a small team, and managing virtual machines, continuous integration (CI), and continuous deployment (CD) took a lot of their time. We deliberated how to introduce smarter practices to reduce deployment time and maintenance efforts. RealBox decided to use Azure App Service to host their API application.

There were some troubles at first but in just a couple of days the entire solution was migrated to Azure App Service and the team was then able to focus more on the product than on maintaining the server. It also reduced the time to deploy new changes, test them quickly, and bring them to production.

Device data management

The RealBox point-of-sale/gateway device needs the capability to do both device-to-cloud and cloud-to-device messaging. Cloud-to-device is a specific requirement because the orders punched by customers using the customer app need to be punched in the same point-of-sale box through API.

The RealBox team also needs to have visibility in terms of how many devices are connected and authentication of devices.

Mobile application

This solution has three applications:

  • Customer application. This is used by customers to order food from their cinema seats. The application must be available for both Android and iOS platforms.
  • Guest relationship assistant (GRA) application. This is used by Cinema GRAs and Cinema managers to manage the food orders and track their delivery.
  • Kitchen order ticketing (KOT) application. This shows the order status in Kitchens and notifies the chefs to prepare new orders. The chefs can mark the orders complete from this application itself.

The GRAs get the notification that the order is ready, pick up the order, and deliver it to the customer. This application can also serve as the point-of-sale application. It must be available for both Android and iOS platforms.

The RealBox team had C# skills so they decided to use Xamarin for these mobile apps. Xamarin enabled them to write one single code base for each application and prepare different builds for each platform.

Point-of-sale monitoring and troubleshooting

Maintaining a point of sale can be challenging. Point-of-sale companies have to keep ground staff for configuring (initial setup), updating (menu items), and troubleshooting. RealBox wanted to solve all of these problems at a very low cost. They wanted a plug-and-play device that can be configured remotely—from staff profile and branding to menu items. All information must be pushed to remote point-of-sale devices. In general, troubleshooters find that 80-90 percent of problems are with local devices—for example, thermal printer not working, Internet not working, PC being unresponsive. RealBox wanted to develop a way to self-test printers and the network and reset devices.

The hackfest

Solution

The new solution architecture consists of a number of Azure services. This includes Azure App Service, which hosts the RealBox APIs and artifacts for Xamarin apps, Azure IoT Hub, which helps with data ingestion as well as cloud-to-device messaging for new orders, and a notification hub that pushes the order status to the GRA application and the customer application.

The following diagram shows the architecture before the hackfest.

Figure 1: Realbox Pre-hack architecture

Architecture components

The architecture components include the following:

  • An Azure App Service-based NodeJS application. This NodeJS application hosts APIs and artifacts for Xamarin applications. This application uses a MongoDB database for the back end. The same app service also fetches order data from Azure IoT hub and ingests it into a MongoDB database.
  • An Azure IoT hub that receives order data from the RealBox point-of-sale device as well as sends order data to the point-of-sale device coming from the customer mobile application.
  • Three Xamarin mobile applications (customer app, GRA app, KOT app).
  • An Azure notification hub that helps push notifications to the customer and GRA applications.
  • A virtual machine-based MongoDB cluster.

The following diagram shows the final architecture at the end of the hackfest.

Figure 2: Realbox architecture

Hackfest objective

The following image displays all devices and applications in the RealBox solution: the RealBox point of sale, KOT app, GRA app, and customer app.

Figure 3: Realbox devices

The focus of the hackfest was to:

  • Migrate the RealBox NodeJS application from a virtual machine to Azure App Service and set up a CI/CD process.
  • Design and develop the Xamarin mobile apps.
  • Set up an Azure IoT hub and enable the Raspberry Pi 3-based point-of-sale devices to send and receive cloud messages.
  • Set up an Azure notification hub to enable the push notifications to the customer and GRA applications.

Azure App Service

RealBox didn’t want to invest the time and effort into managing the virtual machine-based servers. The application is a NodeJS (Express, Jade) one that uses a MongoDB database as a back end.

Some issues and resolutions:

  • At first we wanted a full platform as a service (PaaS) solution in which we would have replaced MongoDB with DocumentDB with MongoDB protocol support. However, it didn’t work out because DocumentDB at the time didn’t have support for MongoDB aggregate query support, which is used heavily in the RealBox solution.
  • The RealBox team realized that in the NodeJS solution, if the node modules are omitted while uploading the code using FTP, the server-side CD process of running the npm install command does not trigger.
  • The source must be a Git repo in order for the npm install command to trigger after the code push.
  • RealBox hosts its code in its own Gitlab repo so we created another “local Git repository” endpoint that acts as another remote branch. Whenever the team wants, they can do a push to the remote branch to make their build.

The team can now skip pushing the node module and Azure App Service will seamlessly run the npm install command over their code.

The NodeJS application also uses deployment slots to quickly test the staging builds and swap them in production.

Figure 4: Realbox appservices evidence1

Figure 5: Realbox appservices evidence1

Azure IoT Hub

The RealBox solution needed functionality for both cloud-to-device and device-to-cloud messaging to allow a seamless flow of orders from the customer app to Azure cloud to point of sale and from the local point of sale to Azure cloud.

Azure IoT Hub enabled the solution in following ways:

  • It lets the device securely register itself to the IoT hub so that it can be managed from the cloud itself.
  • It receives both device-to-cloud and cloud-to-device messages (orders).

The RealBox point-of-sale device is based on Raspberry Pi 3. It uses a NodeJS application to interact with the Azure IoT hub. The device can connect with both wire and Wi-Fi for Internet and can be provisioned remotely by the RealBox executive as soon as it comes online.

The process of provisioning a point-of-sale installation is as follows:

  1. The user unpacks the RealBox point-of-sale box, powers it on, and waits for the light on the box to turn red.
  2. The RealBox point of sale acts as a Wi-Fi router that the user can connect to with the password from the packaging box.
  3. The user connects to the Wi-Fi of the RealBox point-of-sale box with SSID “RealboxPOS”.
  4. The user opens a website, http://192.168.0.2, and sees a list of locally available Wi-Fi choices. The user selects the Wi-Fi SSID to which the RealBox point of sale must connect and provides its password. The RealBox point of sale reboots. The SSID “RealboxPOS” is now gone; the device will display a blue light to indicate it is connected to the local Wi-Fi and the Internet.
  5. A device registers itself using the Azure IoT hub SDK API; each registered device is stray until it is provisioned by the RealBox executive.
  6. The RealBox executive creates the location (cinema location) account on the executive portal and assigns a device (stray device) to the location. The same portal is also used to assign staff.
  7. The user can now connect the KOT printer to the box using USB. RealBox also provides USB converters for older KOT printers.
  8. The user can press the Action button on the RealBox point-of-sale device for five blinks of multi-color LED to get a test print from the KOT printer.

The device can also connect with thermal ticket printers and run commands over the thermal printers using delayed switches and show their status of online or offline using the LEDs.

The same delayed switching can help with different commands such as:

  • Test the thermal printers with test prints
  • Reset the Wi-Fi
  • Check status of Wi-Fi
  • Send test commands to RealBox server

A typical data packet consists of order information with details on menu items, quantity, location/seat served, PAX (number of people), timestamp, and taxes levied. The size of data packets typically varies from 10 KB to 30 KB.

An order can be initiated in the system from three nodes: A customer can punch an order from the customer application, a GRA can take the order while standing next to the customer using the GRA application (mobile application running on Android phones), or the point-of-sale executive can punch the order using the GRA app running on an iPad.

The following image shows the device along with its customized casing.

Figure 6: Realbox POS Device

The following screenshot shows the IoT hub provisioned for the solution.

Figure 7: Realbox IoT Hub evidence

The messages (orders) are sent to IoT hub in JSON format. The messages are read through the NodeJS application and ingested into the MongoDB database. The format cannot be shared due to IP reasons. RealBox is using the Razorpay platform for payments.

Only PVR-privilege card members can use the customer application. A customer must provide a mobile number for login, then gets authorized using a one-time password. The mobile number is used to fetch the customer-privilege card information and e-wallet balance. Customers must recharge their e-wallets to use this application. To recharge, they can use the Razorpay platform.

Access to the customer profile, e-wallet, and privilege card information is available through a secure HTTPS API hosted on Azure App Service.

Xamarin applications

RealBox didn’t want to write repetitive code for developing builds for different platforms. They already had a good C# developer who quickly picked up the Xamarin skills.

The process started from mock screens. Here are some examples:

Figure 8: Realbox Xamarin app 1

Figure 9: Realbox Xamarin app 1

Setting up the development environment

For Android, we used Visual Studio 2015 with Xamarin over Windows 10 machines to make Android builds.

For iOS, we used Macs with Xamarin Studio to make iOS builds.

During user interface design, we took care not to build any specific UI components that do not resonate with other platforms. As a result, the UI we developed was platform-agnostic.

Because the same applications can be white-labeled for different businesses, it was important that the user interface is customizable to the taste of the customer. All UI-related artifacts such as icons, and base color palette, are fetched via a REST API hosted on Azure App Service.

The menu and staff details are also fetched using REST APIs hosted over Azure App Service.

Consumer application

Only the consumer application is to be distributed using the app store. The other two applications are installed manually by RealBox support staff.

The consumer application can only be used by PVR club members. Login is through a one-time-password mechanism. The consumer application is already in the Apple store. (The URL is listed at the end of this report.)

The consumer application allows customers to place orders by selecting menu items and their quantity. Once customers have entered an order, they place it by selecting the seat to which it should be delivered and paying through the PVR wallet.

The consumer app pushes the order to a system using a REST API. This REST API pushes the order to a MongoDB database and sends the same message to the RealBox point-of-sale device using cloud-to-device messaging. The point-of-sale device updates the local KOT and GRA applications about new orders or updates of orders.

The following are screenshots of the consumer application.

Guest Relationship Assistant (GRA) application

The GRA application is used by the guest relationship assistant. GRAs are available on call in the cinema while a screening is going on. The consumer can place an order to the GRA and the GRA uses this Android application to punch this order. The GRA app can connect directly to the point-of-sale device using local network. It discovers the local point of sale using a discovery REST API that is available on Azure, but it does so only one time. Once the GRA app has discovered the local point-of-sale box, it can cache the address of the local point of sale and from then on it uses the local point-of-sale box only. This is to ensure that it can run when no Internet is available but the Wi-Fi is working.

The GRA application is not fancy—it has large buttons so the GRA can punch the order quickly. After the GRA enters the order, it is pushed to the point-of-sale box via a local REST API available on the point-of-sale box and the point-of-sale box pushes the same to the KOT application and prints a kitchen order.

The same GRA application can be used on an iPad and work as a proper point-of-sale box.

The following are screenshots of the GRA application.

Kitchen order ticketing application

The KOT application is a display system that is used in the kitchen. Generally, it runs on a tablet, but it also has a web version that can run on any browser. The cooks can look at the current running orders and mark them completed. This application also connects to the point-of-sale box in a similar manner as the GRA app. Once the cook marks an order as complete using the KOT application, the order-complete information is pushed to the point-of-sale box, which in turn pushes a notification to the GRA application. This notification tells the GRA to pick up and deliver the order to customer.

The following are screenshots of the KOT application.

Figure 12: Realbox Xamarin KDS app 1

Figure 13: Realbox Xamarin KDS app 1

Developed solution overview

We recorded a video that shows the end-to-end process of the RealBox solution:

IMAGE ALT TEXT

Conclusion

By the end of the hackfest, we had successfully developed and deployed the solution in the PVR Director’s Cut Cinema in Vasant Kunj, Delhi. The iOS-based consumer application is already live in the Apple Store under the name CineChef.

Except for virtual machines running MongoDB clusters, we used Azure managed services to develop the platform. We intend to move the MongoDB cluster to DocumentDB as soon as it supports aggregate query functions.

The next steps would be:

  1. Implement Azure Application Insights for efficient logging and debugging of issues.
  2. Implement Azure Stream Analytics jobs to get rid of the NodeJS process (but only when DocumentDB comes into picture).

“Microsoft has been supporting us along the way in our journey of discovery and innovation. Technology just keeps evolving and changing every day. Consultation with Microsoft helped us identify the right technical component and streamline the process. We are using Azure IoT Hub notification for discovery of our remote RealBox servers and MongoDB on Azure to save the acquired data. This enables us to run BI algorithms to update our product PULSE in real time that our clients love.”

—Saurabh Moody, CEO, RealBox

Resources