Mobile applications help organizations improve the productivity of their employees by speeding up business processes and improving the quality of services. Just think of a company delivering field services for maintenance and repair. Giving a technician the right information about a piece of equipment using a mobile app improves productivity and reactivity and reduces paperwork. Using photos and videos taken with a mobile phone to document the technician’s work leads to better customer satisfaction. Mobile applications can also help improve customer loyalty by allowing them to track work orders or to report feedback and problems. These are just a few examples—there are numerous ways to use mobile apps for business improvements.

However, developing a mobile solution with SAP access is not a simple task. If you want to use a full-fledged mobility suite with SAP connectivity on board you could easily invest more than $100,000 per year, according to the Gartner Magic Quadrant for Mobile App Development Platforms report. On the other hand, a lot of Mobile-Backend-as-a-Service (MBaaS) providers offer their solutions for a much more affordable price, but they lack the SAP connectivity.

The second reason is the feature set of Firebase as it offers my top five features for mobile application development:

1. Authentication: Firebase offers back-end services and easy-to-use user interface (UI) libraries to authenticate users of your app. It can use popular identity providers, such as Google, Facebook, and Twitter, but there is also support for industry standards such as OAuth 2.0 and OpenID Connect.
2. Push notification: Firebase Cloud Messaging (FCM) is a messaging solution that sends notification to devices in a highly reliable way. Notifications are received and presented to the user of a device even when the app is not running, and it can be used as a kind of wake-up call to open your app.
3. Real-time database: The Firebase database is a NoSQL database (Non SQL, sometimes referred as Not only SQL) that stores data as JavaScript Object Notation (JSON) and clients are connected to the database based on a publish-and-subscribe model. Mobile clients subscribe to parts of the database and they are notified in real time of all changes to the data. The sidebar “Firebase Database” gives you some further information.
4. On-device caching of data: The Firebase Android and iOS client libraries support on-device caching of data. Any data that is synced while the device is online is persisted to disk and is available offline. Furthermore, write operations to the database are queued on the device while it is offline and they are sent to the server as soon as the connection is online.
5. Firebase storage: Firebase storage is used to handle large files, such as videos and photos, in a reliable way. If the network connection is poor, you can stop and restart your upload or download where you left off to save time and bandwidth.

The third reason is Google’s commitment to Firebase and the quality of the Firebase Software Development Kits (SDK). Google has constantly improved Firebase since it was acquired in 2014, and in 2016 a much improved version has been released. Although there is a lot of fluctuation in the MBaaS business, a discontinuation of Firebase is very unlikely from my point of view. During my first tests of the Firebase environment I was pleased by the design of the application programming interfaces (APIs) and the operation of the Firebase back end. Therefore, I did not evaluate any other MBaaS back ends although for sure there are other excellent alternatives available.

Firebase Database

The Firebase database is a NoSQL database that stores data as JSON. There are no database tables. Instead you have a tree-like data structure, as you can see in Figure A. You use references to write data to a node or to subscribe to data changes of a node.

Figure A

JSON tree in the Firebase database

Security is another important topic for the database. You can set up security rules that give you a mechanism to tune the permissions of a subtree of your JSON tree.

Technical Architecture

Figure 1

Technical architecture

The technical architecture allows for an easy implementation of the maintenance scenario. Using the connector, the SAP system sends a notification to the service technician’s device to inform him or her that new maintenance orders are available. The SAP system stores the maintenance order data in the Firebase database. The service technician receives the notification and opens the mobile app. The new data is synchronized onto the mobile device in milliseconds. During the execution of the work order the technician uses the mobile app for time tracking. The start and the end times of the work are stored in the Firebase database and synced with the SAP system.

The SAP Firebase Connector

The Firebase SAP connector is developed using the Java programming language and it uses the Firebase SDK for Java and the SAP Java Connector (JCo) SDK. It is a standalone program that performs two different tasks:

1. Sending data to the Firebase database and calling Firebase services from the SAP system. In this case the connector acts like a server and the SAP system acts like a client.
2. Listening to changes in the Firebase database, and updating SAP data per these changes. In this case the connector acts like a client and the SAP system acts like a server.

The Java connector from SAP allows you to implement both tasks in a reliable way. I have implemented a Remote Function Call (RFC) server that performs the first task and an RFC client that implements the second task. The details of this implementation will be shown in the second article in this series.

Scenario 1: Sending Notifications from the SAP System to Mobile Devices

Now I show a real-world example of the connector in action. I have written an ABAP report that sends notifications to mobile devices. Figure 2 shows the interaction of the different components involved.

Figure 2

Sending a notification from an SAP report

The starting point at the left side of the figure is an ABAP report. Figure 3 shows the input screen of the report.

Figure 3

Input screen of an ABAP report for sending notifications

As a unique key for a user I use the user’s email address. You enter a message title, the body of the message, the name of the sender, and a notification type. Depending on the notification type, different icons are shown on the Android client in a list showing all notifications.

After executing the report there is a message that the notification has been delivered successfully. For testing purposes, I shut down my mobile phone while the notification was sent. Once I restart and my phone is online, the notification is delivered to my device and presented on the screen (Figure 4). (Note: All the screenprints of the mobile client shown in this article are taken from my Nexus 6 phone.)

Figure 4

Notification as it appears on a mobile device

When I click the notification, I get a list with all my notifications (Figure 5).

Figure 5

Notification list as it appears on a mobile device

For demonstration purposes, I have used different notification types, as you can see from the different images on the list. The ABAP source code for sending the notification is simple, as you can see from the source code shown in Figure 6.

FORM send_notification.
  DATA : ls_notification  TYPE zfirebase_notification,
         ls_firebase_user TYPE zfirebase_user,
         ls_return TYPE bapiret2.

*-#1- check user
  SELECT SINGLE * FROM zfirebase_user INTO ls_firebase_user WHERE
     email = p_email.

  IF sy-subrc <> 0.
    WRITE: 'User with email ', p_email , 'does not exists!'.
  ELSE.
  
*-#2- get notification data 
    ls_notification-title = p_title.
    ls_notification-body = p_body.
    ls_notification-fcm_id = ls_firebase_user-fcm_id.
    ls_notification-sender = p_sender.
    ls_notification-notif_type = p_notif.

*-#3- send notification
    CALL FUNCTION 'Z_FIREBASE_SEND_NOTIFICATION'
    DESTINATION 'FIREBASE'
      EXPORTING
        i_notification        = ls_notification
      IMPORTING
        e_return              = ls_return
      EXCEPTIONS
        system_failure        = 8
        communication_failure = 9
        OTHERS                = 10.

*-#4- check result
    IF sy-subrc = 0.
      IF ls_return-type = 'S' OR ls_return-type = 'I'.
        WRITE : 'Notification delivered successfully '.
      ELSE.
        WRITE : 'An error occured: ', ls_return-message.
      ENDIF.
    ELSE.
      WRITE : 'Technical Error' , sy-subrc.
    ENDIF.
  ENDIF.
ENDFORM.                    "send_notification

Calling Function Modules in an SAP System from Your Mobile Client

The Firebase database sync capabilities offer an easy way to call remote-enabled function modules in your SAP system from your mobile client. The approach shown here can be extended to other back-end systems. For example, you could also access an MS SQL server instance or a document management system. You just need a Java library that gives access to your server component. Before I get into the details, here is an important design guideline for software components: Adhere to the programming model of your existing environment.

This guideline might seem to be a little strange, but for me it is very important. There are candidates, such as asynchronous web services, that are available to be used to implement an RFC, but they introduce new complexity to your back end and to your client. Instead of using a new technology, I implement the function calls to the SAP system using the Firebase database as shown by the diagram in Figure 7.

Figure 7

Calling a function module in an SAP system from a mobile client

As a first step, the mobile app writes the data of a function call to the database and starts listening for changes to this data (#1). Then the app writes an update request for the function-call data to a queue located in the database (#2). The Firebase SAP connector is listening for new entries in the queue and when the request is written to the database, the connector is triggered (#3). The data of the update request describes the location of the input data and the type of request. The connector knows where the input data is in the database and which SAP function module should be called. The connector reads the input data (#4) and calls the function module in the SAP system (#5). Using the results from the function call, the connector updates the input data in the database (#6) and, as last step, the data on the client is synced with the new data and the UI is updated (#7).

This approach allows you to call function modules even when you are offline. You can also call function modules with a very long execution time. It just takes some time until you get the result, but you have the option to show the user that the execution has ended by playing a sound or by making the mobile device vibrate.

Scenario 2: Performing a Price and Availability Inquiry from a Mobile Device

The second example shows you how to call a function module in the SAP system from a mobile client. In this scenario, a service technician tells the customer that some parts of an equipment should be renewed soon. For internal planning, the customer wants to have price information and an estimated delivery date for the spare parts.

The starting point is an app on the mobile device where you enter the material number and a quantity. Figure 8 shows a screenprint of the Android price inquiry activity I have developed. In the upper part you enter a material number and a quantity, then click the SUBMIT button to send the data to the SAP system. For demonstration purposes, I have not implemented any check of the input data.

Figure 8

Price inquiry from the SAP system on a mobile device with airplane mode activated

In this example, I activated the airplane mode of my mobile device and then entered two price inquiries, shown in a list below the SUBMIT button. The Android ListView control that is used to display the price inquiries is backed by a Firebase database adapter taken from the Firebase UI library. This adapter automatically synchronizes the UI and the database without any additional coding.

After deactivating the airplane mode, the two price inquiries that have been locally cached are sent to the Firebase database and the processing (shown in Figure 6) is done. As a result, the data in the list is updated and you get an error message for missing input data for the first call and a successful price inquiry message for the second call, as shown in Figure 9.

Figure 9

Price inquiry message from the SAP system on a mobile device after airplane mode is disabled

Calling a function module in the SAP system is also used in my mobile app to update the database table with the user information. To send a notification (as shown earlier in this article), you have to know the Firebase Cloud Messaging instance ID of the targeted device. Then, each time a user logs into the app the authenticated user and the instance ID are stored in an SAP database table. This table is used to check the user name that you entered in the SAP report shown in Figure 3.

Scenario 3: Send a Work Order from an SAP System to an Android App

The third example shows you how to send a work order from your SAP system to a mobile device, and how to change or delete it at a later stage. The starting point is an SAP report shown in create mode (Figure 10) and in update mode (Figure 11).

Figure 10

Report to create a Firebase work order

Figure 11

Report to update a Firebase work order

In the upper part you can select whether to create, update, or delete a Firebase work order, and in the lower part are the input fields. The fields consist of the bare minimum for a work order, but extending the number of fields is easy.

After successfully executing the report (Figure 10) the work order (Figure 12) is presented on your mobile device. The START button at the bottom is used for time tracking. For the work order shown in Figure 12, I have executed the report shown in Figure 11 and clicked the START button.

Figure 12

Mobile work order

As the priority increases, the background color of the work order description changes and a STOP button appears to finish the time tracking for the work order. Figure 13 shows the corresponding data in the SAP system. The start date has been updated in the SAP system via an RFC and you also see the Firebase path of the work order, which is the link from the SAP database to the Firebase database.

Figure 13

Firebase work order

Although the example shown here is very minimalistic, it covers some important aspects of a mobile application.

Scenario 4: Sending a File from an Android App to an SAP System

The fourth example shows how to send a file from an Android device to an SAP system. Sometimes pictures or videos are worth a thousand words. In this scenario, for example, a service technician wants to document his work and highlight some equipment problems that might lead to failures in the future.

The Firebase database is not suitable for storing large files such as photos or videos. There is an upper limit of 10 MB per child node in the database and binary files have to be stored as base64 encoded. You could implement a workaround for this limitation by splitting a file into several objects, but it is much easier to use Firebase storage.

Firebase storage can store files of any size and it offers sophisticated support for uploading and downloading. You can stop and restart the upload and download, saving time and bandwidth. To add an image on your mobile device to a work order there is an activity that starts a dialog to choose an image. After you select an image, you can enter a description and select a work order as shown in Figure 14.

Figure 14

Transferring an image from the mobile device to an SAP system

After you click the SAVE button, the file is uploaded to the Firebase storage and then downloaded to the SAP system. The SAP system has a predefined directory where all the files from mobile devices are stored. Figure 15 shows the image from Figure 14 on the file system of the server on which the SAP system is running. It has a unique file name to prevent any problems with duplicate file names. 

Figure 15

File sent from a mobile device on the file system of the SAP server

There is also a database table in the SAP system where the description and the work order associated with this file are stored (Figure 16). 

Figure 16

Database table with additional information on the file uploaded to the SAP file system

Cord Jastram

Cord Jastram works for Computer Sciences Corporation (CSC) in Germany as a software developer. His main focus lies in software development using Java, ABAP, and C++. He holds a Ph.D. from Hamburg University, where he did research in the field of numerical seismic modeling. Before joining CSC in 2000, Cord worked as a software developer for various companies.

You may contact the author at cord.jastram@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.