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.
I show how you can create a reliable and affordable mobile back end for your SAP system by developing an SAP connector for an MBaaS solution.
(Note: SAP offers a strong portfolio of products for developing mobile solutions. When you want to execute complex business processes using a mobile device, SAP HANA Cloud Platform [HCP] and the SAP mobile platform are the way to go. They can connect to anyDB on premise. In addition, Cloud Foundry services on HCP, which is in beta, can connect to any email server, including Lotus Notes. However, it is always a good idea to look at alternative ways to implement mobile solutions, such as the one I describe in this article. It broadens your technical skills and helps you to better evaluate the strengths and weakness of the SAP-based solutions. This article is especially useful if you have no or only a little experience in mobile development.)
For the MBaaS component in this scenario, I have chosen Google Firebase (https://firebase.google.com/) for three reasons. The first reason is that Firebase is a cloud-based solution. After creating a free Firebase developer account (available for up to 100 users), you can start developing without any further hardware setup. (You do have the option to scale your app to thousands of users by upgrading to a paid subscription.)
The second reason is the feature set of Firebase as it offers my top five features for mobile application development:
- 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.
- 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.
- 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.
- 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 up- 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.
(Note: There are other services, such as Firebase Analytics, to gain insights into the user behavior, and Test Lab, that allows you to test your Android app on a variety of devices running in a Google data center, but these services are beyond the scope of this article.)
For details about the Firebase database, see the "Firebase Database" sidebar at the end of the article.
Firebase is a good fit for the mobile part of a mobile business process, but it is missing the data that is needed, whereas an SAP system is an excellent data source. Think of work orders that are created in the SAP system. You have all the necessary information, including execution date, customer address, and contact person available, and Firebase can sync this information with mobile devices. Using a Firebase connector for the SAP system to bridge the gap between the two systems, you get a technical architecture as shown in Figure 1. There are mobile devices that use the real-time synchronization feature of the Firebase database and the Firebase services. On the left side, there is an SAP system with an attached Firebase connector.
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 synched 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:
- 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.
- 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.
(Note: The RFC server technology offered by SAP allows you to call software components written in the Java programming language from your ABAP coding. An RFC server is a standalone program that registers at an SAP system, and that can be reached by calling an ABAP function module with a destination as an additional parameter. In this case the ABAP run-time environment forwards the function call to the RFC server and returns the result of the call back to the ABAP report. RFC servers have built-in support for multi-threading and you can start multiple servers that are called by the SAP system in a round-robin fashion.)
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.
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.
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.)
Notification as it appears on a mobile device
When I click the notification, I get a list with all my notifications (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.
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!'.
*-#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'
i_notification = ls_notification
e_return = ls_return
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 '.
WRITE : 'An error occured: ', ls_return-message.
WRITE : 'Technical Error' , sy-subrc.
Code for sending a notification from ABAP
I won’t go into the details, but using fewer than 50 lines of ABAP code you can send notifications to mobile devices. You just check the existence of the user (#1), get the notification data (#2), send the notification (#3) by calling an ABAP function module with a destination as an additional parameter, and check the result (#4). The function module calls the RFC server shown in Figure 2 and the RFC server sends the data to the device using the FCM service.
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.
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.
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.
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).
Report to create a Firebase work order
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.
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.
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.
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. 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).
File sent from a mobile device on the file system of the SAP server
Database table with additional information on the file uploaded to the SAP file system